# Chainstack > Managed services for blockchain > Contact: admin@chainstack.com ### Posts #### Deploy blockchain nodes on your own infra: Introducing Chainstack Self-Hosted Our goal has always been to be the go-to blockchain node platform across any chain and environment. Today, that includes the nodes you run on your own hardware. Running your own Ethereum infrastructure should be the basic right of every individual and household. Nodes should be easy. Vitalik Buterin  ·  @VitalikButerin  ·  Mar 15, 2026 The catch? Self-hosting has always meant complexity. Manual setup, client updates, nodes falling out of sync, monitoring cobbled together from spare parts. We built Chainstack Self-Hosted to fix that. What is Chainstack Self-Hosted? Chainstack Self-Hosted is a turnkey blockchain node management platform that lets you deploy and operate blockchain nodes on infrastructure you fully own and control — from cloud VPS to your local environment, and everything in between. It brings the operational layer that Chainstack has built for managed infrastructure and makes it available on your hardware. That means automated deployment on any protocol, built-in monitoring and alerts, self-healing, automated updates, and configurable failover — all running inside your own environment, with your data never leaving your perimeter. The core idea is simple: you shouldn’t have to choose between owning your infrastructure and having a production-grade operational experience. Chainstack Self-Hosted gives you both. How it compares to DIY If you’ve run self-hosted nodes before, you know what DIY actually looks like in practice. We wrote a detailed breakdown of the challenges and a direct comparison of DIY vs Chainstack Self-Hosted if you want to go deeper — but here’s the short version: DIYChainstack Self-HostedDeploymentManual setup and scriptingOne-click, minutes to hoursFailure recoveryManual intervention or custom toolingSelf-Healing and automatic recoveryFailoverCustom implementation per setupConfigurable out of the boxUpdatesManual upgrades and coordinationAutomated update workflowsMonitoringSelf-built monitoring stackIntegrated monitoring and alertsTime to productionDays to weeksMinutes to hours What you get One-click deployment across all major protocols: Select your protocol, network, and node type — and you’re live in minutes. Right-sized node configurations are applied automatically based on your hardware and protocol requirements, so you’re not guessing at specs. Snapshots reduce initial sync time significantly, cutting what used to take days down to hours. Self-Healing and auto-updates: Nodes monitor themselves and recover automatically from failures. When client updates are available, you get notified and control when they’re applied — no manual coordination, no maintenance windows that turn into incidents. Zero downtime failover: Configure failover to a secondary node, a Chainstack high-performance RPC endpoint, or any endpoint you specify. Your applications stay online even when a node goes through an update or unexpected failure. Monitoring, alerts, and observability: Real-time insights into node performance, alerts for important events, and the data you need to understand what’s happening across your infrastructure — without building a monitoring stack from scratch. Your data stays yours: Nodes run in secure, isolated environments with encryption and strict access controls. Nothing leaves your infrastructure. Chainstack Self-Hosted is built for teams where data sovereignty isn’t optional. Who it’s for Chainstack Self-Hosted is built for teams and individual developers who need the operational maturity of a managed service without giving up control of their infrastructure. That includes enterprises with compliance and data residency requirements, teams that need to own their node stack, traders that need guaranteed RPC access without rate limits, and developers that are tired of spending cycles on node maintenance instead of product development. If you’ve been putting off self-hosting because of the operational overhead — or if you’re already self-hosting and spending too much time keeping things running — this is built for you. Get started Chainstack Self-Hosted is available now. Check out the documentation to get started, or jump straight into the quick start guide. Explore Chainstack Self-Hosted → Further reading Self-hosted blockchain node: challenges and solutions Self-hosted blockchain node: DIY vs Chainstack Self-Hosted How to run a self-hosted blockchain node on HOSTKEY Top 5 node software options to deploy an Ethereum node in 2026 #### 2X the difference: Why the right node deployment matters Blockchain technology has dramatically transformed different sectors, introducing a new level of transparency, security, and efficiency in processing transactions and data management. At the core of these advances is the critical function of nodes, which serve the vital role of maintaining, verifying, and enhancing blockchain networks. More specifically, Ethereum archive nodes constitute a central element in Ethereum’s blockchain network. These heavyweight nodes provide the most comprehensive data access, storing the full history of transactions and allowing for a full reconstruction of the network’s state at any time. Whether for research, data analysis, block exploration, or even running a DApp, Ethereum archive nodes prove essential. However, the process of running an Ethereum archive node on-premise can appear daunting, especially when it comes to understanding cost implications. Concerns range from deciding on the hardware configuration to account for utility expenses and hiring qualified engineers to manage the system. We aim to unravel this complexity by carefully cataloging individual cost elements and providing an overview of various cost scenarios, which could help blockchain enthusiasts, potential node operators, and decision-makers. In the forthcoming sections, we explore the infrastructure requirements for operating an Ethereum archive node, actual operating costs including human resource expenses, and how these costs come together and compound in different scenarios—from operating a single, unstaffed node to running a dozen nodes with a full team of engineers. Running an Ethereum archive node Ethereum archive nodes on-premise run with a combination of robust hardware, persistent utility, and intense human resources. This explanation sheds light on the associated costs, dissecting each cost element to provide a comprehensive understanding of what goes into managing such a complex operation. Minimum hardware requirements Discussing the infrastructure, the first significant outlay, reveals how critical the setup is. The infrastructure directly affects the performance and reliability of the Ethereum archive node. The hardware configuration that we’ll examine in this context forms the minimum requirements for running an Ethereum archive node. It involves managing harmoniously an 8-core CPU, a 32GB RAM, along with a Hard Disk Drive (HDD) boasting a capacity of more than 3.5TB, although 4TB is the preferred capacity. For improved performance, Solid State Drives (SSDs) are recommended. SpecificationRequirementCPU8-coreRAM32GBStorage3.5TB+ HDD (SSD recommended)Figure 1: Ethereum archive node minimum hardware requirements; Source: Chainstack / Chainstats Building a sample server configuration To put these requirements into perspective, let’s consider an example: a sample server rig configuration. Essentially, it is a single server rig that incorporates a double 3.00Ghz E5-2623v3 quad-core CPU, ending up with a total of 8 cores, and an aggregation of quadruple 16GB PC4-2133P RAM, consequently totaling 64GB RAM. Further, it entails a 6.4TB SSD with eight incorporated 800GB SSD SAS 2.5” drives. This example adheres to the minimum hardware criteria for running an Ethereum archive node on-premises, forming the foundation for the subsequent cost calculations and estimates. You can anticipate the cost of such a fitting server rig at approximately $1,600 for a refurbished model and within the range of $2,000-$2,500 for a new model, although the rates can vary in real-time based on the market dynamics. SpecificationDetailCPU8-core (2x 3.00Ghz E5-2623v3 4x Core CPUs)RAM64GB (4x 16GB PC4-2133P RAM)Storage6.4TB (8x 800GB SSD SAS 2.5”)Cooling7x 80mm fansPrice (refurbished)$1,600Price (new)$2,000 to $2,500Price (article case)$2,200Figure 2: Sample hardware configuration and pricing for running an Ethereum archive node Counting the utility costs Next, there are the often-overlooked utility costs. Running Ethereum archive nodes necessitates significant utility resources. For instance, electricity is a recurring expense. With the average U.S. kWh price hovering around $0.16, the cost implication for powering the nodes is approximately $330 per year. Moreover, considering the indispensable need for a reliable internet connection, a Gigabit Internet plan, estimated at $80 per month, is advisable. ItemCost (1 unit)Cost (12 units)Hardware$2,200$26,400Electricity$28 / month$330 / monthInternet (Gigabit connection)$80 / month$80 / monthFigure 3: Hardware and utilities costs for running the sample Ethereum archive node server rig Taking in the human factor Lastly, you can’t underestimate the role of human capital. Industrial-scale operations need a team of specialists for smooth operation, maintenance, and prompt resolution of node anomalies. At ideal strength, such a team could handle 12-15 nodes around the clock. Usual roles and compensations include a Senior Cloud Engineer who earns around $190K per year or $16K per month, a Mid-level Cloud Engineer with a yearly take of $120K or $10K monthly, and two Junior Cloud Engineers raking in an annual $68K each, summing to about $6K each monthly, resulting in a $12K monthly total for the two. PositionSalary (p.m.)Salary (p.a.)Senior cloud engineer$16,000$192,000Mid cloud engineer$10,000$120,000Junior cloud engineer (x2)$12,000$144,000Figure 4: Human capital costs for running 1-12 Ethereum archive nodes; Source: ComputerCareers This broad interpretation of costs, alongside the selected server configuration, lays a valuable groundwork for individuals, groups, or companies looking to invest in Ethereum node infrastructure and seeking a better understanding of the financial commitment required. Exploring possible short-term scenarios To provide a deeper understanding of costs, let’s explore different scenarios of utilizing Ethereum node infrastructure. The variations in these scenarios lie in the degree of staffing and the node capacity. At the same time, they are all based on the example server rig setup that we defined earlier, as well as the utility costs involved in powering it. As the scenarios unfold, we’ll be factoring in additional manpower-related costs little by little for a more granular look and explore ‘hacky’ approaches too. Scenario 1: No humans involved Firstly, let’s start with a scenario that excludes the biggest spend for any organization—staff payroll. We will be taking into consideration only costs associated with hardware acquisition and utilities. In doing so, we can extend this estimate to other regions of the world, considering it will not be tied to the salaries of US workers. In its minimum capacity, running a single node, you’ll incur a one-time cost of $2,200 for the hardware purchase. Of course, utility expenses aren’t a one-off, and you’d be setting aside $108 per month—$28 for electricity and $80 for internet services, bringing the total upfront cost to $2,200 while the monthly recurring costs stand at $108. Now, if you opt to maximize the capacity by running 12 nodes, the one-time cost for hardware installation escalates to $26,400. Monthly utility costs would now amount to $416, a sum of $336 meant for electricity and the previously mentioned $80 for internet connection. Thus, the total upfront cost equals $26,400, while the monthly recurring costs rise proportionately to $416. Scenario 2: Bare minimum staff Here, we will explore a scenario that does include some payroll costs but in their absolute minimum. This means that when it comes to staff, there will be a single employee taking care of the entire deployment (don’t ask how!), so to make things balanced, we will consider them a senior. For minimum capacity or a single node, the expenses largely remain the same as the unstaffed option at $2,200 for the one-time rig purchase and $108 monthly utility cost. However, you’ll now need to factor in staff costs and allocate $16,000 per month for a senior engineer. Again, the total upfront cost is capped at $2,200, but the monthly recurring expenses have significantly increased to $16,108 due to the added expenses of human capital. Maximizing to 12 nodes, the one-time purchase cost for the rigs reaches $26,400. Monthly utility bills rise to $416, and, considering the senior engineer’s presence, $16,000 monthly staff cost is sustained. This brings your total upfront purchase to $26,400, but the monthly recurring costs sit higher at $16,416. Scenario 3: Fully staffed deployment Finally, let’s consider a more realistic scenario, where the entire operation is staffed accordingly. In this alternative, the whole team is involved with a senior, an intermediate, and two junior cloud engineers. This allows for a 24/7 weekly covered, while still letting employees take their time to rest, after working a typical 40-hour work week. No weekend slacking though! Running at minimum capacity, the single node will set you back $2,200 as a one-time cost for the rig. The usual $108 utility bill is accompanied by a much larger monthly staff cost of $38,000 to pay the complete team, making the total upfront cost $2,200 and the monthly recurring costs rising up to $38,108. In its maximum capacity of 12 nodes, the initial cost required for rig installation sits at $26,400. Once the utilities are accounted for ($416 per month), along with the monthly wage bill ($38,000), the total upfront cost stands at $26,400. In contrast, the monthly recurring costs have escalated to a substantial $38,416. This thorough examination of costs under different circumstances hammers home the importance of staff and the scale of Ethereum node infrastructure in cost implications. Furthermore, it drives the point that, while upfront investments may appear quite steep in every scenario, operating expenses can significantly add to the ongoing cost, especially when considering human resources. Expanding to a five-year timeframe Understanding the cost implications over a longer period forms an important part of any investment plan. For instance, envisioning these expenditures over a span of five years, a typical hardware lifecycle, allows the possibility of more informed decision-making. This consideration becomes even more critical given the potentially significant outlays, especially those related to staffing a full team. Let’s narrate how these costs compile for different scenarios over a five-year lifecycle. Scenario 1: Infrastructure-only Going back to the outline of our previous first scenario, which estimates the costs for an operation that involves zero human capital. This time, however things will be a bit more different, considering a longer time-frame that eliminates the potential bias, caused by the initial hardware purchase costs having higher impact on the short-term bottom-line. At the minimum capacity, running a single node incurs an upfront cost of $2,200 (one-time hardware cost). Facility-related expenses will pile up over the five years to around $6,480. Hence, the operation cost circles around a total of $2,200 upfront and $6,480 spread over five years. Maximizing to 12 nodes, the upfront cost winds up at $26,400, which covers the hardware for all nodes. Having these 12 nodes demands a facility cost of $24,960 over the subsequent five years. The total investment, therefore, rises to an upfront payment of $26,400 and $24,960 spanning the five years. Scenario 2: The one-man army Next, we return to the single-employee scenario #2, detailing projections for an operation, manned by a single senior engineer, regardless of how cruel that may sound if it was real. Once again, to keep things relatively realistic still, the engineer would be a senior. For a single node operation, the upfront cost for the rig remains at $2,200. The five-year facility expense is equivalent to the previous scenario—$6,480. However, you must acknowledge the considerable staff costs over these five years, amassing to a massive $960,000. The total investment spikes to an upfront expenditure of $2,200 and an enormous 5-year expense of $966,480. Let’s stretch these specifications to fit a 12-node setup. The upfront cost for the rigs equals $26,400. Facility expenses rise to $24,960, while staff costs hold at $960,000. Thus, the total of your investment for this five-year period would be an upfront cost of $26,400 and an impressive total 5-year expenditure of $968,680. Scenario 3: Full-blown operation Finally, we circle back to examine scenario 3, expecting a fully staffed node operation. Like before, the roster here is composed of a balanced set of four team members with a single senior and mid, as well as the two junior engineers supporting them in the process. With minimum capacity, that is, a single node, the upfront cost ticks all the same boxes—the rig costing $2,200. While the facility expenses over five years add up to $6,480, staffing costs—with the full team on board—escalate to $2,280,000. Your final calculation results in a total upfront cost of $2,200, coupled with a monumental 5-year expense of $2,288,680. When you opt for maximum capacity, catering to 12 nodes, the upfront cost for the rigs counts to $26,400. The five-year facility costs total $24,960. However, the five-year staff cost remains static at a grand $2,280,000. The total cost to keep in mind, therefore, is an upfront investment of $26,400 and a significant sum of $2,331,360 over five years. TimeframeNo staffMin staffedFully staffedMonthly (1 node)$2,308$18,308$40,308Monthly (12 nodes)$26,816$42,816$64,816Yearly (1 node)$3,496$195,496$459,496Yearly (12 nodes)$31,392$223,392$487,3925-year (1 node)$8,680$968,680$2,288,6805-year (12 nodes)$51,360$1,011,360$2,331,360Figure 5: Sample scenarios costs breakdown These long-term estimations under various circumstances highlights the potentially significant impact of human resources on the cost side of the ledger over the long haul. While upfront investments might echo previous expenditures, the long-term perspectives, especially factoring in staff wages, can mound to considerable heights. Hence, planning for the long term is crucial. Putting costs into perspective Running an Ethereum archive node is an indispensable activity for many businesses, especially those heavily relying on blockchain technology. However, the costs associated with operating these nodes independently, both upfront and over time, can demand significant resources. In addition to the substantial financial commitments, businesses are also subject to the additional burdens related to infrastructure setup, ongoing maintenance, and human capital management. In comparing costs of making such an investment independently, it is vital to also explore the topic from the angle of utilizing a Node-as-a-Service (NaaS) platforms like our very own at Chainstack. In doing so, you, as a reader can get a much more balanced perspective into what each option brings to the table and what it asks for in return. That is why, in the following sections, we will be looking into the Chainstack subscription plans that allow for node deployment that fits our criteria so far and then compare costs accordingly. The two plans in question are the Growth and Business plans, which give you the ability to deploy Ethereum archive nodes without the overhead of managing a full in-house infrastructure. Why choose a Nodes-as-a-Service provider? Naturally, the provisions that each subscription plan offers empower Chainstack users to run Ethereum archive nodes. At the same time, however they do keep the burden of infrastructure management and human resource expenses that come with operating these nodes independently off the user’s shoulders. Less energy and resources spent on side tasks, means more pooling toward core factors and most importantly toward BUIDLing a product for your clients to fall in love with. In essence, much of the value derived from Chainstack’s pricing plans arises from eliminating the direct cost elements inherent in managing an Ethereum archive node independently. Not only is there a potential reduction in costs, but users can also reap significant benefits and flexibility from indenting the costs to flexible monthly payments based on the scale of usage. What’s in the box for each plan? The Growth plan, tailored towards accommodating lesser capacity requirements, is priced at a modest $49 per month. This cost includes 20 million request units that come as part of the package. With this level of service, customers get additional perks. They enjoy access to regional elastic archive nodes, a provision for dedicated nodes, and they can deploy up to 10 nodes and 10 subgraphs. If the level of usage scales beyond the included request units, an extra cost will apply, amounting to $15 per one million additional request units. Priced at $499 per month, the Business plan features expanded capabilities for subscribers, allowing for a whopping 140 million request units. Beyond the comprehensive offerings in the Growth plan, this tier accommodates even more nodes and subgraphs, allowing users to deploy up to 20 apiece. PlanCost p.mCost p.a.Cost p.m. (-16%)Cost p.a. (-16%)Growth plan$49$588$40$480Business plan$499$4,188$290$3,480Figure 6: Chainstack Growth and Business plans costs breakdown; Source: Chainstack In the event of usage exceeding the bundled request units, the extra cost for this plan is lowered to $10 per one million additional request units. Chainstack vs the staffless scenario Let’s dissect the cost comparisons for varying durations, starting with a zero-staff deployment scenario operating at its maximum capacity. Independently managing this operation would levy an upfront cost of $26,400 for the infrastructure. Additionally, over a five-year timeline, utility expenses would accumulate to $24,960, bringing the total investment to $51,360. Growth plan comparison In stark contrast, consider the Chainstack Growth plan. The quoted pricing is $49 per month, which totals to $2,940 when distributed across 60 months, or five years. However, our platform facilitates an annual payment scheme, offering a 16% discount, reducing the yearly cost to approximately $480 and summing to a total of $2,400 over five years. The prospect of user savings is even more significant. With the Growth plan’s monthly or discounted annual payment scheme, savings amount to an impressive 94% to 95% for 12 nodes, or 64% to 73% for a single one, slashing the total cost you would have incurred running an Ethereum archive node independently. Business plan comparison Now, draw your attention to the Business plan, quoted at $499 per month or $20,940 over the five-year span. The same 16% discount applies for annual payments, reducing the yearly cost to approximately $3,480, yielding a total five-year cost of $17,400. The Business plan enhances these savings further. Whether opting for the monthly or discounted annual payment, you could save around 59% to 67% of the costs related to independently running an Ethereum archive node, or 12 respectively. Beyond the five-year horizon, these disparities become evident on the monthly and annual scales as well. Operating independently, while feasible, could usher in recurring costs, including utilities and potential maintenance or upgrade fees. In contrast, the Chainstack Growth or Business plans distribute these costs evenly on a monthly or annual basis, adhering to a predictable fee structure and eliminating hidden or unexpected costs. Chainstack vs the bare minimum scenario Let’s now have a look at one-man-band scenario where there’s a single senior engineer maintaining your Ethereum archive node at its maximum capacity. This setup inherently complicates the task at hand and necessitates a significant investment. The upfront cost for the infrastructure is $26,400. Factoring in the steady monthly wage of the senior engineer, over five years, staffing cost amasses a hefty $960,000. Joining up these expenses with the five-year facility cost of $24,960, the total expenditure culminates in a striking $1,011,360. When you draw these comparisons crystallizing the cost savings, the percentages are as astounding as the raw figures. Against the independent one-man-band operation, the Chainstack offerings of the Growth and Business plans confer savings peaking to nearly 98-99%. This pattern holds on narrower timescales too, with similar savings being observable whether we look at monthly or yearly comparisons. Chainstack vs the optimally-staffed scenario Investing in Ethereum archive nodes incurs considerable costs that are further amplified over extended periods, whether monthly, annually, or over a typical hardware lifecycle of five years. That is especially the case, when considering the scenario, involving the entire team of four engineers. In this particular case, running this setup independently at its maximum capacity would require an upfront expenditure of $26,400, and over five years, the total costs add up to a mind-boggling $2,331,360, meaning you would be investing over $2.35M. Comparing the Chainstack plans to the independent operation costs, it’s clear that the savings are quite phenomenal. With the Growth or Business plan, the costs drop by almost 99.9%, nearly covering the full outlay. Wrapping up the cost comparisons These comparisons truly underline the enormous value that we deliver through the Chainstack platform. Besides spreading costs over manageable monthly or annual payments, you also eliminate significant upfront expenses, reduce ongoing costs dramatically, and enjoy the convenience and efficiency of the Chainstack platform. And with the assurance of these reduced costs, businesses can better channel resources into their core operations, reaping the benefits of running Ethereum archive nodes without incurring the hefty costs that would have otherwise been necessary. Besides the absolute figures, we should consider the convenience and effectiveness of Chainstack’s plans. The Growth and Business plans seamlessly accommodate needs scaling from 10 to 20 nodes. With automatic infrastructure and personnel-related burdens offloaded, users experience a smooth, scalable cost approach aligning with actual needs instead of dealing with costly upfront investments and substantial ongoing costs. Overall, these patterns demonstrate the vast differences between the costs of independently running Ethereum nodes versus leveraging the services of a platform like Chainstack, with savings ranging from 59% to almost total relief. TimeframeNo staffMin staffedFully staffedMonthly (1 node)$2,308$18,308$40,308Monthly (12 nodes)$26,816$42,816$64,816Growth monthly (1 node)$40-$49$40-$49$40-$49Growth monthly (12 nodes)N/AN/AN/AGrowth monthly savings (1 node)97.88%-98.26%99.73%-99.78%99.87%-99.90%Growth monthly savings (12 nodes)N/AN/AN/ABusiness monthly (1 node)$290-349$290-349$290-349Business monthly (12 nodes)$290-349$290-349$290-349Business monthly savings (1 node)84.87%-87.44%98.09%-98.41%99.13%-99.28%Business monthly savings (12 nodes)98.69%-98.91%99.18%-99.32%99.46%-99.55%Yearly (1 node)$3,496$195,496$459,496Yearly (12 nodes)$31,392$223,392$487,392Growth yearly (1 node)$480-$588$480-$588$480-$588Growth yearly (12 nodes)N/AN/AN/AGrowth yearly savings (1 node)83.18%-86.27%99.69%-99.75%99.87%-99.90%Growth yearly savings (12 nodes)N/AN/AN/ABusiness yearly (1 node)$3,480-$4,188$3,480-$4,188$3,480-$4,188Business yearly (12 nodes)$3,480-$4,188$3,480-$4,188$3,480-$4,188Business yearly savings (1 node)-19.79%-0.49%97.85%-98.21%99.08%-99.28%Business yearly savings (12 nodes)86.65%-88.91%98.12%-98.44%99.14%-99.28%5-year (1 node)$8,680$968,680$2,288,6805-year (12 nodes)$51,360$1,011,360$2,331,360Growth 5-year (1 node)$2,400-$2,940$2,400-$2,940$2,400-$2,940Growth 5-year (12 nodes)N/AN/AN/AGrowth 5-year savings (1 node)66.12%-72.35%99.69%-99.75%99.87%-99.90%Growth 5-year savings (12 nodes)N/AN/AN/ABusiness 5-year (1 node)$1,450-$1,745$1,450-$1,745$1,450-$1,745Business 5-year (12 nodes)$17,400-$20,940$17,400-$20,940$17,400-$20,940Business 5-year savings (1 node)79.89%-83.29%99.82%-98.85%99.92%-99.93%Business 5-year savings (12 nodes)59.22%-66.12%97.92%-98.27%99.10%-99.25%Figure 7: On-premise vs Chainstack Growth and Business plans node deployment costs full breakdown Beyond cost considerations, enterprises also benefit from the flexibility, scalability, and convenience delivered by Chainstack’s infrastructure, making it an attractive proposition for a wide range of users. And when it comes to going cross-chain, with Chainstack, handling multiple blockchains is a breeze. You can set up nodes on over 20 blockchains, without fussing over new equipment for each one like Arbitrum or Solana. No big upfront costs, no ongoing hassles. Think of us as your easy button for all things blockchain. Comparison highlights Infrastructure: The initial setting up of an Ethereum archive node requires specific hardware criteria, with an example setup potentially costing between $1,600 (refurbished model) to $2,500 (new model) per node. A median value for a new rig of $2,200 was selected for the case. Utilities: Running Ethereum archive nodes require substantial utility resources such as electricity and internet, with costs estimated to be $28 per year for electricity and $80 per month for internet. Human capital: The inclusion of human resources, varying from one senior engineer to a full team, escalates costs significantly with engineer wages ranging between $16,000 and $38,000 per month. Long-term estimates: The total cost of operating a node, when projected over a typical hardware lifecycle of five years, can range from a few thousand to over $2M, heavily dependent on the node capacity and the degree of staffing. Chainstack plans: Our platform offers Growth and Business plans that are significantly more affordable than running an Ethereum archive node independently. These plans range from $49/month to $499/month and provide a significant number of request units and other perks. Percentage savings: Using Chainstack to deploy the nodes over operating an Ethereum archive node independently can offer savings between 59% and 99.9% over a 5-year span, depending on the scenario—unstaffed, minimally staffed, or fully staffed for single or a dozen nodes. Chainstack efficiency: Beyond the significant cost savings, Chainstack offers convenience and scalability, allowing users to adjust their costs according to actual need and eliminating the burden of dealing with infrastructure and personnel management. Bringing it all together Running an Ethereum archive node on-premise requires a significant financial commitment spanning hardware, utility costs, and human capital. From our calculations, it’s evident that staffing forms the lion’s share of costs, especially when functioning at full capacity. Therefore, decision-makers must thoroughly consider these financial implications to evolve sustainable strategies to run Ethereum archive nodes. Still, the potential returns, depending on your blockchain application’s success and scale, could be well worth it. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### 5 essential factors for setting up RPC node endpoints Setting up a reliable RPC node endpoint determines whether your Web3 applications perform well or fail under pressure. Whether you’re developing trading bots, Web3 wallets, or blockchain analytics tools, RPC nodes can make or break application performance and user experience. Chainstack offers managed solutions for top RPC providers, but the difference between a stable RPC setup and one that crashes comes down to five implementation factors. These factors cover everything from node access rules to performance settings. Getting them right helps you configure node endpoints that work when you need them to. Rate limits and access rules Probably the most essential thing to consider when setting up an RPC node infrastructure is how to prevent abuse by shaping traffic flow and ensuring fair resource allocation among all users. Without proper control over request volume, your node endpoint will be inundated with too many requests, and performance may decline severely or even stop altogether. Key implementation strategies Rate limits per IP: Cuts down on the resource usage of some IP addresses so that no single user can dominate all your resources. Limits unique to methods: RPC methods are not all equally complex and require varying amounts of computing power. Set thresholds on operations of maximum cost, for example eth_getLogs or eth_trace_ *. Tolerated increases, short packet lengths: Configure burst limits to handle legitimate traffic that causes momentary increases in traffic volumes, while maintaining overall traffic stability. Switch the setting in Billing -> Settings section (Pay-As-You-Go budgeting). Whether you can do so depends on whether this feature is enabled or disabled by default in your pay-as-you-go account from the Chainstack Console. Handling gracefully: Align the queue systems with processes such as backoff and other means to gently shift people, rather than pushing them away forcefully. It’s worth considering whether tools such as Nginx with rate-limiting modules in place or an API gateway that can handle various rate-limiting scenarios will fit your circumstances. Security measures Production environments need rate limiters at multiple levels: network, application, and database. Most major RPC providers already have advanced rate-limiting built in, which gives you a good baseline to work from. Security problems with RPC endpoints happen more than people think. A compromised RPC node can cause service outages, data breaches, and financial losses. Essential security measures to keep an eye out for: Authentication and authorization: Use API keys, JWTs, or similar methods to control access to your endpoints. IP and origin restrictions: In the Chainstack Console, go to the Security tab in your node details to set up IP address or domain restrictions. This limits which sources can hit your endpoints. Method whitelisting: Make sure to only enable the RPC methods your application needs. Turn off administrative or potentially dangerous functions. HTTPS/TLS encryption: Use encrypted connections to protect data in transit. Having regular security audits and hacked Pentesting should be part of your routine maintenance. On top, consider setting up Web Application Firewall (WAF) rules specifically for blockchain RPC endpoints to filter out malicious requests. Performance optimization and caching RPC performance directly links to application responsiveness and user satisfaction. Implementing effective caching mechanisms and operational optimizations typically reduces latency significantly while increasing transaction throughput. Optimization techniques to consider: Cache hits for CRUD operations: Build your cache around data unique identifiers to store the most frequently requested information. This works for both large and small requests across multiple instances. Connection pooling: Lower the overhead of creating new connections with connection pooling. Load balancing: Distribute requests across node instances so that the chances of a bottleneck are greatly reduced. For example, Chainstack Global Node features a globally balanced infrastructure, which automatically selects the closest instance to handle your request. Database indexing: Proper indexing of data from the blockchain can be a big help for query performance. Fetch the archive node for looking at historical data, and use Chainstack Subgraph for quick access where the info you want is indexed. Compression: Enable response compression to cut bandwidth usage and speed up responses. Multi-tier caching with Redis or Memcached for hot data and separate archival storage works well here. Monitor cache hit ratios and adjust TTL values based on your specific access patterns. Monitoring and observability RPC services break in production. Monitoring helps you catch issues before they become outages and people start complaining. What you need to monitor: Performance tracking: Response times, throughput, error rates, and server resources like CPU and memory usage. Blockchain specifics: Sync status, peer connections, chain reorgs. If your node falls behind or loses peers, requests start failing. Security monitoring: Set up alarms for strange user behavior patterns, failed authentication attempts, or abnormal levels of demand. System health: Monitor server memory usage, network connectivity, and database performance. You can also check the Chainstack Status page for service updates and maintenance schedules. SLA compliance: Track service availability, uptime, and performance against your defined service levels. Prometheus works well for metric collection, with Grafana handling visualization. For immediate alerts when things go wrong, integrate with Slack or PagerDuty. Distributed tracing gives you end-to-end visibility across your entire operation, so you can see exactly where requests are getting stuck or failing. High availability and disaster recovery The blockchain RPC infrastructure must be super-reliable. The value of many Blockchain applications will make downtime costly and will seriously affect user trust. Available strategies: Deploy nodes in multiple geographical locations. Chainstack Trader and Dedicated Nodes are examples of how to build redundancy into an application. Global Node handles geographic routing automatically if you prefer a simpler setup. Set up health checks that detect node failures and automatically route traffic to healthy instances. Configure automatic failover with minimal service interruption. Disaster recovery planning: Document your recovery procedures for different failure scenarios and test them regularly. Keep runbooks updated for common problems like node crashes or network issues. Verify your backups automatically to make sure they actually work when you need them. Consider managed blockchain services as backup infrastructure. Plan for different disaster types: hardware failures, network outages, or blockchain software bugs that mess up your data. Conclusion Getting your RPC node production ready means attending to these five crucial areas. Every step builds on the next until it forms an environment that is robust, secure, and high-performance, and can support large-scale Web3 applications. Whether you are creating your own RPC infrastructure or considering offerings from major RPC vendors such as Chainstack, remember that it’s essential to be attentive about maintaining it long after installation. Begin with these basic principles, but do not end here. As your applications grow and as requirements change, continue to refine and improve your RPC infrastructure. Investing in proper setup and maintenance will repay the time and effort costs with reliability for your users, as well as efficient operation. Further Reading Tips to handle RPC request errors: Ready-to-use code patterns for handling errors, retries, and provider switching. Unmasking DApp endpoint security: The Chainstack research results: Our analysis of 8,000 DApps shows which practices are putting projects at risk. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### 5 key takeaways from CordaCon 2020 Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. CordaCon 2020 has offered us all a great opportunity to bring in one place technology, advisory and financial partners. The R3 ecosystem is growing at such speed that it may be hard to keep track of all the newcomers and the emergent key players.  Before we look at the 5 key takeaways from CordaCon 2020, here’s a comprehensive map that will help you categorize the ecosystem’s participants, and get a clear overview of who’s who in this growing community.     CordaCon 2020 may be over, but the building continues. These are the 5 key takeaways from the event. 1. Cordite launches XDC, the first digital currency built on Corda The CordaCon 2020 ecosystem witnessed for the first time the launch of a digital currency built on Corda, the Cordite XDC. XDC is governed by Cordite Society Limited. Chainstack and Cordite Society have announced a partnership to make Cordite XDC nodes available to enterprises and innovators of any size through Chainstack’s turnkey blockchain managed services platform. Be among the first to try it.  Learn more in this comprehensive write up. 2. DAML for Corda makes waves  DAML smart contract language is a great step forward in enterprise interoperability and amazing addition to the Corda ecosystem. If you would like to try DAML for Corda, go to the Chainstack Marketplace and deploy it through our intuitive console. If you would like to get hands on with a tutorial on how to deploy the Chainstack ticket scalping app using DAML for Corda on Chainstack, follow this link to this DAML technical blog post. 3. The digital capital markets revolution starts with DASL DASL revolutionizes digital capital markets, as a single API to connect to a global network of financial services that provides robust, compliant, cost-effective infrastructure. CordaCon 2020 provided an opportunity to learn about the real examples of digital banks offering asset securitization services on the public Corda network using DASL. DASL is available to innovators and enterprises of any size through Chainstack’s turnkey blockchain managed services platform. Try DASL on Chainstack. 4. Realizing potential with Spunta Spunta remains the leading use case for the R3 ecosystem. Since October 2020, around 100 Italian banks have been operating on Spunta, the network of nodes built on Corda Enterprise and leveraging a cutting-edge technology that streamlines and automates the reconciliation of transactions. The new blockchain system will provide banks with complete visibility on daily settlements and advanced communication. Read more. 5. Hot topic: unlocking digital bonds liquidity on Corda Discussions around Digi-Assets, especially digital bonds, was at the center stage of CordaCon 2020’s first day. Panelists from banking and fintech companies talked about how blockchain innovation would impact the transfer and management of assets such as stocks, real estate, bonds, private securities, intellectual property, and much more. Placing real-world assets on the blockchain helps in reducing the cost of capital, which will be a key reason for the widespread adoption of technology. Watch video. A virtual conference that connects CordaCon 2020 was certainly a different experience this year, but no less insightful. It brought us closer to the community, giving us a chance to better understand the industry’s needs and fine-tune our offerings. We feel proud to be part of an ecosystem that aims at accelerating the adoption blockchain technology. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### 6 free tools to pick the top RPC node provider Every millisecond matters when your app is syncing blocks or querying smart contracts. RPC performance isn’t about the numbers on a pricing page, it’s about how those endpoints behave when your users need them most. Rather than choosing providers based on feature lists and pricing, six testing tools let you measure actual performance: throughput during network spikes, latency across regions, and how endpoints handle the specific mix of calls your application makes to Ethereum, Solana, Base, and other chains. Introduction Choosing an RPC node provider used to be as simple as checking price and pressing Deploy. Today, Web3 teams juggle RPC endpoints for better reliability and latency, route multi-region traffic, work with debug & trace APIs, and a dozen other moving parts. The good news is that you no longer have to make that call blind: 6 free and low-cost tools can measure the metrics that really matter and surface the provider that fits your workloads. “Which RPC provider is reliable enough for production?” and “Who is the top RPC node provider for Ethereum, Base, or Solana?”- these are perfectly reasonable questions, and price is only one piece of the equation. 1. Chainbench — open-source stress testing tool Most RPC providers display an impressive “No rate limits” or “Up to 10,000 RPS” badges, but raw throughput means nothing if a single wallet read takes 15 seconds during a gas spike. Chainbench solves this gap by replaying your traffic pattern: native on-chain interaction, RPC API calls, and deep archive reads against multiple endpoints in parallel. You set concurrency, method mix, and duration; Chainbench exports full latency histograms plus fail-rate heat maps, so you see precisely where a node throttles under pressure. Chainbench GitHub repository Why it matters: Synthetic tests that mimic your production mix highlight headroom issues long before they hit Mainnet users. Run Chainbench for 15 minutes, and you will know whether a million Requests/Credits/Compute Units is really enough for your application. 2. Provider status pages and SLA trackers Every serious RPC vendor now publishes a public uptime dashboard. Do not treat these pages as marketing fluff. Tools like BetterUptime and StatusPage.io expose historical incident data and mean-time-to-repair (MTTR). Check that pages and compare month-over-month performance. Patterns emerge quickly: some platforms recover from client crashes in minutes, while others require half a day. Pro tip: You can place each candidate’s RSS feed into a Slack channel called #rpc-incidents. After two weeks, the channel tells its own story. If one provider floods your feed with “degraded performance” alerts, cross it off. 3. Explorer-assisted block lag monitors Block explorers are more than UX candy. Create a free account at Chainstack or any other top RPC provider. By querying eth_getBlockNumber on EVM chains or getBlockHeight on Solana, then cross-checking the reported blockNumber height against the latest height on an explorer API, you can calculate block lag in real time. Wrap that logic in a simple cron script and you’ll know when an endpoint quietly falls 10 blocks behind the network. Of course, it depends on the chain and what app you are building: requirements for a trading bot, a wallet, or analytic dashboards are different. Check the code example at Chainstack Docs Tooling tip: Combine Etherscan (or equivalent) with Prometheus + Grafana to chart lag per region. The graph often reveals night-time maintenance windows that vendors never document. 4. OpenTelemetry collectors for end-to-end tracing Latency on chain calls rarely lives in isolation. Analytics Dashboard or Wallet UX also depends on your load balancer, CDN, and back-end. Deploy an OpenTelemetry collector inside your stack and instrument every outbound JSON-RPC call. You will capture queue_time, connect_time, and server_processing_time. When a signature broadcast feels slow, trace IDs jump across spans and point to the sluggish hop: sometimes it is the provider, sometimes your own proxy. Outcome: Armed with distributed traces, you negotiate SLA credits with data in hand instead of anecdotal “users say it is slow.” 5. RPC endpoint testing tool Use Chainstack Compare to benchmark how any two RPC endpoints stack up on real-world data-fetching workloads. A node that answers a single JSON-RPC call in 150 ms can still choke when you pull hundreds of blocks for an indexer or back-test. Chainstack Compare highlights the throughput ceiling, helping you choose endpoints (or plan horizontal scaling) before your production jobs fall behind the canonical chain height. Chainstack Compare — endpoint testing tool 6. Node comparison dashboards Community projects such as ethnode-stats aggregate p99 latency, failure rate, and regional round-trip delay for the top RPC providers: Chainstack, Alchemy, Infura, Ankr, QuickNode, and more. This dashboard continuously pings RPC endpoints from different locations. Use them for a neutral view of real-world experience, then validate results with your own Chainbench runs. Endpoint Compare Dashboard by Chainstack Watch for hidden value: Sometimes a provider ranks second on median latency but dominates on p99 tail, which is critical for trading bots and Web3 wallets, where the slowest call decides success. Final thoughts Developers once chose RPC nodes by googling “Best Ethereum RPC provider”. That era is gone. With enterprise-grade monitoring, open-source stress harnesses, and transparent pricing calculators, you can treat node selection like any other engineering decision: measure, compare, iterate. Try one or two of the tools above today. By the time your next feature ships, you will know which RPC partner can handle the flood of Mainnet RPC calls without melting your budget or your users’ patience. Further Reading How to secure your RPC endpoints with access rules: Step-by-step setup for filtering traffic by domain and IP address to block unauthorized access. Tips to handle RPC request errors: Learn how to catch, retry, and route around RPC request failures using native JavaScript patterns and ethers.js. 5 essential factors for setting up RPC node endpoints: Everything you need to know about rate limiting, caching, security, and disaster recovery for RPC nodes. Power-boost your project on Chainstack  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform.  Input your workload and see how affordable Chainstack is compared to other RPC providers.  Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Optimism, Avalanche, TON, Ronin, zkSync Era, Starknet, Scroll, Aptos, Fantom, Cronos, Gnosis Chain, Klaytn, Moonbeam, Celo, Aurora, Oasis Sapphire, Polygon zkEVM, Bitcoin and Harmony mainnet or testnets through an interface designed to help you get the job done.  To learn more about Chainstack, visit our  Developer Portal or join our Discord server and Telegram group.   Are you in need of testnet tokens? Request some from our faucets. Multi-chain faucet, Sepolia faucet, Holesky faucet, BNB faucet, zkSync faucet, Scroll faucet.  Have you already explored what you can achieve with Chainstack? Get started for free today.  #### 75% of retailers gearing up to accept crypto via payment gateways by 2024 In this ever-evolving digital era, we constantly encounter new technologies challenging our traditional systems, compelling us to adapt and innovate. One such innovation that has captured everyone’s attention is the rise of cryptocurrencies, democratizing how we perceive and handle money. As the cryptocurrency market continues to mature, providing mechanisms that facilitate everyday transactions using these new forms of currencies have become a growing necessity. It is within this scenario that crypto payment gateways have emerged. So, without further ado, let’s dig into the world of crypto payment gateways and explore their impact on the industry as a whole. But first let’s take a closer look at the market and specifically the merchants which these gateways would power. The retail shift towards cryptocurrency The paradigm of the retail industry is shifting at a rapid pace, driven by evolving consumer preferences and the profound technological advances that accompany the digital age. A recent survey by Deloitte in June revealed a significant move by retailers towards embracing cryptocurrency as a valid method of transaction. According to the report titled “Merchants getting ready for crypto,” an astonishing 75% of retailers are gearing up to accept cryptocurrency or stablecoin payments in the imminent two-year window. This not only signifies the growing legitimacy and acceptance of digital currencies but also demonstrates the industry’s agility in adapting to new-age payment methods. Deloitte’s comprehensive study polled 2,000 senior executives from a diverse range of retail subsectors. From cosmetics to electronics, fashion to transportation, and even food and beverage sectors, there appears to be a unified movement towards crypto integration. As consumers become more crypto-savvy, merchants are realizing the potential benefits such as reduced transaction fees, increased payment speeds, and access to a broader global market. The transition signifies not just an adoption of new payment forms but also a broader understanding and acknowledgment of where the future of commerce might be headed. What are crypto payment gateways? A crypto payment gateway is a platform that facilitates the transferring of cryptocurrencies and makes these transactions possible in daily life. While the conventional money transfer systems rely on regulated middlemen like banks or credit unions, crypto payment gateways stand as the facilitators for these payments to take place using cryptocurrencies. These platforms work in a way that they accept payments in the form of crypto tokens from the customer’s digital wallet and processes this payment to the seller. Typically, this is done by converting the tokens into a more conventional currency, saving the seller from the extra complexity of dealing with them directly. Figure 1: Crypto payment gateway vs. fiat payment gateway comparison; Source: CoinTelegraph How crypto payment gateways work? Crypto payment gateways essentially act as a bridge connecting cryptocurrencies with the conventional financial systems, offering a seamless and safe way to transact using crypto tokens. To better understand how crypto payment gateways facilitate transactions, consider the following sequence of actions: The transaction begins with the customer choosing to pay using a cryptocurrency token of their choice. On selecting this option, the crypto payment gateway generates a unique address for the transaction. This address, a unique string of alphanumeric characters, is connected to the transaction that is about to ensue. The customer then transfers the necessary sum of tokens to this address. Once the transaction is verified by the blockchain network, the crypto payment gateway converts the received tokens’ value into a more widely accepted currency like the US Dollar or Euro. This conversion happens almost instantaneously, shielding the seller from dealing with any cryptocurrency conversion. Finally, after the conversion, the amount is transferred to the seller’s account. Here, the seller receives the payment as they would with any conventional transaction. Figure 2: How does a crypto payment gateway work; Source: RevInfotech Crypto payment gateway advantages for merchants Cryptocurrencies and their payment gateways have rapidly gate-crashed the financial world, and for good reasons. These platforms provide merchants with several key advantages that give them an edge in today’s competitive marketplace: Global access: Crypto payment gateways erase geographical boundaries. Given the global accessibility of cryptocurrencies, any individual or business, irrespective of their location, can make transactions. This represents a vast, untapped customer base with whom merchants can engage without worrying about the limitations of traditional banking networks or the high costs of cross-border transactions. Lower transaction costs: Traditional financial systems and payment networks usually involve fees and intermediaries. Crypto payments, being peer-to-peer, cut out the middleman, resulting in reduced costs for both merchants and consumers. Further, crypto payment gateways generally offer lower transaction fees than standard credit card networks. Near-instantaneous transactions: Cryptocurrencies do not rely on standard banking hours. Crypto payment gateways can process transactions at any time, offering near-instantaneous transaction validation and settlement, a crucial advantage in today’s fast-paced e-commerce world. Enhanced security and privacy: Crypto payment gateways leverage the inherent security features of blockchain technology, such as encryption and decentralization, significantly mitigating the risk of fraud and hacking. Additionally, unlike traditional payment modes that require consumers to share sensitive personal and financial information, crypto payments can be made while preserving the user’s anonymity. Volatility mitigation: Though it’s true that cryptocurrencies can be subject to severe price volatility, many crypto payment gateways offer instant conversions, allowing merchants to accept crypto payments and instantly convert them to a stable fiat currency. This allows the benefits of accepting crypto without the risk of price fluctuation. In the world of e-commerce, adopting crypto payment gateways seems less like a novelty and more like a necessity. However, like all technologies, they too come with their share of challenges. Figure 3: Crypto payment gateway market overview; Source: MaximizeMarketResearch Disadvantages: The flip side of crypto payment gateways While crypto payment gateways undeniably come with a wealth of advantages, they are also accompanied by certain drawbacks that merchants should carefully consider: Dependency on a third party: Cryptocurrencies were initially designed to bypass intermediaries. In the case of payment gateways, the principle of decentralization is compromised to a certain extent as merchants have to trust and depend on the service provider. Service continuity risk: The provider’s ability to operate without interruptions is crucial as you might receive payments from different time zones, around the clock. Any disruption in service could potentially obstruct the merchant’s cash flow. Transaction fees: Even though you pay less than when using traditional payment methods, there is a small transaction fee you have to bear when using a crypto payment gateway. The risk of hacking: If your crypto payment gateway provider gets hacked, all the funds that you had in your account waiting to be transferred are at risk. Volatility risk: While most providers offer instant fiat conversion to mitigate this risk, the possibility of a drastic price fluctuations just before conversion can’t be entirely ruled out. Despite these potential drawbacks, the benefits of accepting cryptocurrency via a payment gateway often outweigh the possible risks, and this is a decision each merchant must make on a case-by-case basis. How does one go about selecting a suitable crypto payment gateway, and are they all the same? Figure 4: Key factors in choosing a blockchain payment gateway; Source: InfluencerMarketingHub Centralized vs decentralized crypto processing solutions Just as cryptocurrency was born out of a need for decentralization and autonomy from traditional financial institutions, so was the concept of decentralized crypto payment gateways. However, not all crypto payment gateways are created equal. There’s an important distinction between centralized and decentralized solutions; both come with their own sets of advantages and disadvantages: Centralized crypto processing solutions Centralized crypto payment gateways, much like traditional banking institutions, have a central authority such as a company or organization that oversees and governs transactions. They tend to be the more popular and well-known gateways, including offerings from Coinbase Commerce, Coinify, CoinGate, Circle, and Binance Pay Merchant. Advantages of centralized solutions include ease of use, customer support, and existing trust relationships. However, they are subject to censorship, service availability, and they require trust in the provider’s ability to secure its platform against threats. Decentralized crypto payment gateways Decentralized crypto payment gateways take peer-to-peer transactions a step further. They connect the buyer directly to the seller without passing through a third party or middleman. Transactional data is publicly available on the blockchain, providing complete transparency. Decentralized solutions such as Curra offer added security, privacy, and freedom, honoring the ethos of blockchain and its tenant of decentralization. They also lower the risk of service interruptions as they are not subject to decisions made by a central authority. It’s evident that both varieties have their place in the digital world, and the choice between centralized and decentralized hinges largely on the specific needs and philosophy of the user. Exploring centralized alternatives While decentralized crypto payment gateways offer numerous benefits, their centralized counterparts have their own unique advantages. These gateways are typically user-friendly and come with robust customer support. Some popular centralized crypto payment gateways in the market are: Coinbase Commerce: A popular choice among businesses, Coinbase Commerce allows a business to accept multiple cryptocurrencies including Bitcoin, Ethereum, Litecoin, and others. It offers an easy integration with major e-commerce platforms and a simple interface to manage transactions. Coinify: This gateway allows businesses to accept Bitcoin and more than a dozen other cryptocurrencies in exchange for a small transaction fee. Merchants can receive payouts in their preferred local currency, mitigating volatility risks. CoinGate: Apart from standard features like integration with multiple e-commerce platforms and support for a wide range of crypto coins, CoinGate stands out with its ‘Trader’ feature, a tool for merchants to accept crypto at physical stores using a dedicated DApp. Circle: A payment gateway with an emphasis on stablecoin transactions, Circle is perfect for merchants seeking the advantages of accepting cryptocurrencies without dealing with their price volatility. Binance Pay Merchant: From one of the world’s biggest cryptocurrency exchanges comes this versatile payment gateway. It offers a host of features, including the ability to convert cryptocurrency to fiat in real time. While these centralized solutions offer convenience and ease of use, there are decentralized counterparts that offer a more aligned vision with the essence of blockchain. Who’s who in decentralized crypto payment gateways In stark contrast to their centralized counterparts, decentralized crypto payment gateways exemplify the ethos of blockchain—decentralization, peer-to-peer transactions, and elimination of intermediaries. Here’s a look at some of the key players in the decentralized crypto gateway domain: Curra: As previously introduced, Curra is a prominent player in the decentralized crypto gateway market. Offering a seamless, secure transactional experience, Curra differentiates itself with its trustless, peer-to-peer nature. Curra provides an elegant, user-friendly solution for businesses looking to accept crypto payments but wanting to maintain the decentralized spirit of cryptocurrencies. NOWPayments: NOWPayments is another decentralized payment platform allowing its users to accept instant online cryptocurrency payments. The major standout of NOWPayments is the auto coin conversion feature, which rids users of the need to manage multiple wallets. CoinPayments: CoinPayments is a comprehensive platform offering shopping cart plugins, donation buttons, invoice creation capabilities, and an advanced Point of Sale (POS) system. It is well-regarded for its multi-cryptocurrency wallet, which adds a layer of convenience for the users. BTCPay Server: BTCPay Server is a self-hosted, open-source cryptocurrency payment processor designed with privacy and censorship-resistance at its core. It’s a tool that has a wide array of features, including direct peer-to-peer payments and complete control over your funds and information. CryptoWoo: CryptoWoo is a payment plugin that allows businesses to accept Bitcoin, Litecoin, and other cryptocurrencies directly into their wallets. It eliminates the need for a middleman and offers a high level of customization for the users. These platforms epitomize the principle of decentralization, catering to users who seek to retain full control of their transactions while reaping the benefits of blockchain technology. Making global payments easy In a globalized world where cross-border commerce is commonplace, efficient and frictionless payment methods are crucial. Traditional payment systems, while largely effective, can pose significant challenges in international trade: currency conversion costs, delayed processing times, and the need for local banking relationships, to name a few. Enter crypto payment gateways. By virtue of their inherent characteristics, these gateways offer a potent solution to streamline global payments: Breaking down borders: Cryptocurrencies, by their very nature, aren’t bound by geography. A customer from any part of the globe can smoothly transact with a merchant located elsewhere. Crypto payment gateways facilitate this transaction, thereby eliminating geographic barriers and handsomely expanding the customer base for merchants. Fast and efficient: Crypto transactions offer near-instantaneous processing, regardless of location. The hassles of time-zone differences or local banking hours are effectively sidestepped. Cost-effective: International transactions frequently involve significant costs related to currency conversion or transaction fees. Crypto payment gateways, by enabling peer-to-peer transactions, cut out these financial intermediaries and their attached costs. Overcoming regulatory hurdles: Certain countries have complex financial regulations that can deter global business. Crypto payment gateways can circumvent these regulatory hurdles, boosting the ease of international commerce. Crypto gateways like Curra, Coinify, and others are fast becoming the chosen route for businesses seeking to capture the global market. Reducing volatility risk Price volatility is a concern often attached to the world of cryptocurrencies. It’s not uncommon for Bitcoin or other cryptocurrencies to experience significant price changes within a short period. This volatility can be particularly concerning for merchants who could potentially see the value of their received payments change drastically. That’s where crypto payment gateways come in. These platforms, especially the centralized ones, offer what is known as automatic conversion. When a customer makes a payment in cryptocurrency, the payment gateway instantly converts the payment into the merchant’s preferred currency at the current exchange rate. This solution allows the merchant to receive the exact amount they expect with no risk of price fluctuation. Furthermore, many crypto payment gateways offer settlement services, where the cryptocurrency transactions are regularly converted to a chosen currency and transferred to the merchant’s bank account. Both these features substantially mitigate the volatility risk, making the adoption of crypto payment solutions a viable option in mainstream commerce. Even decentralized gateways are beginning to adopt these measures. Services like Curra are taking steps to neutralize the potential impact of volatility, ensuring that the merchants can comfortably accept cryptocurrencies. What happens if a crypto gateway is hacked? Cryptocurrencies have garnered a great deal of attention for their unparalleled security and transparency. However, like any technology, they are not entirely immune to hackers. If a crypto payment gateway is compromised, it could potentially result in the loss of the funds stored with the provider. However, it’s important to note that crypto payment gateways incorporate state-of-the-art security measures to safeguard against such threats. Triple layer SSL encryption, two-factor authentication (2FA), multi-signature wallets, and other robust protocols form an intricate security framework to protect against cyber threats. Moreover, many centralized payment gateways carry insurance to cover potential losses, adding another layer of protection for the merchants. In the case of decentralized gateways like Curra, the risk is substantially mitigated as transactions are handled directly between the buyer and seller. This infrastructure minimizes the number of attack vectors, drastically reducing the chances of a successful hack. In the unlikely event of a security breach, most platforms have detailed contingency plans that include prompt user notification, immediate shutdown of services to prevent further damage, and adequate measures to track and recover the stolen funds. In conclusion, while there is a risk factor involved, the state-of-art security measures adopted by crypto gateways and the corrective actions taken post a potential breach underlines the efficacy of these gateways and instills confidence among users. Bringing it all together Embracing crypto payment gateways means opening doors to the future of financial transactions. These indispensable tools offer unparalleled benefits – universal accessibility, lower transaction costs, instant transfers, supreme security, and more. While certain challenges need navigation, the advantages they bring to the table for merchants worldwide are undeniable. As more people embrace cryptocurrencies, the importance of these gateways continues to grow. Centralized and decentralized solutions each offer unique advantages that cater to varying needs. From ensuring swift international transactions to reducing volatility risk – the transformative potential of crypto payment gateways is immense. With platforms like Curra paving the way in the decentralized market, businesses now have a plethora of options at their fingertips. The future of e-commerce and remote transactions undoubtedly lies within the crypto realm. The journey into the world of crypto payment gateways is an enlightening one, presenting potential solutions that could ultimately shape the financial landscape. As we continue to navigate this exciting terrain, one thing is clear—crypto payments are not just a passing trend. They are here to stay, revolutionizing how we perceive and transact value. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### A closer look at NFT use cases: Why NFTs are more than just JPEGs? The rise of Web3 has seen the emergence of Non-Fungible Tokens (NFTs) as a crucial factor in the growing popularity of cryptocurrency and the shaping of a decentralized future in fields such as ownership, finance, and more. Despite claims that NFTs are mere “JPEGs,” the reality is that their potential extends beyond art or collectibles, tapping into our innate desire for social status and community connection. NFTs are the foundation of a new approach to interaction both in the virtual and physical realm. That is why in this article, you’ll be taking a closer look at some alternative NFT use cases than mere collectible art but first… What is an NFT? According to the Merriam-Webster dictionary, an NFT is “a unique digital identifier that cannot be copied, substituted, or subdivided, that is recorded in a blockchain, and that is used to certify authenticity and ownership (as of a specific digital asset and specific rights relating to it)” or “the asset that is represented by an NFT.” As you can see already, the definition is quite broad, leaving plenty of space for some “hmm…” moments in pinpointing exactly what can be deemed an NFT. Is it an artwork? A music piece perhaps? Or an ownership identifier? Let’s bust some of the most common misconceptions about NFTs. Busting NFT myths and misconceptions Are NFTs just pictures? Are NFTs JPEGS? Are NFTs just digital art? Yes and no. NFTs can hold any media, whether it is a static image (e.g. JP(E)G, PNG, or SVG), a dynamic visual (e.g. GIF, MP4, or MOV), or an audio file (e.g. MP3, WAV, FLAC). Are NFTs just links? Are NFTs just URLs? Not exactly. It is true that NFTs carry a link or URL to the media asset they hold (e.g. hosted on IPFS, Arweave, Filecoin, or a Web2 storage solution) but they can also store plenty more information than just that. Are NFTs just a fad? Are NFTs just money laundering? Absolutely not! As blockchain technology was once deemed a fad and a money laundering exercise, so has this stigma spread over to NFTs. Digital assets and collectibles in the form of NFTs are here to stay and we have seen many industry leaders to their own take on the vertical, as is the case with Coca Cola, Nike, or Louis Vuitton, among the now many. What are NFTs and how do they work really? But let’s take a moment to abstract away from the typical NFT definition and look at them from a more technical perspective. When you look at NFTs, as a code implementation, it is clear to see that they are essentially nothing more than just a metadata container. In layman’s terms, this means they are just a way to hold information, regardless of its type. Figure 1: The Non-Fungible Token (NFT) ecosystem; Source: TheBlock And by knowing this, the power to create exceptional Web3 experiences with advanced NFT use cases is now successfully in your hands. All it takes is an appropriate smart contract and a mint transaction to get started. So, let’s get creative—here’s a list of potential NFT implementations beyond the art factor: Digital music releases Event and venue ticketing systems Video game in-app assets Real estate ownership verifiers Decentralized identity identifiers How to drop fire digital releases and what are music NFTs? As mentioned previously, NFTs are nothing more than metadata containers, which makes them a perfect way for music artists to do digital releases. This makes them an incredible opportunity to release that hot new single, EP, LP, or LP, as a musician that your audience will love. And the best thing about it? You get to retain full control over the distribution and royalty systems at the same time. And considering just how stacked against you as an artist, the music industry really is, this is especially meaningful. There are plenty of middlemen you will need to pay along the way, whether it is for helping you distribute your work via digital and analogue media, or for tracking royalty payments for listener engagement on various platforms. And in the end, all you’re left with is a measly 12% share of the entire revenue stream (Bazinet, Jason B., et. al., 2018, 3). Figure 2: Music artist revenue share; Source: Bazinet, Jason B., et. al., 2018, 4 But all of this is essentially rendered useless and redundant once you hold all the keys to distribution and royalty management by opting for a digital-only NFT release. By opting for this approach, you will be calling all the shots on where and by who your musical piece is played at, while reaping all the royalty rewards for every successful resale. A great example of a music platform introducing NFTs to the production process is Audius. And when it comes to a complete digital release being launched, you’d be excited to discover that one of the top bands out there—the Kings of Leon, will be dropping their new album exactly this way. But wait… There’s more – EDM music artists 3lau and Clarian, as well as Linkin Park vocalist Mike Shinoda, have also done their part in pushing adoption of music NFTs forward. That being said, here’s what you’ll need for an adequate music NFT release: Cover Audio file Video link (optional) Lyrics (optional) Web2 reseller link (optional) Turning up the volume of music NFTs: Community BUIDLing Digital single, EP, LP, and LP releases are not the only great examples of using NFTs within the music industry, as community BUIDLing is just as an important factor for artists in this vertical. That is why, creators can leverage the power of an NFT, for example when setting up limited edition pieces, digital concerts or events, and fan clubs, among many other. Want to give out an exclusive music piece, a video, merchandise, or some exclusive album artwork to just your top fans? Well, now you can, should you opt for using NFTs in such fashion. And by giving them ownership over the assets, you are effectively setting up an alternative revenue stream because of it—thanks to the full control over the royalty system that you’d retain meanwhile. The same applies to digital concerts and events that will be covered in greater detail further into the article, as well as exclusive fan club access. Considering we are now living in a near-fully remote world, bands and artists can take advantage of the technology that NFTs use to host digital events. This means that fans would be able to use such pay-per-view kind of systems to gain access to such exclusive performances, and even fan clubs, as the hosts retain full control over the distribution and royalty processes. Beyond music communities: How NFTs play out in other industries? Much like in the music industry, artists in other verticals, as well as athletes in various sports, can take advantage of NFTs in order to develop their loyal community following. Let’s focus on sports players, since their category is a bit more of an edge-case than that of other digital artists. On one hand, athletes stand to benefit from the ability to release fan memorabilia, whether it is coming from them as a player, or from the team they play for. This means setting up an alternative revenue stream via resales of digital collectibles, like video highlight reels (e.g. your favourite team’s game-changing play in a particular match) that can be converted into priceless trading cards that can be just as valuable as a popular athlete’s rookie card, while giving you complete control over the royalty and distribution systems. On the other, this directly translates to increased engagement, also via fan ownership, in addition to creating an even more interacting and rewarding experience. This means that certain fans can be then rewarded for their high loyalty or given access to exclusive communities in the form of Decentralized Autonomous Organizations (DAOs), composed of dedicated fans just like them. What are ticket NFTs and how gather crowds with them? And speaking of happenings, what would live events really be without a fitting venue and the ticketing system that brings them all together under the hood. By opting for the use of NFTs in place of the traditional approach, projects can reap the benefits of a streamlined approach in several avenues—distribution, accountability, and full process ownership. When it comes to distribution, project owners can enjoy cheaper and faster transactions via bulk or batch processing, allowing multiple assets to be sent at once. This also comes with improved accountability, by means of a more reliable and immutable paper-trail on one hand, and removal of the middle-men for lesser impact of such factors to the bottom-line. But while this does sound a bit arcane for most, there are two simple ways you can approach this. On one hand, this can be done via a protected QR code or a unique ticket ID on the other. Regardless of your weapon of choice for this one, what an event or venue NFT ticket would do is to provide a unique identifier along with ownership information that would authenticate the holder. Such information can be made explicit by having it listed within the metadata of the ticket NFTs or implicit by using the holder address and/or transaction hash of the purchase. In the end, what you’ll get as an event or venue manager is again full control over the ticket distribution and royalty payments. And with less middlemen claiming their share along the way, this directly translates to a more transparent process with a larger portion of revenue pouring down towards your wallet. Figure 3: NFT tickets on sale on the YellowHeart marketplace Some great examples of projects taking the NFT route to improve their ticketing systems are the GUTS protocol, YellowHeart, and Relic Tickets. And in case you’re wondering already, this is what you’ll need for a successful event or venue ticketing system NFTs: Cover and ticket ID Visitor details (optional) OR QR code (protected) Visitor details (optional) NFT ticketing one step further: Travel agents and cruise lines We are yet to see a utility NFT being released under this category, but considering that three major cruise lines—Norwegian, Carnival, and Celebrity Cruises have launched their very own art collections already, this might be closer than expected. Overall, there are three main avenues of utility, which travel and cruise businesses can leverage in their operations—loyalty programs, identity, and security. Figure 4: Norwegian Prima Inaugural Sailing – September 2022 NFT; Source: Norwegian Cruise Line Of all three mentioned, loyalty programs stand out the most. By opting for the use of NFTs this way, travel and cruise operators can transparently and securely award their most loyal customers in a similar fashion to the way achievement badges work. A customer has generated 1K air miles? Send them an NFT and entitle them to the appropriate list of benefits, earned for this tier when they prove ownership at checkout. The other two avenues from the lists above can be used to support the loyalty program, or any other moving part of operations. For example, because NFT ownership is easily provable, soft identity verification during checkout, like loyalty program benefits can happen at just of a click of a button. And the same applies to security, where immutability and a robust paper-trail can benefit a more transparent and safe process for everyone involved. Dabbing into sport events with ticket NFTs Arts and travel events are from being the only type, where NFTs can play an important role in. Quite the contrary—sports can be just as valid as a prospect for them to flourish. Looking at this vertical, in particular, it is quite easy to discover that tickets for sporting events can be quite an interesting avenue for such implementation. The key benefits of this are two—on one hand, they’d give easier access to games and matches, while on the other, they reduce fraud. The former gives fans the ability to purchase tickets in a more convenient way by effectively skipping the long and tedious brick-and-mortar lines that are usually part of the process. Meanwhile, the latter brings an extra layer of security via both the immutability and the robust paper-trail factors. But this is far from being ticket-specific, as it also translated successfully to the fraud-free purchase of merchandise and memorabilia just as well. How’s that for a double whammy? Oh right, let’s also not forget about the other double whammy of retaining full control over the royalty and distribution process that will be mentioned excessively in this article. What are gaming NFTs or how to drive engagement with play-to-earn and in-game assets? Much like the music and events industry, the gaming one isn’t that far behind on being stacked against creators. That is true for both AAA and indie publishers but is so especially for the latter. But considering AAA publishers are quite rigid, in terms of distribution processes, you will see this section focusing more on smaller indie teams and their releases instead. An in-game asset NFT presents an incredible opportunity for game developers to promote further engagement in their communities through the ownership factor. Ever wanted to keep a digital record of you earning an epic item from a tough MMORPG boss beyond the game? Traditionally that wasn’t possible but with an in-game asset NFT it is now a reality. But ownership and better engagement are far from being the only benefits here. Should you set the in-game asset NFT system correctly, you can effectively create a brand-new way for players to monetize the time and effort they spend in-game. This is called a play-to-earn mechanism and is a great way to further solidify player interest in your game. Figure 5: Axie in-game asset NFT marketplace listing; Source: Bankless And how about taking your game to the next level with a fresh trading mechanic that could bind communities together even further? Thanks to NFTs, this is now possible, and you won’t even need to implement it within your game’s code—all it takes is setting up your in-game asset NFT smart contract, so an appropriate marketplace can take care of the rest. Some textbook examples of in-game asset NFTs in action are Axie Infinity and Gods Unchained. Here’s what you’ll need to set one up for your project accordingly: Cover In-game item ID In-game item properties (optional) What are real estate NFTs or how to tokenize real world assets and verify ownership? This, as well as the category coming after, are still somewhat of a grey area, considering the legal framework for their application is not as well-defined, as it needs to be to allow effective use at scale. Even so, this does not mean we cannot hypothesize on how to apply them, assuming such framework already exists. Should such a framework be implemented, property owners stand to benefit from a more transparent and streamlined process, which can minimize the countless pages of legal papers and consent to a single transaction signing. And let’s not miss out on mentioning the supporting revenue stream from the ownership of the property resales royalty process that sees to all parties receiving their fair share of profits—from owners and landlords to agencies and even the purchaser in the end. Despite the legal challenges mentioned above, there are some projects already setting out to help defined the framework and give us some great examples of how it all works in action. On one hand, a part of them focus on the less picky digital real estate aspect, as is the case with Decentraland, Upland, SuperWorld, and PolkaCity, for example. Figure 6: Digital real estate NFTs on OpenSea; Source: Switchere Meanwhile on the other, there are those that actually pave the way for the legal framework like fractional real estate ownership project Fraction, in addition to Propy, which takes a more traditional way to do just that. Regardless of the chosen modus operandi, in order to tokenize a real-world asset, like land, or an estate property, while effectively verifying its ownership you would need: Property cover (optional) Technical property information Ownership legal information What are decentralized identity NFTs, DIDs, SSIs, and VCs? Decentralized identity still remains one of the hotly debated topics in Web3 and naturally, there are plenty of takes on the issue because of it. Identity NFTs, Decentralized IDentities (DIDs), Self-Sovereign Identities (SSIs), and Verified Credentials (VCs) are all part of the same approach, albeit being more or less synonymous for each other. Much like the one before it, this category is also still much of a grey area, due to the lack of specific legal framework that would make it 100% valid. Even so, the decentralized identity space is not foreign to projects attempting to tackle it, with Civic Pass being one of the more successful examples. But our focus is on NFTs and Civic does not use this approach for identity verification, so let’s continue digging. One of the projects driving NFT adoption for this particular use case is CollectID, which has made steady waves across the entire landscape by signing up large players like Kappa, as well as various sports teams as is the case with FC Köln, Deportivo de La Coruña, and Bayer Leverkusen, among many. Some of the key benefits of using such approach to solving identity management challenges are giving ownership of user data in the hands of the user, as well as streamlining the verification process at various stages. And while the latter should already be apparent by now, the former represents a cool new way of tackling privacy issues, whether they arise from marketing, sales, or any department whatsoever. Here’s what you’d need to have to spin up your own take on the subject: Cover (optional) User ID Verification information (protected) Transcending human identity: Name services for domains and platforms There is another avenue for decentralized identities apart from that of humans already mentioned—naming services. And while this does sound quite vague for non-tech savvy readers, this can all be boiled down simply to domains and platform nameplates. The former is a cool new take on the classic Web2 Domain Name Service (DNS), which grants the owner of a particular NFT ownership over the name of the website domain they have purchased by means of a digital asset that can be stored in your wallet. A great example of this in action is the Ethereum Name Service (ENS), which mimics the typical domain subscription via time framed NFTs. Figure 7: Vitalik Buterin’s ENS website; Source: vitalik.eth But while, ENS works directly in your browser (via an IPFS connection), other similar services are platform-specific instead, as is the case of Campfire Usernames, which only work as searchable parameters on Campfire Exchange. And unlike ENS’s “.eth” domains, “.fire” ones effectively serve as creator profile tags above anything else. Bringing it all together In conclusion, Non-Fungible Tokens (NFTs) have come a long way from being just a novel concept in the digital world. Today, they are being used to represent ownership, authenticity, and scarcity in a vast array of applications beyond just JPEGs. From digital art and collectibles to gaming, music, and real estate, NFTs are proving to be a game-changer in the way we think about and value digital assets. While the NFT market is still in its infancy, the potential for growth and innovation is immense. As more people begin to understand the true value of NFTs, we can expect to see even more use cases emerge. Whether it’s a new form of digital currency or a way to tokenize and trade assets, the possibilities are endless. In the end, NFTs are more than just JPEGs—they are a revolutionary technology that has the potential to change the way we interact with digital assets forever. Whether you’re an artist, gamer, or collector, there’s no doubt that NFTs will play a big role in shaping the future of the digital world. Start BUIDLing and continue learning So… What’s next? It’s time to BUIDL your first NFT, of course! But even if this sounds quite difficult already, rest easy, for you don’t have to tackle this challenge alone. Instead, join us for yet another round of empiric learning with one of these relevant tutorials: Rookie: Get to know the process—learn how to plan your project, deploy a smart contract, mint an NFT, and market any collection post-release: Adept: Want to start minting NFTs, but you’re not an artist? Skip the paintbrush and discover how to code your way to abstract minting art: Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### A deep dive into GameFi: How NFTs are shaping the future of gaming The gaming industry is no stranger to embracing new technologies, and the recent rise of non-fungible tokens (NFTs) presents an exciting avenue for exploration. NFTs in gaming have the potential to redefine player ownership, create novel revenue streams, and foster innovative game designs. In this article, we’ll delve into the world of blockchain gaming, demystify NFTs’ role in video games, and examine how they’re revolutionizing the gaming landscape. So, without further ado, let’s catch up with blockchain gaming: Catching up with blockchain gaming Blockchain gaming has emerged hand in hand with the rise of NFTs, as the technology offers an entirely new way to develop, distribute, and monetize games. Blockchain gaming allows for decentralized control of game assets, giving players a sense of autonomy and ownership that was previously unavailable in traditional gaming setups. The adoption of NFTs as in-game assets has further fueled this new frontier, opening up novel gameplay mechanics and value propositions for both gamers and developers. Figure 1: 2021 global players per region with YoY growth rates; Source: Cointelegraph / Newzoo Understanding NFTs in gaming NFTs are distinctive and non-divisible digital assets stored on a blockchain. In gaming, NFTs act as digital proxies for in-game assets, offering players authentic ownership and control. By converting these virtual items into NFTs, players can transfer them between games, sell them on digital marketplaces, or gain rewards through play-to-earn schemes. Due to the decentralized structure of the blockchain, NFTs facilitate a self-sufficient gaming economy where players can participate as contributors, traders, and creators. NFTs in gaming come in different forms, mainly categorized into: In-game assets: These NFTs symbolize physical items in a game like weapons, skins, characters, and virtual real estate. Each asset possesses unique attributes, functions, and relevance within the game’s universe. Tokenization of these assets into NFTs provides players with genuine ownership and governance over their digital possessions. Governance tokens: Some games distribute governance tokens as NFTs, granting players voting privileges and sway over the game’s evolution and trajectory. These tokens foster decentralization and allow players to partake in the decision-making for the game’s future. What is GameFi? GameFi is a term derived from the combination of gaming and decentralized finance (DeFi). It refers to the integration of blockchain technology and financial mechanisms into games, enabling players to earn rewards, trade in-game assets, and experience decentralized game governance. NFTs in gaming offer several significant advantages for both players and developers. Leveraged by GameFi projects, these unique digital assets provide real ownership and lucrative opportunities: Ownership and control: NFTs facilitate true digital ownership for players, granting them the autonomy to manage, trade, or sell their in-game assets as they see fit. Interoperability: NFTs can enable cross-platform cooperation, with the potential for assets to move between different games or even ecosystems, enriching player experiences and driving creativity. Monetization: By tokenizing in-game assets and allowing for their transfer and trade, NFTs open up new revenue streams for not only developers but also players, who can now earn value through their game activities. Traditional gaming meets blockchain technology The gaming industry has come a long way since the days of arcade machines and simple 8-bit graphics. With advancements in technology, gaming has transformed from being a niche pastime to a multi-billion-dollar global industry. Similarly, the business models and player experiences that underpin gaming have evolved significantly over time. Traditional gaming typically relies on various revenue models such as upfront sales of physical or digital game copies, in-game microtransactions, and subscription-based revenue for online games. In these models, developers and publishers maintain substantial control over the game’s digital assets, and players often have limited rights to use or monetize in-game items. Trading of these assets is challenging and not officially supported outside of some gaming communities. Figure 2: Traditional games vs. Web3 games comparison; Source: Cointelegraph Evolution of the gaming industry The gaming industry has seen significant growth and change over the past few decades. New technologies like Virtual Reality (VR), Augmented Reality (AR), and eSports have propelled the sector to new heights, with gamers embracing innovative gameplay experiences. The introduction of blockchain technology and NFTs adds a new dimension to gaming, opening up fresh avenues for player engagement, interactivity, and monetization. Nowadays, NFTs enable game developers to create unique and verifiable digital assets that can be owned by players, giving them greater control over their in-game items. These assets can be traded, sold, or used across different games and platforms, further empowering players, and creating realistic in-game economies, as well as new revenue opportunities for developers and players alike. Exploring the GameFi ecosystem GameFi is poised to transform the gaming industry profoundly, opening up new possibilities for player ownership, creative game design, and monetization. By granting players more control over their in-game assets and offering novel mechanics like play-to-earn, socialize-to-earn, and Decentralized Autonomous Organizations (DAOs), GameFi fundamentally changes the relationship between developers, players, and games, ushering in a more decentralized and democratic future for gaming. Play-to-Earn and Socialize-to-Earn The Play-to-Earn model is a revolutionary approach to gaming that allows players to earn rewards by actively participating in games, particularly those integrated with blockchain technology. Rather than spending money on in-game purchases, Play-to-Earn games enable players to accumulate valuable assets as they play, which can later be traded or sold in online marketplaces. Figure 3: The Play-to-Earn business model in a nutshell; Source: FourWeekMBA Socialize-to-Earn is another innovative model, emphasizing players’ social interactions and engagement within the game. This system encourages players to build, share, and participate in game communities to earn tangible rewards in the form of in-game assets and governance tokens. Decentralized Autonomous Organizations (DAOs) GameFi projects often involve Decentralized Autonomous Organizations (DAOs), which are organizations operating through rules encoded in smart contracts on a blockchain. DAOs enable decentralized decision-making, typically giving players and stakeholders the ability to influence game development and other aspects of the project by voting on proposals, using governance tokens as voting power. This decentralization promotes a sense of player agency and fosters community-driven game development. Figure 4: Player governance in GameFi; Source: Chainlink DeFi integration in gaming Another facet of GameFi lies in its potential for integrating DeFi elements with gaming. DeFi and gaming share many similarities, such as decentralized control, tokenization, and community-driven governance. By integrating DeFi into gaming ecosystems, developers open up new ways for players to earn, trade, and invest assets. Games are increasingly leveraging DeFi tools like liquidity pools, decentralized exchanges (DEXs), and lending protocols to create a more vibrant in-game economy. This integration can take various forms, such as allowing players to stake in-game assets and earn rewards, providing liquidity for game-specific tokens or NFT markets, or even using synthetic assets to create new in-game mechanics. Figure 5: General model for blockchain gaming economics; Source: Cointelegraph / The Block Research Encapsulating all these elements, a range of game projects has emerged and found success, such as Axie Infinity, Decentraland, and iguVerse, among others. These projects showcase the potential of GameFi to disrupt traditional gaming models and deliver novel and engaging gaming experiences. Notable GameFi projects In recent years, several GameFi projects have garnered significant attention and traction, standing as a proof-of-concept for the potential of NFTs and blockchain technology in gaming. Among these, Axie Infinity, Decentraland, and iguVerse serve as prominent examples that showcase the viability and impact of this emerging sector. Axie Infinity Axie Infinity is a popular blockchain-based game centered around collecting, breeding, and battling fantasy creatures called Axies. In Axie Infinity, players can earn rewards in the form of Smooth Love Potion (SLP) tokens by participating in battles and completing various tasks. These tokens can be traded or sold on cryptocurrency exchanges or used to breed new Axies, which can be subsequently sold as NFTs on the marketplace. The Play-to-Earn model employed in Axie Infinity has attracted a considerable following, with many players treating the game not only as a source of entertainment but also as an income-generating opportunity. The success of Axie Infinity showcases the potential of NFT gaming to democratize the gaming industry and empower players through a decentralized and player-driven economy. iguVerse iguVerse is a GameFi platform focused on creating an interconnected ecosystem of blockchain-based games. Players can earn rewards and collect NFTs across different games within the iguVerse ecosystem, which can then be traded, sold, or used in other games on the platform as interoperable assets. This approach underscores the potential of cross-game NFT integration and blockchain gaming, illustrating the possibilities for a more dynamic and immersive future in the gaming industry, where players can participate in multiple games with a seamless transition of assets and rewards between them. Explore our iguVerse case study for an in-depth look into the project: Decentraland Decentraland is a virtual world built atop the Ethereum blockchain, offering players a platform for creating, owning, and trading digital assets. At its core, Decentraland utilizes NFTs to represent virtual land parcels, referred to as LAND, where users can build and deploy a wide variety of content, such as art galleries, casinos, or even games. The decentralized nature of Decentraland enables an open economy, allowing players to trade and monetize digital assets, such as LAND, wearables, or in-game items. The integration of DeFi elements, like staking and governance, adds another layer of depth to Decentraland’s metaverse experience, demonstrating the transformative impact that blockchain and NFTs can have on gaming and virtual reality. These successful GameFi projects highlight the diverse and promising landscape that NFTs and blockchain technologies are carving out within the gaming industry. As more developers adopt these technologies and players recognize their benefits, the gaming landscape will continue to evolve and redefine the boundaries of what is possible. GameFi’s road to mainstream adoption Several major developers, including Ubisoft, Konami, Atari, and others, have ventured into the NFT gaming space by releasing NFT collections or announcing plans to incorporate NFTs into their games. However, many of these initiatives have been met with backlash from gamers, developers, and even employees within the companies themselves. Valve Corporation, the company behind the popular digital game distribution platform Steam, has implemented a ban on games that incorporate NFTs or blockchain-based currencies. This resistance illustrates a disconnect between the growing interest in NFT gaming and the skepticism that still exists across different sectors of the industry. In contrast, Valve’s competitor, Epic Games Store, has expressed a willingness to welcome NFT games. This variance in policies mirrors the ongoing uncertainty and debate among industry stakeholders about the role and potential impact of NFTs in gaming. Ubisoft, a major gaming developer, and publisher, serves as an example of mainstream adoption. The company has already ventured into NFTs by establishing its Ubisoft Quartz platform. This platform leverages the energy-efficient Tezos blockchain to create, store, and manage in-game NFT assets called Digits. Figure 6: Ubisoft Quartz announcement trailer; Source: YouTube Although Ubisoft’s entry into the NFT gaming space has generated some criticism, it highlights the ongoing debate within the gaming industry about the role of NFTs and their transformative potential. Challenges and opportunities in GameFi Despite the potential of NFTs in gaming, many questions remain unanswered, and challenges need to be addressed, such as the standardization of assets across different platforms and the integration of gaming NFT marketplaces. However, the evolution of the gaming industry and the growing interest in NFTs continue to pave the way for increasingly immersive and interactive gaming experiences. Standardization and cross-platform compatibility One of the primary challenges facing the adoption of NFTs in gaming is the lack of standardization and cross-platform compatibility. To enable seamless trading and transfer of NFT assets across different games and platforms, standardization must be achieved, and mutual agreements must be reached among game developers. Figure 7: Fragmented gaming and blockchain ecosystems; Source: Chainlink Solution: Consortiums and collaborations among game developers, platforms, and other stakeholders can foster industry-wide agreements and promote the development of universal interoperability standards. New token standards like ERC-1155 for Ethereum and the protocols themselves can help establish frameworks that make cross-platform NFT compatibility possible. Security considerations As the popularity and value of NFT assets and blockchain games rise, so too do the security risks associated with them. Hacks and breaches could lead to significant financial losses for both developers and players. Solution: Robust security measures must be implemented by developers to protect both their platforms and players from malicious actors. This includes secure smart contract development, regular audits, and security best practices across development teams. Scalability Scalability is a major concern in the blockchain space, influencing the potential growth and adoption of NFTs in gaming. As blockchain gaming platforms grow in popularity, the ability of networks to handle increased demand becomes critical for smooth gameplay and effective asset management. Figure 8: The Blockchain Trilemma; Source: Chainlink Solution: Layer 2 scaling solutions, such as sidechains and state channels, can alleviate some scalability issues by offloading transactions and data from the main blockchain. Additionally, developers can explore newer, more scalable blockchain networks better suited for large-scale gaming applications. Skepticism and adoption resistance Many gamers and developers express skepticism and resistance towards NFTs and blockchain gaming. The controversy surrounding NFTs, combined with unclear benefits, can hamper widespread adoption. Solution: Increasing awareness and education about the benefits and possibilities of NFTs and blockchain gaming is essential to overcoming this resistance. Showcasing successful case studies, such as Axie Infinity or Decentraland, and creating more accessible gaming experiences may help win over a larger portion of the gaming community. While these challenges present complications for implementing NFTs in gaming, the industry is continuously exploring innovative solutions to address these issues, further pushing the boundaries of gaming and the potential for NFT integration. Opportunities Despite these challenges, there are notable opportunities for growth and development within the NFT gaming space: Collaboration with traditional game studios: As NFT gaming gains traction, forging partnerships with established game studios can serve as a gateway to broader adoption. Through collaboration, both sides can benefit from shared expertise and resources, exploring innovative gameplay mechanics that cater to a larger player base. Education and awareness: Boosting public understanding of NFTs and GameFi is vital for driving mainstream interest in the space. Efforts to educate gamers, developers, and investors about the potential of NFTs, blockchain, and GameFi can inspire a new wave of enthusiasts and developers. Technological synergy: Identifying points of intersection between NFTs and emerging technology (such as AI, VR/AR, and IoT) can unlock new possibilities for game design, mechanics, and user experiences. The growth of NFT gaming is fueling interest from a larger audience, but hurdles lie ahead on the road to broader adoption. These challenges and opportunities offer exciting prospects for developers and players alike, who together will define the future impact of NFTs in gaming. Impact of GameFi and NFTs on the gaming industry The emergence of NFTs and GameFi has sparked significant interest and development in the gaming industry, which is set to feel the ripple effects of this innovation. The impact of NFTs and GameFi on the gaming landscape can be observed from multiple perspectives, including player experiences, industry stakeholders, and game development philosophies. Figure 9: How does the gaming industry benefit from blockchain technology; Source: Imaginovation Player experiences NFTs and GameFi introduce players to new levels of ownership and control over in-game assets. As these assets become tokenized and tradeable, players can monetize their time, effort, and skill within games by buying, selling, or trading these digital goods. The Play-to-Earn model, for instance, turns gaming into an income-generating activity for many players, especially those in countries with limited economic opportunities. Furthermore, the cross-chain interoperability and the potential for having NFT assets transferable between games create a more interconnected and versatile gaming experience. Players will no longer be confined to a single game world, as their unique assets can travel with them across different platforms and virtual environments. Industry stakeholders The rise of NFTs and GameFi has opened new revenue streams and business models for game developers and publishers, as they can create, sell, and monetize NFT assets or leverage blockchain-based economies. However, not all industry stakeholders and gaming communities have embraced NFTs and blockchain technology. Concerns about environmental impact, financial risks, and potential scams have fueled skepticism and controversy within the gaming industry. Nonetheless, as technology advances and NFTs and GameFi mature, industry stakeholders will continue to explore innovative approaches to gaming that unlock new potential for players and developers alike. Game development philosophies The very concept of NFTs and GameFi signals a shift in game development philosophies, with a focus on player-centric design and the democratization of content creation. By tokenizing in-game assets, developers empower players to become creators, traders, and entrepreneurs within the gaming ecosystem. Figure 10: Closed and open in-game economies; Source: Chainlink This shift in philosophy places more value in the hands of players, leading to more meaningful interactions with games and greater incentives for developers to create engaging virtual worlds. It establishes a symbiotic relationship between players and developers, with each group fueling the success and evolution of the other. Empowering indie developers As NFTs and blockchain technology gain traction in the gaming world, these innovations promise to level the playing field for independent developers. The intersection of NFTs and gaming presents an opportunity for small-scale creators to monetize their work and become financially invested in their projects. Crowdfunding: Through the sale of NFTs representing in-game assets, indie game developers can secure early-stage funding and bootstrap their projects. This approach to financing game development democratizes access to resources and rewards community-driven efforts. Secondary market revenue: NFTs can enable revenue sharing from secondary market transactions, allowing developers to benefit from the ongoing sale and trade of in-game assets. This continuous source of income can sustain indie developers’ efforts and fuel future projects. Player-led innovation NFTs encourage a shift in game design, empowering players to become creators and traders within the gaming ecosystem. Transforming game assets into NFTs broadens creative possibilities and fosters a player-centric game design philosophy. Asset creation: By creating and selling game assets as NFTs, players can take on the role of creators within the game world, shaping the development of the in-game environment while reaping financial rewards for their efforts. User-generated content: Player-created NFTs can fuel the production of user-generated content that enriches game worlds, providing new spaces and stories to explore. The impact of NFTs and GameFi on the gaming industry is undeniable, with the potential to redefine the gaming landscape in profound ways. As the sector continues to innovate and advance, the integration of these technologies and concepts will play a central role in shaping the future of gaming. Such integrations have the potential to democratize the industry, breaking down barriers for indie developers and tapping into the collective imagination of players. By harnessing the creative force of the gaming community, we can imagine a more inclusive and diverse gaming landscape, built by and for the players themselves. Mapping the future of GameFi As GameFi continues to grow and gain momentum, several key trends are poised to further shape its future and redefine the landscape of gaming. Among these trends are cross-chain interoperability, the integration of virtual reality (VR) and augmented reality (AR), and the fusion of artificial intelligence (AI) and machine learning in blockchain gaming. Cross-chain interoperability The importance of cross-chain interoperability cannot be understated, as it allows for seamless interaction and exchange between different blockchain networks and their native assets. In the context of GameFi, this interoperability translates to a more streamlined and integrated gaming experience, where players can utilize items, assets, and currencies across multiple games and platforms without friction. Figure 11: Universal blockchain gaming ecosystem via interoperability standard; Source: Chainlink VR and AR integration The realms of virtual and augmented reality hold immense potential for the gaming industry, with their power to create immersive and engaging experiences. When combined with NFTs and blockchain technology, VR and AR can further revolutionize the gaming landscape by integrating unique digital assets into highly interactive environments. As VR and AR technologies become more accessible and advanced, gaming experiences built on the foundation of GameFi will continue to evolve, offering players and developers an unprecedented level of immersion and interaction within virtual worlds. AI and machine learning in blockchain gaming Artificial intelligence and machine learning are already making inroads into various sectors, and gaming is no exception. In the context of GameFi, AI and machine learning can play a pivotal role in enriching gameplay and creating highly adaptive, intelligent systems within blockchain-based games. Innovative applications of AI and machine learning could range from procedurally generating unique game assets that can be minted as NFTs, developing intelligent non-player characters (NPCs) that learn from player interactions, or even creating entire game worlds that evolve based on player choices. As GameFi continues to advance, the convergence of these technologies and trends, combined with NFTs and blockchain, has the potential to redefine the future of gaming and push the boundaries of immersive, interactive experiences. Bringing it all together NFTs have unleashed a wave of innovation and possibility in the gaming industry, offering players unprecedented levels of ownership and control over their in-game assets. By integrating blockchain technology with gaming, we’re witnessing the emergence of a new paradigm that empowers players to participate in decentralized economies, contribute to communities, and monetize their gaming experiences. While challenges such as security, standardization, and adoption resistance exist, the growth potential of this space is substantial, as it changes traditional game development philosophies towards player-centric designs and encourages democratization of content creation. And in the end, the rise of GameFi is not only elevating the ways we interact with games but also reshaping the gaming industry as a whole, forging a more inclusive, equitable, and democratic landscape for all to enjoy. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### A StarkNet odyssey: Escaping Cairo hell This is part two of the StarkNet odyssey series in which I explore the StarkNet L2 protocol. Make sure to check part one of this series to get an overview of the protocol, understand what ZK-Proofs are, and learn about all the different tools you need to start developing on StarkNet. In this article, we’ll review the fundamentals of Cairo—the language used to write smart contracts in StarkNet—and we’ll see how to interact with our contracts from a front-end app using the ArgentX JavaScript library. You can find all the code samples, contracts, and the web app shown in this article in the GitHub repository. Cairo fundamentals As mentioned by Henri Lieutaud (developer advocate at StarkWare) in one of his presentations, Cairo is… well, Cairo is hell. There is an official Cairo 101 repository with code samples, and although it’s super helpful, you can find yourself completely lost reading those contracts. The learning curve in Cairo is super steep, and trying to understand how things work can be very overwhelming. So let’s try to break down the most common patterns and things that you need to know before you start writing a single line of code. What is felt? felt stands for Field Element and is the only data type in Cairo. In simple terms, it’s an unsigned integer with up to 76 decimals, but it can also be used to store addresses. Strings Currently, Cairo does not support strings. It supports, however, short strings of up to 31 characters but they’re actually stored in felt. # = 448378203247 let hello_string = 'hello' Arrays To use arrays in Cairo, you need a pointer that points to the start of the array, which is declared as a felt* using the alloc method. Adding new elements to the array can be done using assert (more on that later) and the pointer. See an example below: %lang starknet %builtins range_check # import to use alloc from starkware.cairo.common.alloc import alloc # view function that returns a felt @view func array_demo(index : felt) -> (value : felt): # Creates a pointer to the start of an array. let (my_array : felt*) = alloc() # sets 3 as the value of the first element of the array assert [felt_array] = 3 # sets 15 as the value of the second element of the array assert [felt_array + 1] = 15 # sets index 2 to value 33. assert [felt_array + 2] = 33 assert [felt_array + 9] = 18 # Access the list at the selected index. let val = felt_array[index] return (val) end If we try to read a value from an array at an invalid index, the program will fail with the following error: Unknown value for memory cell at address. You can use arrays as function parameters or in returns, but when declaring it, you should indicate two parameters—the array’s length and the array itself. The naming convention is also important and should be my_array_name and my_array_name_len. For example: %lang starknet %builtins pedersen range_check from starkware.cairo.common.cairo_builtins import HashBuiltin # Function that receives an array as parameter, so it actually receives the array length and # the array itself @external func array_play(array_param_len : felt, array_param : felt*) -> (res: felt): # read first element of the array let first = array_param[0] # read last element of the array let last = array_param[array_param_len - 1] let res = first + last return (res) end If you don’t follow the proper naming convention, you’ll get the following error from the compiler: Array argument “array_param” must be preceded by a length argument named “array_param_len” of type felt. Structs and mappings Structs are very similar to Solidity. We just have to define them with the struct keyword and define all its attributes as a member: # Account struct struct Account: member isOpen: felt member balance: felt end To create a mapping in Cairo, you have to define the types and use the -> sign between the key and the value. For example: # Mapping named "accounts_storage" that holds the account details for # each user using his address as key @storage_var func accounts_storage(address: felt) -> (account: Account): end We can also return structs from a Cairo function. Declaring variables Variables can be aliased using the let keyword, or evaluated using the const, local or tempvar keywords. const used for constants, can not be re-assigned. local used for local variables. Can not be re-assigned and requires adding alloc_locals to the function. tempvar used for temporary variables. They can be re-assigned. let used to create alias by value or by reference to other variables. Can be re-assigned. Here are some examples of how to use each one of them: %lang starknet # persistent state variable @storage_var func storage_variable() -> (res : felt): end func variable_examples{}(): # required to use local variables alloc_locals # creating alias by value let a = 5 let b = 3 # creating alias by reference. x value is 5 let x = a # constant, can not be re assigned const ten = 10 # res is 15 here, 5 * 3 tempvar res = a * b # local varible. c is 15 local c = ten + a # re-assign aliased variable let b = 2 # re-assign tempvar. res is 10 here, 5 * 2 tempvar res = a * b return () end Notice that in order to re-assign a variable, you have to indicate the variable type (tempvar, let). Storage variables: read and write Contract state variables are called storage variables in Cairo. To define them, we need to use the @storage_var decorator and declare them as functions as follows: # Keeps a counter of the number of accounts @storage_var func number_of_accounts() -> (res: felt): end To read and write to storage variables, we need to use the read and write methods, making sure that the data type that we pass matches the data type defined in the storage variable: # Keeps a counter of the number of accounts @storage_var func number_of_accounts() -> (res: felt): end # Creates an account for the user @external func readWriteAccounts{syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr}(): # read number of accounts from storage let (n_accs) = number_of_accounts.read() # writes number of accounts in storage number_of_accounts.write(n_accs + 1) return () end Why is {syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr} in every method? If you have read any Cairo contract, you’ve probably found these lines of code all over the place:{syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr}. Those are implicit function arguments and they are used to access the state variables behind the scenes. In addition, range_check_ptr can be used to compare integers. Just remember to include them in your function declarations when you’re reading or writing state variables. If you forget to include them, the compiler will fail with the following error: Unknown identifier ‘syscall_ptr’ … Unknown identifier ‘syscall_ptr’ 😉 Assertions The assert statement is very useful but it can be used for two completely different things: to compare if the value of two variables is the same. to set the value in a variable that has not been set before. See the example below: %lang starknet @external func demo_assert(guess : felt) : const a = 7 tempvar b # verifies if the guess is 7 assert a = guess # assigns 5 to variable b assert b = 5 # verifies if the guess is 5 assert b = guess return () end For other assertions, you can import different methods from the starkware.cairo.common.math library like assert_not_zero, assert_in_range, assert_not_equal, assert_le and assert_lt. For example: %lang starknet from starkware.cairo.common.math import ( assert_not_equal, assert_in_range assert_not_zero, assert_lt, assert_le, ) @external func assertions_demo(a: felt, b: felt): assert_not_zero(a) assert_not_equal(b, a) assert_le(1, 100) assert_lt(b, 1) assert_in_range(b, 1, 60) return () end Contract functions Cairo contract functions are declared with the @external or @view decorators. External functions can be called by users or by other contracts while view functions are similar but they only query the contract state and do not alter it. # view function that returns the number of accounts from the storage variable @view func accountsOpen{syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr}() -> (res: felt): let (res) = number_of_accounts.read() return (res) end # Creates an account for the user and updates the storage variable @external func openAccount{syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr}(): let (sender_address) = get_caller_address() # checks if the user already has an account let (user_account) = accounts_storage.read(sender_address) assert user_account.isOpen = 0 let (n_accs) = number_of_accounts.read() accounts_storage.write(sender_address, Account(isOpen=1, balance=0)) number_of_accounts.write(n_accs + 1) return () end Returned values must be indicated in the function declaration, and wrapped in parenthesis in the body, even if the function does not return anything 😉 Contract structure Contracts in Cairo have a similar structure to contracts written in Solidity. It’ll contain the following: Language declaration %lang starknet Imports Structs and state variables Contract methods Messaging between L1-L2 One of the cool things you can do with Cairo is send messages between StarkNet (L2) and Ethereum (L1). You’d need to deploy a contract in StarkNet and use the send_message_to_l1 function, which takes as parameters the address of the contract that is going to receive the message in the L1 and the payload. You’ll also need to deploy a contract in Ethereum that implements the interface IStarknetCore, which has the methods sendMessageToL2 and consumeMessageFromL2. You can find a step-by-step tutorial about L1-L2 messaging in our docs. Interacting with contracts Although you can interact with contracts directly from Voyager, the official explorer, you will most likely build a web app or script to interact with your contracts. When it comes to interacting with StarkNet contracts from a web application, the most common libraries are starknet.js and @argent/get-starknet. The first one is a standalone JavaScript library that you can use in both the front and the back-end applications. You can find the API documentation here. The second one is a light wrapper that makes it easier to interact with the wallet, although it uses the starknet.js library as a peer dependency, so the API to interact with contracts is the same. Web app example I’ve created a Vue.js web app to showcase how to interact with a contract deployed to StarkNet. You can find the code in the following repository. The @argent/get-starknet makes it super simple to connect a wallet and, by default, includes a pop-up that allows users to use both ArgentX or Braavos wallets. Here’s a quick code snippet that shows how to connect to the user’s wallet: import { connect } from '@argent/get-starknet' let starknet = null const connectWallet = async () => { starknet = await connect() console.log('startknet >>', starknet) if (!starknet) { throw Error( 'User rejected wallet selection or silent connect found nothing' ) } await starknet.enable() // Check if connection was successful if (starknet.isConnected) { console.log('starknet connected') } else { console.log('starknet wallet not connected') } } Once your app is connected to the user’s wallet, you can use it to interact with contracts using the starknet.account.callContract function for view methods, or starknet.account.execute for external methods. Both require an object with the following properties: contractAddress entrypoint which is the method name we want to call. calldata an array with all the parameters we want to send. (optional) Here is an example to use both: const CONTRACT_ADDRESS = '0x07955c619cb22d08ece120ef4f5faa531318ac9934018ef28fdae9284b831b4d' // Reads from the chain using callContract const getUserNumber = async () => { try { const res = await starknet.provider.callContract({ contractAddress: CONTRACT_ADDRESS, entrypoint: 'get_number', }) console.log('res', res) savedNumber.value = Number(`${res.result[0]}`) } catch (error) { console.error(error) } } // Writes on-chain using execute const saveNumber = async () => { try { const trxDetails = await starknet.account.execute({ contractAddress: CONTRACT_ADDRESS, entrypoint: 'save_number', calldata: [userNum.value], }) console.log('trxDetails', trxDetails) } catch (error) { console.error(error) } } StarkNet Python library If you prefer to use Python in your StarkNet projects, StarkNet.py is what you need. It offers both synchronous and asynchronous methods to interact with contracts and query the blockchain. Conclusion I hope this helps you kick-start your projects in StarkNet and solve any doubts you might have about how to start developing apps in it. L2 solutions are becoming more and more popular and StarkNet is one of the most active ones, with hackathons taking place almost every month. The team has recently launched StarkGate, a bridge to move ETH to StarkNet and the adoption has been great so more applications will be available soon. If you want to keep learning about StarkNet and Cairo, make sure to follow Henri Lieutaud on Twitter and check out the StarkWare Youtube channel in which you’ll find workshops and live community calls. And of course, spin up your own StarkNet node in Chainstack 😉 Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Alchemy RPC provider overview (2026) RPC providers connect decentralized applications to blockchain nodes, allowing them to read data and send transactions on various networks. It’s essential for any Web3 app because it abstracts the complexity of running blockchain infrastructure, providing developers with reliable, low-latency access to blockchain data and state. In other words, an RPC provider is the bridge that lets your application communicate with the blockchain seamlessly, it’s crucial for everything from fetching balances to submitting new transactions in real time. In summary, Alchemy is a powerful and developer-friendly RPC provider with a rich feature set and proven performance. It’s an excellent choice for building on popular chains and benefitting from advanced tools. However, when it comes to cost predictability and unlimited scaling, Chainstack has an edge. Alchemy Homepage Alchemy company history Alchemy is a leading blockchain infrastructure company. The platform was founded in 2017. After initially experimenting with consumer apps, the founders pivoted to developer infrastructure upon realizing how difficult it was to build blockchain applications with the tools available at the time. Alchemy launched its platform to simplify Web3 development. Over the years, Alchemy expanded beyond its Ethereum roots to support dozens of chains, helping power many of the most popular dApps across almost 200 countries today. Alchemy’s core products Alchemy offers a suite of products and APIs for Web3 development. Its core offerings include: RPC API: A powerful endpoint for interacting with blockchains using standard JSON-RPC calls. It offers fast, reliable node infrastructure for reading and writing chain data and scaling apps.  Smart Websockets: A WebSocket service that pushes real-time blockchain events (new blocks, transactions, address activity, NFT events) to your app with easy setup.  Rollups: A rollup-as-a-service platform to launch and scale custom Layer-2 chains with built-in developer tooling and APIs.  Cortex: The intelligent blockchain engine that powers Alchemy’s products, improving performance, reliability, and throughput across the platform.  Performance and key factors Latency: Alchemy has invested heavily in global infrastructure to deliver low-latency RPC responses. Developers using Alchemy can expect near real-time data retrieval and transaction submission without noticeable delays. Reliability & Uptime: The platform is known for its strong reliability. Alchemy operates a distributed, fault-tolerant architecture across multiple regions to avoid single points of failure. Many top projects trust Alchemy for its proven track record of keeping infrastructure running smoothly during critical times. Throughput: Alchemy’s RPC service is designed to scale as your application grows. Even the free tier can handle around 300 RPS on Ethereum-equivalent workloads, which is sufficient for many small to mid-sized projects. Higher paid plans allow significantly greater throughput by allocating more compute units per second. Cost model: Alchemy’s pricing is based on compute units rather than raw request counts. Every RPC method is assigned a weight depending on how resource-intensive it is. This usage-based model can be flexible, but it also means costs aren’t always predictable upfront, especially if an application makes a lot of “light” calls that nonetheless add up in compute units. Alchemy Compute Units Costs for Debug API AreaAlchemy strengthsPotential weaknessesPerformance & scaleLow latency on major chains; Supernode handles high RPS and burstsHeavy methods get costlyReliability & uptimeMulti-region, autoscaling architecture; strong uptime track recordHighest SLAs and priority support are enterprise-tierTooling & ecosystemRich suite: Build, Monitor, Notify, Transact; polished docs and UXProprietary stack; depth strongest on Ethereum-first flowsPricing & controlGenerous free tier; flexible CU-based billingMethod-weighted costs are harder to predict; limited per-node infra control Alchemy pricing Alchemy offers a free plan that includes up to 30 million Compute Units per month, which translates to roughly 1.8 million simple RPC requests depending on the method mix. This allowance is noticeably lower than what is available on Chainstack’s free Developer plan. Above that, Alchemy uses a Pay As You Go model where pricing is based on Compute Units rather than simple request counts. In practice, this means different RPC methods consume different amounts of compute, and heavy methods like logs, traces, or complex calls can significantly increase usage. MetricChainstackAlchemyPlan used in exampleProPay As You GoIncluded usage80M Request Units0 Compute Units includedWorkload equivalent73.5M method calls73.5M method callsCompute usage (example workload)Fits in included usage1.955B Compute UnitsPlan price$199$0Overage charges$0$745Total monthly cost$199$745 The difference becomes clear when looking at a real workload example. In the scenario above, the same set of method calls that fits within Chainstack’s included usage generates nearly 2 billion Compute Units on Alchemy, resulting in about $745 in overage charges. For small projects, the pricing model can work well. However, for production workloads with heavy reads, logs, or traces, forecasting costs becomes more difficult because pricing depends on weighted compute usage rather than request volume. See the full cost comparison → Alchemy vs. Chainstack comparison Both Alchemy and Chainstack are high-performance Web3 infrastructure providers, but there are some key differences in their approach that can sway developers towards Chainstack: Multi-chain support: Alchemy has expanded to support around 50+ blockchains including major ecosystems like Ethereum, Polygon, Solana, Base, and even newer chains like Hyperliquid. Chainstack, however, is multi-chain by design and currently supports 70+ protocols. Pricing and scalability: Alchemy’s usage-based billing means costs scale with activity, and certain calls count more against your allowance. By contrast, Chainstack uses transparent flat-fee pricing with no method weighting. Every RPC call is simply a request, making monthly bills much more predictable. Notably, Chainstack offers an Unlimited Node option – an add-on available even on its entry-level plans – which lets you make unlimited RPC requests for a fixed monthly price. Performance and reliability: Both providers excel in low-latency, globally distributed infrastructure. Chainstack matches Alchemy’s speed and also boasts 99.99%+ uptime SLA on its infrastructure, achieved through real-time adaptive failover and load balancing. This level of reliability is offered across all Chainstack plans, whereas Alchemy’s strict uptime guarantees and priority support are typically reserved for higher enterprise tiers. Try Chainstack with predictable RPC pricing → FAQ Is Alchemy a secure and reliable platform? Alchemy runs a multi-cloud, multi-region setup with redundancy and monitoring, which delivers generally strong reliability. Detailed uptime guarantees and priority support, however, are mostly limited to higher-tier or enterprise plans. How does Alchemy price RPC usage? Alchemy bills using Compute Units, with each RPC method assigned a different weight and throughput capped in CUs per second. This model is flexible but method-weighted, making costs harder to predict and requiring active usage monitoring. How does Alchemy perform on latency, throughput, and uptime? Alchemy offers low latency via global infrastructure and handles moderate to high traffic well. Throughput is limited per app, and throttling applies once limits are hit, so retries and rate control are often needed. Strong SLAs are typically reserved for enterprise users. What are the main differences between Alchemy and Chainstack? Both providers offer production-grade RPC. Alchemy’s CU-based pricing can be efficient but less predictable at scale, while Chainstack’s flat, request-based pricing and Unlimited Node option focus on cost predictability and consistent performance across plans. Related Reading Chainstack vs QuickNode vs Alchemy Helius RPC provider overview dRPC provider overview Ankr RPC provider overview Quicknode RPC provider overview #### Aleph One on Chainstack: Accelerating customer growth Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. With Chainstack on board, Aleph One was able to increase its team productivity by 30%, saved 1.5 months of engineering hours, and achieved 25% reduction in release cycle. What does Aleph One do? Aleph One is a global one-stop-shop Fintech consulting and engineering boutique operating since 2016. Their focus is on the creation of innovative software products and systems. Aleph One’s track record includes leading-edge blockchain-based solutions for various supply chains, tokenized asset trading systems for a global Swiss bank, and pitch-perfect regulatory consulting. Their customer base comprises Inc. 500 companies and swift disruptors, including Swag.com and Bloomberg. How did Aleph One come across Chainstack? Right after the release of Hyperledger Fabric 2.2, which introduced features like decentralized governance for smart contracts and private data enhancements, Aleph One’s team decided to move away from a self-managed solution and started to look for a managed service that would fit into their development lifecycle and the production requirements of their customers. Being a power user of Hyperledger Fabric, the Aleph One team had to write and test Fabric chaincode locally, putting 20% of the efforts and time of their cross-functional team in configuration management activities, thus requiring a substantial workforce and infrastructure investment for development and staging environments. It is at this point that finding a more scalable solution became fundamental to Aleph One’s business, and they came across Chainstack managed blockchain services. Although they initially tried IBM Blockchain Platform, Aleph One quickly realized that Chainstack was superior when it came to providing fast and highly responsive support as well as competitive pricing given our highly customer-centric ethos and agile processes. Fortunately, moving their client’s decentralized apps from IBM Blockchain service to Chainstack was easy as Chainstack’s Hyperledger Fabric infrastructure is fully compatible with IBM’s. How does Chainstack’s offer match Aleph One’s needs? The Aleph One core belief is to always operate smarter and more efficiently because this leads to building deeper customer relationships. They needed robust and agile Fabric 2.2 infrastructure so engineers can focus on their product development and customer value. Chainstack’s Hyperledger Fabric offering seamlessly integrated into Aleph One’s CI/CD pipeline and the development environment, contributing to shorter time-to-market and release cycles. Aleph One’s decentralized applications, implemented as Hyperledger Fabric chaincode, could easily be integrated into Chainstack thanks to its execution environment and the support of development tools such as VS Code extension, unmatched by the competition. Outcome 25% shorter release cycle 15% reduction in the total cost of ownership 30% increase in team productivity 1.5 months engineering hours saved What does Chainstack like about Aleph One? Chainstack is a class apart when it comes to doing the right thing. For instance, from gathering clear and specific requirements from our business and IT teams, to detailing out the plan considering both processes and tools—to seamless integration of our decentralized applications developed in Fabric chaincode into Chainstack’s environment. Chainstack’s knowledge and expertise helped save us time and money. Thanks to them, we were able to maximize our resources to reach our IT and product development goals. Stanislav Synko, Aleph One’s Founder Aleph One is committed to extraordinary customer experience, just like Chainstack. Their drive to continuously streamline and optimize processes in order to better focus on customer requirements resonates with the core values of the team at Chainstack. In addition, the deep technical expertise of the Aleph One team in Hyperledger Fabric has meant sharing of knowledge and ideas between the two engineering teams, which is fostering improvements and innovation on both sides. What is the most interesting engineering challenge in working together? Hyperledger Fabric development requires an ongoing investment of time and effort due to the open-source nature of its codebase. Chainstack has great experience in handling and localizing occasional issues in Hyperledger Fabric and supports Aleph One in dealing with them, saving significant amounts of time. This day-to-day collaboration and interactions allowed to discover and resolve critical defects within the protocol. Among them, the Chainstack team revealed a security issue that could lead to the full degradation of the Hyperledger Fabric network as all network peers were constantly crashing due to the incorrect block data they were trying to sync. The peers could not correctly process a block containing an empty byte array added through Hyperledger Fabric chaincode. Chainstack engineering team troubleshot the flaw and reported it as soon as the reproduction steps were identified. Fortunately, Hyperledger Fabric community was very responsive and version 2.3.1 with the fix is already available. Get started with Hyperledger Fabric on Chainstack Deploy and manage high-performing Hyperledger Fabric nodes and networks in cloud or on-prem within minutes. Install and test chaincode, create channels and build applications on top of an infrastructure layer that you can trust. Scale-up by deploying as many nodes as you need, on your cloud of choice, always with predictable pricing. To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Have you already explored what you can achieve with Chainstack? Get started for free today. #### All are not equal: Comparing leading enterprise blockchains’ developer activity As blockchain technology moves ever-forward, so has the world of enterprise blockchains emerged and grown. These protocols–which are based on blockchain and distributed ledger concepts–have privacy, security, and accountability at heart.   Moreover, while the public blockchain space has been the subject of detailed analysis time and time again, enterprise blockchains have remained largely unquantified, with little exploration done into the metrics behind each protocol’s success and popularity, or lack thereof.   Chainstack has produced a report that investigates the activity of developer communities surrounding the leading enterprise blockchain protocols. You can download the report today. Monitoring the landscape  At Chainstack, we have an inherent need to follow the creation and growth of enterprise blockchain protocols very closely. The nature of our product requires us to have a broad and comprehensive view of this space, both in terms of which protocols are actually being used in real-world projects, and of the size and activity of the developer communities that build, develop and engage in conversation around them. The latter is of particular interest to us and should also be valuable information to any company deciding which protocol to use for their next project.  There are numerous choices of protocol available, and they all vary in their level of maturity. As we are still in the relatively early days of these kinds of software projects, it is useful to track the activity of their repositories as a measure of the health of the codebase and the communities around them. This is because when choosing to put time and money behind a protocol (or any open-sourced project for that matter), no matter how well-designed it is or how well-suited it is for the application you are building, if the community is small and there are not enough developers dedicated to growing and evolving the codebase, then you could find yourself facing issues such as incomplete documentation, poor community support, unaddressed bugs and stagnating feature sets.   It is for these reasons that we decided to conduct research to uncover the true scale and growth of enterprise blockchain developer communities in the hopes of adding a new degree of understanding in this important facet of protocol selection.  A dataset emerges  What started as a curiosity quickly developed into a massive dataset of developer activity across multiple enterprise blockchain protocols as our team started to uncover the story of how these communities came to fruition and evolved. After some data wrangling to account for nuances in how and where the developer activity occurred (see Hyperledger Fabric’s existence on Gerrit until late in Q4 2019), what we discovered included repositories with highly engaged communities that have been steadily growing for several years, to those that started with a bang and fizzled down to the point of having very little activity coming from only the most dedicated contributors.  These insights have excited and intrigued us, as many of these protocols have evolved quite quickly to address different use cases while attempting to overcome numerous challenges. This is what created the motivation to write the first Enterprise Blockchain Protocols Evolution Index.   Enterprise Blockchain Protocols Evolution Index 2020 This report is an investigation into the developer activity of open-sourced, general-purpose blockchain protocols hosted on GitHub. Collecting data from the GH Archive starting in 2011 until the end of 2019, we have decided to focus on the 6 protocols that make up the bulk of activity, and that we believe best represent the publicly available options that enterprises would consider in their choice of software to power their blockchain projects.  What you will find inside is a detailed quantitative and qualitative analysis of what makes the communities around these protocols different. Whether that is an attachment to larger communities (like with Quorum to Ethereum or the Hyperledger projects to the Linux Foundation), or a backing by sizeable entities with access to the resources to put behind full-time developers (such as IBM to Fabric, JPMorgan to Quorum or R3 to Corda).   On top of that, we begin to see how these communities change and evolve over time. As the landscape transforms, priorities shift, competition comes and goes, and so the developers lending their time to these protocols change with it. Being barely more than 4 years into this nascent industry, there have already been several such shifts. This is the first time that a time series analysis has been applied to comparing these protocols in this way with any meaningful results, and it will continue to produce additional insights as the industry develops. Continued monitoring and updates  This dataset will continue to evolve, and we are excited to see how it does. There are already new players making waves in communities, while the incumbents continue to grow as they are being used in an increasing amount of real-world, production-grade projects. We aim to continue monitoring these changes and will periodically update the report in order to share new findings, dissect the data in new ways and provide an additional layer of insight to help inform the decisions that are impacting the shape of the industry.   Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### All we need is trust Part 1 of the Trust Trilogy Photo by rawpixel on Unsplash By Laurent Dedenis Going by Oxford English Dictionary, trust is defined as ‘firm belief in the reliability, truth, or ability of someone or something’. It is a concept like any other — love, duty, or responsibility but an incredibly important one. In fact, trust is a fundamental element of social capital — a key contributor to sustaining well-being outcomes, including economic development. I am not certain you feel the same, but it seems that ‘trust’, ‘The Trust’ has been at the center of many more discussions since the beginning of the 21st century. Maybe more than any time in the entire 20th century? In fact, “trust” is now at the core of the most influential segments of our modern societies: entertainment, media, politics, business as well as our overall interactions with others. But how far back does trust go? Did it only begin in the formalization of agreements during the crusades when knights entrusted their land to certain authorities in case they did not return? Or was it earlier during the Romans? Or earlier than that? Surely, a more productive course of enquiry is to ask how trust manifests in our world of trillion dollar commerce, what does it cost, and, going further, talk about the novel way in which it is being upended. From tribes to consortiums It is not an exaggeration to say that even in the 21st-century, our world is still full of tribes. From our gatherings around a fire in ancient times to our modern boardroom meetings, the fundamental nature of being part of a tribe is trust. It is the glue that makes trade happen and leads to alliances, business or social. And wherever there is a lack of it, trusted intermediaries must come into play. Powerful medieval guilds, colonizing merchant groups such as the various East India companies, and the modern consortium came together around shared values. Surely all that was not instantaneous. Building trust requires a long time simply because it stands on the shoulders of reputation. And as Buffett says, “It takes 20 years to build a reputation and five minutes to ruin it.” Never mind the part about ruin, which we will come to shortly; today there is no denying the influence that alliances/consortium have on our daily lives. Today, the World Wide Web, SWIFT, CERN, Hulu, Signature Travel Network, and numerous other alliances form the backbone of our lives. Surprisingly, some massive organizations of today such as Airbus started off as a consortium as well. But trust, the way it has been managed, has its dark side too. History, as well as the present time, is filled with countless examples of collusion. In the recent past, banking, charities, retail, and, sadly, even pharma, have all suffered from the erosion of trust. What every example shows is how fragile and easily manipulable trust is, at least the way it has been managed historically. A new generation of trust We are currently in the blockchain hype cycle. Some call it a fancy distributed database, while others call it a problem looking for a solution, some are in awe of its mathematical elegance, and others are simply turned off by its colossal inefficiency. Regardless, the skeptics have known all along that it won’t cure cancer. I agree. But we are on the topic of trust, so let me give my two cents’ worth. I consider blockchain a ‘Controllable Trust Interface’, and it holds the potential to end the timeless search for a trust that is easy to establish and cannot be manipulated. It holds the promise of creating trust among strangers, beyond borders, and instantaneously. In some way, the new generation of trust is a new standard for trust, an instantaneous and permanent version available for anyone to make use of and collaborate with. I have always maintained that collaboration is at the heart of the modern enterprise. More things can be achieved when we view the world as a place of expanding possibilities instead of a zero-sum game. But what’s at the heart of collaboration? You might have guessed where I am taking this. All this seems like unraveling a Matryoshka doll, where underneath the expanding possibilities is collaboration, underlying collaboration is trust among participants, and underlying trust among participants is trust in the system. Blockchain, here we come! The notion of shared public ledgers may not sound revolutionary or sexy. Neither did double-entry book-keeping or joint-stock companies. Yet, like them, the blockchain is an apparently mundane process that has the potential to transform how people and businesses co-operate. …. The real innovation is not the digital coins themselves, but the trust machine that mints them — and which promises much more besides. Economist The consortium of everyone The elegance of blockchain lies in its ability to combine cryptography and consensus to achieve the holy grail of every group undertaking — trustlessness. The vast advancements in mathematics and computing have led us to a point where human corruptibility can be substituted with unbreakable verification. Now you and I can transact securely, doesn’t matter if we have not met in person, communicated digitally, or don’t have a common friend, as long as we have each other’s public address and a unique set of keys to open doors. This powerful duo of math and computing will create a level playing field for all. Smaller businesses, restricted by the cost and time it takes to establish trust, until now, can start transacting in international markets confidently. Larger businesses can welcome competitors, and rather than playing offense or defense via information silos, can genuinely collaborate. And the individual mom and pop store need not fear being swindled out of their modest capital by transacting with strangers. The blockchain welcomes everyone into its fold and protects everyone. So yes, all we need is trust, but in a whole new way. Welcome to the consortium of everyone, and stay tuned for part 2 of the Trust Trilogy where we explore further the new world of trust and how it’s creating new possibilities. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Amoy Faucet: Get free Amoy testnet MATIC Introducing the Amoy MATIC faucet: Your portal to testnet MATIC. Navigating the realms of Web3 development requires access to testnet tokens for experimenting with smart contracts, building decentralized applications, or refining blockchain solutions. Understanding these needs, we’ve launched the Amoy MATIC faucet, crafted specifically for Web3 developers. Get Amoy MATIC How to use the Amoy faucet Once you’ve registered and set up an API key on the Chainstack console, you can claim up to 1 Amoy MATIC every 24 hours. This MATIC is essential for sending transactions on the Amoy testnet, deploying your smart contracts, and testing functionalities before moving to the mainnet, which uses real funds. Why do I need Mainnet ETH to request funds from the faucet? Our faucet mandates holding a small amount of ETH in your mainnet wallet to use it. This requirement helps ensure fair usage and prevent abuse of the faucet. Why the delay in receiving tokens? Receiving your tokens is typically quick, but network congestion might cause delays. If your tokens don’t arrive within 15 minutes, please contact us on Telegram or Discord. I get an error saying “The user can only receive funds every 24 hours.” To ensure fair distribution, we limit requests to a maximum of 1 Amoy testnet MATIC per day. I get an error saying “Something went wrong. Check credentials and try again.” This could be due to an incorrect API key or wallet address. Verify your details, refresh the page, and try again. To generate your API key, sign up via the Chainstack console. Learn how to generate your API key by visiting our documentation then request Amoy MATIC from the faucet. If your API key and wallet address are correct and you still face issues, contact us on Telegram or Discord for assistance. Need help using the faucet? Reach out via Telegram or Discord, and our team will assist you in acquiring testnet tokens. Now that I have my funds, what shall I do next? Share details about the DApp you are building and tag our @ChainstackHQ Twitter account. We’re eager to hear about your projects. I want the best Polygon nodes Sign up on Chainstack to deploy a node for free. We support over 20 different blockchains and provide extensive developer tools. What is Chainstack? Chainstack offers a comprehensive Web3 development stack, providing every protocol, API, and tool needed to scale any DApp. Get Amoy MATIC Where can I learn to build DApps? Our Web3 documentation is the perfect starting point. It includes everything from smart contract tutorials to APIs and recipes. Here’s a quick glossary to get you started: What is a faucet? A faucet is a developer tool that provides testnet tokens for testing smart contracts or DApp interactions on test networks. Our Chainstack faucet supplies you with Amoy testnet MATIC for testing your smart contracts before production. What is the Amoy testnet? Amoy is a public Polygon testnet, designed for testing decentralized applications, smart contracts, and other EVM functionalities. What does ‘drip’ mean in the context of Web3 faucets? In faucet terminology, a drip is the amount of testnet tokens received daily. For our faucet, it’s up to 1 Amoy Testnet MATIC per day. What are Amoy testnet MATIC tokens? Amoy testnet MATIC tokens are used as gas fee tokens on the Amoy testnet. While these tokens hold no real monetary value, they are crucial for deploying and interacting with smart contracts on the testnet. Have more questions? Join our Telegram or Discord communities to speak directly with our team members. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ankr RPC provider overview (2026) In the Web3 world, your RPC provider is the quiet backbone, moving every on‑chain read and write between your app and the networks you support. Ankr homepage Whether you’re shipping a dApp, running an analytics pipeline, or powering a wallet, providers like Ankr give you production endpoints, multi‑chain coverage, and performance. Ankr offers: a global RPC platform, Node API for standard JSON‑RPC, Advanced API for pre‑indexed, multi‑chain queries, WebSockets and gRPC options and per‑method, pay‑as‑you‑go pricing via API credits. Premium unlocks higher limits, private endpoints, debug/trace, and whitelisting. If you prefer granular usage billing and want indexed endpoints in the same console, Ankr is a solid fit, just keep an eye on method mix and rate limits. Brief history of Ankr Ankr has been around since 2017 as a Web3 infrastructure company focused on node access, APIs, and related services. Today it positions its network as a DePIN. It’s a decentralized physical infrastructure network, serving billions of requests daily across 30+ regions. Core Ankr RPC products & services Service plans. You choose among Public, Freemium, Premium, and Enterprise. Public gives free, rate‑limited endpoints; Freemium adds 200M monthly API credits while still using Public rate limits; Premium unlocks private endpoints and higher limits. Coverage & features by plan. Ankr lists 40+ chains on Public, 65+ on Freemium, and 80+ on Premium. All tiers include full and archive data. Premium adds debug and trace namespaces, WebSockets, team accounts, and multi‑project stats. Node API. Standard JSON‑RPC access across EVM and non‑EVM chains with both HTTPS and WSS on paid plans. Advanced API. A curated set of pre‑indexed JSON‑RPC methods with SDKs for JS/Python and React hooks. Useful when you’d rather query ready‑made endpoints than stitch raw RPC. Global footprint. Ankr markets a globally distributed, bare‑metal‑heavy footprint and highlights 30+ global regions as part of its DePIN. Ankr pricing profile Ankr uses a per-method pricing model based on API credits rather than simple request counts. Different RPC methods consume different amounts of credits, and WebSocket subscriptions and event notifications are also metered. Ankr offers Freemium and Premium tiers, as well as prepaid “Deal” credit bundles. In practice, this means costs depend heavily on your method mix and event volume, especially if your workload includes logs, filters, or high-frequency calls. The example below shows how a typical workload translates into API credit usage and monthly cost compared to request-based pricing. Ankr Pricing per request MetricChainstackAnkrPlan used in exampleProPremium (Deal)Included usage80M Request Units6B API CreditsWorkload equivalent73.5M method calls73.5M method callsCredit usage (example workload)Fits in included usage~14.7B API CreditsPlan price$199$500Overage charges$0$870Total monthly cost$199$1370 In this example, the same workload that fits within Chainstack’s included usage generates significant API credit consumption on Ankr, resulting in additional overage charges on top of the subscription plan. For smaller workloads, credit-based pricing can work well and scale gradually. However, for production workloads with heavy reads, logs, filters, or WebSocket events, forecasting costs becomes more difficult because pricing depends on method-level credit consumption rather than request volume. See the full cost comparison → Strengths vs potential weaknesses StrengthsPotential WeaknessesBroad chain coverage on Premium with both HTTPS and WebSockets supportPer-method, usage-based pricing can cause cost drift if method mix or event volume changesOffers Advanced API with pre-indexed, multi-chain endpointsMany useful features sit behind PremiumStrong global footprint with 30+ regions and emphasis on bare-metal deploymentsPublished RPS/RPM numbers vary and depend on real-world load, requires your own benchmarkingTeam accounts, IP/domain/contract whitelisting, and multi-project stats improve governanceFreemium rate limits are restrictive; Advanced API limits are much lower without Premium Ankr vs Chainstack Both aim to deliver high‑performance, multichain RPC with enterprise‑minded features. Here are the practical differences most teams care about: Pricing model Ankr: per‑method, usage‑based pricing via API credits; optional monthly “Deal” packs (pre‑purchased credits). Good if you want granular costs that scale linearly with calls. Chainstack: classic request‑unit plans and an Unlimited Node add‑on offering flat monthly fees by RPS tier, no per‑request charges. It’s useful when you want absolute cost predictability under sustained load. Features & tooling Ankr: Premium unlocks debug/trace, WSS, whitelisting, and multi‑project stats; Advanced API gives indexed, cross‑chain data in the same console. Chainstack: offers Global Node, Dedicated Node, and Unlimited Node; supports debug/trace and publishes docs and tooling for it; provides access rules. Coverage & footprint Ankr: lists 80+ chains on Premium and markets 30+ regions with bare‑metal presence. Chainstack: advertises support for 70+ chains across products and provides options like archive data and Solana gRPC streaming. Start building with Chainstack If predictable spend is your priority, turn any node into an Unlimited Node and pay a flat monthly fee by RPS tier, no per‑request billing, including archive and debug/trace. It’s a clean way to de‑risk cost while you scale. Try Chainstack with predictable RPC pricing → FAQ How do I get started with Ankr? Sign in to the Web3 API console, pick Freemium/Premium, create a Project to generate your API key, optionally add IP/domain/contract whitelists, then point your app at the private endpoint (HTTPS/WSS). What chains and methods does Ankr support? Public shows 40+, Freemium 65+, and Premium 80+ chains. Support varies by chain, but Premium unlocks debug and trace for EVM families, with both HTTPS and WSS. How predictable is cost with Ankr? It’s per‑request and per‑event by method. Batch where possible and prune WSS subscriptions to stay efficient. #### Announcing the community developer hub program TL;DR: Beef up your Web3 portfolio by getting published at Chainstack. Earn the Web3 cred. Talk to other developers. Get paid. Check out the Chainstack developer hub page. What is the developer hub program? In short, you create a full technical tutorial on how to do useful or fun things on blockchain networks using the supported protocols. The tutorial should preferably be complete with a GitHub repository. Then you get published at the Chainstack blog under your account and get your tutorial promoted by Chainstack to thousands of developers building with Chainstack. And you get paid too. It’s a win-win collaboration between you and Chainstack. Benefits for you: Work with experienced Chainstack Web3 developer advocates.Get known in the community. (Don’t wait, join our Discord now).Once published, your tutorial will be promoted.Get the Web3 portfolio by having a reviewed and polished tutorial at Chainstack—a full blockchain company.Get paid. Benefits for us: Keep a thumb on the Web3 development pulse.Help promote and elevate the Web3 talent.Onboard new developers into the Web3 space. For examples, see the tutorials section of our blog. What topics are we looking for? Pretty much anything that’s fun and educational and involves using a blockchain node of the currently supported protocols. That said, here’s a very broad list of categories if you need help in focusing on: Wallets & stakingExchanges: DEX, CEXTrading & arbitrageWeb3 developer platformsNFTs: markets, creators, game artifactsDecentralized identityNaming services: for example, ENSDAOs & votingFunding, launchpads & investmentsReward systemsSupply chainOn-chain & Oracle analyticsPlay & earn, aka P2E, aka GameFiSocial networks & messengersDistributed computing & overlay networkingDecentralized storageL1 & L2 chains, Polygon supernets, Avalanche subnets What is the publication process? Join our Discord for communication. Make yourself known in the COMMUNITY > #developer-hub channel specifically. Submit your proposal by following the guidelines. We’ll evaluate and start working with you. Once you submit your draft, our experienced team of developer advocates and technical copywriters will work with you to make your content and code the most polished, expertly, and presentable. The final version will be published at the official Chainstack blog and promoted. What is the payout process and structure? Total of $300 per published piece. The payout structure is: A fixed reward of $200.A bonus reward of $100. The payout will be processed through Request Network in USDC. Have more questions? Talk to us on Discord now. Check out the Chainstack developer hub page. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Announcing unlimited free access to Ethereum nodes TL;DR: Chainstack is excited to be announcing that as of Monday October 7 2019, we’re making unlimited access to shared Ethereum nodes completely free at every subscription tier. That means you get: Unlimited requests to Ethereum networks.No throttling or rate limiting.Decentralized nodes across multiple cloud providers.Predictable stability and uptime.All 100% free. High speed development on infrastructure you can trust The number of developers building on Ethereum and other public chains is increasing every day, with Ethereum having 4x the number of developers than the next biggest ecosystem and new use cases for decentralized applications consistently appearing. The community is only growing and the team at Chainstack has enjoyed being along for the ride. We’ve always believed that building the new era of applications on Web 3.0 should be easy, without the need to run and maintain your own hardware. So while managed infrastructure is nothing new for us, we want to make it accessible to more people, which is why this week at Devcon 5 we’re announcing a small but significant change to our subscription plans: we’re giving developers unlimited access to build on Ethereum networks (with other public chains like Bitcoin coming soon), completely for free. Free, distributed, unlimited access Unlimited access means no ceilings on the number of requests that can be made and no throttling or rate limiting. Plus, with full access to the node’s native API, you can investigate transactions deeper and more transparently. On top of it all, Chainstack lets developers select from a number of nodes across a growing list of different cloud providers. That means you can test and choose what works best for you to get the results you need, whether you’d rather deploy on GCP, AWS or somewhere else. Meanwhile, we do our part to ensure that the network remains distributed, with our nodes deployed across clouds and regions. Scale your infrastructure Need to go beyond a shared gateway and are looking for the kind of high-volume capacity that comes with running your own node? You can upgrade your Chainstack plan at any time to deploy your own dedicated, high performance node, which can be spun up and fully synced with the network in minutes rather than days or weeks thanks to Chainstack’s Bolt technology. See our pricing plans for more information. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### ApeX Pro x Chainstack: DAC and failsafe fund retrieval mechanism Fostering reliability and trust in high-performance cross-chain trading with StarkEx Our collaboration with Chainstack has been significant, fortifying ApeX Pro’s security and reliability while enhancing user trust. Chainstack’s role in the DAC service offers robust contingency measures and reaffirms user autonomy in transactions. We appreciate their commitment to our shared vision and are glad to have them on board. Mariam I, Head of Marketing, ApeX Protocol In the dynamic landscape of cryptocurrency trading, the hunt for speed, security, and efficiency is endless. As traders increasingly opt for decentralized platforms, offering them an optimized trading experience is imperative. This is where ApeX Pro stands as a beacon of innovation. Here at Chainstack, we are fortunate to work closely with some of the most inventive companies in Web3 and the trading vertical is no exception. Our collaboration with decentralized derivatives trailblazer ApeX Pro proves just that. Let’s explore in detail what ApeX Pro brings to the table and examine Chainstack’s role in making it happen: What is ApeX Pro? Set as a shining example in the vibrant world of decentralized finance, ApeX Pro presents a trading platform that is non-custodial in nature and brings forth permissionless cross-margined perpetual contracts to its community. The platform is built on the ethos of unlimited access to the perpetual swap market and adheres to a potent order book model, reinforcing speed, efficiency, and most importantly, a commitment to transparency in executed trades. As an integral part of its financial toolset, ApeX Pro also extends staking and market-making products to its community. These avenues open up the possibility for users to generate passive income in USDC. The integration of these products into the platform’s ecosystem not only broadens the avenues for income generation but also embodies ApeX Pro’s commitment to creating real value for its users. Building a multi-chain precision trading DEX Beyond offering a selection of intuitive and transparent financial tools to the crypto community members from all backgrounds, the ApeX team stays committed to their vision of a responsive ecosystem. They foster an environment that encourages an influx of such users, enabling a seamless entry into the world of DeFi while facilitating their participation in decentralized trading. Here’s how they accomplish this: Non-custodial trading: ApeX Pro’s non-custodial trading empowers its users to assume complete control over their assets throughout the entire transaction course. This mechanism liberates traders from reliance on a custodian, thus ensuring autonomy over their finances. Private trading experience: Lacking KYC procedures allows ApeX Pro traders to uphold their privacy as they transact, which helps bolster the core ethos of blockchain technology, promoting transparency and fair trades. Gatekeeper-free trading: The permissionless trading setup of ApeX Pro eradicates barriers and gatekeepers, meaning users can trade freely from any part of the world. This encourages global participation and evenly spread opportunities. High-velocity transactions: Apex Pro features high transaction speeds, allowing for up to 10 trades and 1 000 order placements and cancellations per second, so traders can stay ahead of the market and capitalize on opportunities swiftly. Robust privacy safeguards: By integrating zero-knowledge (ZK) proofs and Validium, ApeX Pro shields the transactions of its users from prying eyes, while ensuring the highest level of security for maximum trading confidence. Generous incentive programs: ApeX Pro rewards traders via Staking, Market Making, and the Trade to Earn programs. Since last November, the year-long Trade to Earn campaign has been rewarding active traders with $190K worth of weekly rewards in $BANA for trading any market pair a week prior. Trustless trading transparency: To enable autonomy and control during platform interactions, ApeX Pro makes it possible for users to authenticate their trades, and maintain an indisputable record of transactions. Affordable fee structure: Traders can capitalize on the benefit of affordable trading with ApeX Pro, which features a minimal fee of 0.02% for makers and 0.05% for takers, so they can optimize their returns in a cost-efficient trading environment. Reforming decentralized trading with StarkEx To enact their grand vision of a multi-chain permissionless DEX engineered for high-performance trading, the ApeX team needed the appropriate architecture to support such an endeavor well. After evaluating the pros and cons of the available options, their search eventually led them to StarkEx. This layer 2 scalability engine developed by StarkWare features support for large-scale applications, self-custody, fast withdrawals, multi-asset trading, real-time oracle price feeds, and Validium. In turn, this made it the perfect choice to realize the ApeX team’s vision of exceptional trading performance, robust liquidity, market depth, and transparency during interactions. ApeX Pro effectively leverages StarkEx ZK proofs and Validium in validating batches of non-custodial transactions. Not only does this greatly improve trading efficiency but also elevates user experiences and engagement. And to help ApeX get the absolute max from their StarkEx integration, our team at Chainstack stepped up to the challenge. Establishing a StarkEx Data Availability Committee For us at Chainstack, it was an absolute honor to partner with ApeX Pro on their mission to integrate StarkEx. To help accomplish this, our collaboration focused on running a Data Availability Committee (DAC) service for their StarkEx instance. The DAC allows users to bypass reliance on StarkEx Operators in servicing withdrawal requests in case of emergency. In such instances, the Application Smart Contract (ASC) halts new state updates and allows only direct user withdrawals with valid Merkle proof for the latest state. As a member of the ApeX Pro DAC, Chainstack plays a critical role in ensuring the transparency, security, and reliability of the platform’s operations. Under normal conditions, our responsibilities include: Receiving each state transition, computing the new state, and signing the commitment to the new state. Maintaining a private and secure copy of this off-chain data. Verifying the acceptance of a STARK proof based on a corresponding state commitment. In a highly unlikely but emergency scenario, if ApeX Pro is unable to service withdrawal requests, Chainstack steps in to help their users regain access to their funds without having to trust the platform’s ability to do so. Specifically, in such cases, our team would take the following course of action: Make our secure copy of the off-chain data publicly available. This would enable users to access the Merkle path linked to their accounts. Facilitate users in retrieving their funds directly from the ASC using the provided Merkle path. Overall in essence, Chainstack provides a failsafe mechanism and an additional layer of trust and security for ApeX Pro users, offering a path to retrieve their funds even in the case of the platform missing or being unable to do so. Resolution summary Enhanced transparency and security: Our collaboration with ApeX Pro, integrating StarkEx and running the DAC service, has amplified user trust in the platform by offering a failsafe mechanism for fund retrieval. Reliability assurance: As a DAC member, Chainstack ensures consistent and secure operation of the ApeX Pro platform under normal circumstances, managing state transitions, maintaining off-chain data, and verifying STARK proof acceptances. Robust contingency measures: In emergency scenarios where withdrawal requests cannot be serviced by ApeX Pro, Chainstack steps in to make off-chain data publicly available, facilitating direct fund retrieval by users from the ASC using the Merkle path linked to their accounts. Reinforced user autonomy: Our role as a DAC member allows ApeX Pro users to bypass reliance on platform operators in emergencies, ensuring a seamless and trustworthy transaction process, and reaffirming our shared commitment to offering reliable and transparent solutions. Bringing it all together Navigating the rapidly-evolving landscape of cryptocurrency trading demands a relentless pursuit of speed, security, and efficiency. Decentralized platforms like ApeX Pro stand at the forefront of these advancements, aspiring to provide an optimized trading experience for their users. By partnering with ApeX Pro, contributing to their integration of StarkEx, and establishing a DAC, we are proud to play an integral part in this forward-thinking initiative. Our shared efforts have yielded notable improvement in transparency, security, and overall reliability of the ApeX Pro platform. As a member of the DAC, we ensure the efficient operation of the platform under regular conditions and provide robust contingency measures to deal with any emergencies. In doing so, we strengthen the autonomy of ApeX Pro users, allowing them to bypass platform reliance, thus asserting our mutual commitment to reliable, user-centric solutions. The integration of StarkEx into ApeX Pro’s infrastructure and the formation of the DAC are pivotal steps toward a future of frictionless, autonomous, and secure decentralized trading. With these developments, ApeX Pro fortifies its position as a beacon of innovation across the DeFi vertical, with Chainstack by its side, providing robust infrastructure and exceptional support. Together, we look forward to continuing our journey in fostering the progress of the blockchain landscape. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### APY.vision on Chainstack: Bringing DeFi analytics to the masses APY.vision is a DeFi analytics manager that helps users to track their transactions on dozens of DeFi platforms, as well as understand their profits and losses. The platform tracks the gains of its users across a variety of liquidity pools and yield farms to maximize their returns. What is APY.vision? The goal of the APY.vision platform is to aggregate and index DeFi analytics data, essentially providing a historical profit and loss breakdown for its users. In turn, this allows users to track their gains and impermanent loss, which is key for an adequate profitability overview to maximize returns. In layman’s terms, the DApp’s goal is to help users identify the most profitable opportunities before others and the best times to enter or exit. This is made possible by APY.vision’s ability to monitor vault, pool, farming, and AMM activities, calculate net profits, and compare pool performance by APY, impermanent loss, and collected fees. And while this is great already, the DApp also offers additional premium functionalities like real-time price data and advanced pool searches that are sure to make your experience even smoother! At present, the APY.vision platform supports as many as 11 chains and even more protocols, the full list of which you can find here. Because of its wide cross-chain interoperability and powerful feature set, the DApp has effectively managed to garner over 70 000 users on its platform, while tracking billions of dollars worth of user assets across the DeFi landscape. How did APY.vision come across Chainstack? Considering APY.vision’s extensive multi-chain coverage, their development team was looking first and foremost for a robust RPC node provider to support the resource-heavy operations that are a given when querying historical user data. But to be truly successful in this endeavor, the APY.vision team needed above anything else a provider that could offer up-to-par performance across all of the DApp’s supported protocols. After doing their due diligence in researching and comparing their potential options to reach the goals they sought to complete, the platform’s development team eventually came across Chainstack. And in the end, it was Chainstack’s exceptional performance across a multitude of top protocols that made them take the ultimate choice. How does Chainstack’s offer match APY.vision needs? Having the above-mentioned factors that the APY.vision development team was looking to answer in mind, they saw Chainstack as a perfect match for their needs, especially in terms of cross-chain availability. Even so, it was the enterprise-grade performance of any node deployed on the Chainstack platform and the exceptional uptime offered that sealed the deal between us. Thanks to Chainstack’s wide multi-chain support, the APY.vision team was able to extend support swiftly and securely to exactly what their customers needed the most. And as icing on the cake, the versatility and flexibility of Chainstack’s subscription packages ensured APY.vision was receiving what they were paying for and more, given their budget and needs. Outcome The APY.vision saw little need to interact with our team to help solve any mishaps in the integration process of our reliable infrastructure services. Thanks to the seamless and intuitive Chainstack platform interface, their development team enjoyed a smooth-sailing experience, which got them from testing to market both swiftly and securely. What does APY.vision like about Chainstack? Chainstack offers support to an extensive range of networks that our users prefer and are currently on. Their RPC nodes are stable and perform well, which is why we recommend them for their services. Tom Chan, Founder and Core Developer, APY.vision What does Chainstack like about APY.vision? Navigating the DeFi space, while keeping an adequate birds-eye perspective over the profitability of your efforts is still quite a rare sight across the landscape. We are thrilled to support avant-garde use cases, like that of APY.vision, as they are essential for the healthy functioning of DeFi as we know it. Eugene Aseev, Founder & CTO, Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Arbitrum Nitro: An overview What is Arbitrum Offchain Labs’ Arbitrum One is a Layer 2 (L2) scaling solution for Ethereum, introduced in 2021. Arbitrum aims to lower transaction fees and increase its ability to process thousands of transactions per second, like any scaling solution. It moves contract computation and storage from Ethereum’s primary chain, enabling significantly better throughput. Transactions on Arbitrum only cost a few cents to complete. Despite being a separate blockchain, it uses Layer 1 (L1) security and privacy features and relays all transaction information to the main Ethereum chain. Furthermore, it is effortless for developers to integrate Arbitrum with no modifications because it supports the Ethereum Virtual Machine (EVM). How Arbitrum works Developers create smart contracts and submit transactions to the Arbitrum chains’ inboxes. After processing it, Arbitrum generates a transaction receipt. The transactions in Arbitrum’s inboxes impact how it handles the transaction and hence its chain state. Arbitrum handles Ethereum transactions using a technique known as an optimistic rollup. Rollups significantly increase processing speeds by moving many transaction data off-chain. However, unlike other sidechains, optimistic rollups still publish a small amount of data on the decentralized layer one network to be validated, increasing security.   Optimistic rollups do not publish proofs of validity for transaction batches posted on-chain since they presume off-chain transactions are valid. This characteristic separates optimistic rollups from zero-knowledge rollups that print cryptographic proofs of validity for off-chain transactions.  Arbitrum Nitro Arbitrum launched Nitro on August 31. Nitro is a significant technical upgrade for Arbitrum meant to be more EVM-compatible, create a better experience for users, lower the fees, and speed up the transactions. Nitro is a new prover that can do Arbitrum’s classic interactive fraud proofs using WebAssembly (WASM) code. Nitro vs Classic If we zoom out a little, we can see that both classic and Nitro perform a similar thing: seek to establish an execution environment as close to the EVM as possible, which acts as a second layer to Ethereum.However, unlike Classic, Nitro uses WebAssembly instead of AVM for low-level instruction. It compiles the Go code to WASM, implements to the ArbOS, and includes the most widely utilized Ethereum implementation within the Geth. Classic achieved compilation via a custom-made virtual machine named AVM (Arbitrum Virtual Machine). One of the most crucial characteristics distinguishing Nitro from Classic is architecture.The AVM (Arbitrum Virtual Machine) connects to the bridge and regularly validates the validity of the transactions between L1 and L2. ArbOS ArbOS is the operating system that runs on an Arbitrum chain at Layer 2 to govern the chain’s operation, smart contract lifecycles, security, and other functions. Offchain Labs also upgraded ArbOS, rewritten in the Go programming language. The updated version will enhance cross-chain communication between Layer 2 (Arbitrum) and Layer 1. (Ethereum). The other advantage of Nitro is its direct usage of Geth. It means most of the work of creating an L2 VM is inherited right out of the box. Nitro migration for DApps This section is for Solidity developers who want to migrate their DApp to Arbitrum Nitro. So let’s first talk about some advantages of moving your DApps to Nitro.  Ethereum L1 Gas compatibility: the gas price for all EVM operations is precisely in line with Layer 1.  Calldata compression: since compression in Nitro occurs at the protocol level, DApps don’t need to make any changes.  Supports All Ethereum precompilers: all Ethereum L1 precompilers, including ripemd160, blake2f, and others, are supported by Arbitrum Nitro.  Frequent timestamps: Timestamps that can be accessed via block.timestamp have been decoupled from the timestamp of the previous Layer 1 block and are updated every block.  There are a few breaking changes for RPC, protocols, and DApps.  There is no longer the concept of a separate pool for storing gas.  Reduced maximum contract code size: Previously, contracts up to 48KB could be deployed, but now they can only be up to 24KB.  How Arbitrum Nitro works Since the previously mentioned Arbitrum Nitro is compiled to WASM, the current custom-designed language and compiler can be replaced with standard languages and tooling for building and compiling the entire system instead of Arbitrum Classic’s AVM architecture.  And to provide cross-chain communication and reduce the L1 expenses, the Offchain Labs are rewritten ArbsOS components in Go. They also have a new and enhanced batching and compression scheme.   According to the docs, the core of Nitro and its major innovations are based on four major concepts.  Sequencing: Nitro developed two methods to process transactions. First, a single ordered sequence is created out of all the transactions, and Nitro commits to that sequence. A deterministic state transition function then processes the transactions in that order.  Geth: By including the core code of the go-Ethereum (Geth), Nitro supports Ethereum’s data structures, formats, and virtual machines. This method of using Geth as a library assures very high levels of compatibility with Ethereum.  Separate Proving from Execution: Nitro takes the same source code and compiles it twice, once to native code for use in proving, which is designed for portability and security, and again to WASM for use in execution on a Nitro node, which is optimized for speed.  Optimistic Rollup: Using an optimistic rollup protocol with Arbitrum’s interactive fraud proofs, Nitro settles transactions to the Layer 1 Ethereum chain.  The processing of transactions in Nitro is illustrated in the below figure.  On the client level, there are no pending transactions and no txpool. The transactions get immediately accepted or rejected by the sequencer. Running a node You can either run your node or use Chainstack. Running your node can be both difficult and costly.   Using Arbitrum Nitro on Chainstack is just as easy as it is to launch any other node on the platform: Log in to the Chainstack console. Select a cloud provider. Deploy the node in any preferred global location with low latency. This allows developers and enterprises interested in building on Arbitrum Nitro to deploy, run, and manage all the nodes they’ve launched within a single, seamless platform. With Chainstack’s help running blockchains at scale becomes truly effortless for any project, regardless of its use case or size. Deploying a sample contract on the Arbitrum Goerli testnet To summarize everything in this post, let’s deploy a contract on the Arbitrum Goerli testnet.  First, let’s add the Arbitrum Goerli testnet network to our wallet provider. In this case, we’ll use MetaMask.  Network Name: Arbitrum Nitro Goerli testnet  RPC URL: Get one with Chainstack. ChainID: 421613  Symbol: GoerliETH  Block Explorer URL: https://testnet.arbiscan.io/ Then request some Goerli ETH from the goerli faucet. Once received, bridge it to the Arbitrum Goerli testnet using the official bridge from the Arbitrum Nitro testnet. Once confirmed, it will take approximately 15 minutes to bridge the tokens.  If everything goes well, now you should have your bridged GoerliETH on the Arbitrum Goerli testnet. After that, let’s begin working on our contract. First, create a new project folder, and start a new Truffle project. We will also use the @truffle/hdwallet-provider package. mkdir arbitrum-nitro-adoption && cd arbitrum-nitro-adoption truffle init npm I @truffle/hdwallet-provider Then, inside the contracts folder, create a new Adoption.sol contract. This contract will allow an account to adopt a new pet and name it.  // SPDX-License-Identifier: MIT pragma solidity ^0.8.15; contract Adoption { event PetAdopted(uint256 petIndex, string petName); uint256 totalAdopted; mapping(uint256 => string) petName; mapping(uint256 => address) petOwner; function adopt(string memory _petName) public { petName[totalAdopted] = _petName; petOwner[totalAdopted] = msg.sender; totalAdopted++; emit PetAdopted(totalAdopted - 1, _petName); } } Now, let’s prepare the Arbitrum Nitro testnet in our truffle project for deploying the contract. Open the truffle-config.js file and paste the following content. const HDWalletProvider = require("@truffle/hdwallet-provider"); const DEPLOYER_PRIVATE_KEY = ""; const CHAINSTACK_NITRO_TESTNET_RPC = ""; module.exports = { networks: { "nitro-goerli": { provider: () => new HDWalletProvider( DEPLOYER_PRIVATE_KEY, CHAINSTACK_NITRO_TESTNET_RPC ), network_id: 421613, }, }, // Configure your compilers compilers: { solc: { version: "0.8.15", // Fetch exact version from solc-bin (default: truffle's version) }, }, }; Be sure to use your own private key to deploy it. After that check, under the migrations folder, create a new file called 2_deploy_contract.js and setup the deployment instructions:  const Adoption = artifacts.require("Adoption"); module.exports = function (deployer) { deployer.deploy(Adoption); }; Once all is settled, run the migrations to deploy the contract. truffle migrate --network nitro-goerli Once the deployment gets done, you should an output like this.  And that’s it! We’ve succesfully deployed a contract to the Arbitrums Nitro Goerli testnet.  Conclusion   The purpose of this post was to provide you with an overview of the Arbitrum Nitro, how it works, and the difference between Nitro and Classic. More about Arbitrum and its mechanism will be covered in upcoming posts.   Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Arbitrum vs Optimism RPC: which L2 for production A practical comparison of Ethereum’s two largest optimistic rollup ecosystems, covering architecture, transaction flow, performance, RPC infrastructure, and developer tooling for teams deploying production applications at scale. TL;DR A production application on Ethereum scaling infrastructure is rarely limited by smart contract design or backend architecture. These layers have become increasingly standardized. The more consequential choices are structural, and they get locked in early — including which L2 to build on. This is where the choice between Arbitrum and Optimism becomes important to understand. Both are mature optimistic rollups and fully EVM-compatible, but differences in their infrastructure, sequencing, fees, and tooling decide where early meaningful usage is most likely to emerge. The real difference extends beyond the protocol. It shows up in how each ecosystem channels early adoption, how liquidity concentrates, and how applications scale. Over time, these “small” infrastructure decisions compound — shaping your app’s growth and user adoption. Prerequisite Basic understanding of Ethereum No prior experience with Layer 2s required What is an L2? Rollups are Layer 2 scaling solutions that increase the transactions per second (TPS) on Ethereum without proportionally increasing gas costs. Rather than executing all transactions directly on Ethereum mainnet, Layer 2 networks process transactions off-chain, bundle them into batches, and periodically publish transaction data and state commitments back to Ethereum. There are two types of rollup: Optimistic rollups: assume transactions are valid by default unless challenged with a fraud proof Zero-knowledge rollups: prove correctness upfront using cryptographic validity proofs. Learn more about zkEVM and zkRollups All users on L2s pay a single gas fee that is composed of: L2 execution cost: for compute, storage, and EVM gas. It is much cheaper than L1 because it is not being executed by every Ethereum validator L1 data cost: for posting transaction data and state roots to Ethereum Sequencer fee When Ethereum gas prices increase, overall L2 fees increase as well. Upgrades like Fusaka help offset these costs by increasing blob capacity and reducing the cost of posting data to Ethereum. 📖 The Ethereum Fusaka upgrade bundles multiple EIPs to improve rollup scalability by increasing blob capacity and improving data availability. For a deeper breakdown, explore the Ethereum Fusaka Upgrade article. This is what makes Ethereum scalable without giving up security. Layer 2s focus on increasing TPS, while Ethereum Layer 1 focuses on security and data availability. Arbitrum vs Optimism Arbitrum and Optimism are among the largest Layer 2 ecosystems today, both built using optimistic rollup technology. Network metrics Optimism is built on one of the largest growing ecosystems of chains through the Superchain, providing shared standards and interoperability from day one, while inheriting Ethereum’s security and liquidity alongside operational flexibility. Arbitrum provides a custom execution layer for the programmable economy, enabling scalable Ethereum apps with lower costs, faster settlement, and flexible onchain design space through Orbit. Arbitrum One has processed over 2.7 billion transactions, while Optimism has processed 1.2 billion transactions since its inception. Source: tokenterminal.com/explorer/projects/optimism As of June 22, 2026, Optimism leads in cumulative unique addresses with approximately 406.5 million distinct addresses, while Arbitrum has approximately 84.9 million distinct addresses. Source: arbiscan.io (Arbitrum) Source: optimistic.etherscan.io (Optimism) While revenue is competitive between the two networks, Arbitrum leads in cumulative revenue with approximately $139.1 million generated over time, compared to approximately $117.7 million for Optimism. Source: tokenterminal.com/explorer/projects/arbitrum Both networks are L2Beat Stage 1, meaning fraud proofs are permissionless and third parties can challenge invalid state roots without team permission. Source: l2beat.com Although both platforms use optimistic rollups, they each offer distinct features catering to various needs within the Ethereum ecosystem. Architecture 🤔 Already familiar with both? Jump straight to the Which is the better L2? section below to choose the right one for your production app. Optimism is built around a simple principle: stay as close to Ethereum as possible. OP Stack nodes: a modular set of services. op-reth handles EVM execution, op-node reconstructs L2 state from Ethereum data, op-batcher handles data availability by posting transaction batches to L1 (or alternative DA), and op-proposer submits L2 state roots to L1 Modular architecture: execution, sequencing, data availability, and proving are separated into independent components Superchain vision: multiple OP Stack chains share standards, infrastructure, and interoperability guarantees The result is a rollup ecosystem optimized for Ethereum compatibility, shared standards, and long-term interoperability. For a more modular, flexible architecture, op-geth is deprecated. op-reth, purpose-built for the OP Stack, provides faster sync times, lower hardware and memory costs, and higher transaction throughput (TPS) without the garbage-collection overhead of Go. Arbitrum prioritizes efficient verification on Ethereum. Nitro node (arb-node): a single integrated node that handles execution, sequencing feed processing, L2 state management, and RPC interfaces Validators: monitor state transitions and can challenge invalid execution through fraud proofs Sequencer: orders transactions and produces L2 blocks before settlement on Ethereum Interactive fraud proofs: disputes are narrowed down to a single instruction before Ethereum verifies the result WASM-based proving: Nitro compiles the state transition function into WebAssembly for efficient verification Orbit ecosystem: developers can launch custom L2s and L3s while inheriting Arbitrum’s settlement and fraud-proof infrastructure The result is a rollup ecosystem optimized for verification efficiency, scalability, and customization. Transaction lifecycle Production apps require dependable RPC infrastructure. A dedicated provider such as Chainstack gives developers consistent transaction submission, lower latency, and better observability than public endpoints, making it easier to track transactions throughout their lifecycle on both Arbitrum and Optimism. OP Mainnet User submits to op-reth via JSON-RPC → sequencer picks up and orders L2 block created (soft finality, ~2 seconds) op-batcher posts L2 transaction data to Ethereum Batch Inbox op-proposer posts state root to OptimismPortal 7-day Cannon fault proof window Ethereum-finalized state → hard finality Arbitrum One User submits via sequencer RPC → sequencer orders and executes the transaction eth_sendRawTransaction returns only after the block is created (soft finality, ~1–2 seconds) Sequencer batches and compresses transactions → posts to Ethereum 7-day BOLD challenge window Ethereum-finalized state → hard finality Both networks deliver sub-2-second soft confirmation and 7-day withdrawal periods. For most application logic, soft confirmation is sufficient. For withdrawal and bridge flows, the 7-day window is the binding constraint on both chains. Transaction fees For many users, transaction fees are one of the most important metrics when choosing a Layer 2. Optimism has prioritized simplicity through a single-round fault-proof architecture. In the rare event of a dispute, this can result in higher L1 verification costs because more computation is settled directly on the base layer. Arbitrum’s multi-round interactive dispute protocol narrows disagreements step-by-step, requiring less computation to be executed on Ethereum. This approach helps keep verification costs low and contributes to Arbitrum’s long-term gas efficiency. That said, the introduction of EIP-4844 has reduced data availability costs for both networks, bringing transaction fees much closer together than in previous years. For everyday activities such as token transfers, swaps, and DeFi interactions, users will find both networks inexpensive to use. Fees are no longer the primary differentiator between the two chains. Ecosystem depth, liquidity, and infrastructure tooling are the relevant decision factors. RPC infrastructure Arbitrum and Optimism both expose Ethereum-compatible JSON-RPC interfaces, which means applications interact with them in the same way as Ethereum L1. Arbitrum Arbitrum exposes a fully Ethereum-compatible JSON-RPC interface. Under the hood, Nitro integrates execution, state management, sequencing, and JSON-RPC into a single node implementation. Production RPC through Chainstack provides access to Arbitrum One with JSON-RPC methods, WebSocket connectivity, archive infrastructure, and Stylus tracing. Arbitrum RPC is available on both Mainnet and Sepolia. Chain ID: 42161 Mainnet: https://arbitrum-mainnet.core.chainstack.com Testnet: https://arbitrum-sepolia.core.chainstack.com Since Arbitrum exposes the standard Ethereum JSON-RPC interface, common methods work exactly as they do on Ethereum. For example, you can retrieve the latest block number using eth_blockNumber: const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify( {jsonrpc: '2.0', method: 'eth_blockNumber', id: 1} ) }; fetch('https://arbitrum-sepolia.core.chainstack.com/<KEY>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Production applications often rely on WebSocket connections for real-time updates such as new blocks, pending transactions, and contract events. Chainstack provides dedicated WebSocket endpoints for Arbitrum: wss://arbitrum-mainnet.core.chainstack.com ⚠️ The public Arbitrum RPC URLs do not support WebSocket connections. If your application requires subscriptions such as eth_subscribe or real-time event streaming, consider using a dedicated provider such as Chainstack. The following example subscribes to newly produced blocks using eth_subscribe: const WebSocket = require('ws'); const webSocket = new WebSocket('wss://arbitrum-mainnet.core.chainstack.com/<KEY>'); async function subscribeToNewBlocks() { const request = { id: 1, jsonrpc: '2.0', method: 'eth_subscribe', params: ['newHeads'], }; const onOpen = (event) => { webSocket.send(JSON.stringify(request)); }; const onMessage = (event) => { const response = JSON.parse(event.data); console.log(response); }; try { webSocket.addEventListener('open', onOpen); webSocket.addEventListener('message', onMessage); } catch (error) { console.error(error); } } subscribeToNewBlocks(); Archive-enabled infrastructure also supports advanced debugging (use debug_* for post-Nitro blocks) and tracing (arbtrace_* for pre-Nitro blocks) methods, such as Stylus tracking using the native stylusTracer. This tracer is for debugging Stylus contracts by tracing calls between the WasmVM and EVM, allowing developers to fully understand their Stylus transactions. stylusTracer is currently available on Arbitrum One mainnet. const url = "https://arbitrum-mainnet.core.chainstack.com/<KEY>"; const payload = { method: "debug_traceTransaction", params: [ "0x3c9329b765d88c03d18f87dc1f2b5138c89d9a415d5c73dc7827b87aca176c8e", { tracer: "stylusTracer" } ], id: 1, jsonrpc: "2.0" }; async function traceTransaction() { try { const res = await fetch(url, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(payload) }); const data = await res.json(); console.log(data); } catch (err) { console.error(err); } } traceTransaction(); Transactions are submitted to the Arbitrum sequencer through the standard eth_sendRawTransaction RPC method. The following example sends a signed transaction to the sequencer: curl https://arbitrum-mainnet.core.chainstack.com/<KEY> \ -H "Content-Type: application/json" \ -d '{ "jsonrpc":"2.0", "method":"eth_sendRawTransaction", "params":["0xsigned_tx"], "id":1 }' Once the sequencer accepts the transaction and includes it in an L2 block, the RPC request returns immediately. This provides soft confirmation within approximately 1 to 2 seconds, while Ethereum finality is reached after the challenge period. For a complete reference covering supported endpoints, authentication, archive access, WebSocket connectivity, and advanced RPC methods, see the Chainstack Arbitrum documentation. Optimism Optimism exposes the same Ethereum-compatible JSON-RPC interface that developers use on Ethereum, allowing existing tooling and applications to work without modification. Within the OP Stack architecture, both Global and Trader nodes run op-reth to execute transactions and serve RPC requests. Production RPC through Chainstack provides access to Optimism Mainnet and Sepolia, with support for archive workloads and WebSocket connectivity for production applications. Chain ID: 10 Mainnet: https://optimism-mainnet.core.chainstack.com Testnet: https://optimism-sepolia.core.chainstack.com Since Optimism implements the Ethereum JSON-RPC specification, common workflows such as reading chain state, subscribing to new blocks, and submitting transactions use the same RPC methods as Ethereum. const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({jsonrpc: '2.0', method: 'eth_blockNumber', id: 1}) }; fetch('https://optimism-mainnet.core.chainstack.com/<KEY>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Subscribe to Optimism WebSocket connections for real-time updates: wss://optimism-sepolia.core.chainstack.com ⚠️ Public Optimism RPC endpoints are intended for basic JSON-RPC access and are rate limited. Applications that rely on eth_subscribe, event streaming, or other WebSocket features should use a dedicated RPC provider such as Chainstack. Subscribe to real-time Optimism event logs using eth_subscribe: const WebSocket = require('ws'); const webSocket = new WebSocket('wss://optimism-sepolia.core.chainstack.com/<KEY>'); async function subscribeToNewBlocks() { const request = { id: 1, jsonrpc: '2.0', method: 'eth_subscribe', params: ['newHeads'], }; const onOpen = (event) => { webSocket.send(JSON.stringify(request)); }; const onMessage = (event) => { const response = JSON.parse(event.data); console.log(response); }; try { webSocket.addEventListener('open', onOpen); webSocket.addEventListener('message', onMessage); } catch (error) { console.error(error); } } subscribeToNewBlocks(); To enable debug and trace APIs on your Optimism node, deploy a global node with the debug & trace APIs enabled. Like Ethereum, transactions are submitted using the standard eth_sendRawTransaction RPC method. The request is forwarded to the Optimism sequencer, which orders and executes the transaction before including it in an L2 block. curl https://optimism-sepolia.core.chainstack.com/<KEY> \ -H "Content-Type: application/json" \ -d '{ "jsonrpc":"2.0", "method":"eth_sendRawTransaction", "params":["0xsigned_tx"], "id":1 }' Like Arbitrum, transactions are accepted by the sequencer first and only later posted to Ethereum for finalization after the challenge window. Explore the Chainstack Optimism documentation for a complete reference of supported RPC methods, endpoints, authentication, and archive features. Although both networks expose identical JSON-RPC methods, their RPC behavior differs at the infrastructure level. This difference affects how providers scale infrastructure, but not how developers interact with the API. Ecosystem The ecosystem surrounding a rollup often matters as much as the underlying technology. Liquidity, users, developer tooling, and application distribution all influence where new products gain traction. Arbitrum and Optimism approach ecosystem growth differently. Arbitrum focuses on deep liquidity and application-specific expansion through Orbit. Optimism focuses on cross-chain interoperability and infrastructure standardization across multiple OP Stack chains through the Superchain. Superchain Optimism’s ecosystem extends beyond OP Mainnet through the Superchain, a network of chains built on the OP Stack. The goal is to create a shared infrastructure layer where applications, assets, and users can move between chains using common standards. The Superchain includes OP Mainnet, Unichain, World Chain, Zora, Ink, Soneium, and other OP Stack deployments. Together, these networks process more than 16 million daily transactions, making the Superchain one of the largest Ethereum-aligned ecosystems by activity. As Superchain interoperability matures, participating chains gain access to shared messaging, common standards, and increasingly seamless asset movement. For developers, this creates a larger addressable user base without requiring entirely different infrastructure stacks for each deployment. Protocols on OP Mainnet: Velodrome: primary liquidity hub on OP Mainnet and the leading ve(3,3)-based DEX in the ecosystem Synthetix: one of the earliest large-scale protocols to adopt Optimism as its primary execution environment Aave V3: major lending market with significant liquidity and borrowing activity Uniswap V3: core liquidity venue used across the Ethereum ecosystem ether.fi: liquid staking and restaking infrastructure with a growing presence on OP Mainnet Exactly Protocol: fixed-rate lending and borrowing markets Beyond DeFi, Optimism hosts identity and attestation infrastructure such as Ethereum Attestation Service (EAS), while several Superchain members focus on consumer applications, creator economies, and social experiences. Superchain deployments: Unichain: built by Uniswap Labs with a focus on trading infrastructure and low-latency execution World Chain: designed around verified human users and consumer-scale onboarding Zora: creator-focused network optimized for NFT and media applications Soneium: developed by Sony Block Solutions Labs for entertainment and consumer experiences Orbit Arbitrum’s expansion strategy centers around Orbit, a framework for launching custom Layer 2 and Layer 3 networks using the Nitro stack. Orbit chains can settle to Arbitrum One or Ethereum and support a range of customization options, including alternative data availability layers, application-specific execution environments, and custom gas token models. This flexibility has attracted gaming networks, trading-focused chains, and application-specific deployments that require greater control over execution and infrastructure design. Notable Orbit deployments include XAI, Sanko, Degen Chain, and a growing number of application-specific chains. Protocols on Arbitrum: GMX: one of the largest on-chain perpetual futures exchanges and an early success story for Layer 2 derivatives Camelot DEX: native Arbitrum DEX focused on ecosystem liquidity and token launches Pendle Finance: leading yield tokenization protocol with significant activity on Arbitrum Radiant Capital: cross-chain lending and borrowing markets Dolomite: margin trading and advanced lending infrastructure Arbitrum has also become a destination for institutional and real-world asset initiatives. Robinhood selected Arbitrum as the infrastructure layer for tokenized stocks, ETFs, and commodities. Converge, developed by Ethena Labs and Securitize, brings large-scale dollar-denominated assets and tokenized financial products into the Arbitrum ecosystem. LG Electronics recently partnered with Arbitrum to build blockchain infrastructure for its onchain advertising network. The ecosystem differences between Arbitrum and Optimism influence where applications find users and liquidity. Arbitrum’s strengths are concentrated around trading, derivatives, lending markets, and institutional finance. Applications in these categories benefit from deep liquidity, mature financial infrastructure, and an active DeFi user base. Optimism’s strengths come from ecosystem distribution. The Superchain provides access to multiple OP Stack networks through a shared technology stack, creating opportunities across consumer applications, identity systems, creator platforms, and multi-chain products. For production teams, ecosystem selection shapes more than user acquisition. It influences liquidity access, integration opportunities, infrastructure requirements, and long-term expansion strategies across the Ethereum Layer 2 landscape. Builder tools Supported languages Arbitrum Solidity: primary language for EVM smart contracts Vyper: Python-inspired smart contract language Rust: supported through Stylus for WebAssembly contracts C: supported through Stylus and WebAssembly compilation C++: supported through Stylus and WebAssembly compilation Optimism Solidity: primary language for EVM smart contracts Vyper: Python-inspired smart contract language SDKs and libraries Arbitrum SDK: TypeScript SDK for bridging, cross-chain messaging, and L1/L2 interaction Arbitrum Orbit SDK: toolkit for deploying and configuring Orbit chains Stylus SDK: Rust SDK for developing Stylus contracts Nitro Node Tooling: core tooling and node implementation for the Arbitrum stack Viem OP Extensions: OP Stack integrations for viem applications supersim: local Superchain simulator for multi-chain testing Superchain ERC-20: token standard for interoperability across Superchain networks Developer support Arbitrum Docs: documentation for Nitro, Stylus, Orbit, and node operations Arbitrum Foundation: grants, ecosystem programs, and governance support Arbitrum DAO: governance forum and protocol decision-making Optimism Docs: documentation for the OP Stack, Superchain architecture, and node operations Optimism DAO: ecosystem governance Which is the better L2? The choice between Arbitrum and Optimism is an ecosystem and infrastructure alignment decision. Fees and execution speed are equivalent in 2026. The relevant considerations are where your users are, what protocols you need to compose with, and what your long-term infrastructure strategy looks like. Choose Arbitrum One when: your application is a DeFi protocol, trading platform, derivatives exchange, or yield product that benefits from composing with GMX, Pendle, Aave’s $12B+ market (as of June 29, 2026), or Camelot’s liquidity your use case involves institutional or RWA flows (Robinhood, Converge, and BlackRock BUIDL are all on Arbitrum) you need the deepest single-chain DeFi liquidity among L2s you want access to Stylus for Rust-based contract development or performance-critical computation Choose Optimism when: you are building or planning to launch an appchain and want the Superchain interop infrastructure (single-block cross-chain messaging, shared fault proofs) your application spans multiple OP Stack chains (Unichain for DeFi, Zora for NFTs, World Chain for identity) you want alignment with the Optimism Collective’s RetroPGF model, which funds public goods contributors retroactively your team wants infrastructure standardization across a multi-chain deployment without maintaining separate codebases Choose both when: you are a stablecoin issuer, a major DeFi protocol, or an application where cross-rollup liquidity is important you expect users to interact across multiple ecosystems and want routing flexibility between liquidity venues you prefer intent-based routing systems that decide execution path dynamically across Arbitrum and OP Stack chains you are building at scale and want redundancy across two major Layer 2 ecosystems Conclusion Arbitrum One and OP Mainnet are both production-grade Ethereum scaling environments. They share the same rollup model, the same settlement layer, and equivalent fees post-EIP-4844. What they offer differently is ecosystem composition and infrastructure scaling philosophy. Arbitrum leads in single-chain DeFi depth, institutional adoption, and Stylus as an execution environment for non-Solidity developers. Optimism leads in cross-chain infrastructure standardization through the OP Stack and Superchain interoperability. For either choice, reliable RPC infrastructure is non-negotiable in production. Public endpoints are rate-limited and unsuitable for load. Archive access, trace methods, and WebSocket support all require a provider. Chainstack covers both networks with the infrastructure profile production applications need: dedicated nodes, archive access, trace support, and SOC 2 Type II and ISO 27001 compliance. The technical foundation exists on both chains. The question is which ecosystem gives your application the best starting position. Start building on Arbitrum or Optimism → FAQ Which is faster, Arbitrum or Optimism? Both networks deliver soft confirmation in approximately two seconds through centralized sequencers. For most production applications, execution speed is comparable. The larger differences are ecosystem maturity, infrastructure architecture, and developer tooling rather than transaction latency. Can I use the same Ethereum RPC methods on Arbitrum and Optimism? Yes. Both networks expose Ethereum-compatible JSON-RPC interfaces, allowing existing wallets, SDKs, and applications to interact with them using familiar methods such as eth_call, eth_getLogs, eth_sendRawTransaction, and eth_subscribe when WebSocket support is available. Do I need a dedicated RPC provider for production applications? Production applications benefit from dedicated RPC infrastructure that provides higher request throughput, lower latency, archive access, WebSocket connectivity, and advanced debugging and tracing methods. These capabilities support reliable transaction submission, real-time event streaming, and blockchain data indexing at scale. How should I choose between Arbitrum and Optimism for a new application? The decision depends on the ecosystem your application is designed for and the infrastructure requirements of your workload. Arbitrum provides deep DeFi liquidity, Stylus, and the Orbit ecosystem for customizable chains. Optimism provides the OP Stack and Superchain for standardized infrastructure and interoperability across multiple networks. How long do withdrawals take from Arbitrum or Optimism to Ethereum? Both networks impose a 7-day challenge window before withdrawals to Ethereum mainnet finalize — Optimism uses the Cannon fault proof system, Arbitrum uses BOLD. For everyday transactions and DeFi activity within L2, soft confirmation arrives in 1-2 seconds. The 7-day window only applies to bridging funds back to Ethereum L1, and third-party bridges (Across, Stargate, Hop) can deliver L1 → L2 → L1 transfers in minutes for a fee. What can I build with Stylus on Arbitrum that I cannot on Optimism? Stylus lets you write smart contracts in Rust, C, and C++ — languages that compile to WebAssembly and run alongside Solidity contracts on the same Arbitrum chain. Use cases include performance-critical computation (cryptographic operations, ML inference, custom VMs), porting existing Rust libraries directly to chain, and applications hitting gas limits with pure Solidity. Optimism does not support non-EVM languages — all contracts must compile to EVM bytecode through Solidity or Vyper. Additional resources Arbitrum on Chainstack Best Arbitrum RPC providers in 2026 Arbitrum RPC nodes and APIs How to get an Arbitrum RPC endpoint in 2026 Arbitrum tooling docs Arbitrum Nitro: an overview RPC infrastructure for RWA protocols Optimism and the Superchain on Chainstack What is Unichain: choosing Unichain RPC for production Best Optimism RPC providers in 2026 Optimism RPC nodes and APIs How to get an Optimism RPC endpoint in 2026 Optimism tooling docs Flashblocks on Optimism via Chainstack #### Are perp DEXs safe? Pros & cons explained Perpetual DEXs (decentralised exchanges) now process around 10% of all crypto perpetual futures volume, up from roughly 3% at the start of 2025, according to data from Coinperps. Close to $500 billion changes hands each month on venues where users retain control of their collateral. Whether this is safer than using a centralised exchange depends on the type of risk. Perp DEXs eliminate the failure modes that brought down FTX. There is no custodian, funds cannot be commingled, and withdrawals cannot be frozen by an exchange operator. Other risks take their place, including contract exploits, oracle manipulation, vault losses and chain downtime. Governance can also rewrite outcomes within minutes. Here are the advantages and drawbacks, the incidents that exposed them, and the checks to make before depositing. What is a perp DEX and how does it differ from a CEX? A CEX holds your collateral, operates the matching engine and sets the mark price. It also controls liquidations. All of this happens inside a system traders cannot inspect. With a perp DEX, collateral remains in a smart contract or an on-chain account under your control until the position settles. Code enforces margin, funding and liquidations under publicly available rules. The amount of infrastructure running on-chain varies by design: Appchain order books (Hyperliquid, dYdX): a purpose-built chain operates the book. Hyperliquid uses its HyperCore layer for matching and margin, while HyperEVM runs alongside it for smart contracts. Oracle-priced pools (GMX, Jupiter Perps): these venues have no order book. Traders open positions against a liquidity pool using the oracle price. ZK and validium order books (Lighter, Paradex, edgeX, GRVT): orders are matched off-chain, with proofs and settlement handled on-chain. Hybrid multi-chain venues (Aster): an off-chain sequencer operates the book, while custody and settlement are distributed across several chains. These architectures have different failure modes, which shape the risks discussed below. Are perp DEXs safer than centralized exchanges? (Pros) No custodian to fail: collateral stays in your wallet or a contract with public code. There is no exchange balance sheet to misstate or withdrawal function that an operator can disable. FTX halted withdrawals on 8 November 2022 with roughly $8 billion of customer funds missing. Bankruptcy filings later showed depositors that Alameda had traded against them using their own money. A perp DEX cannot do this by construction because its holdings are visible on-chain at every block. Rules you can read: margin requirements, liquidation thresholds and backstop mechanics are published and enforced through code. Hyperliquid documents the maintenance margin for each asset and the point at which positions pass to the HLP backstop. GMX publishes its liquidation fee and pool utilisation caps. CEX insurance fund balances and auto-deleveraging queues remain internal, leaving traders to discover how the engine works when they are liquidated. Verifiable activity: fills, margin changes and liquidations are recorded on-chain. After the JELLY incident, Arkham, Halborn and OAK Research reconstructed the attacker’s three accounts and precise sequence of margin withdrawals from public data within hours. Court-appointed examiners took months to unravel FTX’s internal ledger. This transparency also allows aggregators to compare reported volume with on-chain open interest, as covered below. No account to freeze: the contracts do not know who you are. Front ends may geoblock users, and Hyperliquid’s interface blocks US traffic, but a compliance team cannot lock an account balance during a trade. There is also no “withdrawals temporarily suspended” banner. Governance can still treat addresses differently during remediation. Following JELLY, the Hyper Foundation reimbursed users except for flagged addresses, showing that permissionless access does not guarantee permissionless outcomes. Composability: positions, collateral and vault shares exist as on-chain state that other protocols can use. Anyone can deposit into HLP. Since October 2025, HIP-3 has allowed anyone staking 500,000 HYPE to deploy perp markets. HyperEVM contracts can also read HyperCore positions and prices through precompiles, allowing hedging or structured product contracts to react to live positions without an intermediary oracle. The CEX equivalent is an API key with trading permissions, which introduces a security liability rather than offering the same feature. Perp DEX risks explained (cons) Smart contract exploits: code acts as the custodian, making any bug a potential theft vector. GMX V1 lost roughly $42 million to a reentrancy exploit in July 2025. The funds were returned under a bounty agreement, but that outcome is unusual. Most losses fall on liquidity providers or the treasury without an insurance scheme behind them. Oracle manipulation: a venue is only as reliable as its price feed, and thin markets are cheaper to manipulate. On 26 March 2025, a trader used roughly $8 million in offsetting JELLY positions to trigger a liquidation that Hyperliquid’s book could not absorb. This pushed the HLP vault to a $12 to 13.5 million unrealised loss. HyperEVM contracts can now read HyperCore prices through precompiles rather than relying on an external oracle. That removes one attack surface for builders, but it does not change the behaviour of thin markets. Vault and liquidity provider exposure: the LP is the trader’s counterparty on pool-based venues. With order book venues, the backstop vault inherits positions that the market cannot close. Depositors earn yield under normal conditions but carry the tail risk when markets break. Supplying liquidity is effectively selling insurance and should be priced accordingly. Liquidation and auto-deleveraging: because liquidations occur on-chain, congestion or a thin book can cause execution far from the trigger price. If the vault cannot absorb a bankrupt position, auto-deleveraging closes profitable positions on the opposite side at a price those traders did not choose. Governance and admin keys: Hyperliquid validators resolved JELLY in about two minutes by delisting the contract and settling all positions at $0.0095, the attacker’s entry price. This converted a vault loss into a $700,000 profit. It can be viewed as competent emergency intervention or a small group overriding the market. Every perp DEX has some form of this authority through admin keys, multisigs or validator votes. Hyperliquid has since moved delisting to fully on-chain votes. Chain and sequencer downtime: traders can only close positions or add margin while the chain is producing blocks. On 15 December 2023, Arbitrum’s sequencer stalled for about 78 minutes. Positions on Arbitrum venues were frozen while oracle prices became stale. For appchains such as Hyperliquid, the exchange and chain are the same system, so a halt leaves no fallback. Public RPC limitations create a less severe version of this problem. Hyperliquid’s public HyperEVM RPC has been capped at 100 requests per minute per IP since August 2025, which is sufficient for a browser but inadequate for bots or liquidation monitors. Bridges and deposits: most venues require collateral to cross a bridge before it can be used, and bridges are the industry’s most frequently exploited component. A venue operating across four chains depends on four bridges, along with a messaging layer connecting them. Front ends and DNS: self-custody secures your keys, not the transaction you sign. Compromised interfaces have drained users through malicious approvals presented on legitimate-looking domains. Bookmark the correct URL and confirm contract addresses against official sources. How to tell if DEX volume is real Perp DEX activity is theoretically verifiable because it occurs on-chain. In practice, points programmes often reward volume and create incentives for wash trading. Some venues also publish figures that aggregators cannot reconcile. A useful check is to compare volume with open interest because genuine trading requires margin. As of early September 2026, Hyperliquid processed around $180 billion over the trailing 30 days against roughly $10.5 billion in open interest. That represents a ratio of about 17 to 1. It handles more volume than any other perp DEX and holds over 70% of the sector’s open interest. Several venues in the top ten turn over their full open interest more than 100 times per month. One exceeds 1,000 times. This does not prove wash trading, but it shows why volume should not be the sole basis for assessing liquidity. Open interest and protocol revenue are more difficult to fabricate. Perp DEX vs CEX safety compared CategoryPerp DEXCentralized exchangeCustodyYour wallet or a public contractExchange balance sheetInsolvency riskNone from the venue; contract risk insteadFull counterparty exposureLiquidation rulesPublic, enforced on-chainInternal, opaqueOracle riskHigh, especially in thin marketsLow, internal index priceDowntimeChain or sequencer halt freezes positionsExchange outage freezes positionsRecovery after lossRare, no insurance schemeOccasional, discretionaryWho can override outcomesAdmin keys, validators, multisigsThe exchangeAccessPermissionlessKYC and jurisdictional limitsActivity dataVerifiable on-chainReported by the exchange Does the chain a perp DEX runs on affect safety? The venue inherits the failure modes of its underlying chain, and each type of network fails differently. Appchains (Hyperliquid, dYdX): because the exchange is the chain, its validator count, client diversity and halt history form part of the venue’s safety record. HyperCore and HyperEVM use the same consensus, so a stall affects both. This design has fewer moving parts than an L2, but no fallback. Ethereum L2s (Arbitrum for GMX, ZKsync for GRVT, Starknet for Paradex): users inherit the centralised sequencer and its outage record. A forced exit through L1 can take from several hours to a day. Proof systems provide verifiability while introducing another component that may stall. Solana (Jupiter Perps, Drift): Solana is fast and inexpensive, although its network halt history should inform position sizing. As with any chain, positions remain frozen during an outage. Multi-chain venues (Aster): the main risk lies in communication between chains rather than one specific network. Each additional deployment introduces another bridge and another collection of endpoints that must remain operational. Regardless of the architecture, the trader’s connection is the final link. Public RPC infrastructure tends to deteriorate during the same volatility that causes liquidations. A private or dedicated endpoint is the only part of this stack directly controlled by the trader. How to check if a perp DEX is safe Exploit history and code age: focus on how long the current code has operated under genuine load without an incident, not simply whether audits exist. Who can override the market: review admin keys, validator count and timelocks. Check whether the venue can delist markets or force settlements. Oracle design and open interest caps: examine both carefully, particularly for markets outside the major assets. Chain maturity and exit path: assess the chain’s performance under load and determine what options remain if its sequencer stops. Volume against open interest: perpetual futures data aggregators such as Coinperps track both metrics across centralised and decentralised venues using a standardised methodology, allowing like-for-like comparisons. Deposit and withdrawal path: identify the bridge involved, its transaction times and any previous losses. Your own infrastructure: automated systems should not rely on a public RPC endpoint. Why RPC infrastructure matters for perp DEX safety Every safety check above assumes you can see your position and act on it. On a perp DEX that depends on an RPC connection, and the moment it matters most is the moment public endpoints are least reliable. Stale data means wrong decisions: if your endpoint lags the chain by a few blocks during a fast move, the liquidation price you are watching is already out of date. Rate limits hit under load: public endpoints throttle when everyone queries at once, which is exactly when liquidations cascade. A capped endpoint turns a close order into a failed request. Bots and monitors need redundancy: anything automated should run against a dedicated endpoint with a fallback, not a shared public one. None of this fixes a halted chain. It does remove the failure that sits between you and a chain that is still running. Providers like Chainstack offer dedicated RPC nodes across the chains perp DEXs run on, including Hyperliquid, Arbitrum, and Solana, which is one way to remove the shared-endpoint bottleneck from your own setup. Conclusion Perp DEXs protect users from the failure that led to their creation. No operator can lend out your collateral or refuse a withdrawal. In exchange, traders accept exposure to code, oracles and chains, as well as whoever controls the admin keys. The sector has produced a real example of each risk: GMX for code, JELLY for oracle and governance failures, and Arbitrum’s sequencer for chain outages. The trade is counterparty risk for protocol risk. For most traders, that is worthwhile on a mature venue with deep books and an uneventful exploit history. It is not worthwhile when reported volume looks implausibly high relative to open interest. Get an RPC endpoint on Chainstack for perp DEX trading → Related reading How to build a HIP-4 trading bot on Hyperliquid Hyperliquid API guide: endpoints, SDK, and WebSocket Jito explained: bundles, tips, and how MEV works on Solana Hyperliquid RPC for perps trading: best providers and full trading guide 2026 #### Auto Layout components in Figma At Chainstack, we do pay attention to how people interact with our platform. That’s why we need to optimise the design processes that we have to be able to iterate faster and in a more efficient way. Here I will show how Auto Layout components help us to make it happen and how to create a full-page component using Auto Layout in Figma. I’m a big fan of atomic design because it works well for designers, and it brings us closer to the approach that front-end developers use in their work. While we use the same approach, we can collaborate more effectively. With this in mind, I was trying to find a way to maximize the usage of the atomic design in my components library, and finally with the new Auto Layout it’s possible. Let’s take a look at what I’ve learned. The approach If you aren’t familiar with the atomic design concepts, I highly recommend you to read more about atomic design first.  Atomic design applied to the native mobile app Instagram. Source: https://atomicdesign.bradfrost.com/ The picture above illustrates the logic that I use for my components. With this approach, it’s easy to design components and—what’s very important—to support them after. Below you can see the page I’ll use as an example. That’s a real page that I’ve designed and use in the project I’m working on at Chainstack. In this post, I’ll focus only on the components that use Auto Layout. If you don’t want to dive into details, I put a link to the final result in Figma at the end of this post.  Atoms  On the atomic level, everything is quite simple. I highlighted the components that use Auto Layout.  Let’s take a look at their anatomy. Text styles and colors are defined in Figma Styles.  That’s a typical atomic level component. Auto Layout: Horizontal, Spacing Between Items 8px.  Molecules Here the things are getting a bit more challenging. For our molecules, we use only the atoms that we’ve created at the previous step and some of the base elements that I’ve created in my library (font & color styles).  The hint bar is the most challenging element here. I use it on a few different pages on the platform, and it behaves differently according to the situation. It should:  Fit to the content size.  Take the full width of the content area.  Support multi-line text for both scenarios above.  You can’t simply resize an Auto Layout component in Figma, but I don’t want to keep two very similar components in my library. I found a solution.  How it works: I have an Auto Layout component that adjusts its size to the content, but it sits in a component without Auto Layout, so I can resize the parent component manually if I need to adjust it to the page width.  The rest of the components are quite simple.  The breadcrumbs component, for example, is a stack of atomic components that behave in the same way as its children: atoms adjust their size to the content > the breadcrumbs component adjusts its size to the size of atoms inside.  The buttons block works in the same way. It’s an Auto Layout component with a few atomic buttons components inside.  Organisms  The most challenging part here was to organize the details section: it should support multi-line parameters. This means that all blocks should behave according to the amount of content the blocks above have. It can have from one to three rows of parameters, so we need to support any configurations within these limits:   From 1 to 3 rows.  Rows can have 4 blocks of information or less.  The first layer helps us create paddings around the content.  This layer split the content section from the section header (“Details”).  Here we create paddings between the rows with a few atomic design components inside.  The final level is a row component with a few atomic design components inside. It behaves in the same way as the breadcrumbs component.  Another big organism is a table component, but it’s much simpler. Here we need the first Auto Layout component to separate the header from the body.  Then I use Auto Layout with 0 spacing to make the table.  Templates  The template has a content section where we collect all dynamic elements and a few components that sit in their places (breadcrumbs, section header).  The main header I didn’t add the main header to the final template because components in Figma don’t support fix position when scrolling for its elements. This is the only reason that doesn’t allow us to use this page as a component, but it’s not a problem for short pages that fit 100% of its content to the screen.  Now we have a very flexible, easy to support page. This is what it looks like in the end.  In the animation above, you can see how our atomic design page works in the prototyping mode in Figma.  That’s how simple and clean the page looks. On top of that, all components on the page are very flexible and responsive, and I can use them across all my design files. In case of any changes in the design of the page, I can update them in my library, and it will update all my design files automatically.   Here is a link to the page: https://figma.fun/TxDFA4  P.S.  Figma suggests using an automatic Auto Layout creation (press Shift + A) for simple components, and usually it works well, but sometimes it doesn’t work as expected. Instead of removing the background layer and replicating it with Auto Layout parameters, Figma thinks that it’s an object that’s supposed to be a part of the component that we’re trying to create. You can see an example of this behaviour below. In this case, I create the Auto Layout component manually.  Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Avalanche subnet tutorial series: Indexing subnet with The Graph is is the last article of the Avalanche subnet tutorial series. It has been a long way here, hoping you have achieved most of your goals by now. A quick recap on what has been done: started off by creating a validator node on Fuji testnet; then a subnet was spun off on it; after that, on top of the subnet, a blockchain was established and connected to with MetaMask; finally a smart contract was deployed with Remix. Make sure the blockchain is properly working by sending a simple request to its RPC endpoint. The URL is most likely in the format of: 127.0.0.1:9650/ext/bc/*fill in your block chain id here/rpc. For example: curl -X POST --data '{ "jsonrpc": "2.0", "method": "eth_chainId", "params": [], "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/2t27BUokp5Pj8zNQhSNVgqYHChSqrd4k8ewSBrEMXoixxjsXQj/rpc If it returns its chain ID in response, it is working as expected. Also make sure MetaMask and Remix is linked to the blockchain too. If it doesn’t work, feel free to revisit the previous articles here: What is a subnet.Running a local Avalanche node on Fuji testnet.Creating a subnet, then create a blockchain on it.Deploying a smart contract.Indexing subnet with The Graph. <– You are here. This article is about indexing subnet with an extremely useful tool for DApp development—The Graph. About The Graph The Graph is an indexing protocol, a platform, and also an open-source tool. It can be confusing for most beginners, so this section is dedicated to explaining what The Graph is. (You can skip this part if you are already familiar with this). There are 4 main concepts to explain. GraphQL and The GraphThe Graph as a protocolGraph node and subgraphHosted service and subgraph studio About GraphQL and The Graph GraphQL is a language. It was implemented on multiple platforms with different tools. The Graph is just one of them. The Graph is maintained by The Graph Foundation and GraphQL is maintained by the GraphQL foundation. The relationship between GraphQL and The Graph is just like this: They are mostly unrelated. The Graph protocol The illustration looks complicated but the protocol itself is not. Basically what The Graph does is listen to blockchain events and record down all transactions of a specific smart contract. The transaction data are indexed and saved, it can be consumed through RPC and WebSocket endpoints using GraphQL. About The Graph node and subgraph The center of the protocol is the Graph node. It is an open-source project (GitHub repo) that links the blockchain, the database (PostgreSQL), and the file-hosting system (IPFS) together. The subgraph contains the metadata for the graph node. It defines how data is mapped, stored, and consumed. The node starts indexing the smart contract only after a subgraph is deployed to The Graph node. About hosted service and subgraph studio thegraph.com also provides subgraph hosting services. Users can create their own subgraph using graph cli on local machine and upload it to the graph hosted service. Subgraph studio is an online IDE for subgraph, however, it currently supports only Ethereum network. The hosted service, on the other side, supports most EVM-compatible chains. Unfortunately, it is not, at least not for hosted service. The only way to use The Graph with Subnet, is hosting a local graph node. Hosting a local graph node The official GitHub repository for The Graph node is here. Most of the installation steps in this tutorial are the same, so feel free to use that as a reference source too. To run a local graph node, there are three external systems needed. They are: Rust and Cargo, for building and compiling The Graph node. See How to install Rust.PostgreSQL, for keeping data. See PostgreSQL Downloads.IPFS, for file hosting. See Installing IPFS. Follow the steps to install the systems, and make sure IPFS and PostgreSQL are properly running. IPFS is running PostgreSQL is running The first three steps is identical to graph-node GitHub repo, they are directly copied from there: 1.Install IPFS and run ipfs init followed by ipfs daemon. 2.Install PostgreSQL and run initdb -D .postgres followed by pg_ctl -D .postgres -l logfile start and createdb graph-node. 3.If using Ubuntu, you may need to install additional packages: sudo apt-get install -y clang libpq-dev libssl-dev pkg-config Now navigate to the working directory, run: git clone https://github.com/graphprotocol/graph-node cd graph-node cargo build * If Rust is installed but the command not found: cargo error shows up, running the following command may solve the issue: source $HOME/.cargo/env Once all the dependencies are successfully installed, run: cargo run -p graph-node --release -- \ --postgres-url postgresql://postgres:*fill-in-posgresql-username: :*fill-in-posgresql-password @localhost:5432/graph-node \ --ethereum-rpc fuji:http://127.0.0.1:9650/ext/bc/*fill-in-your-blockchain-id/rpc \ --ipfs 127.0.0.1:5001 The start-up parameters need to be customized. One example is this: cargo run -p graph-node --release -- \ --postgres-url postgresql://postgres:password123@localhost:5432/graph-node \ --ethereum-rpc fuji:http://127.0.0.1:9650/ext/bc/2t27BUokp5Pj8zNQhSNVgqYHChSqrd4k8ewSBrEMXoixxjsXQj/rpc \ --ipfs 127.0.0.1:5001 If everything goes ok, this shows up: It means The Graph node is up and running. Deploying subgraph To deploy a subgraph, navigate to the working directory. Run: git clone https://github.com/graphprotocol/example-subgraph cd example-subgraph yarn yarn codegen This downloads the official sample subgraph. It is based on the smart contract for the gravatar registry. In the previous tutorial, its source code was downloaded from the Ethereum network and deployed to the subnet blockchain using Remix. The sample subgraph can be used directly with little modification. In fact, only two parameters need to be changed. Open subgraph.yaml: Change dataSources -> network to fujiChange dataSources -> source -> address to the smart contract address Run: yarn create-local yarn deploy-local The subgraph should be deployed successfully. Graph node may take a while to scan all the blocks to get history data. Once it is finished, open: http://127.0.0.1:8000/subgraphs/name/example/graphql in the browser. In the query box, fill in: query MyQuery { gravatars { id imageUrl displayName } } Press the run button to see it in action. There it is. The Graph is successfully indexing the smart contract now. To learn more about The Graph, there are many good tutorials on the official documentation. Conclusion This is the end of Avalanche subnet tutorial. Hope it is helpful. If you need any help or have questions, feel free to reach us on our Discord channel! Cheers, happy coding. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Avalanche subnets tutorial series: Avalanche smart contracts This is the fourth article in the Avalanche subnet tutorial series. Check out the other articles here: What is a subnet?Running a local Avalanche node on Fuji testnet.Creating a subnet, then create a blockchain on it.Deploying a smart contract. <– You are here.Indexing subnet with The Graph. This project has come a long way. At this point, a local node has been set up; then it is staked and is a validator node for the Fuji testnet; then a subnet was created, and the node was assigned to validate the subnet; then a brand new blockchain was established on it. Just a quick recap: The name of the blockchain is chainstacksubnet;Its ID is 2t27BUokp5Pj8zNQhSNVgqYHChSqrd4k8ewSBrEMXoixxjsXQj. (The ID is unique for every blockchain and subnet).It is a Ethereum Virtual Machine (EVM) blockchain. Based on the genesis block information, 333.33 blockchain token was pre-stored in the address 8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC. So, the first objective of this tutorial is to transfer some of the tokens out. How to access your subnet with MetaMask? Like every other EVM blockchains, subnet EVM too supports the (arguably) most widely used tool-MetaMask. This section guides the reader to configure MetaMask to access a subnet. Firstly, open MetaMask, click Add Network: Fill in the following information: Network Name: *any name is okNew RPC URL: http://127.0.0.1:9650/ext/bc/*fill in your blockchain id/rpc Example: http://127.0.0.1:9650/ext/bc/2t27BUokp5Pj8zNQhSNVgqYHChSqrd4k8ewSBrEMXoixxjsXQj/rpcChain ID: 13213Currency Symbol: *any symbol is ok Now MetaMask should successfully link to the blockchain. It now can be used to access the initial address. The initial address is defined during creation of genesis block. Its public address is 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC. Its private key is 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027. This private key is publicly shared, it is also given in the official tutorial. Do not use this account on mainnet or testnet. Now import the private key into MetaMask. Click the fox head to open MetaMask. Click on the top right icon, click Import Account: Key in the private key and click Import: The account should be added into MetaMask. A fresh account should contain 333.3333 tokens. Now funds can be sent to another account by clicking on Send button. Input an address or select Transfer between my accounts. Complete the steps to send 30 tokens to another account. The genesis specified the minimum base fee as 13000000000 which is equivalent to 0.0000000144 native token. Once the transaction is finalised, it is shown in the Activity section. The blockchain is successfully deployed and compatible with MetaMask. Sending Avalanche smart contracts with Remix Next step is deploying a smart contract on the blockchain. Remix is used to do that. Remix is a popular IDE for creating/deploying smart contracts on Ethereum based blockchains. It can be used with Avalanche subnet EVM blockchain too. First, make sure the previous section is finished successfully and MetaMask is connected. Log in to Remix. In the left-most pane, click on file explorer logo. Right-click on contracts folder, create a new file. Name the file Gravatar.sol (any name is ok). Go to Etherscan.io, search for 0x2E645469f354BB4F5c8a05B3b30A929361cf77eC. This is the contract for Gravatar Registry, it will be moved to our subnet. Scroll down to the lower half of the page, click the Contract tab, copy its source code. Go back to Remix, paste it into Gravatar.sol and go to the solidity compiler in the left pane. Compile Gravatar.sol. When it is finished, you will see GravatarRegistry in the contract dropdown menu. It means the contract is successfully compiled. Next step is to deploy it to the subnet blockchain. Click Deploy tab in the left pane. Set environment to Injected Web3 to use MetaMask. Select an account with sufficient funds. Select the contract GravatarRegistry. Click Deploy. Click confirm on MetaMask pop-up. It takes a while to finish the transaction. After the smart contract is successfully deployed, it can be tested in the Remix IDE. In the Deploy tab, a new section shows up now for Deployed Contracts. The methods from the GravatarRegistry contract are displayed there. It means the contract is successfully deployed. Feel free to play around with all the methods. Click on createGravatar, enter a displayName and imageURL, click transact. Finish this step in MetaMask by clicking on the Confirm button. The transaction shows up in the activity section on MetaMask too: Use Remix to test the getGravatar function with the owner’s address, it returns the image URL. Now the smart contract is successfully deployed on the subnet. Conclusion This is the end of this article. In this article we deployed a smart contract on our blockchain using Remix and MetaMask. Hoping it is useful. To clarify any question, please feel free to send your message in Chainstack’s discord channel. Happy coding. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Avalanche subnets tutorial series: Creating an Avalanche subnet and a blockchain This is the third article in Avalanche subnet tutorial series. Check out the other articles here: What is a subnet. Running a local Avalanche node on Fuji testnet. Creating a subnet, then create a blockchain on it. <– You are here. Deploying a smart contract. Indexing subnet with The Graph. In the previous articles, we talked about Avalanche’s unique multiple chains setup, what subnets are, and even established a validator for our own. By now you should have a validator node for the Fuji testnet running locally. Check if the node is ready by calling info.isBootstrapped. If it is, the response will be the following: Then call info.getNodeID to retrieve its node ID. It is formatted as NodeID-********, write it down somewhere, as it will be used multiple times in this tutorial. Call platform.getCurrentValidators to get a list of the current validators in the network, and make sure your node ID is in the list. If you get all of this, it is time to move on to the next part: creating a subnet and starting a new blockchain. Creating Avalanche subnets Check the official Avalanche document about creating subnets. It is 70% identical to this tutorial, so please use it as a reference if needed. The first thing to do is to create a user with the keystore API. The keystore username and password exist only on the initial node—they are not accessible from other nodes. Also, take note that the node operator has access to them too. Try to avoid using it on third-party nodes. Call keystore.createUser to create a new user: "id" :1, "method" :"keystore.createUser", "params" :{ "username":"chainstack", "password":"Chainstack122!" } }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/keystore Make sure the password is at least 8 characters and contains both upper and lower case letters, as well as numbers and symbols. In this case, the username is chainstack and the password is Chainstack122!. Once it is created, this message shows: Call platform.createAddress to get an address for control keys. The official tutorial uses two control keys, but one is sufficient. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.createAddress", "params": { "username":"chainstack", "password":"Chainstack122!" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P Run it twice, get two addresses on P-chain. Copy them down for later. In case these keys are lost, call platform.listAddresses to retrieve them. Then call platform.createSubnet to create a subnet. Fill in the control keys generated in the previous step. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.createSubnet", "params": { "controlKeys":[ "P-fujiabcdefg*change this*", "P-fujiabcdefg*change this*" ], "threshold":2, "username":"chainstack", "password":"Chainstack122!" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P It will most likely return an error message: couldn't create tx: couldn't generate tx inputs/outputs: provided keys have balance (unlocked, locked) (0, 0) but need (100000000, 0). It means AVAX is needed for this operation. In the first article of this tutorial series, we mentioned how the P-chain is isolated from the rest of its folks; Therefore, topping up P-chain takes a few extra steps. Firstly, call platform.exportKey to get the private keys of the first address. Copy it down. curl -X POST --data '{ "jsonrpc":"2.0", "id" :1, "method" :"platform.exportKey", "params" :{ "username" :"chainstack", "password": "Chainstack122!", "address": "P-fujiabcdefg*change this*" } }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P Go to Avalanche’s official wallet, and click Access wallet. Log in with the private key. Get some test AVAX from the faucet airdrop page. The detailed steps are in this previous article. Transfer 1 AVAX to P-chain—see the steps in the previous article too. Call platform.createSubnet again. If this is shown: Congratulations! You have created a subnet! Now call platform.getSubnets, it gives all the subnets on Avalanche. Go through the list, look for a subnet with matching control keys and ID. Copy them down for later use. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.getSubnets", "params": {}, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P The next step is to add a validator node to the newly created subnet. It is done via calling platform.addSubnetValidator: curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.addSubnetValidator", "params": { "nodeID":"Fill in", "subnetID":" Fill in", "startTime":'$(date --date="10 minutes" +%s)', "endTime":'$(date --date="30 days" +%s)', "weight":30, "username":" Fill in ", "password":" Fill in " }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P Fill in the nodeID, subnetID, username, and password. The start time and end time can be strings in the Epoch & Unix timestamp format. Below is a sample request and its response. Copy the txID, call platform.getTxStatus to verify transaction status. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.getTxStatus", "params": { "txID":"fill in txID from previous step" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P If the status shows Committed, the transaction is successful. Now go to terminal, terminate the avalancheGO instance by pressing CTRL-C. Restart it with a new parameter --whitelisted-subnet: ./build/avalanchego --network-id=fuji --whitelisted-subnets=3fbrm3z38NoDB4yMC3hg5pRvc72XqnAGiu7NgaEp1dwZ8AD9g Change the value to your own subnet ID, this will make your validator start working for the subnet. After it is done, a new subnet is up and running but wait, we still have to create a blockchain in it. Creating a blockchain The next step is to create a blockchain. Avalanche supports 3 types of blockchains—AVM, EVM, and custom VM. The Avalanche virtual machine (AVM) blockchain is identical to X-chain. The Ethereum virtual machine (EVM) blockchain is an Ethereum instance; it is identical to the C-chain, as well as other Ethereum based blockchains. The Custom virtual machine allows users to create their own blockchain. For this tutorial, we’ll use an EVM blockchain as an example. This can be done by sending just one API call: platform.createBlockchain. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.createBlockchain", "params" : { "subnetID": "your subnet ID", "vmID":"the vmID", "name":"any name is ok here", "genesisData": "the genesis block byte data", "username":"your username", "password":"your password" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P By now, the developer should have a subnetID, username, and password from the previous steps. The only thing that is missing is the vmID and the genesisData. Download the source code for EVM: clone git@github.com:ava-labs/subnet-evm.git Build the source code by running: cd subnet-evm ./scripts/build.sh ./build/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy is the VM ID—it is the default ID and corresponds to the string subnetevm (zero-extended in a 32-byte array and encoded in CB58.) Move the built binary into the AvalancheGO plugin folder: avalanchego/build/plugins. Restart the node. Run avm.buildGenesis to get the genesis block byte data. The genesis block is the initial block in a blockchain, for an EVM it is defined as: curl -X POST --data ' { "jsonrpc": "2.0", "id": 1, "method": "subnetevm.buildGenesis", "params": { "genesisData": { "config": { "chainID": 13213, "homesteadBlock": 0, "eip150Block": 0, "eip150Hash": "0x2086799aeebeae135c246c65021c82b4e15a2c451340993aacfd2751886514f0", "eip155Block": 0, "eip158Block": 0, "byzantiumBlock": 0, "constantinopleBlock": 0, "petersburgBlock": 0, "istanbulBlock": 0, "muirGlacierBlock": 0, "subnetEVMTimestamp": 0, "feeConfig": { "gasLimit": 8000000, "targetBlockRate": 2, "minBaseFee": 13000000000, "targetGas": 15000000, "baseFeeChangeDenominator": 36, "minBlockGasCost": 0, "maxBlockGasCost": 1000000, "blockGasCostStep": 200000 }, "allowFeeRecipients": false }, "alloc": { "8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC": { "balance": "333333333333333333333" } }, "timestamp": "0x0", "gasLimit": "0x7A1200", "difficulty": "0x0", "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000", "coinbase": "0x0000000000000000000000000000000000000000", "number": "0x0", "gasUsed": "0x0", "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000" } } } ' -H 'content-type:application/json;' 127.0.0.1:9650/ext/vm/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy/rpc All these values can be copied and used directly, there is no need to modify them. This returns the byte data for the genesis block. Copy it down Now run platform.createBlockchain again with the vmID and the lengthy genesisData: The response: The blockchain is now created successfully. Check it by calling platform.getBlockchains: curl -X POST --data '{ "jsonrpc":"2.0", "id" :1, "method" :"platform.getBlockchains", "params" :{} }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P Find the newly created blockchain in the list. Copy down the ID. Call platform.getBlockchainStatus. curl -X POST --data '{ "jsonrpc": "2.0", "method": "platform.getBlockchainStatus", "params":{ "blockchainID":"your block chain id" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/P The status should be validating. Congratulations. The blockchain is now up and running. It can be accessed from the RPC end point:127.0.0.1:9650/ext/bc/YOUR_BLOCKCHAIN_ID/rpc For example: 127.0.0.1:9650/ext/bc/2t27BUokp5Pj8zNQhSNVgqYHChSqrd4k8ewSBrEMXoixxjsXQj/rpc Minting a new token To mint a new token, the user can do it via a precompiled contract. First, nativeMinterConfig needs to be set in genesis: { "config": { "contractNativeMinterConfig": { "blockTimestamp": 0, "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"] } } } The detailed steps can be found here. Conclusion In this article we’re reviewed how to create a new subnet, whitelist it in our previously created validator, and created a new blockchain from scratch in it. Hope it is helpful. If you have any questions, feel free to ping us on the Discord channel. Happy coding. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Avalanche subnets tutorial series: Running a local Avalanche node on Fuji testnet This is the second article in Avalanche subnet tutorial series. Check out the other articles here: What is a subnet.Running a local Avalanche node on Fuji testnet. <– You are here.Creating a subnet, then create a blockchain on it.Deploying a smart contract.Indexing subnet with The Graph. In this article, we’ll guide you for educational purposes in setting up a personal Avalanche node on a local machine and making it a validator. Also, talk to us if want a subnet set up with Chainstack. The entire process is split into three parts: Setting up Git with GitHub and Go.Running a local Avalanche node.Getting AVAX and stake the node to make a validator node. Warning: this tutorial is crafted for macOS. Developers should adjust accordingly depending on their system. Setting up Go The first step is setting up Go. Go is exceedingly popular for blockchain VMs, and it is also the default language for AvalancheGo. Blockchain developers using a recent version of macOS should already have Go on their machine—run go version in your terminal to confirm. If Go is not installed, download and install the package. In rare instances, developers may have issues running the AvalancheGo build script. That is because of a missing environment variable. If that happens, try adding $GOPATH/bin to your $PATH by running the following command: export PATH="$PATH:$(go env GOPATH)/bin" Setting up Git Git is another must-have tool for developers. Run the following command to check if it is already installed. git version If not, install it. Setting up node Download the AvalancheGo source code: git clone git@github.com:ava-labs/avalanchego.git If it does not work and shows the following error message: git@github.com: Permission denied (publickey). This is because the SSH key is missing from the SSH agent. Follow this article to resolve this issue. When Git is ready to go, run the command again to download the source code. After the download is finished, navigate to the avalanche go folder: cd avalanchego To build the source code, run: ./scripts/build.sh When it is done, run the following command to start the node for Fuji testnet. ./build/avalanchego --network-id=fuji In the terminal, you will see: This means the node is up and running. If it is the first time it runs, it needs to synchronize data with the Avalanche primary network. The bootstrapping process takes approximately 50–100 hours and requires 100 GB of space. The node is unusable before it is done. The endpoints are reachable, but most RPC calls respond with error messages. The bootstrapping status can be checked by sending the following cURL request: curl -X POST --data '{ "jsonrpc": "2.0", "method": "info.isBootstrapped", "params":{ "chain":"X" }, "id": 1 }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info Now it is wait time. ****************** Or is it more like: The good news is that shutting down the node does not terminate the process. The next time the node is turned on, it’ll start from where it was left.When the process is complete, you will see: Hooray, your node is up and running. It is not a validator yet, but it is part of the Avalanche primary network already and developers can now access all three chains through this endpoint. Run Avalanche validator node The official documentation explains how to set a validator node on the mainnet and the steps are 90% the same for the Fuji testnet. First, get your node ID by running the following cURL request: curl -X POST --data '{ "jsonrpc":"2.0", "id" :1, "method" :"info.getNodeID" }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info The response is: Now visit Avalanche’s official wallet website and create a new wallet for your validator. Remember to change the network to Fuji. Since it is a new wallet, it is empty. The validator node needs some AVAX to start validating transactions. To get testnet AVAX, copy its X-chain address. Go to the official faucet page to request for testnet faucet. You should receive 2 AVAX on the X-chain. Go to the cross-chain tab, and transfer 1 AVAX to P-chain. Go to the Earn tab and click Add validator. Fill in the node ID and AVAX and click on Confirm. Congratulations, you have a validator node now! Conclusion In this article, we have shown you how to set up and run an Avalanche node locally and make it a validator of the Fuji testnet. In the next article, we will go into creating our own subnet, so make sure you will not miss them.   If you need any help or have questions, feel free to reach us on our Discord channel! Happy coding. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Avalanche subnets tutorial series: What are Avalanche subnets? Avalanche is the 4th largest blockchain network with 10.6 billion total value locked (TVL) as of April 2022. The reason more and more developers choose Avalanche is because of its improved throughput and scalability.   Performance-wise, Avalanche can process 4500 transactions per second (TPS) right now.   Scalability-wise, subnet is the key feature making Avalanche stand out from its peers.  Avalanche subnets allow users to create and run their own blockchain networks, and it is very flexible. A subnet can be set to private, so its transactions are separated from the primary network. Subnet chains can also be tuned to meet different compliance requirements like geographical bounds and KYC/AML checks. This tutorial series is created to help developers start their journey with Avalanche subnets. For testing purposes, it is based on Avalanche’s Fuji testnet, but the steps are applicable to mainnet too. It is extended from this article on Avalanche’s official website, so many code snippets were reused from there. This tutorial consists of 5 parts: What is a subnet. <– You are here. Running a local Avalanche node on Fuji testnet. Creating a subnet, then create a blockchain on it. Deploying a smart contract. Indexing subnet with The Graph. This is the first article in the series. It is a collection of essential background bits of knowledge and common doubts that may arise during development. It is optional and independent from other articles, so feel free to skip it if you think you have a foundation in Avalanche and come back in the future if needed.  The roadmap This is a comprehensive roadmap of what this series is about. Please take note that all the sample codes, command line inputs, and system setups are macOS-based. Developers using different platforms should adjust accordingly depending on their system. The summary of this tutorial: Running a node for Avalanche’s Fuji testnet. Making the node a validator node. Creating a subnet. Initializing a blockchain network. Deploying a smart contract on a blockchain network. Using The Graph with a subnet. Building a DApp. About AVAX validator nodes  Many readers may already know what a node is; Nodes are actually AvalancheGo instances/servers/hosts. Nodes keep the state of the blockchain(s) and offer API endpoints for users to query the blockchain and send transactions. In general, there are two types of nodes on Avalanche: validator nodes and non-validator nodes. Users can access Avalanche chains through either of them. Non-validator nodes do not verify transactions, they are merely an endpoint to access the protocol. Validator nodes are staked with AVAX. They participate in the transaction verification process on Avalanche following the Snowman consensus model with staking. On mainnet, the minimum amount that a validator must stake is 2,000 AVAX, while on the Fuji testnet there is no minimum. This tutorial starts from scratch and begins with creating your own validator node. There are two main reasons for this: To create a subnet, a Keystore user is needed; and the username and password are all accessible by the node admin. It is recommended to do this on your own node(it doesn’t have to be a validator node). To start validating a subnet, the participating validator nodes must be configured and restarted to whitelist the subnet with its subnet ID. What are the Avalanche X-chain, P-chain, and C-chain?  There are 3 primary blockchains on Avalanche. Together they are running on the primary network of Avalanche, and all the nodes on Avalanche have access to these three chains. Validator nodes must always be a part of the primary network, so it is not possible to have a validator node for a subnet only. Chains are accessed through different APIs. Each chain serves different purposes. The P-chain is for platform management. It handles requests related to the validator, the subnet, and the blockchain.  The C-chain is for contract management. It is based on EVM; hence its API is almost identical to other EVM protocols. It has both RPC and WebSocket endpoints, and it handles requests for smart contracts.  The X-chain is for asset exchange. It is Avalanche’s native platform; it is used for creating and trading assets like AVAX and NFTs.  About the AVAX currency and the wallet AVAX is the native token on Avalanche, and it can be exchanged and consumed on all three chains, for different purposes though. On the X-chain, AVAX is traded as the primary currency. The transaction fee is fixed to 0.001 AVAX. On the P-chain, AVAX is used for validator node staking. A validator node earns AVAX rewards for validating transactions. On the C-chain, AVAX is used in smart contracts or to pay for gas. The transaction and gas fees are not fixed as opposed to the X-chain. Unlike the X-chain and the P-chain, the C-chain address is Ethereum styled, and starts with 0x. Subnets, on the other hand, do not exchange AVAX; they issue their own tokens. AVAX tokens are stored in wallets. Each wallet has 3 addresses, one for each chain. Users can easily manage them using the official Avalanche wallet. AVAX can be transferred either to:  An address on the same chain. Different chains in the same wallet. It is not possible to transfer AVAX to another address on a different chain.  Note that addresses on P-chain cannot transfer tokens between each other. Neither can they request a faucet airdrop in testnet. To set up a validator node, AVAX needs to be transferred to the X-chain or C-chain address before moving it to P-chain. About Avalanche subnets There is a common misunderstanding that the subnet is a blockchain. A subnet is actually a set of validator nodes. The official documentation states that:  A subnet, or subnetwork, is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by exactly one subnet. A subnet can validate many blockchains. A node may be a member of many subnets. To elaborate on this:  A subnet is not a blockchain, it is a group of validator nodes. When a subnet contains no validator, its state becomes invalidated, and any blockchain on it stops functioning. One node can be a part of multiple subnets. Subnets can be assigned to many blockchains. One blockchain can only be validated by one subnet. A very brief summary of how to use a subnet:  A user owns one or more validator nodes on Avalanche’s primary network. The user creates a new subnet. No validator is assigned to the subnet yet.  The primary network gets notified; a new subnet is created.  A validator node is assigned to the subnet. The subnet starts getting validated. A new blockchain is created on the subnet. About customized blockchain Avalanche supports 3 distinct types of blockchain virtual machines(VM).  AVM creates a private X-chain.  The Subnet EVM creates a private C-chain.  By modifying the source code in the ChainVM interface, developers can create their own chain.  Conclusion Hope this article helps to clarify doubts about Avalanche and subnet. In the next articles, we will dive deeper into creating our own subnet, so make sure you will not miss them.   If you need any help or have questions, feel free to reach us on our Discord channel!  Happy hacking. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Base chain migration guide: from OP Stack to base/base TL;DR For node operators: Base V1 is the hard migration boundary. After activation, op-node + op-geth will no longer sync with the canonical chain. You must switch to base-consensus + base-reth-node. Sepolia activates 2026-04-20 at 18:00 UTC — mainnet date TBD. For app developers: Nothing breaks. Chain ID (8453), contract addresses, RPC methods, and EVM behaviour are unchanged. The optimism_* namespace remains fully supported. For DeFi / MEV teams: Flashblocks introduces 200ms sub-block ordering. Once a Flashblock is sealed its transaction order is final. Factor this into liquidation and arbitrage logic. For infrastructure providers: Sequencer, consensus client, and fault proof system are now consolidated into a single Reth-based binary from github.com/base/base. One release channel, one set of release notes. What is Base? ➡️ If you are already familiar with the Base and it’s new architecture, skip to “What changes for node operators” section below for the step-by-step migration guide. Base is an Ethereum Layer 2 network incubated by Coinbase. It was launched on Optimism‘s OP Stack and has since grown into the largest chain in the Superchain ecosystem by total value locked. Source: https://www.superchain.eco/chains Base processes transactions off-chain and posts compressed calldata back to Ethereum for data availability. It uses optimistic rollup mechanics, with fraud proofs allowing any party to challenge invalid state transitions during a dispute window. The network is EVM-equivalent. Smart contracts written in Solidity, developer tooling built for Ethereum mainnet, and standard JSON-RPC methods all work on Base without modification. Why the migration happened Base launched on the OP Stack because it offered a production-ready, well-audited foundation. The trade-off was coordination overhead from distributed ownership. Over time, Base grew into a diverse ecosystem. The code operating Base’s sequencer, consensus layer, and fault proof system was spread across repositories maintained by multiple teams, including Optimism, Flashbots, and Paradigm. Shipping a single feature required coordination across several external engineering teams and their release schedules. Hence, Base introduced a new unified stack. A new, unified stack for Base ChainExcited to share that we are evolving our technical roadmap, consisting of our own spec, code, and infra to accelerate the foundation of Base. This shift gives us the autonomy to ship protocol improvements more frequently and focus our…— wilson.base.eth (@WilsonCusack) February 18, 2026 Three specific objectives drove the migration decision: Faster shipping cadence: The previous schedule supported three hard forks per year. The base/base architecture supports six, with smaller, tightly scoped upgrade batches. This reduces risk per upgrade and shortens the feedback loop between design and production deployment. Reduced cognitive overhead: The protocol spec and codebase should be understandable by a single developer. Consolidating into base/base eliminates the need to cross-reference documentation across OP Stack, Flashbots’ builder infrastructure, and Paradigm’s Reth codebase separately. Alignment with Ethereum roadmap: Base is positioned to deploy high-impact Ethereum Improvement Proposals like BAL (EIP-7928) ahead of L1 to generate data that informs the Ethereum roadmap. A consolidated codebase makes this faster to execute. Architecture: before and after Let’s compare the earlier architecture to better understand the changes introduced. Before: Distributed multi-client architecture Base previously ran as a composite system: Consensus client: op-node (maintained by OP Labs / Optimism) Execution client: op-geth (canonical OP Stack execution client) or op-reth Block building: Flashbots builder infrastructure Fault proofs: Optimism Cannon, coordinated with OP Labs Sequencer: Separate binary, maintained across multiple repositories Each component had its own release cycle. Any upgrade to Base required coordination across Optimism, Flashbots, and in some cases Paradigm (for Reth-related changes). When a sequencer-level fix was needed, Base engineers had to coordinate with at least two external teams before shipping. After: Unified base/base architecture Source: https://blog.base.dev/next-chapter-for-base-chain-1 The base/base Stack: The unified repository lives at github.com/base/base. The unified stack ships one official distribution per upgrade. One binary. One release channel. One set of release notes to track. Core execution: Reth The execution client is Reth, the Rust-based Ethereum client built by Paradigm. Base adopted Reth progressively in late 2024, migrating archive nodes first, then sequencer infrastructure. Reth’s advantages for Base specifically: Disk usage grows at a fraction of the rate of op-geth (Geth archive nodes were projected to hit 30TB NVMe limits around May 2025 at prior growth rates; Reth’s storage model extends that timeline to the mid-2030s) Block building performance is measurably faster, enabling the safe increase to 150 Mgas/s The modular ExEx (Execution Extension) system allows Base to deploy custom extensions without modifying core client code Paradigm released Reth 2.0 in Q1 2026, achieving 1.7 Gigagas/s performance with a disk footprint of approximately 240 GB. Base’s production infrastructure uses op-reth, the OP Stack-compatible fork. Consensus: op-node derived The consensus client is derived from op-node but will be maintained entirely within base/base going forward. Bug fixes and protocol updates flow from the Base Engineering Team rather than OP Labs. Fault proofs The current system uses optimistic proofs. Base V1 will replace this with TEE (Trusted Execution Environment) and ZK proofs, enabling faster finality. The Kona fault proof program, a Reth-based implementation built by OP Labs, will replace the existing Cannon-based system after the Base V1 upgrade. Flashblocks: The Performance Layer Flashblocks is a preconfirmation system developed by Flashbots and deployed on Base. Rather than waiting for a 2-second block, the sequencer issues sub-blocks every 200 milliseconds. Block Structure: Flashblocks are partial blocks with committed transactions. Multiple Flashblocks form a final block. Transaction Signal: Transactions appear once executed by the builder. Apps receive inclusion signals in ~200ms. Transaction Ordering: Ordering is fixed per Flashblock, late transactions cannot modify already emitted Flashblocks. Reorg Handling: Flashblocks are not final, apps reading Flashblock state before finalization need to handle potential state rollbacks. Gas Constraints: Large transactions exceeding ~10% gas limit are delayed, they are included in later Flashblocks. RPC Compatibility: Works with standard Ethereum JSON-RPC : Use "pending" to access Flashblock state. curl -X POST <YOUR_CHAINSTACK_BASE_RPC_URL> \\ -H "Content-Type: application/json" \\ -d '{ "jsonrpc": "2.0", "id": 1, "method": "eth_getBlockByNumber", "params": ["pending", false] }' Fallback: Flashblocks maintains 99.9% uptime. If the infrastructure goes offline, the network automatically falls back to standard ~2-second block times 📖 Flashblocks is not exclusive to Base — to understand how it works across all supported chains, see What are Flashblocks? Superchain cross-chain messaging Before the migration, Base operated as part of a tightly integrated OP Stack ecosystem alongside chains like Optimism, sharing a common execution framework and cross-chain messaging layer. Superchain interoperability was being built around standardized messaging contracts like L2ToL2CrossDomainMessenger and CrossL2Inbox, with the goal of letting OP Stack chains pass messages directly without routing through Ethereum L1. It is worth noting that native Superchain interoperability was still rolling out iteratively at the time Base announced its migration. It was not yet a fully deployed production feature on Base when the announcement landed. Nothing changes immediately for developers or users. Base will remain compatible with the OP Stack specification including continued support for existing RPCs, and will continue upstreaming bug fixes and coordinating security disclosures to help keep the broader Superchain ecosystem safe. The divergence is forward-looking: as base/base evolves its own upgrade cycle, consensus client, and proof systems independently of OP Labs, Base will gradually move outside the native Superchain interop cluster. Over time, this may affect access to emerging OP Stack interop features like SuperchainERC20, while current functionality remains intact. The separation is technical, not adversarial and Base will continue working with Optimism as a client of OP Enterprise for mission-critical support. Hard fork roadmap Base published its hard fork schedule publicly for the next several months: ReleaseStatusKey ChangesBase V0Active• Unified repo established• Flashblock Access Lists for improved transaction speedBase V1Sepolia: 2026-04-20 18:00 UTC | Mainnet: TBD• Client consolidation to base/base• Optimistic proofs → TEE/ZK proofs• Fusaka Upgrade supportBase V2Upcoming• Block Access Lists (EIP – 7928)• New transaction types for protocol-level UX improvementsBase V3Planned• Upcoming Glamsterdam support• Opcode repricing• Base fee mechanics changes Base V1 is the critical migration boundary for node operators: Prior to V1, full backward compatibility with the previous execution specification is maintained After activation, legacy op-node + op-geth nodes will no longer remain compatible with the canonical chain Restricts supported node software to base-consensus and base-reth-node only Introduces multi-proof system using TEE and ZK components alongside optimistic assumptions for faster withdrawals and a path toward stronger decentralization Simplifies Flashblocks websocket format to improve consistency and reduce integration complexity Aligns Base with Ethereum Fusaka upgrade for improved data availability and rollup scalability. Learn more about the Fusaka upgrade. ⚠️ Mainnet activation is currently TBD, while Sepolia activation is scheduled for 2026-04-20 18:00:00 UTC. Base V2 Block Access Lists for block-level state access optimization New transaction types for improved execution efficiency and UX Reduced execution overhead under high network load No changes to EVM semantics Base V3 Support for Ethereum Glamsterdam upgrade Opcode repricing aligned with upstream EVM changes Base fee mechanism adjustments for improved fee market stability Continued alignment with Ethereum execution-layer roadmap What changes for node operators This section covers the migration steps for teams running Base nodes. Current state (before Base V1): Nodes running op-node (consensus) + op-geth or op-reth (execution) continue to function normally. Base remains fully compatible with the OP Stack specification. After Base V1: After Base V1, the following components are no longer supported for canonical sync: op-node op-geth standalone OP Stack op-reth Nethermind-based configurations Nodes using these clients will diverge after the upgrade boundary. ℹ️ Checkout the official announcement : https://blog.base.dev/next-chapter-for-base-chain-1 Required node stack LayerPreviousNewExecutionop-geth / op-rethbase-reth-nodeConsensusop-nodebase-consensus Migration steps From OP Reth → base-reth-node If you are already running OP Reth via base/node, update to the latest version and your node will automatically use base-reth-node. Your existing ./reth-data directory is fully compatible. No re-sync or snapshot restore is needed. Stop existing node Shutdown all running services before migration begins docker compose down Update Base node repository Pull the latest Base node configuration git pull origin main cd base/node Verify sync Confirm the node is running the Base stack correctly: web3_clientVersion Should include base in the version string (e.g. reth/v1.11.3-.../base/v0.7.0) Migrating from another client op-geth and nethermind are no longer supported. You must start fresh with base-reth-node. Stop existing node Shutdown all running services before migration begins docker compose down Update Base node repository Pull the latest Base node configuration git pull origin main cd base/node Remove deprecated execution state (if required) If you are running op-geth or Nethermind, you must reset execution data. rm-rf ./geth-data rm-rf ./nethermind-data Edit your .env.mainnet or .env.sepolia file to match your configuration preferences. Bootstrap from a Reth snapshot to avoid a full sync. Start your node docker compose up Migrating Consensus Layer Replace op-node with base-consensus by updating your environment configuration. Set in .env file: USE_BASE_CONSENSUS=true Update .env file from OP_NODE_* → BASE_NODE_* Restart your node docker compose up Verify Check consensus logs: docker compose logs -f node Confirm sync status: optimism_syncStatus continues to work. ℹ️ See the following document for detailed migration instructions and all new environment variables: https://docs.base.org/base-chain/node-operators/base-v1-upgrade What changes for developers For teams building applications on Base, not operating nodes: Nothing changes immediately: Contract addresses remain the same. Chain ID (8453) remains the same. All existing RPC endpoints continue to function. EVM behavior is identical. What gets better: The faster upgrade cadence means features move from proposal to production faster. The proof system upgrade in V1 (Optimistic → TEE/ZK) will enable faster withdrawal finality. Current optimistic fraud proof windows require a 7-day challenge period before L1 finalization; TEE/ZK proofs compress this significantly. Transaction ordering changes with Flashblocks: For protocols that depend on block-level ordering guarantees (MEV strategies, liquidation bots, arbitrage), the 200ms Flashblock window introduces a time-based ordering constraint. Once a Flashblock is sealed, its transaction ordering is final within that window. Smart contract deployments: No redeployments required. Existing contract addresses, ABIs, and event signatures are unaffected. Security and decentralization Base is a Stage 1 decentralized rollup. Upgrade authorization is enforced via a Security Council multisig, and state validity is enforced through permissionless fault proofs. Protocol upgrades require approval from a 12-member Security Council multisig (Coinbase + 11 independent entities). Execution requires a ≥9-of-12 threshold (75%). The Base Security Council currently includes members from organizations like Aerodrome, Moonwell, Blackbird, ChainSafe, and Talent Protocol, among others. Each member operates an independent key used for protocol upgrade and governance signing. Stage 1 properties: Permissionless fault proofs enabled Fraud proofs allow any actor to challenge invalid state transitions during the dispute window Upgrade execution requires 9-of-12 signatures No single entity has unilateral upgrade authority Separation between execution operation and upgrade authorization The Security Council composition replaces a prior external governance dependency with an independent signer, preserving the 12-member structure and 9-of-12 threshold while maintaining quorum integrity and reducing reliance on external coordination. Council responsibilities include protocol upgrade signing, key rotation approvals, signer replacement, key custody security, and liveness verification. Key compromise or loss is handled through coordinated rotation procedures that preserve quorum requirements without disrupting upgrade authority. Base is a transitional system targeting Stage 2, where upgrade authority is constrained by on-chain verifiable fault proofs and a multi-proof validation system (optimistic + TEE + ZK). Base V1 introduces early components of this model by integrating hybrid proving infrastructure, reducing reliance on social coordination for correctness. Key resources for node operators and builders Core Infrastructure base/base (GitHub): Unified stack repository. The canonical source for Base binary releases post-V1. base/node (GitHub): Node configuration repository. Docker configurations for Reth, Geth, and Nethermind. Base Documentation: Official developer documentation. EVM Tooling Foundry: Smart contract development framework. Works with Base without modification. Wagmi: React hooks for Ethereum. Supported and actively contributed to by Base Engineering. viem: TypeScript interface for Ethereum. Base is a built-in chain definition. Hardhat: Ethereum development environment. Full Base compatibility. Flashblocks Flashblocks Demo: Live testnet demo of Flashblocks latency. Flashblocks Docs: Integration guide for apps, wallets, and indexers. transaction-latency tester (GitHub): Tool for benchmarking transaction inclusion times with and without Flashblocks. Conclusion The base/base migration resolves a structural tension that had been building since Base’s launch: a chain with the largest TVL in the Superchain was still dependent on external teams to ship protocol changes. base/base eliminates that dependency. The EVM semantics, chain ID, contract addresses, and JSON-RPC interface are unchanged. But the infrastructure beneath them is now Base’s to control — and to upgrade six times a year instead of three. What this means by audience: Node operators: Base V1 on Sepolia activates 2026-04-20 at 18:00 UTC. Test your migration from op-node + op-geth to base-consensus + base-reth-node on Sepolia now. Mainnet date is TBD — watch the base/base release channel. App developers: No action required in this phase. Watch for withdrawal finality improvements in V1 and Block Access Lists in V2. DeFi / MEV teams: Review your ordering assumptions against Flashblocks’ 200ms sub-block windows. Managed infrastructure users: Chainstack’s Base nodes are already on the base/base stack. No migration steps required on your end. Running your own Base node? If the migration overhead isn’t worth it for your team, Chainstack offers managed Base nodes with no infra management required. Get started free → FAQ Do I need to resync from scratch when migrating to base-reth-node? Only if you are coming from op-geth or Nethermind. If you are already running OP Reth via base/node, your existing ./reth-data directory is fully compatible — no resync or snapshot restore needed. For op-geth and Nethermind operators, delete the old execution data and bootstrap from a Reth snapshot to avoid a full sync. When does Base V1 activate on mainnet? Mainnet activation is currently TBD. Sepolia activates on 2026-04-20 at 18:00 UTC. Monitor the base/base GitHub releases and the official Base blog for the mainnet announcement. Test your migration on Sepolia before mainnet goes live. Does the chain ID change? No. Chain ID 8453 is unchanged across this migration. No wallet or dApp configuration updates are needed. Do the optimism_* RPC methods still work after the migration? Yes. All optimism_* namespace methods — including optimism_syncStatus — remain fully supported in base/base. No RPC changes are required for node operators or application developers. What happens to Nethermind support? Nethermind is no longer supported for canonical sync after Base V1. Operators running Nethermind must migrate to base-reth-node before the upgrade boundary and start fresh — Nethermind data is not compatible with Reth’s storage format. What is the 7-day withdrawal window and when does it get shorter? Currently, withdrawing assets from Base to Ethereum L1 requires a seven-day challenge period — the dispute window during which anyone can submit a fraud proof challenging an invalid state transition. Base V1 introduces TEE and ZK proofs that compress this window substantially. The exact finality times for TEE/ZK-proven withdrawals will be published by the Base Engineering Team closer to V1 mainnet activation. Related Reading Flashblocks on Base: 200ms preconfirmations for lightning-fast UX How to get a Base public RPC endpoint Best Ethereum RPC providers in 2026 Base: Deploy an ERC-721 contract with Hardhat Best Base RPC providers for onchain applications in 2026 #### Base Faucet: How to get free Base testnet ETH Base is an Ethereum L2 built for onchain applications — fast, low-cost, and fully EVM-compatible. To test applications before deploying to production, developers typically rely on a Base faucet to get testnet ETH. Whether you’re building consumer apps, DeFi protocols, or payment flows, you’ll need testnet ETH before anything goes to mainnet. The Chainstack Base faucet gives you 0.5 ETH every 24 hours with no Twitter gate, no friction. Just sign in, paste your wallet address, and start building. How the Chainstack Base faucet works Before you push anything to mainnet, you dry-run the flow — deploy a contract, test stablecoin transfers, fire transactions against a Base testnet RPC, or validate payment and settlement logic. For any of that, you need ETH. We’re one of the first to ship a Base faucet built for that. It’s tied to your wallet address and lets you claim 0.5 ETH every 24 hours, with no Twitter authentication in the mix. Just sign in, point it at your wallet, and you’re ready to test. From there, you can use your balance to cover gas on testnet, validate smart contract deployments on Base, or run automated checks in your dev loop. And when you’re ready to go beyond test tokens, you can deploy a Base node in the console and plug into mainnet or testnet RPCs all in one place. ⚠️ Faucet requirements: To safeguard against misuse, the Chainstack faucet implements two key checksbefore disbursing funds: The requesting address must have a minimum balance of 0.08 ETH on theEthereum mainnet. The address should have a history of holding ETH on the mainnet; it shouldnot have been recently empty. These precautions help maintain the integrity of the faucet, ensuring fair andequitable access for all users. How to use the Base testnet faucet on Chainstack Getting test ETH from our Base faucet is simple. Sign in — Log into your Chainstack console. Get your API key — In the console, go to Settings → API keys and copy an active key. You’ll need it to authenticate with the faucet. Open the faucet — Navigate to the Base faucet page and paste your API key when prompted. Enter your wallet address — Paste the address you want to fund. Claim tokens — Submit the claim. You’ll receive 0.5 ETH every 24 hours. Confirm balance — Check your wallet or query your Base RPC endpoint. Once your wallet has balance, you can use it to pay gas on testnet, deploy contracts, or run integration scripts against the Base testnet. If you need stable, high-performance infrastructure, alongside tokens, you can spin up a Global Node for quick tests or a Dedicated Node for latency-sensitive workloads. Both expose HTTPS and WebSocket RPC URLs that slot straight into wallets, frameworks, or custom tooling. Get test ETH now → What you can do with Base testnet ETH On Base, nothing moves without ETH, even on testnet. ETH pays gas for contract deployments, transaction calls, and anything routed through a Base testnet RPC. That makes a Base faucet the starting point for testing real workloads before going to mainnet. With testnet ETH, you can: Test stablecoin settlement flows and payment infrastructure Simulate DeFi activity like swaps, lending, and liquidation checks Run bots or automation scripts against real RPC responses Stress-test AI agents or keeper logic under bursty request patterns Backtest protocol logic without risking real funds Once you’ve got tokens in your wallet, the next step is to connect them to infrastructure you control. In the Chainstack console, you can spin up a Base node, copy the HTTPS or WebSocket RPC URL, and start routing calls through your own endpoint. To explore production workloads on Base — from stablecoin settlement to DeFi protocols and AI agents — see the detailed breakdown of Base RPC providers and infrastructure use cases. Deploy a Base node → Base tooling Beyond the faucet and nodes, Base provides developer tooling you can integrate into your stack. You can interact with the network using standard EVM-compatible tooling over JSON-RPC, making it easy to work with smart contracts, query chain state, and run automated workflows. Base works with familiar Ethereum developer tools and libraries, allowing you to reuse existing Solidity code, frameworks, and scripts without custom integrations. For the full set of SDKs, APIs, and integration guides, check the Base tooling docs. Chainstack also supports Flashblocks on Base — 200ms transaction preconfirmations for latency-sensitive apps. Wrap up: more for Base builders Faucet ETH gets you moving, but production-grade stablecoin and payment workflows need more than just gas. On Chainstack, you can run a reliable Base RPC infrastructure to query historical data, debug transactions, and stream state changes over WebSocket connections. If you prefer starting from code, Chainstack provides examples and reference implementations that show how to interact with Base RPC endpoints using standard EVM-compatible tooling. The Base API refers to the standard Ethereum-compatible JSON-RPC interface exposed by Base RPC nodes. Between the faucet, stable RPC infrastructure (Global or Dedicated Nodes), and up-to-date documentation, you get an end-to-end setup: test with faucet tokens, validate against production-like infrastructure, and move to mainnet without reworking your stack. FAQ How do I get Base testnet ETH? From the Chainstack Base faucet — 0.5 ETH every 24 hours, no social login required. Is Base EVM-compatible? Fully. Deploy Solidity contracts and use any standard Ethereum tooling without modification. What’s testnet ETH for? Gas. It covers contract deployments, transaction calls, and RPC interactions on Base testnet. Can I test smart contracts on Base testnet? Yes — that’s exactly what it’s for. Deploy, run scripts, validate integrations, then move to mainnet. Are there rate limits on RPC endpoints? Public endpoints are shared and rate-limited. For consistent throughput, use a dedicated Chainstack node. Additional resources Flashblocks on Base: 200ms preconfirmations for lightning-fast UX How to get a Base public RPC endpoint Best Base RPC providers in 2026 Base: Deploy an ERC-721 contract with Hardhat #### Base RPC for AI agents: infrastructure and setup (2026) TL;DR LLMs gave AI agents the ability to answer questions, analyze information, write code, and plan complex tasks. But an LLM’s capabilities stop at the point of execution, limiting them to being a copilot. To become truly autonomous, they need infrastructure that enables them to take action. Give your agents wallets, onchain identities, and the ability to execute transactions, interact with smart contracts, and perform onchain actions — all through a single Base RPC — to build production-ready AI agents with Base AgentKit, powered by the x402 protocol. Prerequisites Before setting up an AI agent on Base, have the following ready: Node.js 18+ or Python 3.10+, depending on your SDK choice An LLM provider API key (OpenAI, Anthropic, or any framework-compatible model) A Base RPC endpoint from a dedicated infrastructure provider Familiarity with basic wallet concepts: private keys, gas, and transaction signing A package manager: npm/pnpm for TypeScript, pip/poetry for Python What are Base Agents (and what is AgentKit)? It all started with a dormant HTTP status code: 402 Payment Required. Originally reserved for a web-native payment flow for future use, HTTP 402 has found a new purpose onchain with AI agents. 📖 Learn more about how the HTTP 402 status code is being used by the x402 protocol. AI agents are no longer limited to answering questions. They can hold wallets, execute transactions, manage liquidity, deploy contracts, and interact with decentralized applications autonomously. Built by Coinbase, Base provides a low-cost, high-throughput environment that makes autonomous onchain actions economically viable. Combined with frameworks like AgentKit, developers can build AI agents capable of interacting with smart contracts, managing assets, and executing complex workflows onchain. Base AgentKit provides the core infrastructure for building autonomous onchain agents, abstracting away wallet management, transaction execution, and payment flows into reusable components so developers can focus on agent logic. AgentKit equips agents with everything they need to operate onchain: Built-in agent skills. Plug-and-play actions such as authentication, funding, transfers, trading, and earning, without implementing transaction logic from scratch. Native x402 support. A payment protocol designed for machine-to-machine interactions, enabling agents to pay for APIs, compute, and services programmatically. Gasless execution on Base. Keep agents running continuously without manually managing gas balances. Agent CLI. Provision wallets, fund agents, and manage capabilities from the command line in minutes. Security by default. Programmable spending limits, secure key isolation, and compliance guardrails powered by Coinbase’s infrastructure. As agent frameworks mature, the challenge shifts away from model capabilities and toward infrastructure reliability. An AI agent that misses a market opportunity because of stale blockchain data, fails a transaction due to rate limits, or loses context because of inconsistent RPC responses quickly becomes unusable in production. Chainstack provides the infrastructure that supports every stage of an AI agent’s onchain workflow: Read onchain data. Query balances, token prices, contract state, events, and historical data through high-performance RPC endpoints, indexed APIs, or ingest the entire Chainstack documentation as a structured knowledge source using chainstack.com/llms.txt or the more comprehensive llms-full.txt. Sign and execute transactions. Connect AgentKit wallets or other custody solutions to securely submit transactions. With a Chainstack API key, agents can also deploy and manage blockchain nodes that power transaction execution. Make programmable payments. Integrate payment protocols such as x402 to let agents pay for APIs, compute, and other machine-to-machine services as part of autonomous workflows. Swap and bridge assets. Build agents that automatically swap tokens, rebalance portfolios, and bridge assets across supported blockchain networks using onchain protocols. Participate in governance. Enable agents to monitor proposals, delegate voting power, and cast votes across DAOs based on predefined policies. Build onchain identity. Create attestations, establish reputation, and integrate with identity standards such as ERC-8004, allowing agents to become trusted participants in decentralized ecosystems. AgentKit enables agents to act onchain, while Chainstack MCP gives them direct access to the blockchain infrastructure they need. Compatible with Claude Code, Cursor, Codex, ChatGPT, Gemini, and other MCP-enabled assistants. Base RPC infrastructure for AI agents: endpoints, WebSocket, Flashblocks Base provides a fully Ethereum-compatible JSON-RPC interface and was originally built on the OP Stack, maintaining compatibility with the OP Stack specification. It has since evolved into the unified base/base stack, consolidating sequencer, consensus, execution, and fault-proof components into a Reth-based architecture (base-reth-node + base-consensus) to improve scalability, upgrade velocity, and operational efficiency. This architecture introduces Flashblocks (~200ms preconfirmations), optimized state management, and a modular foundation for advanced TEE/ZK proving systems while exposing a fully Ethereum-compatible JSON-RPC interface. 📖 If you are building AI agents or making RPC calls through AgentKit, the base/base node-software migration does not affect you. The JSON-RPC interface, chain ID, and contract addresses stay the same, and Chainstack handles the underlying node transition. If you run your own Base node, operate validating infrastructure, or are otherwise affected at the node-software layer, refer to the Base chain migration guide: from OP Stack to base/base. Production RPC through Chainstack provides access to Base Mainnet and Base Sepolia with JSON-RPC methods, WebSocket connectivity, archive infrastructure, and Flashblocks-aware endpoints for sub-second preconfirmations. Base RPC is available on both Mainnet and Sepolia. Mainnet Chain ID: 8453 HTTPS: https://base-mainnet.core.chainstack.com WebSocket: wss://base-mainnet.core.chainstack.com Testnet (Sepolia) Chain ID: 84532 HTTPS: https://base-sepolia.core.chainstack.com Since Base exposes the standard Ethereum JSON-RPC interface, common methods work exactly as they do on Ethereum. For example, you can retrieve the latest block number using eth_blockNumber: const options = { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', method: 'eth_blockNumber', id: 1 }) }; fetch('https://base-mainnet.core.chainstack.com/<KEY>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Production applications often rely on WebSocket connections for real-time updates such as new blocks, pending transactions, and contract events. Chainstack provides dedicated WebSocket endpoints for Base: wss://base-mainnet.core.chainstack.com ⚠️ The public Base RPC URLs do not support WebSocket connections. If your application requires subscriptions such as eth_subscribe or real-time event streaming, use a dedicated provider such as Chainstack. The following example subscribes to newly produced Flashblock transactions using eth_subscribe: const WebSocket = require('ws'); const webSocket = new WebSocket('CHAINSTACK_WSS_URL'); async function subscribeToFlashblockTransactions() { const request = { id: 1, jsonrpc: '2.0', method: 'eth_subscribe', params: ['newFlashblockTransactions'], }; const onOpen = (event) => { webSocket.send(JSON.stringify(request)); }; const onMessage = (event) => { const response = JSON.parse(event.data); console.log(response); }; try { webSocket.addEventListener('open', onOpen); webSocket.addEventListener('message', onMessage); } catch (error) { console.error(error); } } subscribeToFlashblockTransactions(); For agent code that reads balances or nonces ahead of a transaction, an AgentKit action provider can request preconfirmed state by passing pending instead of latest on eth_getBalance or eth_getTransactionCount, cutting the effective wait for fresh state from roughly 2000ms down to 300–500ms. Chainstack’s Base nodes also support the eth_subscribe, newFlashblockTransactions, and pendingLogs subscription types over WebSocket, for agents that need to react to individual preconfirmed transactions or filtered event logs rather than polling. Archive-enabled infrastructure also supports advanced debugging methods such as debug_traceTransaction, useful for reconstructing exactly how an agent’s transaction executed after the fact: const options = { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', method: 'debug_traceTransaction', id: 1, params: ['0x317888c89fe0914c6d11be51acf758742afbe0cf1fdac11f19d35d6ed652ac29'] }) }; fetch('https://base-mainnet.core.chainstack.com/<KEY>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Transactions are submitted to the Base sequencer through the standard eth_sendRawTransaction RPC method. The following example sends a signed transaction to the sequencer: const options = { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', method: 'eth_sendRawTransaction', id: 1, params: ['0xsigned_tx'] }) }; fetch('https://base-mainnet.core.chainstack.com/<KEY>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Once the sequencer accepts the transaction, the standard block includes it within roughly 2 seconds — or as fast as 200ms if reading through the Flashblocks-aware pending tag. Full finality against Ethereum L1 follows separately, in roughly 15 to 20 minutes once the batch is posted and finalized. Base has no public mempool, since a single sequencer orders transactions, which means the RPC endpoint an agent submits through is the only path in, making endpoint latency a direct factor in inclusion speed. For a complete reference covering supported endpoints, authentication, archive access, WebSocket connectivity, and Flashblocks integration, see the Base documentation. How to set up a Base AI agent with Chainstack MCP Provisioning RPC infrastructure manually — opening a console, clicking through project settings, copying an endpoint — is a workflow built for humans. An agent’s RPC traffic profile differs from a typical dApp frontend in a specific way: it is bursty and event-triggered rather than steady and human-paced. A liquidation-scanning agent might issue a handful of calls per minute during quiet markets, then fire hundreds of eth_call and eth_getLogs requests within seconds when a price move triggers its logic. Infrastructure that rate-limits aggressively or bills unpredictably under burst conditions becomes the actual bottleneck, not the LLM. MCP (Model Context Protocol) shifts blockchain infrastructure from raw JSON-RPC requests to a structured tool interface designed for AI agents. Rather than constructing payloads such as eth_getBalance or parsing hexadecimal RPC responses, an agent invokes typed tools like get_balance with named parameters and receives structured outputs it can reason about directly. The underlying communication still uses JSON-RPC, but MCP abstracts node interactions into discoverable, self-describing capabilities that are significantly easier for LLMs to orchestrate autonomously. Through the Chainstack MCP server, exposed as a remote Streamable HTTP endpoint at mcp.chainstack.com, AI agents can provision blockchain nodes, retrieve RPC endpoints, search documentation, monitor platform status, and access pricing information directly from a prompt. Connect Chainstack MCP in Claude Code Paste this into Claude Code or Claude Desktop chat: get mcp.chainstack.com Option 1: Skill mode (no MCP registration) The agent pulls a SKILL.md on demand and calls tools over HTTP without keeping them loaded in context every session. mkdir -p ~/.claude/skills/chainstack curl -o ~/.claude/skills/chainstack/SKILL.md https://mcp.chainstack.com/skill Option 2: Register as an MCP server Tools stay available in every session. claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp # Available across all projects: claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp --scope user # Verify: claude mcp list Passing the Chainstack Platform API key: claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp \ --header "Authorization: Bearer YOUR_API_KEY" -s user Windsurf, GitHub Copilot, Gemini CLI, Antigravity, Claude.ai, and ChatGPT are all supported; the fastest way into any of them is simply typing get mcp.chainstack.com into the agent, which fetches the onboarding page and self-configures. Full connection guides are available for Claude and Codex. What Chainstack MCP tools are available Tool access is split into two tiers. No API key needed. Works immediately, no account required. ToolDescriptionsearch_docsSearch Chainstack documentationget_doc_pageFetch the full content of a documentation pageget_platform_statusCheck platform status, active incidents, and network healthcontact_chainstackSubmit a message to the Chainstack teamget_chainstack_pricingFetch a live Chainstack pricing snapshot API key required. All tools appear in the agent’s tool list regardless of auth. The tools below execute only when the key is configured. Calls without it return an auth error. ToolDescriptionget_organizationGet organization name and IDget_deployment_optionsList available blockchain/cloud/region combinationslist_projectsList all projectscreate_projectCreate a new projectget_projectGet project detailsupdate_projectUpdate a project’s name or descriptiondelete_projectDelete a projectlist_nodesList all nodes with status and endpointsget_nodeGet a node’s full details including RPC endpointscreate_nodeDeploy a new blockchain nodeupdate_nodeRename a nodedelete_nodeDelete a noderequest_testnet_fundsTop up a testnet address from the Chainstack faucet How to deploy a Base node by prompt With the server registered, provisioning the Base RPC endpoint for your agent becomes a single prompt inside your coding assistant: Deploy a Base mainnet Global Node on Chainstack and give me the HTTPS endpoint. The agent calls create_node with the Base protocol and mainnet network, then get_node to return the live HTTPS and WSS endpoints, ready to drop directly into your AgentKit wallet provider configuration. The same pattern works for Base Sepolia during testing: Create a Base Sepolia node with Chainstack and show me the RPC endpoint. Other prompts worth knowing while building: What's the correct method to get an account's ETH balance on Base? Write the call. This routes through search_docs and get_doc_page, so the agent grounds its answer in Chainstack’s actual RPC reference instead of generating a plausible-looking but incorrect method signature — a common failure mode when LLMs write blockchain code from memory. Any upcoming maintenance on Base I should plan around? This calls get_platform_status, useful for scheduling agent deployments or pausing a live trading agent ahead of a known maintenance window. Trace transaction [signedTx] and explain what happened step by step. For migrating an existing agent off another provider, the MCP server can inventory current usage and estimate savings directly, since Chainstack bills 1 request unit per standard call and 2 for archive or debug/trace calls, with no per-method multiplier — a structural difference from providers that weight individual methods at 20 to 26 times a base call. I'm on a provider spending ~$2k/mo on these methods. Assess my setup, plan the move to Chainstack, and tell me how much I'd save. Tools for building AI agents on Base Build the next generation of AI agents on Base using the builder tools below: AgentKit SDK (TypeScript & Python) — Open-source framework for building autonomous onchain AI agents with wallet management, transaction execution, and built-in agent actions. Model Context Protocol (MCP) — AgentKit support for MCP-compatible AI assistants and development environments. Base Agents Overview — Introduction to the Base agent ecosystem, architecture, and capabilities. Base Agent Documentation — Resources for deploying, configuring, and scaling autonomous agents on Base. Chainstack MCP server — Official guide for connecting AI assistants to Base through MCP and building agent-powered applications. Chainstack llms.txt — Structured documentation context optimized for AI assistants and LLM-powered workflows. Coinbase Developer Platform (CDP) — API key management, wallet infrastructure, and developer tooling for Base applications. x402 Protocol — Documentation and tooling for machine-to-machine payments and autonomous agent transactions. Claude Code — MCP-compatible coding environment for building and provisioning Base agent infrastructure. Cursor — AI-native development environment with MCP support for blockchain workflows. GitHub Copilot — AI-assisted coding platform compatible with Chainstack MCP tools. Gemini CLI — Command-line AI assistant with support for MCP-based blockchain infrastructure management. Codex — MCP-enabled AI assistant by ChatGPT capable of provisioning infrastructure and interacting with blockchain development tools directly from natural language prompts. Considerations Testnet-first development is not optional. Every action provider should be exercised on base-sepolia, including failure paths, before any mainnet key is funded. Use eth_simulateV1 before submission. Simulating a multi-step transaction sequence in a single call catches failures before gas is spent, which matters for an autonomous agent that cannot manually retry a failed transaction the way a human would. Implement application-level failover. An agent that depends on a single RPC endpoint fails completely when that endpoint has an incident. Chainstack’s Global Nodes provide built-in geo-failover, so a regional degradation reroutes automatically without additional application logic. Monitor nonce. Agents that submit transactions in quick succession are prone to nonce collisions if two tool calls race. Track the expected nonce in application state rather than re-fetching it from eth_getTransactionCount for every submission. Custody model shapes risk. A CDP-managed MPC wallet, a Privy embedded wallet, and a self-managed viem signer each carry different operational and security trade-offs. The right choice depends on whether the agent’s funds are custodial, semi-custodial, or fully self-directed by the end user. Set spending guardrails. Prompt instructions telling an LLM to limit spend are not a security boundary. Enforce transaction value limits and allow-listed contract addresses in the wallet provider or action provider logic itself. Log every action provider call. Since agents act autonomously, a clear audit trail of what was called, with what parameters, and what the RPC response was, is the primary tool for debugging unexpected agent behavior. Conclusion Building an AI agent on Base comes down to three coordinated layers: an LLM that reasons about actions, AgentKit that translates those decisions into structured wallet and contract operations, and Chainstack’s Base RPC that reliably executes them onchain. The first two layers are increasingly standardized through Coinbase’s open-source tooling. The third is where most production incidents originate, since agent traffic is bursty in a way that most RPC pricing models were not designed to absorb gracefully. Chainstack’s request-based pricing, archive and trace support, and geo-failover infrastructure address this mismatch directly, making it a practical foundation for AgentKit deployments moving from prototype to production on Base. Setting it up no longer requires leaving the coding assistant: register the Chainstack MCP server, provision a Base node by prompt, and drop the returned endpoint straight into your AgentKit wallet provider. Deploy a Base node on Chainstack → FAQs What is Base AgentKit and why is it useful for AI agents? Base AgentKit is an open-source framework from Coinbase that helps developers build AI agents capable of performing onchain actions. Instead of manually handling wallets, transaction signing, payments, and smart contract interactions, developers can use AgentKit’s built-in tools to give agents the ability to transfer assets, interact with decentralized applications, and execute blockchain transactions autonomously. Can I build and test my AI agent on Base Sepolia before deploying to mainnet? Yes. Base Sepolia is the recommended environment for development and testing. Developers should validate wallet operations, smart contract interactions, transaction simulations, and error-handling workflows on Base Sepolia before funding wallets or deploying agents on Base Mainnet. This approach helps identify issues early and reduces the risk of costly mistakes. Fund your testnet wallet through the Chainstack Base Sepolia faucet. What is the x402 protocol and how does it help AI agents? The x402 protocol repurposes the HTTP 402 Payment Required status code to enable machine-to-machine payments. For AI agents, this creates a standardized way to pay for APIs, compute resources, infrastructure services, and other digital products programmatically. Combined with AgentKit, x402 allows agents to participate in autonomous economic activities without requiring manual payment approvals. How can AI agents benefit from Flashblocks on Base? Flashblocks provide preconfirmations that can make blockchain state available in as little as a few hundred milliseconds. By reading pending state and subscribing to Flashblock-related events, AI agents can react more quickly to market changes, monitor transactions in near real time, and execute time-sensitive workflows with lower latency than waiting for full block confirmations. Is MCP required to use Base AgentKit? No. AgentKit can be used independently with any compatible RPC endpoint. However, MCP significantly improves the developer experience by allowing AI coding assistants to provision infrastructure, retrieve documentation, monitor platform status, and manage blockchain resources through structured tools instead of raw API calls. This makes agent development faster and more automated. What are the most important security considerations when deploying AI agents on Base? Security should focus on wallet custody, spending limits, transaction validation, and audit logging. Developers should enforce hard transaction limits in code, maintain detailed logs of every onchain action, carefully manage private keys or MPC wallets, monitor nonce handling, and test extensively on Base Sepolia before deploying agents with access to real funds. Related Chainstack articles What is B20? Base’s new native token standard explained Base transaction lifecycle: sequencer, finality, and RPC Base migration: from OP Stack to base/base Best Base RPC providers in 2026 How to get a Base RPC endpoint for AI agents (2026 guide) #### Base transaction lifecycle: sequencer, finality, and RPC TL;DR Base transactions move through five confirmation stages — from a 200ms sequencer preconfirmation to full Ethereum finality at ~15 minutes. Speed is the product, but speed isn’t finality. Most bugs on Base trace to one mistake: reading latest (2s, reversible) where the code needed safe (5–10 min, batch on Ethereum) or finalized (15–20 min, validators signed off). Withdrawals back to Ethereum wait an additional 7 days for fraud challenges. Pick the confirmation tier whose failure mode you can live with. How Base got here By 2022, Coinbase had a problem that every fee spike on Ethereum made worse. Their users wanted to swap, mint, and move money on-chain, but L1 gas was eating the experience alive. The obvious fix was a chain of their own. The unobvious part was how to get there without spending three years writing a rollup from scratch. So they didn’t. They picked up the OP Stack, already audited, already EVM-compatible, already running Optimism in production, and used it as the foundation for Base. The trade-off was deliberate: ship something real in months, accept that the sequencer — the node that receives transactions, orders them, and builds blocks — would be a single Coinbase-run node on day one, and lean on Ethereum for the parts that actually need to be trustless. Base was announced in February 2023 and went live on mainnet on August 9, 2023. Within a year it was the busiest Ethereum Layer 2 by daily transactions. No native token, no separate gas asset, no governance theater. Just a chain that settles to Ethereum and gets out of the way. Two decisions from that origin still shape every Base transaction today: One sequencer, run by Coinbase. Speed over decentralization. Your transaction has one way in. A 7-day withdrawal window, from optimistic rollup design. Deposits feel instant. Exits feel slow. One more was added later, once the UX gap became obvious: Flashblocks, shipped mid-2025, cut the confirmation wait from 2 seconds to 200ms without changing the underlying architecture. The path of a Base transaction 1. Submission via RPC You sign a transaction in a wallet or backend, send it to a Base RPC endpoint, and it lands in the sequencer’s mempool. Base has one sequencer (Coinbase), so unlike Ethereum there’s no public mempool gossip. The sequencer has no public mempool, so an RPC endpoint is the only way in. Slower endpoints mean later inclusion. 2. Flashblocks: a 200ms preconfirmation Every 200ms, Base’s sequencer emits a partial block update called a Flashblock. Flashblocks went live on Base mainnet in July 2025 and were built by Flashbots as an add-on to the OP Stack. They give your UI something to render long before the next 2-second block is finalized. A Flashblock is a preconfirmation. Coinbase has accepted the transaction but hasn’t finalized a full block. Treat Flashblock state as a hint for UX, like showing a balance change or animating a swap result. Reading it needs a Flashblocks-aware endpoint that subscribes to the stream over WebSocket. Chainstack offers one at Flashblocks on Base via Chainstack RPC. 3. Sequencer block: the soft confirmation Every 2 seconds, the sequencer finalizes a full block and your transaction gets a receipt. This is what most code calls “confirmed” today, and what eth_blockNumber returns by default. You can read its state with the latest block tag. At the latest stage, the only entity that has committed to this block is Coinbase’s sequencer. The data hasn’t been posted to Ethereum yet — it lives entirely on Base’s infrastructure. If the sequencer resets or rolls back, these blocks can be rewritten. Transactions you saw in a latest block could end up in a different position, or not included at all. This is what a sequencer reorg looks like: not a malicious attack, usually just a restart or a bug, but the result is the same — state you read from latest no longer matches the chain. In normal operation this rarely happens. But “rarely” is the wrong frame when the cost of being wrong is money. If you’re displaying a balance in a UI, a brief flicker from a reorg is annoying but recoverable. If you’re crediting a user deposit, releasing held funds, or recording a payment as settled, a reorg means you acted on state that no longer exists. The safe block tag exists precisely for this: it only advances once the batch has landed on Ethereum, removing the sequencer’s ability to reorder it. 4. Batch posted to L1 and the safe tier Every few minutes, Base’s batcher service compresses a span of recent blocks and posts the data to Ethereum. Since EIP-4844 (an Ethereum upgrade from March 2024), Base posts these batches as blob data rather than calldata. Blobs are a cheaper way to attach large chunks of data to an Ethereum transaction — Ethereum nodes store them temporarily and delete the raw data after around 18 days. But before deletion, a cryptographic fingerprint of each blob is permanently recorded on-chain, which is enough to prove the data existed and was committed to. The sequencer also posts a state root for those blocks via the proposer contract. What gets posted is enough to reconstruct the state. If the Base sequencer disappeared tomorrow, anyone could replay the L1 data and rebuild the chain. Once the batch lands in an Ethereum block, Base nodes mark the corresponding L2 blocks as safe. You can read that state with the safe block tag in any standard JSON-RPC call. Coinbase can no longer reorder or drop these transactions — doing so would require reorging Ethereum itself, which is theoretically possible but extremely rare in practice. 5. L1 finality and the finalized tier About two Ethereum epochs (~13 minutes, depending on slot position) after the L1 block holding the batch is included, that block gets finalized by Ethereum’s validator set. Base nodes then mark the corresponding L2 blocks as finalized. This is a stronger guarantee than safe. At the safe stage, an Ethereum reorg — however unlikely — could still undo the block. Once finalized, Ethereum validators have collectively signed off on that block being permanent. Reversing it would require a catastrophic consensus failure: corrupting or slashing over a third of all Ethereum validators simultaneously. In practice, this is treated as impossible. 6. The 7-day fault-proof window Withdrawals from Base to Ethereum wait 7 days. Base shipped permissionless fault proofs on October 30, 2024, which means anyone can challenge a fraudulent state root during this window. If a challenge is submitted, smart contracts on Ethereum run the verification and act as the final judge — if the fraud proof holds, the bad state root gets rejected. Deposits from L1 to L2 don’t wait. Only exits do. End users feel this part of the lifecycle the most. A deposit feels instant, a withdrawal feels broken. UX should communicate the delay up front. Why this matters for builders Treat Base like Ethereum and you’ll ship bugs. Apps that credit users on latest lose money when the sequencer rolls back. Withdrawal flows surprise users when they discover the 7-day exit. Indexers miss reorgs because Base’s WebSocket stream doesn’t behave the way Ethereum’s does. Each has the same cause: the wrong confirmation tier for what the code was doing. Confirmation tiers cheat sheet TierTimeWhat it meansUse it forFlashblock200msSequencer preconf, no block yetUI feedback, gameplaylatest2sSequencer block, no L1 dataDisplay balancessafe~5–10 minBatch on EthereumPayments, swapsfinalized~15–20 minL1 block finalizedBridge accounting, treasury The general rule: pick the lowest tier whose failure mode you can absorb. A reverted UI animation is fine. A reverted USDC transfer is not. RPC design implications Your app talks to Base through an RPC endpoint. Every query you make, whether checking a balance, reading a log, or fetching a transaction receipt, hits that node and gets answered based on whatever state the node has at that moment. The problem is that “what state the node has” depends on which confirmation tier you’re reading from. And most RPC methods let you choose — they just default to the most recent tier, which is also the least reliable. Pick the right block tag When you call methods like eth_getBalance, eth_call, eth_getLogs, or eth_getTransactionReceipt, you can pass a block tag alongside your request to tell the node which confirmation tier to read from: latest, safe, or finalized — the same tiers covered above. Most RPC libraries default to latest if you don’t specify, which is wrong for releasing held funds, or recording a settlement. Those actions need safe at minimum. The staleness is the cost: reading at safe means your answer is ~5–10 minutes behind the tip of the chain. For most financial logic, that trade is worth it. For real-time UI updates, it isn’t. The key is to be intentional — know which tag you’re using and why. A common mistake is mixing tiers without realizing it. An indexer might fetch the latest events with latest for speed, then key the database records by block hash. If the sequencer later reorgs those blocks, the hashes in your database no longer exist on the canonical chain. You read at one tier, stored at another, and the mismatch corrupts your data. Handle sequencer reorgs A sequencer reorg happens when the sequencer discards blocks it already broadcast and replaces them with a different set. This isn’t an attack — it usually happens when the sequencer restarts or fixes a bug. But the effect on your code is the same: blocks you saw as latest might disappear, and their transactions might reappear at a different block height or not at all. If your indexer reads at latest, there are two reliable signals to watch for reorgs: removed: true on log subscriptions. When you subscribe to logs via eth_subscribe(“logs”, …), the node emits removed events for any log that belonged to a reorged-out block. This is the standard JSON-RPC mechanism and it works reliably — as long as your WebSocket connection stays live. If the connection drops during a reorg, you will miss the removed events and wake up with stale state. On reconnect, re-fetch logs from the last block hash you trust rather than resuming from the latest block number. Block hash conflicts on newHeads. Subscribe to eth_subscribe(“newHeads”) and track the hash for each block height you process. If a new head arrives at a height you’ve already seen with a different hash — that’s a reorg. Roll back everything you stored for that height and above, then reprocess from the new canonical block. These two signals together cover the reorg surface. Conclusion Base moves fast by design. The sequencer takes your transaction in 200ms, a block lands in 2 seconds, and the chain handles more daily transactions than any other Ethereum L2. That speed is the product, and it works — until you write code that assumes speed means finality. Every stage in the lifecycle exists because something can still go wrong at the stage before it. The sequencer can roll back. The batch might not land on L1 immediately. Even an Ethereum block can be reorged before validators sign off. Each confirmation tier is a reduction in that risk, not an elimination of it — until finalized, where the remaining risk is effectively zero for any practical purpose. The bugs that burn builders on Base usually trace back to one misstep: using latest in a place that needed safe, or skipping reorg handling because it “never happens in practice.” The fix is the same in every case — match the confirmation tier to the consequence. Getting that match right also depends on the endpoint behind it. Chainstack’s Base RPC supports every tier covered here, plus a dedicated Flashblocks-aware WebSocket for 200ms preconfirmations — so you can match the right guarantee to each call without juggling providers. Start building with Chainstack → FAQ How long does a Base transaction take to finalize? It depends on what you mean by “finalize.” A Base transaction moves through several stages: the sequencer accepts it within 200ms (via Flashblocks), includes it in a block within 2 seconds, posts it to Ethereum in roughly 5–10 minutes, and Ethereum finalizes that block after about 15–20 minutes. For most financial applications, the practical answer is 15–20 minutes — that’s when reversal becomes effectively impossible. For UI feedback, 2 seconds is usually enough. For payments and settlements, the 5–10 minute safe tier is the right cutoff. What is the difference between latest, safe, and finalized on Base? These are block tags you pass to JSON-RPC methods to control which confirmation tier your query reads from. latest returns the most recent sequencer block — fast (2s) but reversible if the sequencer reorgs. safe only advances once Base’s batch has been posted to Ethereum, removing the sequencer’s ability to reorder those transactions — this takes roughly 5–10 minutes. finalized goes one step further: it only advances after Ethereum’s validators have signed off on the block, making reversal catastrophically unlikely — around 15–20 minutes. Most RPC libraries default to latest. For anything involving money movement, you should be explicit about which tag you need. What are Flashblocks on Base? Flashblocks are 200ms preconfirmations emitted by Base’s sequencer before a full 2-second block is produced. Built by Flashbots as an add-on to the OP Stack, they went live on Base mainnet in July 2025. When the sequencer includes your transaction in a Flashblock, it has accepted the transaction but hasn’t finalized the block yet — so Flashblock state is a strong hint, not a guarantee. The main use case is UI responsiveness: showing a balance update or animating a swap result without waiting 2 seconds. Reading Flashblock state requires a WebSocket connection to a Flashblocks-aware endpoint. Is Base a Layer 2? Yes. Base is an Ethereum Layer 2 built on the OP Stack, the same open-source framework that powers Optimism. It processes transactions off Ethereum mainnet to keep fees low, then periodically posts compressed transaction data back to Ethereum as proof of what happened. Ethereum acts as the settlement layer — it stores the data needed to reconstruct Base’s state and enforces the rules via fault proofs. Base launched on mainnet in August 2023 and is operated by Coinbase, though the underlying protocol settles trustlessly to Ethereum. Additional resources What are Flashblocks? Faster confirmations for L2 rollups Flashblocks on Base via Chainstack RPC How to get a Base RPC endpoint Best Base RPC providers in 2026 Base migration: from OP Stack to base/base #### Battle Codes Lands in Brooklyn On October 7, Cracked Labs Presents: Battle Codes. One-day, onsite, bracket-style showdown where founders, traders, and liquidity engineers go head-to-head. The last one standing takes home $10,000. Hosted at OS NYC, the format is simple: show up, code, survive each round. Matches are live, timed, and elimination-based. Each one testing speed, accuracy and the ability to make the right call under pressure. And in a space where seconds decide who moves on, you need infra that won’t fail you, and latency low enough to keep pace. That’s why we are backing the event with our infra to let everyone push their limits without worrying about what’s under the hood. Event Details Battle Codes takes place Tuesday, October 7, 2025 at OS NYC. It’s a one-day, onsite bracket with a winner-take-all $10,000 prize. Trades execute live on BNB Chain via Aster. Here’s how the format unfolds, live and on-chain: Opening bell: 10 traders, one eliminated every 20 minutes Endgame push: Final 3 compete in a 30-minute round Final match: One winner takes the prize Be there If you’re in New York, you can apply to compete or grab a free ticket to attend. If you can’t attend, keep an eye on Cracked Labs’ channel for the stream. #### Behind the scenes of the Fabric Bootcamp: How you deployed 30 nodes in 90 minutes Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Back in July 2020, we planned and ran a Hyperledger Fabric Bootcamp during the Singapore Blockchain Week, via Zoom, and with over 250 people signed up. We set the goal of the workshop to be an exciting and experiential educational event, within an allocated timeframe of 90 minutes. How many people would actually show up? How could we structure it? How should we prepare its execution? What were the pitfalls to watch out for? As we moved to experiment on something that had never been attempted before, there were many question marks for us to address, a lot of enthusiasm, and a deep passion for making this event into an unforgettable community gathering. Read on to understand what we did, why we did it, and how it turned out. If you want to see us in action, here’s the link to the video recording of the event. Setting our goals straight After multiple internal discussions, we decided to craft the workshop on these assumptions: Participants may not have any knowledge on blockchain. Participants may not have any knowledge on Hyperledger Fabric. Participants may have very basic knowledge on JavaScript and Node.js. Participants may have very basic knowledge on executing command through the CLI. The objectives we set out for the bootcamp: Participants should learn how a Hyperledger Fabric consortium works together via chaincode. Participants should learn how to build and connect a web application to a Hyperledger Fabric v2 node. Participants should learn how to deploy a Hyperledger Fabric network and nodes via Chainstack. From design to execution The initial plan of the workshop was to have participants deploy their own network and connect their web application to the deployed network learning how Hyperledger Fabric works—hands on but that felt too conventional and we wanted to spice things up. We agreed to go big, and attempt to deploy the largest Hyperledger Fabric consortium ever deployed in the shortest possible time (a 90-minute bootcamp!) by participants representing different organizations of the network. The KPI was to have them install, approve, commit, and execute the same chaincode on the same network deployed on Chainstack. During the dry-run, we concluded that the biggest challenge we faced was time, 90 minutes may be enough for 15 participants but it might have not been enough for the higher number of participants that we were expecting. To mitigate this risk and shorten the process, we decided to ask the participants to set up the environment one day before the workshop, installing the pre-required repositories, libraries and setting up their node on the network we had pre-created. We tried our best to design the workshop so that it would be as easy to follow as possible, and we reduced the number of steps as much as we could. We set up a public repository with everything that the participants needed—the web application and the chaincode we were using for the bootcamp. All that was required from the participants was a git pull and a few commands on the terminal. Testing the boundaries of what was possible Running the workshop via Zoom was definitely a challenge in terms of support as compared to a physical bootcamp, because troubleshooting and support were restricted to online chat functions. We therefore decided to open a dedicated Gitter room where our team of engineers was on hand to assist any participant needing a hand. During the workshop, having everyone on the network running the same chaincode meant that we couldn’t move on due to the Hyperledger Fabric configuration of having the majority approve the chaincode before it could be committed. At one time we couldn’t reach the majority or figure out who was having issues approving the chaincode. It was an interesting moment and a very good example of how Hyperledger Fabric works. There wasn’t anything we could do on our end (in a centralized way) to solve this issue other than to wait for participants to approve the chaincode. In the end, a few unnamed heroes sacrificed their nodes from the network for the rest of us to reach a majority and commit the chaincode. What a team effort to get the network running! One key requirement during the bootcamp was to query the number of approvals on the chaincode against the total number of organizations in real-time. This was essential to tell if we had majority approval for the chaincode to be committed without having participants to constantly refresh the page to check. This was implemented with a poll mechanism at one-second intervals. We could have used WebSocket for this, but due to the time constraint, we decided to use the simplest implementation available. To get the most accurate state of the network, we were executing 4 commands on the network from each web application at one-second intervals: peer lifecycle chaincode queryinstalled peer lifecycle chaincode querycommitted discover peers discover config Using 200 participants as an example, we would be executing 800 queries every second on the network. This is a great way to push the limits, and although everything worked during the bootcamp, it highlighted the need to implement stringent end-to-end stress testing automation for simultaneous operations on the same network that our engineering team is already working on. Making it all worth it Ultimately, our goal was to make the developer experience as effective and smooth as possible. Equally, we wanted to test the boundaries of what could be achieved, something that could have ended up encountering some bumps on the road. We were very happy with how everyone got stuck in hands-on, and we were even more pleased to have received great feedback from the participants. Here’s some: “Thank you guys. Looking forward to use Chainstack for my PoC. Great stuff, loved it!!” “Thank you, that’s hands down one of the best Hyperledger Fabric workshops ever” “Great guys!!! It was really a risk having so many people from different countries on same network…it’s really historical!! Great stuff, Chainstack!!!” “Thank you for the courage to take this risk to demonstrate to us your brilliant technology” “Great session! Special thanks to Evgeny for tolerating my questions” “Great job guys!” “Thank you, all for organising this. Great introduction for Hyperledger to me. This will definitely help me with my Master’s Thesis on smart contracts on Hyperledger” “It was a great session. Thanks a lot 🙂” “Thank you for great session!!!” “A great informative and hands on session. Thanks to everyone!” “Great work! thank you guys keep up the good work n keep rocking 👍” “Mexico City represent 🤘rock solid” “Thank you Thomas. You are awesome 🙂 Engineering life indeed” “Good stuff!” What are the they key takeaways? It was our first bootcamp conducted via Zoom, and we used it to reflect and identify areas that we could improve on for future bootcamps. It was an exciting bootcamp without a doubt, the atmosphere was fun, filled with enthusiastic and curious participants, and high energy overall. It felt like a true team effort with everyone coming together, participants and the Chainstack team alike, to work towards the same goal—deploy the largest Hyperledger Fabric consortium network in the shortest possible time. The bootcamp was a learning experience not only for the participants but for us at Chainstack too. It brought us closer to the community, giving us a better perspective of what the community needs and help us better align our product vision to meet these needs. Something to repeat again soon! Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Best Aptos RPC providers in 2026 Aptos continues to scale as a high-throughput Layer 1, with the network consistently handling tens of millions of transactions per day and demonstrating sub-second finality under real workloads. The network is designed for parallel execution and low latency, supporting Move smart contracts, on-chain applications, trading systems, and stablecoin transfers. As Aptos adoption grows across DeFi and payments, reliable RPC access has become a critical foundation for production workloads. Different teams optimize for different priorities — some need ultra-low latency, others focus on cost efficiency, scalability, or enterprise-grade reliability. In this benchmark, we compare the best Aptos RPC providers in 2026 across key criteria such as performance, uptime, pricing models, and security capabilities. We focus on two critical Aptos use cases – stablecoin payments and enterprise applications – to see how each provider measures up. Aptos RPC providers comparison #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow latency global routing with 99.99%+ uptimeDocs, dashboard metrics, testnet faucets, archive, Access rules2OnFinality400K response units/day, up to 40 RU/secGrowth $49/mo (20M RU, $6/M extra); Accelerate $249/mo (100M RU, $3.75/M extra); Ultimate customPublic rate limit 5 req/sec; REST-based (not JSON-RPC)Dedicated nodes pay-as-you-go, archive access, request analytics on paid plans3Ankr200M credits/month, ~30 RPSPay-as-you-go ($10 per 100M credits), goes up to up to 15,000 RPS.GEO-distributed network, 99.99% SLA on Enterprise tiersSimple dashboard, multi-chain support, HTTPS, archive available4GetBlock50k req/day (~1.5M /mo), 20 RPS$39 for 50M (100 RPS); $399 for 600M (500 RPS); Dedicated from $1000 no capRegional nodes, 99% shared / 99.99% dedicated uptimeBasic dashboard, regional choice, easy setup5Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow latency routing, uptime available on higher tiersMonitoring APIs, analytics, SDK support6QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams, Webhooks, team dashboards, multi-region setup What separates one RPC provider from another usually comes down to the same few metrics: pricing, latency, uptime, and scalability options available. Here’s how the leading Aptos options measure up: Key takeaways from the comparison: Chainstack offers the most balanced feature set with transparent request-based pricing, highest uptime (99.99%+), and full SOC 2 Type II and ISO 27001 certification Quicknode leads in performance with maximum RPS and globally distributed infrastructure Alchemy provides the richest developer tooling including monitoring APIs GetBlock is ideal for small projects and developers needing simple setup Before diving into detailed provider reviews, let’s examine how each performs across critical Aptos use cases: Choose Aptos RPC provider by your use case: Stablecoin & payments infrastructure Stablecoins have become the backbone of on-chain payments, now making up ~30% of all crypto transaction volume (over $4 trillion in 2025). Payment applications require Aptos RPC service with consistent throughput, near-zero downtime, and predictable costs. Even minor RPC outages or high latency can disrupt thousands of stablecoin transfers. Top providers address this with robust multi-region infrastructure that automatically fails over if any node goes down. Chainstack’s network delivered 99.99%+ availability in testing, with multi-cloud architecture that reroutes traffic instantly if a region fails. Such redundancy ensures stablecoin transactions aren’t halted by regional outages. Explore stablecoin-ready infrastructure → Enterprise-grade performance Enterprise Aptos deployments demand strong performance guarantees. Corporate and institutional users often have high-throughput workloads and strict SLA requirements. Enterprise RPC essentials: High throughput: Chainstack offers high-throughput plans with custom RPS configurations on Aptos and achieves ~99.99% measured uptime via global load balancing SLA guarantees: Quicknode handles enterprise-scale volumes while maintaining 99.99% uptime Low-latency across regions: Multi-region data centers and intelligent routing keep response times uniform worldwide Request enterprise plan → SOC 2 compliant providers Security and compliance are paramount for enterprises integrating with Aptos. SOC 2 certification has become a key benchmark of a provider’s security controls and operational integrity. Security leaders: Chainstack achieved SOC 2 Type II and ISO 27001 in late 2025, underscoring enterprise-grade security and 99.99%+ uptime SLA guarantees Quicknode maintains SOC 1 Type 2, SOC 2 Type 2, plus ISO 27001 certifications Note: Certification coverage varies: Alchemy holds SOC 2 Type II but has not published ISO 27001; Ankr and GetBlock have not published SOC 2 certification In-depth Aptos provider analysis: Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most complete ways to connect to Aptos without the overhead. By choosing Chainstack Aptos RPC node, you get secure HTTP access to Aptos, backed by 99.99%+ uptime and globally distributed routing for consistently low latency. What makes it stand out is how much is available from the same console: Global Nodes for geo-balanced Aptos RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Archive nodes for deep historical reads, full historical blocks from the genesis to the latest one, debug and trace queries on the Aptos blockchain. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for unlimited requests with flat monthly pricing, so you never have to worry about hitting plan limits. All of this adds up to the Aptos setup that covers nearly every use case. Whether you’re deploying contracts, building DeFi products, or streaming on-chain data, Chainstack gives you reliable performance, clear pricing, and infrastructure to scale with. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier.Dedicated Nodes — $0.50 / hour plus storage costs for exclusive, high-performance isolated Aptos node instances, what means ~$0.25 per million requests effectively.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Predictable, request-based pricing with Unlimited Node add-on for flat, unmetered traffic within your chosen RPS tier– Built-in testnet faucets– 99.99%+ uptime SLA, SOC 2 Type 2, globally distributed routing for low latencyOne provider for Aptos plus 70+ other chainsCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Dedicated Nodes require at least a Pro plan 🤖 You can also access Chainstack Aptos RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. Chainstack offers a full-featured infrastructure stack for running Aptos, including high RPS capacity, global routing, and archive access. The deployment model stays consistent as workloads grow, helping teams scale without re-architecting their setup or losing cost visibility. OnFinality OnFinality provides Aptos RPC access over its own REST-based API surface (Aptos doesn’t use EVM JSON-RPC), covering account, transaction, block, and ledger endpoints. It offers a path from public testing to authenticated API access and pay-as-you-go dedicated Aptos nodes for teams that outgrow shared infrastructure. How much does it cost?Developer — free, 400,000 response units/day, up to 40 RU/sec.Growth — $49/month, 20M response units/month, no daily cap, 200 RU/sec, $6/million extra.Accelerate — $249/month, 100M response units/month, 500 RU/sec, $3.75/million extra.Ultimate — custom pricing, custom throughput, crypto payments accepted.PerformancePublic rate limit: 5 req/sec on the public endpoint.Access: REST-based (GET /v1/accounts/{address}, /v1/transactions/by_hash/{hash}, /v1/blocks/by_height/{height}), not JSON-RPC.Dedicated nodes: pay-as-you-go, for isolated capacity and custom operations.Archive: available for historical Aptos state, analytics, and audits.Pros– Simple path from free public testing to authenticated production access– Pay-as-you-go dedicated Aptos nodes, no long-term commitment– Archive access for historical state– Request visibility/analytics on paid plansCons– Public free-tier rate limit (5 req/sec) is tight without upgrading– REST-only surface — no WebSocket subscriptions documented for Aptos– Security certifications not explicitly documented Ankr Ankr provides Aptos RPC through a globally distributed network of node operators, routing traffic across regions to keep latency low and reduce reliance on any single infrastructure provider. You can connect to Aptos mainnet and testnets via HTTPS, with more than 30 regions in rotation and archive access available for historical queries and tracing It’s a solid option for teams that prefer a pay-as-you-go model and want to tap into a decentralized setup, though it skips some of the advanced tooling and analytics you’d find in larger, more centralized providers. How much does it cost?Ankr uses an API credits model where credit cost varies by method (heavier calls cost more). Pricing is pegged at $0.10 = 1M API credits (PAYG), and there’s a freemium tier. It’s enough for testing, but high-traffic apps will hit the ceiling quickly.Their paid plans use a pay-as-you-go model:Premium — $10 per 100M credits (~500K requests), with up to 1,500 RPS.Enterprise — from $1,000/month, 15,000 RPS, dedicated endpoints, and priority support.PerformanceUptime: Claims up to 99.9%.Latency: Region-routed.Throughput: 30 RPS on free; ~1.5K–15K RPS on paid tiers.Reliability: Distributed design reduces single-point failures but outages can still occur.Monitoring: The console shows usage and request stats, with more advanced visibility once you move to a paid.Pros– Freemium with 200M credits/month, – Supports HTTP and archive queries, – Multi-chain supportCons– Advanced visibility/support gated to paid, – No fixed monthly plans, – Fewer built-in analytics If you don’t mind variable performance across regions, Ankr could be a way to go when testing or for the smaller projects. Yet, if you need steady throughput and predictable billing, platforms with fixed RPS tiers and dedicated routing tend to offer a more stable path for production workloads. GetBlock GetBlock provides Aptos RPC access on mainnet and testnets over HTTP, with the option to choose regions such as New York, Frankfurt, or Singapore to improve latency. Developers can use shared endpoints to get started quickly or switch to dedicated nodes when they need higher uptime guarantees, archive access, or more consistent performance under load. While it skips the advanced APIs and deep analytics of bigger platforms, GetBlock remains a good option for teams that prioritize simplicity, regional control, and predictable access to Aptos infrastructure. How much does it cost?Free Tier — 50k CU per day, 20 RPS.Start (Shared) — $39/month, 50M CU/month, 100 RPS.Advanced (Shared) — $159/month, 220M CU/month, 300 RPS.Pro (Shared) — $399/month, 600M CU/month, 500 RPS.Enterprise (Shared) — from $799/month, custom CU/RPS and features.PerformanceUptime: 99% on shared plans, 99.99% on dedicated.Latency: Region-pinned routing for lower RTT.Throughput: 20 RPS on free, 100 RPS on Start, 500 RPS on Pro, unlimited on Dedicated.Reliability: Shared nodes work well for low-volume usage, but performance can vary when load increases.Monitoring: Basic dashboard is available but deeper analytics are only unlocked on higher tiers.Pros– Dedicated nodes offer unlimited requests and 99.9% uptime, – Low-latency via regional nodes, – Setup is quickCons– Free tier is capped at 20 RPS, – Strict RPS ceilings on shared plans, – Monitoring features are limited compared to other infra providers GetBlock works well for early-stage testing or smaller workloads. However, as demand increases, throughput caps can limit you, and basic options for monitoring will make it harder to manage growth or troubleshoot performance issues at scale. Alchemy Alchemy offers Aptos RPC through its Supernode, providing HTTP access to mainnet and testnets. Developers get enhanced transaction monitoring, real-time notifications, and historical data alongside global infrastructure reliability On top of that, Alchemy supports dozens of networks, giving developers access to historical blockchain data and real-time event streaming tailored for Aptos, including Move-specific transactions, resources, and state changes. Backed by global infrastructure, Alchemy suits teams looking for additional APIs and monitoring tools. How much does it cost?Alchemy measures usage in compute units (CUs) rather than raw requests, which can make costs less predictable for teams sending large volumes of latency-sensitive calls compared to flat, request-based models.Alchemy starts with a free tier offering 30M CUs per month, roughly equal to 1.2M basic requests up to 25 RPS. Paid plans scale by total CU usage:Pay-as-you-go — $5 per 11M CUs (~$0.45 per million).Enterprise — custom pricing with lower per-unit costs at high volumes.PerformanceUptime: Reports 99.9% historical uptime, but an uptime SLA is only guaranteed on Enterprise plans.Latency: Region-based routing helps keep response times low; however, Alchemy does not publish official Aptos-specific latency numbers.Throughput: Begins at about 25 RPS on the free tier, with scaling up to 300 RPS on paid.Reliability: The Supernode setup helps maintain data accuracy during heavy traffic.Monitoring: You can check usage, errors, and request patterns through the dashboard in real time.Pros– Covers Aptos plus 40+ chains, – Optimized transaction delivery for Aptos networks– Rich toolingCons– CU pricing isn’t intuitive, – Hard to verify real performance without public benchmarks, – Throughput caps by plan, very high RPS needs an enterprise plan Alchemy performs reliably under heavy load with consistent low latency across global regions. Compute-based CU pricing offers flexibility but bills vary by API call complexity, making cost prediction challenging at scale. Ideal for teams needing enhanced monitoring and real-time transaction notifications, less optimal for fixed-budget planning. Quicknode Quicknode runs a multi-region infrastructure for Aptos RPC, letting you connect to mainnet and testnets over HTTP. Archive support is available for teams that need to query deep historical data. It also supports dozens of other chains and offers add-ons such as Webhooks and Streams if you want event-based triggers or real-time blockchain feeds. It’s popular with high-traffic teams because the network scales well under pressure, but to get to that performance you would need to move to the higher-priced tiers. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom terms for higher volumes and dedicated support. Credits rollover unused portions, which helps variable Aptos loads, though the model adds a layer compared to straight request counts.PerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Scales up to 500+ RPS on higher plans, – Archive data available (by chain/plan), – Low latency from multi-region routingConsFree trial caps at 15-25 RPS with only community support, – Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode gives you speed, global routing, and developer tooling, which makes it good option for Aptos apps. The main limitation is its credit-based (method-weighted) pricing. Because different methods burn credits at different rates, long-term cost planning takes more effort, especially if your workload isn’t static. Getting started with Aptos on Chainstack The provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. Chainstack bundles the full stack into a setup that takes minutes to deploy: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Choose Aptos, then pick mainnet or a testnet. Deploy a node with RPC access and copy the HTTP endpoint into your app. Once your endpoint is live, query Aptos over its REST-based API — for example, checking the current ledger: curl https://YOUR_CHAINSTACK_ENDPOINT/YOUR_API_KEY/v1 Conclusion The 2026 Aptos RPC landscape is more competitive and mature than ever. Chainstack leads as the top all-around provider, combining enterprise-grade performance and 99.99% uptime via multi-cloud routing, transparent request-based pricing ($0.25-$2.50/M with unlimited options), and full SOC 2 Type II and ISO 27001 compliance. It perfectly serves stablecoin payments, and enterprise dApps include 70+ chain support.​ Quicknode is a strong choice for latency-sensitive workloads, offering high RPS limits and robust compliance certifications. Alchemy remains a developer-first platform with rich tooling and a generous free tier, best suited for teams prioritizing productivity over raw infrastructure control. GetBlock and Ankr serve more cost-conscious and early-stage use cases. GetBlock fits testing and lightweight applications with simple regional endpoints, while Ankr offers broad multi-chain access and flexible pricing—but with fewer enterprise-grade features compared to top-tier providers. Overall, developers now have a wide range of Aptos RPC options—from enterprise-ready infrastructure to flexible, budget-friendly platforms—making it easier to match providers to specific performance, compliance, and cost requirements. Additional resources Chainstack Aptos product page — build better with Aptos. Aptos tooling — supported libraries and SDKs. Chainstack Enterprise plans — custom RPS, SLAs, and dedicated support. Reliable Aptos RPC infrastructure Getting started with Aptos on Chainstack is fast and straightforward — deploy a reliable node in seconds through an intuitive console, no hardware or complex setup required. With 99.99% uptime, 24/7 SLA-backed operations and low-latency global endpoints, Chainstack ensures seamless RPC access for building and scaling DeFi, analytics, and trading applications. Building on Aptos? Deploy your Aptos node on Chainstack → FAQ What is Aptos RPC and why do I need it? Aptos RPC is the standard interface that lets applications communicate with the Aptos blockchain. Through an RPC provider, you can read blockchain data (balances, transactions), send transactions, deploy smart contracts, and interact with dApps using JSON-RPC API calls. Without reliable RPC, your app can’t connect to Aptos. Which Aptos RPC provider is best for production use in 2026? For production workloads, Chainstack is a strong option, combining predictable request-based pricing, scalable performance, 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and both free/enterprise tiers. It covers payments, enterprise, and DeFi needs better than competitors. Are there free Aptos RPC options suitable for real development? Yes. Chainstack offers 3M requests/month (~25 RPS) free with full mainnet/testnet access, archive data, and testnet faucets. Alchemy gives 30M CUs (~1.2M requests) GetBlock 50K daily, and Ankr includes a limited free tier suitable for testing and light usage. How do I connect to an Aptos RPC node? When you start building on Aptos, the provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. While different platforms cater to different use cases, Chainstack bundles the full stack into a setup that takes minutes to deploy:1. Log in to your Chainstack account (or create one if you don’t have it yet).2. Create a new project or select an existing one.3. Choose Aptos, then pick mainnet or a testnet4. Deploy a node with RPC access and copy the HTTP endpoint into your app. #### Best Avalanche RPC providers in 2026 Avalanche has established itself as a high-performance blockchain for DeFi, payments,and enterprise use cases, thanks to its fast finality, sub-second block times, andcustomizable subnet architecture. In 2026, it is increasingly used for stablecoinsettlement, gaming infrastructure, and regulated financial applications where reliabilityis non-negotiable. Recent milestones highlight Avalanche’s growing adoption: Over 3 billion transactions processed since mainnet launch (September 2020) Stablecoin transfer volume up 250% in 2025 — more than 2× the previous annual high Native USDC integration with Circle for seamless stablecoin settlement Growing institutional adoption, with major enterprises deploying subnets forregulated use cases As adoption grows, RPC infrastructure becomes a critical dependency. Production workloads on Avalanche require consistent low latency, predictable throughput, and strong security controls. This applies not only to DeFi and payments, but also to Avalanche’s growing gaming ecosystem and subnet-based applications, where real-time interactions and isolated execution environments add additional performance and reliability requirements. In this guide, we compare the best Avalanche RPC providers in 2026, focusing on performance, uptime, pricing models, and enterprise readiness for stablecoin, gaming, and institutional use cases. Avalanche RPC providers comparison #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow latency global routing with 99.99%+ uptimeDocs, dashboard metrics, testnet, guides, Access rules, Subnets2OnFinality400K response units/day, up to 40 RU/secGrowth $49/mo (20M RU, $6/M extra); Accelerate $249/mo (100M RU, $3.75/M extra); Ultimate customPublic rate limit 5 req/sec; covers C-Chain, P-Chain, X-ChainDedicated nodes pay-as-you-go, archive on every plan, request analytics on paid plans3Ankr200M credits/month, ~30 RPSPay-as-you-go ($10 per 100M credits), goes up to up to 15,000 RPS.GEO-distributed network, 99.99% SLA on Enterprise tiersSimple dashboard, multi-chain support, HTTPS & WebSocket, archive available4DwellirFree — 20 RPS, 500k requests/dayPaid plans start at $5/month (20 RPS, 100k requests/day) and scale up to $999/month with 2000 RPS and 500M requests/month.Isolated on dedicated; rate-limited on shared; public status page availableAPI reference, docs, GitHub, explorers, node snapshots5Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow latency routing, uptime available on higher tiersMonitoring APIs, analytics, SDK support6QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams, Webhooks, team dashboards, multi-region setup What separates one RPC provider from another usually comes down to the same few metrics: pricing, latency, uptime, and scalability options available. Here’s how the leading Avalanche options measure up: Key takeaways from the comparison: Chainstack offers the most balanced feature set with transparent request-based pricing, highest uptime (99.99%+), and full SOC 2 Type II and ISO 27001 certification Quicknode leads in performance with maximum RPS and globally distributed infrastructure Alchemy provides the richest developer tooling including monitoring APIs Dwellir is ideal for small projects and developers needing simple setup Before diving into detailed provider reviews, let’s examine how each performs across critical Avalanche use cases: Choose Avalanche RPC provider by your use case Gaming & real-time applications Avalanche has become a major hub for on-chain gaming, thanks to its low latency, fast finality, and subnet architecture that supports custom game environments. Many Avalanche games rely on frequent state updates, real-time interactions, and bursty transaction patterns during gameplay or events. Gaming workloads place unique demands on RPC infrastructure. Game backends need consistently low response times, high RPS headroom during traffic spikes, and stable WebSocket connections for real-time state sync. Any RPC lag or instability directly impacts player experience, causing delays, dropped actions, or failed transactions. Providers optimized for gaming use multi-region routing and elastic scaling to absorb sudden load without throttling. Chainstack’s global Avalanche RPC infrastructure delivers predictable latency and high throughput, allowing game studios to support live gameplay, in-game marketplaces, and NFT mechanics without compromising performance during peak usage. Start building gaming Infrastructure → Stablecoin & payments infrastructure Stablecoins have become the backbone of on-chain payments, now making up ~30% of all crypto transaction volume (over $4 trillion in 2025). Payment applications require Avalanche RPC service with consistent throughput, near-zero downtime, and predictable costs. Even minor RPC outages or high latency can disrupt thousands of stablecoin transfers. Avalanche has established itself as a major stablecoin settlement layer, with native USDC issuance by Circle and significant USDT liquidity. The network’s sub-2-second finality and low transaction costs make it particularly suited for high-frequency payment processing and institutional settlement. Top providers address this with robust multi-region infrastructure that automatically fails over if any node goes down. Chainstack’s network delivered 99.99%+ availability in testing, with multi-cloud architecture that reroutes traffic instantly if a region fails. Such redundancy ensures stablecoin transactions aren’t halted by regional outages. Explore stablecoin-ready infrastructure → Enterprise-grade performance Enterprise Avalanche deployments demand strong performance guarantees. Corporate and institutional users often have high-throughput workloads and strict SLA requirements. Enterprise RPC essentials: High throughput: Chainstack offers high-throughput plans with custom RPS configurations on Avalanche and achieves ~99.99% measured uptime via global load balancing SLA guarantees: Quicknode handles enterprise-scale volumes while maintaining 99.99% uptime Low-latency across regions: Multi-region data centers and intelligent routing keep response times uniform worldwide Request enterprise plan → SOC 2 compliant providers Security and compliance are paramount for enterprises integrating with Avalanche. SOC 2 certification has become a key benchmark of a provider’s security controls and operational integrity. Security leaders: Chainstack achieved SOC 2 Type II and ISO 27001 in late 2025, underscoring enterprise-grade security and 99.99%+ uptime SLA guarantees Quicknode maintains SOC 1 Type 2, SOC 2 Type 2, plus ISO 27001 certifications Note: Certification coverage varies: Alchemy holds SOC 2 Type II but has not published ISO 27001; Ankr and Dwellir have not published SOC 2 certification In-depth Avalanche provider analysis Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most complete ways to connect to Avalanche without the overhead. By choosing Chainstack Avalanche RPC node, you get secure HTTP and WebSocket access to Avalanche, backed by 99.99%+ uptime and globally distributed routing for consistently low latency. Chainstack is listed as an official integration on the Avalanche developer portal, highlighting its active role in the Avalanche ecosystem. From a single console, teams can deploy and manage: Global Nodes for geo-balanced Avalanche RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Archive nodes for deep historical queries, tracing, and debugging. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for flat-rate, unmetered requests within a fixed RPS tier. Chainstack also supports Avalanche Subnets, enabling teams to run application-specific environments for gaming, enterprise, and regulated use cases. Subnet-based infrastructure can be operated alongside Avalanche C-Chain RPC while maintaining the same standards for uptime, security controls, and compliance. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier.Dedicated Nodes — $0.50 / hour plus storage costs for exclusive, high-performance isolated Avalanche node instances, what means ~$0.25 per million requests effectively.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Predictable, request-based pricing with Unlimited Node add-on for flat, unmetered traffic within your chosen RPS tier– Avalanche Subnets & on-chain gaming support– 99.99%+ uptime SLA, SOC 2 Type 2, globally distributed routing for low latencyOne provider for Avalanche plus 70+ other chainsCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Dedicated Nodes require at least a Pro plan 🤖 You can also access Chainstack Avalanche RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. Chainstack offers a full-featured infrastructure stack for running Avalanche, including high RPS capacity, global routing, and archive access. The deployment model stays consistent as workloads grow, helping teams scale without re-architecting their setup or losing cost visibility. OnFinality OnFinality provides EVM-compatible HTTPS and WebSocket RPC access to Avalanche’s C-Chain, plus API access to the P-Chain and X-Chain, with archive access included on every plan and Trace/Debug APIs on paid tiers. Pay-as-you-go dedicated Avalanche nodes are available for teams that need isolated infrastructure. How much does it cost?Developer — free, 400,000 response units/day, up to 40 RU/sec.Growth — $49/month, 20M response units/month, no daily cap, 200 RU/sec, $6/million extra.Accelerate — $249/month, 100M response units/month, 500 RU/sec, $3.75/million extra.Ultimate — custom pricing, custom throughput, crypto payments accepted.PerformanceAccess: C-Chain over EVM JSON-RPC (HTTPS + WebSocket); P-Chain and X-Chain via their native APIs.Public rate limit: 5 req/sec.Archive: included on every plan, including Free.Dedicated nodes: pay-as-you-go, for isolated capacity.Pros– Covers all three Avalanche chains (C/P/X), not just C-Chain– Archive access on every plan, including Free– Pay-as-you-go dedicated nodes on all tiersCons– Public free-tier rate limit (5 req/sec) is tight without upgrading– Trace API not available on the Free plan– Security certifications not explicitly documented Ankr Ankr provides Avalanche RPC through a globally distributed network of node operators, routing traffic across regions to keep latency low and reduce reliance on any single infrastructure provider. You can connect to Avalanche mainnet and testnets via HTTPS or WebSocket, with more than 30 regions in rotation and archive access available for historical queries and tracing It’s a solid option for teams that prefer a pay-as-you-go model and want to tap into a decentralized setup, though it skips some of the advanced tooling and analytics you’d find in larger, more centralized providers. How much does it cost?Ankr uses an API credits model where credit cost varies by method (heavier calls cost more). Pricing is pegged at $0.10 = 1M API credits (PAYG), and there’s a freemium tier. It’s enough for testing, but high-traffic apps will hit the ceiling quickly.Their paid plans use a pay-as-you-go model:Premium — $10 per 100M credits (~500K requests), with up to 1,500 RPS.Enterprise — from $1,000/month, 15,000 RPS, dedicated endpoints, and priority support.PerformanceUptime: Claims up to 99.9%.Latency: Region-routed.Throughput: 30 RPS on free; ~1.5K–15K RPS on paid tiers.Reliability: Distributed design reduces single-point failures but outages can still occur.Monitoring: The console shows usage and request stats, with more advanced visibility once you move to a paid.Pros– Freemium with 200M credits/month, – Supports HTTP, WebSocket, and archive queries, – Multi-chain supportCons– Advanced visibility/support gated to paid, – No fixed monthly plans, – Fewer built-in analytics If you don’t mind variable performance across regions, Ankr could be a way to go when testing or for the smaller projects. Yet, if you need steady throughput and predictable billing, platforms with fixed RPS tiers and dedicated routing tend to offer a more stable path for production workloads. Dwellir Dwellir known for its infrastructure work across multiple blockchain ecosystems, offers Avalanche RPC access via shared endpoints and dedicated nodes. Each dedicated setup is provisioned and managed individually by Dwellir’s team, giving users isolated resources rather than pooled capacity. This model reduces contention for bandwidth and helps keep performance more predictable under load. Dwellir also provides shared endpoints for quick integration, making it easier to get started without managing infrastructure directly. The trade-offs are mostly on the pricing and feature side: there is no recurring free tier, RPS limits on lower plans are more restrictive than some competitors at similar price points, and teams that require advanced platform features or deeper analytics may need to supplement with additional tooling. How much does it cost?Starter — $5, 20 RPS, 100k/day cap.Developer — $49/mo, 100 RPS, 25M API responses/month.Growth — $299/mo, 500 RPS, 150M API responses/month.Scale — $999/mo, 2000 RPS, 500M API responses/month.PerformanceThroughput: Plan-based, scales up to 2,000 RPS, though higher limits are available on request.Latency: Solid on dedicated, though real-world response times may vary depending on your region.Monitoring: A dashboard where you can check metrics and stats, plus a public status page.Pros– Shared and dedicated options available – Usage/latency visibility in dashboard and public status page– Setup is quickCons– No free or test tier– Fewer built-in platform features– Pricing is quota & RPS based, unmetered-in-tier options unavailable If you’re building on Avalanche and need predictable performance with the option to move from shared RPC to fully isolated infrastructure, Dwellir is a solid choice. Dedicated nodes reduce bandwidth contention and suit applications with steady traffic patterns. However, teams should account for the absence of a free monthly tier and stricter RPS limits on entry plans. Alchemy Alchemy offers Avalanche RPC through its Supernode, providing HTTP/WebSocket access to mainnet and testnets. Developers get enhanced transaction monitoring, real-time notifications, and historical data alongside global infrastructure reliability On top of that, Alchemy supports dozens of networks, giving developers access to historical blockchain data and real-time event streaming tailored for Avalanche, including EVM transactions, contract events, and state changes. How much does it cost?Alchemy measures usage in compute units (CUs) rather than raw requests, which can make costs less predictable for teams sending large volumes of latency-sensitive calls compared to flat, request-based models.Alchemy starts with a free tier offering 30M CUs per month, roughly equal to 1.2M basic requests up to 25 RPS. Paid plans scale by total CU usage:Pay-as-you-go — $5 per 11M CUs (~$0.45 per million).Enterprise — custom pricing with lower per-unit costs at high volumes.PerformanceUptime: Reports 99.9% historical uptime, but an uptime SLA is only guaranteed on Enterprise plans.Latency: Region-based routing helps keep response times low; however, Alchemy does not publish official Avalanche-specific latency numbers.Throughput: Begins at about 25 RPS on the free tier, with scaling up to 300 RPS on paid.Reliability: The Supernode setup helps maintain data accuracy during heavy traffic.Monitoring: You can check usage, errors, and request patterns through the dashboard in real time.Pros– Covers Avalanche plus 40+ chains, – Optimized transaction delivery for Avalanche networks– Rich toolingCons– CU pricing isn’t intuitive, – Hard to verify real performance without public benchmarks, – Throughput caps by plan, very high RPS needs an enterprise plan Alchemy performs reliably under heavy load with consistent low latency across global regions. Compute-based CU pricing offers flexibility but bills vary by API call complexity, making cost prediction challenging at scale. Ideal for teams needing enhanced monitoring and real-time transaction notifications, less optimal for fixed-budget planning. Quicknode Quicknode runs a multi-region infrastructure for Avalanche RPC, letting you connect to mainnet and testnets over HTTP or WebSocket. Archive support is available for teams that need to query deep historical data. It also supports dozens of other chains and offers add-ons such as Webhooks and Streams if you want event-based triggers or real-time blockchain feeds. It’s popular with high-traffic teams because the network scales well under pressure, but to get to that performance you would need to move to the higher-priced tiers. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom terms for higher volumes and dedicated support. Credits rollover unused portions, which helps variable Avalanche loads, though the model adds a layer compared to straight request counts.PerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Scales up to 500+ RPS on higher plans, – Archive data available (by chain/plan), – Low latency from multi-region routingConsFree trial caps at 15-25 RPS with only community support, – Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode gives you speed, global routing, and developer tooling, which makes it good option for Avalanche apps. The main limitation is its credit-based (method-weighted) pricing. Because different methods burn credits at different rates, long-term cost planning takes more effort, especially if your workload isn’t static. Getting started with Avalanche on Chainstack The provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. Chainstack bundles the full stack into a setup that takes minutes to deploy: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Choose Avalanche, then pick mainnet or a testnet. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Once your endpoint is live, the C-Chain behaves like a standard EVM JSON-RPC network — for example, checking the latest block: curl -X POST https://YOUR_CHAINSTACK_ENDPOINT/ext/bc/C/rpc/YOUR_API_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 }' Conclusion The 2026 Avalanche RPC landscape is more competitive and mature than ever. Chainstack leads as the top all-around provider, combining enterprise-grade performance and 99.99% uptime via multi-cloud routing, transparent request-based pricing ($0.25-$2.50/M with unlimited options), and full SOC 2 Type II and ISO 27001 compliance. It perfectly serves stablecoin payments, and enterprise dApps include 70+ chain support.​ Quicknode is a strong choice for latency-sensitive workloads, offering high RPS limits and robust compliance certifications. Alchemy remains a developer-first platform with rich tooling and a generous free tier, best suited for teams prioritizing productivity over raw infrastructure control. Dwellir and Ankr serve more cost-conscious and early-stage use cases. Dwellir fits testing and lightweight applications with simple regional endpoints, while Ankr offers broad multi-chain access and flexible pricing—but with fewer enterprise-grade features compared to top-tier providers. Overall, developers now have a wide range of Avalanche RPC options—from enterprise-ready infrastructure to flexible, budget-friendly platforms—making it easier to match providers to specific performance, compliance, and cost requirements. Deploy your Avalanche RPC endpoint on Chainstack → FAQ What is Avalanche RPC and why do I need it? Avalanche RPC is the standard interface that lets applications communicate with the Avalanche blockchain. Through an RPC provider, you can read blockchain data (balances, transactions), send transactions, deploy smart contracts, and interact with dApps using JSON-RPC API calls. Without reliable RPC, your app can’t connect to Avalanche. Which Avalanche RPC provider is best for production use in 2026? For production workloads, Chainstack is a strong option, combining predictable request-based pricing, scalable performance, 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and both free/enterprise tiers. It covers payments, enterprise, and gaming needs better than competitors. Are there free Avalanche RPC options suitable for real development? Yes. Chainstack offers 3M requests/month (~25 RPS) free with full mainnet/testnet access and archive data. Alchemy gives 30M CUs (~1.2M requests), and Ankr includes a limited free tier suitable for testing and light usage. What are Avalanche Subnets and when should you use them? Avalanche Subnets are application-specific networks that let teams run isolated environments with custom rules, performance, and validators. They’re commonly used for gaming, enterprise, and regulated applications that need predictable performance and control.Chainstack supports Avalanche Subnets alongside C-Chain RPC, and also provides guides explaining how subnets work and when to use them.Avalanche subnet tutorial series How do I connect to an Avalanche RPC node? When you start building on Avalanche, the provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. While different platforms cater to different use cases, Chainstack bundles the full stack into a setup that takes minutes to deploy:1. Log in to your Chainstack account (or create one if you don’t have it yet).2. Create a new project or select an existing one.3. Choose Avalanche, then pick mainnet or a Fuji testnet4. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Additional resources Chainstack Avalanche product page — build better with Avalanche. Avalanche tooling — supported libraries and SDKs. Chainstack Enterprise plans — custom RPS, SLAs, and dedicated support. #### Best Base RPC providers for onchain applications in 2026 Introduction Base has become the dominant L2 production environment in 2026 — commanding 48.54% of all rollup TVL (nearly double Arbitrum’s 26.33%) and ranking as the #1 EVM chain by DeFi TVL after Ethereum, with $3.789B locked across 837 protocols and $4.644B in stablecoin market cap (DefiLlama, Feb 2026). As Base’s adoption across stablecoin platforms, DeFi protocols, and AI agent deployments grows, selecting among Base RPC providers is no longer a minor infrastructure choice — it’s a core architectural decision. Rollup Chains By TVL. Source: DefiLiama A note on Base’s evolving stack: Base has announced it is migrating from the OP Stack to its own unified stack — base/base — targeting a faster six-hard-fork-per-year cadence and a simpler, Base-specific codebase. The transition is rolling out over the coming months; all existing RPCs (including the optimism_ namespace) remain fully supported throughout. This guide focuses on present-day provider selection, which is still shaped by the current OP Stack architecture. The starting point every production team should know: Base’s public RPC endpoints are explicitly rate-limited and marked “not for production” in the official documentation, making the choice of a third-party provider non-negotiable for any serious workload. Beyond that, Base’s current architecture introduces two infrastructure considerations that go beyond typical L1 or L2 thinking. First, OP Stack defines two distinct failure classes often misread as “RPC is down” — sequencer downtime (block height freezes, no new transactions) and transaction submission outages (sequencer runs but struggles to publish to L1, affecting safe/finalized status). A good RPC provider can’t fix these, but it can make incidents survivable. Second, Flashblocks — Base’s 200ms preconfirmation layer — has redefined what fast confirmation means on Base, and providers must support it correctly through both HTTP and WebSocket to be viable for time-critical applications. In this benchmark, we compare the best Base RPC providers for 2026 across latency, uptime, throughput, pricing structure, and security posture — mapped to the three core use cases: stablecoin infrastructure, DeFi protocols, and AI agents. The comparison includes real benchmark data from Chainstack’s Compare Dashboard with method-level performance across EU, JP, and US West regions. Base RPC providers comparison 2026 When evaluating Base RPC providers, teams should look beyond headline uptime claims and instead benchmark method-level performance, billing transparency, and Flashblocks implementation quality: ProviderFree PlanPricing ModelUptime / SLADev ExperienceComplianceChainstack3M req/mo, ~25 RPSRequest Units (1 RU standard, 2 RU archive)99.99% formal SLA doc; 99.99%+ on Global/Dedicated linesDashboard metrics, IP/origin access rules, archive, testnet faucets, Chainbench, Compare DashboardSOC 2 Type IIRouteMeshFree community endpoint (reads)Premium: $3–$6 per 1M calls (economy/performance routing)No formal SLA; daily sync + replay correctness checksRoutes across 16–20 upstream providers per method, automatic failoverNot published (routing layer)OnFinalityPublic 5 RPS; Free plan 40 RPSGrowth: 500 RPS, no daily response limitNo published SLA on free tiersDedicated Nodes, archive, trace/debug on paid, WebSocket subscriptionsNot publisheddRPC210M CU/30 days (public nodes)Flat-rate: 20 CU/request, $6 per 1M requestsHigh availability via multi-provider routing; no formal public SLASimple setup, OpenAI-compatible API, public status page, key control, front-end protectionNo public SOC 2Ankr200M credits/mo, ~30 RPSPAYG: $0.10 = 1M credits; EVM methods 200 credits flat99.99% uptime claimed; avg 56ms response timeBasic dashboard, multi-chain support (40+ chains, EVM + non-EVM), HTTPS & WebSocket, archiveSOC 2 Type I (Type II in progress)Alchemy30M CUs/mo, ~25 RPSCompute Units by method weight; PAYG + monthly99.99% uptime claimed during peak; SLA formally on EnterpriseNotify & Transact APIs, Mempool streaming, MEV protection, real-time analytics dashboard, SDK supportSOC 2 Type IIQuicknodeTrial only (10M credits)API credits (method-weighted; e.g. eth_call = 20 credits on Base)99.99% guaranteed, formal SLAStreams, Webhooks, OP-Node API, Trace API, marketplace add-ons (incl. DeFi integrations), team dashboardsSOC 2 Type II + ISO 27001 Choose the right Base RPC providers by use case Different Base RPC providers perform differently depending on workload profile — stablecoin settlement, DeFi indexing, and AI-driven automation each stress infrastructure in distinct ways. Stablecoin settlement and payment infrastructure Base Stablecoins Market Cap. Source: Defiliama Stablecoin platforms on Base run continuous, unforgiving pipelines — every payment, redemption, and treasury rebalance depends on infrastructure that simply doesn’t go down. Even brief outages cascade into failed settlements, reconciliation gaps, and user-facing errors that erode trust fast. The Base-specific risk to plan for is sequencer downtime, which is distinct from an RPC provider failure. When it happens, transactions can’t be submitted through the normal path regardless of how good your provider is — so payment architectures need built-in grace periods and pause logic to handle it gracefully. On the upside, Flashblocks’ 200ms preconfirmations give stablecoin UIs faster transaction feedback than any other major L2, meaningfully improving the payment experience. For this use case: prioritize providers with flat or request-unit billing (volume spikes shouldn’t surprise your finance team), stable WebSocket connections for real-time confirmation flows, and 99.99%+ uptime with multi-region failover. Explore stablecoin-ready infrastructure → DeFi Protocols Base’s DeFi landscape is anchored by lending markets (Morpho, Aave), major DEXs (Aerodrome, Uniswap), and a growing derivatives layer — all of which place heavy, continuous read demands on RPC infrastructure. During volatility, every protocol queries simultaneously: positions checked, prices updated, liquidity rebalanced. Shared RPC endpoints degrade exactly when your protocol needs them most. Dedicated Nodes eliminate this risk — your infrastructure doesn’t share resources with anyone else, so response times stay consistent whether the market is quiet or in freefall. For lending protocols where stale data or a delayed liquidation has direct financial consequences, that consistency is a business requirement, not a performance optimization. Beyond real-time performance, DeFi protocols need deep historical access for incident investigation, risk modeling, and compliance reporting. Archive data and transaction tracing should be part of your provider selection from day one, not an upgrade you retrofit after an incident. For this use case: Dedicated Nodes for performance isolation during peak market conditions, archive access, and a provider with proven tail latency rather than just marketing averages. Explore Dedicated infrastructure → AI agents on Base Base has become a primary home for onchain AI agents in 2026 — from Coinbase’s AgentKit-powered bots to autonomous DeFi strategies and LLM-orchestrated onchain workflows. Agent workloads expose two infrastructure problems that don’t show up in standard benchmarks: billing unpredictability and WebSocket reliability. Agents generate autonomous, bursty request patterns that are hard to forecast — credit-weighted pricing models can produce invoices that make agent economics unworkable, while a dropped event subscription means a missed liquidation or a failed keeper action. Chainstack is purpose-built for this. Nodes are spec-compliant and expose standardized endpoints that any LLM can connect to out of the box — from OpenAI GPT and Anthropic Claude to Google Gemini, DeepSeek, and compact local models. MCP support ships in two forms: an RPC MCP server for all supported chains, and a Developer Portal MCP server so agents can autonomously ingest best practices and apply them to on-chain operations. For simulation-heavy agent architectures, full forking and call simulation is available out of the box. And the RU pricing model — 1 RU per standard call, 2 RU per archive or debug call — makes cost scaling predictable as agent volume grows, with no method-weight surprises. For this use case: flat-rate or request-unit billing, high RPS headroom for burst windows, stable WebSocket infrastructure, and Flashblocks support. Try RPC for AI agents → In-depth Base RPC providers analysis Below, we take a closer look at how individual Base RPC providers perform in real-world production environments, including latency consistency, scalability, and operational reliability. Chainstack What makes Chainstack stand out for Base is how much is available from the same console: Global Nodes for geo-balanced Base RPC access across US, EU, and APAC. Dedicated Nodes for isolated performance and full control over node configuration — worth it when tail latency consistency matters. Archive nodes for full historical data from genesis, including debug and trace queries. MEV protection enabled by default on Global Nodes, with the option to opt out from the node’s Add-ons tab. Self-Hosted deployment (Base-Reth + Base-Node) for teams that need the node inside their own infrastructure perimeter. Unlimited Node add-on for flat monthly pricing with no request limits — useful for workloads with unpredictable burst windows. Base developer tooling with Base APIs, testnet faucet, and step-by-step development guides covering setup, deployment, and production best practices. MCP support for AI agent integrations — compatible with any LLM out of the box. All of this adds up to a Base setup that covers nearly every use case. Whether you’re building stablecoin infrastructure, DeFi protocols, or AI agent backends, Chainstack gives you reliable performance, clear pricing, and infrastructure to scale with. 🤖 You can also access Chainstack Base RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP, or see the Chainstack Agents page for the fuller agent stack. DetailsPricingDeveloper — free, 3M req/mo (~25 RPS). Growth — $49/mo, 20M req (~250 RPS). Pro — $199/mo, 80M req (~400 RPS). Business — $499/mo, 200M req (~600 RPS). Enterprise — from $990/mo, 400M+ req, custom RPS. Unlimited Node add-on from $149/mo flat. Dedicated Nodes — $0.50/hr compute. Crypto payments accepted.Billing modelRequest Units: 1 RU per full node call, 2 RU per archive call. No method-weight multipliers.Uptime / SLAFormal SLA document: 99.99% minimum with service credits. Product positioning on Global/Dedicated lines: 99.99%+. Public status page available.SecuritySOC 2 Type II and ISO 27001 certified (achieved late 2025). Security materials accessible via security page.FlashblocksSupported on Base Mainnet and Sepolia.Archive / debugFull archive from genesis; debug and trace methods included on Dedicated. For enterprise: SOC 2 Type II and ISO 27001 artifacts are available, access controls are production-grade, and managed upgrades eliminate the OP Stack timestamp divergence risk. The distinction between the formal SLA document (99.99% minimum) and the product-level positioning (99.99%+) is worth noting for vendor risk documentation — both figures exist and serve different purposes. Pros: Transparent RU billing, Flashblocks support, Unlimited Node add-on, full archive + debug/trace, SOC 2 Type II and ISO 27001, access controls, 70+ chains, crypto payments. Cons: Fixed RPS per tier (ultra-high-frequency apps may need Dedicated); free tier tight for indexers/bots; Dedicated Nodes require at least Pro plan; Ultra-high-frequency trading systems requiring custom node-level tuning may prefer fully self-hosted or bespoke infrastructure configurations. RouteMesh RouteMesh is an RPC aggregation and routing layer rather than a node operator — it routes requests across 16-20 upstream providers per method, including Chainstack, with real-time health scoring and automatic failover. RouteMesh confirms full support for Base. Pricing is split between a free community endpoint (read requests routed to public nodes, transaction sends routed to premium infrastructure) and a Premium tier priced $3-$6 per million calls depending on routing strategy. For teams that want redundancy without managing multiple provider relationships, RouteMesh’s automatic failover across many upstream operators is the pitch. Pros: Automatic failover across many upstream providers, low p50 latency on reads, no vendor lock-in. Cons: No formal SLA; archive depth and debug/trace availability depend on whichever upstream serves a given request rather than being a property you configure directly. OnFinality OnFinality runs managed Base infrastructure on a request-unit (RU) model across four tiers: Developer (free, 400K RU/day, 40 RU/sec, archive access, no trace API), Growth ($49/mo, 20M RU/month, 200 RU/sec, trace API included, $6 per million RU overage), Accelerate ($249/mo, 100M RU/month, 500 RU/sec, $3.75 per million RU overage), and Ultimate (custom limits and pricing, enterprise support). The public endpoint is capped at 5 RPS. Dedicated Base Nodes are available on every paid tier for high-volume RPC, exchanges, indexers, archive-heavy analytics, and trace workloads. Pros: Dedicated Nodes, archive plus trace/debug on paid tiers, WebSocket subscriptions. Cons: No SLA published on free/public tiers; formal SLA terms for paid tiers weren’t independently confirmed and should be checked directly before a production commitment. dRPC dRPC takes a different architectural approach: rather than running its own node infrastructure, it aggregates across 40+ providers in 9 geoclusters, routing traffic intelligently to optimize availability and performance. Base mainnet and Sepolia are available, and Base’s official documentation highlights dRPC’s smart routing, analytics, key control, and front-end protection as specific differentiators. The most significant development for cost planning: in 2025, dRPC moved to flat-rate method pricing — 20 CU per request regardless of method, at $6 per 1M requests. This eliminates the “pricing trap” that makes debug_traceTransaction and eth_getLogs expensive surprises in credit-weighted models. For DeFi teams doing heavy log queries or trace-based analytics, this is a meaningful advantage. DetailsPricingFree — 210M CU/30 days (public nodes only). Paid — PAYG with deposit, flat-rate: 20 CU per request, $6 per 1M requests. Private endpoints and additional features (fallback, verification) on paid tier. “Go unlimited” option available.Billing modelFlat-rate per request — no method-weight multipliers. Predictable cost regardless of call composition.Uptime / SLAHigh availability through multi-provider routing. Public status page available (Base mainnet and Sepolia listed as components). No formal published SLA.SecurityNo publicly documented SOC 2 certification at time of writing.FlashblocksAvailable through aggregated Base endpoints.Multi-provider routingReduces risk from individual upstream provider degradation — but does not eliminate OP Stack L2 failure classes (sequencer downtime, L1 publication issues). Important nuance on reliability: dRPC’s aggregation reduces the risk of a single upstream provider degrading your service, but this is distinct from L2-level reliability. Sequencer downtime and safe/finalized discrepancies are OP Stack characteristics that exist at a layer above any RPC provider’s routing logic. The correct framing: dRPC reduces upstream-provider risk, not L2 protocol risk. Pros: Flat-rate pricing (no method surprises), most generous free tier, multi-provider redundancy, public status page, no vendor lock-in. Cons: No formal SLA; no SOC 2 certification; enterprise compliance features depend on specific contract terms; performance consistency varies across distributed provider network. Ankr Ankr provides Base access through a globally distributed network spanning 800+ nodes across 12 countries on 5 continents, with Base mainnet and Sepolia available over HTTPS and WebSocket. The platform publishes specific performance metrics: average response time 56ms, 99.99% uptime, 2.5B+ daily API requests across the network — a level of public performance transparency that’s rare in this space. For multi-chain teams adding Base to an existing stack that already includes other EVM and non-EVM networks, Ankr’s breadth (40+ chains) and consistent API surface lower the integration overhead compared to managing separate providers per chain. DetailsPricingFree — 200M credits/mo (~30 RPS). Premium — PAYG at $0.10 per 1M credits; EVM methods flat at 200 API credits each. Enterprise — custom SLA, region orchestration, dedicated infrastructure.Billing modelAPI credits; EVM methods uniformly 200 credits (simpler than variable CU weights, but still credit-based).Uptime / SLA99.99% uptime and 56ms avg response time publicly stated. Enterprise plan includes custom SLA.SecuritySOC 2 Type I certified (Asphere entity). SOC 2 Type II and ISO 27001 reported as near completion — verify current trust center status before using in vendor risk documentation.FlashblocksAvailable through Base endpoint.ArchiveFull and archive access available. On SOC 2 status: Ankr’s enterprise entity (Asphere) holds SOC 2 Type I. Type II has been described as nearly complete. For enterprise vendor risk documentation, confirm current certification status directly with Ankr’s trust center rather than relying on this article — the status may have updated since publication. Pros: 200M free credits/mo, publicly stated performance metrics (56ms / 99.99%), HTTP + WSS + archive, 40+ chains including non-EVM, flexible PAYG. Cons: SOC 2 Type II and ISO 27001 not yet confirmed (verify current status); advanced analytics/support gated to paid; performance can vary across distributed nodes; no flat-rate unlimited option. Alchemy Alchemy functions as a developer platform that extends well beyond raw RPC. For Base specifically, it is listed as an official node provider in Base documentation and publishes a Flashblocks quickstart covering pending block logic for key methods — reducing integration friction for teams adding preconfirmation to existing applications without changing API surface. The platform’s strongest differentiation for DeFi workloads is tooling depth: Notify for event webhooks, Transact for private transaction submission, Mempool access for MEV-aware strategies, and real-time analytics dashboards. Teams building liquidation bots, MEV searchers, or event-driven settlement systems will find Alchemy’s extended APIs genuinely useful. DetailsPricingFree — 30M CUs/mo (~25 RPS). Pay-as-you-go — $5 per 11M CUs. Enterprise — custom with volume discounts. Different methods have different CU weights (heavier calls cost more).Billing modelCompute Units: method-weighted. Bill depends on call composition, not just volume. Requires tracking method mix for accurate budget modeling.Uptime / SLA99.99% uptime claimed during peak market conditions; global infrastructure with automatic failover. Formal SLA on Enterprise plans.SecuritySOC 2 Type II certified; public trust center available.FlashblocksFlashblocks API quickstart published; accessible through existing Alchemy Base RPC.Archive / debugAvailable; specifics depend on plan tier. On OP Stack and sequencer risk: Alchemy’s Flashblocks integration and rich dev tooling are strong, but sequencer risks don’t disappear at the RPC layer. Protocols using Alchemy should still design fallback logic and pause mechanisms for sequencer downtime — the infrastructure doesn’t abstract away OP Stack’s operational characteristics. Pros: SOC 2 Type II, Notify/Transact/Mempool APIs, MEV protection, Flashblocks quickstart, 40+ chains, rich analytics. Cons: CU pricing requires careful method-mix tracking; billing less predictable at scale than flat request models; very high RPS requires Enterprise plan; no Dedicated Node product in standard offerings. Quicknode Quicknode‘s Base infrastructure is among the most complete from an OP Stack-awareness perspective. Its documentation explicitly covers Flashblocks (“partial block updates every 200ms, up to 10× faster than the standard 2-second block”), Trace API, OP-Node API (for rollup-specific objects and diagnostics), and event streaming via Streams and Webhooks. For DeFi teams that need real-time data feeds as an architectural pattern rather than just request-response endpoints, Quicknode’s ecosystem is hard to match. The platform handles enormous volume — 200B+ API calls/month across its network — and maintains a formally guaranteed 99.99% uptime SLA on paid plans, with dedicated clusters available for isolated enterprise workloads. DetailsPricingBuild — $49/mo, 80M credits, 50 RPS. Accelerate — $249/mo, 450M credits, 125 RPS. Scale — $499/mo, 950M credits, 250 RPS. Business — $999/mo, 2B credits, 500 RPS. Enterprise — custom. Credits roll over. Note: eth_call on Base = 20 credits — method-weighting matters significantly for DeFi workloads.Billing modelAPI credits, method-weighted. Call composition directly affects cost.Uptime / SLA99.99% formally guaranteed on paid plans; enterprise SLA available.SecuritySOC 2 Type II + SOC 1 Type 2 + ISO 27001.FlashblocksFull documentation with examples; supported natively.OP Stack-specificOP-Node API, Trace API, Flashblocks docs all available. For DeFi teams specifically: the method-weighted credit model means eth_call and eth_getLogs — the two methods that typically dominate DeFi workloads — consume credits faster. Benchmarking your actual call composition against the credit pricing table before committing to a plan is strongly recommended. Pros: 99.99% formal SLA, SOC 2 Type II + ISO 27001, Flashblocks, OP-Node API, Trace API, Streams/Webhooks, 500+ RPS at scale, archive access. Cons: No free tier (trial only); method-weighted credits make long-term cost modeling complex; no flat-rate unlimited option for burst-heavy workloads. Real-world performance benchmark on Base Provider scores (lower is better) Metrics collected included average response latency and request success rate per method. All providers were tested within the same 30-minute timeframe to ensure comparable network conditions. Performance metrics may vary depending on network congestion, market volatility, regional traffic spikes, and provider-side scaling events. The results reflect relative performance during the measured window rather than absolute guarantees under all conditions. Dedicated and Enterprise-tier infrastructure were not included in this benchmark. Response time by API method — key findings The method-level breakdown reveals differences that matter significantly for Base production workloads: eth_getLogs — Quicknode showed substantially higher response times (~1.5–2s range) compared to Chainstack, Alchemy, and dRPC on this method. For DeFi protocols where log scanning is a core operation (event indexing, liquidation triggers, settlement confirmation), this gap is operationally significant. eth_subscribe — dRPC showed the highest latency on WebSocket subscriptions (~2s), which matters for any application relying on real-time event streams rather than polling. eth_call, eth_getBalance, eth_blockNumber — All providers performed comparably on these lighter methods, with differences in the sub-100ms range. debug_traceTransaction, debug_traceBlockByNumber — Chainstack and Alchemy led on trace methods, relevant for DeFi incident analysis and compliance workflows. What this means by use case For stablecoin and payment flows — dominated by eth_call (balance checks) and eth_getTransactionReceipt (confirmation) — all four providers perform comparably. The overall score difference between Chainstack (0.38) and Alchemy (0.40) is minimal at this method profile. For DeFi protocols — where eth_getLogs and eth_subscribe drive a significant portion of traffic — Chainstack and Alchemy pull ahead meaningfully. Quicknode’s eth_getLogs latency and dRPC’s eth_subscribe latency are worth testing against your specific workload before committing. For archive and trace-heavy workloads (analytics, incident response, compliance reporting) — Chainstack’s advantage on debug/trace methods is consistent across regions. These results illustrate how Base RPC providers diverge under real production method mixes rather than synthetic single-method testing. Methodology note: Scores reflect growth-tier plan benchmarks across EU, JP, and US West. Enterprise or Dedicated tier performance will differ — dedicated infrastructure typically shows lower tail latency and more consistent p95/p99 than shared endpoints. Run provider-specific benchmarks using the Chainstack Compare Dashboard against your actual method mix before finalizing infrastructure decisions. Conclusion: choosing the right Base RPC providers For Base in 2026, choosing between Base RPC providers means selecting the infrastructure layer that will quietly determine your system’s reliability, cost predictability, and upgrade resilience. Base’s dominance as the leading L2 (48.54% of rollup TVL, #1 EVM chain after Ethereum) means the stakes for infrastructure decisions are higher than ever. Stablecoin platforms need WSS stability and sequencer monitoring. DeFi protocols need tail latency control and honest cost modeling under peak load. AI agents need flat-rate billing, high RPS headroom for burst windows, and stable WebSocket connections for event-driven execution. Chainstack covers all three — predictable request-unit pricing, SOC 2 Type II and ISO 27001, full archive and debug access, Flashblocks support, and managed infrastructure that handles Base upgrades on your behalf. For teams where Base infrastructure is foundational rather than incidental, it’s the most complete option in 2026. Deploy your Base RPC endpoint on Chainstack → FAQ Why can’t I use Base’s public RPC endpoints for production? Base explicitly marks its public endpoints as rate-limited and not suitable for production workloads. The official Base documentation recommends using partner node providers or self-hosting for any application requiring consistent performance. This is the starting point, not a footnote. What is Flashblocks and why does it affect RPC provider selection? Flashblocks is Base’s preconfirmation mechanism, delivering partial block updates every 200ms versus the standard ~2-second block time. For stablecoin confirmation flows, DEX interfaces, and any time-critical UX, Flashblocks support at the RPC/WSS level is now a baseline requirement, not an optional feature. Verify that your chosen provider explicitly supports Flashblocks on Base mainnet. What happens to my application during Base sequencer downtime? The sequencer going down looks like a frozen block height — users cannot submit transactions through the standard path. This is not an RPC provider failure. Well-architected applications detect this condition and enter a grace period or pause state. An RPC provider can help by maintaining stable reads and correct WSS behavior during the incident, but cannot route around the sequencer. How do OP Stack upgrades affect my RPC infrastructure? OP Stack upgrades activate at hard timestamps. Self-hosted nodes and unmanaged infrastructure that miss the window diverge from the canonical chain and require resync. Managed RPC providers coordinate upgrades and eliminate this risk. For enterprise teams and any production system where unplanned downtime is unacceptable, this is a concrete operational argument for managed infrastructure. Which provider has the most predictable billing for DeFi workloads? For DeFi workloads dominated by eth_getLogs, eth_call, and trace methods, method-weighted credit models (Alchemy, Quicknode, Ankr) make cost modeling complex because heavier methods consume credits faster. Chainstack’s request-unit model (1 RU per call) and dRPC’s flat-rate model ($6/1M, 20 CU regardless of method) are the most predictable for mixed or trace-heavy workloads. How do I connect to Base on Chainstack? 1. Log in to your Chainstack account (or create one if you don’t have it yet).2. Create a new project or select an existing one.3. Choose Base Mainnet or Base Sepolia Testnet.4. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app.Need testnet ETH to get started? Chainstack’s built-in Base Sepolia faucet lets you fund a test wallet directly from our website — no third-party tools required. Related Reading Flashblocks on Base: 200ms preconfirmations for lightning-fast UX How to get a Base public RPC endpoint Best Ethereum RPC providers in 2026 Base: Deploy an ERC-721 contract with Hardhat #### Best blockchain infrastructure providers in 2026 The blockchain infrastructure market in 2026 is more fragmented than the marketing suggests. “Bare metal”, “Web3 servers”, “managed validator”, “dedicated for blockchain” — these phrases get used interchangeably even when the products underneath them are completely different categories. Buyers pick by brand recognition or pricing, then find six months in that they bought the wrong category and need to migrate. This guide ranks nine providers across four distinct infrastructure categories. For each, we cover what they actually deliver, who they’re built for, and where they fit in the broader 2026 landscape. We end with how Chainstack Self-Hosted plugs in as the node operations layer that works on top of most of them. The blockchain infrastructure landscape in 2026 Pick the category first, then the provider inside that category. Mixing categories is where most teams lose money. Bare-metal hosts — physical, single-tenant servers. You own the OS, the node software, the monitoring, the recovery. Maximum performance and control, maximum operational burden. Latitude.sh, Hetzner, OVHcloud, Cherry Servers. Pre-installed managed servers — bare metal that ships with a node operations platform already running. You log in to a control panel, deploy nodes, and the operational layer (deployment, self-healing, monitoring, updates) is handled. HOSTKEY, Velia, BreezeHost, serverside.com, and Vultr through Chainstack Self-Hosted. Cloud / VM platforms — virtualized infrastructure with general-purpose marketplaces. Easier to spin up and tear down, but with virtualization overhead that matters for heavy validator and archive workloads. DigitalOcean. Managed node and validator services — they run nodes on their infrastructure, you keep custody of keys or just delegate stake. Zero operational burden, but you don’t own the hardware. Allnodes. The categories aren’t ranked against each other — they answer different questions. The question is which question matches your team’s reality. Most providers sell in more than one category — the matrix below shows where each operates and where they’re placed in this guide. ProviderBare metalCloud VMManaged K8sPre-installed SHManaged serviceLatitude.shPrimary————OVHcloudPrimarySecondarySecondary——Cherry ServersPrimary————HetznerPrimarySecondary———HOSTKEYSecondary——Primary—VeliaSecondary——Primary—BreezeHostSecondarySecondary—Primary—serverside.comSecondary——Primary—DigitalOceanSecondaryPrimarySecondary——Vultr—Secondary—Primary—Allnodes————Primary Primary = the category we cover for this provider below. Secondary = they sell it, but it’s not why they’re in this guide. If you came here looking for managed Kubernetes specifically, OVHcloud and DigitalOcean cover it even though we discuss them under other primary categories. How we evaluated each provider CriterionWeightWhat we looked atBlockchain workload fit25%Hardware specs matched to node requirements, NVMe capacity, network throughputOperations layer25%What runs above the OS — managed services, monitoring, recovery, updatesPricing transparency20%Flat-rate vs metered, egress costs, sustained-use economicsGeographic coverage15%Datacenter locations relevant to validator decentralization and latencyProvisioning experience15%Time from order to usable server, API access Operations layer carries the same weight as workload fit because it determines what your team actually has to build versus what comes with the server. Two providers with identical hardware specs can have a 10x difference in the operational work required to keep nodes running. Bare-metal hosts 1. Latitude.sh — the largest Web3-focused bare-metal host Latitude.sh hosts roughly 19% of Solana validators by stake, making it the second-largest Solana infrastructure provider after Teraswitch — per independent measurement from Helius (epoch 685, August 2025). That single number tells you more about their Web3 positioning than any marketing page. They operate 20 global locations, run Gen4 instances tuned for Solana RPC and validator workloads, and have a formal partnership with Jito Labs for MEV-enabled Solana validator deployments. What you get: Single-tenant bare-metal servers with API-first provisioning, NVMe storage at meaningful capacities, high-clock CPUs, generous network. Crypto payments accepted. Free 20TB egress per server with pooling. Strengths: Genuine track record in Solana infrastructure. Strong hardware specs. Clean Terraform-friendly API for fleet automation. Geographic depth in regions other hosts ignore — including South America. Limitations: No first-party operations layer — out of the box you handle deployment, monitoring, failover, and updates yourself. Chainstack Self-Hosted installs cleanly on top to close that gap. Pricing sits in the mid-to-upper range for European-equivalent specs. Best for: Solana validator and RPC operators, teams that want raw bare metal with API automation, organizations that value supply-side decentralization (Latitude.sh’s geographic spread genuinely contributes to it). Why #1: Of every independent host in this comparison, Latitude.sh is the only one whose market position in a major blockchain ecosystem is measurable and significant. That’s a stronger signal than any positioning page. 2. OVHcloud — European hyperscaler with serious Web3 commitment OVHcloud hosts approximately 8.65% of Solana validators (Helius, August 2025), placing them third globally behind Teraswitch and Latitude.sh. Their blockchain product line is a real investment, not a marketing landing — they have an official Web3 product page, dedicated blockchain documentation, a global blockchain director (Omar ABI ISSA), and case studies with organizations like EthStaker for Ethereum validator deployment. What you get: Bare-metal servers, cloud instances, managed Kubernetes, up to 10 Gbps public bandwidth with zero ingress/egress fees on Dedicated Servers. Multiple European and global datacenter regions. ISO/IEC 27001, SOC certifications. Sustainability metrics with carbon tracking. Strengths: Genuine Solana validator footprint. Service breadth — when you need managed K8s for orchestration plus bare metal for nodes plus block storage for archive data, you can get it from one provider with one bill. Up to 99.99% SLA. Active in EthStaker, Hoodi, and Ethereum staking communities. Limitations: Console UX is built for enterprise workloads, not node operators specifically — there’s a learning curve. Pricing varies by datacenter region. Best for: Mid-to-large teams that need a hyperscaler’s service depth (managed K8s, networking, storage tiers, compliance) alongside bare metal, and want a single vendor relationship. Why #2: OVHcloud is the closest thing to “enterprise-grade Web3 infrastructure as a service” in 2026 without being a hyperscaler that bans crypto. Trade-off versus Latitude.sh is breadth vs depth. 3. Cherry Servers — Solana-heavy bare metal with crypto-friendly billing Cherry Servers hosts approximately 8.45% of Solana validators (Helius, August 2025) — fourth-largest globally. They’re a Lithuanian bare-metal host that has invested heavily in Solana-specific positioning, including a partnership with DoubleZero for ultra-low-latency network routing between validator nodes. Cherry Servers accepts 15+ cryptocurrencies for billing, which makes them a default choice for teams that want to pay infrastructure costs from their treasury directly. Solana validator operators like Everstake, StableLab, and ELSOUL LABO publicly run on Cherry hardware. What you get: Single-tenant bare metal with AMD EPYC and Ryzen CPUs, up to 768GB DDR5 RAM, enterprise NVMe storage, 3 Gbps network with 100TB free egress per server. Crypto payment support including BTC, ETH, USDC, SOL, USDT. EU-based data centers (Amsterdam, Frankfurt, Lithuania, Stockholm) connected to DoubleZero. Strengths: Real Solana validator market share with public reference customers. Crypto-native billing without third-party processor friction. 24/7 Web3-aware support including Telegram. DoubleZero connectivity for latency-critical workloads. Limitations: Cherry is pure hardware — everything above the OS is on you out of the box. “Web3-ready” in their marketing means hardware tuned for blockchain workloads, not a node management platform; Chainstack Self-Hosted installs on top to provide that layer. Self-claimed “second-largest” and “third-largest” Solana provider position depending on which Cherry page you read — independent Helius data places them fourth. Best for: Teams that want crypto-friendly billing without going through a payment processor, Solana validator operators willing to build their own operational stack, anyone whose primary constraint is “don’t lose access to your servers because the host doesn’t like crypto.” Why #3: Real Solana traction, real Web3 commitment in the product. Ranks below OVHcloud because the operations gap is wider — OVH gives you managed K8s and storage tiers to build on, Cherry gives you only the box. 4. Hetzner — best value bare metal in Europe, with a crypto warning Hetzner sells the cheapest serious bare-metal hardware in Europe. AX-series machines with high-clock CPUs and multi-TB NVMe storage cost meaningfully less here than at any provider above. For solo Ethereum stakers and small validator teams, it’s the default cost benchmark. There’s one critical caveat: in November 2022, Hetzner blocked all Solana validator activity on their network, forcing 1,000+ nodes offline overnight and taking roughly 20% of Solana’s network stake delinquent. Hetzner’s terms of service prohibit cryptocurrency activity. The 2022 enforcement against Solana wasn’t an isolated incident — it was the policy being applied. Operators report account verification friction for accounts flagged as crypto-related, and the same enforcement risk remains in 2026. What you get: Bare-metal or cloud servers via Hetzner Robot and Hetzner Cloud. OS images, no first-party blockchain templates. Mature network, reliable hardware, broad community knowledge base for node setup. Strengths: Lowest cost-per-spec in Europe. Hardware specs well-matched to Ethereum, Polygon, and similar full-node requirements. AX-series machines are popular among solo stakers. Limitations: Cryptocurrency activity violates Hetzner’s terms of service. Running validators here means accepting the risk that the provider can terminate your servers at any time. Geographic coverage limited to Germany and Finland. Best for: Cost-sensitive solo Ethereum operators on full (non-validator) nodes, where the workload is read-heavy and a sudden termination is recoverable. Not recommended for production validator deployments without a documented exit plan. Why #4: Pure economics keep Hetzner in the conversation. Risk profile keeps them at the bottom of the bare-metal category for serious workloads. Pre-installed managed servers (Chainstack SH partners) Five hosting providers ship their servers with Chainstack Self-Hosted already installed. Pick any of them, finish checkout, and you land directly in the SH control panel — no install step, no Kubernetes setup, no monitoring stack to build. Each partner brings a different strength. There is no “best” inside this group — they cover different geographies, price points, and customer profiles. HOSTKEY — broadest geographic reach. Servers with Chainstack Self-Hosted pre-installed across the Netherlands, UK, Germany, Finland, Iceland, Turkey, and the US. Good fit for teams that need nodes in regions where hyperscalers are expensive or absent. Deploy on HOSTKEY. Velia — steepest first-month discount. 80% off your first month with code ChainstackSH80. Useful for evaluating Self-Hosted on a real workload before committing to a long-term contract. Get 80% off on Velia. BreezeHost — Web3-focused host. 50% off your first month with code CHAINSTACK50. Peering, network configuration, and hardware questions get handled by people who already know what a node operator is asking for. Get 50% off on BreezeHost. serverside.com — UK/EU coverage with long-running managed-services maturity. 10% off on servers with Self-Hosted pre-installed. Get 10% off on serverside.com. Vultr — global cloud marketplace. Chainstack Self-Hosted available as an app in the Vultr marketplace at checkout, across Vultr’s global datacenter footprint. Deploy on Vultr. Cloud / VM platforms DigitalOcean — best developer UX, virtualization-first DigitalOcean wins on developer experience. The console is clean, the API is well-documented, the Marketplace catalog is broad, and the community of tutorials is the largest of any provider here. None of those one-click apps cover production blockchain nodes — DO’s Marketplace is general-purpose — but everything around the box (provisioning, networking, snapshots, managed Kubernetes) is faster to navigate than at the hyperscalers. What you get: Droplets (cloud VMs), bare-metal options via DigitalOcean dedicated, managed Kubernetes (DOKS), block storage. Global datacenter coverage. No blockchain-specific templates. Strengths: Best developer UX in this comparison. Mature managed Kubernetes that pairs naturally with Chainstack SH. Clean API. Transparent pricing. Limitations: Virtualization-first compute is less efficient per dollar than dedicated bare metal for sustained validator and archive workloads. Egress bandwidth costs add up at scale. Best for: Developer teams already using DO for application infrastructure who want to add node operations on top — typically by deploying Chainstack SH on a DOKS cluster. Managed node and validator services Allnodes — managed validator service (different category, included for clarity) Allnodes is on this list because search intent overlaps with the others, not because they’re in the same category. Allnodes runs blockchain nodes and validators on their infrastructure — you don’t get a server, you get a managed node. They support Ethereum, Solana, Polygon, Cosmos ecosystem, and many others. You keep custody of your validator keys, they handle the operations. Strengths: Truly zero-config compared to anything else in this list. Strong protocol coverage. Reasonable pricing for the convenience. Limitations: You don’t own the infrastructure. You can’t customize the node software stack, you can’t run an archive node tuned to your application, you can’t peer the node into your private network. Chainstack Self-Hosted doesn’t apply — there’s no server to install it on. Best for: Home stakers and small operators who want a managed validator and don’t care about owning the underlying hardware. Comparison table ProviderCategorySolana validator share (Helius 2025)Crypto-friendly billingOperations layerLatitude.shBare metal19% (#2)YesNone — BYOOVHcloudBare metal + cloud8.65% (#3)No (standard payments)Optional managed K8sCherry ServersBare metal8.45% (#4)Yes (15+ cryptos)None — BYOHetznerBare metalBanned 2022NoNone — BYOHOSTKEYPre-installedNot measuredStandardChainstack SH pre-installedVeliaPre-installedNot measuredStandardChainstack SH pre-installedBreezeHostPre-installedNot measuredStandardChainstack SH pre-installedserverside.comPre-installedNot measuredStandardChainstack SH pre-installedVultrPre-installedNot measuredStandardChainstack SH pre-installedDigitalOceanCloud VMNot measuredNoOptional managed K8sAllnodesManaged serviceN/A (runs nodes for you)YesManaged service is the product Chainstack Self-Hosted layer Most of the bare-metal providers above sell you a great box and leave the rest to you. That gap is what Chainstack Self-Hosted fills. SH is a Kubernetes-native control plane for blockchain nodes that runs on infrastructure you control. Currently supported deployments: Available now: Ethereum mainnet, Sepolia, Hoodi (Reth + Prysm clients), Bitcoin, Base, TRON, Optimism, StarkNet, Unichain, Zora Coming soon: Solana, Arbitrum What SH delivers on top of any compatible host: One-click node deployment with right-sized configurations applied automatically Self-healing — nodes that crash or fall behind recover without manual intervention Automated update workflows — get notified when client updates are available, control when they’re applied Zero-downtime failover to a secondary node, a Chainstack managed RPC endpoint, or any endpoint you specify Integrated monitoring — Grafana, VictoriaMetrics, and a blockchain node exporter, ready from day one SH installs cleanly on Latitude.sh, OVHcloud, Cherry Servers, DigitalOcean (via DOKS), and any other Kubernetes-capable host. Hetzner technically supports the install, but the policy risk above applies. For teams that don’t want to install it themselves, five partners ship it already running on their servers. The architectural takeaway: the hosting provider choice becomes a question of geography, pricing, and ecosystem fit — not a question of whether you can run production-grade nodes on it. The operations layer stays constant; only the hardware varies. How to choose If you are…Use thisA Solana validator operator wanting Web3-aware bare metal with API automationLatitude.shA team needing a European hyperscaler’s service breadth alongside bare metalOVHcloudRunning validators on crypto-treasury billing with DoubleZero connectivityCherry ServersA solo Ethereum (non-validator) operator focused on absolute costHetzner (with the policy risk understood)No team or time to manage DIY node operationsHOSTKEY, Velia, BreezeHost, serverside.com, or VultrAlready on DigitalOcean for other workloadsDigitalOcean + Chainstack SH on DOKSWanting a managed validator, not a serverAllnodes Get started Chainstack Self-Hosted is available now across five pre-installed partners — and free to install yourself on any infrastructure that meets the requirements. Deploy on HOSTKEY — pre-installed Chainstack Self-Hosted across European, US, and Turkish data centers Get 80% off first month on Velia — code ChainstackSH80 on pre-installed Web3 servers Get 50% off first month on BreezeHost — code CHAINSTACK50 on pre-installed servers Get 10% off on serverside.com — pre-installed Chainstack Self-Hosted in UK/EU Deploy on Vultr — Chainstack Self-Hosted is available as an app in the Vultr marketplace across their global datacenter footprint Install on your own infrastructure — the SH installation guide covers Latitude.sh, OVHcloud, DigitalOcean, Cherry Servers, and any Kubernetes-capable environment Get started with Chainstack Self-Hosted → Conclusion The 2026 blockchain infrastructure market splits into two practical questions. The first: which category fits your workload — bare metal, pre-installed managed, cloud VM, or managed service? Get the category wrong and no provider inside it will save you. The second: which provider inside that category matches your geography, budget, and ecosystem? That’s where the comparison numbers in this guide do their work — Latitude.sh and OVHcloud for serious Solana operators, HOSTKEY through serverside.com for teams skipping the install step, Cherry Servers for crypto-treasury billing. What stays constant across all of them is the operations layer. Whether you choose Latitude.sh and install Chainstack SH yourself, or pick HOSTKEY where it’s pre-installed, the node management experience is the same: deployment in minutes, self-healing, automated updates, integrated monitoring. The provider choice becomes a hardware swap, not a re-architecture. FAQ What’s the difference between bare metal and pre-installed managed servers? Bare metal is a physical server with an OS — Latitude.sh, OVHcloud, Cherry Servers, Hetzner. You install your node software, build your monitoring, write your failover logic. Pre-installed managed servers (HOSTKEY, Velia, BreezeHost, serverside.com, Vultr with Chainstack SH) ship with a node operations platform already running on top of the bare metal — you skip directly to deploying nodes from a control panel. Is Cherry Servers really the third or fourth-largest Solana infrastructure provider? Their own marketing varies between “second” and “third” largest depending on the page. Independent measurement from Helius (epoch 685, August 2025) places them fourth at 8.45% of Solana validators, behind Teraswitch (24%), Latitude.sh (19%), and OVHcloud (8.65%). The “fourth-largest” framing is what the public validator data supports. Can I run Solana validators on Hetzner? You can, but Hetzner’s terms of service prohibit cryptocurrency activity, and they enforced the policy against Solana validators in November 2022, taking 1,000+ nodes offline overnight. The risk remains in 2026. For production validators, choose a host with explicit Web3 support — Latitude.sh, OVHcloud, or Cherry Servers — or run pre-installed SH on a partner host where the relationship is contractually aligned with blockchain workloads. Can I install Chainstack Self-Hosted on a server I already have? Yes. Chainstack Self-Hosted is infrastructure-agnostic. If your server can run Kubernetes with the required storage and networking — that covers Latitude.sh, OVHcloud, Cherry Servers, DigitalOcean, the major hyperscalers, and on-prem hardware — SH installs on top. The installation guide walks through the setup. Cherry Servers vs Chainstack — are they competitors? They’re complementary, not competing. Cherry Servers is a hardware provider — they sell you a bare-metal box. Chainstack Self-Hosted is a node operations platform — it runs on the box. Teams running on Cherry Servers can install Chainstack SH on top to get automated deployment, self-healing, monitoring, and failover. The combination — Cherry hardware with crypto billing + SH operations — is a legitimate stack for crypto-native teams. Is Allnodes the same category as Latitude.sh or Cherry Servers? No. Allnodes is a managed node and validator service — they run nodes on their infrastructure, you don’t get a server. Latitude.sh and Cherry Servers sell you a server you control end-to-end. If your reason for running a node is “I want to own my infrastructure,” Allnodes is the wrong category. If your reason is “I want a validator running with minimal effort,” it’s a reasonable choice. What protocols does Chainstack Self-Hosted support in 2026? Available now: Ethereum (mainnet, Sepolia, Hoodi). Available in the SH control plane: Bitcoin, Base, TRON, Optimism, StarkNet, Unichain, and Zora. Coming soon: Solana and Arbitrum. Additional protocols are added regularly — check the Chainstack SH documentation for the current list. Additional resources Chainstack Self-Hosted Top 5 easiest ways to run an Ethereum node in 2026 Top 5 Ethereum node setup tools in 2026 How to run a self-hosted blockchain node on HOSTKEY Chainstack Self-Hosted documentation #### Best BNB Smart Chain RPC providers for production use in 2026 BNB Smart Chain’s continued growth in 2026 has driven strong demand for production-grade RPC infrastructure across stablecoin platforms, real-world asset (RWA) tokenization, and enterprise deployments. As one of the most active blockchain networks, BNB Chain processes millions of transactions daily for payments, settlement, asset issuance, and corporate on-chain systems—choosing the right BNB Smart Chain RPC providers are a foundational requirement rather than an optimization. Each category brings distinct infrastructure expectations. Stablecoin platforms depend on uninterrupted transaction flows, predictable latency, and cost stability for payments and treasury operations. RWA applications require isolated performance, auditability, and compliance-ready infrastructure for token issuance and lifecycle management. Enterprise deployments demand strict uptime guarantees, consistent throughput, and transparent pricing that scales with long-term production use. In this benchmark, we compare the best BNB Smart Chain RPC providers for Web3 in 2026 across core production metrics including latency, uptime, throughput, pricing models, and security posture. The analysis focuses on three primary BNB Smart Chain use cases—stablecoin infrastructure, RWA platforms, and enterprise workloads—to evaluate how each provider performs under real-world production conditions. BNB Smart Chain RPC providers comparison What separates one RPC provider from another usually comes down to the same few metrics: pricing, latency, uptime, and scalability options available. Here’s how the leading BNB Smart Chain options measure up: #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow-latency global routing with 99.99%+ uptimeDocs, dashboard metrics, tooling, testnet faucets, archive, Access rules2OnFinality400K response units/day, up to 40 RU/secGrowth $49/mo (20M RU, $6/M extra); Accelerate $249/mo (100M RU, $3.75/M extra); Ultimate custom99.99% 30-day uptime; HK + N. Virginia regionsArchive on every plan, Trace/Debug on paid, pay-as-you-go dedicated nodes3Ankr200M credits/month, ~30 RPSPay-as-you-go ($10 per 100M credits), goes up to up to 15,000 RPS.GEO-distributed network, 99.99% SLA on Enterprise tiersSimple dashboard, multi-chain support, HTTPS & WebSocket, archive available4GetBlock50k req/day (~1.5M /mo), 20 RPS$39 for 50M (100 RPS); $399 for 600M (500 RPS); Dedicated from $1000 no capRegional nodes, 99% shared / 99.99% dedicated uptimeBasic dashboard, regional choice, easy setup5Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow-latency routing, uptime available on higher tiersTransact & Notify APIs, analytics, SDK support6QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams, Webhooks, team dashboards, multi-region setup Key takeaways from the comparison: Chainstack offers the most balanced feature set with transparent request-based pricing, highest uptime (99.99%+), and full SOC 2 Type II and ISO 27001 certification Alchemy provides the richest developer tooling including Notify and Transact APIs GetBlock is ideal for small projects and developers needing simple setup Quicknode leads in performance with maximum RPS and globally distributed infrastructure When comparing BNB Smart Chain RPC providers side by side, differences in pricing models, uptime guarantees, and throughput limits become especially clear at production scale. Compare Dashboard now tracks Arbitrum and BNB Smart Chain, letting you benchmark RPC providers across latency, uptime, and throughput using real performance data. Before diving into detailed provider reviews, let’s examine how each performs across critical BNB Smart Chain use cases: Choose BNB Smart Chain RPC providers by use case Stablecoin infrastructure Stablecoin platforms on BNB Smart Chain require infrastructure that can sustain continuous transaction flows with zero tolerance for downtime. Payment processing, treasury operations, redemptions, and on-chain settlement depend on predictable latency, high write throughput, and stable operating costs. Even brief RPC interruptions can delay settlements, disrupt payment flows, or create reconciliation issues. To avoid this, production-grade providers rely on multi-region routing and isolated infrastructure to guarantee availability during peak demand. Chainstack supports stablecoin workloads with Dedicated Nodes for transaction execution and the Unlimited Node add-on for unmetered read and write traffic at a flat monthly rate. This setup ensures predictable costs during volume spikes while maintaining 99.99%+ uptime through multi-cloud failover. Explore stablecoin-ready infrastructure → RWA infrastructure Real-world asset (RWA) platforms on BNB Smart Chain place stricter demands on RPC infrastructure than typical DeFi applications, especially as the RWA sector on BNB Smart Chain continues to grow significantly. Token issuance, lifecycle management, compliance checks, and on-chain reporting on BSC require isolated performance, auditability, and long-term reliability to support expanding institutional adoption. RWA workloads are often write-heavy and sensitive to latency inconsistencies, especially during issuance events, rebalancing cycles, or investor reporting periods. Shared RPC environments introduce unnecessary risk for these regulated operations. Chainstack’s Dedicated Nodes provide isolated BNB Smart Chain infrastructure for RWA minting, settlement, and compliance workflows, while the Unlimited Node add-on ensures predictable pricing for analytics dashboards, investor portals, and historical data access. Combined with SOC 2 Type II and ISO 27001 compliance and SLA-backed uptime, this architecture aligns with institutional RWA requirements. Explore Dedicated infrastructure → Enterprise BNB Smart Chain RPC providers Enterprise BNB Smart Chain deployments demand strong performance guarantees. Corporate and institutional users often have high-throughput workloads and strict SLA requirements. Whether building supply chain tracking systems, tokenized asset platforms, or enterprise DeFi solutions on BNB Chain, reliability is non-negotiable. Enterprise RPC essentials: High throughput: Chainstack offers high-throughput plans with custom RPS configurations on BNB Smart Chain and achieves ~99.99% measured uptime via global load balancing SLA guarantees: Quicknode handles enormous volumes (200B+ API calls/month) while maintaining 99.99% uptime SLA for enterprise clients Low-latency across regions: Multi-region data centers and intelligent routing keep response times uniform worldwide Request enterprise plan → SOC 2–compliant BNB Smart Chain RPC providers Security and compliance are paramount for enterprises integrating with BNB Smart Chain. SOC 2 certification has become a key benchmark of a provider’s security controls and operational integrity. Security leaders: Chainstack achieved SOC 2 Type II in late 2025 and ISO 27001, underscoring enterprise-grade security and 99.99%+ uptime SLA guarantees Quicknode maintains SOC 1 Type 2, SOC 2 Type 2, plus ISO 27001 certifications Note: Certification coverage varies by provider; Alchemy holds SOC 2 Type II but has not published ISO 27001 certification, unlike Chainstack and Quicknode, which hold both. In-depth BNB Smart Chain RPC providers analysis Below, we take a closer look at how individual BNB Smart Chain RPC providers perform in real-world production environments, including latency consistency, scalability, and operational reliability. Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most complete ways to connect to BNB Chain without the overhead. By choosing Chainstack BNB Smart Chain RPC node, you get secure HTTP and WebSocket access to BNB Smart Chain Mainnet, and Testnet, backed by 99.99%+ uptime and globally distributed routing for consistently low latency. What makes it stand out is how much is available from the same console: Global Nodes for geo-balanced BNB Smart Chain RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Archive nodes for deep historical reads, full historical blocks from the genesis to the latest one, debug and trace queries on the BNB Smart Chain blockchain. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for unlimited requests with flat monthly pricing, so you never have to worry about hitting plan limits. BNB Chain developer tooling with BSC APIs, testnet faucets, and step-by-step development guides covering setup, deployment, and production best practices. All of this adds up to the BNB Smart Chain setup that covers nearly every use case. Whether you’re deploying contracts, building DeFi products, or streaming on-chain data, Chainstack gives you reliable performance, clear pricing, and infrastructure to scale with. 🤖 You can also access Chainstack BNB Smart Chain RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier.Dedicated Nodes — $0.50 / hour plus storage costs for exclusive, high-performance isolated BNB Smart Chain node instances.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Predictable, request-based pricing with Unlimited Node add-on for flat, unmetered traffic within your chosen RPS tier– Built-in testnet faucets– 99.99%+ uptime SLA, SOC 2 Type 2, globally distributed routing for low latencyOne provider for BNB Smart Chain plus 70+ other chainsCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Dedicated Nodes require at least a Pro plan With Chainstack, you get the full stack: reliability, high RPS, global routing, and archive access, all with pricing that’s clear and consistently better than most. From testing to scaling, the setup doesn’t change, and the costs stay predictable, making it one of the most dependable ways to run BNB Smart Chain at any stage. OnFinality OnFinality provides EVM-compatible HTTPS and WebSocket RPC endpoints for BNB Smart Chain Mainnet and Testnet, with Archive access included on every plan and Trace/Debug APIs available on paid tiers. It also offers pay-as-you-go dedicated BNB Smart Chain nodes for teams that need isolated infrastructure. How much does it cost?Developer — free, 400,000 response units/day, up to 40 RU/sec.Growth — $49/month, 20M response units/month, no daily cap, 200 RU/sec, $6/million extra.Accelerate — $249/month, 100M response units/month, 500 RU/sec, $3.75/million extra.Ultimate — custom pricing, custom throughput, crypto payments accepted.PerformanceUptime: 99.99% 30-day uptime on BNB Smart Chain, publicly tracked.Latency: Endpoints in Hong Kong and N. Virginia.Rate limits: Public endpoint capped at 10 req/min; paid plans scale to 500 RU/sec on Accelerate.Archive: Included on every plan, including Free.Pros– Archive access on every plan, including Free– Trace/Debug APIs on paid plans– Pay-as-you-go dedicated nodes on all tiers– Enterprise plan accepts crypto paymentsCons– Public free-tier rate limit (10 req/min) is tight without upgrading– Trace API not available on the Free plan– Only two endpoint regions (Hong Kong, N. Virginia) vs. broader multi-region coverage elsewhere Ankr Ankr provides BNB Smart Chain RPC through a globally distributed network of node operators, routing traffic across regions to keep latency low and reduce reliance on any single infrastructure provider. You can connect to BNB Smart Chain mainnet and testnet via HTTPS or WebSocket, with more than 30 regions in rotation and archive access available for historical queries and tracing It’s a solid option for teams that prefer a pay-as-you-go model and want to tap into a decentralized setup, though it skips some of the advanced tooling and analytics you’d find in larger, more centralized providers. How much does it cost?Ankr uses an API credits model where credit cost varies by method (heavier calls cost more). Pricing is pegged at $0.10 = 1M API credits (PAYG), and there’s a freemium tier. It’s enough for testing, but high-traffic apps will hit the ceiling quickly.Their paid plans use a pay-as-you-go model:Premium — $10 per 100M credits (~500K requests), with up to 1,500 RPS.Enterprise — from $1,000/month, 15,000 RPS, dedicated endpoints, and priority support.PerformanceUptime: Claims up to 99.9%.Latency: Region-routed.Throughput: 30 RPS on free; ~1.5K–15K RPS on paid tiers.Reliability: Distributed design reduces single-point failures but outages can still occur.Monitoring: The console shows usage and request stats, with more advanced visibility once you move to a paid.Pros– Freemium with 200M credits/month, – Supports HTTP, WebSocket, and archive queries, – Multi-chain supportCons– Advanced visibility/support gated to paid, – No fixed monthly plans, – Fewer built-in analytics If you don’t mind variable performance across regions, Ankr could be a way to go when testing or for the smaller projects. Yet, if you need steady throughput and predictable billing, platforms with fixed RPS tiers and dedicated routing tend to offer a more stable path for production workloads. GetBlock GetBlock provides BNB Smart Chain RPC access on mainnet and testnets over HTTP and WebSocket, with the option to choose regions such as New York, Frankfurt, or Singapore to improve latency. Developers can use shared endpoints to get started quickly or switch to dedicated nodes when they need higher uptime guarantees, archive access, or more consistent performance under load. While it skips the advanced APIs and deep analytics of bigger platforms, GetBlock remains a good option for teams that prioritize simplicity, regional control, and predictable access to BNB Chain infrastructure. How much does it cost?Free Tier — 50k CU per day, 20 RPS.Start (Shared) — $39/month, 50M CU/month, 100 RPS.Advanced (Shared) — $159/month, 220M CU/month, 300 RPS.Pro (Shared) — $399/month, 600M CU/month, 500 RPS.Enterprise (Shared) — from $799/month, custom CU/RPS and features.PerformanceUptime: 99% on shared plans, 99.99% on dedicated.Latency: Region-pinned routing for lower RTT.Throughput: 20 RPS on free, 100 RPS on Start, 500 RPS on Pro, unlimited on Dedicated.Reliability: Shared nodes work well for low-volume usage, but performance can vary when load increases.Monitoring: Basic dashboard is available but deeper analytics are only unlocked on higher tiers.Pros– Dedicated nodes offer unlimited requests and 99.9% uptime, – Low-latency via regional nodes, – Setup is quickCons– Free tier is capped at 20 RPS, – Strict RPS ceilings on shared plans, – Monitoring features are limited compared to other infra providers GetBlock works well for early-stage testing or smaller workloads. However, as demand increases, throughput caps can limit you, and basic options for monitoring will make it harder to manage growth or troubleshoot performance issues at scale. Alchemy Alchemy offers BNB Smart Chain RPC through its Supernode, giving developers access to mainnet and testnets over HTTP and WebSocket, along with extras like Notify, Transact, and Mempool. On top, Alchemy supports dozens of networks, giving access to historical blockchain data, real-time event streaming, and built-in MEV protection on some chains. Backed by global infrastructure, Alchemy suits teams looking for additional APIs and monitoring tools. How much does it cost?Alchemy measures usage in compute units (CUs) rather than raw requests, which can make costs less predictable for teams sending large volumes of latency-sensitive calls compared to flat, request-based models.Alchemy starts with a free tier offering 30M CUs per month, roughly equal to 1.2M basic requests up to 25 RPS. Paid plans scale by total CU usage:Pay-as-you-go — $5 per 11M CUs (~$0.45 per million).Enterprise — custom pricing with lower per-unit costs at high volumes.PerformanceUptime: Reports 99.9% historical uptime, but an uptime SLA is only guaranteed on Enterprise plans.Latency: Region-based routing helps keep response times low; however, Alchemy does not publish official BNB Smart Chain-specific latency numbers.Throughput: Begins at about 25 RPS on the free tier, with scaling up to 300 RPS on paid.Reliability: The Supernode setup helps maintain data accuracy during heavy traffic.Monitoring: You can check usage, errors, and request patterns through the dashboard in real time.Pros– Covers BNB Smart Chain plus 40+ chains, – Built-in MEV protection on supported networks, – Rich toolingCons– CU pricing isn’t intuitive, – Hard to verify real performance without public benchmarks, – Throughput caps by plan, very high RPS needs enterprise plan Alchemy performs reliably under heavy load, and latency stays tight across regions. Its compute-based pricing gives you flexibility in how you use the service, but it also means your bill depends on call mix, not just volume, which can make it harder to model at scale. If you’re building with features like Notify or Mempool streaming, Alchemy is fine option, but less ideal if you want predictable scaling. Quicknode Quicknode runs a multi-region infrastructure for BNB Smart Chain RPC, letting you connect to mainnet and testnets over HTTP or WebSocket. Archive support is available for teams that need to query deep historical data. It also supports dozens of other chains and offers add-ons such as Webhooks and Streams if you want event-based triggers or real-time blockchain feeds. It’s popular with high-traffic teams because the network scales well under pressure, but to get to that performance you would need to move to the higher-priced tiers. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom terms for higher volumes and dedicated support. Credits rollover unused portions, which helps variable BNB Smart Chain loads, though the model adds a layer compared to straight request counts.PerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Scales up to 500+ RPS on higher plans, – Archive data available (by chain/plan), – Low latency from multi-region routingConsFree trial caps at 15-25 RPS with only community support, – Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode gives you speed, global routing, and developer tooling, which makes it good option for BNB Chain apps. The main limitation is its credit-based (method-weighted) pricing. Because different methods burn credits at different rates, long-term cost planning takes more effort, especially if your workload isn’t static. Getting started with BNB Smart Chain on Chainstack The provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. Chainstack bundles the full stack into a setup that takes minutes to deploy: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Choose BNB Smart Chain, then pick Mainnet or Testnet. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Once your endpoint is live, BNB Smart Chain behaves like any standard EVM JSON-RPC — for example, checking the latest block: curl -X POST https://YOUR_CHAINSTACK_ENDPOINT/YOUR_API_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 }' Conclusion Choosing the right BNB Smart Chain RPC provider in 2026 depends on how well the infrastructure aligns with production-grade requirements around availability, cost predictability, and operational control. As BNB Chain continues to power stablecoin settlement, real-world asset (RWA) platforms, and enterprise blockchain systems, RPC reliability becomes a foundational dependency rather than an implementation detail. Stablecoin platforms require uninterrupted transaction processing, predictable latency, and flat cost models that remain stable during volume spikes. RWA applications introduce stricter demands, including isolated performance, auditability, and compliance-ready operations for asset issuance and lifecycle management. Enterprise deployments extend these requirements further with SLA-backed uptime, security certifications, and long-term cost transparency across teams and environments. Chainstack stands out as the most complete solution for these production workloads. With Dedicated Nodes for isolated, mission-critical operations and the Unlimited Node add-on for flat-rate, unmetered traffic, Chainstack enables stablecoin issuers, RWA platforms, and enterprise teams to scale without exposure to variable pricing models or shared infrastructure risk. Backed by 99.99%+ uptime, multi-cloud routing, and SOC 2 Type II and ISO 27001 compliance, it provides a level of reliability suited for regulated and institutional use cases. While other providers offer strong performance or developer tooling, Chainstack delivers the best balance of predictable pricing, operational resilience, and enterprise readiness for BNB Smart Chain in 2026. For teams building long-lived production systems where downtime, latency variance, or billing uncertainty are unacceptable, the choice is clear. Stablecoin platforms needing uninterrupted, predictable-cost transaction flow: Chainstack Dedicated Nodes + Unlimited Node add-on. RWA platforms needing isolated, compliance-ready infrastructure: Chainstack Dedicated Nodes. Enterprise deployments needing SLA-backed uptime and certifications: Chainstack (SOC 2 Type II + ISO 27001). Smaller teams testing before production: Chainstack’s free Developer tier or GetBlock. Deploy your BNB Smart Chain RPC endpoint on Chainstack → FAQ What is BNB Smart Chain RPC and why do I need it? BNB Chain RPC is the standard interface that lets applications communicate with the BNB Chain blockchain. Through an RPC provider, you can read blockchain data (balances, transactions), send transactions, deploy smart contracts, and interact with dApps using JSON-RPC API calls. Without reliable RPC, your app can’t connect to BNB Chain. Which is the top BNB Smart Chain RPC provider in 2026? Chainstack leads for production use on BNB Smart Chain by combining predictable request-based pricing with scalable, enterprise-grade performance. With 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and support for both free and enterprise tiers, it is well suited for stablecoin platforms, real-world asset (RWA) workloads, and long-running enterprise deployments. Are there free BNB Smart Chain RPC options suitable for real development? Yes. Chainstack offers 3M requests/month (~25 RPS) free with full mainnet/testnet access, archive data, and testnet faucets. Alchemy gives 30M CUs (~1.2M requests), and GetBlock 50k daily. Chainstack’s free tier is most generous for actual development. How do I connect to a BNB Smart Chain RPC node? When you start building on BNB Smart Chain, the provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. While different platforms cater to different use cases, Chainstack bundles the full stack into a setup that takes minutes to deploy:1. Log in to your Chainstack account (or create one if you don’t have it yet).2. Create a new project or select an existing one.3. Choose BNB Smart Chain, then pick Mainnet or a Testnet4. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Not only do you get the option to choose between Global Nodes for shared, geo-balanced access or Dedicated Nodes for isolated performance and full control, but every deployment comes production-ready. You also get built-in security through Access rules, plus testnet faucets and MEV protection enabled by default. Everything required to connect, build, and ship on BNB Smart Chain is available in one place. When evaluating BNB Chain RPC node providers, it’s important to consider not only raw performance, but also long-term reliability, pricing transparency, and support for production workloads. Additional resources BNB Chain developer tooling — supported libraries and SDKs for BNB Smart Chain. Getting started with BNB Chain RPC — API reference and setup guide. BEP-1155 contract tutorial — deploy a BEP-1155 contract with Truffle and OpenZeppelin. Chainstack Enterprise plans — custom RPS, SLAs, and dedicated support. Reliable BNB Smart Chain RPC infrastructure Getting started with BNB Chain on Chainstack is fast and straightforward — deploy a reliable node in seconds through an intuitive console, no hardware or complex setup required. With 99.99% uptime, 24/7 SLA-backed operations and low-latency global endpoints, Chainstack ensures seamless RPC access for building and scaling DeFi, analytics, and trading applications. #### Best crypto APIs for developers in 2026 Building a crypto product means making infrastructure decisions early — and the API layer is usually where those decisions matter most. Different crypto APIs solve very different problems. Some aggregate market data and portfolio context into one feed. Others focus on decentralized indexing, real-time DEX data, institutional analytics, or multi-chain querying. Choosing the wrong layer means rebuilding later. Crypto exchange APIs sit next to the data layer, but solve a different job: adding swaps and exchange flows directly inside a product. Wallets, payment gateways, and fintech apps use this layer when they need users to exchange assets without leaving the interface. This guide covers five of the best crypto APIs for developers in 2026 — CoinStats API, ChangeNOW, Birdeye, Glassnode, and Covalent — plus the infrastructure layer that most of them quietly depend on. What to look for in a crypto API Before choosing, it helps to know which data layer your product actually needs: Market data — prices, OHLCV, exchange coverage, trading pairs Wallet and portfolio data — balances, PnL, transaction history, multi-chain holdings DeFi and on-chain data — protocol positions, liquidity pools, smart contract state Developer experience — SDK quality, documentation, rate limits, pricing model Exchange and swap layer — cross-chain swaps, fiat on-ramps, partner monetization flows Most crypto products end up needing at least two of these layers. Knowing which ones upfront saves significant integration time. The infrastructure layer: Chainstack Most crypto APIs deliver data — prices, wallet balances, DeFi positions. But before that data reaches your product, something has to connect to the blockchain and read it. That’s the infrastructure layer. Chainstack provides managed blockchain node infrastructure and RPC endpoints across 70+ chains, including Ethereum, Solana, BNB Smart Chain, Arbitrum, Base, and Avalanche. Trading bots, DeFi apps, and AI agents that need to read on-chain state, monitor mempool activity, or submit transactions directly depend on this layer — not the data APIs below. For latency-sensitive workloads, Chainstack offers dedicated nodes and Yellowstone gRPC for Solana — relevant for HFT bots and MEV operations requiring sub-second data streams. An MCP server is also available for AI agent integrations. If your product consumes market data and portfolio analytics only, the five APIs below cover everything you need. If it interacts with the blockchain directly — reading contract state, monitoring the mempool, executing on-chain transactions — pair your data API with Chainstack’s RPC infrastructure. The 5 best crypto APIs 1. CoinStats API CoinStats API is built around a simple premise: most crypto products end up stitching together three or four separate data providers. CoinStats replaces that stack with a single API that’s often a couple of times cheaper than the multi-provider equivalent. The platform covers five layers in one integration: Market data — real-time prices, OHLCV, and exchange data across 100,000+ assets Wallet data — multi-chain balances and transaction history DeFi positions — live positions across 10,000+ DeFi protocols Portfolio analytics — realized and unrealized PnL, performance metrics, average buy/sell prices Token security — on-chain risk analysis covering contract verification, ownership concentration, and liquidity health This matters most for products that need context beyond price feeds — AI trading assistants, portfolio dashboards, crypto copilots, and multi-chain tracking tools that need to reason about a user’s actual holdings rather than just market movements. Coverage includes 120+ blockchains, 200+ exchanges and wallets, and 10,000+ DeFi protocols. CoinStats also supports MCP, making it compatible with AI agent workflows and LLM-based systems out of the box. On pricing: consolidating market data, wallet tracking, and DeFi analytics into one API is typically cheaper than maintaining separate subscriptions for each layer — which matters at the early stages of product development. Strengths Single API replacing multiple data providers 120+ chains, 200+ exchanges, 10,000+ DeFi protocols Built-in portfolio analytics and PnL tracking MCP support for AI integrations More cost-effective than multi-provider stacks Tradeoffs Broader scope means less depth than specialized providers in any single category Not optimized for ultra-low-latency execution Best for Portfolio dashboards, AI crypto assistants, multi-chain tracking tools, and products that need aggregated crypto intelligence without managing multiple data subscriptions. 2. ChangeNOW ChangeNOW offers a crypto exchange API for products that need swaps inside their own interface. It sits in the execution layer: users select assets, choose a fixed-rate or standard flow, and complete a cross-chain exchange without being redirected to a separate exchange product. ChangeNOW API supports 1,500+ coins across 110+ networks, with liquidity sourced from centralized and decentralized exchanges. It is used by wallets, payment gateways, exchange products, and fintech apps that want a ready exchange flow rather than a custom swap backend. Partner monetization is built into the integration. Teams can start with revenue share from 0.4% per transaction and customize commissions by asset, trading pair, or swap size. ChangeNOW also provides API documentation, 24/7 support, post-integration maintenance, and fiat on- and off-ramp options upon request. Strengths 1,500+ coins across 110+ supported networks Fixed-rate and standard exchange flows Cross-chain swaps between supported assets Partner revenue starting from 0.4% per transaction 99.99% availability and 350 ms response time Tradeoffs Not a market data or portfolio analytics API Fiat on- and off-ramp features are available upon request Products that need custom on-chain analytics will still need a separate data provider Best for wallets, payment gateways, exchange products, and fintech apps that need in-app swaps, cross-chain exchange flows, and partner monetization. 3. Birdeye Birdeye started as a Solana-native data platform and has since expanded across EVM chains — but Solana remains where it runs deepest. The platform reads token prices directly from DEX liquidity pools in real time, which makes it strong on assets that centralized exchanges don’t list: new launches, memecoins, and low-cap tokens that exist only on-chain. Coverage includes wallet balances, transaction history, token security checks, trending token feeds, and WebSocket streams for live price updates. For Solana specifically, Birdeye aggregates liquidity across Raydium, Orca, Jupiter, and other major DEXs into a single price feed. The combination of real-time DEX pricing, wallet data, and token security in one API makes it practical for products where freshness and Solana coverage matter more than institutional depth. Strengths Real-time DEX-native pricing across Solana liquidity venues Strong coverage of new and low-cap tokens Wallet data and transaction history included Token security screening built in WebSocket support for live price streams Tradeoffs Primarily Solana-focused — thinner coverage on EVM chains Less suitable for institutional reference rates or compliance workflows Not designed for portfolio analytics at CoinStats depth Best for Solana trading tools, DEX analytics dashboards, memecoin trackers, and any product where real-time on-chain pricing for new tokens matters. 4. Glassnode Glassnode is the institutional benchmark for on-chain analytics. Where most APIs return raw balances and transactions, Glassnode surfaces derived metrics: entity-adjusted holdings, realized cap, long-term holder behavior, exchange inflows, miner revenue, and macro overlays across Bitcoin, Ethereum, and 1,200+ assets. Two features set it apart for serious research. Entity-adjusted metrics cluster addresses controlled by the same actor — exchanges, miners, large holders — so raw address counts become meaningful economic signals. Point-in-Time data delivers immutable historical snapshots, eliminating look-ahead bias in backtests and model validation. Delivery options include REST, Snowflake, BigQuery, and Parquet or CSV exports. A Glassnode MCP server is also available for AI-assisted research workflows. Strengths 7,500+ on-chain metrics across Bitcoin, Ethereum, and major assets Entity-adjusted data for cleaner economic signals Point-in-Time historical snapshots for bias-free backtesting Institutional delivery options including Snowflake and BigQuery MCP server for AI research workflows Tradeoffs Pricing reflects an institutional buyer profile — not suited for indie projects Limited wallet-level or portfolio aggregation features Narrower asset coverage compared to multi-chain data providers Best for Quant desks, asset managers, macro research teams, and any workflow where audit-grade on-chain history and entity-adjusted metrics matter. 5. Covalent Covalent covers more blockchains in a unified API than any other provider on this list — over 200 networks through a single consistent interface. The same API call structure works across Ethereum, Solana, Avalanche, Fantom, and hundreds of other chains. For teams building on less common networks, Covalent often provides data where other APIs don’t. For teams building cross-chain analytics pipelines, the unified schema saves significant engineering work. Covalent covers wallet balances, token transfers, NFT metadata, log events, and DEX data. The historical data depth is strong, making it well-suited for analytics workloads and products that need to reconstruct historical on-chain state. Strengths Broadest chain coverage — 200+ networks Unified API schema across all supported chains Strong historical data for analytics workloads DEX and liquidity data included Tradeoffs Can be slower than chain-native APIs for real-time use cases Less focused on DeFi position parsing than CoinStats Pricing complexity at scale Best for Multi-chain analytics platforms, blockchain data pipelines, products targeting niche or emerging chains, and data science workloads that need consistent historical data across many networks. Comparison CoinStatsChangeNOWBirdeyeGlassnodeCovalentMarket data✅❌✅LimitedLimitedWallet data✅❌✅❌✅DeFi positions✅❌Limited❌LimitedCross-chain swaps❌✅❌❌❌Fixed-rate exchange❌✅❌❌❌Partner revenue share❌✅❌❌❌Fiat on/off ramp❌✅❌❌❌On-chain analyticsLimited❌Limited✅✅Real-time streams✅❌✅❌LimitedChain coverage120+110+ networksSolana-firstBTC/ETH200+MCP support✅❌❌✅❌Best forAll-in-oneIn-app swapsSolana/DEXInstitutionalMulti-chain Which crypto API should you choose? Choose CoinStats if you need market data, wallet intelligence, DeFi positions, and portfolio analytics in one integration — particularly for AI-powered products. Choose ChangeNOW if your product needs in-app cross-chain swaps, a ready exchange flow, and partner monetization without building a custom swap backend. Choose Birdeye if you’re building on Solana or need real-time DEX-native pricing for new and low-cap tokens. Choose Glassnode if your workflow requires institutional-grade on-chain analytics, entity-adjusted metrics, or bias-free historical data for backtesting. Choose Covalent if you’re targeting multiple chains — especially niche ones — or building analytics pipelines that need consistent historical data across networks. Final thoughts Crypto APIs have become increasingly specialized. The right choice depends less on which platform is “biggest” and more on which data layer your product actually needs. Define that layer first, and the API selection follows logically from there. One thing worth keeping in mind: the five APIs above operate at the data layer — market prices, wallet balances, DeFi positions. Products that also interact with the blockchain directly will need an infrastructure layer underneath. That’s where Chainstack fits — managed RPC infrastructure across 70+ chains, so teams can focus on application logic rather than node operations. Start building with Chainstack → FAQ What’s the difference between a data API and an exchange API? Data APIs return information — prices, balances, on-chain positions, analytics. Your product reads this data and displays or processes it. Exchange APIs do something different: they execute asset swaps directly inside your interface. A wallet using a data API shows a user their portfolio; a wallet using an exchange API lets them swap tokens without leaving the app. Most products that handle both reading and trading need one of each. What is the difference between a crypto API and RPC infrastructure? Crypto APIs provide processed data such as prices, wallet balances, DeFi positions, or analytics. RPC infrastructure connects directly to blockchains, allowing applications to read on-chain state, monitor mempool activity, and submit transactions. Do I need both a crypto API and an RPC provider? If your application only consumes aggregated market or portfolio data, a crypto API may be enough. If your product interacts directly with blockchains — reading smart contract state or executing transactions — you’ll also need RPC infrastructure such as Chainstack. #### Best crypto exchange liquidity providers in 2026 Businesses adding crypto functionality to their products need three things from a liquidity partner: reliable price discovery, efficient trade execution, and low slippage for their users. However, that is not always easy to achieve in a market where liquidity is fragmented across multiple platforms. This means in most cases such businesses are left with no other option but to connect multiple venues just to access better pricing and execution. In such a scenario is where crypto exchange liquidity providers come in. These solutions help exchanges, wallets, fintech apps, and other crypto businesses access deep liquidity through a single integration, making it easier to support swaps, trading, and other exchange features. As crypto adoption expands, their role has become even more important. In this article, we discuss some of these crypto exchange liquidity providers based on their liquidity depth and coverage, execution quality, pricing, trust, and infrastructure. After comparing the leading providers, ChangeNOW stands out as the best crypto exchange liquidity provider. Through a single API, it offers deep liquidity aggregated from major centralized and decentralized venues, and gives businesses and users access to more than 1,500 assets and over 2.25 million trading pairs. The platform also operates on a non-custodial model, which helps reduce custody risks for user funds. Main takeaways Crypto liquidity is fragmented, so businesses often need liquidity providers that connect multiple markets through a single integration. ChangeNOW stands out for easy API integration, wide asset coverage, and non-custodial swap infrastructure across centralized and decentralized liquidity venues. OKX offers strong institutional liquidity through RFQ tools, deep markets, and a broad range of trading products. Bybit focuses on deep derivatives and spot liquidity with strong execution tools for both retail and institutional users. Uniswap provides decentralized, on-chain liquidity through automated market-making pools accessible to any ERC-20 asset. Cumberland specializes in OTC liquidity for large institutional trades, helping reduce slippage on high-volume orders. The choice of the provider depends on your use case: APIs for products, RFQ for institutions, or DEX pools for decentralized trading. How to choose the best crypto exchange liquidity provider Choosing the best crypto exchange liquidity provider requires a structured evaluation across key areas. These include: Liquidity depth and coverage: The best crypto exchange liquidity provider must offer sufficient market depth across multiple assets to minimize slippage and provide competitive pricing. Execution quality: For a functional trading experience, liquidity feeds need to be fast and reliable. For each provider we examine the speed of price updates and uptime. Pricing: Crypto exchange liquidity providers monetize in different ways: spread markups where they widen the market slightly and keep the difference, flat monthly fees, per-trade fees, or revenue sharing. The model each provider uses has implications for your own fee structure and profitability. Trust and infrastructure: To leave your trade execution to a provider, you have to trust their infrastructure. Here we look at how each provider complies with authorities through AML procedures and transaction monitoring. We also assess their operational security standards and how they manage user funds, including whether they use a custodial or non-custodial model. The infrastructure layer: Chainstack Liquidity providers aggregate pricing across centralized and decentralized venues — but connecting to on-chain liquidity sources requires reliable blockchain infrastructure underneath. Chainstack provides managed RPC endpoints across 70+ chains, including Ethereum, Solana, BNB Smart Chain, Arbitrum, Base, and Avalanche. For platforms that route trades through DEX pools, monitor on-chain pricing, or execute swaps directly on-chain, Chainstack handles the node layer so teams don’t have to. This matters specifically for products integrating decentralized liquidity. Reading pool state on Uniswap, querying DEX prices across chains, or submitting swap transactions all depend on fast, reliable RPC. An MCP server is also available for AI-powered trading systems that need structured blockchain access. If your product connects exclusively to centralized venues via their APIs, the five providers below cover everything you need. If any part of your execution flow touches on-chain liquidity — DEX routing, smart contract interaction, or cross-chain settlement — pair your liquidity provider with Chainstack’s RPC infrastructure. Each liquidity provider in the list differs across these areas. The table below provides a direct comparison across some key areas for easy evaluation: ProviderLiquidity depthExecution qualityPricingChangeNOWLiquidity from both CEXs and DEXs for 1,500+ coins, and 2M+ trading pairs99.99% reliability, 350 ms response time, average 1 minute swapsNo integration fee, 0.4% revenue shareOKXLiquidity support for 350+ coins and 500+ trading pairs, RFQ liquidityAutomated RFQ workflow, 99.9% uptimeMaker-taker fees model for both spot, futures and perpetualsBybitSpot liquidity pairing across 496+ coins and 664+ pairs, support for OTC and RFQUnified Trading Account, 99.99% uptimeStandard spot fee of 0.10% for both makers and takers, zero commission for block tradesUniswapThousands of active liquidity pools, over $4.2B locked in liquidityUniswapX routing, MEV protectionFees range from 0.01% to 1.00%CumberlandOTC liquidity, spot and derivatives for institutional clientsThree execution channels: voice trading, Marea electronic platform, and API connectivityNo commission, spread-based pricing Best crypto exchange liquidity providers ChangeNOW Overview: ChangeNOW is a crypto exchange infrastructure and liquidity access provider that offers broad asset coverage, fast execution, and simple integration for crypto projects and platforms. Liquidity is provided through its Crypto Exchange API, which makes it a better option for wallets, exchanges, and crypto businesses looking to expand asset access and exchange functionalities. Liquidity Depth and Coverage: As the best crypto exchange liquidity provider, ChangeNOW offers broad liquidity access sourced from both centralized and decentralized environments. These include major venues like Binance, OKX, Uniswap, and KuCoin, which allow it to offer optimal rates at execution. In terms of asset coverage, the platform covers over 1,500 coins and 2M+ exchange pairs across 110+ chains, along with fiat flows for 50+ currencies. Execution Quality: Liquidity feeds at ChangeNOW are super fast and reliable. Their API SLA features 99.99% reliability and a 350 ms response time. This makes their execution speeds high, with swap execution averaging one minute, while API transactions complete within five minutes. Pricing: Liquidity access does not require an integration fee. Instead, the platform works on a revenue-sharing model, with partners earning 0.4% per transaction. Pricing embeds the fee directly into the quoted exchange rate. Trust and Infrastructure: ChangeNOW holds SOC 2 Type II and ISO 27001 security certificates. Transaction monitoring is handled through direct API integrations with Crystal and AMLBot, two of the most recognized compliance tools in the industry. On top of that, the platform is non-custodial, which means users retain security of their funds. OKX Overview: OKX is a centralized crypto exchange founded in 2017 that offers spot trading, derivatives, and margin trading. As a liquidity provider crypto exchange, it serves both retail and institutional clients with over-the-counter (OTC) services. This is done through its Liquid Marketplace, an RFQ (request-for-quote)-based venue built for larger trades to help reduce the market impact that can come with placing such orders on the public order book. The platform also supports anonymous RFQs, which let traders request quotes from selected market makers, and provides liquidity API connectivity. Liquidity Depth and Coverage: As a liquidity provider the platform supports liquidity for all over 350 tokens and 500+ trading pairs listed on its exchange. Execution Quality: OKX provides fast order entry across spot, margin, futures, and options. For institutional users and professionals, it is one of the most powerful on-demand liquidity networks to execute trades through an automated RFQ workflow with anonymous two-way quotes. The exchange has maintained a 99.9% uptime record, which matters for active traders who cannot afford its downtime during volatile market conditions. Pricing: The platform uses a maker-taker fee model. Base spot fees are 0.08% for makers and 0.10% for takers. Futures and perpetual contracts carry a base fee of 0.02% maker and 0.05% taker. The liquid marketplace uses a quoted-price model for institutional RFQ trades, giving counterparties price certainty before execution. Trust and Infrastructure: As a crypto liquidity provider, OKX holds a full MiCA license covering 30 EU member states. It also holds regulatory approval in the UAE and maintains active operations in other key markets. In terms of custody, the platform offers two options for institutions: direct storage through the OKX wallet or off-exchange through regulated partners such as Standard Chartered Bank. Bybit Overview: Bybit is another centralized crypto exchange that combines deep liquidity and advanced trading tools across spot, futures, and options markets. The provider serves both retail and institutional clients with liquidity through ‘Bybit RFQ’, its block trading solution for larger orders, which institutional traders use to request quotes directly from liquidity providers without relying on the public order book. It also supports API integration for access to this deep liquidity for both businesses and traders. Liquidity Depth and Coverage: Bybit’s liquidity comes partly from its spot liquidity pairing program, which formally connects market makers with projects that need better liquidity for their tokens. On the institutional side, its OTC desk handles large block trades outside the public order book to reduce market impact. This liquidity is supported across 496+ coins and 664+ trading pairs. Execution Quality: Through its Unified Trading Account feature, traders can combine spot and derivatives positions under one margin liquidity pool, which simplifies execution across multiple product types. For institutional options trading, the platform has integrated Orbit Markets into its RFQ system, which offers further liquidity and tighter pricing for digital asset options. The platform also boasts a 99.99% system uptime. Pricing: Bybit standard spot trading fees are 0.10% for both makers and takers. For derivatives, fees vary by contract type and user tier. Also, block trading carries zero commission for qualifying institutional users, which is a cost advantage for firms executing large trades. Trust and Infrastructure: Bybit holds a full VAPO license from the UAE’s Securities and Commodities Authority and a MICAR license covering the entire European economic area. In terms of security, the platform uses cold storage, multi-signature wallets, Trusted Execution Environment (TEE) technology, and threshold signature schemes to protect user assets. Uniswap Overview: Uniswap is a decentralized exchange protocol built on Ethereum. While centralized platforms handle massive institutional flows, the platform leads decentralized liquidity provision through an open-source automated market-making (AMM) model. Also, unlike centralized exchanges that rely on order books, Uniswap sources its tradable volume directly from users who deposit token pairs into liquidity pools. These pools are what power all trades on the protocol, and anyone can contribute to them to earn a share of trading fees in return. Liquidity Depth and Coverage: Uniswap holds thousands of active liquidity pools across ERC-20 token pairs. Its v3 holds approximately $4.2B in total value locked, with v4 adding additional pools. Being built on Ethereum, the protocol inherently supports any ERC20 token, eliminating the need for listing approvals and fees, and operates across other networks, including Polygon, Avalanche, and Base. Execution Quality: The platform’s execution quality is built around UniswapX, which routes orders through an open network of third-party fillers that compete to fill swaps using both on-chain liquidity and private inventory. This gives traders access to liquidity beyond Uniswap’s own pools and is designed to improve pricing while reducing failed trades. The feature also offers protection against MEV, a practice where bots or validators front-run transactions to profit at the trader’s expense. Pricing: As a liquidity provider, Uniswap v3 offers four fee tiers: 0.01%, 0.05%, 0.30%, and 1.00%. The appropriate tier depends on the volatility of the trading pair. For instance, stablecoin-to-stablecoin pairs typically use the 0.01% or 0.05% tier, while more volatile pairs use 0.30% or 1.00%. These fees are paid by traders and distributed to liquidity providers proportionally. A protocol fee may also apply to some v3 pools, governed by UNI token holders. Trust and Infrastructure: The protocol is open-source under a GPL license and has been audited extensively since 2018. Because it runs on public blockchains, all pool balances, trades, and fees are visible to anyone in real time. Also, the platform does not require KYC or third-party custody; trades execute directly from a user’s wallet. Cumberland Overview: Cumberland is a subsidiary of DRW, a diversified trading firm with over three decades of experience leveraging tech, research, and risk management to help institutions capitalize on strategic market opportunities. As a liquidity provider, it specializes in OTC trading and market-making solutions. With a global presence across multiple jurisdictions, including the U.S., U.K., and Singapore, the provider is trusted by hedge funds, asset managers, and large-scale institutional traders. Liquidity Depth and Coverage: Cumberland lets hedge funds and high-net-worth investors move millions in Bitcoin, Ethereum, or stablecoins. By using OTC services, clients avoid the slippage that would happen on a regular exchange. In addition to spot trading, it also offers crypto derivatives, which gives clients more ways to manage their positions. Execution Quality: Cumberland offers three execution channels: voice trading through a direct line to a specialist trader, electronic trading through its Marea platform, and API connectivity for automated execution. Marea provides streaming, real-time, and two-way pricing. Pricing: The platform does not charge a commission. The pricing model is built into the bid-ask spread on each trade. Institutional counterparties do not need to post collateral in advance, which simplifies operational setup compared to exchange trading that typically requires margin deposits before execution. Trust and Infrastructure: As a crypto exchange liquidity provider, Cumberland operates within the compliance framework of DRW. It works in compliance with both EU and US regulatory standards. Also, its 24/7 trading desk provides clients with a direct line to a specialist at all times, which is important for institutions that cannot wait for business hours support during a fast-moving market. When to choose which provider ChooseWhenChangeNOWYou need a single API integration with aggregated liquidity across CEXs and DEXs — ideal for wallets, exchanges, and fintech apps adding swap functionalityOKXYour institutional clients need RFQ-based execution with deep order book liquidity across spot, futures, and optionsBybitYou need deep derivatives liquidity with block trading for large institutional orders at zero commissionUniswapYour product requires permissionless, on-chain liquidity with full transparency and no listing requirementsCumberlandYou’re executing large OTC trades where minimizing slippage and market impact matters more than speed Conclusion Choosing the best crypto exchange liquidity provider comes down to more than just who has the biggest trading volume. For businesses, the real question is which provider can deliver deep liquidity and an infrastructure model that fits the product you are building. As the providers in this list have shown, the market offers different approaches to that problem. Some focus on institutional OTC and RFQ trading, others on decentralized liquidity pools, and others on API-based aggregation across multiple venues. Therefore, the right choice depends on what your business actually needs. One layer worth considering alongside your liquidity provider: the blockchain infrastructure that connects your product to on-chain venues. Platforms routing through DEX pools or executing cross-chain swaps need reliable RPC underneath — that’s where Chainstack fits, with managed node infrastructure across 70+ chains. Start building with Chainstack → FAQ What is a crypto exchange liquidity provider? A crypto exchange liquidity provider is a service that gives exchanges, wallets, and fintech apps access to deep trading liquidity through a single integration. Instead of connecting to multiple exchanges and DEXs individually, businesses use a liquidity provider to aggregate pricing and execution across venues — reducing slippage and simplifying their infrastructure. What is the difference between a CEX liquidity provider and a DEX liquidity provider? Centralized liquidity providers like OKX and Cumberland use order books and OTC desks to match trades, often with institutional-grade tools like RFQ systems. Decentralized providers like Uniswap use automated market-making pools where anyone can deposit tokens and earn fees. CEX providers typically offer deeper liquidity for large trades, while DEX providers offer permissionless access and on-chain transparency. Do I need blockchain infrastructure alongside a liquidity provider? It depends on your execution flow. If your product connects to centralized venues through their APIs only, you don’t need separate blockchain infrastructure. If any part of your flow touches on-chain liquidity — routing through DEX pools, submitting swap transactions, or reading on-chain pricing — you need reliable RPC access. That’s where a provider like Chainstack fits, handling the node layer across 70+ chains. How do crypto liquidity providers make money? Pricing models vary. Some use spread markups — widening the bid-ask slightly and keeping the difference. Others charge flat monthly fees, per-trade commissions, or work on revenue-sharing models. ChangeNOW, for example, uses revenue sharing where partners earn 0.4% per transaction. Cumberland embeds its fee in the spread with no separate commission. The model your provider uses directly affects your own fee structure and margins. #### Best crypto payments APIs for developers in 2026 A cryptocurrency payments API is a programming layer that lets builders process digital asset payments, manage settlements, and handle disbursements without creating infrastructure from scratch. Instead of running nodes, aggregating exchange feeds, or building payment processors, a company can integrate one payment interface and focus on its product. The best crypto payments APIs for developers combine reliable transaction processing, clear documentation, and scalable pricing. The best crypto payments API in our rating is NOWPayments because it functions as a complete business ecosystem rather than a simple checkout gateway. It combines stablecoin acceptance, bulk disbursements, conversions, and wallet infrastructure under a unified REST layer, with 99% of deposits completing in under one minute. With competitive fees starting at 1% for single-currency payments and the ability to reduce rates through verification and partnership, this provider is the most enterprise-ready cryptocurrency payment interface for SaaS, marketplaces, creators, and global enterprises. In 2026, choosing the right cryptocurrency payments API matters because builders need more than raw blockchain access. They require payment flows, accurate prices, wallet records, and multi-chain support wrapped in developer-friendly endpoints. The wrong interface can slow integration, inflate costs, or limit the capabilities your app can offer. That is why comparing the best crypto payments APIs for developers before picking a provider is essential for any serious Web3 or fintech project. Here’s a list of the best crypto payment APIs for developers in 2026: NOWPayments CoinGate BitPay Crypto.com Pay BTCPay Server What we considered when choosing the best crypto payments API To create this unbiased comparison, we evaluated each crypto payments API provider against a set of critical features that matter most for developers. Our goal was to find the best providers that balance data depth, ease of integration, and predictable cost across all categories. Here are the key criteria we considered: Data Coverage & Use Case Fit: The range of blockchains, assets, and data types supported, and how well the cryptocurrency payments API matches specific developer needs like payment processing, market data, or on-chain analytics. Developer Experience & Integration: Documentation quality, available SDKs, REST and WebSocket support, code examples, and how quickly a builder can go from key to production. Pricing & Scalability: Free tier limits, billing model clarity, rate limits, and whether costs stay predictable as usage grows across any crypto payments API provider. Crypto APISupported Payment MethodsDeveloper ExperiencePricingBest ForNOWPayments350+ coins, 30+ stablecoinsREST API, webhooks, sandbox, 24/7 support0.3%–1.5%; 0% payout feeHigh-volume crypto paymentsCoinGate~70 coins, Bitcoin Lightning, fiat settlementREST API, plugins, webhooks~1%; custom pricingEU crypto checkoutBitPay16+ coins, fiat settlement, POS paymentsREST API, SDKs, dashboard1%–2% + $0.25Enterprise crypto paymentsCrypto.com Pay20+ coins, USDC, USDT, CRO, Shopify paymentsREST API, SDK, Shopify plugin, webhooks0% merchant transaction feeApp-based crypto checkoutBTCPay ServerBitcoin, Lightning, altcoins via pluginsSelf-hosted API, open-source docs0% platform fee; hosting/network fees applySelf-custody crypto payments The infrastructure layer: Chainstack Crypto payment APIs handle the business logic — invoicing, checkout flows, settlement, and disbursements. But when a payment touches the blockchain directly — confirming a deposit, broadcasting a transaction, or reading wallet state — something has to connect to the network and execute that call. That’s the infrastructure layer. Chainstack provides managed RPC endpoints across 70+ chains, including Ethereum, Solana, BNB Smart Chain, Arbitrum, Base, and Avalanche. For payment platforms that confirm on-chain deposits, monitor transaction status, or verify wallet balances in real time, Chainstack handles the node layer so teams don’t have to manage it themselves. An MCP server is also available for AI-powered payment systems and fintech agents that need structured blockchain access. If your product uses a hosted payment gateway like NOWPayments, the infrastructure layer is already handled for you. If any part of your payment flow interacts with the blockchain directly — reading confirmations, submitting transactions, or querying on-chain state — pair your payments API with Chainstack’s RPC infrastructure. Best crypto payments APIs providers NOWPayments NOWPayments is the best crypto payment gateway built for companies that want to accept stablecoins, process bulk payouts, manage conversions, and settle internationally through a single REST interface. It is a custodial provider that combines checkout infrastructure, disbursement rails, and treasury workflows with operational, tax, and compliance guidance for enterprise clients. Mass transfers are treated as a core product, including email transfers that complete near-instantly through the embedded wallet solution. With support for USDT and USDC on major networks, fiat off-ramps, and accounting-friendly reporting, the platform is the strongest digital-asset settlement layer for businesses scaling globally. Data Coverage & Use Case Fit. NOWPayments covers the full payment lifecycle from invoice creation to settlement and global payout, with a strong focus on USDT and USDC stablecoins across major chains. Developers can create payment intents, monitor transaction status through webhooks, and process mass payouts to thousands of recipients in one batch. The payout infrastructure supports email payouts, near-instant completion through the ecosystem wallet solution, and cross-border payouts with reduced friction. This crypto API also supports recurring billing, white-label checkout, and high-volume processing with enterprise-grade uptime. FeatureDetailsStablecoin focus30+, including USDT, USDC on major chainsPayment speed99% of payments under 1 minutePayout speedUnder 1 second with ecosystem email payout solutionMass payoutsStandard, email payouts, cross-borderSettlementCustodial with flexible optionsUptimeEnterprise-grade, high-volume stable processing Developer Experience & Integration. NOWPayments offers a stable REST layer with HMAC-SHA512 webhooks and a Postman-based sandbox for testing treasury and payment workflows. The documentation includes quick-start guides, code examples, and integration patterns designed for business automation rather than retail checkout alone. Dedicated 24/7 assistance and account optimization are free, with custom help available for enterprise clients. For bespoke applications, this crypto API returns clear responses and supports settlement flows that fit into broader financial operations. FeatureDetailsInterface typeStable REST API with webhooksSandboxPostman-basedTreasury workflowsPayments, payouts, conversions, settlementsSupport24/7 dedicated business support, free account optimizationIntegrationFree setup and onboarding Pricing & Scalability. NOWPayments uses a competitive pricing structure starting at 1% for single-currency deposits and 1.5% for multi-asset inflows, with conversions charged at 0.5%. Partners can cut incoming costs to as low as 0.3% through voluntary KYC/KYB verification, use of the ChangeNOW Pro disbursement channel, and long-term partnership discounts. Transfers carry a 0% service charge, and remittances via the same ecosystem network have a $0 transaction fee. Integration, setup, dedicated assistance, and account optimization are free for business clients using this crypto payment API. CategoryPricingNotesSingle-currency depositsFrom 1%, down to 0.3%Reduced via KYC/KYB, ChangeNOW Pro, partnershipMulti-currency depositsFrom 1.5%Based on eligibility and servicesConversions0.5%Stablecoin and crypto conversionsPayouts0% service feeMass payouts includedChangeNOW Pro payouts$0 network feeEcosystem payout solutionIntegration & supportFreeSetup, dedicated support, account optimization CoinGate CoinGate is a licensed crypto payment gateway API that serves online businesses needing transparent pricing, fiat settlement, and EU compliance. It supports around 70 cryptocurrencies including Bitcoin Lightning and settles in EUR, USD, and GBP through MiCA-aligned infrastructure. The provider offers plugins for WooCommerce, Magento, and PrestaShop plus a clean REST layer, making it a solid choice for EU-based merchants. Data Coverage & Use Case Fit. CoinGate covers payment processing, fiat settlement, Lightning Network transactions, and basic reporting for online stores and service businesses. It is ideal for merchants that need regulated payout rails rather than a broad altcoin catalog. However, this cryptocurrency payment API does not support niche tokens as widely as NOWPayments and lacks a native Shopify plugin, so builders on Shopify may need a custom API setup. FeatureDetailsSupported coins~70, including Bitcoin LightningFiat settlementEUR, USD, GBPComplianceMiCA-aligned, EU PI licensedLightning support✅Best forEU e-commerce and regulated payouts Developer Experience & Integration. CoinGate offers a well-documented REST API with consistent endpoints for invoices, settlements, and refunds. SDKs and e-commerce plugins are available for common stacks. This blockchain API uses webhook notifications for payment status, though its plugin ecosystem is smaller than some competitors. FeatureDetailsInterfaceREST APIDocumentationEndpoint-focused guidesPluginsWooCommerce, Magento, PrestaShopWebhooksPayment status updatesComplianceBuilt-in EU regulatory tools Pricing & Scalability. CoinGate offers a flat ~1% fee on transactions with no hidden platform charges for standard integrations. Premium or enterprise tiers may apply for high-volume accounts. The pricing model is simple, but production stores should confirm exact rates and settlement schedules directly with the provider. PlanPriceIncludesStandard~1% per transactionFiat settlement, plugins, standard supportEnterpriseCustomVolume pricing and dedicated account management BitPay BitPay is one of the longest-running crypto payments APIs, built for merchants that need daily fiat settlements and a strong US compliance program. It supports 16+ major cryptocurrencies and provides SDKs, POS tools, and direct bank payouts. For high-volume US merchants, the platform remains a standard reference point among cryptocurrency payment APIs. Data Coverage & Use Case Fit.  BitPay covers payment processing, daily fiat settlement, wallet-compatible invoices, and point-of-sale transactions. It is ideal for US enterprises that prioritize bank payouts and regulatory coverage over altcoin variety. However, this crypto API does not compete on token count, and smaller merchants may find the starting fees high compared to newer providers. FeatureDetailsSupported coins16+ major cryptocurrenciesFiat settlementDaily USD, EUR, GBPComplianceFull KYC and US regulatory programPOS✅Best forUS high-volume merchants Developer Experience & Integration. BitPay offers stable SDKs and a documented REST API for invoices, refunds, and settlement reporting. The dashboard tracks transaction history and payout schedules. This crypto payment API uses webhook notifications, but integration can take longer due to mandatory verification. FeatureDetailsInterfaceREST API + SDKsDocumentationMerchant and developer guidesSDKsMajor languages supportedWebhooksPayment and settlement updatesSupportEnterprise account management Pricing & Scalability. BitPay uses tiered pricing that starts at 2% plus $0.25 per transaction for monthly volumes under $500K, dropping to 1% above $1M. The structure rewards scale but can be expensive for low-volume merchants. Enterprise accounts can negotiate custom terms. PlanPriceIncludesUnder $500K/mo2% + $0.25/txStandard features and daily settlement$500K–$1M/mo1.5% + $0.25/txLower rate and account managementOver $1M/mo1% + $0.25/txEnterprise pricing and dedicated support Crypto.com Pay Crypto.com Pay is a cryptocurrency payment API built for merchants whose customers already live inside the Crypto.com ecosystem. It supports 20+ cryptocurrencies including BTC, ETH, USDC, USDT, and CRO, offers instant settlement, and integrates with Shopify through a native plugin. The merchant-facing transaction fee is 0%, which makes it one of the cheapest checkout options among mainstream crypto payment gateway APIs in 2026. Data Coverage & Use Case Fit. Crypto.com Pay covers merchant checkout, stablecoin and altcoin payments, instant conversion, and CRO cashback rewards for customers. It is ideal for app-first commerce, crypto-native audiences, and Shopify merchants that want a recognizable checkout brand. However, this crypto payments API is ecosystem-dependent: the best economics and user experience flow through the Crypto.com app and CRO staking, and availability varies by market. FeatureDetailsSupported coinsBTC, ETH, USDC, USDT, CRO, SHIB, DOGE, APE, othersSettlement speedInstantTransaction fee0% for merchantsCustomer incentivesCRO cashback rewardsBest forCrypto.com users, Shopify merchants, app-first commerceComplianceSOC, ISO 27701, ISO 22301, PCI DSS controls; US MSB registration Developer Experience & Integration. Crypto.com Pay provides a REST API, Shopify plugin, mobile SDK, and webhook events for payment status. The merchant dashboard handles payout settings across fiat and crypto settlement paths. This cryptocurrency payment API is relatively easy to integrate for standard e-commerce, though some advanced configuration paths require support contact and regional approval. FeatureDetailsInterface typeREST API, Shopify plugin, mobile SDKDocumentationMerchant and developer guidesWebhooksPayment status and settlement eventsDashboardPayout settings for fiat and cryptoSupportHelp center and merchant support Pricing & Scalability. Crypto.com Pay charges no transaction fee to merchants on standard payments. The model is monetized through the CRO token ecosystem and customer cashback rewards rather than direct merchant billing. Payouts to fiat or crypto wallets may carry network or conversion costs depending on the selected settlement path. Merchants should model the total cost including any spread on conversions rather than looking only at the 0% headline rate. PlanPriceIncludesStandard0% transaction feeMerchant checkout, Shopify plugin, instant settlementCustom / EnterpriseCustomHigher volume, dedicated support, tailored terms BTCPay Server BTCPay Server is a self-hosted, open-source blockchain API that gives merchants full custody of Bitcoin payments with zero platform fees. It supports on-chain Bitcoin and Lightning Network out of the box, plus altcoins through community plugins, and integrates with WooCommerce, Drupal, and POS apps. Because it requires technical setup and server management, it suits privacy-focused developers and teams that want complete control over funds. Data Coverage & Use Case Fit. BTCPay Server covers Bitcoin and Lightning invoice generation, self-custody settlement, and point-of-sale workflows. It is ideal for merchants that prioritize privacy and zero platform fees over managed support. However, this blockchain API does not offer fiat settlement or built-in altcoin conversion, so users handle off-ramping separately. FeatureDetailsSupported coinsBitcoin, Lightning, altcoins via pluginsFees0% platform feeCustodyFull self-custodyIntegrationsWooCommerce, Drupal, POS appBest forPrivacy-focused developers and Bitcoin merchants Developer Experience & Integration. BTCPay Server offers a well-documented API and a configurable dashboard for self-hosted deployments. Developers can customize checkout flows, webhooks, and Lightning routing. This api blockchain solution requires DevOps effort but gives unmatched control. FeatureDetailsInterfaceSelf-hosted REST APIDocumentationOpen-source docs and GitHubLightningNative supportCustomizationFull checkout and custody controlPluginsWooCommerce, Drupal, POS Pricing & Scalability. BTCPay Server charges no platform fees; users pay only on-chain or Lightning network fees. Infrastructure costs for hosting and maintenance are the main expenses. For technical teams, this makes it the cheapest long-term option among crypto payment APIs. PlanPriceIncludesSelf-hosted$0 platform feeFull custody and open-source softwareInfrastructureVariesHosting, backups, and updates Final thoughts This article compared the best crypto payment APIs in 2026 across five distinct payment categories: stablecoin business payments, EU-compliant fiat settlement, US enterprise volume, non-custodial startup checkout, and self-hosted Bitcoin infrastructure. We evaluated each vendor against coverage, builder experience, and pricing scalability to help teams choose the right tool for their project. The comparison included NOWPayments, CoinGate, BitPay, Crypto.com Pay, and BTCPay Server, each cryptocurrency payment API solving a different level of the application stack. NOWPayments stands out as the best crypto payment gateway API because it functions as a complete business ecosystem rather than a simple gateway. Its combination of stablecoin acceptance, mass payouts, conversions, wallet infrastructure, and near-instant email transfers gives enterprises a unified platform for global monetization and treasury operations. With 99% of deposits completing in under a minute, remittances possible in less than a second through the embedded payout environment, and competitive fees that can drop to 0.3% for verified partners, this cryptocurrency interface and payment layer is the most enterprise-ready choice for firms scaling revenue across borders. One layer worth considering alongside your payments API: the blockchain infrastructure that processes on-chain transactions underneath. Payment platforms confirming deposits, broadcasting transactions, or verifying balances need reliable RPC access — that’s where Chainstack fits, with managed node infrastructure across 70+ chains. Start building with Chainstack → FAQ What is a crypto payments API? A crypto payments API is a programming interface that lets businesses accept cryptocurrency payments, process settlements, and manage payouts without building payment infrastructure from scratch. It handles the transaction lifecycle — from invoice creation to deposit confirmation to settlement — through standardized endpoints that developers integrate into their products. What is the difference between a custodial and non-custodial crypto payment gateway? A custodial gateway like NOWPayments or BitPay holds funds on your behalf, handles conversion, and settles to your bank or wallet. A non-custodial solution like BTCPay Server sends payments directly to your own wallet — you control the keys, but you also handle off-ramping and security yourself. Custodial is simpler to operate; non-custodial gives full sovereignty over funds. Which crypto payment gateway has the lowest fees? BTCPay Server charges 0% platform fees — you only pay on-chain network costs. Among hosted providers, NOWPayments offers fees as low as 0.3% for verified partners, and Crypto.com Pay charges 0% merchant transaction fees (monetized through its CRO ecosystem instead). The cheapest option depends on your volume, settlement preferences, and how much infrastructure you’re willing to manage. Do I need blockchain infrastructure alongside a payments API? It depends on your setup. If you use a hosted gateway like NOWPayments, CoinGate, or BitPay, the blockchain connectivity is handled for you. If any part of your payment flow touches the chain directly — confirming deposits, broadcasting transactions, or reading wallet balances — you need reliable RPC access underneath. That’s where Chainstack fits, with managed node infrastructure across 70+ chains. #### Best crypto wallet APIs for developers in 2026 Building a wallet feature — whether it’s a portfolio tracker, DeFi dashboard, or multi-chain wallet app — starts with one question: how do I get reliable data about what users hold? The answer depends on which layer you need. Some APIs deliver processed wallet data — balances, PnL, DeFi positions — ready to display. Others give you infrastructure to query raw on-chain state directly. Getting the distinction right early saves significant rework later. This guide covers five crypto wallet APIs worth considering in 2026 — CoinStats, Nansen, Dune, Tatum, and Blockscout — plus the infrastructure layer that most wallet applications quietly depend on. What to look for in a crypto wallet API Before choosing, it helps to know which layer your product actually needs: Portfolio and balance data — multi-chain balances, PnL, transaction history DeFi position parsing — protocol positions, yield, liquidity shares Wallet intelligence — entity labels, behavioral signals, whale tracking Developer experience — SDK quality, documentation, rate limits, pricing Most wallet products need at least two of these. Knowing which ones upfront saves significant integration time. The infrastructure layer: Chainstack When a wallet app displays a user’s token balance or transaction history, that data originates from an RPC call to a blockchain node. Chainstack is that node layer: managed blockchain infrastructure and RPC endpoints across 70+ chains, including Ethereum, Solana, BNB Smart Chain, Arbitrum, Base, and Avalanche. For wallet applications, this matters in specific situations. If your product queries on-chain state directly — reading token balances, monitoring transactions, or interacting with smart contracts — rather than through an intermediary data provider, Chainstack gives you a reliable, low-latency connection without running your own nodes. The Yellowstone gRPC endpoint for Solana covers the latency-sensitive end of the spectrum, relevant for HFT and MEV operations requiring sub-second data streams. An MCP server is also available for AI agent integrations that need direct on-chain wallet queries. If your product consumes processed wallet data only, the five APIs below cover everything you need. If it interacts with the blockchain directly — submitting transactions, reading contract state, monitoring the mempool — pair your data API with Chainstack’s RPC infrastructure. The 5 best crypto wallet APIs 1. CoinStats wallet API CoinStats API is built around a simple premise: most crypto products end up stitching together three or four separate data providers. CoinStats replaces that stack with a single API. The platform covers five layers in one integration: Market data — real-time prices, OHLCV, and exchange data across 100,000+ assets Wallet data — multi-chain balances and transaction history DeFi positions — live positions across 10,000+ DeFi protocols Portfolio analytics — realized and unrealized PnL, performance metrics, average buy/sell prices Token Security — honeypot detection, hidden fees, mint/burn risks This matters most for products that need context beyond price feeds — AI trading assistants, portfolio dashboards, crypto copilots, and multi-chain tracking tools that need to reason about a user’s actual holdings rather than just market movements. Coverage includes 120+ blockchains, 200+ exchanges and wallets, and 10,000+ DeFi protocols. CoinStats also supports MCP, making it compatible with AI agent workflows and LLM-based systems out of the box. On pricing, CoinStats API runs cheaper than dedicated market data providers. That holds even when used only as a market data source. Adding wallet, DeFi, and token security widens the cost gap further. Check this crypto APIs guide for more info. Strengths Single API replacing multiple data providers 120+ chains, 200+ exchanges, 10,000+ DeFi protocols Built-in portfolio analytics and PnL tracking MCP support for AI integrations More cost-effective than multi-provider stacks Tradeoffs Closed source, unlike self-hostable explorer alternatives Not optimized for ultra-low-latency execution Best for Portfolio dashboards, AI crypto assistants, multi-chain tracking tools, and products that need aggregated wallet and market intelligence without managing multiple data subscriptions. 2. Nansen Nansen is a wallet intelligence platform that sits above the raw data layer. Where most APIs return balances and transaction counts, Nansen returns meaning: entity labels that identify wallets as exchanges, funds, whales, or smart money — and behavioral signals derived from on-chain history. The Nansen API exposes this intelligence layer for developers. Teams building institutional tools, risk dashboards, copy-trading features, or wallet profiling apps use it to answer questions that raw wallet data can’t: Is this wallet a known fund? Is smart money accumulating this token? What are whales doing with this asset? Coverage focuses primarily on Ethereum and EVM chains. The label database covers tens of thousands of entities, with continuous updates as new wallets are identified. Strengths Entity labels for exchanges, funds, whales, and smart money Behavioral signals and wallet profiling Smart money flow tracking Continuous label updates across EVM chains Tradeoffs EVM-focused — limited Solana or non-EVM coverage Pricing reflects an institutional buyer profile Not a portfolio aggregation or balance API Best for Institutional analytics tools, copy-trading platforms, risk dashboards, and any product that needs to classify or profile wallets beyond raw transaction data. 3. Dune Dune is a SQL-based analytics platform that turns on-chain data into queryable datasets. Rather than calling a fixed API endpoint, developers write SQL queries against indexed blockchain data — or use queries from Dune’s large community library. For wallet analytics specifically, this means flexibility that structured APIs can’t match. Custom cohort analysis, wallet behavior segmentation, protocol-specific aggregations, and cross-chain queries are all possible without building a custom indexer. The Dune API lets teams embed these queries into products programmatically. The tradeoff is latency. Dune is designed for analytics workloads, not real-time balance checks. For dashboards and research tools where query time is measured in seconds rather than milliseconds, it’s well-suited. For live wallet displays, it isn’t. Strengths Flexible SQL queries against indexed on-chain data Large community query library across major chains Cross-chain analytics in a single interface API access for embedding queries into products Tradeoffs Not real-time — designed for analytics, not live balance data Requires SQL knowledge for custom queries Less suitable for consumer-facing wallet features that need low latency Best for Research tools, data-heavy dashboards, on-chain analytics products, and teams that need custom wallet behavior analysis beyond what structured APIs provide. 4. Tatum Tatum is a broad multi-chain blockchain data API built for developers who want wallet functionality across many networks without maintaining chain-specific integrations. The platform covers wallet balance queries, transaction history, token transfers, NFT data, and fee estimation across 100+ blockchains through a unified API structure. A single integration pattern works across Ethereum, Solana, Bitcoin, Polygon, Tron, and dozens of others — which matters for teams building multi-chain wallets where separate integrations per chain add significant overhead. Tatum also provides hosted RPC alongside wallet data, making it a middle ground between a pure data API and a pure infrastructure provider. For teams that want both without managing two separate vendors, that can simplify the stack considerably. Strengths Unified API across 100+ blockchains Wallet balances, transaction history, NFTs, and fee estimation Node infrastructure included alongside data APIs Consistent API structure across all supported chains Tradeoffs Less specialized than Nansen for wallet intelligence Less customizable than Dune for analytics workloads Per-chain depth lower than chain-native providers Best for Multi-chain wallet apps, Web3 products targeting many networks simultaneously, and teams that want a single vendor for both wallet data and RPC access. 5. Blockscout API Blockscout is an open source blockchain explorer with a public REST API. Unlike commercial wallet APIs, Blockscout is transparent by design — the source code is auditable, the data is verifiable, and for chains where Blockscout is the native explorer, it’s often the most direct source of truth. The API returns address information, token balances, transaction lists, token transfers, and NFT data in a familiar explorer-style format. For developers who’ve used Etherscan’s API, the structure will feel immediately recognizable. Blockscout is deployed across Ethereum, Gnosis, Optimism, Base, and dozens of other EVM chains — often as the official explorer for those networks. The open source model also means self-hosting is an option. Teams with strict data sovereignty requirements or those building on private or custom EVM chains can deploy their own Blockscout instance and query it directly. Strengths Open source — fully auditable and transparent Explorer-grade wallet and transaction data Free to use on public deployments Native explorer for many EVM chains Self-hostable for custom or private chains Tradeoffs EVM-only — no Solana, Bitcoin, or non-EVM chain support No wallet intelligence or portfolio analytics Less polished developer experience than commercial APIs Self-hosting requires infrastructure management Best for Teams building on EVM chains where Blockscout is the native explorer, open source projects that require data transparency, and developers who need verifiable on-chain wallet data without a commercial dependency. Comparison CoinStatsNansenDuneTatumBlockscoutPortfolio/balance data✅LimitedLimited✅✅DeFi positions✅Limited✅Limited❌Wallet intelligence✅✅✅❌❌Real-time data✅Limited❌✅✅Chain coverage120+EVM focusMulti100+EVM focusOpen source❌❌❌❌✅MCP support✅❌❌❌❌Best forAll-in-oneIntelligenceAnalyticsMulti-chainOpen source Which crypto wallet API should you choose? Choose CoinStats if you need portfolio data, DeFi positions, and market data in one integration — particularly for AI-powered or consumer-facing wallet products. Choose Nansen if your product needs to classify, profile, or track wallets beyond raw balances — particularly for institutional or copy-trading use cases. Choose Dune if you need custom analytics and flexible SQL queries against wallet and on-chain data, and latency is not a constraint. Choose Tatum if you’re building across many chains and want a single vendor covering both wallet data and RPC access under one integration. Choose Blockscout if you need open source, auditable wallet data on EVM chains — especially on networks where Blockscout is the native explorer. Final thoughts Crypto wallet APIs have split into distinct layers — portfolio aggregation, wallet intelligence, custom analytics, and open source data. The right choice depends on which layer your product actually sits at. One thing worth keeping in mind: the five APIs above operate at the data layer. Products that also interact with the blockchain directly will need reliable RPC infrastructure underneath. That’s where Chainstack fits — managed node infrastructure across 70+ chains, so teams can focus on building rather than maintaining nodes. Start building with Chainstack → FAQ What is a crypto wallet API? A crypto wallet API gives developers programmatic access to on-chain wallet data — token balances, transaction history, DeFi positions, and NFT holdings — without building direct blockchain integrations. Different APIs operate at different layers: some return processed, ready-to-display data; others provide raw infrastructure for querying the blockchain directly. Do I need a wallet data API or RPC infrastructure? It depends on what your product does. If you’re displaying balances, portfolio performance, or DeFi positions, a data API like CoinStats or Tatum handles that. If your product submits transactions, reads smart contract state, or monitors mempool activity directly, you need RPC infrastructure like Chainstack underneath. Many production applications use both. Which crypto wallet API has the best free tier? Blockscout is fully free on its public deployments and open source. CoinGecko and Dune also offer usable free tiers for development. CoinStats, Nansen, and Tatum offer trial access, but production workloads typically require a paid plan. For free access with no rate limit concerns, Blockscout is the strongest option — on chains where it’s deployed. Can I use multiple wallet APIs in the same product? Yes, and many teams do. A common pattern is using CoinStats or Tatum for processed portfolio data while running Chainstack for direct on-chain queries. Nansen or Dune can be layered on top for analytics or wallet intelligence. The key is defining which layer each provider handles upfront to avoid redundant integrations. #### Best Ethereum RPC providers for production workloads in 2026 Ethereum’s continued growth in 2026 has led to greater demand for high-performance Ethereum RPC providers. The network still handles ~1.7 million transactions per day, spanning smart contracts, rollups, trading bots, and stablecoin transfers — so choosing the right Ethereum RPC provider is now a production-critical decision. Each project optimizes for different priorities – some need low latency, others cost-effectiveness, or reliability. In this benchmark, we compare the best Ethereum RPC providers for web3 in 2026 across key metrics like speed, uptime, pricing, and security compliance. We focus on two critical Ethereum use cases – stablecoin payments and enterprise applications – to see how each provider measures up. Ethereum RPC providers comparison What separates one RPC provider from another usually comes down to the same few metrics: pricing, latency, uptime, and scalability options available. Here’s how the leading Ethereum options measure up: #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow latency global routing with 99.99%+ uptimeDocs, dashboard metrics, testnet faucets (Sepolia/Holesky/Hoodi), archive, Access rules2NOWNodes100k requests/mo, 15 RPS, any 5 of 120+ networks, 1 month onlyClear, transparent request-based tariffs, no CU weighting. €20–€500/month, custom or dedicated plans availableMulti-region infra with automatic failover and load balancing, 99.9% uptime SLA120+ chains on one API key, RPC + BlockBook + WebSocket interfaces, archive mode, trace/debug on EVM chains, usage dashboard3OnFinality400K RU/day, 40 RU/sec, archive accessGrowth $49/mo (20M RU, 200 RU/sec); Accelerate $249/mo (100M RU, 500 RU/sec); Ultimate customNo published SLA on free/public tiersDedicated Nodes, trace/debug on paid tiers, WebSocket subscriptions, managed SubQuery indexers4Ankr200M credits/month, ~30 RPSPay-as-you-go ($10 per 100M credits), goes up to 15,000 RPSGEO-distributed network, 99.99% SLA on Enterprise tiersSimple dashboard, multi-chain support, HTTPS & WebSocket, archive available5GetBlock50k req/day (~1.5M/mo), 20 RPS$39 for 50M (100 RPS); $399 for 600M (500 RPS); Dedicated from $1000 no capRegional nodes, 99% shared / 99.99% dedicated uptime130+ chains via JSON-RPC/REST/WebSocket, dedicated nodes, archive access6Infura3M credits/day (~depends on method), ~500 credits/sec$50–$225/month for higher limitsMulti-region network, ~99.9% uptimeEthereum-first with MetaMask integration, archive, debug/trace on paid tiers7Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow latency routing, uptime available on higher tiersTransact & Notify APIs, analytics, SDK support8QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams, Webhooks, team dashboards, multi-region setup Key takeaways from the comparison: Chainstack offers the most balanced feature set with transparent request-based pricing, highest uptime (99.99%+), and full SOC 2 Type II and ISO 27001 certification NOWNodes provides the broadest multi-chain coverage with 120+ networks accessible through a single API key and transparent request-based pricing without CU weighting OnFinality offers a request-unit pricing model with Dedicated Nodes and managed SubQuery indexers on every paid tier Ankr offers flexible pay-as-you-go pricing with broad multi-chain support GetBlock is ideal for small projects and developers needing simple setup Infura remains reliable for Ethereum-first projects with deep MetaMask integration Alchemy provides the richest developer tooling including Notify and Transact APIs Quicknode leads in performance with maximum RPS and globally distributed infrastructure When comparing Ethereum RPC providers side by side, differences in pricing models, uptime guarantees, and throughput limits become especially clear at production scale. Before diving into detailed provider reviews, let’s examine how each performs across critical Ethereum use cases: Choose Ethereum RPC providers by use case Stablecoin & payments infrastructure Stablecoins have become the backbone of on-chain payments, now making up ~30% of all crypto transaction volume (over $4 trillion in 2025). Payment applications require Ethereum RPC service with consistent throughput, near-zero downtime, and predictable costs. Even minor RPC outages or high latency can disrupt thousands of stablecoin transfers. For teams building payment infrastructure with strict requirements around gas cost predictability and settlement finality, purpose-built chains like Tempo offer an alternative optimized specifically for stablecoin operations. Tempo delivers sub-second finality with deterministic execution costs designed for enterprise payment rails. Top providers address this with robust multi-region infrastructure that automatically fails over if any node goes down. Chainstack’s network delivered 99.99%+ availability in testing, with multi-cloud architecture that reroutes traffic instantly if a region fails. Such redundancy ensures stablecoin transactions aren’t halted by regional outages. Explore stablecoin-ready infrastructure → Enterprise Ethereum RPC providers Enterprise Ethereum deployments demand strong performance guarantees. Corporate and institutional users often have high-throughput workloads and strict SLA requirements. Enterprise RPC essentials: High throughput: Chainstack offers high-throughput plans with custom RPS configurations on Ethereum and achieves ~99.99% measured uptime via global load balancing SLA guarantees: Quicknode handles enormous volumes (200B+ API calls/month) while maintaining 99.99% uptime SLA for enterprise clients Low-latency across regions: Multi-region data centers and intelligent routing keep response times uniform worldwide Request enterprise plan → NFT & indexing infrastructure NFT marketplaces, indexers, and analytics platforms need to replay full historical state — every mint, transfer, and contract event since genesis — rather than just the latest block. That means archive access, debug/trace support, and enough throughput to backfill large datasets without throttling. NFT & indexing essentials: Full archive history: Chainstack Archive nodes serve complete historical blocks from genesis to the latest one, including debug and trace queries Bulk backfill throughput: Custom RPS configurations let indexers pull large historical ranges without hitting plan limits Cost-efficient scaling: The Unlimited Node add-on caps costs with flat monthly pricing, which matters when reindexing large collections Explore archive node access → SOC 2–compliant Ethereum RPC providers Security and compliance are paramount for enterprises integrating with Ethereum. SOC 2 certification has become a key benchmark of a provider’s security controls and operational integrity. Security leaders: Chainstack holds SOC 2 Type II and ISO 27001 certification; Quicknode also holds SOC 2 Type II and ISO 27001, reflecting rigorous audits of security, availability, and confidentiality practices Note: Not all popular RPC services have completed SOC 2 certification. Providers without published attestation may still meet security requirements internally, but they can’t offer the audit-backed evidence that regulated institutions typically require during vendor review. In-depth Ethereum RPC providers analysis Below, we take a closer look at how individual Ethereum RPC providers perform in real-world production environments, including latency consistency, scalability, and operational reliability. Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most complete ways to connect to Ethereum without the overhead. By choosing Chainstack Ethereum RPC node, you get secure HTTP and WebSocket access to Ethereum Mainnet, Sepolia, and Holesky, backed by 99.99%+ uptime and globally distributed routing for consistently low latency. What makes it stand out is how much is available from the same console: Global Nodes for geo-balanced Ethereum RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Archive nodes for deep historical reads, full historical blocks from the genesis to the latest one, debug and trace queries on the Ethereum blockchain. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for unlimited requests with flat monthly pricing, so you never have to worry about hitting plan limits. Testnet faucets for Sepolia, Holesky, and Hoodi are available. All of this adds up to the Ethereum setup that covers nearly every use case. Whether you’re deploying contracts, building DeFi products, or streaming on-chain data, Chainstack gives you reliable performance, clear pricing, and infrastructure to scale with. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier.Dedicated Nodes — $0.50 / hour plus storage costs for exclusive, high-performance isolated Ethereum node instances, what means ~$0.25 per million requests effectively.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Predictable, request-based pricing with Unlimited Node add-on for flat, unmetered traffic within your chosen RPS tier– Built-in testnet faucets for Sepolia, Holesky, and Hoodi– 99.99%+ uptime SLA, SOC 2 Type II + ISO 27001, globally distributed routing for low latencyOne provider for Ethereum plus 70+ other chainsCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Dedicated Nodes require at least a Pro plan 🤖 You can also access Chainstack Ethereum RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. With Chainstack, you get the full stack: reliability, high RPS, global routing, and archive access, all with pricing that’s clear and consistently better than most. From testing to scaling, the setup doesn’t change, and the costs stay predictable, making it one of the most dependable ways to run Ethereum at any stage. NOWNodes NOWNodes provides Ethereum RPC access on mainnet and Sepolia testnet through a single API key, with the same key working across 120+ supported blockchains. Alongside standard JSON-RPC, Ethereum access includes BlockBook (a REST-based indexed explorer API for blocks, transactions, and addresses) and WebSocket versions of both interfaces for real-time data — plus archive access, and trace/debug methods on request. It’s built for teams that need solid, reliable coverage across many chains at once — not just Ethereum — so one integration and one API key carry your whole multi-chain stack instead of stitching together a separate provider per network. NOWNodes prices access with a clear, transparent tariff schedule: every plan is billed by raw request volume, with no compute-unit weighting or per-method multipliers to track. Plans scale by monthly request volume. How much does it cost?Start (Free) — 100k requests, 15 RPS, 5 networks, 1 month only.Pro — €20/month, 1M requests, €5 per 100k overage, WebSocket included, 3 API keys.Business — €200/month, 30M requests, €1 per 100k overage, 25 API keys.Enterprise — €500/month, 100M requests, €0.5 per 100k overage, 100 API keys.Dedicated nodes — custom pricing, combinable with shared plans.PerformanceUptime: 99.9% SLA on shared plans.Latency: multi-region infrastructure with automatic failover and load balancing.Throughput: unlimited RPS on all paid plans; 15 RPS on the free tier.Reliability: 2n+1 node redundancy, 24/7 activity monitoring.Monitoring: usage dashboard; DevOps support; account-manager support starting on Pro plan; market-data feature.Pros– One key for 120+ chains, reducing multi-chain integration overhead– Unlimited RPS once past the free tier, with no compute-unit weighting– BlockBook REST + WebSocket interfaces alongside standard RPC– Fast support response times (as low as 3 min) on paid plansCons– Free tier is time-boxed (1 month) and capped at 15 RPS– Pricing in EUR with per-request overage can be less predictable at scale than flat RPS tiers– No published SOC 2 certification– Dashboard and analytics are lighter than providers built around Ethereum-specific tooling NOWNodes is a solid pick for teams whose priority is chain breadth — wallets and multi-chain products that would otherwise need separate contracts with several providers. It’s less built around Ethereum-specific extras like SOC 2 compliance, MEV protection, or Notify/Transact-style APIs, but for broad, dependable multi-chain access under one account and one API key, it’s a strong option. OnFinality OnFinality runs managed Ethereum infrastructure on a request-unit (RU) model across four tiers: Developer (free, 400K RU/day, 40 RU/sec, archive access, no trace API), Growth ($49/mo, 20M RU/month, 200 RU/sec, trace API included, $6 per million RU overage), Accelerate ($249/mo, 100M RU/month, 500 RU/sec, $3.75 per million RU overage), and Ultimate (custom limits and pricing, enterprise support). The public endpoint is capped at 5 RPS. Dedicated Ethereum Nodes are available on every paid tier for high-volume RPC, exchanges, indexers, archive-heavy analytics, and trace workloads. Pros: Dedicated Nodes, archive plus trace/debug on paid tiers, WebSocket subscriptions, managed SubQuery indexers for teams building analytics on top of raw RPC. Cons: No SLA published on free/public tiers; formal SLA terms for paid tiers weren’t independently confirmed and should be checked directly before a production commitment. Ankr Ankr provides Ethereum RPC through a globally distributed network of node operators, routing traffic across regions to keep latency low and reduce reliance on any single infrastructure provider. You can connect to Ethereum mainnet and testnets like Sepolia via HTTPS or WebSocket, with more than 30 regions in rotation and archive access available for historical queries and tracing It’s a solid option for teams that prefer a pay-as-you-go model and want to tap into a decentralized setup, though it skips some of the advanced tooling and analytics you’d find in larger, more centralized providers. How much does it cost?Ankr uses an API credits model where credit cost varies by method (heavier calls cost more). Pricing is pegged at $0.10 = 1M API credits (PAYG), and there’s a freemium tier. It’s enough for testing, but high-traffic apps will hit the ceiling quickly.Their paid plans use a pay-as-you-go model:Premium — $10 per 100M credits (~500K requests), with up to 1,500 RPS.Enterprise — from $1,000/month, 15,000 RPS, dedicated endpoints, and priority support.PerformanceUptime: Claims up to 99.9%.Latency: Region-routed.Throughput: 30 RPS on free; ~1.5K–15K RPS on paid tiers.Reliability: Distributed design reduces single-point failures but outages can still occur.Monitoring: The console shows usage and request stats, with more advanced visibility once you move to a paid.Pros– Freemium with 200M credits/month, – Supports HTTP, WebSocket, and archive queries, – Multi-chain supportCons– Advanced visibility/support gated to paid, – No fixed monthly plans, – Fewer built-in analytics If you don’t mind variable performance across regions, Ankr could be a way to go when testing or for the smaller projects. Yet, if you need need steady throughput and predictable billing, platforms with fixed RPS tiers and dedicated routing tend to offer a more stable path for production workloads. GetBlock GetBlock provides Ethereum RPC access on mainnet and testnets like Sepolia over HTTP and WebSocket, with the option to choose regions such as New York, Frankfurt, or Singapore to improve latency. Developers can use shared endpoints to get started quickly or switch to dedicated nodes when they need higher uptime guarantees, archive access, or more consistent performance under load. While it skips the advanced APIs and deep analytics of bigger platforms, GetBlock remains a good option for teams that prioritize simplicity, regional control, and predictable access to Ethereum infrastructure. How much does it cost?Free Tier — 50k CU per day, 20 RPS.Start (Shared) — $39/month, 50M CU/month, 100 RPS.Advanced (Shared) — $159/month, 220M CU/month, 300 RPS.Pro (Shared) — $399/month, 600M CU/month, 500 RPS.Enterprise (Shared) — from $799/month, custom CU/RPS and features.PerformanceUptime: 99% on shared plans, 99.99% on dedicated.Latency: Region-pinned routing for lower RTT.Throughput: 20 RPS on free, 100 RPS on Start, 500 RPS on Pro, unlimited on Dedicated.Reliability: Shared nodes work well for low-volume usage, but performance can vary when load increases.Monitoring: Basic dashboard is available but deeper analytics are only unlocked on higher tiers.Pros– Dedicated nodes offer unlimited requests and 99.9% uptime, – Low-latency via regional nodes, – Setup is quickCons– Free tier is capped at 20 RPS, – Strict RPS ceilings on shared plans, – Monitoring features are limited compared to other infra providers GetBlock works well for early-stage testing or smaller workloads. However, as demand increases, throughput caps can limit you, and basic options for monitoring will make it harder to manage growth or troubleshoot performance issues at scale. Infura Infura provides Ethereum RPC access through infrastructure operated by ConsenSys, with direct integration into MetaMask for wallet connections. You get Ethereum mainnet and testnets like Sepolia via HTTPS and WebSocket, including archive data for historical queries. The service focuses on Ethereum-first support, with add-ons for Layer 2s (L2s) such as Polygon and Optimism. How much does it cost?Infura uses a credit-based model where each request consumes credits based on method complexity. This structure works for Ethereum-focused apps but demands monitoring to avoid caps on high-volume days.Core (Free) — 3M credits/day, 500 credits/sec.Developer — $50/month, 15M requests/day, 4K credits/sec.Team — $225/month, 75M requests/day, 40K credits/sec.Enterprise — custom.PerformanceUptime: Minimum 99.9% uptime guarantee.Latency: No official ms target published.Throughput: Credit-per-second caps by plan, Effective RPS depends on method credit cost (see examples above).Reliability: Maintains performance during spikes.Monitoring: Dashboard with usage analytics and request visibility (24h on Free; up to 30 days on paid).Pros– Built-in MetaMask integration, – Broad L2 coverage, – Archive support and Debug/Trace on eligible plansCons– IPFS API/Gateway access requires pre-approval, not open for all users, – Cost depends on method mix, – No public Ethereum-specific latency metrics Infura is a good choice for Ethereum-focused projects, especially those that rely on MetaMask and is consistent and easy to integrate. The main drawback is its credit-based structure (and IPFS access gating), which introduces limits and variable costs as usage grows. For teams that are comfortable with those trade-offs, it would be a good pick. Alchemy Alchemy offers Ethereum RPC through its Supernode, giving developers access to mainnet and testnets over HTTP and WebSocket, along with extras like Notify, Transact, and Mempool. On top, Alchemy supports dozens of networks, giving access to historical blockchain data, real-time event streaming, and built-in MEV protection on some chains. Backed by global infrastructure, Alchemy suits teams looking for additional APIs and monitoring tools. How much does it cost?Alchemy measures usage in compute units (CUs) rather than raw requests, which can make costs less predictable for teams sending large volumes of latency-sensitive calls compared to flat, request-based models.Alchemy starts with a free tier offering 30M CUs per month, roughly equal to 1.2M basic requests up to 25 RPS. Paid plans scale by total CU usage:Pay-as-you-go — $5 per 11M CUs (~$0.45 per million).Enterprise — custom pricing with lower per-unit costs at high volumes.PerformanceUptime: Reports 99.9% historical uptime, but an uptime SLA is only guaranteed on Enterprise plans.Latency: Region-based routing helps keep response times low; however, Alchemy does not publish official Ethereum-specific latency numbers.Throughput: Begins at about 25 RPS on the free tier, with scaling up to 300 RPS on paid.Reliability: The Supernode setup helps maintain data accuracy during heavy traffic.Monitoring: You can check usage, errors, and request patterns through the dashboard in real time.Pros– Covers Ethereum plus 40+ chains, – Built-in MEV protection on supported networks, – Rich toolingCons– CU pricing isn’t intuitive, – Hard to verify real performance without public benchmarks, – Throughput caps by plan, very high RPS needs enterprise plan Alchemy performs reliably under heavy load, and latency stays tight across regions. Its compute-based pricing gives you flexibility in how you use the service, but it also means your bill depends on call mix, not just volume, which can make it harder to model at scale. If you’re building with features like Notify or Mempool streaming, Alchemy is fine option, but less ideal if you want predictable scaling. Quicknode Quicknode runs a multi-region infrastructure for Ethereum RPC, letting you connect to mainnet and testnets like Sepolia and Holesky over HTTP or WebSocket. Archive support is available for teams that need to query deep historical data. It also supports dozens of other chains and offers add-ons such as Webhooks and Streams if you want event-based triggers or real-time blockchain feeds. It’s popular with high-traffic teams because the network scales well under pressure, but to get to that performance you would need to move to the higher-priced tiers. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom terms for higher volumes and dedicated support. Credits rollover unused portions, which helps variable Ethereum loads, though the model adds a layer compared to straight request counts.PerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Scales up to 500+ RPS on higher plans, – Archive data available (by chain/plan), – Low latency from multi-region routingConsFree trial caps at 15-25 RPS with only community support, – Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode gives you speed, global routing, and developer tooling, which makes it good option for Ethereum apps. The main limitation is its credit-based (method-weighted) pricing. Because different methods burn credits at different rates, long-term cost planning takes more effort, especially if your workload isn’t static. Conclusion Choosing the right Ethereum RPC providers in 2026 depends on your workload profile, compliance requirements, and tolerance for variable pricing models. The 2026 Ethereum RPC landscape is more competitive and mature than ever. Chainstack leads as the top all-around provider, combining enterprise-grade performance and 99.99% uptime via multi-cloud routing, transparent request-based pricing ($0.25-$2.50/M with unlimited options), and full SOC 2 Type II and ISO 27001 compliance. It perfectly serves stablecoin payments, and enterprise dApps include 70+ chain support.​ NOWNodes offers the broadest multi-chain coverage with 120+ networks accessible through a single API key and transparent request-based pricing, making it a strong pick for wallets and multi-chain products that need dependable coverage without provider fragmentation. OnFinality runs a request-unit pricing model with Dedicated Nodes and managed SubQuery indexers on every paid tier. Quicknode excels in speed (2-3× faster responses, 500+ RPS) for latency-critical apps, with dual SOC 2/ISO certifications. Alchemy dominates developer tooling (Notify/Transact APIs, generous free tier). Ankr provides flexible pay-as-you-go pricing with broad multi-chain support. GetBlock suits budget-conscious devs with simple regional endpoints. Infura remains Ethereum’s trusted veteran with MetaMask integration. Developers now have mission-critical infrastructure options that deliver unprecedented reliability and performance. Deploy your Ethereum RPC endpoint on Chainstack → FAQ What is Ethereum RPC and why do I need it? Ethereum RPC is the standard interface that lets applications communicate with the Ethereum blockchain. Through an RPC provider, you can read blockchain data (balances, transactions), send transactions, deploy smart contracts, and interact with dApps using JSON-RPC API calls. Without reliable RPC, your app can’t connect to Ethereum. Which is the top Ethereum RPC provider in 2026? Chainstack leads for production use, combining predictable request-based pricing and scalable performance for enterprise workloads, 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and both free/enterprise tiers. It covers payments, enterprise, and DeFi needs better than competitors. Are there free Ethereum RPC options suitable for real development? Yes. Chainstack offers 3M requests/month (~25 RPS) free with full mainnet/testnet access, archive data, and testnet faucets. Alchemy gives 30M CUs (~1.2M requests), Infura ~100k daily requests, and GetBlock 50k daily. Chainstack’s free tier is most generous for actual development. Which Ethereum RPC provider supports the most blockchain networks? NOWNodes leads in multi-chain breadth with 120+ supported networks accessible through a single API key, making it a natural fit for wallets and multi-chain products where breadth matters most. Chainstack supports 70+ chains and adds enterprise-grade features like SOC 2 Type II + ISO 27001 certification, dedicated nodes, and 99.99% uptime SLA — the stronger pick for production workloads requiring compliance and premium performance. Ankr and Quicknode each support 40+ chains with different pricing models. How do I connect to an Ethereum RPC node? When you start building on Ethereum, the provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. While different platforms cater to different use cases, Chainstack bundles the full stack into a setup that takes minutes to deploy:– Log in to your Chainstack account (or create one if you don’t have it yet).– Create a new project or select an existing one.– Choose Ethereum, then pick mainnet or a testnet like Sepolia or Hoodi.– Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Not only do you get the option to choose between Global Nodes for shared, geo-balanced access or Dedicated Nodes for isolated performance and full control, but every deployment comes production-ready. Both options include Bolt fast sync for same-day readiness and GraphQL support. You also get built-in security through Access rules, plus testnet faucets and MEV protection enabled by default. Everything required to connect, build, and ship on Ethereum is available in one place. When evaluating Ethereum RPC node providers, it’s important to consider not only raw performance, but also long-term reliability, pricing transparency, and support for production workloads. Reliable Ethereum RPC infrastructure Getting started with Ethereum on Chainstack is fast and straightforward — deploy a reliable node in seconds through an intuitive console, no hardware or complex setup required. With 99.99% uptime, 24/7 SLA-backed operations and low-latency global endpoints, Chainstack ensures seamless RPC access for building and scaling DeFi, analytics, and trading applications. Additional resources For more on building with Ethereum RPC, explore these resources: Ethereum API reference on Chainstack — JSON-RPC methods, quickstart, and endpoint setup Ethereum tooling guide — wallets, SDKs, and libraries that work with Chainstack Ethereum nodes Chainstack Ethereum RPC — the product page for deploying Ethereum mainnet and testnet nodes Ethereum JSON-RPC specification — the official method-by-method spec on ethereum.org Ethereum developer docs — ethereum.org’s official documentation for building on Ethereum #### Best free tier RPCs for web3 builders in 2026 TL;DR: Every RPC provider says “free tier.” Almost none of them mean it. Some require a credit card upfront just to see the dashboard. Others throttle you into uselessness with tiny per-second quotas. Most cap real production features — WebSockets, MEV protection, dedicated endpoints — behind paid plans. A few pretend “free” means a 30-day trial that deactivates your account when it ends. If you’re a web3 builder trying to ship your first dApp without funding a subscription first, most of these free tiers waste your time. Chainstack’s Developer plan doesn’t play these games — no credit card, no trial, no time limit, and features (private endpoint, WebSockets, MEV protection, MCP for AI agents, free testnet faucet) that others charge for. Why “free” isn’t the same everywhere Every major RPC provider advertises a free tier. But “free” means very different things in practice. Some providers give you a permanent free plan with real production features. Others give you a 30-day trial that deactivates your account when it ends. Some require a credit card just to see the dashboard. Some throttle you so aggressively that anything past a toy project needs a paid upgrade. ➡️ None of that on Chainstack. No trial. No countdown. No credit card at signup or at upgrade. No account deactivation after 30 days. No downgrade of features to force you onto a paid plan. The free Developer plan is a permanent, standalone plan — not a marketing funnel dressed up as one. If you’re just starting your web3 builder journey — spinning up your first dApp, learning Solidity, prototyping a bot, testing an idea — the last thing you want is to hand over your card before you’ve written a line of code. This article covers what you actually get on Chainstack’s Developer plan: the free tier that requires no credit card, has no time limit, and includes the features you’d normally have to pay for elsewhere. What you actually get on Chainstack’s free Developer plan Ten features — most of which competitors either lock behind paid tiers, gate behind a credit card, or don’t offer at all. Each section below covers one feature, what it means for a builder, and how it compares to Alchemy, Infura, and Quicknode where relevant. 1. A private, geo-balanced RPC endpoint Yes — the free Developer plan gives you a private RPC endpoint, not a shared public URL. It lives in your Chainstack console, only your API key routes through it, and it runs on Chainstack’s geo-balanced Global Node infrastructure with “>99.99% uptime” and sub-second failover between regions. Chainstack’s own pricing page puts it plainly: “Global nodes are free on Chainstack.” This is the difference between a public endpoint (shared with thousands of anonymous users, aggressive rate limits, 429 Too Many Requests errors, no SLA) and a private one (yours alone, higher throughput, predictable behavior). Public endpoints are fine for reading the chain occasionally. They break the moment your app has real users. On the free plan you get: 3,000,000 request units per month — enough for a real prototype, not a toy 25 requests per second steady throughput Global Node architecture — requests route to the nearest region automatically Support for 70+ protocols including Ethereum, Solana, Bitcoin, BNB Smart Chain, Polygon, Arbitrum, Base, Optimism, TON, TRON, Starknet, Hyperliquid, and more Node analytics, node logs, and 2FA — all included Why 3M requests on Chainstack is worth more than 3M elsewhere. Chainstack bills every API call as 1 request unit, regardless of the method. Quicknode’s credits and Alchemy’s compute units are weighted — the same call costs more depending on complexity, and archive/trace methods cost multiple times more. According to Chainstack’s own pricing page, 3M Chainstack request units is roughly equivalent to 75M Alchemy compute units or 60M Quicknode API credits for typical workloads. That’s the actual comparison, not the sticker number. See the full method-by-method breakdown here. Compared to competitors: Alchemy’s free tier gives you ~30M compute units/month (roughly ~1.1M requests) but its documented rate limit is 25 req/s — comparable to Chainstack. Infura’s Core plan is 3M credits/day at 500 credits/sec (~37K standard requests/day at 80 credits each). Quicknode has no permanent free plan — its entry tier is a 30-day trial, after which the account is deactivated. 2. WebSocket endpoints — included, not upsold Yes — WebSocket endpoints (wss://) are included on the free plan. You can subscribe to new blocks, pending transactions, log events, and account changes in real time, without polling. Every free-plan endpoint ships with both an HTTPS URL and a WSS URL. No separate upgrade, no add-on, no “starts at $49/mo.” Just paste the WSS URL into your ethers.js or web3.py provider and start listening. Why this matters for a beginner: most useful web3 patterns — mempool watching, event indexing, real-time UIs, bots reacting to trades — need WebSockets. Learning to build them on a free tier that supports WebSockets is the difference between building the actual thing and building a rate-limited HTTP polling workaround. Alchemy and Infura also include WebSockets on their free tiers. Quicknode’s trial technically includes them for 30 days. The real value here isn’t uniqueness — it’s that on Chainstack you get WebSockets on a plan that never expires. 3. MEV protection — enabled by default Yes — MEV protection is included and turned on by default on the free plan. You don’t opt in. It’s already routing your eth_sendRawTransaction calls through a private builder network instead of the public mempool. You’d have to actively click Disable to turn it off. This is a real feature. Front-running bots watch the public mempool for profitable transactions and race to execute against them — sandwich attacks, arbitrage sniping, liquidation front-running. On a standard public RPC, every transaction you send is visible to those bots the moment it hits the mempool. With MEV Protection on, your transaction goes through a private relay directly to a block builder. Bots never see it. Supported chains on Chainstack: Ethereum, BNB Smart Chain, Arbitrum, Base. Compared to competitors: Alchemy also includes MEV protection built-in on its free tier across the same chains. Infura offers MEV protection but not as a default. dRPC has it as a paid add-on. Quicknode enables MEV protection on paid plans, not on its free trial. This is one of the few features where Chainstack and Alchemy are at parity on free — and everyone else trails. Chainstack MEV Protection docs → 4. Community support that actually answers On the free plan you get community support through Discord and Telegram, plus a comprehensive knowledge base and docs for self-service. To be clear about what “community” means: you get access to the knowledge base, plus Discord and Telegram channels where Chainstack engineers are active. You don’t get email support, guaranteed response times, or a support SLA — those are Standard-tier (included in all paid plans starting at Growth, $49/mo). This matters more than most people expect. Free tiers on cloud infrastructure are notorious for “read the docs and figure it out.” Getting a straight answer from an actual engineer when your eth_getLogs call is timing out or your WebSocket subscription is silently dropping is what separates finishing a project from abandoning it. 5. Pay in crypto — never touch a card, even when you upgrade Yes — you can pay for Chainstack in crypto instead of using a card, on every plan including the free-to-paid transition. This is genuinely rare. Alchemy, Infura, and Quicknode all require a credit card for their paid tiers. Chainstack accepts crypto for balance top-ups, which then covers your subscription and any extra usage. For a web3 builder, this closes the loop on “no credit card required.” You start on the free Developer plan without a card. When your app grows past 3M request units per month and you want to move to Growth ($49/mo), you still don’t need a card — you top up your Chainstack balance with crypto and the charges deduct from it automatically. This matters for two audiences. First, anyone in a jurisdiction where getting a card that works with US-based SaaS is complicated (which is a lot of the world). Second, anyone who ideologically wants to keep their web3 infrastructure paid for in web3-native rails. Either way, it’s a real feature, not marketing. 6. Unlimited team users on the free plan Yes — you can invite unlimited team members to your Chainstack organization on the free Developer plan. No seat limit, no per-user pricing, no upgrade required to add your co-founder or your hackathon team. This is unusual. Most SaaS platforms cap free-tier seats at 1-5 to push teams onto paid plans. Chainstack’s free plan lets you run a full team on one shared organization, with unlimited users across your 1 included project. For beginners this matters more than it sounds. If you’re building at a hackathon, running a study group, contributing to an open-source dApp, or working on a founding team before you have revenue — you don’t want infrastructure that punishes you for having collaborators. On Chainstack, everyone on your team gets access to the same endpoints and dashboard for free. 7. Run self-hosted nodes with no limits Yes — you can deploy and manage unlimited blockchain nodes on your own infrastructure with Chainstack Self-Hosted Free Community edition, at zero platform cost. This is a category where Alchemy, Infura, and Quicknode have no equivalent product at all — they are closed managed-only platforms. Chainstack is the only major provider that gives you an enterprise-grade orchestration layer for your own nodes, for free. Chainstack’s wording from the June 2026 launch: “The Free Community tier is unlocked by default — unlimited nodes with basic monitoring at no extra cost.” No node fee to Chainstack. No credit commitment. No enterprise sales call. No request-a-demo form. You bring your own infrastructure — any cloud VPS, bare metal, a homelab server, or a local machine — and Chainstack gives you the Kubernetes-native control plane for deploying, monitoring, self-healing, and managing blockchain nodes. Supported protocols on Self-Hosted include Ethereum, Arbitrum, Optimism, Base, Unichain, Zora, Robinhood Chain, Polygon, Starknet, TRON, and Bitcoin — see the full list of supported deployments for exact clients and networks. For beginners, this matters as a graduation path. You start on the managed free endpoint. When you eventually want an archive node, custom tracing configuration, or infrastructure in a specific jurisdiction, you don’t have to re-platform — the same account, same UI, same MCP integration, just running on your own hardware. 8. Referral program — earn while you learn The referral program is open to free-plan users. You get 20% of your referral’s subscription spend for a full 12 months, paid monthly to your Chainstack balance. Your referred friend gets 20% bonus credits for their first three billing cycles. The referral cookie window is 30 days. You can withdraw the balance or apply it to Chainstack services. For a beginner writing tutorials, contributing to web3 Discords, or streaming builds on YouTube, this turns knowledge-sharing into a small revenue stream without any upfront cost. 9. Free MCP server + Platform API for AI-agent workflows Yes — the Chainstack MCP server is free to use on the Developer plan, and the Platform API is included too. Chainstack’s MCP page states it directly: “Free-tier accounts get full access to all unauthenticated tools immediately.” No per-request charges from Chainstack for the MCP layer itself — you’re only spending your normal RPC request units on the underlying calls. The MCP server (mcp.chainstack.com) works out of the box in Claude, Cursor, OpenAI Codex, Gemini CLI, and VS Code. No local install. Point your AI agent at it and it can create endpoints, query chain data, manage nodes, and read your account state — all through your existing Chainstack account. The Platform API (docs) does the same programmatically: spin up nodes, rotate keys, monitor usage, automate deploys. This is a genuine differentiator in 2026. Most providers either don’t have a public MCP server or charge separately for API access. For anyone building AI-agent workflows or wanting to manage infra from Claude Code, this is a category where Chainstack’s free tier includes what others sell as a separate product. 10. Free testnet tokens via faucet — no X login required Yes — Chainstack runs a free testnet faucet covering 12 networks, and it doesn’t ask for an X or Discord login. All you need is a Chainstack API key (free from your Developer plan) and a wallet address. Pick a network, paste the address, paste the key, click Claim. If you’ve spent any time on web3 tutorials, you know the drill: you need Sepolia ETH to deploy your first contract, so you google “Sepolia faucet.” The top results either want you to authenticate with X, ask for a mainnet ETH holdings check, throw a captcha, or hand you 0.00001 ETH once a week. Multiply this by every testnet you touch — Hyperliquid, Robinhood, Monad, Plasma, Solana devnet, Base Sepolia — and you’re spending more time hunting for tokens than writing code. Chainstack’s faucet supports 12 networks, including the ones you actually need in 2026: Hyperliquid testnet, Robinhood Chain testnet, Ethereum Sepolia, Base Sepolia, and Solana devnet. Also on the list: Ethereum Hoodi, BNB Smart Chain testnet, Monad testnet, Polygon Amoy, TON testnet, Plasma testnet, and zkSync Sepolia. Each address can top up once every 24 hours. Bonus: the faucet is also exposed through the Chainstack MCP server as request_testnet_funds, so your AI agent can fund a testnet wallet without you leaving your IDE. One thing to know upfront: Chainstack uses two anti-abuse checks instead of X login. Your requesting address needs a minimum balance of 0.08 ETH on Ethereum mainnet and a history of holding ETH on mainnet (not a freshly empty wallet). This keeps the faucet usable — no drained pools from farming bots — but it does mean a brand-new wallet with zero mainnet history won’t work. In practice, any developer who’s touched mainnet even once passes this check. For a first-time deployer, this saves hours. For a hackathon team, it removes a class of blockers entirely. Free-tier comparison at a glance (mid-2026) FeatureChainstack DeveloperAlchemy FreeInfura CoreQuicknodePermanent free (no time limit)✅ Yes✅ Yes✅ Yes❌ 30-day trial, then deactivatedMonthly quota3M request units~30M CU (~1.1M req)3M credits/day10M credits (trial only)Rate limit25 req/s25 req/s500 credits/sec15 req/sPrivate endpoint✅ Yes✅ Yes✅ Yes✅ (trial)Geo-balanced by default✅ YesPartialPartialPartialWebSockets✅ Yes✅ Yes (100 conn cap)✅ Yes✅ (trial)MEV protection built-in✅ Included by default✅ Included❌ Not default❌ PaidFree MCP server✅ Yes❌❌❌Free testnet faucet (no X login)✅ 12 networksLimited networksLimited networksLimited networksPay in crypto✅ Yes❌❌❌Unlimited team users on free✅ YesSeat-limitedSeat-limitedLimited (trial)Self-hosted option✅ Free Community edition, unlimited nodes❌❌❌Referral program✅ 20% / 12 monthsLimitedLimitedLimited Sources: chainstack.com/pricing, plus each provider’s public pricing pages. Last verified July 2026. The best place to start your web3 journey Every RPC provider has a free tier. Very few have a free tier you can actually build on — private endpoint, WebSockets, MEV protection on by default, a full team on one account, self-hosted option when you’re ready, MCP for AI agents, a testnet faucet that doesn’t gate you behind Twitter, and no credit card at any point, ever. That’s what Chainstack’s Developer plan is: not a marketing funnel with a countdown timer, not a 30-day trial that deactivates you, not a “free” quota that requires a card to unlock. A permanent starting point with production-grade features included from day one. If you’re prototyping your first dApp, learning Solidity, building a hackathon project, or standing up infrastructure for a founding team without revenue yet — this is the plan for you. Create your free Chainstack account and deploy your first endpoint in under a minute. No credit card, no time limit, no upgrade required. Create your free Chainstack account → FAQ What is an RPC endpoint and why do I need one? An RPC endpoint is a URL (HTTPS or WebSocket) that lets your app read data from a blockchain and send transactions to it. Without one, your dApp, wallet, or bot cannot see chain state or broadcast transactions. You either run your own node — expensive and complex — or use a managed provider that gives you an endpoint URL. Is there a truly free RPC provider with no credit card? Yes. Chainstack’s Developer plan is free with no credit card required and no time limit — it’s a permanent plan, not a trial. It includes 3M request units per month, WebSockets, a private geo-balanced endpoint, MEV protection by default, and a free MCP server for AI agents. Some other providers advertise free tiers too, but signup flows and card requirements vary — always check before you commit. Sign up here. Does Quicknode have a free tier? No. Quicknode offers a 30-day free trial with 10M credits and 15 req/s. After 30 days, if you don’t upgrade to a paid plan (starting at $49/mo), your account is deactivated and your endpoints stop working. There is no permanent free tier. What’s the difference between a public and a private RPC endpoint? A public endpoint is a shared URL used by many anonymous users — heavily rate-limited, no SLA, prone to 429 errors, fine for testing. A private endpoint is tied to your account and API key, has higher throughput, predictable behavior, and is stable enough for production. Chainstack’s free plan gives you a private endpoint, not a public one.A public endpoint is a shared URL used by many anonymous users — heavily rate-limited, no SLA, prone to 429 errors, fine for testing. A private endpoint is tied to your account and API key, has higher throughput, predictable behavior, and is stable enough for production. Chainstack’s free plan gives you a private endpoint, not a public one. Do I need WebSocket endpoints for a beginner project? If you want real-time features — mempool watching, live event listeners, streaming block updates, trading bots — yes. If you only need to read chain state occasionally, HTTPS is enough. Chainstack, Alchemy, and Infura all include WebSockets on their free tiers, so you don’t have to choose upfront. Is MEV protection really free on Chainstack? Yes. MEV Protection is enabled by default on every free-plan endpoint for Ethereum, BNB Smart Chain, Arbitrum, and Base. Your eth_sendRawTransaction calls route through a private builder network instead of the public mempool, protecting your transactions from front-running and sandwich attacks. You’d have to actively click Disable to turn it off. Can I use Chainstack from AI agents like Claude or Cursor? Yes. The Chainstack MCP server is free to use and works out of the box in Claude Desktop, Cursor, OpenAI Codex, Gemini CLI, and VS Code. It lets AI agents create endpoints, query chain data, and manage your infrastructure through your existing Chainstack account. No additional charges from Chainstack for MCP requests. How long does it take to switch from Quicknode or Alchemy to Chainstack? Most teams complete the switch in under 10 minutes. Sign up and create a project on Chainstack, deploy a node for your target network (Global, Trader, or Dedicated), and copy the new endpoint URL into your application or gateway in place of the old one. Chainstack’s endpoints follow standard JSON-RPC, so most codebases work with only a URL change. See the dedicated Quicknode and Alchemy migration guides. What happens when I outgrow the free plan? Extra usage on the Developer plan is metered at $20 per 1M request units — no forced upgrade. If you need more throughput, dedicated hardware, archive nodes, debug/trace API, or an SLA, the Growth plan unlocks those. You can also stay on Developer indefinitely if your app fits within 3M request units per month. Additional resources Compare and migrate: Chainstack vs Quicknode vs Alchemy: cost breakdown — method-by-method pricing comparison Switch from Quicknode to Chainstack — migration guide with pricing calculator Switch from Alchemy to Chainstack — migration guide with cost calculator Why switch to Chainstack — full differentiator overview Learn web3 development: ethereum.org developer docs — the canonical starting point Solana developer docs Chainstack Developer Portal — tutorials, guides, code examples Chainstack Blog — technical deep-dives #### Best Hyperliquid RPC providers in 2026 Hyperliquid RPC providers play a critical role for builders and traders using Hyperliquid in 2026. This guide compares the top Hyperliquid RPC providers and explains how to choose and set up the right one for trading bots, staking, and smart contracts. Hyperliquid has become a popular choice thanks to its high throughput, EVM compatibility, and native order book design. The order book is directly tied to HyperEVM, meaning Solidity contracts execute against the same state as live trades. With sub-second finality via HyperBFT, negligible fees, and high throughput, Hyperliquid is well suited for high-speed trading bots, on-chain funds, and real-time applications. Naturally, the free public Hyperliquid RPC is your first stop for testing, though limits vary by method, and some public endpoints are capped near ~100 requests/min. So, if you’re moving into production, you’d look for a private RPC provider. Yet performance across these providers is anything but consistent (and some proprietary HyperCore trading methods remain public-RPC-only, regardless of provider). That’s why we lined up the main Hyperliquid RPC providers and put them side by side on speed, scale, and reliability so you can see which one matches your build. Comparison of the best Hyperliquid RPC providers Here’s a quick look at how the top Hyperliquid RPC providers stack up on rate limits, latency, pricing, and network coverage. #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPS250–600 RPS by plan; subscription tiers with included quota + overage. Unlimited Nodes option for unmetered requests at a flat monthly rateLow latency, global routing with 99.9%+ uptimeComprehensive docs, MCP server, Access rules, Hyperliquid faucet, dashboard analytics, Node comparison tool, HyperEVM archive + HyperEVM WebSockets2dRPCAvailable, ~40–250 RPSUp to 5,000 RPS; flat $6 per 1 M requestsLatency-aware routing, uptime on paid plansAnalytics dashboard, unlimited API keys3HypeRPC10k requests/mo, 5 RPS50–300 RPS; tiered monthly plans, custom on requestLow, region-based, 99.99% uptimeReal-time metrics, trader-focused console4DwellirFree — 500k req/day, 20 RPSUp to 2,000 RPS on plans; custom on enterpriseIsolated on dedicated; rate-limited on shared; public status page availableHyperEVM JSON-RPC/WebSockets + Hyperliquid L1 gRPC5Alchemy300M credits/mo, ~300 RPS capHigher CU throughput by plan; pay-as-you-go credit tiersLow latency routing, uptime available on higher tiersTransact & Notify APIs, simulation tools, analytics dashboards6QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based monthly plansLow latency, global routing with 99.99% uptime on paid plansStreams, Webhooks, analytics dashboard Important: HyperCore proprietary methods Critical for trading applications: Several HyperCore methods remain exclusive toHyperliquid’s public RPC and are not available through any private provider: l2Book — Order book depth order — Submit orders cancel — Cancel orders recentTrades — Recent trade history This means all trading bots must use the public RPC for order execution, regardlessof which private RPC provider you choose for HyperEVM and other HyperCore info methods. Private RPC providers (including Chainstack) support:✅ HyperEVM methods (smart contracts, events, archive)✅ Non-proprietary HyperCore info methods (account data, fills, user state)❌ Proprietary trading methods (order placement, cancellation, book queries) Choose Hyperliquid RPC providers by use case High-frequency trading bots and market makers need the lowest possible latency on HyperEVM plus non-proprietary HyperCore info methods, since order placement itself stays on the public RPC regardless of provider. Chainstack and HypeRPC are the strongest fits here — Chainstack for multi-region routing and archive access, HypeRPC if you’re fully committed to Hyperliquid and want servers sitting closest to its validators. Teams already running multi-chain infrastructure on Ethereum or Polygon get the fastest path to Hyperliquid through Alchemy or Quicknode, since both let you reuse the same libraries (ethers.js, web3.py) and dashboards you already have for other chains, at the cost of Hyperliquid-specific tooling like a faucet. Cost-conscious teams testing before committing to production should look at dRPC’s flat per-request pricing with no fixed quota, or Chainstack’s free Developer tier, before scaling into a paid plan. Teams that need fully isolated, dedicated infrastructure rather than shared capacity are better served by Dwellir’s dedicated nodes or Chainstack’s Dedicated Node tier. Chainstack Chainstack is a multi-chain infrastructure platform and one of the first providers to bring full Hyperliquid RPC support to production. By choosing Chainstack Hyperliquid RPC endpoints, you get private access to both HyperEVM (smart contracts) and HyperCore (the native order book) over HTTP and WebSocket, all backed by a guaranteed 99.99%+ uptime, with most HyperCore methods available privately and a few remaining public-only per Hyperliquid’s own setup. What’s more, with Chainstack, you get a full set of tools that make building on Hyperliquid easier, all from the same platform, including: One of the first built-in Hyperliquid faucet to grab testnet HYPE. HyperEVM archive for historical reads, plus HyperEVM WebSockets for live contract events. A method table showing 100+ HyperEVM calls (with notes on which HyperCore methods are public-RPC-only), an API reference, MCP Server, and even a ready-to-clone trading bot repo. Access rules to set limits on keys, requests, and IPs directly from the dashboard. Backed by a globally distributed, multi-cloud network, Chainstack delivers predictable performance for builders moving from test to production. And the setup takes just a few minutes in the console. How much does Chainstack cost? Chainstack has cost-effective plans, so infra costs are easy to track and estimate: Developer — free, 3M requests/month (~25 RPS), $20 per extra million. Growth — $49/month, 20M requests (~250 RPS), $15 per extra million. Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million. Business — $499/month, 200M requests (~600 RPS), $10 per extra million. Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million. Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149. Dedicated — $0.50/hour + storage for exclusive ultra-high performance Hyperliquid nodes. This setup offers one of the few providers that allow you to start for free and scale into predictable tiers as traffic grows. Performance of Chainstack among Hyperliquid RPC providers Chainstack’s entire stack is engineered to give you the competitive edge on Hyperliquid with: Global routing: Deploy nodes in the US, EU, or Asia regions to minimize latency. Uptime guarantee: 99.99%+ uptime on Hyperliquid nodes, with self-healing infra behind it. Performance: Low on EVM calls, upper tiers support ~400–600 RPS for heavy use. Monitoring: Built-in tools and compare benchmarks to validate endpoint performance against competitors. Pros & cons of Chainstack ProsConsOne provider for Hyperliquid plus 70+ other chainsFree plan (3M calls, 25 RPS) may be too limited for bots or indexersPredictable pricing with flat monthly plans and high included quotasFixed RPS caps per plan; very latency-sensitive apps may need Unlimited or Dedicated99.9%+ uptime, SOC2 compliance, globally distributed nodesDedicated Nodes require at least a Pro/Business planSupports both elastic scaling and dedicated nodes. Can handle heavy load (hundreds of RPS) with an unlimited tier for nonstop throughputClear docs, built-in Hyperliquid faucet, unified dashboard for metrics and logs You get everything you need for Hyperliquid on Chainstack: private HyperEVM and HyperCore endpoints, a faucet for testnet HYPE, HyperEVM archive + HyperEVM WebSockets, and monitoring in the same console. The pricing model is clear, nodes are distributed globally, and there’s a free tier to try it out before committing to a paid plan. dRPC dRPC is one of the newer names in the industry, built around a decentralized model and supporting Hyperliquid from day one. Here, instead of a single backend, traffic is routed through a network of independent node operators, with an AI balancer deciding where each request goes. With this setup, DRPC aims to combine redundancy with ease of use. That said, since the platform is still fairly new, there’s not a ton of long-term data yet on how it performs under constant production load. dRPC exposes HyperEVM archive and HyperEVM WebSockets; consult docs for any HyperCore streaming options. How much does dRPC cost? dRPC pricing is pretty simple, as you just pay for what you use. Free plan — $0/month, and runs between roughly 40 and 250 RPS, depending on network load. Premium plan — $6 per 1M requests, flat rate across all chains and methods. Volume discounts — Available for high-traffic users. It’s a good setup if you’re testing or ramping up a smaller Hyperliquid project. However, teams already in production may prefer something with defined quotas and guaranteed support. Performance on Hyperliquid with dRPC dRPC’s setup moves traffic across seven regional clusters, sending each call to whichever node is both close and under-loaded. That system helps balance speed and consistency across a decentralized network. So you can generally expect: Throughput: Up to 5,000 RPS per endpoint on premium plan. Latency: Routing that automatically favors the fastest available node. Uptime: Uptime that’s strong in practice, though detailed SLAs aren’t public yet. Scalability: No fixed rate limits on premium, with unlimited API keys. Infrastructure: Built-in redundancy, so if one node stalls, another picks up the load. Pros & cons of dRPC ProsConsFlat $6-per-million pricing that keeps billing simpleStill a new platform without long-term reliability dataHandles heavy loads (up to ~5K RPS) with no fixed quotasNo broader dev tools like webhooks or indexingDecentralized routing provides automatic failoverSupport is community-based, and Hyperliquid-specific docs are limited In short, dRPC is a flexible choice for builders who want raw RPC access and are open to using a newer service that’s still proving itself. HypeRPC HypeRPC is a bit different from most RPC providers, as it’s built solely for Hyperliquid. Everything in its setup, from caching layers to where servers sit, is tuned around this one network. The team works closely with Hyperliquid’s core devs, which likely helps them stay ahead on updates and performance tweaks. Update: as of 2026, HypeRPC has been acquired by Hyperdash — verify current product and pricing directly at hyperpc.app before committing, since the plans below reflect the pre-acquisition offering. You can pick between shared global endpoints or a dedicated setup that’s fully isolated. That focus pays off in raw speed, though it ties you to a single ecosystem. Therefore, it’s a great fit if you are all-in on Hyperliquid, but less ideal if you’re managing a stack that spans multiple chains. By default, HypeRPC covers HyperEVM archive and HyperEVM WebSockets; review HypeRPC docs for current HyperCore stream availability. How much does HypeRPC cost? Pre-acquisition, HypeRPC offered plans focused on performance over high quotas, sitting at the premium end of the market (confirm current tiers post-acquisition): Starter — Free, 10K requests/month, 5 RPS. Professional — $99/month, 1M requests, 50 RPS. Enterprise — $299/month, 3M requests, 150 RPS. Unlimited — $499/month, 5M requests, 300 RPS. Dedicated nodes — Custom pricing with no hard caps. There are no public overage fees; once you reach your plan’s limit, you’ll likely need to upgrade. The cost is higher compared to general RPC providers, but it reflects HypeRPC’s focus on one network and its optimized setup for Hyperliquid. Performance on Hyperliquid with HypeRPC Since HypeRPC is built only for Hyperliquid, its servers sit close to the chain’s validators, trimming latency to almost nothing. It’s designed for fast, continuous trading workloads rather than casual testing so you’ll notice: Uptime: 99.99% uptime. Latency: Very low latency from regional nodes in Europe and Japan. Scalability: Enough headroom to handle short market spikes or steady high-frequency traffic. Visibility: A live dashboard that lets you watch latency and request counts in real time. Security: Enterprise-grade DDoS protection and routing safeguards for live trading environments. Pros & cons of HypeRPC ProsConsEverything runs close to the network’s validators, so latency stays low and updates land fastPlans start high for what’s included, with 1–5M monthly calls that can run out quickly on data-heavy bots or analytics pipelinesSolid uptime and smooth scaling during trading spikesOnly EU and JP regions are available for now, which can add latency for users in other parts of the worldWebSockets, archive data, and responsive support are available, making it easy to monitor and react in real timeIt’s new and focused only on Hyperliquid, so teams running multi-chain systems might need another provider HypeRPC gives you exactly what you’d expect from a Hyperliquid-only provider:  speed, uptime, and a setup tuned for trading workloads. It’s a strong pick if your whole stack runs on Hyperliquid and you care about every millisecond. But if you’re running multi-chain systems or want broader flexibility, pairing it with another provider might make more sense. Dwellir Dwellir, known for its work in the Polkadot ecosystem, offers both shared HyperEVM endpoints and dedicated Hyperliquid RPC nodes. Each user gets their own managed node by Dwellir’s team. That setup means you’re not competing for bandwidth with anyone else, which helps keep performance the same. Additionally, you get shared endpoints for quick integration and gRPC for L1 data streaming. However, the trade-off comes on the pricing side as Dwellir’s RPS limits are lower than some competitors at comparable price points, and if your stack needs advanced infrastructure features, that would be an extra lift. How much does Dwellir cost? Dwellir also offers a free tier (500k requests/day, 20 RPS) you can start on before moving to shared or dedicated endpoints. Dedicated nodes are available as well when you need isolated infrastructure, so it’s a good pick if you’re prioritizing stable performance, predictable behavior, and higher throughput than what shared plans can usually handle. Starter — $5, 20 RPS, 500k/day cap. Developer — $49/mo, 100 RPS, 25M API responses/month. Growth — $299/mo, 500 RPS, 150M API responses/month. Scale — $999/mo, 2000 RPS, 500M API responses/month. Performance on Hyperliquid with Dwellir Dwellir supports shared endpoints for quick starts and dedicated nodes for isolated performance. On dedicated, your traffic is fully isolated; on shared, you run within plan rate limits. Throughput: Plan-based, scales up to 2,000 RPS, though higher limits are available on request. Latency: Solid on dedicated, though real-world response times may vary depending on your region. Real-time data: HyperCore gRPC streaming for order-book and trade events, plus HyperEVM WebSockets for contract events. Monitoring: A dashboard where you can check metrics and stats, plus a public status page. Pros & cons of Dwellir ProsConsShared and dedicated options availableLower RPS at lower plan tiersUsage/latency visibility in dashboard and public status pageFewer built-in platform featuresIncludes gRPC streaming for order-book and trade data in real timePricing is quota & RPS based, unmetered-in-tier options unavailable If you need Hyperliquid with built-in gRPC L1 streaming and the option to move to a dedicated node for full isolation, Dwellir is a nice pick. Just be aware that RPS limits at the lower plan tiers are lower than what some competitors offer at the same price point. Alchemy Alchemy recently rolled out Hyperliquid support through HyperEVM endpoints, making it easy for developers already familiar with Ethereum tools to plug in. You can still use the same libraries, like ethers.js, web3.py, and the workflow feels the same. The platform carries over much of what it’s known for on Ethereum and Polygon: APIs like Transact and Notify, detailed analytics dashboards, and debugging utilities such as transaction simulation. On Hyperliquid, this translates to full RPC access to chain data, along with the ability to trigger trading functions through HyperEVM. WebSockets and archive are for HyperEVM. Review Alchemy docs for any HyperCore stream support. How much does Alchemy cost? One thing to note is that Alchemy measures usage in Compute Units (CUs) rather than raw requests. For Hyperliquid teams making lots of lightweight, latency-sensitive calls, this can make costs less predictable than flat request-based models. That said, Alchemy does offer a free tier: up to 300 million CUs per month with ~300 RPS throughput, enough for many small to mid-sized projects. Beyond that, the pricing options are: Pay-as-you-go — $5 per 11M CUs (~$0.45/M) Growth — $49/month for ~400M CUs Scale — $289/month for 1.5B CUs (~$0.19/M) Enterprise — custom pricing, with lower per-unit costs at very high volumes Performance on Hyperliquid with Alchemy Alchemy runs a solid global setup for performance and uptime, which you can see reflected across its platform. One thing to note, though: they don’t publish Hyperliquid-specific performance data, so it’s hard to judge how it stacks up in practice. Uptime: ~99.9% historical uptime. Latency: global routing for consistent response times. Throughput: up to 300 RPS on free, scales higher with paid plans. Architecture: “Supernode” tech handles parallel requests through caching and load balancing. Pros & cons of Alchemy ProsConsGenerous free tier with 300M monthly CUsThe compute unit system can be confusing, and the free tier still caps throughput at about 330 CUs per secondLow per-unit cost, around $0.40–$0.50 per million beyond the free tierLacks Hyperliquid-specific tooling like order book websockets or custom data streams, and advanced monitoring sits behind enterprise pricingSolid developer experienceLimited regional control since endpoints are auto-routed rather than manually deployed by region While Alchemy doesn’t include Hyperliquid-specific tools, it’s still an easy way to get started and connect through a familiar setup. Pricing runs on compute units instead of raw requests, so costs can fluctuate if you’re sending a high number of simple calls. Quicknode Quicknode has recently added Hyperliquid to its lineup of supported chains. The provider runs on a globally distributed, auto-scaling network of RPC nodes, routing traffic to the closest region to keep latency low. Hyperliquid support covers the standard JSON-RPC methods for HyperEVM, with private endpoints over HTTP and WebSocket. Unlike platforms that bundle in extras like a faucet or Hyperliquid-specific monitoring, Quicknode keeps its offer focused on RPC delivery. The additional tooling available — Streams, Webhooks, and analytics APIs — is broader but geared more toward other networks in its stack rather than Hyperliquid itself. WebSockets and archive refer to HyperEVM by default. Check Quicknode docs for any HyperCore stream coverage. How much does Quicknode cost? Quicknode runs on a credit system across its monthly plans. It gives flexibility, but once your quota burns through, you’ll need to watch usage to avoid extra costs. With Quicknode, you get a free trial for one month, which includes 10 million credits at 15 RPS, but there’s no permanent free tier for Hyperliquid. Other paid plans available on the platform are: Build — $49/month, 80M credits, ~50 RPS Accelerate — $249/month, 450M credits, ~125 RPS Scale — $499/month, 950M credits, ~250 RPS Business — $999/month, 2B credits, ~500 RPS Overage runs around $0.50–$0.62 per million requests, depending on plan. Every plan includes access to Quicknode’s wider multi-chain stack, Streams for WebSocket feeds, archived data, and the developer dashboard. Performance on Hyperliquid with Quicknode Quicknode focuses on speed and uptime for Hyperliquid. That said, request-per-second limits are enforced per plan, so scaling heavy workloads may mean upgrading or spreading the load across endpoints. Uptime: 99.99% uptime on paid plans, with billing tied to availability. Latency: Low response times because of global routing and caching. Throughput: Capped by plan (50–500 RPS), so higher loads need larger tiers or multiple endpoints. Scale: Network handles 400B+ requests monthly across all supported chains. Hyperliquid tooling: unlike some providers, Quicknode does not offer Hyperliquid-specific extras such as a faucet or dedicated monitoring tools. Pros & cons of Quicknode ProsConsGlobal low-latency network with auto-routing to the nearest regionCredit-based pricing is complex, as some RPC methods consume more credits than others99.99% uptime on paid plans with 24/7 support channelsNo permanent free tier; access after trial requires paid planScales underlying infra during traffic spikes, up to ~400 RPS per endpoint on standard plansRPS limits per plan (50–500) can throttle high-frequency bots unless on higher tiers or multiple endpoints Quicknode delivers fast, globally routed Hyperliquid RPC with an SLA suited for production use, though its credit-based pricing can add complexity. A solid choice if you need scale and multi-chain tooling, but for Hyperliquid-specific features like faucets or dedicated monitoring, other providers fit better. How to get a Hyperliquid RPC There are several ways to connect to Hyperliquid, and the right RPC setup depends on your workload and performance requirements. If you want something reliable, quick to set up, and with extras like a faucet and archive data, Chainstack is a good place to start. You can spin up a private Hyperliquid RPC in minutes and start building right away in a few clicks: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Pick Hyperliquid as the network and choose mainnet or testnet. Deploy a node configured for RPC access. Once deployed, you’ll find your private RPC URLs, including /evm and /info, in the dashboard. Once your endpoint is live, HyperEVM behaves like any standard EVM JSON-RPC — for example, checking the latest block: curl -X POST https://YOUR_CHAINSTACK_ENDPOINT/YOUR_API_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 }' For more details, you can check our How to get a Hyperliquid RPC endpoint guide Conclusion The Hyperliquid RPC landscape in 2026 has matured into a competitive space shaped by production trading, automated strategies, and latency-sensitive applications. As real volume and on-chain execution scale, RPC infrastructure becomes a defining factor not only for reliability and execution quality, but also for enterprise-grade requirements like predictable performance, isolation, and operational stability. Chainstack offers the most balanced option overall, combining private HyperEVM and HyperCore access, predictable pricing, global and dedicated deployments, and a full set of Hyperliquid-specific tools. This makes it a strong fit for teams running trading bots, smart contracts, and production workloads that need consistent performance under sustained load. HypeRPC stands out for teams fully committed to Hyperliquid, prioritizing ultra-low latency and proximity to validators for live trading environments. Quicknode and Alchemy provide solid multi-chain platforms with familiar tooling, while dRPC and Dwellir offer alternative approaches for teams optimizing around cost, decentralization, or dedicated infrastructure. In 2026, choosing the right Hyperliquid RPC provider is less about basic connectivity and more about execution reliability at scale. Teams that invest early in stable, production-ready infrastructure are better positioned to operate as Hyperliquid continues to grow as a trading-first network. Trading bots and latency-sensitive execution: Chainstack or HypeRPC. Multi-chain teams already using Ethereum tooling: Alchemy or Quicknode. Cost-conscious testing and smaller projects: dRPC, or Chainstack’s free Developer tier. Isolated, dedicated infrastructure: Dwellir or Chainstack Dedicated Nodes. Recommended reading If you want to go deeper into the Hyperliquid ecosystem and start building production-ready trading systems, we also recommend checking out the following guides: What is Hyperliquid? — an overview of Hyperliquid’s architecture. How to build a Hyperliquid trading bot — a step-by-step guide to set up and wire a trading bot. Hyperliquid On-Chain Activity Tracker — build automated alerts with Hyperliquid RPC. Mastering Hyperliquid — guides to Hyperliquid APIs, authentication, and trading. Reliable Hyperliquid RPC infrastructure Getting started with Hyperliquid on Chainstack is fast and straightforward — deploy a reliable node in seconds through an intuitive console, no hardware or complex setup required. Private HyperEVM and HyperCore access Built-in faucet for testnet HYPE Archive data and WebSocket support 99.99% uptime SLA Deploy a private Hyperliquid RPC endpoint → FAQ What is a Hyperliquid RPC? A Hyperliquid RPC endpoint lets your app, bot, or contract talk directly to the Hyperliquid blockchain. It’s how you read on-chain data, submit transactions, or listen to live events through HyperEVM or HyperCore. Does Hyperliquid have a public RPC? Yes. Hyperliquid offers a free public RPC. Some methods — especially trading-related ones — are proprietary and available only there. Rate limits vary by method, with several capped near ~100 requests/min. What’s the difference between public and private RPCs? Public RPCs are shared and rate-limited. They also include proprietary HyperCore endpoints like l2Book, placeOrder, cancelOrder, and recentTrades that are not exposed by third-party providers. Private RPCs reserve bandwidth for you and cover HyperEVM plus non-proprietary HyperCore info, but they do not replace public-only DEX methods. Which Hyperliquid RPC provider is best? It depends on your use case. If you want a multi-chain platform with predictable pricing and extras like a faucet and archive data, Chainstack is a strong starting point. For specialized setups, other providers might fit specific workloads. How do I start testing on Hyperliquid? You can use Chainstack’s Hyperliquid faucet to grab HYPE tokens, deploy a testnet node, and connect through your private RPC URL in seconds, ideal for quick experiments before going live. Which Hyperliquid RPC providers are best for trading bots? The best Hyperliquid RPC providers for trading bots offer low latency, predictable throughput, and stable WebSocket connections. Providers like Chainstack and HypeRPC are commonly chosen for production trading workloads in 2026. #### Best MegaETH RPC providers for high-throughput apps Introduction MegaETH is one of the most infrastructure-sensitive networks to launch in the Ethereum ecosystem. It is an Ethereum-compatible Layer 2 designed for real-time applications, with 10 ms mini blocks, 1-second EVM blocks, and a throughput target above 100,000 transactions per second. That changes the usual RPC discussion. On slower EVM networks, a mediocre endpoint can still be “good enough” for many apps. On MegaETH, RPC quality quickly becomes a product-level constraint. Source: MegaETH Website That is because MegaETH is built for workloads that feel more like low-latency systems engineering than conventional blockchain backends: real-time trading, on-chain gaming, social applications, and high-frequency state updates. When a chain can move this quickly, your MegaETH RPC provider has to do more than answer eth_call reliably. It has to keep up with large request bursts, stable WebSocket subscriptions, fast transaction submission, and often more advanced debugging or dedicated-node requirements. MegaETH does provide a native public RPC. But the official docs also make the tradeoffs clear: methods are whitelisted, rate limiting is dynamic, and many debug, trace, and txpool methods are not available on the public endpoint. For teams building production systems, that is usually where a third-party MegaETH node provider becomes necessary. That is why most teams evaluating MegaETH RPC providers move from public endpoints to managed infrastructure early in development. MegaETH RPC providers comparison #ProviderFree PlanPricing ModelUptime / SLADev Experience1Chainstack3M req/mo, ~25 RPSRequest Units (1 RU standard, 2 RU archive);99.9% formal SLA doc; 99.99%+ on Global/Dedicated linesDashboard metrics, IP/origin access rules, archive, Chainbench, Compare Dashboard2RouteMeshNo dedicated free tierPer-request; Economy from $3/M, Performance from $6/MNo formal SLA; Replay/Lag data-quality checks insteadAggregates 20+ providers incl. Chainstack, 1,282+ chains, auto-failover3dRPC210M CU/30 days (public nodes)Flat-rate: 20 CU/request, $6 per 1M requestsHigh availability via multi-provider routing; no formal public SLASimple setup, OpenAI-compatible API, public status page, key control, front-end protection4Dwellir100K responses/day, 20 RPS, access to 140+ chainsFlat: 1 response = 1 credit (incl. trace & debug); Developer $49/mo (25M, 100 RPS); Growth $299/mo (150M, 500 RPS); Scale $999/mo (500M, 2,000 RPS)99.99% uptime SLA; multi-region redundancy; auto-failover & load balancing140+ chains (EVM, Substrate, Move, Cosmos); HTTPS & WebSocket; trace & debug APIs; autoscaling; dashboard with monitoring5Alchemy30M CUs/mo, ~25 RPSCompute Units by method weight; PAYG + monthly99.99% uptime claimed during peak; SLA formally on EnterpriseNotify & Transact APIs, Mempool streaming, MEV protection, real-time analytics dashboard, SDK support6QuicknodeTrial only (10M credits)API credits (method-weighted; e.g. eth_call = 20 credits)99.99% guaranteed, formal SLAStreams, Webhooks, OP-Node API, Trace API, marketplace add-ons (incl. DeFi integrations), team dashboards Use Cases for MegaETH Infrastructure On-chain games MegaETH is one of the few EVM environments where real-time game logic actually becomes practical on-chain. But gaming infrastructure has demanding requirements: fast state reads, stable event subscriptions, and consistent visibility during bursts of player activity. While shared public RPC endpoints may be sufficient for early testing, production games typically require a managed MegaETH RPC provider. Reliable WebSocket connections and predictable throughput are essential to keep gameplay responsive and prevent infrastructure bottlenecks as player activity scales. Start building gaming Infrastructure → Real-time trading and market infrastructure Trading systems on MegaETH depend on both fast reads and fast writes. Low-latency eth_call, current-state visibility, and reliable transaction submission matter far more than they do on slower chains. If you are routing large volumes of orders, liquidation attempts, or market-making updates, a provider with strong write-path reliability and isolated infrastructure quickly becomes worthwhile. Dedicated MegaETH nodes make sense once throughput rises and trading logic depends on consistently low-latency state updates. Explore Dedicated infrastructure → Social and speculative consumer apps MegaETH is a strong fit for consumer apps built around speed, feedback loops, and live participation. Social trading, prediction-driven experiences, viral apps, and attention markets all work better when user actions feel immediate and state updates are visible in real time. Shared public RPC may be enough to prototype, but consumer apps with growing engagement usually need infrastructure that can keep reads fast and subscriptions stable during sudden traffic spikes. That is where Chainstack Global Nodes are a strong fit, giving teams geo-balanced access, reliable performance, and the resilience needed to support real-time consumer experiences at scale. Launch consumer apps with Global Nodes → What to look for in a MegaETH RPC provider When comparing MegaETH RPC providers, the criteria shift compared to standard EVM networks. This is not a typical Ethereum mainnet or OP Stack evaluation—MegaETH’s performance profile exposes different bottlenecks, making latency, throughput, and real-time reliability far more critical. Latency is the first criterion. MegaETH is designed around real-time execution, so endpoint distance, routing quality, and queue behavior matter. On a chain with 10 ms mini blocks, the difference between a fast provider and a congested one is no longer academic. Throughput is next. MegaETH’s upside is that you can build applications that generate much larger request volumes than on slower chains. That means the right provider is one that remains stable under bursty read traffic and sustained write traffic, not just one that looks fine in a single-request benchmark. Uptime matters more than usual because real-time applications degrade badly when subscriptions fall behind or transaction forwarding becomes inconsistent. Low error rates, stable failover behavior, and predictable rate limiting are critical. Multi-region infrastructure is especially important for global applications. If your users, bots, or game clients are distributed across regions, a single-region endpoint can quietly become the weak point in an otherwise fast stack. Archive and debug APIs are another major differentiator. MegaETH’s public RPC does not expose the full debug and trace surface, so teams building analytics, transaction simulation, or advanced operational tooling should check this before committing. Dedicated nodes matter when shared infrastructure is no longer enough. If you are running a game backend, a trading system, or any application with aggressive burst traffic, shared RPC can become unpredictable even when the underlying chain is fast. Pricing model matters because MegaETH changes request economics. Credit- and CU-based pricing can become harder to forecast on high-throughput chains. Predictability becomes almost as important as raw price. Mini blocks and WebSocket subscriptions This is one of the most important differences between MegaETH RPC providers, especially for event-driven applications. MegaETH’s eth_subscribe behavior depends on what the provider exposes. On a standard EVM chain, subscribing to newHeads gives you one event per block — straightforward. On MegaETH, there are two layers: mini blocks (10ms, partial state updates) and full EVM blocks (1 second, complete state). If a provider only exposes newHeads at the EVM block level, your event-driven logic will fire once per second — not once per mini block. For a trading system or game backend built to take advantage of MegaETH’s speed, this is functionally equivalent to running on a 1-second chain. The 10ms advantage disappears at the subscription layer. Check whether your provider explicitly supports mini block subscriptions before building event-driven architecture on MegaETH. This is the kind of implementation detail that won’t show up in a benchmark but will directly shape what your application can do. One more MegaETH-specific point: the official docs note that MegaETH uses a multidimensional gas model, and local simulation may undercount gas. In practice, that makes RPC quality for eth_estimateGas, eth_call, and transaction confirmation more important than on many other EVM networks. Method coverage and advanced RPC access One important difference between MegaETH RPC providers is not the number of standard JSON-RPC methods, but how much of the extended method surface they expose. MegaETH’s public RPC intentionally restricts many advanced methods such as debug, trace, and txpool. As a result, providers that expose a broader method surface effectively unlock more advanced use cases, including transaction simulation, analytics, and infrastructure-level debugging. Best MegaETH RPC providers Below is a breakdown of the most relevant MegaETH RPC providers available today, based on infrastructure depth, latency behavior, and WebSocket support. 1. Chainstack Overview Chainstack is the strongest all-around option for MegaETH infrastructure right now. It supports MegaETH Mainnet on Global Nodes and Dedicated Nodes, and MegaETH Testnet on Dedicated Nodes. More importantly, its MegaETH documentation is unusually complete: HTTPS and WSS endpoints are documented, standard EVM tooling is supported, and the MegaETH method surface is broad enough to cover serious production use. 🤖 You can also access Chainstack MegaETH RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. That matters because MegaETH is not just another EVM chain with a public endpoint. It is a chain where real-time performance and method availability directly shape application design. Chainstack is the only provider in this comparison with a clearly documented MegaETH offering that combines shared access, dedicated nodes, WebSocket support, and broad debug/trace coverage. DetailsPricingDeveloper — free, 3M req/mo (~25 RPS). Growth — $49/mo, 20M req (~250 RPS). Pro — $199/mo, 80M req (~400 RPS). Business — $499/mo, 200M req (~600 RPS). Enterprise — from $990/mo, 400M+ req, custom RPS. Unlimited Node add-on from $149/mo flat. Dedicated Nodes — $0.50/hr compute. Crypto payments accepted.Billing modelRequest Units: 1 RU per standard call, 2 RU per archive or debug/trace call. No method-weight multipliers.Uptime / SLAFormal SLA document: 99.9% minimum with service credits. Product positioning on Global/Dedicated lines: 99.99%+. Public status page available.SecuritySOC 2 Type II and ISO 27001 certified. Security materials accessible via security page.Archive / debugFull debug and trace method coverage available.WebSocketHTTPS and WSS endpoints available.MegaETH TestnetAvailable on Dedicated Nodes. Pros: Transparent RU billing, Dedicated Nodes for MegaETH, full archive + debug/trace, SOC 2 Type II and ISO 27001, broad method coverage including eth_getBlockReceipts and txpool, EVM tooling support, Unlimited Node add-on, 70+ chains. Cons: Free tier tight for high-frequency workloads; Dedicated Nodes require at least Pro plan; fixed RPS per tier means ultra-high-frequency apps may need Dedicated from day one. 2. RouteMesh Overview RouteMesh is an RPC aggregation and routing layer rather than a node operator itself. It routes requests across 20+ upstream providers, including Chainstack, and 1,282+ chains, including MegaETH, with automatic retries and failover built in. Instead of running its own MegaETH infrastructure, RouteMesh’s value is picking the best available upstream route per request and catching bad data before it reaches your app. DetailsPricingPer-request, billed monthly. Economy keys from $3 per 1M requests; Performance keys (lowest-latency routing) from $6 per 1M requests. No minimum commitments or hidden fees.Billing modelPriced by chain, method, and key type — price adjusts dynamically with the set of upstream providers available for that route.Uptime / SLANo formal published SLA. Reliability comes from routing across multiple upstream nodes with automatic failover, plus Replay Checks (cross-node data consistency) and Lag Checks (freshness) to filter out lagging or incorrect nodes.SecurityNot explicitly documented at time of writing.Archive / debugDepends on the upstream provider selected for a given route; not separately documented for MegaETH.WebSocketNot explicitly documented for MegaETH.MegaETH TestnetNot explicitly documented. Pros: No vendor lock-in to a single node operator, per-request pricing with no minimums, automatic multi-provider failover, built-in data-quality checks (Replay/Lag) that most aggregators don’t publish. Cons: Not a MegaETH-specific infrastructure provider — it aggregates other operators rather than running dedicated MegaETH nodes; no formal SLA; dedicated-node and testnet support not documented for MegaETH specifically. 3. dRPC Overview dRPC supports MegaETH through its NodeCloud platform with both free and paid access. Its main value proposition is predictability: flat-rate pricing, multi-region routing, and managed failover. dRPC is especially attractive for teams that want global RPC access without running their own infrastructure and do not want their costs distorted by method-weight multipliers. The main limitation is that dRPC’s MegaETH public materials are less explicit than Chainstack’s about dedicated MegaETH node patterns. It is strong as a managed multi-region RPC layer, but not the most complete MegaETH-specific infrastructure story in this comparison. DetailsPricingFree — 210M CU/30 days (public nodes only). Paid — PAYG with deposit, flat-rate: 20 CU per request, $6 per 1M requests. “Go unlimited” option available.Billing modelFlat-rate per request — no method-weight multipliers. Predictable cost regardless of call composition.Uptime / SLAHigh availability through multi-provider routing. Public status page available. No formal published SLA.SecurityNo publicly documented SOC 2 certification at time of writing.Archive / debugNot explicitly documented for MegaETH.WebSocketAvailable through NodeCloud.MegaETH TestnetNot explicitly documented. Pros: Flat-rate pricing (no method surprises), most generous free tier, multi-provider redundancy, OpenAI-compatible API, no vendor lock-in. Cons: No formal SLA; no SOC 2 certification; less explicit MegaETH-specific documentation; dedicated node patterns not clearly documented; performance consistency varies across distributed provider network. 4. Dwellir Overview Dwellir is one of the more interesting MegaETH options for teams that care about simple pricing and explicit multi-region operations. It lists MegaETH mainnet HTTPS and WSS endpoints, advertises 99.99% uptime SLAs, and positions itself around a simple billing model: 1 response = 1 credit. It also offers Dedicated Clusters in its wider infrastructure product line. For MegaETH specifically, that pricing simplicity is meaningful. High-throughput applications tend to punish complex CU math, and Dwellir’s flat model removes that variable entirely. DetailsPricingDeveloper — $49/mo, 25M responses, 100 RPS. Growth — $299/mo, 150M responses, 500 RPS. Scale — $999/mo, 500M responses, 2,000 RPS. Free tier: 100K responses/day at 20 RPS.Billing model1 response = 1 credit, regardless of method. Trace and debug calls count the same as standard calls.Uptime / SLA99.99% uptime SLA; multi-region redundancy; auto-failover and load balancing.SecurityNot explicitly documented at time of writing.Archive / debugTrace and debug APIs included across plans.WebSocketHTTPS and WSS endpoints available.MegaETH TestnetNot explicitly documented. Pros: Simple flat pricing including trace/debug, 99.99% uptime SLA, multi-region redundancy, 140+ chains, high RPS ceiling on Growth and Scale plans. Cons: Smaller ecosystem than Chainstack or Quicknode; security certification not publicly documented; less MegaETH-specific documentation depth; Dedicated Clusters not prominently featured for MegaETH specifically. 5. Alchemy Overview Alchemy supports MegaETH with both RPC and WebSocket endpoints and treats MegaETH as a standard JSON-RPC network inside its broader developer platform. That makes it attractive for teams already standardized on Alchemy’s SDKs, dashboards, and operational tooling. The tradeoff is that Alchemy’s public MegaETH positioning is more about developer platform integration than chain-specific infrastructure differentiation. It clearly supports MegaETH, but it is less explicit than Chainstack or Quicknode about dedicated MegaETH node patterns. DetailsPricingFree — 30M CUs/mo (~25 RPS). Pay-as-you-go — $5 per 11M CUs. Enterprise — custom with volume discounts. Method-weighted pricing applies.Billing modelCompute Units: method-weighted. Bill depends on call composition, not just volume. Requires tracking method mix for accurate budget modeling.Uptime / SLA99.99% uptime claimed during peak market conditions; global infrastructure with automatic failover. Formal SLA on Enterprise plans.SecuritySOC 2 Type II certified; no published ISO 27001 certification; public trust center available.Archive / debugArchive and debug access available on paid plans; method coverage for MegaETH not explicitly documented in public docs at time of writing.WebSocketWSS endpoints available.MegaETH TestnetAvailable. Pros: SOC 2 Type II, broad SDK and platform tooling (Notify, Transact, Mempool APIs), MEV protection, 40+ chains, rich analytics, strong developer experience for teams already on Alchemy. Cons: CU pricing requires careful method-mix tracking; less explicit about dedicated MegaETH node patterns; billing less predictable at scale; very high RPS requires Enterprise plan. 6. Quicknode Overview Quicknode is a strong commercial option for teams that want MegaETH support with both shared endpoints and isolated enterprise infrastructure. Quicknode documents HTTP and WSS MegaETH endpoints, and its MegaETH docs explicitly include Debug API and Trace API sections. On the enterprise side, it offers Dedicated Clusters, positioned as isolated, redundant infrastructure for higher-scale workloads. Quicknode’s MegaETH product is well suited to teams that want more than basic node access and are already comfortable with a credit-based RPC model. DetailsPricingBuild — $49/mo, 80M credits, 50 RPS. Accelerate — $249/mo, 450M credits, 125 RPS. Scale — $499/mo, 950M credits, 250 RPS. Business — $999/mo, 2B credits, 500 RPS. Enterprise — custom. Credits roll over.Billing modelAPI credits, method-weighted. Call composition directly affects cost.Uptime / SLA99.99% formally guaranteed on paid plans; enterprise SLA available.SecuritySOC 2 Type II + SOC 1 Type 2 + ISO 27001.Archive / debugDebug API and Trace API sections documented for MegaETH.WebSocketHTTP and WSS endpoints documented.MegaETH TestnetNot explicitly documented. Pros: 99.99% formal SLA, SOC 2 Type II + ISO 27001, Debug and Trace API for MegaETH, Dedicated Clusters, Streams/Webhooks, strong commercial positioning for wallets and DeFi. Cons: No free tier (trial only); method-weighted credits make cost modeling complex on high-throughput chains; no flat-rate unlimited option for burst-heavy workloads. Which MegaETH RPC provider should you choose? If you are just testing contracts, verifying network behavior, or building an internal prototype, the native MegaETH public RPC is usually enough. It gives you direct chain access and works well for low-volume development. For production applications, managed RPC providers become the default choice. This is where differences between providers start to matter. Chainstack is the most complete option in this comparison, covering both shared and dedicated MegaETH infrastructure with broad method support and production-ready reliability. It is particularly strong for teams building real-time applications that need consistent performance and a clear scaling path. Quicknode is a strong alternative for teams already operating within a credit-based model and looking for additional ecosystem tools such as Streams and Webhooks, especially for analytics-heavy or event-driven architectures. Alchemy fits best for teams already integrated into its developer platform. It offers a smooth experience with strong tooling and SDK support, but is less focused on MegaETH-specific infrastructure depth. Dwellir stands out for its simple and predictable pricing model. It is a practical option for teams that want to control costs on high-throughput workloads without dealing with method-weighted pricing. dRPC is best positioned as a managed multi-region RPC layer with flat pricing and built-in routing. It works well for teams that want global coverage without managing infrastructure, though it is less focused on deep MegaETH-specific features. Overall, most teams will benefit from a provider that can handle both early-stage development and production workloads without requiring a migration later. In that context, Chainstack stands out as the most complete all-around MegaETH RPC provider, covering the full range of use cases from prototyping to high-throughput production systems. Getting started with MegaETH on Chainstack Chainstack bundles shared and dedicated MegaETH access into a setup that takes minutes to deploy: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Choose MegaETH, then pick Mainnet on Global or Dedicated Nodes, or Testnet on Dedicated Nodes. Deploy a node and copy the HTTPS or WSS endpoint into your app. Once your endpoint is live, MegaETH behaves like a standard EVM JSON-RPC network — for example, checking the latest block: curl -X POST https://YOUR_CHAINSTACK_ENDPOINT/YOUR_API_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 }' Conclusion MegaETH changes what developers should expect from RPC infrastructure. A chain built for 10 ms mini blocks, high throughput, and real-time applications puts more pressure on endpoint latency, WebSocket stability, and method availability than a conventional EVM network. For low-volume testing, the native public RPC is enough. But once you move into production workloads such as gaming, trading, or high-volume consumer apps, a managed MegaETH RPC provider is the safer choice. And when traffic becomes latency-sensitive or burst-heavy, dedicated infrastructure becomes the practical next step. For most teams, Chainstack is the strongest all-around MegaETH RPC provider in 2026. It combines shared and dedicated MegaETH support, WebSocket access, broad method coverage, and a clear path from prototype to production infrastructure. Deploy a MegaETH RPC endpoint → FAQ What is a MegaETH RPC provider? A MegaETH RPC provider gives your application access to MegaETH nodes over JSON-RPC, usually through HTTPS and WebSocket endpoints. In production, providers are used to improve reliability, scaling, and operational stability beyond what public RPC can offer. Is the public MegaETH RPC enough for production? Usually not. MegaETH’s official RPC documentation shows dynamic rate limiting based on compute usage and bandwidth, and several methods are unavailable on the public endpoint, including eth_subscribe, eth_getBlockReceipts, debug_*, trace_*, and txpool_*. That makes public RPC useful for testing, but limited for real-time production apps. Do I need WebSocket support for MegaETH? For many applications, yes. If you rely on real-time event streams, confirmation tracking, or state-driven UX updates, WebSocket support is important. This is especially true for trading systems, gaming backends, and event-heavy applications. When should I use a dedicated MegaETH node? Use a dedicated node when shared RPC starts to introduce latency variance, subscription instability, or throughput bottlenecks. Dedicated infrastructure is usually justified for high-frequency trading, high-throughput gaming, and other workloads with sustained or burst-heavy traffic. Which MegaETH RPC providers are best for high-throughput applications? For most high-throughput workloads, Chainstack is the strongest option thanks to dedicated MegaETH infrastructure, stable WebSocket subscriptions, and broad method support.Quicknode is a solid alternative for teams using a credit-based model and building event-driven systems. Dwellir fits high-throughput workloads where predictable, flat pricing matters more than platform features. What should I compare before choosing a MegaETH node provider? Focus on latency, throughput behavior under load, uptime, WebSocket support, debug/trace availability, dedicated-node options, and pricing predictability. On MegaETH, method support and request economics matter more than they do on slower EVM chains. Additional resources MegaETH methods MegaETH Chainstack tooling How to get a MegaETH RPC endpoint #### Best Polygon RPC providers for high-throughput apps in 2026 Polygon remains one of the most practical chains for production apps in 2026 not just because it is cheap and EVM-compatible, but because transaction demand is clearly still there. Daily transaction volume on Polygon PoS has climbed sharply, with the network closing Q2 2026 with an all-time-high 743 million transactions, which reinforces its role as a live execution layer for stablecoin transfers, payment rails, gaming backends, consumer apps, and bots. Even as newer L2s compete for attention, Polygon continues to combine real usage, low costs, and mature tooling in a way that makes it operationally relevant for production workloads. That is exactly why your choice among Polygon RPC providers matters more than most developers initially realize. On Polygon, the bottleneck is almost never “can I get an RPC URL.” The real question is whether that endpoint stays fast and reliable when traffic spikes, when event subscriptions pile up, or when a bot starts backfilling logs at scale. High-throughput apps do not just need a provider that works in a benchmark demo. They need one that keeps latency stable, exposes the right method surface, and does not become unpredictable under sustained load. This guide breaks down the leading Polygon RPC providers for production workloads in 2026—with a specific focus on stablecoin and payment flows, enterprise deployments, and analytics-heavy or dedicated-node environments. 🤔 Already using Chainstack? Jump straight to the Polygon tooling docs or the Polygon getting started reference to deploy your endpoint in minutes. Testing on Amoy? Grab free test tokens from the Chainstack Amoy faucet. Why Polygon RPC provider choice matters for production In a development environment, almost any Polygon RPC provider will do. But in production—where a stablecoin payment app sees sharp spikes around balance checks and transaction confirmations, or where a trading bot needs consistent low-latency state access—the difference between providers becomes operationally significant. The key factors that separate production-grade Polygon RPC providers from basic public endpoints are: Throughput stability under load, not just average latency in quiet conditions WebSocket support for subscriptions and real-time event tracking Archive, debug, and trace access for indexers, analytics pipelines, and historical queries Dedicated node options when shared infrastructure introduces too much noise Clear SLA commitments for payment systems, regulated products, and enterprise workloads Pricing transparency so cost does not become unpredictable as traffic scales The comparison below focuses on exactly these criteria across six leading Polygon RPC providers—evaluated for real production conditions, not sandbox demos. Polygon RPC providers comparison table (2026) The table below summarizes the public positioning of six Polygon RPC providers as of March 2026. Where providers reserve details for enterprise sales, the table reflects only what is publicly documented. ProviderPricing modelFree tierDedicated nodesArchive / debug / traceSLA & securityChainstackRequest-based plans with optional flat-rate RPS add-on3M RU/month, 25 RPSYes, on paid plansArchive on paid tiers; debug/trace on advanced setups99.99%+ uptime; formal SLA on paid plans; SOC 2 Type II and ISO 27001OnFinalityResponse-unit based, unified tiers400K RU/day, up to 40 RU/secYes, pay-as-you-goArchive on every plan; trace/debug on paidNo formal SLA published; security certs not documentedAnkrAPI-credit pricing across Freemium, Premium, and Enterprise tiers200M API credits/month after sign-inPremium private endpoints and enterprise infrastructure, but no clearly positioned dedicated Polygon node productFull archive; trace/debug on Premium99.99% uptime; SOC 2 Type 2 (2025)dRPCFlat-rate request pricing on paid tierFree public access (public nodes, no SLA)No clearly documented dedicated Polygon node tier in public materialsStandard methods; paid-tier trace/filterHigh-availability positioning; no clear public SLA or SOC 2 foundAlchemyCompute-unit pricing with free, PAYG, and enterprise scaling30M CUs/monthEnterprise/custom infrastructure, but no clearly marketed dedicated Polygon node tier in public docsFull archive; Debug and Trace API on PAYG and Enterprise99.99% uptime; enterprise custom SLAs; SOC 2 Type II (no published ISO 27001)QuicknodeCredit-based plans with optional Flat Rate RPS and dedicated enterprise optionsTrial only — 10M API credits for 30 daysYes, Dedicated Clusters availableArchive, Debug API, Trace API, Polygon-specific APIs99.99% uptime; formal SLA on paid tiers; SOC 1/2 Type 2, ISO 27001 How to choose a Polygon RPC provider 1. Shared RPC is often enough for moderate traffic If your app has steady but moderate traffic, shared RPC is often sufficient. This applies to dashboards, wallet backends, light bot infrastructure, and consumer apps that read chain state frequently but do not depend on heavy archive queries or strict latency guarantees. In this range, what matters most is a clean pricing model, stable WebSocket support, and reasonable default throughput. 2. Dedicated infrastructure starts to matter when your app becomes operationally sensitive That threshold is usually crossed in three scenarios: Payment or stablecoin traffic with bursty reads and writes Bots that depend on consistent low-latency state access, where jitter from shared infrastructure creates operational risk Indexers running long backfills or traces, where a noisy shared endpoint can corrupt the consistency of your data pipeline Once traffic becomes burst-heavy or sustained, shared RPC can become noisy even if average latency still looks fine on a dashboard. 3. Archive, debug, and trace access matters for analytical workloads If your workload is not just transactional but analytical—replaying historical state, indexing large event ranges, tracing smart contract execution, or supporting internal observability—you need more than a standard full-node endpoint. Archive data access, debug_traceTransaction, trace_block, and long-range eth_getLogs behavior become more important than free-tier size. 4. Latency consistency matters more than average latency for real-time workloads Average latency is a misleading metric for latency-sensitive applications. What breaks DeFi execution layers, real-time event listeners, keeper networks, and live price feeds is not average response time — it is tail latency and jitter. A provider that averages 40ms but occasionally spikes to 800ms under load will fail production workloads that depend on reacting to chain state within a narrow window. For these workloads, the relevant criteria are: WebSocket connection stability under sustained subscription load, consistent p95 and p99 latency rather than just p50, and a provider architecture that does not introduce shared-infrastructure noise during peak network activity. Dedicated nodes remove the noise floor entirely, which is why latency-sensitive applications are often the first to outgrow shared RPC — even when average metrics still look acceptable. 5. Enterprise support matters when Polygon is part of a regulated product Stablecoin apps, payment rails, treasury systems, and institutional middleware usually need more than a performant endpoint. They need a clear SLA, a defined security posture, access controls, and support quality that does not depend on a Discord thread. At this level, your Polygon RPC provider becomes part of your risk model. Choose the right Polygon RPC provider by use case For stablecoin and payment apps Source: Defiliama Payment applications on Polygon need a different kind of reliability than general-purpose dApps. The core requirement is not exotic RPC methods. It is consistent low-latency reads, clean transaction submission, and stable performance during bursty traffic. Payment systems create sharp spikes around balance checks, transaction confirmations, webhooks, and reconciliation. A provider that looks inexpensive for casual usage can still become a liability in production—because payments fail operationally long before they fail cryptographically. The strongest criteria here are: predictable throughput, clear uptime, and pricing that does not become opaque when traffic becomes repetitive but heavy. Chainstack stands out because its request-based pricing is easier to reason about than CU-heavy alternatives, and because it offers a clear upgrade path from shared Polygon RPC to dedicated infrastructure. Ankr is also credible for cost-sensitive payment applications, especially where Premium endpoints and WebSockets are sufficient. Alchemy is strong if the payment stack already depends on its broader platform products, but its compute-based billing model is less intuitive for teams that want straightforward cost forecasting. Explore stablecoin-ready infrastructure → For enterprise workloads Enterprise Polygon workloads are less about raw throughput and more about operational assurance. The questions shift from “does it respond fast?” to “is there a contractual uptime model, do we have clear support paths, and does the provider pass our internal security review?” For enterprise teams, the critical criteria are: Publicly available or negotiable SLA terms Clear security posture (SOC 2, ISO certifications) Dedicated or isolated infrastructure options Multi-region resilience Support quality that does not degrade when you escalate a P1 incident Quicknode is strong here because it combines formal security credentials (SOC 1 Type 2, SOC 2 Type 2, ISO 27001) with dedicated cluster options and a mature platform surface. Alchemy is also compelling for enterprise teams already embedded in its ecosystem. Chainstack is a serious contender for teams that want a direct path to dedicated nodes, transparent pricing logic, and SOC 2 Type II and ISO 27001-backed infrastructure—without navigating a complex enterprise procurement process just to get meaningful throughput. Request enterprise plan → For DeFi, analytics, and indexers DeFi and analytics workloads stress a Polygon RPC provider differently from payment or bot traffic. They care less about single-request latency and more about whether the provider can survive long-running historical reads, event backfills, trace calls, and archive-heavy access patterns without collapsing into throttling or returning inconsistent results. A cheap endpoint can look fine until it has to serve eth_getLogs across large block windows, replay transactions, or support indexing jobs that run continuously for hours. Chainstack and Quicknode are the strongest fits here based on publicly documented feature sets. Chainstack has the clearest path to a dedicated Polygon RPC node and production-oriented node control. Quicknode is strong on archive, trace, and marketplace-style platform depth. Alchemy remains viable for analytics-heavy teams, especially those already familiar with its Debug and Trace APIs, but method-weighted cost behavior needs closer modeling at scale. Request Dedicated node → Polygon RPC providers: breakdown by provider Chainstack High-throughput apps, bots, and payment systems on Polygon RPC node infrastructure often graduate into dedicated capacity as traffic grows. Chainstack has the cleanest production path in this comparison. It offers a free shared tier for entry, request-based billing that is easier to forecast than CU-heavy alternatives, and dedicated Polygon nodes for teams that outgrow shared endpoints. It also publicly emphasizes archive access, WebSockets, enterprise support, and SOC 2 Type II and ISO 27001 compliance. 🤖 You can also access Chainstack Polygon RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. Pricing & throughput: Developer plan is free (3M RU/month, 25 RPS). Growth starts at $49/mo (20M RU, 250 RPS). Pro at $199/mo (80M RU, 400 RPS). Business at $499/mo (200M RU, 600 RPS). Enterprise at $990/mo (400M RU, unlimited RPS). Overage rates drop from $20/1M RU on Developer to $5/1M RU on Enterprise. The Unlimited Node add-on converts any node to flat-fee, unlimited requests within a chosen RPS tier (25–500 RPS) — no per-request billing, no overage exposure. See Chainstack pricing tiers here → For teams that care about predictable cost and a direct move into isolated infrastructure, that is a practical advantage over providers where dedicated nodes are available only through opaque enterprise sales processes. Limitations: Compared with Alchemy and Quicknode, Chainstack has fewer add-on platform abstractions around notifications, indexed APIs, or broader middleware products. If your team wants a provider that also acts as an application-data platform, that may matter. Fit by workload: Stablecoin and Payment Apps: Excellent — request-based pricing and dedicated-node upgrade paths are straightforward to operationalize Enterprise Polygon Workloads: Strong — SOC 2 Type II and ISO 27001, reliable public uptime positioning, dedicated infrastructure Dedicated Nodes, Analytics, and Indexers: Strongest in this comparison — clearest path to dedicated Polygon access without building your own node operations stack OnFinality OnFinality provides EVM-compatible HTTPS and WebSocket RPC access to Polygon PoS Mainnet and the Amoy testnet, with archive access included on every plan and Trace/Debug APIs on paid tiers. Pay-as-you-go dedicated Polygon nodes are available for teams that need isolated infrastructure. How much does it cost?Developer — free, 400,000 response units/day, up to 40 RU/sec.Growth — $49/month, 20M response units/month, no daily cap, 200 RU/sec, $6/million extra.Accelerate — $249/month, 100M response units/month, 500 RU/sec, $3.75/million extra.Ultimate — custom pricing, custom throughput, crypto payments accepted.PerformancePublic rate limit: 5 req/sec.Private rate limit: up to 500 RPS.Archive: included on every plan, including Free.Region: N. Virginia.Dedicated nodes: pay-as-you-go, for isolated capacity.Pros– Archive access on every plan, including Free– Trace/Debug APIs on paid plans– Pay-as-you-go dedicated nodes on all tiersCons– Public free-tier rate limit (5 req/sec) is tight without upgrading– Trace API not available on the Free plan– Security certifications not explicitly documented Ankr Pricing & throughput: Freemium includes 200M API credits/month but caps at 30 RPS. Premium PAYG is advertised at $0.10/1M API credits — but each eth_call costs ~200 Ankr credits, making the effective rate closer to $20/1M actual requests. Premium scales to 1,500 RPS. The generous free credit allowance makes Ankr attractive for moderate-volume apps, but cost modeling on heavier method mixes requires careful attention to the credit multiplier. Ankr clearly separates Public, Freemium, Premium, and Enterprise service levels. It supports HTTPS and WebSocket access, archive data, and Premium-only trace/debug methods. It also publishes concrete rate-limit and block-range guidance, which is practical for teams planning around operational limits. Ankr announced SOC 2 Type 2 compliance in 2025. Limitations: The Polygon offering is more “platform with Premium private endpoints” than a clearly marketed dedicated Polygon node product. That is fine for many teams but less ideal if you explicitly need isolated infrastructure with dedicated-node semantics. Fit by workload: Stablecoin and Payment Apps: Strong, especially for cost-aware teams that need Premium-level throughput and WebSockets Enterprise Polygon Workloads: Viable, but not as cleanly packaged as Chainstack or Quicknode for enterprise Polygon isolation Dedicated Nodes, Analytics, and Indexers: Usable on Premium, but less cleanly positioned than providers with explicit dedicated-node products dRPC Pricing & throughput: The clearest pricing model in this comparison — $6/1M requests flat, with 20 CUs per call regardless of method. No multiplier math, no per-method surprises. Paid tier scales to 5,000 RPS, the highest ceiling among the shared, non-dedicated tiers in this comparison. The free public tier routes through public nodes with no SLA guarantees, making it unsuitable for production. dRPC’s value proposition is clear: multi-chain access, WebSocket support, flat-rate request pricing, and distributed routing. Its Polygon documentation exposes standard chain info, subscriptions, and paid-tier trace methods. Limitations: dRPC is the weakest of the six for dedicated Polygon workloads. Public materials do not clearly describe a Polygon-specific dedicated-node tier. Security and compliance language is also less explicit in public documentation than with the other four providers. Fit by workload: Stablecoin and Payment Apps: Acceptable for cost-sensitive setups, but weaker when strict support, compliance, or dedicated capacity are required Enterprise Polygon Workloads: Weakest fit — limited public enterprise and compliance detail Dedicated Nodes, Analytics, and Indexers: Fine for standard workloads, but not the best choice for heavy archive, debug, or indexing requirements. Alchemy Pricing & throughput: Free tier includes 30M CUs/month. Paid tiers start with PAYG at around $0.45/1M CUs (dropping to $0.40/1M after 300M/month). The important caveat: each eth_call consumes ~26 CUs, heavier methods more. This means effective cost per actual request is higher than the headline CU rate suggests. Shared plans scale to 300 RPS; higher throughput requires Enterprise. Alchemy supports Polygon with RPC, WebSockets, full archive access, and Debug/Trace APIs on paid plans. Its platform also includes analytics, webhooks, and a familiar SDK environment. For product teams already standardized on Alchemy, the operational convenience can outweigh raw request-cost simplicity. Limitations: The compute-unit pricing model is workable but less intuitive than request-based billing, especially for workloads that use heavier methods or high-volume subscriptions. Dedicated Polygon infrastructure is also less explicitly positioned in public materials compared to Chainstack or Quicknode. Fit by workload: Stablecoin and Payment Apps: Good when the broader Alchemy platform is already part of the stack Enterprise Polygon Workloads: Strong through custom throughput, enterprise support, and SOC 2 Type II Dedicated Nodes, Analytics, and Indexers: Viable, but cost predictability needs closer review Quicknode Pricing & throughput: No free plan — trial only (10M credits, 30 days). Build at $49/mo gives 80M credits and 50 RPS. Accelerate at $249/mo (450M credits, 125 RPS). Scale at $499/mo (950M credits, 250 RPS). Business at $999/mo (2B credits, 500 RPS). Each standard EVM call costs 20 API credits; heavier methods like trace calls consume more. Overage rates range from $0.50–$0.62/1M credits depending on plan. Quicknode’s Polygon documentation is among the most explicit in this set. It covers archive access, Debug API, Trace API, Polygon-specific methods, HTTP and WebSocket endpoints, and dedicated infrastructure paths. Flat Rate RPS is useful for teams that want more predictable billing without jumping immediately to dedicated clusters. Security posture is strong, with SOC 1 Type 2, SOC 2 Type 2, and ISO 27001 publicly stated. Limitations: The pricing model can still be harder to forecast than simpler request-based providers, especially for workloads that mix standard methods, traces, subscriptions, and higher-cost calls. Flat Rate RPS runs on shared infrastructure and does not include dedicated isolation or SLA guarantees. Fit by workload: Stablecoin and Payment Apps: Good, especially if predictable RPS billing or enterprise controls matter Enterprise Polygon Workloads: One of the strongest — compliance posture and dedicated cluster availability Dedicated Nodes, Analytics, and Indexers: Very strong — documented archive, debug, and trace support Final recommendations For stablecoin and payment apps: The best Polygon RPC provider is Chainstack. It combines predictable request-based pricing, solid WebSocket support, and a clean upgrade path to dedicated infrastructure when payment traffic stops behaving like normal app traffic and starts behaving like production finance. For enterprise Polygon infrastructure: The strongest options are Quicknode and Chainstack, with Alchemy close behind for teams already committed to its broader platform. Quicknode leads on public compliance posture and enterprise packaging. Chainstack leads if you want dedicated Polygon nodes with simpler cost logic and a direct path to isolated infrastructure. For DeFi, analytics, and indexers: The best Polygon RPC provider is Chainstack, with Quicknode as the closest alternative. Both are well-suited to archive, trace, and higher-intensity Polygon operations. Alchemy is still viable here, but teams should model cost behavior carefully before committing at scale. Conclusion For Polygon in 2026, choosing between Polygon RPC providers means selecting the infrastructure layer that will quietly determine your system’s reliability, cost predictability, and operational resilience. Polygon’s continued relevance as a low-cost EVM execution layer for stablecoin payments, gaming, and consumer apps means the stakes for infrastructure decisions are higher than they appear. Payment platforms need throughput stability and clean billing under bursty traffic. Bot operators need consistent low-latency state access and reliable WebSocket subscriptions. DeFi, analytics, and indexing pipelines need archive depth and trace access that holds up under sustained load. Chainstack covers all three — predictable request-unit pricing, SOC 2 Type II and ISO 27001, full archive and debug access, dedicated node infrastructure, and a managed environment that does not surprise you at scale. For teams where Polygon RPC is foundational rather than incidental, it is the most complete option in 2026. Deploy your Polygon RPC endpoint on Chainstack → FAQ What is a Polygon RPC provider? A Polygon RPC provider is a service that gives your application an API endpoint to interact with the Polygon blockchain. Rather than running your own full node—which requires significant infrastructure overhead—you connect your app, bot, or smart contract tooling to the provider’s node infrastructure via JSON-RPC over HTTP or WebSocket. The provider handles node uptime, syncing, and scaling. What is the difference between a shared and a dedicated Polygon RPC node? A shared Polygon RPC endpoint means your requests are processed on infrastructure shared with other customers. This is cost-effective for most apps. A dedicated node means you get isolated infrastructure—no other customers share your compute or bandwidth. Dedicated nodes matter when traffic is burst-heavy, latency needs to be consistent under load, or you need to run archive or trace calls without competing for resources. What is archive access and why does it matter for Polygon? Archive access means the node stores the complete historical state of the blockchain, not just the most recent block. Without it, you cannot query historical account balances, replay transactions, or run eth_getLogs across large ranges. Most production analytics, indexing, and compliance workloads require archive access. Not all Polygon RPC providers include it on their base tier—check before committing. Is there a free Polygon RPC provider for testing? Yes. Chainstack offers 3M requests/month on its Developer plan. Alchemy offers 30M CUs/month free. Ankr has a Freemium tier with 200M API credits/month. Quicknode offers a 30-day trial. For testnet development on Amoy, you can also use the Chainstack Amoy faucet to get test MATIC without spending mainnet funds. Does Polygon RPC work with standard Ethereum tooling like ethers.js and web3.py? Yes. Polygon PoS is EVM-compatible, so standard Ethereum libraries like ethers.js, web3.py, viem, and Foundry work with Polygon RPC endpoints with minimal configuration changes—typically just swapping the RPC URL and chain ID. Chainstack’s Polygon tooling docs cover integrations with the most common libraries and frameworks. What is the difference between HTTP and WebSocket for Polygon RPC? HTTP (or HTTPS) is the standard request-response model: your app sends a call and waits for a reply. It works well for most read and write operations. WebSocket provides a persistent, bidirectional connection that is better suited for real-time use cases like subscribing to new blocks, pending transactions, or event logs. For bots, payment listeners, and live dashboards, WebSocket support from your Polygon RPC provider is essential. Related reading Public Polygon RPC: complete endpoint catalogue How to get a Polygon RPC Endpoint in 2026 Polygon’s Second Life as Payments Infrastructure Build a Polymarket Trading Bot Using OpenClaw on Chainstack #### Best Solana RPC providers for fast and reliable production in 2026 Solana dominated 2025 with 33B transactions — leading ALL blockchains and driving massive demand for high-throughput, low-latency RPC infrastructure. With record-breaking transaction volume across stablecoin transfers, on-chain finance, and real-time analytics, placing extreme pressure on RPC providers to deliver resilient infrastructure. Each project has different priorities — some need low latency, others cost efficiency, throughput guarantees, or streaming data access via Yellowstone gRPC. In this benchmark, we compare the best Solana RPC providers in 2026 across speed, uptime, pricing, and data tooling. We focus on three critical Solana use cases — stablecoin payments, enterprise-grade workloads, and real-time data streaming with Trader Nodes — to see how each provider performs under production conditions. Top providers comparison Solana RPC providers differ not just in pricing, but in how they handle latency, throughput, uptime guarantees, and developer tooling. Here’s how the top providers compare in 2026: #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow latency global routing with 99.99%+ uptimeComprehensive docs, dashboard metrics, Access Rules, ShredStream-enabled endpoints, and advanced tooling including Yellowstone gRPC Geyser plugin support2OnFinality400K RU/day, 40 RU/sec, archive accessGrowth $49/mo (20M RU, 200 RU/sec); Accelerate $249/mo (100M RU, 500 RU/sec); Ultimate customNo published SLA on free/public tiersDedicated Nodes, archive, WebSocket subscriptions, 24/7 support on dedicated tier3UniblockFree tier available (compute-unit based)Unified pricing across 300+ chains via 55+ underlying providersNot documented specifically for SolanaSingle API and single invoice across 300+ chains; Unified APIs (token/NFT/market data) layered on raw RPC4Helius1M credits/mo, 10 RPS$49–$999/mo credit-based tiers, 50–500 RPS; enterprise offers custom RPSLow-latency Solana routing with staked RPC; no public SLASolana-native APIs, webhooks, NFT and token data, clear docs and SDKs5Triton OneNo traditional free tier; $125 minimum prepaid deposit (stablecoins, valid 12 months)Pay-as-you-go: $0.08/GB bandwidth + $10 per million calls (standard RPC); Shred streaming $1,500/mo per IP per data center99.99% uptime; GeoDNS routing with auto-failover across bare-metal infrastructureFull feature access at every spend tier, Yellowstone gRPC Geyser plugin (created by Triton One), 1-on-1 senior engineer support6dRPC~210M CUs/mo (~≈10M calls), ~100–250 RPS~$6 per 1M requests (Pay-as-you-go). Scales to ~5,000 RPS; enterprise custom beyond thatLatency-aware multi-region routing; 99.99% uptime on paidDashboard analytics and request metrics, unlimited keys on paid plans, stake weighted QoS messaging and MEV safe routing7Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow latency routing, uptime available on higher tiersWebhooks and WebSocket streaming, per method analytics in dashboard, request tracing and alerting, archive access and cross chain SDKs8QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams and WebSockets, add ons for transaction handling and MEV protection, multi region endpoint setup and archive access Key takeaways from the comparison: Chainstack offers the best balance of features, transparent pricing, 99.99%+ uptime, and full SOC 2 Type II and ISO 27001 compliance. OnFinality offers a request-unit pricing model with Dedicated Nodes on every paid tier and 24/7 support on dedicated infrastructure. Uniblock consolidates 300+ chains behind one API and one invoice, useful for teams that don’t want a separate integration per provider. Helius provides Solana-native APIs for NFTs, metadata, and real-time tracking. Triton One runs pay-as-you-go bare-metal infrastructure and created the Yellowstone gRPC Geyser plugin used across the industry. dRPC focuses on low-latency and free access, with limited observability. Alchemy delivers strong tooling, holds SOC 2 Type II, but lacks ISO 27001. Quicknode leads on raw performance and global RPS scaling for production apps. How to choose a Solana RPC provider The right Solana RPC provider isn’t the fastest one on paper — it’s the one that matches your workload’s actual constraints. Weigh these criteria before comparing vendors: Latency and regional routing — trading and market-making apps need sub-100ms round trips; without multi-region routing or GeoDNS failover, that shows up as missed fills, not just slow responses. Throughput (RPS) ceiling — check the RPS cap on the plan you’d actually pay for, not the free-tier headline number; indexers and analytics pipelines can burst well past it during backfills. Archive data access — historical account states, full transaction history, or indexing backfills need archive nodes, which most providers price and provision separately from standard RPC. Streaming needs (Yellowstone gRPC / Geyser) — polling can’t keep up with sub-second account and program updates; prioritize providers with managed Yellowstone gRPC Geyser access over building your own plugin infrastructure. MEV exposure and priority fees — trading and DeFi workloads should check for MEV-aware transaction submission or shred streaming, since landing rate and priority-fee strategy directly affect execution quality on Solana. Budget and pricing model — Solana providers bill by RPS tier, credit/compute-unit consumption, or flat bandwidth; model your call volume and method mix against each structure, since a credit-weighted plan can cost more than an RPS plan at the same volume. Before diving into detailed provider reviews, let’s examine how each performs across critical Solana use cases: Choose by your use case: Stablecoin & payments infrastructure Stablecoins now account for over 30% of all crypto transaction volume — surpassing $4 trillion in 2025 — and Solana is increasingly used for real-time payment flows. To support this, Solana RPC providers must offer high availability, low-latency global routing, and predictable performance. Even small delays or regional failures can disrupt thousands of transfers per second. For teams with strict requirements around gas cost predictability and settlement finality, purpose-built chains like Tempo offer an alternative optimized specifically for payment infrastructure. Tempo delivers sub-second finality with deterministic execution costs, designed for enterprise stablecoin rails. Top providers like Chainstack and Quicknode deliver robust failover systems and multi-cloud infrastructure, ensuring 99.99%+ uptime and uninterrupted stablecoin settlements. Explore stablecoin-ready infrastructure → Enterprise-grade performance Institutional teams building on Solana need guarantees around throughput, uptime, and security compliance. Whether supporting payments, custody, or analytics, enterprise use cases often require custom RPS setups, global scaling, and strict SLA-backed operations. Chainstack and Quicknode support enterprise-grade workloads through: Custom RPS tiers and dedicated infrastructure Multi-region data centers with intelligent routing SOC 2 Type II and ISO 27001 certifications for compliance Request enterprise plan → Real-time data access with Trader Nodes Solana’s high-speed architecture demands more than just standard RPC. Trading platforms, explorers, and analytics apps rely on Trader Nodes and Yellowstone gRPC streaming to access live account updates, program events, and transaction states with minimal latency. Leading RPC providers like Chainstack and Helius offer Trader Nodes with priority routing and gRPC support, unlocking deep real-time blockchain data access—critical for high-frequency DeFi, analytics, and indexing apps. Start building with Trader Nodes → In-depth provider analysis: Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most scalable ways to connect to Solana without running validator-grade hardware yourself. You can choose between reliable Global Nodes, which provide geo-balanced RPC access for predictable performance, or Dedicated Nodes, which offer isolated infrastructure and full configuration control, both backed by 99.99%+ observed uptime. What makes Chainstack the default choice for teams building on Solana is its alignment with the protocol’s high-speed architecture. Instead of relying on standard pull-based JSON-RPC alone, Chainstack supports ShredStreams and Yellowstone gRPC via the Geyser plugin to enable real-time data streaming at validator speed. On top of that, you get Access Rules for securing endpoints, real-time usage visibility, and an Unlimited Node add-on that gives you flat-fee scaling instead of metered request limits. What makes it stand out is how much is available from the same console: Global Nodes for geo-balanced Solana RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for unlimited requests with flat monthly pricing, so you never have to worry about hitting plan limits. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly price with unmetered Solana RPC traffic, effective ~$2.00 per million requests at scale.Dedicated Nodes — $0.50 / hour plus storage for isolated Solana RPC nodes, working out to ~$0.25 per million requests depending on workload.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Dedicated Nodes are billed separately on an hourly plus storage– Solana-native streaming support (Yellowstone gRPC, ShredStream) for real-time data– 99.99%+ uptime SLA, SOC 2 Type II, globally distributed routing for low latencyCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Enterprise-grade features like private networking or SLAs are reserved for higher tiers 🤖 You can also access Chainstack Solana RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. Chainstack fits nearly every Solana builder — from early-stage teams on the free tier to production-ready projects needing consistent low latency for trading, analytics, or infrastructure. The combination of predictable pricing, real-time streaming, and multi-cloud routing makes it easy to trust that your RPC will hold when traffic spikes. You still get full control from the console without having to manage hardware or vendor lock-ins. For builders who care about performance as much as uptime, Chainstack is the one provider that keeps pace with how Solana actually runs. OnFinality OnFinality runs managed Solana infrastructure on a request-unit (RU) model across four tiers: Developer (free, 400K RU/day, 40 RU/sec, archive access, no trace API), Growth ($49/mo, 20M RU/month, 200 RU/sec, $6 per million RU overage), Accelerate ($249/mo, 100M RU/month, 500 RU/sec, $3.75 per million RU overage), and Ultimate (custom limits and pricing, enterprise support). Dedicated Solana Nodes are available on every paid tier for high-throughput dApps, trading bots, and any workload where predictable latency matters, with 24/7 support on dedicated tiers. Pros: Dedicated Nodes, archive access, WebSocket subscriptions, managed infrastructure with 24/7 support on dedicated tiers. Cons: No SLA published on free/public tiers; Solana-specific throughput ceilings on shared plans weren’t independently confirmed beyond the general RU-based rate limits. Uniblock Uniblock is a unified RPC aggregation platform rather than a node operator — it routes requests to upstream providers behind a single API and a single invoice across 300+ chains, including Solana. For teams juggling multiple chains, Uniblock’s value is consolidation: one API shape and one bill instead of separate integrations per provider, plus its higher-level Unified APIs (token, NFT, market data) layered on top of raw RPC. Limitations: Uniblock is not a Solana-specific infrastructure provider — it aggregates upstream providers rather than running dedicated Solana validators, and Solana-specific details (stake-weighted QoS, archive depth, dedicated node options) are not clearly documented on its own site. Confirm current Solana coverage directly before committing to a production workload. Helius Instead of going multi-chain, Helius is built squarely around Solana. Its RPC traffic runs through staked validator nodes that get higher priority in the network, helping transactions land faster during congestion. Average latency sits around 140 ms, and the setup scales well under load thanks to Solana-specific tuning. So, the trade-off with Helius is the focus as you get a strong Solana experience, but no cross-chain flexibility or custom routing control. Helius adds a few extras that make it feel closer to an indexer than a standard RPC. You get token and transaction parsing APIs, webhook subscriptions, and support for the Digital Asset Standard (DAS) plus Geyser plugin streams. It runs shared clusters for most workloads and dedicated validators for teams that need isolation or performance guarantees. For Solana-only builders who want integrated data and real-time event streams out of the box, it’s a specialized choice, though less customizable than full-stack platforms like Chainstack and other infra providers. How much does it cost?Free — $0/month, 1M credits, 10 RPS.Developer — $49/month, 10M credits, 50 RPS.Business — $499/month, 100M credits, 200 RPS.Professional — $999/month, 200M credits, 500 RPS.Enterprise — custom pricing, up to 1B+ credits, custom RPS.Dedicated nodes — from $2,900/month for isolated gRPC streaming infrastructure with custom optimizations.Data add-on — LaserStream / Enhanced WebSockets plans start at $500/month for fixed-rate streaming tiers.PerformanceAvailability: Staked RPC designed to keep transactions landing under load. Uptime is positioned as a reliability feature, but there is no public 99.99% SLA on lower tiers.Latency: ~140 ms average Solana RPC response time, with routing that prioritizes proximity to the current leader to reduce slot delay.Scalability: From 10 RPS (free) to 500 RPS (paid) plus dedicated validators.Stability: Holds transaction success rates during mints or fee spikes.Controls: Transaction and account parsing APIs, webhooks for on-chain triggers, DAS support, and Geyser-powered streams. Enterprise tiers layer on higher sendTransaction rates, private validator access, and direct engineering support.Pros– Staked RPC routing aims to improve inclusion during congestion and keep transactions landing under load – Low reported latency (~140 ms average response time) and routing that follows leader proximity– Credit-based plans scale from ~10 RPS (free) to ~500 RPS (paid), plus dedicated validator options for isolation– Built-in parsing APIs, webhooks, DAS support, and Geyser streams reduce the need to run your own indexerCons– Solana-only focus, so no cross-chain flexibility if you want the same setup on other networks– No public 99.99% uptime SLA on lower tiers, stronger guarantees sit in higher plans– Credit/CPU-style billing can be harder to forecast for bursty workflows compared to straight request-based pricing– Some advanced features and higher sendTransaction rates sit behind Business / Professional / Enterprise tiers If you or your team builds only on Solana and wants data depth out of the box, Helius as a choice makes sense. You get staked RPC routing, parsed transactions, webhooks, DAS, and Geyser streams without wiring your own indexer. It’s a good match for products that tie backend logic to real-time account changes and want to move fast on one chain. Yet, if you need broader control, predictable request-based pricing, multi-cloud routing, and streaming in the same stack, or just multi-chain support, other providers like Chainstack are the safer all-around choice. Triton One Triton One runs Solana RPC on global bare-metal infrastructure, with GeoDNS routing and automatic failover. It created the Yellowstone gRPC Geyser plugin now used across the industry for low-latency streaming, and offers a gap-free reconnect with a 4-day cache on its streaming feed. There is no traditional free tier — access starts with a $125 prepaid stablecoin deposit, valid for 12 months, and every spend tier gets complete access to all features (no plan-gated throttling). Pricing is pay-as-you-go rather than tiered: standard RPC, unary gRPC, and ledger queries cost $0.08/GB bandwidth plus $10 per million calls; streaming services and the Titan Prime API bill bandwidth only, with no per-call charge; dedicated Shred streaming runs $1,500/month per IP per data center. Every account gets 1-on-1 senior engineer support regardless of spend. Pros: Full feature access at every tier, creator and maintainer of the Yellowstone gRPC Geyser plugin, 99.99% uptime with GeoDNS failover, transparent pay-as-you-go pricing with no overage penalties. Cons: No free tier — testing requires a non-refundable $125 minimum deposit; pay-as-you-go billing needs usage monitoring to forecast costs at scale. dRPC dRPC, instead of running its own single cluster, routes traffic across a network of 50+ independent node operators and uses an AI-driven load balancer to select the fastest, healthiest endpoint for each request. The goal is to eliminate single points of failure, reduce latency by steering calls to the nearest region, and deliver production-level throughput without tying you to a single provider’s hardware profile. That design comes with a clear trade-off: you’re not getting one tightly controlled Solana stack. Speed and redundancy are achieved by sitting on top of multiple operators, so performance depends on a rotating pool of providers. As a result, you don’t always get the same level of deterministic routing, regional pinning, or operational visibility that other providers provide. How much does it cost?dRPC prices Solana access on a pay-as-you-go model. Costs are structured around compute units and per-million-request pricing: higher tiers get you more RPS capacity, priority routing, uptime SLAs, and dedicated support.Free — $0. Includes 210M compute units per month (roughly ~10M calls).Growth / Pay-as-you-go — $6 per 1M requests. Includes high-performance nodes behind an AI-driven load balancer, up to 5,000 requests per second class throughput.Enterprise — Custom pricing starting from ~300M+ requests/month.PerformanceAvailability: 99.99 % uptime goal with automatic fallback across 50 + operators and 7 regions.Latency: Region-aware routing keeps calls close; speeds can fluctuate slightly.Scalability: Pay-as-you-go throughput up to ≈ 5,000е RPS, expandable for enterprise.Stability: Automatic retries and smart rotation maintain flow during mints or heavy network load.Controls: Unlimited API keys, request analytics, and MEV-safe routing included.Pros– Decentralized aggregator with AI routing across 50+ operators for low latency and no single point of failure– High headroom on paid plans– Built-in MEV-safe routing and automatic fallback under congestionCons– Less predictable than a single-provider stack; routing and performance can vary between upstream operators– Finer controls like strict regional pinning or per-cluster visibility are limited compared to infra-first providers– Debugging edge cases can take longer because issues may originate from different upstream node operators dRPC is a good fit for teams that want high RPS fast and are fine with smart routing deciding where traffic goes. The pay-as-you-go model and high burst capacity work for bots, liquidators, and monitoring systems that just need throughput right now. If you need strict region pinning, predictable billing, or deep visibility into a single stack, something more infra-directed like Chainstack will feel safer long term. Alchemy Alchemy runs Solana RPC on top of its supernode architecture, which is designed for correctness, high uptime, and consistent routing under load. With this infra provider, you get global routing, 99.99% uptime targets, and latency around 170 ms, fast enough for most use cases but not optimized for Solana’s validator layer. However, where Alchemy leans hardest is the developer layer. Alchemy’s dashboard shows per-method latency, request tracing, and error tracking, along with APIs for tokens and balances. Still, it’s a generalist setup, great if you’re shipping across multiple chains, but less tuned to Solana’s unique speed and streaming requirements than Solana-native or infra-focused providers. How much does it cost?Free — 30M compute units per month (~25 RPS).Pay-as-you-go — $5 per 11M CUs, no base fee, scaling to ~300 RPS.Enterprise — Custom SLAs, routing, support.Platinum — Uncapped throughput, advanced analytics.PerformanceAvailability: Multi-region routing and 99.99 % uptime targets.Latency: ~170 ms average across US, EU, APAC.Scalability: 25 RPS on free, ~300 RPS paid, custom enterprise.Stability: Supernode architecture absorbs traffic spikes and method-heavy bursts without performance drops.Controls: Per-method metrics, WebSockets, webhooks, API keys, and SDKs.Pros– Covers Solana plus 40+ chains– Global routing with auto-failover– Support for Solana-specific tooling including Yellowstone gRPCCons– CU pricing isn’t intuitive– Hard to verify real performance without public benchmarks– Throughput caps by plan, very high RPS needs enterprise plan Alchemy performs reliably under heavy load, and latency stays tight across regions. Its compute-based pricing gives you flexibility in how you use the service, but it also means your bill depends on call mix, not just volume, which can make it harder to model at scale. If you’re building with features like Notify or Mempool streaming, Alchemy is fine option, but less ideal if you want predictable scaling. Quicknode Quicknode runs Solana alongside other chains on a global, multi-region network with load balancing and automatic failover. With this provider, you get standard RPC, WebSocket streaming, and the Streams API for real-time delivery, plus usage analytics, request logs, team dashboards, and a marketplace of add-ons like MEV protection, webhook-style streaming, and transaction handling. While capable, Quicknode comes with trade-offs around control and cost. Pricing is credit based, so spend can fluctuate depending on method mix, and RPS headroom scales tightly with your tier. There’s also no ongoing free plan (only a time-limited trial), which makes long testing cycles harder to sustain without paying. If you need more precise control over routing, predictable request-based billing, or unmetered options, it’s worth looking into other options. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom pricing + RPSPerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Global multi-region routing with automatic failover– Streams and WebSockets for event delivery, plus usage analytics, request logs, and team dashboards– Add-on marketplace (e.g., MEV protection, webhook-style streaming, tx handling)Cons– No ongoing free plan, only a short trial before paid usage– Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode is a comfortable choice for wallets, analytics surfaces, dashboards, or multi-chain consumer apps that value logs, Streams, WebSockets, and team access controls. However, you’ll need to be okay with the trade-offs: RPS ceilings scale with your tier, pricing is credit-based, and there’s no true free plan beyond the trial. Conclusion The 2026 Solana RPC landscape has matured into a competitive market where every top provider covers the basics — the differentiator is which workload each one is actually built for. Stablecoin and payments infrastructure: Chainstack or Quicknode, for multi-cloud failover and 99.99%+ uptime under sustained transfer volume. Enterprise and compliance-sensitive workloads: Chainstack, for SOC 2 Type II and ISO 27001 coverage alongside custom RPS tiers and dedicated infrastructure. High-frequency trading and real-time data: Chainstack or Helius, for Trader Nodes and Yellowstone gRPC Geyser streaming with priority routing. Solana-native app and NFT tooling: Helius, for purpose-built APIs, webhooks, and metadata indexing. Budget-conscious or early-stage projects: dRPC or Chainstack’s free tier, for low-latency access without committing to a paid plan upfront. Bare-metal, pay-as-you-go infrastructure: Triton One, for unthrottled access at any spend level with no plan-gated feature walls. Deploy your Solana RPC endpoint on Chainstack → FAQ What is Solana RPC and why does it matter? An RPC (Remote Procedure Call) provider lets your app communicate with the Solana network without running your own validator. It lets you read account data, send transactions, and stream updates via gRPC or WebSockets. Without reliable RPC, your app can’t function properly on Solana. Which is the top Solana RPC provider in 2026? Chainstack leads for production use, combining predictable request-based pricing and scalable performance for enterprise workloads, 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and both free/enterprise tiers. It covers payments, enterprise, and DeFi needs better than competitors. Are there free Solana RPC options suitable for real development? Yes. Chainstack offers a free tier with ~25 RPS, mainnet/testnet access, and gRPC streaming. Helius also has a free plan, but Chainstack’s tier includes more production-grade capabilities. Alchemy also offers a limited free plan, but with tighter usage caps or fewer production-ready features. Triton One has no free tier at all — access starts with a prepaid deposit.​ How do I connect to a Solana RPC node? Solana’s speed means infrastructure choices matter more than most builders think, and there’s no one-size-fits-all setup. Trading bots, dashboards, indexers, or DeFi frontends all hit the chain differently. But whatever you’re building, you need an RPC provider that can deliver low latency, stable throughput, and real-time access.With Chainstack, that’s all built in. You can deploy a Solana RPC endpoint in under a minute and start sending requests right away with a few short steps:– Log in to the Chainstack console (or create one if you don’t have it yet).– Create a new project or select an existing one.– Pick Solana as the network and choose mainnet or testnet.– Deploy your node.– Copy your HTTPS or WebSocket endpoint. How do I access Solana account and program data in real time via Yellowstone gRPC? Standard JSON-RPC polling can’t keep up with sub-second Solana account and program updates, so latency-sensitive apps use Yellowstone gRPC, built on Solana’s Geyser plugin interface, to stream changes directly instead. Chainstack provides managed Yellowstone gRPC Geyser access on its Solana Trader Nodes and Dedicated Nodes, so you don’t have to build or operate your own Geyser plugin infrastructure. Triton One originally created the plugin, and Helius also layers Geyser-based streams on top of its APIs, but this kind of streaming access is generally a paid or dedicated-tier feature rather than something included on free plans. How much do RPS limits differ between free and paid Solana RPC tiers? The gap is significant. Chainstack’s free tier caps out at roughly 25 RPS (3M requests/month), while its paid plans scale from about 250 RPS on Growth up to 600+ RPS on Business, with custom RPS on Enterprise and a flat-fee Unlimited Node add-on for unmetered traffic. Other providers show the same pattern: Helius moves from 10 RPS free to up to 500 RPS on paid tiers, and providers like Quicknode and Triton One skip a free plan altogether, so meaningful throughput only starts once you’re on a paid or prepaid plan. Always check the RPS cap on the tier you’d actually pay for rather than the free-tier headline number, since real workloads like bots and indexers can burst well past it. Additional resources Chainstack Solana tooling docs — CLI, SDKs, and Yellowstone gRPC Geyser setup for Solana nodes. Chainstack Solana RPC — product page for Global and Dedicated Solana nodes. Solana documentation — official developer docs from the Solana Foundation. Solana JSON-RPC API reference — the full method spec for Solana’s RPC interface. #### Best Sui RPC providers for production in 2026 Sui has emerged as a serious non-EVM Layer-1 in 2026. The launch of USDsui and CME cash-settled futures confirm it has crossed from developer experiment to institutional-grade network, with on-chain stablecoin transfers crossing $1 trillion cumulatively by early 2026. The defining constraint for Sui builders in 2026 is a hard deadline: JSON-RPC public endpoints shut down the week of July 6 (testnet) and July 20 (mainnet), with full protocol-level deactivation on July 31, 2026, replaced by gRPC and GraphQL. This guide covers the leading Sui RPC providers for production workloads in 2026, with specific focus on gRPC depth, object version retention, archive access, pricing predictability, and operational reliability under real traffic. 💡 Already using Chainstack? Jump straight to the Sui tooling docs for SDK examples across TypeScript, Go, Python, and cURL — or deploy your endpoint in minutes. Why Sui RPC provider choice matters for production In development, Sui’s public endpoints are sufficient. They’re free, easily accessible, and have no setup overhead. In production — where a gaming backend processes thousands of object mutations per second, where a DeFi protocol tracks checkpoint sequences for liquidation monitoring, or where an indexer backfills historical object states across months of chain history — the gap between providers becomes operationally decisive. The API migration is the single most important constraint shaping provider selection in 2026. JSON-RPC, the legacy default that most Sui developers started with, has now been deprecated. Providers that hadn’t implemented gRPC in time forced migrations onto their customers at the worst possible moment — mid-growth, when infrastructure changes carry maximum risk. But beyond the protocol question, Sui’s object model means that standard EVM tooling assumptions simply don’t apply. There are no eth_getLogs-style calls, no account-based state lookups, no block-based event scans. Your provider needs to understand and support Sui’s actual data model — objects, checkpoints, Move events, dynamic fields — not just expose a URL that proxies requests to a Sui node. The key factors separating production-grade Sui RPC providers from basic public options: gRPC support — required for Sui’s API roadmap; JSON-RPC public endpoints shutting down July 6 (testnet) and July 20 (mainnet), with full deactivation July 31, 2026 GraphQL RPC access — flexible object and event queries with field-level precision and efficient pagination Archive and historical checkpoint access — essential for indexers, analytics pipelines, and backfill workloads Checkpoint-based query consistency — Sui’s object model requires checkpoint tracking, not block-log scanning WebSocket support — for real-time object state updates and Move event subscriptions SLA and security certifications — non-negotiable for gaming studios, DeFi protocols, and institutional deployments Pricing predictability — cost must be modelable as Sui’s throughput scales; method-weighted billing creates budget uncertainty Sui RPC providers comparison table (2026) The table below summarizes public positioning as of August 2026. Enterprise-only details are noted where applicable. ProviderPricing modelFree tierDedicated nodesgRPC supportObject versions storedChainstackRequest-based (RU)3M RU/month, 25 RPSYes (paid plans)Yes (x-token auth required)51.3M (6.76%)UniblockCompute-unit based, unified across chainsYes, free tierNot documented for SuiNot documented for SuiNot documented for SuiOnFinalityResponse-unit based, unified tiersPublic 5 RPS; Free plan 40 RPSYes (Dedicated/Enterprise Nodes)Yes (gRPC primary; JSON-RPC legacy)Not benchmarkedDwellirFlat 1:1 (1 response = 1 credit)Free public endpoints (no SLA)Yes (dedicated clusters)Yes (auth required)14.0M (1.85%)AnkrAPI credit200M credits/monthPremium private endpointsYes (bare-metal)Not benchmarkedAlchemyCU-based (method-weighted)30M CUs/monthNo standard dedicated tierYes (auth required) 7.4M (0.97%)QuicknodeCredit-based (method-weighted)Trial only (30-day)Yes (dedicated clusters)Yes (auth required)13.5M (1.78%) 📖 What “object versions stored” means: Sui’s data model is object-centric — every time an object changes (a token transfer, an NFT update, a contract state mutation), a new version is created. Providers retain a limited window of these historical versions before pruning. More versions stored means your app can query deeper historical object state via sui_tryGetPastObject — critical for DeFi protocols replaying collateral history, indexers backfilling NFT provenance, and analytics pipelines auditing past on-chain state. All providers support full checkpoint and transaction history from genesis; object version retention is a separate, finer-grained capability. How to choose a Sui RPC provider 1. API protocol support is the first filter Unlike EVM chains where JSON-RPC remains stable indefinitely, Sui is mid-migration. JSON-RPC public endpoints begin shutting down in July 2026 — testnet the week of July 6, mainnet the week of July 20 — with full protocol-level deactivation July 31. Any provider without confirmed gRPC support creates a forced migration during your application’s growth phase. Before evaluating pricing, latency, or feature depth — confirm that the provider supports gRPC today and has a public roadmap for GraphQL. This single criterion eliminates providers from consideration for new production Sui deployments. 2. When dedicated infrastructure starts to matter In a development or low-traffic context, shared RPC infrastructure is usually sufficient. The threshold for dedicated infrastructure arrives quickly on Sui, typically in three scenarios: gaming applications with concurrent object mutations during peak player sessions, where shared endpoint noise introduces jitter into user-visible transaction flows; DeFi bots and keeper networks that depend on consistent checkpoint polling latency to hit liquidation windows; and indexers running long checkpoint backfills where shared endpoint throttling corrupts the consistency of historical data pipelines. Once any of these apply, shared RPC becomes a liability even if average metrics still look acceptable. 3. Archive and historical checkpoint access Sui’s full nodes retain only the last 14 epochs by default. Queries for older checkpoint data must route to archive infrastructure. For indexers, analytics pipelines, compliance tooling, and any workload that replays historical object states, your provider must explicitly support archive access — not just current chain state. Some providers handle this transparently through automatic routing from the same endpoint; others require separate archive endpoints, paid plan upgrades, or manual configuration. Know which category your provider falls into before you need it in production. 4. Latency consistency versus average benchmarks Sui’s sub-second finality creates user experience expectations that average latency figures won’t reveal. What breaks real-time workloads — wallets displaying stale object state, games lagging on transaction confirmations, DeFi bots missing checkpoint windows — is p95 and p99 latency under sustained load, not median response times from a quiet endpoint. Sui isn’t currently one of the chains tracked on Chainstack’s public performance dashboard, so before committing to a provider, benchmark endpoint latency yourself against your actual Sui method mix under representative load — a simple curl loop or k6 script is enough. A provider that averages 40ms but spikes to 800ms under concurrent subscriptions is not production-ready, regardless of what its marketing page says. 5. Enterprise support for regulated and institutional workloads Institutional DeFi protocols, gaming studios with large player bases, and infrastructure integrators all face the same reality: at some point, a performant endpoint isn’t enough. They need a contractual SLA, verifiable security certifications (SOC 2, ISO 27001), dedicated or isolated infrastructure options, multi-region resilience, and support quality that doesn’t require a public Discord thread to escalate a P1 incident. At this level, your Sui RPC provider becomes part of your operational risk model and needs to pass internal procurement reviews. Choose the right Sui RPC provider by use case For gaming and NFT applications Sui has emerged as a serious gaming platform, driven by the object-centric Move model where in-game assets are native on-chain objects with direct ownership semantics — not entries in a contract mapping. This architectural choice makes Sui genuinely compelling for gaming: NFT transfers happen without global consensus, parallel execution handles concurrent player actions, and the object model maps naturally to game state. Projects like EVE Frontier migrating to Sui reflect real developer conviction, not ecosystem marketing. But this architecture also creates specific RPC demands: high-frequency object state reads, real-time Move event subscriptions for in-game actions, and transaction submission pipelines that must stay responsive during concurrent player sessions without introducing visible lag. For gaming workloads, the critical provider attributes are gRPC support for streaming, WebSocket connection stability under sustained concurrent subscriptions, and consistent low latency during peak periods. Jitter or connection drops in a game loop are immediately user-visible failures that erode retention. Chainstack offers predictable request-unit pricing and a direct upgrade path to dedicated Sui infrastructure — practical for studios that need to model infrastructure costs as player counts and session concurrency scale. Quicknode’s gRPC depth and globally distributed infrastructure make it a strong alternative for gaming apps where archive access and the broadest API surface matter. Dwellir’s 1:1 pricing model eliminates billing surprises that are particularly costly for gaming workloads with unpredictable method mixes. Explore gaming infrastructure on Chainstack → For DeFi protocols and stablecoin infrastructure DeFi on Sui has matured significantly in 2026. DeepBook provides institutional-grade order book infrastructure, Suilend has become a cornerstone lending platform, and the launch of USDsui creates new stablecoin liquidity and payment rails on the network. Each of these protocols creates demanding RPC patterns: real-time object state reads for price feeds and collateral tracking, checkpoint sequence monitoring for liquidation triggers, Move event indexing for on-chain activity feeds, historical backfill for analytics and audit trails, and transaction submission pipelines that must stay fast during market volatility spikes. For DeFi workloads, gRPC is not optional — it’s the only protocol with a reliable future on Sui after July 2026, and providers without it will force migrations during exactly the windows when your protocol is most stressed and your team has the least capacity for infrastructure changes. Chainstack has the clearest upgrade path from shared RPC to dedicated Sui infrastructure, with transparent request-unit pricing that’s easier to model than method-weighted credits when your workload mixes archive queries, checkpoint reads, and real-time subscriptions in variable proportions. Quicknode’s archive auto-routing via a single gRPC endpoint removes the friction of managing separate endpoints — a material advantage for analytics-heavy DeFi stacks. Alchemy brings strong developer tooling and a generous free tier, well-suited to teams with predictable, well-characterized method mixes. Explore dedicated Sui node infrastructure on Chainstack → For indexers, analytics, and enterprise deployments Indexers and analytics pipelines stress a Sui RPC provider differently from transactional workloads. The concern here is not single-request latency — it’s whether the provider can sustain historical checkpoint reads across months of data, run long-duration object backfills without throttling, and deliver continuous Move event streams without gaps that corrupt downstream data pipelines. Enterprise deployments add compliance and SLA requirements: SOC 2 certifications for vendor procurement, contractual uptime guarantees for regulated products, and dedicated infrastructure so that a noisy neighbor on shared infrastructure can’t introduce data inconsistency into your indexing jobs. For this workload category, the realistic production options narrow to Chainstack and Quicknode — both support gRPC with archive access and hold enterprise-grade security certifications. For enterprise deployments specifically, Chainstack’s SOC 2 Type II and ISO 27001, dedicated Sui node options, and transparent request-unit pricing provide a compliance-ready path that doesn’t require complex procurement negotiation just to get meaningful throughput. Quicknode’s dual SOC 2 + ISO 27001 certifications and archive auto-routing make it the strongest option for organizations where both compliance breadth and indexing infrastructure depth are required simultaneously. Explore enterprise blockchain infrastructure on Chainstack → Sui RPC providers: breakdown by provider Chainstack Chainstack supports Sui with Global Nodes offering HTTP, WebSocket, and gRPC access — covering the full protocol stack required for production applications in 2026. Per Chainstack’s own Sui gRPC developer guide, checkpoint depth on gRPC currently reaches back roughly 64.8 million checkpoints from the chain tip. Chainstack gRPC access requires authentication via an x-token header, passed with every call. The Sui tooling documentation covers TypeScript, Python, Go, Rust, and cURL with full gRPC examples. Pricing & throughput: Developer plan is free (3M RU/month, 25 RPS). Growth: $49/month (20M RU, 250 RPS). Pro: $199/month (80M RU, 400 RPS). Business: $499/month (200M RU, 600 RPS). Enterprise: $990/month (400M RU, unlimited RPS). Overage rates scale down from $20/1M RU on Developer to $5/1M RU on Enterprise. The Unlimited Node add-on converts any node to flat-fee unlimited requests within a fixed RPS tier (25–500 RPS), removing per-request billing entirely. Dedicated Nodes are available for teams that need isolated, guaranteed throughput. Limitations: Chainstack’s Sui-specific marketplace add-ons and streaming product surface are narrower than Quicknode’s. Teams needing a fully integrated AI agent data layer or advanced analytics dashboards alongside RPC may find Quicknode’s platform depth more compelling. GraphQL for Sui is not yet supported — it is an open feature request, not a shipped capability. Fit by workload: Gaming and NFT apps: Excellent — gRPC, predictable request-unit pricing, dedicated node upgrade path without enterprise procurement overhead DeFi protocols and stablecoins: Excellent — clearest path to dedicated Sui infrastructure, archive included on paid plans, transparent billing for mixed-method workloads Indexers and enterprise: Strong — SOC 2 Type II and ISO 27001, 99.99%+ uptime, dedicated nodes with clear SLA on paid plans Uniblock Uniblock is a unified RPC aggregation platform rather than a node operator — it routes requests to upstream providers behind a single API and a single invoice across 300+ chains, including Sui. For teams juggling multiple chains, Uniblock’s value is consolidation: one API shape and one bill instead of separate integrations per provider, plus its higher-level Unified APIs (token, NFT, market data) layered on top of raw RPC. Limitations: Uniblock is not a Sui-specific infrastructure provider — it aggregates upstream providers rather than running dedicated Sui nodes, and Sui-specific details (gRPC support, archive depth, dedicated node options) are not clearly documented on its own site. Confirm current Sui coverage directly before committing to a production workload. Fit by workload: Multi-chain dashboards and wallets: Good — one API and one bill across 300+ chains reduces integration overhead. Gaming and NFT apps: Moderate — Sui-specific archive/gRPC depth isn’t independently confirmed. Indexers, analytics, and enterprise: Limited — no published Sui-specific SLA or compliance attestation found. OnFinality OnFinality runs production Sui Mainnet infrastructure with gRPC as the primary API (querying checkpoints, transactions, objects, and balances, with streaming support) and legacy JSON-RPC maintained for existing applications during migration. Plans run from a public endpoint (5 RPS) and a Free plan (40 RPS with usage insights) up to a Growth plan (500 RPS, priority support), with Dedicated and Enterprise Nodes available for high-performance, scalable deployments. Limitations: No SLA published on the free/public tiers; Sui-specific archive retention depth wasn’t independently confirmed and should be checked directly before a production commitment. Fit by workload: Gaming and NFT apps: Strong — gRPC-primary access with streaming support fits real-time object state reads. Indexers, analytics, and enterprise: Strong — Dedicated/Enterprise Node tiers exist specifically for this profile. DeFi protocols and stablecoin infrastructure: Moderate — no independently confirmed SLA terms for regulated workloads. Dwellir Dwellir operates Sui infrastructure on bare-metal servers with a 1:1 pricing model — every method costs the same credit regardless of complexity. Benchmark testing shows 14.0 million object versions retained (1.85% coverage, ~1 epoch) and gRPC checkpoint depth of 4.9 million — comparable to Quicknode, but roughly 13x shallower than Chainstack. Dwellir’s gRPC runs on port 443 and requires authentication. All standard Sui RPC methods are supported. The platform covers 150+ networks under a single API key, making it practical for multi-chain teams adding Sui without managing separate billing. Pricing & throughput: Flat 1:1 pricing (1 response = 1 credit, no method multipliers). Paid tiers from $49/month. Free public endpoints available without SLA. Dedicated clusters available with direct technical support. Limitations: Security certifications (SOC 2, ISO 27001) are not prominently published, requiring direct engagement for enterprise procurement. No public SLA for standard plans. GraphQL RPC for Sui is not documented. Object version history at 14.0M is 3.7x shallower than Chainstack. Fit by workload: Gaming and NFT apps: Strong — 1:1 pricing eliminates billing surprises for unpredictable mixed-method gaming workloads, gRPC supported DeFi protocols and stablecoins: Good — bare-metal gRPC, predictable pricing at any method mix, but GraphQL depth requires direct validation Indexers and enterprise: Moderate — dedicated clusters available, 1:1 archive pricing is genuinely valuable for heavy historical workloads, but compliance documentation requires direct engagement Ankr Ankr operates Sui infrastructure on bare-metal servers with private fiber networking — a differentiated architecture compared to cloud-virtualized approaches, aimed at reducing the abstraction overhead between your requests and the underlying Sui node. The platform handles over 8 billion daily requests across its multi-chain network, supports gRPC for Sui as part of the new data stack endorsed by the Sui Foundation, and provides archive access on Premium tier. SOC 2 Type 2 certification was achieved in 2025, making Ankr a viable option for organizations with baseline compliance requirements. The 200M free API credits/month after sign-in is the most generous free tier in this comparison, giving teams substantial runway for pre-production development and testing without committing to a paid plan. Pricing & throughput: Freemium model with 200M API credits/month after account creation. Premium and Enterprise tiers available for higher throughput and dedicated options. The effective per-request cost on mid-tier plans can run approximately $20/1M actual requests — a figure that requires careful modeling at production volume before committing, particularly for workloads that lean heavily on archive access. Limitations: Dedicated Sui node offerings are less clearly positioned in Ankr’s public materials than Chainstack or Quicknode. For teams needing a formal dedicated Sui node with a defined SLA, the upgrade path requires direct engagement with Ankr’s sales team rather than self-service. At production scale, the effective per-request cost also requires careful modeling against the headline credit figures, as the advertised volume can be misleading for workloads with heavier Sui methods. Fit by workload: Gaming and NFT apps: Good — bare-metal gRPC, most generous free tier for pre-production development and load testing DeFi protocols and stablecoins: Good — archive on Premium, bare-metal gRPC support, but dedicated node path and cost modeling require direct engagement Indexers and enterprise: Moderate — SOC 2 Type 2 achieved, bare-metal infrastructure is genuinely differentiated, but dedicated Sui node offerings less clearly structured than top-tier alternatives Alchemy Alchemy supports Sui with HTTP, WebSocket, and full gRPC access — all 7 services (LedgerService, StateService, MovePackageService, NameService, SubscriptionService, TransactionExecutionService, SignatureVerificationService) are documented and available. The free tier — 30M CUs/month (~1.2M Sui calls at average consumption) — is the most generous in this comparison by raw volume. The platform brings its established developer tooling to Sui: analytics dashboards, WebSocket subscriptions, and the familiar SDK experience for teams already using Alchemy on EVM chains. The key gap from the March 2026 benchmark: Alchemy retains only 7.4 million object versions (0.97% coverage) — the lowest in the comparison, 6.9x less than Chainstack — and gRPC checkpoint depth was not measured. Pricing & throughput: CU-based pricing (method-weighted). Free tier: 30M CUs/month. PAYG and higher tiers available. No standard dedicated node tier for Sui — enterprise infrastructure requires direct engagement. Limitations: At 7.4M object versions retained, Alchemy has the shallowest historical object state coverage tested — a real constraint for DeFi protocols and indexers that depend on historical object queries. No GraphQL support for Sui. No dedicated node tier means limited isolation options for latency-sensitive workloads. Fit by workload: Gaming and NFT apps: Good — strong free tier for development, WebSocket support, familiar tooling, but gRPC for Sui requires validation DeFi protocols and stablecoins: Good — reliable infrastructure, generous free tier, but gRPC uncertainty and no dedicated tier limit production commitment for high-throughput DeFi Indexers and enterprise: Moderate — SOC 2 Type II, strong uptime, but no documented dedicated Sui infrastructure and gRPC gap needs resolution for post-July 2026 operation Quicknode Quicknode offers a comprehensive Sui API stack with gRPC, GraphQL (beta), and WebSocket support. Benchmark testing shows 13.5 million object versions retained (1.78% coverage, ~1 epoch) and gRPC checkpoint depth of 4.9 million — solid, but roughly 13x shallower than Chainstack. Unlike Chainstack, Quicknode’s gRPC requires authentication credentials. All standard RPC methods are supported, and the platform explicitly documents gRPC in Go, Python, TypeScript, and grpcurl. For indexers, Quicknode’s archive auto-routing is convenient — queries for data older than 14 epochs route automatically to archive nodes without client-side configuration changes. Pricing & throughput: Credit-based pricing where different methods consume credits at different rates. Build tier starts at $49/month (80M credits, up to 50 RPS). No permanent free plan — only a 30-day limited trial. The credit model requires method-mix modeling to forecast costs for mixed Sui workloads, adding overhead compared to flat or request-unit pricing. Limitations: No permanent free tier makes early-stage development more costly. Credit-weighted billing is unpredictable for workloads with variable method mixes. Object version history at 13.5M (1.78%) is 3.8x shallower than Chainstack — relevant for DeFi protocols and indexers needing deep historical object state. Fit by workload: Gaming and NFT apps: Excellent — deepest gRPC + GraphQL stack, ISO 27001 for studios with formal security procurement requirements DeFi protocols and stablecoins: Excellent — archive auto-routing via single gRPC endpoint removes separate endpoint management entirely Indexers and enterprise: Excellent — SOC 2 Type II + ISO 27001, dedicated clusters, formal 99.99% SLA Getting started with Sui on Chainstack Log in to your Chainstack account or create a free account Create a new project or select an existing one Choose Sui Mainnet or Sui Testnet Deploy a Sui RPC node on Chainstack — Global Node for geo-balanced access or Dedicated Node for isolated, SLA-backed infrastructure Open Access/Credentials and copy your HTTP, WebSocket, or gRPC endpoint Quick connectivity check — get the latest Sui checkpoint: curl --request POST \ --url YOUR_CHAINSTACK_ENDPOINT \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sui_getLatestCheckpointSequenceNumber", "params": [] }' TypeScript (using @mysten/sui): import { SuiJsonRpcClient } from '@mysten/sui/jsonRpc'; const client = new SuiJsonRpcClient({ url: 'YOUR_CHAINSTACK_ENDPOINT' }); const checkpoint = await client.getLatestCheckpointSequenceNumber(); console.log('Latest checkpoint:', checkpoint); For gRPC access, Chainstack Sui mainnet nodes are reachable at sui-mainnet.core.chainstack.com:443. Your gRPC endpoint and x-token credentials appear in the console under your node’s Access and credentials panel. The Sui tooling documentation includes full gRPC examples in Go, Rust, and Python alongside the TypeScript and cURL examples above. 🤖 You can also access Chainstack Sui RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. See the Chainstack Agents page for the fuller agent stack. ⚠️ Migration note: If you haven’t already, move to gRPC now — the JSON-RPC deadline has passed. The @mysten/sui SDK, Rust SDK (sui-sdk), Python pysui, and Go SDK all support gRPC, and the transition from JSON-RPC is straightforward with your existing codebase once your provider endpoint is configured. Conclusion All seven providers in this comparison support Sui in some form, though gRPC-specific depth varies — the July 31, 2026 JSON-RPC deadline is no longer the filter. The differentiation is now benchmark depth: object version retention, gRPC checkpoint history, GraphQL availability, and pricing predictability under mixed workloads. Provider recommendation by use case: Gaming and NFT apps: Chainstack (predictable pricing, gRPC, dedicated node upgrade path) or Quicknode (deepest gRPC + GraphQL stack, ISO 27001) DeFi protocols and stablecoin infrastructure: Quicknode (archive auto-routing via single gRPC endpoint) or Chainstack (dedicated nodes, transparent request-unit pricing) Indexers, analytics, and enterprise: Chainstack (SOC 2 Type II, dedicated nodes, transparent pricing) or Quicknode (SOC 2 Type II + ISO 27001, dedicated clusters, formal SLA) Developer-first with tooling ecosystem: Alchemy (30M CUs free, full gRPC, familiar SDK surface) — best free tier volume in the comparison Cost-optimized high volume: Dwellir (1:1 flat pricing, no method multipliers) or Ankr (200M free credits, bare-metal gRPC) Multi-provider failover: Ankr or Dwellir as secondary endpoints alongside a primary SLA-backed provider Deploy your Sui RPC endpoint on Chainstack → FAQ What is the difference between gRPC and JSON-RPC on Sui? gRPC is Sui’s future API — binary protocol, lower latency, native streaming. JSON-RPC public endpoints shut down in stages — testnet the week of July 6, mainnet the week of July 20 — with full protocol-level deactivation July 31, 2026. Any app still on JSON-RPC after that date stops working. Which Sui RPC provider has the best free tier? Alchemy gives 30M CUs/month (~1.2M Sui calls). Ankr gives 200M API credits/month. Chainstack’s Developer plan (3M RU/month, 25 RPS) is smaller but includes confirmed gRPC access. Quicknode has no permanent free plan — only a 30-day trial. How do I migrate from JSON-RPC to gRPC on Sui? Confirm your provider supports gRPC, then update your SDK (@mysten/sui for TypeScript, sui-sdk for Rust, pysui for Python). Point it at your provider’s gRPC endpoint and port, validate with a checkpoint query, and migrate call sites. Chainstack, Quicknode, Dwellir, and Ankr all have per-language migration guides. Does average latency matter when comparing Sui RPC providers? No — p95 and p99 latency under load matters. A provider averaging 40ms that spikes to 800ms under concurrent subscriptions breaks wallets, games, and DeFi bots. Always benchmark against your actual method mix, not a quiet single-request test. Which Sui RPC providers are enterprise-ready? Chainstack (SOC 2 Type II and ISO 27001, dedicated nodes, 99.99%+ SLA) and Quicknode (SOC 2 Type II + ISO 27001, dedicated clusters, formal 99.99% SLA) are the strongest. Alchemy holds SOC 2 Type II. Ankr achieved SOC 2 Type 2 in 2025. Dwellir requires direct validation. Is Chainstack’s request-unit pricing more predictable than CU-based models? Yes, for mixed Sui workloads. Chainstack charges 1 RU per request regardless of method — checkpoint reads, archive calls, and event subscriptions all cost the same. CU models (Alchemy, Quicknode) weight heavier methods higher, making cost forecasting harder when your method mix varies. Additional resources How to get a Sui RPC endpoint in 2026 Sui tooling documentation — Chainstack Docs Sui official RPC providers documentation Chainstack performance dashboard (other supported chains — Sui not yet tracked) #### Best Tempo RPC providers for stablecoin infrastructure Tempo RPC providers are the backbone of payment infrastructure on Tempo blockchain. As stablecoin settlement and real-time payments migrate to purpose-built chains, selecting reliable Tempo RPC providers directly impacts transaction reliability, cost predictability, and system uptime. The challenge: Payment systems can’t tolerate downtime. A single RPC failure during settlement can halt thousands of transactions, trigger compliance violations, or cause missed SLA targets. Traditional blockchain infrastructure wasn’t built for this—Tempo was. This guide compares the top 6 Tempo RPC providers, evaluating performance, pricing transparency, uptime guarantees, and enterprise readiness. Whether you’re building stablecoin payment rails, high-frequency settlement systems, or regulated financial workflows, you’ll find the Tempo RPC provider that fits your requirements. What is Tempo blockchain? Tempo is a Layer-1 blockchain purpose-built for payment infrastructure. Unlike general-purpose chains that balance multiple use cases, Tempo optimizes specifically for financial transactions where predictable latency, fast finality, and deterministic execution are non-negotiable. Why Tempo matters for payments: Sub-second finality – Transactions confirm in under 1 second, enabling real-time settlement Predictable gas costs – No surprise fee spikes during network congestion Deterministic execution – Smart contracts behave consistently under load Built for compliance – Architecture designed with regulated finance in mind Tempo is being adopted for stablecoin payments, cross-border settlement infrastructure, and institutional transaction processing—environments where even minor latency or inconsistent state reads can disrupt operations. Its architecture prioritizes sustained performance under production load, making it the go-to chain for payment systems and high-frequency financial applications. 📖 Learn more about Tempo and its underlying architecture here: Tempo blockchain: Low-latency infrastructure for stablecoins Why choosing the right Tempo RPC provider matters Your Tempo RPC provider is not just a connection point—it’s mission-critical infrastructure for payment applications. What reliable Tempo RPC providers deliver: 99.99%+ uptime – Multi-region failover ensures zero downtime during settlement windows Low-latency routing – Geographic distribution keeps response times under 50ms globally Predictable costs – Request-based pricing with no surprise compute unit charges SOC 2 compliance – Security controls required for enterprise financial infrastructure Archive access – Historical data for auditing, compliance, and debugging What happens with unreliable Tempo RPC: ❌ Payment transactions fail during critical settlement periods ❌ Unpredictable costs make budgeting impossible ❌ Regional outages halt cross-border payment flows ❌ Compliance violations from insufficient audit trails ❌ Lost revenue from downtime during high-volume periods In this guide, we evaluate the best Tempo RPC providers across five critical dimensions: performance benchmarks, pricing models, uptime SLAs, developer experience, and security compliance. By the end, you’ll know exactly which Tempo RPC provider matches your payment infrastructure requirements. Best Tempo RPC providers comparison This section compares the best Tempo RPC providers by pricing, latency, uptime, and developer experience #ProviderFree planPaid plans & pricingLatency & uptimeDeveloper Experience1Chainstack3M requests/mo, 25 RPSStarting from 250 RPS and scaling beyond 600 RPS on custom Enterprise plans, with an Unlimited Node add-on for unmetered requests at a flat monthly rateLow latency global routing with 99.99%+ uptimeDocs, dashboard metrics, guides, Access rules2RouteMeshNo dedicated free tierPer-request; Economy from $3/M, Performance from $6/MNo formal SLA; Replay/Lag data-quality checks insteadAggregates 20+ providers incl. Chainstack, 1,282+ chains, auto-failover3Conduit100M CUs/month, 1 API keyPro: $50/month, 1B CUs, 5 API keysEnterprise: custom pricing for production-scale workloadsOptimized for testnet; enterprise SLA available.Simple setup via Conduit app, API key–based access, Tempo RPC Quickstart available, HTTPS & WebSocket support4dRPC~210M CUs/mo (~≈10M calls), ~100–250 RPS~$6 per 1M requests (Pay-as-you-go). Scales to ~5,000 RPS; enterprise custom beyond thatLatency-aware multi-region routing; 99.99% uptime on paidDashboard analytics and request metrics, unlimited keys on paid plans, stake weighted QoS messaging and MEV safe routing5Alchemy30M CUs/mo; up to 25 RPSPay-as-you-go or monthly; higher CU throughput on paid plansLow latency routing, uptime available on higher tiersMonitoring APIs, analytics, SDK support6QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based (method-weighted) monthly plansGlobally distributed, 99.99% uptime on paid tiersStreams, Webhooks, team dashboards, multi-region setup What separates one RPC provider from another usually comes down to the same few metrics: pricing, latency, uptime, and scalability options available. Here’s how the leading Tempo options measure up: Key takeaways from the comparison: Chainstack offers the most balanced feature set with transparent request-based pricing, highest uptime (99.99%+), and full SOC 2 Type II and ISO 27001 certification dRPC is ideal for small projects and developers needing simple setup Alchemy provides the richest developer tooling including monitoring APIs Quicknode delivers strong throughput on higher tiers (500+ RPS) with globally distributed infrastructure—though dRPC (~5,000 RPS) and Chainstack (600+ RPS on Business/Enterprise) reach higher RPS ceilings in this comparison Before diving into detailed provider reviews, let’s examine how each performs across critical Tempo use cases: Choose Tempo RPC provider by your use case Stablecoin & payments infrastructure Tempo is purpose-built for payment infrastructure. Applications building on Tempo require RPC service with consistent throughput, near-zero downtime, and predictable costs. Even minor RPC outages or high latency can disrupt payment flows and settlement operations. Top providers address this with robust multi-region infrastructure that automatically fails over if any node goes down. Chainstack’s network delivered 99.99%+ availability in testing, with multi-cloud architecture that reroutes traffic instantly if a region fails. Such redundancy ensures payment transactions aren’t halted by regional outages. Critical requirements for payment infrastructure: Multi-region failover – Automatic rerouting when nodes go down Predictable pricing – Fixed monthly costs, no surprise bills during high-volume periods SLA guarantees – 99.99%+ uptime with financial penalties for violations Security compliance – SOC 2 Type II and ISO 27001 for enterprise financial workflows Explore stablecoin-ready infrastructure → High-frequency transaction workloads Tempo’s deterministic execution model makes it ideal for applications requiring consistent performance under load. Trading bots, automated market makers, and real-time analytics need RPC infrastructure that can handle sustained throughput without degradation. High-frequency essentials: Sustained RPS capacity: Chainstack offers high-throughput plans with custom RPS configurations on Tempo and achieves ~99.99% measured uptime via global load balancing Dedicated Nodes for isolated performance: For ultra-low-latency applications, Chainstack’s Nodes provide exclusive infrastructure with no resource contention from other users Low-latency routing: Multi-region data centers and intelligent routing keep response times uniform worldwide Burst handling: Infrastructure that maintains performance during network congestion Request Dedicated node → SOC 2 compliant providers Security and compliance are paramount for enterprises integrating with Tempo. SOC 2 certification has become a key benchmark of a provider’s security controls and operational integrity. Security leaders: Chainstack achieved SOC 2 Type II in late 2025 and ISO 27001, underscoring enterprise-grade security and 99.99%+ uptime SLA guarantees Quicknode maintains SOC 1 Type 2, SOC 2 Type 2, plus ISO 27001 certifications In-depth Tempo RPC providers analysis Chainstack Chainstack is a multi-chain infrastructure platform offering one of the most complete ways to connect to Tempo without the overhead. By choosing Chainstack Tempo RPC node, you get secure HTTP and WebSocket access to Tempo, backed by 99.99%+ uptime and globally distributed routing for consistently low latency. Chainstack is listed as an official integration on the Tempo docs, highlighting its active role in the Tempo ecosystem. From a single console, teams can deploy and manage: Global Nodes for geo-balanced Tempo RPC access. Dedicated Nodes for isolated performance and full control over node configuration. Archive nodes for deep historical queries, tracing, and debugging. Access rules to manage allowed domains and IPs directly from the dashboard. Unlimited Node add-on for flat-rate, unmetered requests within a fixed RPS tier. How much does it cost?Developer — free, 3M requests/month (~25 RPS), $20 per extra million.Growth — $49/month, 20M requests (~250 RPS), $15 per extra million.Pro — $199/month, 80M requests (~400 RPS), $12.5 per extra million.Business — $499/month, 200M requests (~600 RPS), $10 per extra million.Enterprise — from $990/month, 400M requests (custom RPS), extra from $5 per million.Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier.Dedicated Nodes — $0.50 / hour plus storage costs for exclusive, high-performance isolated Tempo node instances, what means ~$0.25 per million requests effectively.While others price in shifting compute units, Chainstack keeps it simple with request-based billing and clear RPS tiers, so you always know what you’ll pay. What’s more, on Chainstack, you are able to pay in crypto.PerformanceUptime: 99.99%+ availability backed by a multi-cloud network that reroutes automatically if a region drops. Public status page is also available.Latency: Choose endpoints in the US, EU, or APAC to keep response times tight.Throughput: Plans come with enough RPS capacity to absorb traffic surges without forcing you to throttle the app.Stability: Remains steady under load, including during network-wide surges.Monitoring: Built-in console metrics plus public performance/compare dashboards and a status page.Pros– High throughput at price point (~250 RPS on Growth, ~600 RPS on Business)– Predictable, request-based pricing with Unlimited Node add-on for flat, unmetered traffic within your chosen RPS tier– 99.99%+ uptime SLA, SOC 2 Type 2, globally distributed routing for low latencyOne provider for Tempo plus 70+ other chainsCons– Fixed RPS per tier; ultra-low-latency apps may need Dedicated Nodes– Free plan (3M calls, ~25 RPS) can be tight for bots or indexers– Dedicated Nodes require at least a Pro plan 🤖 You can also access Chainstack Tempo RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. Chainstack offers a full-featured infrastructure stack for running Tempo, including high RPS capacity, global routing, and archive access. The deployment model stays consistent as workloads grow, helping teams scale without re-architecting their setup or losing cost visibility. RouteMesh RouteMesh is an RPC aggregation and routing layer rather than a node operator itself. It routes requests across 20+ upstream providers, including Chainstack, and 1,282+ chains, including Tempo, with automatic retries and failover built in. Instead of running its own Tempo infrastructure, RouteMesh’s value is picking the best available upstream route per request and catching bad data before it reaches your app. How much does it cost?Per-request, billed monthly. Economy keys from $3 per 1M requests; Performance keys (lowest-latency routing) from $6 per 1M requests. No minimum commitments or hidden fees.PerformanceUptime: No formal published SLA — reliability comes from routing across multiple upstream nodes with automatic failover.Data quality: Replay Checks (cross-node consistency) and Lag Checks (freshness) filter out lagging or incorrect nodes.Latency: Edge routing measures caller-to-router latency per region; Performance keys prioritize the lowest-latency route.Pros– No vendor lock-in to a single node operator– Per-request pricing with no minimums– Automatic multi-provider failover– Built-in Replay/Lag data-quality checks most aggregators don’t publishCons– Not a Tempo-specific infrastructure provider — aggregates other operators rather than running dedicated Tempo nodes– No formal SLA– Security certifications and Tempo-specific WebSocket/testnet support not documented Conduit Conduit provides high-performance RPC infrastructure for Tempo. Developers can create API keys and access Tempo endpoints through the Conduit app with straightforward setup and reliable connectivity. Conduit focuses on simplicity and developer experience, offering quick access to Tempo RPC without complex configuration. The platform is designed for teams that want to get started fast with development and testing. How much does it cost?Conduit offers a free tier for mainnet access with pay-as-you-go pricing for higher usage. Enterprise plans are available with custom pricing for production-scale workloads.– Free tier — 100M CUs/month, 1 API key– Pro — $50/month, 1B CUs/month, 5 API keys, Basic support– Enterprise — Custom pricing for dedicated infrastructure and supportPerformance– Uptime: Reliable infrastructure with monitoring – Latency: Optimized for testnet performance – Throughput: Scales with usage-based plans – Accessibility: Simple API key management through Conduit app – Documentation: Tempo RPC Quickstart available in Conduit HubPros– Simple setup through Conduit app– Free tier for testnet development– Tempo RPC Quickstart guide availableCons– Limited public information on specific RPS limits– Fewer advanced features compared to enterprise-focused providers Conduit is a solid choice for developers getting started with Tempo. The platform prioritizes ease of use and quick onboarding, making it ideal for early-stage development and testing. For teams needing enterprise-grade SLAs, compliance certifications, or advanced monitoring, providers like Chainstack or Quicknode may be better suited. dRPC dRPC, instead of running its own single cluster, routes traffic across a network of 50+ independent node operators and uses an AI-driven load balancer to select the fastest, healthiest endpoint for each request. The goal is to eliminate single points of failure, reduce latency by steering calls to the nearest region, and deliver production-level throughput without tying you to a single provider’s hardware profile. That design comes with a clear trade-off: you’re not getting one tightly controlled Tempo stack. Speed and redundancy are achieved by sitting on top of multiple operators, so performance depends on a rotating pool of providers. As a result, you don’t always get the same level of deterministic routing, regional pinning, or operational visibility that other providers provide. How much does it cost?dRPC prices Tempo access on a pay-as-you-go model. Costs are structured around compute units and per-million-request pricing: higher tiers get you more RPS capacity, priority routing, uptime SLAs, and dedicated support.Free — $0. Includes 210M compute units per month (roughly ~10M calls).Growth / Pay-as-you-go — $6 per 1M requests. Includes high-performance nodes behind an AI-driven load balancer, up to 5,000 requests per second class throughput.Enterprise — Custom pricing starting from ~300M+ requests/month.PerformanceAvailability: 99.99 % uptime goal with automatic fallback across 50 + operators and 7 regions.Latency: Region-aware routing keeps calls close; speeds can fluctuate slightly.Scalability: Pay-as-you-go throughput up to ≈ 5,000е RPS, expandable for enterprise.Stability: Automatic retries and smart rotation maintain flow during mints or heavy network load.Controls: Unlimited API keys, request analytics, and MEV-safe routing included.Pros– Decentralized aggregator with AI routing across 50+ operators for low latency and no single point of failure– High headroom on paid plans– Built-in MEV-safe routing and automatic fallback under congestionCons– Less predictable than a single-provider stack; routing and performance can vary between upstream operators– Finer controls like strict regional pinning or per-cluster visibility are limited compared to infra-first providers– Debugging edge cases can take longer because issues may originate from different upstream node operators dRPC is a good fit for teams that want high RPS fast and are fine with smart routing deciding where traffic goes. The pay-as-you-go model and high burst capacity work for bots, liquidators, and monitoring systems that just need throughput right now. If you need strict region pinning, predictable billing, or deep visibility into a single stack, something more infra-directed like Chainstack will feel safer long term. Alchemy Alchemy offers Tempo RPC access with Day 1 support, providing HTTP/WebSocket connectivity to Tempo Testnet. Alchemy launched Tempo support alongside the testnet, demonstrating strong commitment to the ecosystem. Developers get enhanced transaction monitoring, real-time notifications, and historical data alongside Alchemy’s global infrastructure. The platform supports dozens of networks, giving developers access to blockchain data and real-time event streaming tailored for Tempo, including transactions, contract events, and state changes. How much does it cost?Alchemy measures usage in compute units (CUs) rather than raw requests, which can make costs less predictable for teams sending large volumes of latency-sensitive calls compared to flat, request-based models.Alchemy starts with a free tier offering 30M CUs per month, roughly equal to 1.2M basic requests up to 25 RPS. Paid plans scale by total CU usage:Pay-as-you-go — $5 per 11M CUs (~$0.45 per million).Enterprise — custom pricing with lower per-unit costs at high volumes.PerformanceUptime: Reports 99.9% historical uptime, but an uptime SLA is only guaranteed on Enterprise plans.Latency: Region-based routing helps keep response times low; however, Alchemy does not publish official Tempo-specific latency numbers.Throughput: Begins at about 25 RPS on the free tier, with scaling up to 300 RPS on paid.Reliability: The Supernode setup helps maintain data accuracy during heavy traffic.Monitoring: You can check usage, errors, and request patterns through the dashboard in real time.Pros– Day 1 Tempo support– Covers Tempo plus 40+ chains – Optimized transaction delivery – Rich developer tooling and analyticsCons– CU pricing isn’t intuitive, – Hard to verify real performance without public benchmarks, – Throughput caps by plan, very high RPS needs an enterprise plan– SOC 2 Type II certified; no published ISO 27001 certification Alchemy’s early Tempo support and developer-first tooling make it attractive for teams prioritizing monitoring and analytics. Compute-based CU pricing offers flexibility but bills vary by API call complexity, making cost prediction challenging at scale. Best suited for teams needing enhanced observability over strict cost predictability. Quicknode Quicknode runs a multi-region infrastructure for Tempo RPC, letting you connect to Tempo over HTTP or WebSocket. Archive support is available for teams that need to query deep historical data. It also supports dozens of other chains and offers add-ons such as Webhooks and Streams if you want event-based triggers or real-time blockchain feeds. It’s popular with high-traffic teams because the network scales well under pressure, but to get to that performance you would need to move to the higher-priced tiers. How much does it cost?Build — $49/month, 80M credits plus $0.62 per extra million, up to 50 RPS.Accelerate — $249/month, 450M credits plus $0.55 per extra million, up to 125 RPS.Scale — $499/month, 950M credits plus $0.53 per extra million, up to 250 RPS.Business — $999/month, 2B credits plus $0.50 per extra million, up to 500 RPS.Enterprise — custom terms for higher volumes and dedicated support. Credits rollover unused portions, which helps variable Tempo loads, though the model adds a layer compared to straight request counts.PerformanceUptime: Targets 99.9% availability on paid plans.Latency: Region-routed endpoints optimized for low latency; no official ms target published, so benchmark in your region.Throughput: Initial plans handle 15–25 RPS; advanced tiers scale well past 500 RPS.Reliability: Requests are rerouted automatically.Monitoring: The dashboard gives real-time visibility into request performance and errors.Pros– Scales up to 500+ RPS on higher plans, – Archive data available (by chain/plan), – Low latency from multi-region routingConsFree trial caps at 15-25 RPS with only community support, – Method-weighted, credit-based billing makes costs less predictable, – No flat-rate unlimited option for heavy workloads Quicknode gives you speed, global routing, and developer tooling, which makes it good option for Tempo apps. The main limitation is its credit-based (method-weighted) pricing. Because different methods burn credits at different rates, long-term cost planning takes more effort, especially if your workload isn’t static. Getting started with Tempo on Chainstack The provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. Chainstack bundles the full stack into a setup that takes minutes to deploy: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Choose Tempo Mainnet or Testnet. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Once your endpoint is live, Tempo behaves like a standard EVM JSON-RPC network — for example, checking the latest block: curl -X POST https://YOUR_CHAINSTACK_ENDPOINT/YOUR_API_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 }' Conclusion The 2026 Tempo RPC providers landscape is more competitive and mature than ever. Chainstack leads as the top all-around provider, combining enterprise-grade performance and 99.99% uptime via multi-cloud routing, transparent request-based pricing ($5-$20/M for extra usage, or $0.25/M with Dedicated Nodes), and full SOC 2 Type II and ISO 27001 compliance. It perfectly serves stablecoin payments, and enterprise dApps include 70+ chain support.​ dRPC and Conduit serve more cost-conscious and early-stage use cases. dRPC fits testing and lightweight applications with simple regional endpoints, while Conduit offers broad multi-chain access and flexible pricing—but with fewer enterprise-grade features compared to top-tier providers. Alchemy remains a developer-first platform with rich tooling and a generous free tier, best suited for teams prioritizing productivity over raw infrastructure control. Quicknode is a strong choice for latency-sensitive workloads, offering solid throughput (500+ RPS on top tiers) and robust compliance certifications—though the comparison table above shows dRPC (~5,000 RPS) and Chainstack (600+ RPS) scaling to higher RPS ceilings. Stablecoin settlement and payment infrastructure: Chainstack (predictable pricing, SOC 2 Type II + ISO 27001). High-throughput bots and monitoring systems: dRPC’s pay-as-you-go, AI-routed capacity. Early-stage testing and prototyping: Conduit’s free tier and quick setup. Latency-sensitive production workloads with compliance needs: Quicknode. Deploy a Tempo RPC endpoint → FAQ What is Tempo RPC and why do I need it? Tempo RPC is the standard interface that lets applications communicate with the Tempo blockchain. Through an RPC provider, you can read blockchain data (balances, transactions), send transactions, deploy smart contracts, and interact with dApps using JSON-RPC API calls. Without reliable RPC, your app can’t connect to Tempo. Which Tempo RPC provider is best for production use? For production workloads, Chainstack is a strong option, combining predictable request-based pricing, scalable performance, 99.99% uptime, global low-latency routing, SOC 2 Type II and ISO 27001 compliance, and both free/enterprise tiers. It covers payment infrastructure, settlement systems, and high-frequency transaction needs better than competitors. Are there free Tempo RPC options suitable for real development? Yes. Chainstack offers 3M requests/month (~25 RPS) free with Tempo access and archive data. Alchemy gives 30M CUs (~1.2M requests), and Conduit includes a limited free tier suitable for testing and light usage. How do I connect to a Tempo RPC node? When you start building on Tempo, the provider you choose shapes your baseline for speed, reliability, and how easily you can scale over time. While different platforms cater to different use cases, Chainstack bundles the full stack into a setup that takes minutes to deploy:1. Log in to your Chainstack account (or create one if you don’t have it yet).2. Create a new project or select an existing one.3. Choose Tempo Mainnet or Testnet4. Deploy a node with RPC access and copy the HTTP or WebSocket endpoint into your app. Does Tempo RPC support WebSocket connections? Yes. Most top Tempo RPC providers, including Chainstack, Quicknode, and Conduit, support both HTTP and WebSocket endpoints for Tempo, so you can subscribe to real-time events such as new blocks and pending transactions in addition to making standard JSON-RPC calls. What RPS should I plan for on Tempo? It depends on your workload. Light applications can start on free tiers around 25 RPS, while high-throughput systems need higher ceilings: Chainstack scales beyond 600 RPS on paid plans (custom RPS on Enterprise), dRPC advertises pay-as-you-go throughput up to roughly 5,000 RPS, and Quicknode scales past 500 RPS on its top tiers. Check the comparison table above for exact figures before choosing a plan. Additional resources Chainstack Tempo product page — build better with Tempo. Stablecoin infrastructure — Chainstack’s stablecoin-focused infrastructure. Chainstack Enterprise plans — custom RPS, SLAs, and dedicated support. #### Best TRON RPC providers in 2026: pricing and performance Introduction TRON processes over $20 billion in daily stablecoin transfer volume across more than 7 million transactions per day. With $86 billion in circulating USDT, 373 million total accounts, and roughly 31% of global stablecoin supply sitting on the network, TRON is the second-largest blockchain by stablecoin market cap (behind Ethereum) and ranks among the top three chains by DeFi TVL (DefiLlama, TRONSCAN). TRON Stablecoins Mcap. Source: DefiLlama This isn’t speculative activity — the average TRON stablecoin transaction is around $6,400, consistent with commerce, remittances, and exchange settlement rather than trading (Arkham TRON Stablecoin Ecosystem Report, Jan 2026). For developers and infrastructure teams, this usage profile means one thing: the RPC node provider you choose for TRON is stablecoin infrastructure. It determines whether your payment processor handles volume spikes, whether your exchange backend confirms transfers in time, and whether your analytics pipeline keeps up with 7 million daily transactions without falling behind. TRON’s public endpoints aren’t built for this. TronGrid’s free tier caps at 15 QPS with an API key and throttles harder without one. For any production workload — payment systems, wallets serving millions of users, data indexing at scale — third-party RPC infrastructure is a core dependency, not an optional upgrade. This guide compares the best TRON RPC providers in 2026 across performance, pricing, protocol support, and enterprise readiness, mapped to the use cases that actually drive TRON adoption. TRON infrastructure specifics TRON’s infrastructure differs from a typical EVM chain in ways that directly affect provider selection. Understanding these differences helps you evaluate which provider features matter for your specific workload. API access: four interfaces, different trade-offs TRON exposes four distinct API interfaces. Most third-party providers support only a subset — knowing which ones your workload requires narrows the field immediately. /wallet — the native TRON HTTP API for full node operations including transaction creation and broadcast. Methods like broadcastTransaction, getAccount, and triggerSmartContract live here. This is what TronWeb.js connects to by default. /walletsolidity — confirmed-only data from the solidity node namespace. Useful when your application needs to read only finalized state (payment confirmation flows, balance verification). /jsonrpc — limited Ethereum-compatible JSON-RPC for read operations. Helpful if you have existing EVM tooling, but write methods (eth_sendRawTransaction, eth_getTransactionCount) are not available. Hardhat and Foundry can compile and test against this interface, but contract deployment and transaction submission require TronWeb through /wallet. gRPC — TRON’s high-performance binary protocol using HTTP/2 and Protocol Buffers. For exchange backends, data indexing pipelines, and any integration making thousands of calls per second, gRPC can meaningfully reduce serialization overhead versus JSON-RPC — check current benchmarks for your workload — and eliminates connection overhead through HTTP/2 multiplexing. Not all RPC providers expose TRON gRPC — this is one of the most meaningful differentiators in provider selection. For a detailed walkthrough of each interface with code examples across Python, Go, and JavaScript, Chainstack’s TRON tooling guide covers setup, proto file generation for gRPC, and integration patterns for TronWeb.js, web3.py, and Hardhat hybrid workflows. Throughput, fees, and the resource model TRON’s DPoS consensus produces blocks every 3 seconds via 27 Super Representatives, supporting 2,000+ TPS with 100% mainnet uptime since 2018 (TRONSCAN). Transaction costs use a bandwidth-and-energy model instead of conventional gas — TRC-20 transfers can cost fractions of a cent when a sender has staked TRX for resources. This is the primary reason payment processors and exchanges prefer TRON for stablecoin settlement. The resource model also creates an operational layer that most EVM developers don’t encounter. High-volume USDT transfer operations require managing energy delegation, bandwidth staking, and resource allocation across wallets. Chainstack’s guide on mastering energy and bandwidth with Python walks through programmatic resource management — a practical concern for any team running production payment infrastructure on TRON. Stablecoin concentration and what it means for RPC Tether (USDT) Mcap. Source: DefiLlama USDT (TRC-20) accounts for approximately 98% of stablecoins on TRON (DefiLlama). The network handles more USDT transfer volume than any other chain. In practice, this means your TRON RPC infrastructure is a USDT settlement pipeline. Provider evaluation should focus on how well the endpoint handles continuous triggerSmartContract calls against the USDT contract, how quickly /walletsolidity reflects confirmed state, and whether throughput holds during the volume surges that follow market volatility. WebSocket and event access Unlike EVM chains where eth_subscribe over WebSocket is standard, TRON nodes do not currently support WebSocket connections for event subscriptions. Event data is accessed through polling the /event API or provider-specific indexing services. If your application requires real-time notification of new USDT transfers or contract events, plan for polling logic or evaluate providers with event indexing layers. TRON RPC providers comparison 2026 Table 1: Overview — pricing, positioning, and free tiers #ProviderBest forFree planEffective cost per 1M requestsBilling predictability1ChainstackEnterprise, stablecoin infra, gRPC-dependent workloads3M req/mo, ~25 RPS~$10–20 (varies by plan tier)High — 1 RU per call, no method weighting2TronGridDevelopment, TRON-native event indexing100K req/day, 15 QPSFree (within daily cap) / opaque customLow — daily caps, throttling penalties3AnkrMulti-chain development, archive access on free tier200M credits/mo, ~30 RPS~$20 (at 200 credits/call)Medium — per-method weighting inflates costs4dRPCCost-optimized high-volume workloads, failover endpointFree tier (public nodes)$6 flatHigh — 20 CU per call regardless of method5QuicknodeMulti-chain teams needing formal SLA + complianceTrial onlyVaries by method mixMedium — requires method-mix modeling The table above covers pricing and positioning. The next table compares protocol support, data access, and compliance — the factors that typically determine the final provider decision for production workloads. Table 2: Technical capabilities — protocol support, data access, and compliance #ProvidergRPC supportArchive dataUptime / SLASOC 2WebSocket events1ChainstackYes (Mainnet + Nile Testnet)Full nodes (non-archive)99.99% formal SLA with service creditsType IINot supported (TRON limitation)2TronGridYes (native TRON gRPC)LimitedNo formal public SLANo public SOC 2Not supported (TRON limitation)3AnkrListed in docsFull and archive on Premium99.99% claimedType I (Type II in progress)Not supported (TRON limitation)4dRPCNo public TRON gRPCDepends on upstream providersMulti-provider routing; no formal SLANo public SOC 2Not supported (TRON limitation)5QuicknodeNo public TRON gRPCAvailable on paid plans99.99% formal SLAType II + ISO 27001Not supported (TRON limitation) Reading the tables gRPC is a real differentiator. Chainstack launched TRON gRPC support for Mainnet and Nile Testnet in January 2026. TronGrid offers gRPC natively. Most other third-party providers don’t expose it for TRON — for exchange backends and data pipelines, this narrows the field. Archive availability varies. Chainstack currently offers TRON full nodes (non-archive), meaning some deep-history methods are unsupported. If your workload requires historical state queries at arbitrary block heights, confirm archive support explicitly before committing. Pricing models diverge. Chainstack’s 1 RU per call (regardless of method) and dRPC’s flat 20 CU per request are the most predictable. Ankr’s credit model applies per-method weighting that inflates effective costs. TronGrid’s free tier is daily-capped and rate-limited — functional for development but not for production. Best TRON RPC providers: in-depth analysis Chainstack Chainstack is the only third-party provider that supports all four TRON API interfaces — /jsonrpc, /wallet, /walletsolidity, and gRPC — from a single endpoint. That coverage matters because TRON workloads typically span multiple namespaces: /wallet for transaction broadcast, /walletsolidity for confirmed state reads, and gRPC for high-throughput data access. Having all of them behind one provider with unified billing eliminates the complexity of routing different call types through different services. Exciting news is here 🔥TRON @trondao Mainnet and Nile Testnet now support gRPC!What this means for builders:🔹 Faster and more efficient data access🔹 gRPC endpoints for production workloads🔹 Designed for high-performance applicationsTry building on TRON with gRPC now…— Chainstack 💙🛠️ (@ChainstackHQ) January 26, 2026 The gRPC addition (January 2026, Mainnet and Nile Testnet) is the standout feature for enterprise and exchange teams. Chainstack’s TRON tooling documentation includes proto file setup, client code generation for Python and Go, and authenticated gRPC call examples — reducing integration time from days to hours. Beyond protocol support, Chainstack’s infrastructure options cover the spectrum: Global Nodes for geo-balanced routing across US, EU, and APAC; Dedicated Nodes for isolated compute when tail latency consistency matters (payment settlement windows, exchange hot wallet operations); and the Unlimited Node add-on for flat monthly pricing with no request limits during unpredictable burst windows. The full TRON API reference covers every supported method across all four interfaces. For teams evaluating whether to use public or private TRON RPC — and what the practical differences look like in production — Chainstack’s article on how to get a TRON RPC node breaks down the trade-offs between free public endpoints, managed private nodes, and self-hosted infrastructure. 🤖 You can also access Chainstack TRON RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. Learn more about Chainstack MCP. DetailsPricingDeveloper — free, 3M req/mo (~25 RPS). Growth — $49/mo, 20M req (~250 RPS). Business — $499/mo, 200M req (~600 RPS). Enterprise — from $990/mo, 400M+ req, custom RPS. Dedicated Nodes — $0.50/hr compute. Crypto payments accepted.Billing modelRequest Units: 1 RU per full node call. No method-weight multipliers.gRPCSupported on TRON Mainnet and Nile Testnet. Requires proto files from the official TRON protocol repository.Archive dataFull nodes (non-archive). Some deep-history methods unavailable.Uptime / SLAFormal SLA: 99.99% minimum with service credits. Global/Dedicated positioning: 99.99%+.SecuritySOC 2 Type II and ISO 27001. IP and origin access rules for endpoint protection. For enterprise teams: SOC 2 Type II and ISO 27001 artifacts are available for vendor risk assessments. The distinction between the formal SLA (99.99%) and product-level positioning (99.99%+) is worth noting for procurement documentation — both figures exist and serve different purposes. Pros: Full TRON API coverage (all four interfaces), gRPC support, transparent RU billing, Dedicated Node isolation, SOC 2 Type II and ISO 27001, 70+ chain support, access controls, MCP server support for AI agent integrations. Cons: TRON nodes are full only (non-archive); WebSocket event subscriptions not supported (TRON protocol limitation); free tier is tight for production indexing; Dedicated Nodes require at least Business plan. TronGrid TronGrid is the official TRON Foundation infrastructure and the default endpoint bundled with TronWeb.js. It’s where most developers start, and for good reason — TronGrid exposes the complete native API surface including gRPC (port 50051 for Full Node, 50061 for Solidity) and a PostgreSQL-backed event indexing layer that no generic RPC provider fully replicates. The event API is TronGrid’s unique strength. Contract event queries, transaction monitoring by address, and time-range event filtering are purpose-built for TRON and provide capabilities that teams otherwise need to build themselves or source from a separate indexer. The trade-offs are rate limits and enterprise readiness. The free tier caps at 100K requests/day with 15 QPS — enough for development, not for production. Penalty mechanics are aggressive: exceeding limits triggers a 30-second access block returning 403 errors. Custom plans exist but require direct engagement with the TRON Foundation, and there is no published SLA or SOC 2 certification. DetailsPricingFree: 100K req/day, 3 API keys, 15 QPS. Custom: contact TRON Foundation.Billing modelDaily request quotas. Overage triggers throttling, not billing.gRPCNative support (port 50051 / 50061).Archive dataLimited. Event indexing covers historical events; full archive state not publicly documented.Uptime / SLANo formal public SLA.SecurityNo public SOC 2. API key authentication only. Pros: Official TRON infrastructure, native gRPC, purpose-built event indexing, deep TronWeb.js integration, comprehensive API docs. Cons: 15 QPS ceiling, aggressive throttling penalties, no formal SLA, no SOC 2, TRON-only, opaque custom pricing. For teams evaluating TronGrid alternatives with higher throughput, formal SLAs, and enterprise compliance, the remaining providers in this comparison address those gaps Ankr Ankr’s value proposition for TRON is breadth — 80+ networks on Premium, archive data on all tiers, and a 200-million-credit free tier that’s genuinely useful for development and testing. The platform spans 30+ global regions with bare-metal infrastructure and offers Advanced API for pre-indexed, cross-chain queries alongside standard RPC. The pricing trap is well-documented but worth repeating. Ankr charges $0.10 per million API credits, but standard TRON methods consume 200 credits each. That translates to roughly $20 per million actual requests — among the highest effective per-request costs in this comparison. For production TRON workloads processing millions of calls daily, this math matters more than the headline rate. Premium is required to unlock features most teams consider baseline for production: WebSocket access, debug/trace methods, IP whitelisting, and multi-project statistics. The free and Freemium tiers are development-only in practice. DetailsPricingFree: 200M credits/mo, ~30 RPS. Premium: PAYG at $0.10/1M credits. Deal packs available.Billing modelAPI credits with per-method weighting. 200 credits per standard TRON call.gRPCListed in Ankr’s pricing docs.Archive dataAvailable on all tiers.Uptime / SLA99.99% claimed, 56ms average response time.SecuritySOC 2 Type I (Type II in progress). Pros: Generous free tier, 80+ chains, archive on all tiers, 30+ global regions, Advanced API for indexed queries. Cons: $20/1M effective per-request cost; Premium required for production features; SOC 2 Type II and ISO 27001 not yet completed; TRON-specific features less developed than dedicated providers. dRPC dRPC takes a fundamentally different approach — it’s a decentralized routing layer that distributes requests across multiple independent node operators. For TRON, this means built-in redundancy against any single provider going down. The pricing is the simplest in this comparison: every method costs a flat 20 CU, working out to $6 per million requests regardless of call complexity. That cost predictability is dRPC’s strongest selling point for TRON. Workloads heavy on triggerConstantContract and getTransactionInfoById cost the same as simple getAccount calls — no credit-weight surprises. For high-volume, cost-sensitive operations (analytics pipelines, bulk transaction monitoring), the math is straightforward. The trade-off is consistency and enterprise readiness. Latency varies across the distributed provider network — one request might hit a fast node, the next a slower one. There’s no formal SLA, no SOC 2, and TRON may require a paid plan. For a secondary/failover provider or for workloads where cost matters more than tail latency, dRPC makes sense. For primary production infrastructure serving payment flows, the absence of formal guarantees is a gap. DetailsPricingFree tier (public nodes). Paid from $10/mo. $6 per 1M requests.Billing modelFlat-rate: 20 CU per request regardless of method.gRPCNot publicly documented for TRON.Archive dataDepends on upstream providers.Uptime / SLAMulti-provider routing; no formal SLA.SecurityNo SOC 2. API key management available. Pros: Flat-rate pricing, multi-provider redundancy, 95+ chains, 5,000 RPS ceiling, no vendor lock-in. Cons: No formal SLA; no SOC 2; TRON may require paid plan; inconsistent latency; no gRPC; archive access not guaranteed. Quicknode Quicknode brings operational maturity and the strongest compliance posture in this comparison — SOC 2 Type II, ISO 27001, and a formally guaranteed 99.99% uptime SLA. For teams already running Ethereum or Solana workloads on Quicknode, adding TRON to the same dashboard simplifies multi-chain infrastructure management. TRON-specific protocol depth is where Quicknode is thinner. The platform provides HTTP API access compatible with TronWeb.js, but gRPC for TRON is not publicly documented. For workloads where gRPC performance matters (exchange backends, high-frequency data pipelines), this is a gap. The platform’s Streams and Webhooks tooling — strong on EVM chains — has more limited applicability on TRON given the network’s different event model. The credit-weighted pricing also requires attention. TRON workloads dominated by triggerSmartContract calls (every TRC-20 balance query or transfer simulation) will consume credits faster than simple balance lookups. Model your actual method mix against the credit schedule before committing — the effective per-request cost for TRON-heavy workloads may differ significantly from headline pricing. DetailsPricingTrial only (no permanent free tier). Paid plans with credit bundles. Enterprise: custom with SLA. 15% annual discount.Billing modelAPI credits: method-weighted. Heavier TRON methods consume more credits.gRPCNot publicly documented for TRON.Archive dataAvailable on paid plans.Uptime / SLA99.99% formally guaranteed. Dedicated clusters for enterprise.SecuritySOC 2 Type II + ISO 27001. Pros: 99.99% formal SLA, SOC 2 Type II + ISO 27001, 70+ chains, Streams and Webhooks, dedicated clusters, strong operational track record. Cons: No permanent free tier; method-weighted credits complicate TRON cost modeling; no public TRON gRPC; TRON-specific tooling is less developed than EVM chains. How to choose a TRON RPC provider If you’re building stablecoin payments or settlement Your endpoint needs to sustain continuous broadcastTransaction and triggerSmartContract calls against the USDT contract without degrading during volume spikes. Flat billing matters — payment volume is hard to predict and credit-weighted models produce invoice surprises. First choice: Chainstack Dedicated Nodes with gRPC for high-throughput settlement, plus the energy and bandwidth management guide to optimize per-transaction costs. Chainstack’s stablecoin infrastructure page details how the platform is architected for this exact workload profile. Alternative: Quicknode for teams that prioritize the 99.99% formal SLA above all else. Explore stablecoin-ready infrastructure → If you’re running exchange or fintech integrations gRPC narrows the field to Chainstack and TronGrid. SOC 2 narrows it further to Chainstack. Exchange backends processing thousands of balance lookups and transaction broadcasts per second get measurable performance gains from protobuf serialization — see the gRPC setup examples in the TRON tooling docs. First choice: Chainstack (gRPC + SOC 2 Type II and ISO 27001 + Dedicated Nodes for isolated compute that doesn’t share resources during peak settlement windows). Supplement with: TronGrid’s event indexing for contract monitoring where its purpose-built query layer adds value. Request Dedicated node → If you’re indexing data or running analytics Volume and cost predictability are the primary concerns. Archive access matters if you need historical state — confirm support explicitly. First choice: dRPC at $6/1M requests for bulk workloads where latency consistency is less critical. Alternative: Chainstack’s RU model for workloads that also need gRPC access to the full TRON API surface. If TRON is one chain among many in your stack Consolidation reduces operational overhead. Evaluate whether your multi-chain provider’s TRON support includes the specific interfaces you need — many multi-chain platforms support TRON’s HTTP API but not gRPC or the event namespace. Broad coverage: Ankr (80+ chains, archive on all tiers) or dRPC (95+ chains). Deeper TRON integration within multi-chain: Chainstack (70+ chains with full TRON API coverage including gRPC). Pricing reality check ProviderEffective cost per 1M TRON requestsBilling predictabilityChainstack~$10–20 (varies by plan tier)High — 1 RU per call, no method weightingTronGridFree (within daily cap) / opaque customLow — daily caps, throttling penaltiesAnkr~$20 (at 200 credits/call)Medium — per-method weighting inflates costsdRPC$6 flatHigh — 20 CU per call regardless of methodQuicknodeVaries by method mixMedium — requires method-mix modeling Enterprise TRON infrastructure Compliance posture SOC 2 Type II and ISO 27001 is the baseline for enterprise blockchain infrastructure procurement. The current landscape: Chainstack — SOC 2 Type II and ISO 27001 (achieved late 2025). Access controls include IP whitelisting and origin restrictions. Ankr — SOC 2 Type I (Type II in progress). TronGrid, dRPC — no public SOC 2 certification. Quicknode — SOC 2 Type II + ISO 27001. Dedicated clusters with SLA-backed support. For exchange integrations and licensed payment processors, this narrows the primary provider choice to Chainstack or Quicknode. TronGrid and dRPC can serve as secondary or failover endpoints where formal compliance isn’t required for every provider in the stack. Chainstack’s enterprise infrastructure page covers SOC 2 certification details, SSO and 2FA support, custom SLAs, and dedicated account management for regulated teams. Request enterprise plan → gRPC as enterprise protocol For enterprise-grade TRON integrations, gRPC isn’t a performance optimization — it’s the correct protocol choice. Binary serialization reduces payload sizes, HTTP/2 multiplexing handles high-frequency call patterns without connection overhead, and strongly typed protobuf definitions catch integration bugs at compile time rather than runtime. Chainstack is currently the only third-party provider offering TRON gRPC alongside enterprise compliance (SOC 2 Type II and ISO 27001). Recommended production architecture For mission-critical TRON workloads, run a multi-provider setup: primary traffic through a provider with formal SLA and gRPC (Chainstack Dedicated Nodes), with automated failover to a secondary provider (Ankr or dRPC) triggered by latency degradation or error rate thresholds. For teams new to TRON infrastructure — including the decision between public endpoints, managed private nodes, and self-hosted options — Chainstack’s guide on how to get a TRON RPC node covers the practical trade-offs and setup steps for each approach. Conclusion TRON’s role as the dominant stablecoin settlement rail means your RPC provider choice is, in practice, a payments infrastructure decision. Here’s how the field breaks down: Chainstack is the most complete option — the only third-party provider with all four TRON API interfaces (/jsonrpc, /wallet, /walletsolidity, gRPC), SOC 2 Type II and ISO 27001, transparent per-request billing, and Dedicated Node isolation. If you need gRPC for enterprise throughput and compliance artifacts for procurement, Chainstack is the default. TronGrid is the right development starting point and the only provider with purpose-built TRON event indexing. Production use requires a custom plan to escape the 15 QPS ceiling. Quicknode offers the strongest formal SLA (99.99%) and dual compliance certifications (SOC 2 Type II + ISO 27001). Best for teams adding TRON to an existing Quicknode multi-chain stack where TRON gRPC isn’t required. dRPC delivers the lowest cost at scale ($6/1M requests) with the simplest billing model. Best as a primary provider for cost-sensitive, high-volume workloads or as a failover endpoint in a multi-provider architecture. Ankr provides the broadest free tier and archive access on all plans. Watch effective per-request costs — at $20/1M actual requests, production economics require careful modeling. For TRON in 2026, choose based on what the network actually does: settle stablecoins, process payments, and power fintech infrastructure at scale. The provider that matches your protocol requirements (gRPC or HTTP), compliance obligations (SOC 2 or not), and billing model (flat or method-weighted) is the right one. Other providers serving TRON include Dwellir, GetBlock, NOWNodes, Tatum, and TronQL — each with different coverage, pricing structures, and infrastructure approaches. The TRON developer hub maintains a list of recommended providers alongside public seed nodes for reference. Building on TRON? Deploy your TRON node on Chainstack → FAQ What is a TRON RPC URL? An HTTP endpoint that connects your application to the TRON blockchain without running your own node. Most TRON RPC URLs point to a Full Node’s /wallet endpoint for general operations or /walletsolidity for confirmed-only data. Unlike Ethereum, TRON’s native API uses REST-style HTTP calls rather than JSON-RPC for most operations. Does TRON support MetaMask? No. TRON uses a different address format (Base58), fee model (bandwidth/energy), and RPC design than Ethereum. You cannot add a TRON RPC URL to MetaMask. Use TronLink or Trust Wallet for native TRX and TRC-20 tokens. Is TronGrid free? TronGrid’s free tier allows 100,000 requests per day at 15 QPS. Exceeding limits triggers a 30-second access block. For production workloads, the free tier is insufficient — custom plans exist but require contacting the TRON Foundation directly. What is the difference between TRON HTTP API and gRPC? HTTP API (/wallet) uses JSON over HTTP/1.1 — simpler, what TronWeb.js connects to by default. gRPC uses HTTP/2 with Protocol Buffers, and can meaningfully reduce payload sizes versus JSON-RPC — check current benchmarks for your workload — using persistent connections. Use HTTP for typical dApp development; gRPC for exchange backends and high-throughput data pipelines. How do I choose between TRON RPC providers? Several providers offer free TRON RPC access: Chainstack (3M req/mo), TronGrid (100K req/day), Ankr (200M credits/mo), and dRPC (public nodes). For production, start with your workload profile — stablecoin payments need gRPC and flat billing (Chainstack), compliance-heavy integrations need SOC 2 (Chainstack or Quicknode), cost-sensitive analytics need flat-rate pricing (dRPC). The comparison tables and “How to choose” section above map providers to specific use cases. Build with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. Related Reading How to get a TRON RPC node TRON Tooling TRON node API TRON: Mastering Energy & Bandwidth with Python and Chainstack #### BetSwirl on Chainstack: Paving the way for decentralized gaming on Metaverse BetSwirl is a new online cryptocurrency gaming platform that is fully decentralized and anonymous. This means that everyone can enjoy a fair game, have an enjoyable time, and experience something innovative. What does BetSwirl do? The platform offers a unique interactive gaming experience, enriched by animations, sound effects, and an upcoming Metaverse integration. BetSwirl supports popular games like Dice, Coin Toss, Million Jackpot, and more. It is made for easy access, allowing players to use the token of your choice—MATIC, USDC, BETS, and others. Powering the protocol is the platform’s token $BETS, presenting multiple use cases and deflationary mechanisms. Apart from that, the platform offers a staking program, allowing the community to claim a share of the project’s profits. BetSwirl also features a multi-level referral program, which creates opportunities for users to multiply their gains. The more referrals, the higher the reward. All this runs through a system that offers complete transparency through the protocol analytics dashboard. Overall BetSwirl utilizes a community-driven approach and presents multiple incentives, rewards, and special surprises for the most dedicated users. How did BetSwirl come across Chainstack? BetSwirl’s team was looking for a robust WebSocket Node API to power their platform’s services when they began their search. This API needed to support the platform’s rigorous requirements, especially when it came to uptime and stability. Without access to such WebSocket node, BetSwirl’s services would suffer from downtime issues that would plague their users’ gameplay experience. And in the world of online gaming, more downtime translates to fewer profits, more unsatisfied players, and a severe hit to the project’s reputation. After looking into potential options, available on the market, the BetSwirl team discovered that only Chainstack presented a suitable solution in the form of the WebSocket API. For the purposes of the project, such API delivers better performance, considering its speed over HTTP and most importantly offers real-time updates. With a swift and scalable deployment, our team was fully able to match BetSwirl’s desired uptime and requirements in a cost-effective manner. How does the Chainstack offer match BetSwirl needs? Above anything else, BetSwirl needed the means to offer a smooth and stable gameplay experience to its users. To do that, they leveraged the Chainstack WebSocket API to inform the community of bet resolutions in real-time. Aside from that, they wanted to extend their support to other layer one solutions, like Avalanche and BNB Smart Chain, as well as other side chains. To accomplish this, Chainstack offered BetSwirl a complimentary Business plan trial. In doing so, their team took full advantage of Chainstack’s reliable node infrastructure to build and test upon in the crucial moments leading up to the project’s launch. Chainstack’s commitment to creating a truly multi-chain platform that is flexible enough to respond to customization, accessibility, and scalability needs from projects was a perfect fit for BetSwirl. Our team delivered on all their requests, resolving the above-mentioned roadblocks quickly and effectively. Outcome After deploying Chainstack’s flexible infrastructure, BetSwirl was able to offer its users swift access to its core services on Polygon. The deployment of our solution proved vital for the streamlined experience the BetSwirl team was looking for. Ever since the mainnet launch in March, the platform has been successfully handling a volume of more than 110,000 request calls for a total of 1416 bets from 68 players. This allowed early BetSwirl players to start enjoying a truly mainnet experience, even before the platform’s official launch by scaling 2200% with ease. BetSwirl were excited to see their services running without any disruption, whatsoever, highlighting Chainstack as the solution that stood out in this regard. Our teams worked together in resolving any issues encountered, such as the case of Brave Global Shield. Chainstack worked closely with the platform’s development team and delivered a solution for the challenge at hand, quickly and effectively. What does BetSwirl like about Chainstack? We met Chainstack’s team when we were unable to use the WebSocket feature which is required for our gameplay to be as smooth as possible, Chainstack has provided us with exceptional service that is highly responsive, supporting our requirements with a tailored business plan solution that just works! Romuald Hog, CEO, BetSwirl What does Chainstack like about BetSwirl? BetSwirl offers an innovative and interactive take on the online gaming genre. Its fully decentralized and anonymous approach creates a transparent environment that fosters trust, where many other alternatives fail. We are excited to work with BetSwirl in disrupting the gaming sphere and paving the way towards complete Metaverse integration. Eugene Aseev, CTO & Founder, Chainstack What is the most interesting engineering challenge in working together? By far the most interesting engineering challenge we encountered with BetSwirl was the strong security setting offered by the Brave Global Shield. While this normally works great for user privacy, it also brings undesired prevention of other vital connections that can interrupt core services. In Chainstack’s mission to make Web3 accessible for all, reliability and security are key components to better adoption. Our robust and flexible infrastructure provided a sensible and cost-effective approach for the product development initiatives of BetSwirl and quickly resolved any future disruption to the platform’s experience, caused by Brave. This allowed BetSwirl to successfully conduct testnet trials that effectively translated into a seamless experience for their users post-launch. Are you looking to take advantage of a scalable WebSocket Node API that can deliver results at scale? Secure high-performing infrastructure for your project, available at the click of a button today: Power-boost your project on Chainstack Connect to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, Solana, Harmony, and Tezos mainnet or testnets through the interface designed to help you get the job done. Get access to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, and Tezos archive nodes to query the entire history of the mainnet—starting at just $49 per month. Choose where you want to deploy, and we will provide you with the dedicated managed infrastructure that can handle high-volume, high-velocity read/write access to the network. To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### Beyond monolithic: Modular blockchain architecture and the Scalability Trilemma The advent of blockchain technology significantly changed various industries, offering transparency in a decentralized system. Blockchain’s profound impact can especially be seen in innovative transaction processes that brought unprecedented tracking capabilities to supply chains and simplified the process of international payments. In public blockchains, validators, who are motivated by self-interest, play a crucial role in transaction recording. However, the sustainability of these incentives can often lead to network congestion and high fees. This has shifted the preference towards alternative blockchain models, which might favor higher transactions per second (TPS) over security and decentralization. This diversity in blockchain designs also contributes to the inherent fragmentation within the sector. High chain performance, scalability, and adaptability largely depend on its architecture and design. To overcome these challenges and improve scalability, Web3 developers are turning to modularity—a strategy that segments a blockchain into smaller, autonomous parts, thereby increasing flexibility and efficiency. Embracing modularity in blockchain architecture design Rather than having a blockchain technology that encompasses all its functional dimensions within a single system (a monolithic blockchain), modularity aims to break down the blockchains into smaller, self-contained parts. The idea is to increase flexibility and efficiency, promote innovation, and reduce transaction times, in order to improve the overall user experience. By breaking the blockchain down into autonomous parts, developers can fine-tune the individual sections to better handle specific tasks within the network. This customized approach to design allows for seamless integration and optimized network performance. However, maintaining high-level security in a decentralized network while also supporting a large volume of transactions is a complex challenge for blockchain technology. This challenge is known as the Scalability Trilemma and serves as the foundational model for blockchain architecture design. Unraveling the Scalability Trilemma The Scalability Trilemma or the Blockchain Trilemma as it is also known as, refers to the complex and delicate balance that public blockchains face when striving to attain three critical aspects: Security: Providing reliable consensus and unchangeability. Decentralization: Ensuring broad-based control of the network. Scalability: The capability of handling many transactions simultaneously. To fulfill these objectives at once becomes challenging, often resulting in the need for significant trade-offs among these key attributes. In turn, these trade-offs form the essence of the trilemma. Figure 1: The Scalability Trilemma (Blockchain Trilemma); Source: BlockchainSentry Blockchains that focus on decentralization and security exhibit strong resilience against manipulation due to robust consensus mechanisms. However, they often encounter hardships with scalability. In contrast, blockchains created with scalability and security as priorities often compromise some degree of decentralization. Consequently, those which opt for decentralization and scalability tend to suffer from security issues. This trilemma poses a significant challenge for the development and adoption of blockchain technology. However, with modularity in performance and design, the industry is starting to see a way of addressing this trilemma more effectively. The core layers of blockchain architecture Blockchain architecture consists of four fundamental layers that facilitate its effective functioning: Execution: This layer is responsible for the actual processing of transactions within the chain. It involves nodes carrying out transactions, moving the blockchain from one state to the next. The execution layer is vital for user engagement within the protocol, enabling them to submit transactions, interact with smart contracts, and transfer assets. Settlement: Settlement acts as the stabilizing force of the blockchain, ensuring the permanency of transactions. It confirms the irreversibility of transactions, preventing any alteration, by verifying and settling discrepancies. Consensus: The consensus layer is fundamental for decision-making within the blockchain. This is where the nodes agree on the validity and order of transactions, maintaining a unified and consistent state across the blockchain network. Data Availability: This layer focuses on ensuring that data is consistently available within the network. It involves the distribution of transaction data by block creators, confirming that other participants in the network can easily access and store this data for the integrity and efficiency of the network. These layers, collectively, support the efficiency and security of the blockchain, whether it has a monolithic or modular design. Understanding these layers makes it clear how different operational facets of a blockchain are interlinked in ensuring successful interactions with the protocol. Figure 2: Layers of modular chains; Source: VISA Understanding monolithic and modular blockchain architecture Blockchain architecture impacts its performance, scalability, and adaptability significantly. To amplify efficiency and determine the most suitable option for a project, it is important to understand the differences, strengths, and weaknesses between monolithic and modular designs. Monolithic blockchain designs In monolithic blockchain architectures, all functions are consolidated into a single layer or a network of interlinked chains functioning at one level. Every node within these chains handles multiple responsibilities, including achieving consensus, ensuring data availability, and overseeing transaction verifications. Solana and Ethereum prior sharding serve as classic examples of monolithic architectures with their integrated design, requiring each node to process blocks individually while maintaining a copy of their own ledger. While this reinforces security and decentralization, it also constrains the protocols’ ability to process large volumes of transactions or scale effectively as adoption grows. Modular blockchain architecture In contrast, modular blockchains consist of distinct units, each specializing in a specific operation. This division simplifies the process of development, testing, and maintenance while simultaneously improving scalability and flexibility. Modular blockchain architectures function as a set of specialized units, with each module fine-tuned to perform its own specific function efficiently. This encourages a cohesive ecosystem of interoperable chains where developers have the freedom to integrate different modules to meet specific project requirements. Rollups, whether they are optimistic like Arbitrum and Optimism, or zero-knowledge (ZK) such as Scroll and zkSync Era, which aim to improve the scalability of monolithic systems, stand out as an example in the arena of modular blockchains. Monolithic vs modular blockchain architecture Making an informed choice between monolithic and modular blockchain architectures requires considering their distinct attributes and implications. These two architectures vary considerably in aspects such as scalability, flexibility, complexity, and security. Here’s a comparison of the two: CriteriaMonolithicModularScalabilityStruggles with scalability, often at the cost of either decentralization or security due to inherent limitations.Specifically engineered to enhance scalability by fine-tuning individual modules for better performance.FlexibilityCharacterized by a less flexible, unified structure that limits customization and adaptability.Offers a high degree of adaptability through its composition of specialized chains, each designed for specific tasks.ComplexityFeatures a straightforward, single-layer structure, which is easier to grasp but less flexible.Inherently more intricate, integrating multiple components that require advanced security protocols for safe operation.SecurityOffers robust security via comprehensive node validations, supported by data redundancy across the network.Security is contingent on the reliability of each module, posing a risk of systemic issues if any component fails.ComposabilityFacilitates a cohesive DApp ecosystem within a single network, streamlining interactions and functionality.Could face challenges in DApp integration due to the involvement of disparate systems, potentially leading to operational inefficiencies.State ManagementOften grapples with state bloat resulting from transaction accumulation, affecting hardware demands and network decentralization.Utilizes approaches like data sharding to efficiently manage data growth, thus alleviating state bloat concerns.Cross-chain SecurityThe equilibrium between security, decentralization, and scalability is tough to maintain, complicating the shared security paradigm in a multi-chain setup.Can boost security by tapping into the security models of parent chains, a significant advantage for Layer 2 solutions.ExecutionConfined to a uniform operational environment, albeit with the advantage of network-wide access to resources via smart contracts.Provides more operational sovereignty, permitting specific adjustments to the technological stack as needed.Developer ExperienceTends to be more developer-friendly due to established methods and accumulated experience in its usage.Represents a newer, more experimental domain, necessitating a deeper learning curve and expertise in novel technologies.UpgradabilitySystem upgrades can be challenging, often requiring a comprehensive overhaul and risking extended downtime.Promotes smoother, incremental enhancements, reducing the likelihood of complete system failures and minimizing operational interruptions.Figure 3: Monolithic vs Modular blockchain architecture comparison This comparison underscores the trade-offs when choosing between monolithic and modular blockchain architectures. Each has its own benefits and challenges, catering to the diverse needs of Web3 developers, their projects, and users within the landscape. Degrees of modularity in blockchain architecture design Blockchain architecture is in a state of constant flux, giving rise to a diverse range of designs. From fully integrated monolithic systems to highly fragmented modular setups, blockchain architectures can be categorized into four primary types, each representing a different approach to modularity: Monolithic: Notable examples in this category include Bitcoin, Ethereum prior sharding, and Solana. These chains handle all core blockchain functions internally without dependence on external blockchain networks. Polylithic: Chains like Avalanche (Subnets), Polygon (CDK), Starknet (Appchains), and zkSync Era (Hyperchains), exemplify the polylithic model. This structure is characterized by a foundational layer that interconnects a series of chains with varying degrees of similarity. They distribute network functions across several subnetworks, all reliant on the main network. Semi-modular: In this category, you will find chains like Ethereum (post data sharding updates) and Tezos. These networks combine internal operations with external systems for specific functionalities. While they manage some processes internally, they delegate other functionalities to external, specialized networks. Despite this, semi-modular blockchains maintain the capability to process and validate transactions within their own ecosystem. Modular: This category includes networks like Aptos and execution-specific protocols such as Arbitrum, Optimism, and Scroll. Such protocols specialize in particular functions and are not equipped to manage all operational aspects on their own. The degree of modularity a blockchain design adopts depends on the specific needs of a project and the tradeoff it is willing to make between decentralization, security, and scalability—the three components of the Blockchain Trilemma. Figure 4: Spectrum toward blockchain modular design; Source: VISA Modular blockchains in the future to come Since Bitcoin’s launch in 2009, blockchain technology has seen significant transformations, particularly in its design and structural aspects. The initial focus on decentralization and security has expanded to include scalability and adaptability for real-world applications. Consequently, blockchain designs now exhibit varying degrees of modularity, each tailored to cater to the specific needs and challenges of different applications and use cases. Modular designs, while offering flexibility, scalability, and specialization, do add an extra layer of complexity, which requires cross-chain coordination, as well, in order to function properly. However, as blockchain technology and its applications continue to develop, the modularity spectrum is likely to expand, giving rise to novel and inventive design approaches. But alongside the burgeoning modular ecosystem, there is also a resurgence in new monolithic designs focused on scalability, such as the Oasis Sapphire protocol. These emerging trends in blockchain architecture indicate that the ongoing diversity in design and innovation will continue to enrich the Web3 landscape in the years to come. Bringing it all together As blockchain technology continues to evolve, the shift from monolithic to modular designs is becoming increasingly evident. This transition speaks to the technology’s ability to adapt its architecture and functionality to meet the demands of increasing complexity, scalability, and diversity in its applications. While monolithic designs emphasize a comprehensive, all-in-one approach that favors security and decentralization, the evolving industry necessitates more adaptable solutions. Modular blockchains are meeting this demand by developing specialized, interoperable layers that offer a balance of security, scalability, and decentralization, addressing the blockchain trilemma more effectively. However, it’s crucial to understand that each type of architecture has its strengths and weaknesses, and the choice between monolithic and modular should be navigated carefully. A decision should be driven by the specific needs of a project or its use case, considering factors such as adaptability, scalability, security, and the target audience’s technical proficiency. Regardless of the type of architecture chosen, it’s evident that as blockchain technology matures, so does its versatility and potential. Whether through the robust, proven security of monolithic designs or the flexibility and scalability of modular architectures, blockchain technology continues to redefine the realms of digital transactions and beyond. It’s an exciting time for developers, businesses, and individuals alike in the world of blockchain. The future holds even more promise as we explore further into uncharted territories of this truly revolutionary technology. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Bitcoin halving: What to expect from the fourth halvening event due to go live on April 24, 2024 Next month, on the 24th of April, 2024, Bitcoin’s ecosystem will experience yet another milestone event—the Bitcoin halving, also known colloquially as the halvening. As one of the most anticipated moments in the history of Bitcoin, halving is not a new phenomenon and has happened twice before 2020. Every four years or precisely every 210,000 blocks, the number of new Bitcoins entering circulation witnesses a decline. This change in Bitcoin’s minting rate incites speculations of possible wealth accumulation, given that the tightened supply, in theory, should maintain the demand, and maybe even drive the price of Bitcoin up. Thus, the halving event triggers passionate debates extending to price predictions and market responses. However, the impact of halving extends beyond immediate financial implications. The reduction in block rewards over time could significantly affect the operational structure of Bitcoin. Considering the dwindling rewards, there’s a chance of destabilization in Bitcoin’s security, challenging the economic incentives that underpin it. As we stand on the cusp of the next Bitcoin halving, destined for the 24th of April, it’s about time we delve into the intricate workings of this complex topic. The concept of block rewards in Bitcoin Block rewards are an integral component of the Bitcoin ecosystem. New Bitcoins enter circulation as block rewards, and these are generated by miners who apply their computational power to earn, or ‘mine’, them. A fascinating aspect to note in this mechanism is the event, roughly every four years when the total number of Bitcoin that miners can potentially win is halved. In 2009 when Satoshi Nakamoto launched Bitcoin, successful miners were rewarded with 50 BTC every 10 minutes. Fast forward to three halvings later, only 6.25 BTC are being dispensed every 10 minutes. This process, driven by the enigmatic vision of Bitcoin’s pseudonymous creator, Satoshi Nakamoto, is set to end once the number of Bitcoins in circulation reaches 21M—a milestone anticipated to occur near the year 2140. Figure 1: Bitcoin halving block rewards; Source: Crypto.com As of this moment, more than 18.5M BTC are circulating, and with the upcoming halving event slated for April 24th, the issuance rate will decrease even further. While there are concerns regarding the potential devaluation as a result of the finite distribution, supporters argue that scarcity is one of the defining factors contributing to Bitcoin’s store of value. Bitcoin’s halving effect The impact of Bitcoin halving is multi-dimensional. Starting with how it affects Bitcoin’s circulation, it’s noteworthy that halving is ultimately a mechanism implemented to control inflation. Since the introduction of Bitcoin in 2009, there have been three halving events (in 2012, 2016, and 2020). Each of these has corresponded with a decrease in the rate new Bitcoins enter circulation which in turn can lead to a price increase assuming demand remains constant. Figure 2: Bitcoin’s halving timeline; Source: CoinDesk Focusing on Bitcoin’s price, history does appear to suggest that each halving event has marked the beginning of a price surge. The halving in November 2012 was followed by an impressive bull run, rocketing Bitcoin’s price successes. The same pattern recurred following the 2016 halving. However, it’s essential to be wary of the misconception that a price surge always succeeds in halving. Other factors like market demand, technological advancements, and global economic conditions have significant roles to play. When engaging in debates regarding the price effects of Bitcoin’s halving, it’s crucial to keep in mind that cryptocurrency markets are notoriously volatile and unpredictable. Past trends may not necessarily dictate future outcomes. Scholars and analysts widely diverge in their forecasts, with some predicting significant price increases and others forecasting milder impacts or even a potential price drop. What matters the most is the block being halved and its value. Including transaction fees, the block’s value is set by the market. However, as block rewards decrease and eventually disappear, the transaction fees’ role in Bitcoin’s price determination will become increasingly significant, adding another dimension to the halving impact. Upcoming challenges for Bitcoin miners This brings us to Bitcoin miners—the guardians of the Bitcoin network—and the absolute significance of block rewards for them. They expend considerable resources, in terms of hardware and electricity, to solve complex mathematical problems, thereby earning the privilege of adding a new block to the Bitcoin blockchain. The block reward, combined with transaction fees, offsets their costs and keeps the system lucrative for them. Figure 3: Bitcoin mining reward and supply over the years; Source: CoinGecko However, when the rewards are halved, the miners’ revenue takes a hit. This leads to at least two potential outcomes: first, miners who operate with slim profit margins may be forced out of business. Second, miners may try to stay profitable by investing in more powerful and efficient hardware, thereby escalating the stakes in the ‘mining arms race’. Formulating effective strategies post-halving becomes a focal point for Bitcoin miners. Some might lean on energy-efficient hardware, while some might look for geographical locations with cheaper electricity. It is indeed a challenge for them to mitigate costs while juggling the demanding protocols of the Bitcoin network. The efficiency and costs of Bitcoin mining equipment play a significant role in the profitability of mining operations. One must optimize hardware design toward power efficiency while maintaining competitive processing capabilities. This operational balance has spurred several advancements in Bitcoin mining technology, making it more sophisticated and greener. Several innovative solutions for post-halving revenue have emerged, such as the adoption of cutting-edge mining equipment and the use of renewable energy sources. The long-term sustainability of these solutions is yet to be tested, raising intriguing questions about the future evolution of Bitcoin mining. Bringing it all together Uncertainties and risks surround the big questions about Bitcoin halving. While exciting, the future of Bitcoin post-halving is predictably unpredictable. It heavily depends on factors like market demand, technological advancements, miner strategies, and changes in blockchain operability. Mining could become less profitable unless either the Bitcoin price remains high or advances in technology and efficiency can offset the drop in rewards. Miners receive these rewards because they provide a vital function for the Bitcoin network. They validate the transactions and maintain the blockchain. Their contribution to the network is rewarded through these block rewards, and reducing rewards might theoretically jeopardize Bitcoin’s security by disincentivizing miners. Hence, it’s crucial to analyze and prepare for potential risks with each halving. Each Bitcoin halving is unique. Factors such as the widespread acceptance of cryptocurrency, the impact of institutional investors, and the maturation of Bitcoin as an ‘asset class’, means the upcoming Bitcoin halving might truly be different this time. In closing, Bitcoin halving is a price control mechanism interwoven into the fabric of Bitcoin’s blockchain protocol. It is a celebration of scarcity, a battle cry for decentralization, and a testament to the true nature of Bitcoin as a deflationary currency. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blank Wallet on Chainstack: Delivering complete financial privacy Blank Wallet is a private, non-custodial crypto wallet that offers the ultimate browser extension wallet for complete financial privacy, without compromise. With privacy-enhancing smart contracts, Blank Wallet provides users across Web 3.0 with the complete privacy functionality not only in DeFi but for all decentralized applications. What does Blank Wallet do? Blank Wallet was created to give users on-chain privacy as cryptocurrency markets increased adoption and use cases. Privacy was a key component that has become a highly sought-after commodity by users throughout blockchain industries and decentralized applications. For newcomers and enthusiasts alike, blockchain’s lack of privacy poses a real security risk that stems from the growth of cryptocurrency. Blank Wallet eliminates the friction faced by millions of users by making privacy accessible for everyone, everywhere. The wallet uses battle-tested privacy-enhancing technology to protect your financial data. Cryptographic proofs allow users to deposit their funds in a privacy-enhancing smart contract. When you want to make a withdrawal, Blank Wallet creates a fresh wallet address with no links to your history on the blockchain. Anyone can easily install Blank Wallet and start reaping the benefits. Besides full privacy functionality, Blank Wallet comes packed with an array of features that go beyond privacy for a seamless user experience. With full Web 3.0 support, the wallet allows you to connect to any DApp and harness the power of the decentralized web. Aleksandras Gaska, Founder and Operations lead, Blank Wallet Blank Wallet empowers all users to reclaim financial privacy. How did Blank Wallet come across Chainstack? Since their beta launch, the team at Blank Wallet has offered best-in-class privacy solutions that help users reclaim their financial privacy on the blockchain. With a growing user base, the team initially relied on Ethereum nodes and found maintaining the infrastructure to be highly time-consuming and challenging to scale. Blank Wallet chose Chainstack for its extremely robust node infrastructure and shared views on user data and privacy after evaluating several different solutions. For a privacy-focused blockchain company, it is important that Chainstack’s privacy policy ensures that the user data and the information of users connecting to the node remains secure and private. Chainstack’s team made it easy, with a quick-to-respond support team that was open and helpful in answering any queries the team had. Moving forward with the decision, Blank Wallet gained access to a highly supportive and dependable team, allowing them to focus more time on developing business solutions that add value for their customers while knowing that the nodes are closely monitored and maintained by a highly skilled team. How does the Chainstack offer match the Blank Wallet needs? Change happens quickly in cryptocurrency and blockchain marketplaces, as it does in all emerging sectors. Cutting-edge solution providers like Blank Wallet require flexibility and dependability that could adapt to changing market conditions. Blank Wallet has been able to develop its platform and achieve operational excellence because of Chainstack’s strong and resilient infrastructure, which is capable of high-traffic stable transactions. Furthermore, Chainstack’s many hosting options have helped offer improved latency and connection, resulting in a better product experience for end-users. Chainstack topped the list and became a long-term partner for Blank Wallet thanks to a remarkable collection of features that checked all of Blank Wallet’s needs, as well as accessible and flexible pricing options. Outcome Blank Wallet can automate infrastructure network operations with uncompromised connectivity, security, and performance thanks to the Chainstack managed blockchain services. The partnership with Chainstack has opened avenues to a wider range of customization options, supported by a highly dedicated and experienced team. Blank Wallet does not need to waste time worrying about maintenance or upgrades to nodes. The affordable and predictable pricing structure of Chainstack allows Blank Wallet to accurately allocate resources to improve their core services, eliminating the friction to focus on developing the important product optimization and products that deliver instant functionality that is secure and private in design. What does Blank Wallet like about Chainstack? Chainstack shares some of our fundamental values on privacy and has always been reliable and supportive. Chainstack has been an impeccable infrastructure partner with enterprise-grade solutions, protected endpoints and a secure platform that is highly dependable. The Chainstack team is very responsive, professional and always great to interact with and get direct support when we need it. Aleksandras Gaska, Founder and Operations lead, Blank Wallet What does Chainstack like about Blank Wallet? Blank Wallet adds privacy, anonymity, and security to blockchain, making privacy more accessible to everyone. In Chainstack’s mission to make Web 3.0 accessible for all, reliability and security are key components to better adoption. Chainstack’s principles are very much connected with Blank Wallet’s dedication to technological innovation, consumer empowerment, and exceptional service. The collaboration of the two highly experienced service providers results in revolutionary technological solutions that accelerate the growth of all customers and stakeholders in the market. Power-boost your project on Chainstack  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Block 11234873 and the Geth chain split What happened and why it didn’t affect Chainstack In brief On November 11, 2020, a transaction included in block 11234873 of Ethereum mainnet caused a chain split. The chain split was caused by the Geth clients starting from v1.9.17 and above being incompatible with the older Geth versions after block 11234873. Timeline A brief timeline of how the chain split happened: November 7, 2019 — Geth v1.9.7 is released. The release accidentally breaks the EIP-211 implementation and introduces a bug to which no one is alerted because the bug stays undiscovered at that point.July 15, 2020 — John Youngseok Yang from Software Platform Lab reports the bug to the Ethereum bounty program.July 20, 2020 — The bug is silently fixed and released with Geth v1.9.17. The release set the stage for the potential chain split between Ethereum nodes running Geth versions v1.9.16 and older and those running v.1.9.17 and newer.November 11, 2020 — A transaction in block 11234873 triggers the chain split. All Ethereum clients, including Geth v1.9.17 and higher, stay on the longer chain version. Geth v1.9.16 and below stay on the shorter chain version. Impact Chain splits happen often and are a part of the normal blockchain network operation. Two factors affected why this chain split made the news: Backwards incompatibility between Geth v1.9.17+ and older Geth versions.Some of the major products and services staying on older Geth versions. Why stay on the older Geth version? Why did some of the major services running on Ethereum stay on older Geth versions? As Ethereum evolves as the network, the idea, and the software implementing it, it’s become so much less of a garage project and so much more of the enterprise software realm. Staying on a working older version and not upgrading unless there is an absolute necessity to is something that is very common in industries like banking software and so on. As Ethereum crosses the territory from being a project run by enthusiasts to the fully-fledged industry with many many services and products around it and depending on it, staying on the stable software version is direct evidence of this space getting more mature. And bugs will always happen. Resolution The resolution is to upgrade to the latest Geth version. Why did the chain split not affect Chainstack users? Chainstack has the practice of ensuring the nodes of our users are on Geth versions that are at most two versions behind. At the time of the issue, the Chainstack dedicated Ethereum nodes were using at least v1.9.21, which is not affected by the bug. Our upgrade strategy Before being released to Chainstack users, any software upgrade goes through a set of standard tests in our sandbox environment internally. What happens when a new Geth version is released? We are informed of the release via emails and other notifications.We look through the changelog to identify any critical changes. Most releases are maintenance and light bug fixes. We act on the changelog items accordingly.If the release is for an impending hard fork or for critical security fixes, we will spend additional time to research them and understand them. Sandbox environment We push some of our sandbox nodes up with the latest release and observe any anomality within them.We monitor GitHub Geth issue pages for any latest issues created due to the latest version regularly.If everything is good for a period of days, we internally mark this Geth version to be stable for production. Production environment Once we deem the sandbox Geth version to be stable for production, dedicated Ethereum node customers will be informed of a scheduled node maintenance for an upgrade to either latest (if critical) or be upgraded to a version that is one or two releases behind latest. What if things go wrong? We have snapshots containing the last sync with the latest version and two previous versions, and we plan to use them in case of reverts. Other things we note on changelogs Is the release backward compatible?Geth v1.9.20 introduced a database change. This means, we cannot revert to Geth v1.9.19.Any deprecated commands or new features?We will have to change our deployment commands if there are deprecated commands.If there are new features, we see how we can apply them to make the customer’s experience better.If this release is to support a hard fork, which block does it start from?We will ensure all nodes are upgraded by that block number. Benefits of using Chainstack We always provide native JSON-RPC and WebSocket connectivity. This means, you are connected to the node directly through our high-performance nginx server instead of going through any middleman caching mechanisms.Your node’s Geth client version is always visible in the Chainstack UI.We support GraphQL within Geth which enables users to do quick and efficient queries on our nodes. See GraphQL on Ethereum: Availability on Chainstack and a quick rundown. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain Interoperability: Building cross-chain ecosystems at scale Blockchain, over the years, has proven to have brought about a shift in how we perceive the exchange of value and data, underscoring the power of a distributed, transparent, and secure ecosystem. While the range of blockchains currently in existence offers a variety of tools and platforms for the development of decentralized applications, the lack of interoperability between these networks can decrease their overall potential and limit user experience. This is where the concept of “Blockchain Interoperability” comes into play. Being one of the most talked-about subjects in recent years in the context of blockchain evolution, it aims to enhance the way blockchains communicate with each other and effectively share information. Let’s dip your toes into the fascinating world of Blockchain Interoperability. What is Blockchain Interoperability? Blockchain Interoperability refers to the ability of different protocols to communicate and interact with each other in a seamless and integrated manner. It enables a connected and cooperative ecosystem wherein data and value can be fluidly transacted across multiple chains. In practical terms, Blockchain Interoperability means that transactions and general information can be broadcast across multiple blockchains, bringing a new level of connectivity between these separate networks. This allows blockchains, even with different protocols and designs, to verify transactions from other chains, share data, trigger actions, and communicate seamlessly. Figure 1: What is Blockchain Interoperability; Source: 101blockchains The potential applications and benefits of achieving Blockchain Interoperability are enormous. It could lead to an improved user experience, foster a collaborative blockchain ecosystem, and drive innovation across the space. However, achieving interoperability among the diverse, sparsely connected Web3 universe is no small feat. Considering most protocols have been independently developed to serve a variety of purposes, they usually operate as isolated entities and tend not to interact with each other. As more companies, organizations, and individuals begin to build, innovate, and secure assets on multiple blockchains, the need for these networks to communicate becomes more eminent than ever. Just as the internet enabled the global exchange of data and information, Blockchain Interoperability aims to enable the exchange of value and information across different blockchain networks. Why is Blockchain Interoperability important? Blockchain Interoperability is essential because it allows for a seamless user experience across multiple blockchain networks. Currently, each blockchain operates in a silo, similar to an isolated island. Each has its unique operational procedures and protocols, which essentially forces users to know and understand the processes behind each blockchain to be able to use them effectively. Figure 2: Cross-chain smart contracts workflow; Source: Chainlink Moreover, the lack of interoperability presents a challenge in terms of time and cost. Suppose a user wants to perform a transaction that involves different blockchains. In that case, they must go through a status change in one blockchain and then begin a new process in the other, which is both time-consuming and expensive. With interoperability, users can freely and quickly move across blockchains. This feature is particularly important to average users who don’t have the technological expertise to navigate through different blockchains. Interoperability also removes barriers to innovation. Developers and entrepreneurs can release products and services on various blockchains, knowing that their users will be able to access and use them regardless of the blockchain network they primarily operate on. Advantages of Blockchain Interoperability There are numerous potential benefits to achieving better interoperability between blockchains. Some of these include: Simplified transactions: Interoperability can navigate transactions to be completed faster and in an automatic manner, regardless of the blockchain network an asset is from. Increased value: Assets can gain more value as they can be utilized more flexibly across various platforms instead of being confined to a single blockchain. Cooperation among chains: Blockchain networks can cooperate in unprecedented ways, such as sharing mechanisms for consensus, which enhances security and sustainability. Empowers greater decentralization: The potential to facilitate value transfers and trigger events in other blockchains empowers DApps to be more decentralized and functional across many blockchains. Blockchain Interoperability challenges While the concepts and technology for Blockchain Interoperability have made significant strides, they’re not without their challenges. Some of these include security concerns, especially given the increase in cross-chain interactions and the inherent complexities associated with different blockchain platforms. Moreover, the lack of industry standards creates obstacles to timely adoption and scalability. However, through collaborative efforts by developers, regulators, and businesses, it’s fair to believe these challenges can be met, and Blockchain Interoperability can elevate the blockchain industry to new heights. How Blockchain Interoperability works Blockchain Interoperability is far from just a theoretical concept or idealistic vision. It embodies a set of technologies, protocols, and methodologies that work together to facilitate interaction between different blockchain networks. Interoperability is realized through specific protocols that cater to cross-chain communication. These allow for assets and information to be transferred across different networks, facilitating seamless interaction between them. The degree of interoperability hinges on the compatibility between these protocols and the blockchains they communicate with. Figure 3: How interoperable blockchain works; Source: Cointelegraph Interoperability isn’t just about blockchains communicating with each other, however. It also involves distributed ledger technology (DLT) interfacing with external systems for data exchange. This is where cross-chain technology comes in. What is cross-chain technology? As the name implies, cross-chain technology provides the means for different blockchains to interact with one another. It enhances Blockchain Interoperability by allowing data interchange between DLT designs or external systems, building a more integrated, secure, and flexible blockchain ecosystem. Its work hinges on achieving interoperability among divergent blockchains, thereby solving the problem of asset and data exclusivity kept within individual chains. By enhancing interoperability, cross-chain technology essentially allows for multi-token transactions, the operation of cross-chain contracts, and a host of other possibilities. Cross-chain methods for Blockchain Interoperability The specific methods used for establishing interoperability can vary greatly depending on the specific characteristics and mechanisms of the blockchain network in question. Techniques such as atomic swaps, which permit the exchange of tokens across multiple blockchains, and relays, which allow blockchain networks to monitor activities occurring on other chains, vary in their implementations and costs across different networks. In all these scenarios, what remains a constant is the aim to eliminate the need for third-party interfaces and to facilitate direct communication and transactions using these specific methods for Blockchain Interoperability. Here are some applications of cross-chain technology in the context of Blockchain Interoperability: Atomic swaps (Programmable) token bridges Validator frameworks Blockchain routers Native payments Contract calls Hashed TimeLock contracts (HTLCs) Oracles There’s no one-size-fits-all when it comes to how cross-chain technology operates. Every network employs a unique method to facilitate transactions, and there’s a wide array of variations when considering how different blockchain networks use cross-chain protocols. Let’s explore each of these in greater detail in the following sections. Atomic swaps Archetypal examples of Blockchain Interoperability in action, atomic swaps enable users of different cryptocurrencies to exchange assets in a trustless manner. While efficient and highly secure, atomic swaps don’t support the transfer of tokens from one blockchain to another. They function more as a means to exchange tokens across blockchain boundaries. (Programmable) token bridges Token bridges facilitate the transfer of assets between blockchains through the use of smart contracts, enhancing token utility by enabling cross-chain liquidity. There are three primary mechanisms for managing tokens within these bridges: Lock and mint: This approach involves locking tokens into a smart contract on the originating blockchain. Subsequently, equivalent wrapped tokens are created on the target blockchain, known as bridged assets. To reverse the process, wrapped tokens are destroyed on the target chain, releasing the original tokens on the originating chain. Burn and mint: In this model, tokens are permanently destroyed (burned) on the originating chain and then recreated (minted) on the target chain, preserving the token’s total supply across ecosystems. Lock and unlock: Tokens are locked on the originating chain and subsequently made available from a liquidity pool on the target chain. This method often relies on incentives, such as profit-sharing, to maintain liquidity on both sides of the bridge. In turn, programmable token bridges combine token transfers with complex messaging, allowing for immediate contract execution upon token receipt on the target chain. This facilitates advanced cross-chain interactions such as staking, token swaps, or deposits into contracts as part of the bridging process, enabling seamless multi-chain operations. Validator frameworks Validator frameworks represent a direct method for enabling interoperability between blockchains. Within these frameworks, a group of validators is appointed to monitor and validate transactions occurring on different blockchains. When a transaction is executed on one blockchain, these validators, who have the ability to observe the transaction, relay and validate the information on the secondary blockchain to ensure that proper procedures are followed. Although validator frameworks offer a streamlined approach to Blockchain Interoperability, they reintroduce a degree of trust into the system. Users are required to trust in the integrity and fairness of the validators to act in the best interest of all parties involved. Blockchain routers Blockchain routers take a different approach to interoperability. They serve as a universal plug-and-play solution that connects to multiple blockchains and allows them to communicate and interoperate. Working similarly to a traditional web router, blockchain routers offer a scalable and efficient solution for Blockchain Interoperability. They can connect to multiple blockchains at once, manage data between them, and even allow cross-chain operations, all while maintaining the decentralization and security attributes that characterize blockchain technology. Native payments Native payments enable transactions on one blockchain to trigger payments in the native currency of another blockchain. This can be based on the activities within the originating blockchain or external inputs, serving as a means of settlement across chains. Contract calls Contract calls allow a smart contract on one blockchain to activate a function within a contract on another blockchain, based on data from the first chain. These calls can be linked together for complex cross-chain operations, including token exchanges and transfers. Hashed TimeLock contracts (HTLCs) HTLCs are a method for facilitating “trustless” swaps, a term that refers to the ability to have a transaction without a trusted third party. They ensure that the swap either happens fully or not at all, so neither party can cheat the other. Atomic swaps and Lightning Network payment channels use Hashed TimeLock Contracts. Oracles Oracles are cross-chain communication methods that act as agents that verify real-world information for blockchain contracts. Oracles can feed real-world information to one blockchain from another, allowing for data and transactions to flow across ecosystems. Chainlink’s Cross-Chain Interoperability Protocol (CCIP) Chainlink, well-known for its decentralized oracle network which securely connects smart contracts with real-world data and services, has recently introduced its Cross-Chain Interoperability Protocol (CCIP). This novel solution aims to increase the interoperability capabilities of the existing Chainlink Network. The Cross-Chain Interoperability Protocol is designed to extend the capabilities of Chainlink’s decentralized oracle networks. It allows smart contracts to interact with any other smart contract, irrespective of the blockchain network the latter resides on. This promises to extend the capabilities of smart contracts dramatically, enhancing the appeal of blockchain as a versatile solution for many industries. Figure 4: Chainlink CCIP workflow diagram; Source: Chainlink Advantages of using CCIP CCIP facilitates secure cross-chain computation and data transfer, presenting several advantages: Permissionless messaging across chains: CCIP provides a general-purpose, platform-agnostic interface for sending messages between chains. Increased functionality: By allowing smart contracts to interact cross-chain, CCIP effectively increases their functional depth and usability. Enhanced applications: With CCIP, developers have the opportunity to devise applications with increased efficiency, utilizing the strengths of different chains to suit different applications. Use cases for Chainlink CCIP CCIP can be used not only for data delivery but also for value delivery, potentially involving multiple networks. For example, a bet on a sports event could be agreed upon on one blockchain, monetary assets could be transferred from a second blockchain, and the result of the sporting event could be obtained from a third blockchain. The result will then trigger the transfer of value, and the winner of the bet gets paid. Figure 5: Chainlink cross-chain stack; Source: Chainlink It’s obvious from this that CCIP could significantly impact decentralized finance, gaming, supply chain management, and many other industries. Here are some of its core use cases: Token transfers: CCIP facilitates the programmatic movement of tokens between blockchains through lock-and-mint or burn-and-mint processes, allowing for the inclusion of arbitrary data commands. Gaming interoperability: CCIP supports the interoperability of Web3 games on various blockchains, enabling gamers on one blockchain to compete with those on another. Web3 usernames: Through CCIP, Web3 naming protocols achieve full interoperability, letting users register on-chain names on one blockchain and extend them across others. Cross-chain DeFi: CCIP empowers DeFi platforms to accept tokens from one blockchain as collateral on another, opening up cross-chain borrowing and lending markets. DeFi liquidation prevention: CCIP offers a mechanism to safeguard DeFi positions on multiple blockchains by automatically transferring assets to another chain’s DeFi protocols to avert liquidation risks. Future of Blockchain Interoperability The Web3 landscape is continually evolving, and with it, the prospects for Blockchain Interoperability. Such a unified environment would greatly amplify the functionality and capabilities of blockchains, fostering innovation and efficiency across various industries and applications. Given the current pace of development, it isn’t far-fetched to anticipate that Blockchain Interoperability will soon become a standard feature in the blockchain ecosystem. More and more projects will likely focus on developing solutions that promote cross-chain interactions to enhance efficiency and collaboration within the blockchain space. Further, the foreseeable future might see most if not all, decentralized applications become multi-chain or cross-chain applications. This could considerably enrich the user experience, open up new avenues for blockchain adoption, and accelerate the mainstream adoption of blockchains. Bringing it all together Blockchain technology, with its inherent features of immutability, transparency, and security, has opened up a plethora of opportunities, but it is the concept of “Blockchain Interoperability” that has taken center stage in recent discussions around the future of blockchain. The idea of interconnected blockchains operating side-by-side, sharing and validating data, and executing complex multi-chain smart contracts is fascinating. It holds the promise of unlocking significant potential in creating a seamlessly connected, integrated future. With the tremendous strides made in this field, from atomic swaps to validator frameworks, and innovative solutions like Chainlink’s CCIP, we are closer than ever to achieving this vision. Nonetheless, the quest for perfect interoperability is an ongoing one that certainly warrants attention and investment. As we continue to navigate the digital frontier, it’s clear that Blockchain Interoperability isn’t just about the advancement of the technology; it’s also crucial for its wider adoption and the maximization of its benefits. By breaking down the boundaries that separate individual blockchains, we open the door to a multitude of possibilities for innovation, efficiency, and growth. Regardless of the challenges that lie ahead, it is evident that the future of Blockchain Interoperability is a fundamentally promising one—a future that heralds a new era of connectivity, functionality, and cooperation in the blockchain universe. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain node hosting: how to choose the best setup in 2026 Running a blockchain node is straightforward. Deciding where to host it — which blockchain node hosting environment fits your workload, your compliance requirements, and your ops capacity — is where most teams lose weeks. Not because the options are complicated, but because the tradeoffs aren’t obvious until you’re already in production and something breaks. This article breaks down the three environments where you can run a self-hosted node, what each one costs in practice, and how to pick the right one for your workload. The three environments for self-hosted blockchain nodes VPS (virtual private server) A VPS gives you a virtualized slice of shared physical hardware with root access, billed by the hour or month. It’s the fastest way to get a node running — no hardware procurement, no data center contracts, no upfront commitment. Who it’s for: Individual developers, early-stage projects, testnets, and teams that want to start quickly without over-engineering the infrastructure layer before they know what their production workload actually looks like. What to watch: Shared hardware means shared risk. A noisy neighbor can degrade your I/O at the worst time. Storage costs compound fast — a full Ethereum archive node requires 18–20 TB of fast NVMe SSD as of early 2026 — and grows ~1–2 TB per month, and VPS pricing at that scale stops being cheap. You also still own everything above the hypervisor: OS updates, disk monitoring, client upgrades, service restarts. Where it makes sense: Dev/test, non-critical production, validators with modest performance requirements, and any project at an early stage where flexibility matters more than raw throughput. VPSUpfront costNone (hourly or monthly)PerformanceMedium — shared hardwareData controlMedium — hosted by providerTime to provisionMinutesBest forDev/test, early production, cost-sensitive projects Dedicated server Dedicated server means a physical server — rented from a provider — that you don’t share with anyone. No virtualisation overhead, no noisy neighbors, consistent I/O performance. The provider handles power, cooling, and network transit. You own the OS up. This is the most common environment for production blockchain node hosting. It combines the performance characteristics of bare metal with the operational convenience of a cloud provider — no hardware to procure, no data center to manage, but no shared tenancy either. Who it’s for: Teams running production nodes with real traffic, validators, MEV infrastructure, archive nodes, indexers — anything where consistent I/O performance and predictable latency matter. Also the right fit for teams that have outgrown VPS but aren’t ready to manage on-premises hardware. What to watch: Dedicated servers are priced per machine. Scaling up means provisioning new hardware, which can take hours to days depending on the provider. You’re typically locked into monthly billing cycles, so unused capacity costs money. Sysadmin work — OS installation, patching, monitoring, blockchain-specific tuning — is still on you unless you add a management layer. Where it makes sense: Consistent high-load workloads with predictable resource requirements. Performance-per-dollar at production scale is the best of the three environments. Dedicated serverUpfront costLow–medium (monthly per-server)PerformanceHigh — no shared hardwareData controlHighTime to provisionHours to daysBest forProduction nodes, validators, MEV, archive 📖 If your primary need is access to full historical chain state rather than running your own archive node, Chainstack Archive Data gives you instant access to Ethereum, Solana, Arbitrum, Base, and more — without the hardware footprint. Local environment (on-premises) Local means your own hardware, in your own facility — a server room, a co-location rack, or a data center you operate. You own every layer: the physical machine, the network switch, the power supply, the OS, the node software, and every upgrade in between. Who it’s for: Enterprises with data residency requirements or compliance mandates that make third-party cloud infrastructure non-negotiable. Teams where regulatory, legal, or security constraints explicitly require on-premises hardware. Not a default “we want full control” choice — it’s a requirement-driven one. What to watch: Hardware is not the expensive part. Ops is. Running a local environment means staffing for it: someone who can replace a failed drive at 2 AM, negotiate co-location contracts, plan capacity 18 months ahead, and handle a power event over a public holiday. Most teams significantly underestimate this burden until they’re managing it. Where it makes sense: Regulated financial institutions, sovereign infrastructure, and any deployment where third-party data residency is legally prohibited. If you’re considering local primarily for cost reasons, model the total cost of ownership including ops headcount before committing. Local environmentUpfront costHigh (CapEx)PerformanceMaximum — dedicated hardwareData controlMaximum — your premisesTime to provisionWeeks to monthsBest forRegulated enterprises, compliance-mandated deployments Where Chainstack Self-Hosted fits in Chainstack Self-Hosted is an ops layer that runs on top of whichever environment you choose. You bring the infrastructure — VPS, dedicated server, or local hardware — and Chainstack handles everything above the OS: node deployment, configuration, monitoring, automated self-healing, and lifecycle management. The key properties stay the same regardless of which environment you deploy into: Your infrastructure, your data. Nodes run where you specify. No shared tenancy, no third-party data residency concerns. Automated operations. If a node falls behind on sync or crashes, the platform detects it and recovers — no manual intervention required. Multi-chain, one control plane. Ethereum, Solana, L2s — all managed from a single dashboard. No lock-in to an environment. Start on VPS, move to dedicated when load justifies it, extend to local if compliance requires it — the platform follows your infrastructure. This matters most for teams that want production-grade node operations without building the tooling themselves. Whether that’s a solo validator on a VPS, a growth-stage team running archive nodes on dedicated hardware, or an enterprise deploying on-premises — the ops burden is the same: low. 📖 Not sure which Chainstack product fits your stack? See the full breakdown on the Chainstack pricing page — from the free Global Node tier through Dedicated Nodes and Self-Hosted deployment. How to choose your blockchain node hosting environment The decision comes down to three variables: how much performance predictability you need, how much ops work you’re willing to own, and whether you have a compliance constraint that forces your hand. Use this table as a starting point: WorkloadRecommended environmentApproximate monthly costMain risk if you choose wrongDev/test, testnet, early prototypeVPS$20–$150Noisy neighbor kills I/O during a critical testProduction validator, indexer, MEVDedicated server$100–$400VPS shared hardware causes missed attestationsArchive node (Ethereum)Dedicated server, high-storage$300–$800+VPS storage costs exceed dedicated at 10+ TBRegulated deployment, data residencyLocal / on-premisesCapEx + ops headcountUnderestimated ops burden — plan for 1–2 FTE The most common mistake: teams start on VPS for cost reasons, hit I/O degradation at production load, and migrate under pressure. Starting on dedicated server for a production validator costs roughly $100–200/month more than VPS — a cost that’s easy to justify once you’ve experienced one missed attestation event. The second most common mistake: choosing local for “full control” without modelling the ops cost. A co-location rack with redundant power, 24/7 on-call coverage, and hardware replacement SLAs typically costs more in engineering time than a managed dedicated server — often by a factor of three. You’re building, testing, or just getting started → VPS. Provision in minutes, pay as you go, upgrade when you have real production load to justify it. You’re running production workloads — validators, indexers, archive nodes, MEV → Dedicated server. Consistent performance, no shared hardware risk, best cost structure at production scale. You have a compliance or data residency requirement → Local environment. Model the full ops cost before committing — hardware is not the expensive part. Conclusion The environment where you host your blockchain node matters, but it’s not the hardest part of the decision. VPS gives you speed and flexibility. Dedicated server gives you performance and predictability. Local gives you maximum control when compliance demands it. What most teams underestimate is the ops layer above the infrastructure — deployment, monitoring, patching, recovery. That burden is the same whether you’re on a VPS or a bare-metal rack. Chainstack Self-Hosted removes it from the equation entirely, so the infrastructure choice becomes exactly what it should be: a pure tradeoff between cost, performance, and data control. Deploy Chainstack Self-Hosted → FAQ Can I run Chainstack Self-Hosted on a VPS? Yes. VPS is a supported environment and a common starting point. The minimum hardware requirements depend on the chain and client — check the system requirements in the documentation before provisioning. What’s the difference between Chainstack Self-Hosted and Chainstack Dedicated Nodes? With Dedicated Nodes, Chainstack owns and manages the infrastructure entirely — you get a single-tenant node on Chainstack’s cloud without managing any servers. With Self-Hosted, you bring your own infrastructure (VPS, dedicated server, or local hardware) and Chainstack manages the node layer on top of it. Self-Hosted is for teams that need their data to stay on their own infrastructure. Is a dedicated server or a VPS better for a blockchain validator? For validators, consistent low-latency performance matters more than flexibility. Dedicated server is generally the better fit — no noisy-neighbor I/O risk, predictable hardware performance, and no shared tenancy. VPS can work for testnets or low-stakes validators, but for mainnet validators where uptime directly affects rewards, dedicated hardware reduces one category of risk. What are the storage requirements for hosting an Ethereum node? A pruned Ethereum full node runs ~1.2 TB. An archive node requires ~18–20 TB of fast NVMe SSD as of April 2026, growing ~1–2 TB per month. Solana full history exceeds 100 TB — a different category entirely. Always size for 12–18 months of growth, not current state. Storage requirements are the single biggest factor when choosing between VPS, bare metal, and cloud. What does Chainstack Self-Hosted actually manage — and what’s still on me? Chainstack handles node deployment, configuration, monitoring, self-healing, and client upgrades. Your responsibility is the infrastructure layer: provisioning the server, maintaining the OS, managing network connectivity, and ensuring hardware availability. In a local environment, that includes power, cooling, and physical hardware. On VPS or dedicated server, the provider handles the physical layer. When should I choose local over cloud? When a regulatory, legal, or security requirement explicitly mandates it — not as a default preference for control. If you’re considering local primarily for cost or performance, model the full total cost of ownership including ops staffing. For most teams, dedicated server delivers equivalent performance with significantly lower operational overhead. Additional resources Chainstack Self-Hosted Self-Hosted documentation How to deploy a self-hosted Ethereum node with Chainstack Self-hosted blockchain node: DIY vs Chainstack Self-Hosted How to run a self-hosted blockchain node on HOSTKEY #### Blockchain node providers: What, how, and why Starting out in the Web3 space can be a cumbersome task, especially if you are a rookie developer or someone without the savviness of Web3 native. But fortunately, you don’t have to be either to have a go at building on top of your favorite blockchain protocol. Quite the contrary, which is why we have devised this article just for you. So, without further ado, let’s explore blockchain nodes, providers, and their intricacies. What is a node in a blockchain? Before you can understand what a node is, you have to get a better idea of how a blockchain network works. A blockchain network is essentially a distributed system. This means that the software components involved in its operation and the data that passes between them depend on multiple sources. These sources are network participants, or simply put, nodes.  Figure 1: Centralized, Decentralized and Distributed systems; Source: Vasilomanolakis, Karuppayah, Mühlhäuser, Fischer (2015)  The purpose of the nodes is to communicate complex messages with the aim of sharing resources to accomplish a single goal. In the case of a blockchain network, for example, those goals can be changes in state, like an update to your wallet’s balance via transactions, block propagation, such as validating the hash of new blocks, or other complex and not so operations.  To keep things simple, let’s do a quick recap. A blockchain network is composed of nodes. Each of these nodes participates by broadcasting relevant information to the network. Other nodes in the network confirm the validity of that information in various ways (the consensus mechanism), and once everything checks out, changes are processed live. Figure 2: Different types of Ethereum nodes by Sethu Raman; Source: EVM Nodes  Different types of nodes in a blockchain In essence, blockchain nodes are divided into two main types—full and light. The key difference? One contains a copy of the blockchain’s history (full), while the other downloads block headers only to save the hard drive space for its users. There is more to nodes than just that, however, so let’s dig further down into the specifics.    Light nodes  As just mentioned, light nodes do not carry the entire weight of the blockchain but rather only the headers of blocks to allow portable interaction with Web3. This type of node is the most commonly seen throughout the space, as it is usually found on the user side, such as a wallet interface.  Light nodes, or Simple Payment Verification (SPV) nodes as they are technically referred to, rely on full nodes to provide them with the data they need to perform their operations. And considering they don’t carry a copy of the blockchain themselves, they can only query the status of the last block and broadcast transactions to the network for processing.   That being said, it becomes clear what makes light nodes such a portable implementation that requires a significantly lower number of resources than a full node would. Even so, this convenience does come at the cost of security.  Full nodes  On the other hand, full nodes are the bread and butter of a blockchain network. They act as a server within the distributed network and are mainly responsible for the verification of transactions. This type of node carries the full weight of a blockchain network by holding a copy of it on its local storage.   Full nodes are also responsible for the consensus mechanism, which ensures only valid transactions are propagated on the network. In doing so, these nodes vote on proposals and make decisions for the future of a network, should 51% of them agree on a certain outcome.  If a particular outcome fails to hit the 51% voting mark, it is automatically rejected by the network, in turn creating what is called an “orphaned block.” In some cases, especially when it comes to large networks with many full nodes involved, this can result in a network split called a hard fork.   Figure 3: Block propagation and chain splits; Source: ExtremeTech  The result of this is two separate networks supported by the full nodes that backed their proposals. One of the most well-known occurrences of this was the Bitcoin Cash Fork, which caused the creation of two new networks—ABC and SV.   Archive nodes and pruned full nodes  Full nodes come in two main forms—archive nodes and pruned full nodes. Both of these nodes synchronize blocks from the beginning of the blockchain’s history. The main difference between them, however, is that pruned full nodes have a certain limit, after which old blocks begin being replaced.   To put this into a better perspective, setting a size limit of 1GB for a pruned full node would result in a blockchain history of no more than 1GB being saved to local storage. If new blocks being propagated increase the size beyond that 1GB limit, the node begins to delete the history of the first blocks, in order to make room for the new ones. And should you wish to get the state of a block that was already replaced, the node needs to go through the entire chain to validate those blocks once again.   On the other hand, archive nodes can be quite heavy, when it comes to storage requirements, as they contain the entire chain state history that can be queried. See also EVM nodes: A dive into the full vs. archive mode. Which nodes secure the network? Technically, all types of full nodes can be used to secure the network, add blocks to it, and maintain consensus. There are some subtle and less so differences, however, especially when it comes to archive nodes, as we are about to see: Mining nodes In Proof-of-Work (PoW) blockchains, such as Bitcoin, or Ethereum (as of this post), mining nodes, or simply put miners, are responsible for completing the work required to create a block. This work usually involved solving complex mathematical operations, in order to come up with the correct result in the form of hash output that validates the block.  Figure 4: How Bitcoins are minted; Source: KitGuru  Depending on the protocol specifics, this work is completed with various hardware components, like the Central Processing Unit (CPU), Graphics Processing Unit (GPU), or Application-Specific Integrated Circuit (ASIC). The first that successfully completes the work in question and broadcasts it to the network, claims the right to propagate the block, should consensus be achieved prior.   Because performing the operations involved in mining can be quite resource-heavy, miners are rewarded a pre-set number of tokens plus all transaction fees used for transactions in that particular block. This reward is called a “coinbase,” or a “coinbase transaction” and is free of charge, considering it is the first transaction in a block, created by the miner of the block itself.  Staking nodes  Much like mining nodes in a PoW blockchain, staking nodes, or stakers, carry the same responsibilities but for Proof-of-Stake (PoS) networks, like the upcoming Ethereum after The Merge, Polygon, or Tezos. The key difference between PoS and PoW chains is that staking does not require the completion of complex mathematical operations, in order to validate blocks, but rather a locked number of tokens called a stake.   Figure 5: Staking process diagram; Source: Nirolution  This makes PoS chains much less resource-dependent, which significantly lowers the barrier to entry for network participants. Naturally, there are many different implementations of the PoS mechanism, but they all bear similar characteristics to that of a lottery. Based on a set of rules in combination with a bit of luck and chance, the network chooses who will propagate the next block.   These factors can range anywhere from coin age, or how long you have held your tokens as a stake, to stake size (total number of tokens you have held) and ratio, or size of your staking share compared to the total locked. And should the network chooses you based on these criteria, you get to earn the dedicated reward.   Authority nodes  Up until now, all blockchain nodes that were mentioned can operate on a permissionless basis, or are in other words in essence decentralized. That is not the case for all, however, as decentralization does come with a certain set of drawbacks that the next type of node aims to resolve—authority nodes.   Authority nodes are used in consensus mechanisms, such as Delegated Proof of Stake (dPoS), Delegated Byzantine Fault Tolerance (dBFT), Proof-of-Authority (PoA), and others. Examples of such implementations can be found in Fantom, Quorum, Multichain and BNB Smart Chain networks. The benefits of such chains are in higher transaction processing speed, for example, and are achieved by introducing a higher level of centralization on the protocol level.   Figure 6: Proof of Authority process diagram; Source: Natoli, Yu, Gramoli, Verissimo (2019)  To do that, a fixed number of authority nodes are defined for the network in question. Much like full nodes, authority nodes are used to create and validate blocks, in addition to the distribution of relevant data to users. This means that all other network participants will be running light nodes instead and will not participate in network validation, block propagation, and maintaining consensus.   Masternodes  Last on our list of nodes are masternodes. Unlike full nodes, masternodes cannot propagate new blocks to the blockchain. Instead, their primary goal is to record transactions and validate them. Other nodes in the network, regardless of whether they are miners in a PoW, or stakers in a PoS setup, take full responsibility for propagating blocks on the chain.  To deploy a masternode, you first need to designate a number of tokens as collateral that is then locked. This entitles you to not only securing the network but also earn a slice of the rewards pie for your participation. But as the “Sword of Damocles” saying goes—“With great power, comes great responsibility,” which means that if you are running a masternode, you are expected to be there for the network 24/7. And failure to do so results in your collateral, or a share of it being lost.  Comparing nodes  That being said, we have reached the end of our overview of the various kinds of nodes, involved in a blockchain network. Even so, the list itself can be quite a tough nut to crack, especially for beginners, which is why, it is best to give you a quick reference sheet for nodes, what they are good at and their pitfalls:   Figure 7: Node types comparison; Source: Nodes  Case study: Cloud vs. on-premises nodes on Ethereum  Running a blockchain node can be a cumbersome process and not everyone has the means to do that with their own setup at home, or at the office. But at the same time, this also begs the question of just how many nodes are being run on-premises compared to those on the cloud. Fortunately for you, back in 2019, Chainstack took the time to dig into the details and do some research on just that.  The protocol that was selected for that was Ethereum, considering it was and still is to a larger extent, one of the most significant chains, when it comes to the number of nodes participating in the network and the load, they bear for the development of Web3. You can find the full case study here, but if you’re looking for the latest data, it is best you refer to the original data source—Ethernodes:  Figure 8: Ethereum mainnet node statistics; Source: Ethernodes  Interacting with nodes  To start interacting with a node, it goes without saying that you first need to have one. If you already have one up and running on a local instance that is great, but if you don’t, you can deploy it in a matter of minutes and completely free of charge with Chainstack. All you need to do is head over to the console to create an account and once you are registered, you can proceed with deployment.  For this example, we will pick Ethereum, as it is one of the most common choices to get started. With an Ethereum node deployed already, go ahead and find the RPC endpoint (HTTP) for your node, as it is one of the primary means of interacting with your node. You do not need to install any Web3 libraries at this point, but you will still need a way to transfer data to and from a server using HTTPS, such as cURL.   Figure 9: Ways to connect to a node; Source: Sethu Raman  You can install cURL using a wizard, or by hopping on to the Command Line Interface (CLI) of your choice and inputting the following command from a preferred directory:  npm install curl  Once you have successfully installed cURL, you can begin interacting with your node. To do that just enter the following line of code:  curl -X POST -H "Content-Type: application/JSON" --data \ '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ https://chainstack-node-endpoint  This, in turn, will invoke the eth_blockNumber method and you will get the latest block number in a format with hex encoding, as a return value:  { "jsonrpc": "2.0", "id": 0, "result": "0xe3acf4"}  With that successfully completed, it’s time to congratulate you on your first interaction with a node!  Managing nodes  While basic interactions, such as that mentioned above, are relatively simple to execute, building a Web3 application requires a palette of ever more complex operations, depending on your use case. On top of that, some may not even be possible without the use of a certain type of full node, which can make the entire process a living nightmare.   That is especially the case, should you opt for running your own on-premises node, placing the cumbersome load of managing the infrastructure all by yourself. This is an enormous responsibility that involves a ton of waiting, during node synchronization and sometimes doing it all over for various maintenance operations.   This gets even worse, considering a single node will hardly be enough for a product that is intended for a market release and not an educational project. And to top it all off, you will not only need to manage these nodes effectively but need to ensure that they suffer as little downtime as possible, in order to deliver a seamless user experience. This brings us to the next topic.  Scaling node operations  As just mentioned, running a single node is relatively straightforward, but the real challenge begins when you need to scale up your operations by using multiple nodes. To do that you will need significant server resources, like storage, bandwidth, processing power, and memory. But what if you don’t have such means at your disposal?  The typical go-to method of resolving this is to use something called a load balancer. A load balancer is a tool that helps you distribute incoming network traffic efficiently across a group of backend servers, or in your case nodes. And considering just how vast the volume of concurrent user requests can be for Web3 applications, this is certainly no easy task, even for the best load balancers.   Figure 10: Load balancer process diagram; Source: Nginx  The biggest challenge in using a load balancer is keeping things consistent. This is so, because every node in a blockchain network perceives the latest state of the chain in their own way so to say. In turn, this can create significant issues, due to inconsistent data being parsed, in addition to other pitfalls that impede a positive user experience.  Pitfalls in interacting with nodes  That being said, you now have a basic idea of what makes running a node so difficult. But to keep things simple, let’s do a quick recap of the major pitfalls involved in running your own on-premises node:  Node synchronization can take a massive amount of time. Running a healthy node requires you to perform regular updates and maintenance. Nodes can timeout, which puts your entire operation to a grinding halt. Despite your best efforts, nodes can desynchronize, creating a ton of issues with it. Running multiple nodes can be quite difficult, especially because of desynchronization. All of these issues are further exacerbated during heavy network traffic. Blockchain node providers  The good news, despite the pitfalls mentioned above, is that you don’t have to face these challenges alone. That is where node providers come in handy. Simply put, a node service provider handles all the nodes you deploy and all the routines involved in doing that, so you don’t have to. In doing, so node providers save you an enormous amount of time and effort that is better put towards further building your application.  Figure 11: Making the choice between on-premises node and using a node provider  The fact of the matter is, however, that if you followed the guide on interacting with nodes to the letter, you’ve already had the chance to experience just how handy using a node provider can be. After all, it allowed you to deploy a fully functioning node for the code example in a matter of minutes, instead of having to wait (sometimes days and weeks) by doing it yourself.  With a node service provider by your side, you were able to use its endpoint API to query the node you deployed to obtain information about the latest block and its number. And in reality, using a node provider to perform other operations such as that is just as simple. Now isn’t that a lifesaver?   Node provider benefits  Using a node provider is not needed for running local instances, but as you saw, once your Web3 application goes live on mainnet, or even testnet, it becomes a vital tool in your development. So having this in mind, let’s do a quick recap of what makes using a node service provider so great:  Deploy well-maintained and regularly-updated nodes in just a few clicks and minutes. Leverage historical transaction data with archive nodes just as simply. Scale reliably, according to your needs and budget. Forget about pesky exceptions and desynchronization issues. Save your budget from investing in expensive server setups. Get professional help that will customize your nodes to your liking. Node provider benchmark  Curious to see how well your node provider fairs against the rest? Compare your node’s performance with the benchmark tool built by our developer advocate Wuzhong Zhu and learn about its inner workings in the dedicated article here. Chainstack as a node provider  Chainstack is a node-as-a-service (NaaS) provider, whose sole purpose is to make your life, as a Web3 developer, as easy as possible. The platform offers a “control panel for blockchains” that operates across a multitude of cloud service providers and supports a wide range of some of the most significant protocols to date.   Why Chainstack?  With Chainstack, you can build rapidly, deploy and manage decentralized networks with absolute ease in just a few clicks, whether you are an enterprise or a solo developer. Let’s walk through some of the factors that make Chainstack an excellent choice for your Web3 project. Multi-chain: 14+ blockchain networks   Ethereum, BNB Smart Chain, Avalanche, Polygon, Fantom, Solana, Harmony, StarkNet, Tezos, Bitcoin, Quorum, MultiChain. Multi-cloud: 4 clouds with 7 locations around the world   AWS, GCP, Azure, Virtuozzo clouds, located in US East, US West, Singapore, Tokyo, London, Frankfurt. Hybrid: Chainstack-hosted, self-hosted, or a mix   Freedom of choice for you to run nodes either in Chainstack’s managed clouds, your own managed clouds, or a combination of the two.  Reliable: self-healing infrastructure with >99.9% uptime   3rd-party independent health status checker of the Chainstack’s platform shows more than 99.9% uptime across all services.  Scalable: run any number of nodes and networks, anywhere   Elastic nodes fit growing businesses starting from a few requests to hundreds of million requests. Dedicated nodes fit businesses’ need for unlimited requests. Nodes can serve up to 4000 requests per second, from 1 to unlimited nodes.  Affordable: pay only for what you use   Availability of free of charge plan for developers with up to 3M requests a month   Dedicated nodes for an unlimited number of requests for predictable payments  Instant: Get started in minutes and experiment   A node can be run in less than a minute and start serving your business. Support: enterprise-class SLAs and premium customer support. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain platform as a service for educators and trainers By Zaid Mahomedy We’ve noticed a huge uptake in Chainstack subscriptions from the education sector, and I’ve done some research to learn more about the motivations and needs of this sector. Based on findings from studies done on job posting sites such as LinkedIn, Upwork, Burning Glass, Angel List, Janco Associates, Hired, and Glassdoor, the demand for blockchain expertise is increasing (by double and triple-digit percent), and these jobs are high paying. Those tasked with preparing new entrants to the job market or upskilling existing professionals are taking note of this demand and scrambling to offer blockchain courses that keep their educational institutions competitive and relevant to the market needs. Roles requiring blockchain expertise In 2019, you should expect to find positions such as blockchain developer/engineer, project manager, designer, architect, attorney/legal advisor, and blockchain consultants being advertised by software development companies, ICO/IEO/STO projects or crypto-related companies, enterprises or IT consultancies with dedicated blockchain teams and a new wave of blockchain-first consultancies. Indirectly, via the application of distributed ledger technology to multiple use cases, blockchain expertise is also being sought in fields such as cryptography, law, marketing, engineering, supply chain, social sciences, information systems, accounting, logistics, warehousing, retail, multiple public and private sector areas, and more. This is not surprising as distributed ledger technology introduces “trust into a trustless environment” meaning that if you have no reason to doubt the authenticity and validity of interactions you’re having with other parties in your value chain, multiple opportunities can be unlocked (e.g. faster exchanges, no need to reconcile exchanges, lower costs, and automated events via smart contracts). Multiple industries want to realize these benefits. Who is offering blockchain education? At Chainstack, we are seeing a rapid uptake of subscriptions from a variety of educators. Primarily universities, colleges, and schools, but also short-course providers and large companies offering internal education programs. Blockchain learning material Initially, much of the content on offer to students was theoretical starting with the basics such as hashing, Merkle trees, linked lists, and mining. The focus was on cryptocurrencies and mining with Ethereum and Bitcoin being the public blockchain protocols of choice. Those who offered practical courses typically educated students on how to compile and run a Solidity smart contract on Ethereum with available tooling that requires a lot of environment setup time on their local workstations. However, students were not leaving with an understanding of the choice of other public or permissioned blockchain protocols available or knowledge of how to implement their basic skills in real-life and specific industries. Application in learning Some educational institutions have started issuing their academic certificates on a blockchain to combat fraud (here is a tutorial on how to do this). This also offers educators practical experience working with blockchain. There is also a demand at hackathons (where many investors or employers scout for talent) for students or enthusiasts to have an environment to rapidly experiment with blockchain technologies for some practical purpose. A major limitation of not having access to a blockchain Platform as a Service is that it generally leads to a lot of time spent on setting up the basic infrastructure. Further, developers are restricted to the popular Ethereum protocol — in a public or private (not permissioned) application. Explaining the high signup rates on Chainstack We were initially surprised by the huge signup rate from a number of educational institutions on Chainstack but it now makes a lot of sense to us. We offer the ability for institutions to rapidly deploy a choice of protocols as a public, private, or permissioned network with a choice of consensus mechanisms and on a choice of infrastructure. These choices on Chainstack are growing. Chainstack charges for resource usage hourly. Hence, from 3-month long team projects and 48-hour hackathons to 180-minute examinations, we offer an ideal solution for educators looking for choice and flexibility in structuring their programs. Not only does Chainstack offer the rapid deployment, management, and scalability of blockchain networks, we also offer a growing library of resources to accelerate development with the chosen protocols on https://docs.chainstack.com/. If a Law class wants to experiment with dispute resolution smart contracts, a Political Science class wants to experiment with various e-voting scenarios on the RAFT or IBFT protocol, an Economics class wants to experiment with inflation of finite resources, or a Computer Science student wants to focus on developing the front-end of DApps without worrying about the backend layer, Chainstack can provision the environment running the chosen blockchain protocol in minutes! Chainstack offers a Developer Plan where resource usage is free for 2 weeks, and there is no subscription fee, ever. If you’re interested, try out Chainstack on https://console.chainstack.com. And if you are keen on joining an ambitious group based in Singapore that’s working at the bleeding edge of blockchain and DevOps, then take a look here. We are looking for numerous blockchain passionate talents. Chainstack 101 Bolt, the technology that makes life easy for developers and blockchain enthusiasts Enterprise blockchain protocols — a primer Chainstack platform Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain RPC benchmark: meet Chainbench Introduction In Web3 development, every millisecond matters. Slow or unreliable RPC endpoints can quickly become bottlenecks that degrade user experience. Whether you’re syncing blocks, querying smart contracts, or processing transactions, your infrastructure’s performance directly impacts your users. That’s why having a reliable blockchain RPC benchmark is essential to identify weak points early. But here’s the challenge: how do you know if your RPC endpoint is actually fast? Marketing promises of “10,000 RPS” or “no rate limits” sound impressive, but they don’t tell you what matters most—how your endpoint performs under real-world conditions with the traffic patterns your app generates. This is why we built Chainbench: an open-source, vendor-neutral tool that provides standardized benchmarking for blockchain RPC infrastructure. Why blockchain infrastructure needs a benchmark standard Until now, measuring blockchain node performance has been inconsistent at best. Teams rely on ad-hoc scripts or trust provider claims that are hard to verify. This creates several problems: Unrealistic marketing claims: “No rate limits” means little when a single balance query takes 15 seconds during network congestion. Inconsistent testing: Without a common tool, it’s nearly impossible to compare providers on equal footing. One-off scripts lack consistency and rarely match real traffic patterns. No visibility under load: Endpoints may perform well in testing but fail when traffic spikes. You need to see how they behave under stress. AspectAd-hoc ScriptsChainbenchSetup timeHours to days5 minutesTest consistencyVaries per scriptStandardized profilesMethod coverageUsually 1-3 methods20+ methods per profileTraffic realismStatic patternsDynamic, weighted distributionResults formatCustom/inconsistentHTML reports + CSVProvider comparisonNearly impossibleDirect comparisonReproducibilityLowHighCommunity supportNoneOpen-source, documented The blockchain space needs what other infrastructure sectors already have: a standardized, transparent way to measure and compare performance. That’s exactly what Chainbench provides. What is Chainbench Chainbench is an open-source blockchain RPC benchmark tool that helps developers measure node performance under real-world conditions. It wraps a high-performance load generator (built on Locust) to simulate realistic blockchain traffic and reveal how nodes perform under stress. Key features: Multi-chain support: Works with EVM chains (Ethereum, Solana, Polygon, BSC, Arbitrum, Base, and more) Built-in profiles: Pre-configured test profiles for each chain that simulate realistic traffic patterns with weighted method distributions. Realistic test data: Uses actual on-chain data (blocks, transactions, addresses) to generate test parameters that match real usage. Flexible testing modes: Run tests via command-line for automation or use the interactive web UI for real-time monitoring. Comprehensive metrics: Captures latency percentiles (p50, p95, p99), requests per second, error rates, and detailed performance breakdowns. Chainbench is completely open source. This transparency allows the community to verify the methodology, contribute improvements, and establish it as a standard blockchain RPC benchmark. See it in action Let’s look at three common scenarios where Chainbench helps you make better infrastructure decisions. Scenario 1: Quick performance check You want to quickly test how fast your endpoint responds to a common RPC call. Install Chainbench and run a single-method test: pip install chainbench chainbench start eth_blockNumber \   --users 50 \   --workers 2 \   --test-time 5m \   --target https://your-endpoint.example \   --headless --autoquit This simulates 50 concurrent users continuously calling eth_blockNumber for 5 minutes. Within seconds, you’ll see requests per second, latency percentiles, and failure rates. When to use this: Quick smoke tests, verifying endpoint availability, or testing a single method’s performance before production deployment. Scenario 2: Realistic workload testing Your app doesn’t just call one method—it makes a mix of requests: reading balances, fetching transactions, querying logs. Test with a profile that matches real-world usage: chainbench start \   --profile evm.light \   --users 100 \   --workers 4 \   --test-time 10m \   --target https://your-endpoint.example \   --headless --autoquit The evm.light profile mixes common read methods with realistic weights: eth_blockNumber eth_getBalance eth_getBlockByNumber eth_getTransactionReceipt eth_call Chainbench also includes chain-specific profiles (bsc.general, polygon.general, solana.general) and heavier profiles that test resource-intensive operations like eth_getLogs and debug traces. When to use this: Performance validation before production, comparing multiple providers, or establishing baseline metrics for your infrastructure. Scenario 3: Verifying method support Before running extensive tests, verify which RPC methods your endpoint actually supports: chainbench discover https://your-endpoint.example \   --clients geth,erigon This checks your endpoint against known method specifications for different node clients (Geth, Erigon, etc.) and shows you: ✓ for methods that work ✗ for unsupported methods Error codes for methods that return errors When to use this: Validating new node deployments, auditing provider capabilities, or debugging unexpected method failures. What the results look like After each test, Chainbench generates a detailed HTML report showing: Latency distribution: Median (p50), 95th percentile (p95), 99th percentile (p99), and maximum response times. Throughput metrics: Total requests per second (RPS) across all methods. Error analysis: Failure rates and error types for each method. Time-series graphs: Performance over time to identify degradation patterns. These metrics answer the questions that matter: Does my endpoint handle p95 requests under 100ms? What happens at 500 RPS? Where does it start failing? The report also includes downloadable CSV files for further analysis or integration into your monitoring dashboards. Advanced features for power users Beyond basic load testing, Chainbench supports several advanced scenarios: Custom profiles: Create profiles that match your exact traffic patterns with custom method weights and timing. Load shapes: Test with step patterns (gradual ramp-up) or spike patterns (sudden traffic bursts) to simulate real-world scenarios. Sync lag monitoring: Track how far behind your node falls during load testing. Batch requests: Test JSON-RPC batch request performance with configurable batch sizes. Interactive web UI: Watch tests run in real-time, adjust parameters on the fly, and export results directly from the browser. Getting started Ready to benchmark your infrastructure? Here’s what you need: Python 3.10 or higher A blockchain RPC endpoint to test 5 minutes to run your first test Install Chainbench and start testing: pip install chainbench chainbench --help For a complete step-by-step guide covering installation, advanced usage, and custom profile creation, check out the official Chainbench tutorial in the Chainstack documentation. Don’t have an RPC endpoint yet? Deploy one on Chainstack with support for 70+ protocols including Ethereum, Base, Solana, and more. Conclusion Blockchain infrastructure performance shouldn’t be a mystery wrapped in marketing speak. Chainbench provides the transparency and standardization the industry needs to make informed decisions about RPC endpoints. It sets the foundation for what an effective blockchain RPC benchmark should look like. Use Chainbench to: Validate node performance before production deployment Compare providers with apples-to-apples benchmarks Test your infrastructure under realistic load conditions Establish baseline metrics for monitoring and alerting Automate performance testing in CI/CD pipelines As a community-driven open-source project, Chainbench will continue to evolve with contributions from developers who need better tools for infrastructure testing. We invite you to try it, share your feedback, and help push the industry toward faster, more reliable blockchain infrastructure for everyone. Start benchmarking today Power-boost your project on Chainstack  Chainstack helps Web3 teams reduce infrastructure costs while scaling reliably across multiple blockchains. With transparent pricing and production-ready tooling, you can run RPC workloads without overpaying for unused capacity. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Tempo, Avalanche, Hyperliquid, Monad, Aptos, and more — all from a single platform designed for developers. Chainstack also provides fast access to archive data, Solana gRPC streaming, and public testnet faucets to support development and testing. Get started for free, explore pricing for your workload, or learn more in the Developer Portal. #### Blockchain RPC for AI agents: infrastructure guide (2026) Key takeaways AI agents generate a fundamentally different RPC load profile than dApps — burst requests, deep parallelism, and unpredictable timing that shared endpoints were never designed to absorb. Rate limits are the primary infrastructure bottleneck for agentic workflows. Understanding the difference between RPS, RPM, and Request Units is the first step to sizing your infrastructure correctly. Request batching, connection pooling, and fallback chains are the three architectural patterns that meaningfully reduce agent failure under load. Dedicated Nodes eliminate rate limit contention entirely. Global Nodes with geo-routing reduce the P99 latency spikes that break multi-step agent reasoning chains. Chainstack’s MCP server lets AI coding assistants deploy nodes, query live chain data, and search docs — without leaving the IDE or terminal. An infrastructure checklist for production agentic systems is at the end of this article. Introduction: why your AI agent is not just another dApp user When a human uses a DeFi application, they click a button, wait two seconds, read the result, and click again. The RPC node handling that request sees a trickle — maybe a few calls per minute, with natural pauses built in by human cognition. Your AI agent does not pause to think. A moderately complex DeFi agent — one that monitors liquidity pools, calculates optimal routes, checks token approvals, and executes a transaction — can generate 50 to 200 RPC calls in the time it takes a human to reach for their coffee. A multi-agent system coordinating three or four specialized sub-agents multiplies that by the number of parallel threads running simultaneously. Add a feedback loop where the agent re-queries state after each action, and you are looking at sustained request rates that would immediately trigger rate limiting on any shared public endpoint. This is not a theoretical problem. It is the first infrastructure wall most teams building on-chain AI agents hit, usually at the worst possible moment: during a live demo, or when a real transaction is on the line. This article covers what that wall actually looks like at the infrastructure level, the architectural patterns that let you work around it, and how to choose node infrastructure that matches how agents actually behave — rather than how dApp users do. 1. How AI agents use blockchain RPC — understanding the load profile Before you can make the right infrastructure decision, you need to understand what your agent’s RPC traffic actually looks like. It is almost certainly not what traditional node provider capacity planning assumes. Burst vs. steady-state traffic A typical web3 dApp generates relatively predictable traffic with gradual peaks. User sessions are bounded by human attention spans. Even a popular DEX sees traffic spikes that follow recognizable patterns — market opens, news events, gas price windows. An AI agent’s traffic pattern looks nothing like this. Agents fire requests in bursts tied to their internal reasoning cycles, not to human behavior. A LangChain agent with tool calls to an Ethereum node will generate zero requests for several hundred milliseconds while the language model processes its context window, then fire five or ten requests in rapid succession as it executes a reasoning step. This creates a jagged, spiky load profile that is hostile to shared infrastructure designed around average throughput assumptions. If your provider enforces a requests-per-second (RPS) limit, an agent that hits 10 RPS in a 200-millisecond burst can trigger a 429 even if its average rate over the last minute is well within limits. Parallelism from multi-agent systems Single-agent systems are manageable. Multi-agent systems — where a coordinator dispatches tasks to specialized sub-agents that run concurrently — multiply your RPC load by the number of active agents. If you have a portfolio monitoring agent, a trade execution agent, and a risk assessment agent all querying the same Ethereum node simultaneously, your effective request rate is the sum of all three, not the average. Frameworks like LangGraph, CrewAI, and AutoGen make it straightforward to build multi-agent pipelines. They do not make it straightforward to reason about the aggregate RPC load those pipelines generate. You need to do that math yourself before your agents hit production. Long-running workflows vs. one-shot transactions A user submitting a transaction from a browser wallet completes in seconds. An agent managing a yield optimization strategy might run continuously for hours, re-querying prices, recalculating positions, and monitoring on-chain events in an ongoing loop. Long-running workflows expose a failure mode that one-shot transactions never encounter: accumulated rate limit pressure. An agent that stays within RPS limits but generates 50,000 calls over the course of a day can hit daily or monthly request caps on shared plans, causing the endpoint to start refusing requests mid-workflow. Unlike a failed transaction, this failure is silent from the user’s perspective — the agent just stops making progress. Concrete load patterns by agent type Agent typeTypical RPC methodsLoad patternDeFi yield optimizereth_call, eth_getStorageAt, eth_getLogsContinuous polling with burst on rebalanceOn-chain data analysteth_getLogs, debug_traceBlock, eth_getBlockByNumberHeavy archive reads, episodic burstsTransaction execution agenteth_sendRawTransaction, eth_getTransactionReceipt, eth_callLow steady-state, high burst at executionPrice monitoring agenteth_call against price oracles, WebSocket subscriptionsSustained high-frequency pollingMulti-chain bridge agentAll of the above, multiplied across chainsHighest aggregate load 2. Rate limits: what they actually mean for agents Rate limiting is the most misunderstood aspect of RPC infrastructure for teams new to agentic systems. Most developers understand rate limits in theory. Far fewer understand the three distinct dimensions across which limits are enforced — or why each one matters differently for agents. RPS, RPM, and Request Units — the three dimensions Requests per second (RPS) is the instantaneous burst limit. Hit 100 requests in a single second on a plan that allows 25 RPS and you will receive 429 responses for the excess, regardless of how quiet you were in the previous minute. This is the limit that kills agents with tight reasoning loops. Requests per minute (RPM) is the rolling window average. Some providers use this instead of, or in addition to, RPS limits. An agent that paces itself to avoid RPS limits can still hit RPM caps if its minute-over-minute average creeps up. Request Units (RU) are Chainstack’s usage metric — and the most practical dimension for cost planning. The model is intentionally simple: a standard full-node call costs 1 RU; an archive node request or Debug & Trace API call costs 2 RUs. That’s it. No opaque compute unit tables with hundreds of method-specific costs. For an agent that heavily uses debug_traceTransaction or eth_getLogs against historical blocks, the 2 RU cost per call is the number to build your capacity model around. Estimating your agent’s RU consumption: list every RPC method your agent calls. Full-node methods = 1 RU each. Archive or Debug & Trace methods = 2 RUs each. Multiply by expected calls per workflow run, then by runs per day. Add a 3x buffer for burst spikes and parallelism from multi-agent coordination. Why public endpoints destroy agentic workflows Public RPC endpoints from chain foundations are designed for developer testing, not production workloads. They enforce aggressive RPS limits (typically 1–5 RPS), do not offer WebSocket subscriptions at any useful reliability level, and apply no SLA guarantees. An agent hitting a public endpoint in a burst will receive 429 responses immediately. If the agent is not built to handle 429s gracefully — and most aren’t on first implementation — it will either crash or enter a retry loop that eventually times out and loses whatever state it was maintaining. Beyond rate limits, public endpoints impose another problem: no request isolation. Every other developer testing against the same endpoint competes with your agent for capacity. Traffic spikes from unrelated developers affect your agent’s latency, unpredictably and without warning. What happens when you exceed rate limits The immediate effect is a 429 Too Many Requests HTTP response. What happens next depends on how your agent handles it: No retry logic: the call fails, the exception propagates up the call stack, and the workflow terminates or enters an error state. Any in-progress state that wasn’t persisted is lost. Naive retry (immediate): the agent retries instantly, hits the limit again — creating a retry storm that makes the problem worse. Exponential backoff (correct approach): the agent waits 1 second, then 2, then 4, backing off until the rate limit window resets. Minimum viable implementation, but it introduces latency into time-sensitive workflows. State loss under sustained limits: if rate limiting persists longer than the agent’s internal timeout, even correct backoff fails. The workflow must restart from scratch — or worse, in an inconsistent on-chain state if a partial transaction sequence was in progress. Chainstack’s error responses are standardized and designed to be machine-readable: they include helpful details and links to documentation so your agent knows exactly what happened and what to do next — whether it needs to upgrade a plan, reduce its request rate, or switch to a different endpoint. 3. RPC patterns for agentic workflows Given the load profile described above, the following architectural patterns meaningfully reduce failure rates and latency for on-chain agents. Request batching JSON-RPC supports batch requests — multiple method calls sent in a single HTTP request, returning a single response array. Most agent frameworks do not use this by default. [ {"jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xABC...", "latest"], "id": 1}, {"jsonrpc": "2.0", "method": "eth_getTransactionCount", "params": ["0xABC...", "latest"], "id": 2}, {"jsonrpc": "2.0", "method": "eth_call", "params": [{"to": "0xDEF...", "data": "0x..."}, "latest"], "id": 3} ] Sending three calls as one batch request consumes one RPS unit instead of three. For agents that need to read multiple state variables at each reasoning step, batching can reduce effective RPS consumption by 60–80%. For on-chain read operations across multiple contracts, Multicall3 goes further — it aggregates arbitrary eth_call invocations into a single contract call, reducing both RPS consumption and latency for complex state reads. Chainstack nodes support all standard simulation methods your agent needs for increased inference time and safer decision-making: eth_simulateV1 and eth_call for EVMs, simulateTransaction for Solana, and full forking with Foundry. An agent can simulate a transaction before executing it, giving it time to reconsider without committing gas. Connection pooling and persistent connections HTTP/1.1 connections have overhead at the TCP handshake level. An agent that opens a new connection for every RPC call adds 20–100ms per call in connection setup latency. This compounds badly in tight reasoning loops. Use HTTP/2 where your provider supports it — it multiplexes multiple requests over a single connection. At minimum, configure your HTTP client to use keep-alive connections. For Python-based agents using web3.py: from web3 import Web3 from requests import Session from requests.adapters import HTTPAdapter session = Session() adapter = HTTPAdapter(pool_connections=10, pool_maxsize=20, max_retries=3) session.mount("https://", adapter) w3 = Web3(Web3.HTTPProvider(YOUR_CHAINSTACK_ENDPOINT, session=session)) Retry logic with exponential backoff and jitter Exponential backoff with jitter prevents the thundering herd problem where multiple agent threads all retry at exactly the same moment after a 429. import random import time def rpc_call_with_backoff(func, max_retries=5): for attempt in range(max_retries): try: return func() except Exception as e: if "429" in str(e) and attempt < max_retries - 1: wait = (2 ** attempt) + random.uniform(0, 1) time.sleep(wait) else: raise WebSocket subscriptions for event-driven agents Agents that need to react to on-chain events have two options: poll with repeated eth_getLogs calls, or receive via push. Polling is RPS-expensive and introduces latency proportional to your polling interval. WebSocket subscriptions via eth_subscribe give you real-time event delivery without polling overhead: async def subscribe_to_events(ws_url, contract_address, event_topic): async with websockets.connect(ws_url) as ws: await ws.send(json.dumps({ "jsonrpc": "2.0", "method": "eth_subscribe", "params": ["logs", {"address": contract_address, "topics": [event_topic]}], "id": 1 })) async for message in ws: event = json.loads(message) await handle_event(event) Fallback chains for resilience A single RPC endpoint is a single point of failure. For production agents, implement a fallback chain: ENDPOINTS = [ "https://your-chainstack-dedicated-node.p2pify.com/...", "https://your-chainstack-global-node.p2pify.com/...", ] def get_web3_with_fallback(endpoints): for endpoint in endpoints: try: w3 = Web3(Web3.HTTPProvider(endpoint)) if w3.is_connected(): return w3 except Exception: continue raise RuntimeError("All RPC endpoints unavailable") 4. Infrastructure requirements for production agents Dedicated vs. shared nodes Shared node infrastructure means your agent competes with other users for a capped pool of capacity. Even if your plan’s stated limits would theoretically support your agent’s load, noisy neighbors can push you into congestion and degraded performance without triggering an explicit rate limit response. Dedicated Nodes give your agent a node that no other user can access. No competing tenants. No noisy neighbor effects. Rate limits become a function of the node’s raw capacity, not a shared pool allocation. For production agentic systems, dedicated infrastructure is the appropriate default. Chainstack also exposes usage controls directly in the dashboard: you can set quotas to cap your agent’s request volume, get email alerts before each threshold is reached, and lift all limits via pay-as-you-go when your agent is generating value and you don’t want the infrastructure to become the bottleneck. Why P99 latency matters more than P50 for agents For agents, the tail latency — P99, the slowest 1 in 100 responses — is more operationally significant than the median. An agent executing a multi-step reasoning chain waits for each RPC response before proceeding. The probability of hitting at least one P99 response in a 20-call chain is approximately 18%. In a 100-call chain, it is nearly 63%. Chain lengthP99 hit probabilityPractical impact5 calls~5%Occasional slowdown20 calls~18%Noticeable in production50 calls~40%Frequent latency spikes100 calls~63%Consistent degraded performance When evaluating node providers, ask for P99 latency data, not just average or P50. Global Nodes with geographic routing reduce P99 by routing each request to the lowest-latency regional node rather than sending all traffic to a single datacenter. Archive nodes and Debug & Trace APIs for agents that need historical data Without archive access, any eth_call with a block number more than 128 blocks in the past returns an error on a full node. Agents that mix real-time execution with historical analysis need archive access — and they should verify it before building the workflow, not after. Chainstack supports archive nodes across chains and exposes the full Debug & Trace API suite. These cost 2 RUs per call instead of 1 — plan accordingly. The tradeoff is worth it for agents doing deep analysis: debug_traceTransaction, debug_traceBlock, and similar methods give your agent low-level execution traces that enable advanced reasoning on on-chain events. Built-in health checks for agent-aware infrastructure Chainstack exposes all standard health check endpoints so your agent can monitor node state in real time. An agent can call eth_syncing on any supported chain to check sync status, or query the Chainstack platform status API directly to verify overall platform health. This gives your agent real-time awareness of the infrastructure it depends on — and the ability to route around degraded nodes automatically. Multi-chain agents An agent operating across multiple chains needs a separate RPC endpoint per chain. The practical solution is a chain-keyed endpoint map with separate connection pools per chain: CHAIN_ENDPOINTS = { "ethereum": os.getenv("ETH_RPC_URL"), "polygon": os.getenv("POLYGON_RPC_URL"), "arbitrum": os.getenv("ARBITRUM_RPC_URL"), "base": os.getenv("BASE_RPC_URL"), "bnb": os.getenv("BNB_RPC_URL"), } def get_provider(chain: str) -> Web3: url = CHAIN_ENDPOINTS.get(chain) if not url: raise ValueError(f"No endpoint configured for chain: {chain}") return Web3(Web3.HTTPProvider(url)) Chainstack supports 70+ chains including Ethereum, Solana, Base, Polygon, Arbitrum, BNB Smart Chain, Hyperliquid, Monad, MegaETH, and more — so your multi-chain agent can use a single provider across the entire stack rather than stitching together endpoints from different vendors with inconsistent reliability and pricing models. 5. Chainstack for agentic AI Dedicated nodes: no rate limits, predictable throughput Dedicated Nodes provision a node exclusively for your use. No rate limits imposed by competing tenants. No noisy neighbor effects. Throughput is bounded only by the underlying hardware, which is documented and consistent. For production agents running continuous workflows, this is the only infrastructure model that gives you predictable capacity planning. You know what the node can handle, you can measure your agent’s actual load against that capacity, and you can scale predictably. Global nodes with geo-routing Global Nodes route each request to the lowest-latency regional node based on the source of the request. For agents deployed across multiple regions — or for teams that want to reduce P99 latency without provisioning dedicated infrastructure — geo-routing provides a meaningful improvement without additional configuration complexity. Transparent, predictable pricing Chainstack measures usage in Request Units (RUs): a standard full-node call costs 1 RU; an archive or Debug & Trace call costs 2 RUs. No per-method pricing tables with hundreds of entries. For agentic workloads where cost predictability matters as much as performance, this simplicity is a material advantage. You can set usage quotas in the dashboard to cap your agent’s spend, and receive email alerts before each threshold is reached. When your agent is ready for production and generating value, you can enable pay-as-you-go to remove limits entirely. The Chainstack MCP server The Chainstack MCP server connects AI coding assistants directly to live blockchain infrastructure. It runs at https://mcp.chainstack.com/mcp — no local installation, no package install, no Docker image required. It works with Claude Code, Claude Desktop, Claude.ai, Cursor, Windsurf, OpenAI Codex, Gemini CLI, and any other assistant that supports HTTP MCP transport. Five tools work without any authentication: ToolWhat it doessearch_docsSearch Chainstack documentation — RPC methods, deployment guides, code examplesget_doc_pageFetch the full content of any documentation pageget_platform_statusCheck live platform and network health across all supported chainsget_chainstack_pricingRetrieve current pricing data for any plan or node typecontact_chainstackRoute questions directly to the Chainstack team With a Chainstack API key, your agent also gets full node lifecycle management: deploy Global Nodes or Dedicated Nodes, inspect their status, get live RPC endpoints, and delete them when done — all from a single prompt. Connecting to Claude Code (one line): claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp --scope user Connecting to Codex CLI: codex mcp add chainstack --url https://mcp.chainstack.com/mcp Connecting to Cursor or Windsurf — add to your MCP config file: { "mcpServers": { "chainstack": { "transport": "http", "url": "https://mcp.chainstack.com/mcp" } } } Once connected, your coding assistant can deploy a Solana mainnet node and return a live endpoint in under a minute, query ETH balances or trace transactions inline, and search Chainstack docs for verified RPC method parameters — eliminating hallucinated method names and guessed parameter formats. Conclusion: infrastructure checklist for on-chain AI agents If your team is building an agent that makes real on-chain calls, run through this before going to production. Calculate RU consumption per workflow run — 1 RU per full-node call, 2 RUs per archive or Debug & Trace call. Add a 3x buffer for burst spikes. Implement exponential backoff with jitter on all RPC calls. Test 429 handling explicitly in staging. Use JSON-RPC batch requests for multi-variable reads. Replace polling with WebSocket subscriptions where latency matters. For production: Dedicated Nodes. For latency-sensitive workloads: Global Nodes with geo-routing. Verify archive node access before building historical workflows, not after. Set usage quotas and alerts in the Chainstack dashboard. Track RU consumption per run to catch cost drift early. Connect your AI agent to Chainstack — no rate limits, no surprises. Dedicated Nodes for production agentic workloads. Global Nodes for global low-latency access. Archive and Debug & Trace API support across 70+ chains. Get started for free → FAQ What’s the difference between Dedicated Nodes and Global Nodes for agents? Dedicated Nodes are provisioned exclusively for you — no competing tenants, no shared rate limits. Global Nodes are geo-balanced shared infrastructure that routes each request to the lowest-latency regional node. For production agents where predictable throughput is critical, Dedicated Nodes are the right default. For agents where latency reduction matters more than isolation, Global Nodes with geo-routing are a strong choice. How does Chainstack count request usage for agents? In Request Units (RUs). A standard full-node call = 1 RU. An archive node request or Debug & Trace API call = 2 RUs. You can monitor usage in real time via the dashboard, set quotas to cap spend, and enable pay-as-you-go to remove limits when your agent is in production. Can my agent deploy its own nodes via the MCP server? Yes. With a Chainstack API key, your agent can create, inspect, and delete both Global Nodes and Dedicated Nodes on any supported chain via the Chainstack MCP server. Nodes deployed via MCP appear in your Chainstack console exactly like any manually created node. What simulation methods does Chainstack support for agents? Full simulation support: eth_simulateV1 and eth_call for EVMs, simulateTransaction for Solana, and full forking with Foundry. This lets agents increase inference time — simulate before they execute — without being constrained by the RPC layer. Does the Chainstack MCP server require local installation? No. The Chainstack MCP server runs as a remote Streamable HTTP server at https://mcp.chainstack.com/mcp. Any AI assistant that supports HTTP MCP transport connects directly — no binary download, no package install, no Docker image required. It works with Claude Code, Cursor, Windsurf, Codex, Gemini CLI, and others. Which chains does Chainstack support for agentic workloads? 70+ chains including Ethereum, Solana, Base, Polygon, Arbitrum, BNB Smart Chain, Hyperliquid, Monad, MegaETH, Avalanche, Aptos, and more. See the full list at chainstack.com/protocols. Related reading Blockchain RPC nodes optimized for AI agents Chainstack MCP server How to connect Chainstack MCP server to Claude How to connect Chainstack MCP server to Codex Building a Web3 AI trading agent from scratch Chainstack MCP server documentation Mastering Web3 LLMs and AI use #### Blockchain security: An in-depth look at smart contract audits As the blockchain industry evolves, one of the most fascinating and potentially transformational innovations is the concept of smart contracts. Functioning as self-operating programs, smart contracts can execute transactions without the need for an intermediary, thereby increasing efficiencies and reducing costs. However, the automated and immutable nature of smart contracts brings with it a certain level of risk. The protocols are often responsible for managing and transferring high-value assets, which makes security anything but an afterthought. In this decentralized landscape, ensuring smart contract security is paramount, and one of the most effective ways to achieve this is through a thorough smart contract security audit. In the following sections, we’ll venture deeper into what smart contract security audits are, the role they play in enhancing smart contract reliability, and why they are now an indispensable step in the smart contract deployment journey. What is a smart contract security audit? A term that perhaps sounds complex on first encounter, ‘smart contract security audit’, is relatively straightforward once unpacked. It is a rigorous, detailed examination carried out on a protocol’s smart contract code to detect potential security flaws, inefficient coding practices, and to suggest appropriate solutions to rectify the detected weaknesses. This pivotal process plays a substantial role in assuring the security, reliability, and performance of today’s revolutionary decentralized applications on Web3 platforms. During this critical audit, security experts run a fine-toothed comb through essential aspects of the application, including its code, logic, architectural design, and security strategies. The objective is to catch any potential vulnerabilities that could be the prey of malicious actors and identify possible areas for improvement. Tools of both automated and manual nature are employed in this process. Figure 1: Smart Contract Security and Auditing 101; Source: Chainlink In the realm of decentralized applications, vulnerabilities can have catastrophic consequences. This is why security audits are mandatory before launching or updating an application. The blockchain, whether it be Ethereum, Avalanche, or BNB Chain, is open for anyone to interact with – from end-users to attackers looking for exploitable vulnerabilities. An audit concludes with the release of a detailed review report. This document outlines their findings, the measures taken for resolution, and any other issues, coupled with a roadmap for tackling unresolved ones. Armed with this comprehensive audit report, project developers can confidently deploy their smart contracts, secure in the knowledge that the infrastructure is securely built, and user funds are adequately protected. Why smart contract security audits? The exponential surge in blockchain technology applications has brought smart contract security issues into sharp focus. For the uninitiated, smart contracts are simply computer programs that automatically execute transactions when predetermined conditions are met. While this forward-thinking technology has brought about an unprecedented level of efficiency, it also brings on board certain risks with it. This is where the role of smart contract security audits becomes crucial. Why, you might ask? Well, let’s first understand the repercussions of neglecting smart contract security audits. Minor coding errors, overlooked due to the absence of proper audits, can quickly escalate into major security breaches, resulting in large-scale asset heists. A chilling run-down memory lane brings us to the DAO hack on the Ethereum blockchain, which led to a loss of around $60 million in Ether. This event shook the cryptocurrency industry, underlining the critical importance of an impregnable security infrastructure. Figure 2: $5.13B in Total Value Lost to hacks in DeFi as of FEB 20, 2023; Source: Chainlink Businesses are well aware of the irreversible and autonomous nature of smart contracts, prompting a well-founded degree of caution towards their deployment. The inability to change or modify smart contracts after deployment, backed with the inherent security vulnerabilities, risk not only loss of the contract but its associated assets as well. Therefore, smart contract security auditing is no longer an optional add-on, but a critical necessity, driven by several compelling reasons: Avoidance of costly errors: Identifying and rectifying errors early in the development lifecycle can prevent catastrophic failures post-launch. Expert review: Automated algorithms can detect a host of issues, but nothing beats the precision of a seasoned security auditor manually checking the code to eliminate false positives. Thwarting security attacks: Awareness and timely action on security vulnerabilities can potentially ward off malicious attacks. Assurance of security: Stakeholders of decentralized products gain confidence in the solidity of the code underpinning their applications. Ensuring continuous security assessment: The smart contract auditing procedure facilitates continuous security assessments, helping developers constantly improve their application’s security infrastructure. Provision of comprehensive reports: Audit reports offer a wealth of information, including a bird’s-eye view of your application’s security status, detailed vulnerability explanations, and recommendations for risk mitigation. Common smart contract vulnerabilities Smart contracts, while revolutionary, can be riddled with pitfalls if not coded and tested carefully. One of the main advantages of a thorough audit is the ability to identify common and potential vulnerabilities before smart contracts are deployed into the public blockchain. Here are some of the common vulnerabilities often found in smart contract security audits: Reentrancy issues: This type of attack occurs when a smart contract function is being called, and during the execution of that function, control is transferred to an external untrusted contract which comes back to the original contract and runs the same function again. This recursive calling can lead to repetitive withdrawals, potentially draining funds from the contract. Integer overflow and underflow: These issues arise when arithmetic operations generate a result exceeding the maximum or minimum size that can be held within a variable. The overflow or underflow results in incorrect values being returned and used, leading to potential exploitation. Frontrunning opportunities: Frontrunning in smart contracts refers to the ability of an attacker to see a smart contract interaction request and then craft a proposal that, by paying a higher gas fee, gets placed ahead of the original request. This exploitation can lead to financial losses for the original requester or an unfair advantage to the attacker. Replay attack: Replay attacks are devious; they involve the capturing and retransmission of a valid data transmission. They can occur during blockchain hard fork events, causing messages on the new network to be used maliciously to extract funds from the old network. Function visibility errors: Function visibility defines who can call a program’s function. By default, functions are public in Solidity. Therefore, if not explicitly set, functions that were intended to be private could be called by anyone—potentially enabling unauthorized operations. Centralization risks: The beauty of blockchain lies in its decentralized nature. However, if smart contracts retain some types of central control, it introduces a point of failure that could be exploited, undermining the entire security framework. Unlocked compiler version: Different compiler versions can lead to different bytecode, leading to unintended complications. Smart contracts should lock the version of the compiler they use to maintain consistency. Understanding these common vulnerabilities is an essential step towards ensuring the robustness of smart contracts, enabling them to withstand potential attacks and exploits. Mitigating risks: Solutions and strategies Navigating the landscape of smart contract development and deployment comes with inherent risks. However, smart contract security audits act as your compass, identifying potential issues and charting a roadmap towards more secure implementation. Here are some strategies for mitigating risks and enhancing the strength of your smart contracts: Regular security audits: Regular security auditing is key in maintaining continual assessment and assurance of smart contract security. Audits should not be a one-time process but a repeat activity incorporated into the development lifecycle. Adopting industry best practices: Best practices provide developers with benchmarks for their coding methodologies. They include coding strategies and resources that have been proven to create safe and efficient smart contracts. Security testing: From conducting fuzzing (inputting massive amounts of random data to trick the system) to unit tests (checking individual parts of the application), it’s crucial to test a project’s resistance to various attack scenarios. Manual code review: Human intuition and expertise still play a substantial role in identifying and solving issues within a smart contract. This step backs up automated testing and can spot discrepancies even the most advanced automated tests might miss. Use of secure dependencies: It is crucial to verify the security of third-party smart contracts before incorporating them into a project. Trusted libraries should always be preferred over creating code from scratch. Writing clear & simple code: The simpler, clearer, and more transparent the code, the better. Complex code not only fosters potential security risks but also makes auditing more difficult. Keeping contracts upgradable: Ensuring that smart contracts are upgradable can be one effective way to resolve issues in the aftermath of a vulnerability disclosure. Equip your smart contracts with these strategies to effectively protect against known vulnerabilities and be prepared to tackle unforeseen security challenges. The audit process in a nutshell Now that we understand the importance of a smart contract audit and its benefits, let’s dive deeper into what the audit process entails. It’s a complex but necessary task that involves several key stages. Step 1. Collect documentation For the audit to begin, the project undergoing the audit must instigate a code freeze, effectively locking the existing state of the project’s code. They then provide the auditors with all relevant technical documentation—this can range from the codebase to specific technical specifications, white papers, and architectural diagrams. This documentation provides critical context and guides the auditors in understanding the project’s goals, scope, and implementations. Step 2. Automated testing Auditors employ a formal verification engine, also known as an automated testing mechanism. This engine carries out an extensive check of every conceivable state of the smart contract and alerts the auditors to any issues potentially compromising the contract’s functionality or security. Auditors also conduct additional tests on individual functions and perform penetration testing, a simulated cyber attack on the smart contract, to study the contract’s response and locate any security vulnerabilities. Step 3. Manual review Manual code reviews follow automated testing. Here, an experienced team of security experts meticulously examines each line of the smart contract to identify anomalies and vulnerabilities. While automated tests are efficient at identifying bugs in the code, human engineers are better equipped to uncover issues like discrepancies in contract logic or architecture and opportunities for gas optimization—problems often overlooked by automated tools. Figure 3: Two forms of manual code analysis; Source: CoinTelegraph Step 4. Classification of contract errors Each vulnerability is then categorized based on its severity: Critical: These issues impact the protocol’s safe functioning. Major: These are typically centralization and logical errors that could lead to loss of user funds or loss of control over the protocol. Medium: These issues affect the performance or reliability of the platform. Minor: These involve inefficient code that, while not immediately dangerous, is best avoided. Informational: These relate to style or best practices within the industry. Figure 4: Classification of code flaws based on its severity and potential impact; Source: CoinTelegraph Step 5. Initial report Following this, auditors draft an initial report summarizing the discovered flaws and suggest potential solutions to these issues. Some smart contract service providers have dedicated experts who can assist in fixing the identified bugs. By addressing all deficiencies, projects can deploy smart contracts, secure in the knowledge they are optimized for potential threats. Step 6. Publish final audit report Finally, the auditor generates a comprehensive report detailing all discoveries. This report marks all identified issues as either resolved or unresolved. The project team receives this report and usually, make it public, enabling all stakeholders (users, investors, partners) to have full transparency into the security of the protocol. The audit, though intricate and time-consuming, remains an important hurdle a project must clear to ensure it is secure and ready for actual deployment. Find out more about the security policies we have implemented on the Chainstack platform for your convenience here. Further reading SOC 2 Type 1 and our commitment to secure Web3 infrastructure: Build securely with Chainstack’s SOC 2 Type 1 certified infrastructure. Unmasking DApp endpoint security: Explore our research findings on DApp endpoint security across 8,000+ projects, revealing crucial vulnerabilities across Web3. CertiK on Chainstack: See how CertiK cut Ethereum archive costs by 70%+ with Chainstack for its radical take on Web3 security, from audits to real-time monitoring. Hypernative on Chainstack: Discover how Hypernative reinforces Web3 security with resilient Chainstack infrastructure, optimizing asset protection and efficiency. FailSafe on Chainstack: Discover how Chainstack infrastructure revolutionizes FailSafe’s Web3 security to reduce latency, boost transaction volumes, and user safety. Wallet security best practices: Learn the basics of protecting your digital assets securely. Bringing it all together The world of smart contracts is booming, bringing exciting opportunities for many industries. However, with new technologies come new challenges and potential vulnerabilities. To ensure the success and security of these revolutionary protocols, smart contract security audits have become an imperative. These audits, encompassing both automated and manual checks, bring a high level of scrutiny to catch and classify potential vulnerabilities and weak points. From reentrancy issues to intrinsic issues like integer overflow, audits help protect against common security threats. They bring a magnifying glass to a contract’s code, clearing the path to a secure and efficient deployment. Vigilance in the face of potential risks and dedicated attention to best practices can help ensure the integrity of a project’s blockchain endeavors. Regular audits, secure dependencies, and upgradability are some solutions that, when incorporated within a development strategy, help fortify smart contracts and safeguard them against threats and exploitation. Smart contract audits are more than just a security measure. They instill confidence—confidence among the development team that they are creating a more secure protocol and confidence among users that their funds are protected. In the fast-paced, ever-evolving world of blockchain, this sense of trust is priceless. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain social media: The rise of decentralized social platforms Social networks have served as the backbone of our digital age, catalyzing connections and communications beyond geographical limitations. However, the centralized control mechanisms of these platforms frequently compromise their virtues, leading to data breaches, privacy violations, and unwanted censorship. To counter these insidious issues, the tech industry is increasingly turning towards blockchain technology. Thus, decentralized social networks have come into the picture. Decentralized social networks, unlike their centralized counterparts, function on blockchain-based platforms. These cutting-edge platforms empower users by enabling them to exchange information and create and distribute content to audiences. Operating on the blockchain, they are naturally characterized by their decentralized nature and the ensuing resistance to censorship and unwarranted control. In stark contrast to established social media services such as Facebook, LinkedIn, Twitter, and Medium, these blockchain-powered networks put users first, ensuring user sovereignty and security. Let’s explore the world of decentralized social networks and what benefits they bring. Centralized vs decentralized social networks Traditional social media platforms, functioning under the centralized architecture, have often faced backlashes for their opaque, autocratic decision-making, and high susceptibility to a data breach. The centralized model allows for single point-of-failure, posing significant risk. On the other hand, decentralized social networks, built on the bedrock of blockchain technology, eliminate these risks and offer superior performance. Being part of a peer-to-peer network that spans across the globe, even if some nodes malfunction, the network remains uninterrupted. This feature makes these systems inherently resistant to failures and outages. Leveraging blockchain technology, decentralized social networks protect user information from exploitation and unauthorized use, ensuring users won’t end up inadvertently selling their personal information to advertisers or fall prey to hackers. Figure 1: Decentralized social networks vs. traditional social networks; Source: CoinTelegraph How decentralized social networks operate Decentralized social networks represent a prime example of DApps powered by smart contracts deployed on the blockchain. The smart contract codes serve as the backbone of these platforms, outlining their logistics and business model. Traditional social networks rely heavily on centralized databases to store user information, content, and other data forms. This mechanism creates single points-of-failure and poses significant risks. An ideal example would be the infamous outage of Facebook’s servers, resulting in users being cut off from the platform for several hours. On the contrary, decentralized social networks are rooted in a peer-to-peer network comprising thousands of nodes worldwide. Because of this global distribution, the network operates seamlessly even if a few nodes fail, rendering it resilient to failures and outages. Decentralized social networks utilize storage systems like the InterPlanetary File System (IPFS), offering an impregnable protection level to user data. Consequently, users can rest assured about the safety of their personal data. Many blockchain-based social platforms have also integrated native tokens into their systems to enable monetization without resorting to advertising revenues. Users can purchase these tokens to unlock certain features, complete in-app purchases, or tip their favorite content creators. The advantages of using decentralized social networks The advantages of decentralized social networks are multifold: Censorship-resistant: Decentralized social networks are open to everyone, ensuring users cannot be arbitrarily banned, deplatformed, or restricted. Open-source: Emboldened by open-source ideals, these networks preserve their applications’ source codes for public scrutiny. By eliminating opaque algorithms that traditional social media commonly employ, blockchain-based social networks can align users’ and platform creators’ interests more effectively. Direct ownership: By eliminating the middle man, decentralized social networks confer content creators with direct ownership over their content and enable them to engage directly with followers, fans, and other participants, interrupted only by a smart contract. Less prone to outages: As DApps running on the Ethereum network, decentralized social networks are less susceptible to server downtime and outages due to their global, peer-to-peer node network. Improved monetization: By integrating NFTs, in-app crypto payments, and more, decentralized social networks offer content creators an improved monetization framework. Enhanced privacy: Decentralized social networks afford users a high level of privacy and anonymity. For instance, an individual can sign into an Ethereum-based social network using an ENS profile or wallet—without sharing personally identifiable information (PII), such as names, email addresses, etc. Better safeguarding of user data: Decentralized social networks leverage decentralized storage, which is considerably better at safeguarding user data than centralized databases. Unfortunately, as with all technologies, there are challenges and limitations to be contended with. Challenges and limitations of decentralized social networks As revolutionary as they may be, decentralized social networks are not without their unique set of limitations and growth complications: Technological understanding: Understanding and adopting blockchain technology and the concepts of DApps, cryptocurrencies, and digital wallets can be a demanding task for the average user. The complexity of blockchain concepts can act as a barrier to entry for many. Scalability: The scalability issue is ubiquitous across blockchain platforms, affecting Ethereum-based decentralized social networks as well. As the number of users grows, the speed of operations can be significantly reduced. Transaction fees: Every operation on the network, except reading data, requires token-based transaction fees (“gas” on the Ethereum network). Since these fees fluctuate based on network congestion, it could deter a good portion of prospective users. Public perception of cryptocurrency: Despite growing recognition, cryptocurrencies are still often associated with fraudulent activities and speculative investments, deterring some potential users. Regulatory approvals: With governments worldwide debating over cryptocurrency regulations, the legal standing of decentralized social networks may face future challenges. Digital divide: Global population segments without access to consistent internet and modern technological devices could be left at a disadvantage, potentially exacerbating the digital divide. Despite these challenges, various innovative decentralized social networks have emerged and flourished. In the next section, let’s shine a light on some notable examples of decentralized social networks that have been successful in bringing about positive change in the world of social networking. Notable examples of decentralized social networks Let’s look at some decentralized social networks that are paving new paths in the realm of digital communication: Friend.Tech: Recently launched on Coinbase’s Base, a new layer 2 network, Friend.Tech offers a novel concept in Web3 social interaction. This platform allows users to tokenize their online personas, enabling others to buy “shares” in them. Owning shares grants access to private chats, with the share value varying based on market dynamics. Lens Protocol: Developed by the creators of Aave in 2022, Lens Protocol is a decentralized social graph platform enabling creators to fully own their content. It empowers users with tools to build their social media platforms using advanced Web3 technology. This innovative approach facilitates the creation of unique, user-controlled social media experiences, emphasizing content ownership and decentralization within the social media ecosystem. Peepeth: A microblogging platform similar to Twitter, Peepeth is built on the Ethereum blockchain and leverages IPFS for secure user data storage. Users can send “Peeps”—concise messages that once sent, are immutable, emphasizing the permanence of words. Tipping is made easy, with users able to tip their favorite content creators in Ether directly from the app. Pixelfield: Launched in 2018 as a decentralized alternative to Instagram, Pixelfield places a strong emphasis on user data control and privacy. The platform ensures the confidentiality of users’ images and offers an ad-free experience. Built with decentralization in mind, Pixelfield represents a shift towards more secure and user-centric photo-sharing services. Mirror: Mirror serves as a decentralized writing platform designed with the user-centric ethos in mind. Apart from free reading and writing by simply connecting wallets, Mirror opens up avenues for writers to mint their posts into NFTs—preserving their work indefinitely on the blockchain. MINDS: MINDS is one of the most prominent names in the decentralized social network sphere. Functioning similarly to Facebook, MINDS has garnered millions of users so far. The platform is underpinned by its native ERC-20 token, $MIND, which users earn by delivering popular content, enhancing the ecosystem, and referring others to the platform. Mastodon: As the world’s largest free, open-source, decentralized microblogging network, Mastodon presents itself as a noteworthy alternative to Twitter. It allows users to create and share brief text posts and follow others within a decentralized framework. Emphasizing its commitment to open-source development, Mastodon offers a unique social media experience that prioritizes user control and decentralization. Integrating blockchain with traditional social media platforms Web3 native social platforms are not the only players interested in integrating blockchain technology into their frameworks: Reddit: Reddit is now experimenting with Community Points—an ERC-20 token that users can earn by contributing valuable content to their community, also known as a subreddit. These tokens can be traded for special privileges and perks alongside other potential uses, thanks to its ERC-20 token nature. Twitter: Twitter Blue recently rolled out support for Ethereum NFTs, allowing users to display these tokens as their profile picture. The company has expressed intentions to build a decentralized version of Twitter in the future. Instagram: Instagram recently opened doors for Ethereum and Polygon-based NFTs. Users can directly post NFTs to Instagram by connecting their Ethereum wallet. A common thread among all these networks is their focus on refusing centralized control, enhancing privacy, and boosting interaction. But what does the future hold for these types of social networks? Let’s explore. The future of decentralized social networks The entire premise of a decentralized social network is built on the belief in a more democratic and accessible internet. As we continue to grapple with issues such as privacy violations, censorship, and data monopolies, blockchain technology offers a promising solution with its inherent characteristics of decentralization and security. Decentralized social networks can be considered an evolution in the sphere of social media as they promise to address many of the problems plaguing mainstream platforms. They prioritize user control and privacy, facilitating a sense of community that vastly transcends basic socializing and connectivity to create value. In the future, decentralized social networks may become the new norm, ruling out the limitations of conventional platforms entirely. They may well become spaces where people will be able to freely express their ideas, own their digital assets, and earn income from their content, defining a new age of social interaction and decentralization. Such networks are also likely to bolster the integration of newer technologies like Virtual Reality (VR) and Augmented Reality (AR) to create a more immersive user experience. Furthermore, as decentralization gains a more important place in society, a socio-economic transformation catalyzed by blockchain-based networks is very much on the horizon. Bringing it all together Decentralized social networks present a transformative model for social interaction, a far cry from the shortcomings of their centralized counterparts. They offer a high degree of control, privacy, and freedom, allowing for self-expression without the constraints that traditional platforms often impose. These networks provide a fertile ground for community-driven growth, innovation, and shared economic success. Instead of entrusting control to a small group of people, decentralization seeks to distribute control among all participants, creating a social environment that prioritizes everyone’s contributions. As we navigate the discontinuities of the digital age, decentralized social networks will only grow in importance, slowly but steadily changing the face of social media. They represent a forward-thinking approach to digital communication, taking us a step closer to a more democratic, inclusive, and user-controlled internet landscape. The future of social networking lies in blockchain-based platforms where users aren’t sidelined but placed at the forefront of their digital experience. This vision of a more egalitarian social network isn’t far-off; it’s being built—and used—today. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain technology for open banking Photo by Anthony DELANOIX on Unsplash What is open banking? Open banking is a system that provides 3rd parties (e.g. FinTech, BioTech, LegalTech companies) access to data from a number of financial institutions via application programming interfaces (APIs). In Europe, open banking has been legislated through the implementation of the Payment Services Directive (PSD2) which came into effect 13 January 2018. The Directive’s purpose is to increase pan-European competition and participation in the payments industry from non-banks and innovative online and mobile payment service providers. Open Banking APIs in this article are considered free and commercial (pay-per-use), where open refers to the technology (open source tools and paradigms). There are various Open Banking standards globally (e.g. The Open Bank Project) that support the PSD2 directive, where developers have access to APIs, sandbox environments with mock-up data to sample, and documentation to aid development. The UK has also taken the lead in open banking initiatives in producing an open banking framework that can enable the open banking standard in the UK. API aggregators such as TrueLayer and Yodlee offer startups, online lenders, personal finance apps, accounting applications software, and crowdfunding platforms access to data from various financial institutions via secure APIs. Previously, the only option for many of these companies to get access to customer data from Financial Institutions (FIs) was to ask their clients for certified printouts from these institutions or to ask their clients to hand over their login credentials (generally frowned upon and in violation of many FIs terms and conditions) so that the 3rd party could retrieve client data by using bots and screen scraping tools. Benefits Open Banking APIs can be consumed by service providers to support a number of ecosystems, each with their own benefits.   Open Banking models, derived from Aite Group publication A financial institution can offer open banking APIs to their own channel developers, which may result in greater agility and a faster pace of development. These open banking APIs can be consumed by 3rd party solution providers that bundle the FI’s services with other 3rd party offerings to create unique and compelling value propositions. Examples in the fintech space are financial product comparison apps, personal finance management apps, and robo-advisory apps. Aggregators also exist offering a platform with generic APIs for a number of FIs and third parties making it easier for solution developers to create bundled value propositions. Concerns However, there are a number of concerns that Open Banking presents, particularly with regards to: What customer data 3rd parties have access to Who they share that data with How secure that data is from theft and misuse The large number of integration points required for a single 3rd party to integrate with multiple FIs Spoofing and phishing (fake app/site prompting a user to hand over their login details) Customers have many reasons to be wary of open banking. In the UK, third party service providers must be registered by the UK’s Financial Conduct Authority which aims to prevent fraudulent non-secure third parties requesting data from FIs. This has resulted in zero UK third parties leveraging open banking APIs as of 31 October 2018, as the journey that FIs require their customers to register with a third party is laborious. Open banking is meant to benefit customers, but an easy and seamless customer experience has been neglected in the implementation by FIs offering Open Banking APIs. Incumbent banks can respond to regulations such as PSD2 hesitantly or with open arms. Each option presents itself as a different set of challenges or opportunities.   Image: Payment Services PSD2 in practice from Deloitte See Alessandro Hatami’s article, where he further elaborates on the risks and opportunities that various types of service providers may consider when considering working together. Leveraging Blockchain for Open Banking A permissioned blockchain network could be introduced to the Open Banking ecosystem to address some of the concerns and introduce additional opportunities. Introducing a Permissioned Blockchain Network and SSID into the Open Banking ecosystem To address customer data privacy and third party usage concerns, a customer could utilize a self-sovereign identity solution where they directly control which third parties have access to their data at a granular level. An existing FI could authenticate the identity of the customer based on previous information the customer provided the FI. E.g. An FI exposes identity management API to an SSID system. A customer submits their login credentials to a FI’s API (via the SSID system). The FI issues a token to the SSID system. The customer chooses third party services that they would like. Open Banking as a Permissioned Consortium Using the operating model of the UK’s Open Banking Ecosystem as a reference (which includes all elements that facilitate the operation of Open Banking e.g. API Standards, governance, systems, processes, security, and procedures) the administration and operation of Open Banking ecosystem on a permissioned blockchain platform appears highly viable. On-chain (tech-enabled), all transactions between members are recorded on an immutable, shared, distributed ledger where activities between specific providers are only visible between permissioned parties (e.g. a regulator). Within this trustless environment, all participants can benefit from innovative capabilities built on a low-cost, high-speed platform where privacy requirements of all participants are maintained and no central intermediary is necessary. Off-chain (institutionally enacted) consortium processes are typically governed against a constitution and legal jurisdictions e.g. which members of a consortium can add/blacklist other members, submit proposals, vote on the standards to adopt, rules to change, and on various types of disputes. These off-chain processes can soon be effectively executed on-chain and with chosen degrees of transparency. With the upcoming introduction of innovative Governance-as-a-Service (GaaS) capabilities on enterprise Blockchain-as-a-Service (BaaS) control panels like Chainstack, weighty aspects such as governance and consortium management can be reduced to a few clicks. Realizing the Opportunity Currently, various building blocks such as permissioned blockchain networks, Open Banking APIs, API aggregation platforms, Open Banking API and OAuth standards, SSID solutions, and BaaS platforms exist at various levels of maturity. Customers expect better data security, more control of their identity, and simple solutions that add value to their lives. Service providers have to adhere to multiple compliance requirements while trying to remain competitive, profitable and protect their own interests. Will Open Banking take off and converge with permissioned blockchain capabilities? Initiatives around multiple private consortia in the banking industry are already underway. It’s just a matter of time until we hear of initiatives around the first open banking blockchain consortium. References and Resources Mastering Open Banking: How the ‘Masters in Openness’ create value, by Mounaim Cortet, Art Stevens The Programmable Bank: How Banks Can Deploy and Monetize Open APIs by By Ron van Wezel from Aite Group FinTech Partnerships — The Shape of Things to Come by Alessandro Hatami What does open banking mean for cyber security? by “Retired Member” on Finextra What is open banking and what does it mean for South Africa? by bbd Will privacy concerns undermine open banking? by Ciaran Dynes of Talend Open banking is coming, but it’s taking its time by Ian Fraser Αnticipating the challenges and opportunities of PSD2 by Deloitte Open banking: implications and risks by Sasidharan Chandran Open Banking — a complete failure? by Chris Skinner Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchain transactions in Ethereum mempool – Coding edition  Welcome. This is part two of the “developer’s guide to the transactions in mempool” series.  The way of the mask.The way of the code. <– You are here. In the previous article, we discussed some of the reasons for transaction confirmation delays in blockchain networks. With the help of the MetaMask wallet, we tried to understand the causes of these delays from a high-level user perspective.  This article looks at the same situations from a more in-depth viewpoint. Here, we will be using the web3.py library to guide us through pending transactions, nonce gaps, transaction replacements, etc. Just like the previous article, this one will also be focusing on the Ethereum network. Thus, most of the technical aspects discussed in the article apply to Ethereum-based protocols. Under the hood  So, you might know that you need access to a blockchain node in order to interact with a blockchain network. Given enough technical expertise, you can set up your own physical node and establish a connection with a network. Still, even then, the entire process of setting up a node and maintaining it on your own can be quite daunting, to say the least. Therefore, most of the developers use services like Chainstack to help them build, manage, and maintain the required blockchain infrastructure, while they focus on other important stuff like application development.  Right, so let us say that our developer has deployed an Ethereum node, and they have an application in mind. Now, how do they make the application communicate with the node?  Well, theoretically, an Ethereum node is any computational device that can interact with the Ethereum network. Based on the differences in network interaction, data synchronization and storage, these nodes are divided into 3 major types: archive nodes, full nodes, and light nodes. (You can refer to this article for an in-depth explanation of each of these types.) Despite the functional differences, all nodes are capable of network interaction. This general functionality is facilitated by a piece of software that runs inside the nodes, called the Ethereum client. The Ethereum client is an implementation of the Ethereum protocol’s technical specifications. As we saw in the previous article, people have developed different clients using different programming languages. All these client implementations are based on the Ethereum yellow paper.  The Ethereum client helps the node access data from the Ethereum blockchain, verify all transactions in each block, establish peer-to-peer (p2p) communication with other clients (running in separate nodes) and maintain the security and accuracy of the data in the network. One can say that the client makes the node “Ethereum-ready.” Why the “Ethereum client” detour? Well, technically, the client is the part of the node that the application communicates with in order to interact with the network. Despite the differences in implementation, all the clients offer a uniform set of JSON-encoded remote procedure call (RPC) commands (based on the JSON-RPC specification) and an application program interface (commonly known as JSON-RPC API) that allows programs and applications to interact with the network via the client.  Developers can interact with the RPC interface using basic HTTP requests. The HTTP interaction, however, would require you to write a lot of code in order to deal with the different RPC commands. That’s no fun.  The other option is to use specialized libraries that take care of all requesting and processing of the commands and allow the developer to interact with the Ethereum network using some cleverly named functions. These libraries are called the web3 libraries. They are available in multiple languages like Python (web3.py), JavaScript/Typescript (web3.js, ether.js), PHP (web3.php), etc. Though there might be slight differences in the approach, all these libraries provide a simple interface that helps the developers interact with the Ethereum nodes and, by extension, the Ethereum network.  In this article, we will be using the Python-based web3 library, web3.py, to interact with our Ethereum nodes. The way of the code  All right, we are no longer going to rely on fancy UIs and flashy warnings. We are going to use the way of the code to guide ourselves through the mempool.  Before we get started with the code, here is what I want you to do: Make sure you have Python (version ^3.6) installed on your system.Install the corresponding version of the Python package manager (pip).Get yourself a nice code editor (I would recommend Visual Studio Code).Copy and save the account addresses from MetaMask.Make sure that these accounts have some (test) tokens in them. (You can get test tokens from these faucets). Great, that takes care of the coding requirements, but in order to interact with the Ethereum network, we also need an Ethereum node, so, get yourself a node by: Heading over to Chainstack and setting up an account.Deploy a node with Chainstack. Note: Since we are working on the Ethereum network, any Ethereum testnet node will be fine. This article, for instance, uses a Ropsten node. Now that you have the nodeL Get the RPC endpoints (HTTP) of the node. Before we start using the web3 library, we can try and invoke some of the Ethereum RPC commands using HTTP.  To do that: Install cURL  Note: cURL (client URL) is a command-line tool that helps you transfer data to and from servers, using protocols like HTTP/HTTPS  After installing cURL, open the terminal and type the following command: curl -X POST -H "Content-Type: application/JSON" --data \ '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ <https://chainstack-node-endpoint> This will invoke the eth_blockNumber method and return the latest block number (as hexadecimal). This is how you invoke the RPC commands using cURL and HTTP.  Now, let us try and do the same thing using the web3.py library: Open a terminal and use pip to install web3.py  $ pip install web3==5.29.2 #Replace the version number with the latest one Once you install python web3: Open your code editor > create a new python file > add the following code: #imports the Web3 class from web3 module from web3 import Web3 #store the node endpoint value CHAINSTACK_NODE_ENDPOINT = '<https://chainstack-node-endpoint>' #connect to your remote chainstack node w3 = Web3(Web3.HTTPProvider(CHAINSTACK_NODE_ENDPOINT)) #check if the node is connected print(w3.isConnected()) #returns true, if connected The code will establish a connection with your remote Chainstack node. To get the latest block number, add the following lines to the above code: #get the latest block number latestBlockNumber = w3.eth.block_number print(f"Latest Block Number : {latestBlockNumber}") And with that, we have successfully established a connection with a node and retrieved the latest block number using the web3.py library. Now, let’s see what else we can do with the library. Setting the gas fee price  As we discussed in the previous article, one of the most common ways of getting your transaction stuck in the mempool involves paying a “less than reasonable” transaction fee. In MetaMask, we are given the transaction (gas) fee estimates based on the previous block’s gas information. We rely on these estimates to set the fee for our transactions.  Now that we are using the web3.py library, how do we get similar estimates, so that we won’t end up paying a low fee?  Generally, the transaction fee is calculated using the following formula,  Fee = unit of gas used * (base fee + priority fee)  Here, the base fee represents an algorithmically determined fee that the user must pay for the inclusion of a transaction in a block. This amount is determined by the network, and it can fluctuate according to the network congestion. The priority fee is the amount that you are willing to pay the node responsible for the validation and verification of your transaction (miners/validators, in Ethereum).  In MetaMask, the users are provided with different transaction fee estimates based on different user priorities (high, medium, low) and the user is free to choose any of these prices based on their preference. This helps the user from both underspending and overspending on a transaction.  According to some of the MetaMask code, they use the following logic in order to generate these different estimates: Get the details of the 5 most recent blocks.Get the base fee of the latest block.Adjust the base fee according to the high, medium, or low user priority.From each block, collect the priority fee for transactions at the 10th, 20th, and 30th percentiles. Note: Here, percentiles represent the contribution level of the transaction to the overall gas used by the block, higher percentile = higher fees  Sort the priority fees according to the percentile and get the medians of each of the sorted list of priority fees.Adjust the medians according to the high, medium, or low user priority.Get the gas estimates of your transaction.Calculate the fee using the following formula,  fee = (gas estimates) * (adjustedBaseFee + adjustedPriorityFeeMedian)  Here, the value adjustments are made according to the user priority. The adjustments either increase or decrease the values, i.e., the base fee is adjusted by increasing the latest base fee value by 10%, 20%, and 25% with respect to the low, medium, and high user priority. Similarly, the priority fee medians are adjusted by decreasing the value by 6%, 3%, and 2% based on the low, medium, and high priority. The adjustments in value result in different fee estimates for each of the priorities.  Now that we know the logic, let us try and implement it using our web3 library.  In web3.py, we have a neat little function called eth.fee_history  that helps us retrieve block information, percentile-based priority fee values, etc. We can use this function to generate transaction fee estimates like that of MetaMask.  To implement this:  Import the necessary libraries: #import Web3 class from web3 module from web3 import Web3 #import the in-built statistics module import statistics # for median calculation Declare all the necessary values and variables: # Setting node endpoint value CHAINSTACK_NODE_ENDPOINT = '<NODE_ENDPOINT>' # Setting account addresses # you can copy the account addresses from metamask] FROM_ACCOUNT = "<FROM_ACCOUNT_ADDRESS>" TO_ACCOUNT = "<TO_ACCOUNT_ADDRESS>" # setting the values for gas fee estimation. # The values are based on the metamask code # Setting the percentage multiplier for the basefee # The base fee is adjusted by INCREASING the value, # thus the percentage multiplier is calculated using the formula # PERCENTAGE MULTIPLIER = 1 + percentage value , # 10 % increase means, PERCENTAGE MULTIPLIER = 1 + (10/100) # the multipliers are chosen according to the priority [low , medium , high] BASEFEE_PERCENTAGE_MULTIPLIER = { "low": 1.10, # 10% increase "medium": 1.20, # 20% increase "high": 1.25 # 25% increase } # Setting the percentage multiplier for the priority fee # priority fee median is adjusted by DECREASING the value, # the percentage multiplier is calculated using the formula # PERCENTAGE MULTIPLIER = 1 - percentage value, # 6 % decrease means, PERCENTAGE MULTIPLIER = 1 - (6/100) # the multipliers are chosen according to the priority [low , medium , high] PRIORITY_FEE_PERCENTAGE_MULTIPLIER = { "low": .94, # 6% decrease "medium": .97, # 3% decrease "high": .98 # 2% decrease } # the minimum PRIORITY FEE that should be payed, # corresponding to the user priority (in WEI denomination) MINIMUM_FEE = { "low": 1000000000, "medium": 1500000000, "high": 2000000000 } # a dictionary for storing the sorted priority fee feeByPriority = { "low": [], "medium": [], "high": [] } Connect to your Chainstack node: w3 = Web3(Web3.HTTPProvider(CHAINSTACK_NODE_ENDPOINT)) Get the priority fee, base fee, etc using the eth.fee_history function:  # parameters : # Number of blocks - 5 # newest block in the provided range - # latest [or you can give the latest block number] # reward_percentiles - 10,20,30 [ based on metamask] feeHistory = w3.eth.fee_history(5, 'latest', [10, 20, 30]) Get the base fee of the latest block: latestBaseFeePerGas = feeHistory["baseFeePerGas"][-1] #the last one in the list Set the ETH value to be transferred and calculate the estimated gas usage: # Setting the ether value to be transferred ETH_VALUE = .5 # Calculating the estimated usage of gas in the following transaction estimateGasUsed = w3.eth.estimateGas( {'to': TO_ACCOUNT, 'from': FROM_ACCOUNT, 'value': w3.toWei(ETH_VALUE, "ether")}) Sort the priority gas fees: # The reward parameter in feeHistory variable contains an array of arrays. # each of the inner arrays has priority gas values, # corresponding to the given percentiles [10,20,30] # the number of inner arrays = # the number of blocks that we gave as the parameter[5] # here we take each of the inner arrays and # sort the values in the arrays as low, medium or high, # based on the array index for feeList in feeHistory["reward"]: # 10 percentile values - low fees feeByPriority["low"].append(feeList[0]) # 20 percentile value - medium fees feeByPriority["medium"].append(feeList[1]) # 30 percentile value - high fees feeByPriority["high"].append(feeList[2]) Adjust the values and perform the calculations: # Take each of the sorted arrays in the feeByPriority dictionary and # calculate the gas estimate, based on the priority level # that is given as the key in the feeByPriority dictionary for key in feeByPriority: # adjust the basefee, # use the multiplier value corresponding to the key adjustedBaseFee = latestBaseFeePerGas * BASEFEE_PERCENTAGE_MULTIPLIER[key] # get the median of the priority fee based on the key medianOfFeeList = statistics.median(feeByPriority[key]) # adjust the median value, # use the multiplier value corresponding to the key adjustedFeeMedian = ( medianOfFeeList * PRIORITY_FEE_PERCENTAGE_MULTIPLIER[key]) # if the adjustedFeeMedian falls below the MINIMUM_FEE, # use the MINIMUM_FEE value, adjustedFeeMedian = adjustedFeeMedian if adjustedFeeMedian > MINIMUM_FEE[key] else MINIMUM_FEE[key] suggestedMaxPriorityFeePerGasGwei = w3.fromWei(adjustedFeeMedian, "gwei") # [optional] round the amount suggestedMaxPriorityFeePerGasGwei = round( suggestedMaxPriorityFeePerGasGwei, 5) # calculate the Max fee per gas suggestedMaxFeePerGas = (adjustedBaseFee + adjustedFeeMedian) # convert to gwei denomination suggestedMaxFeePerGasGwei = w3.fromWei(suggestedMaxFeePerGas, "gwei") # [optional] round the amount to the given decimal precision suggestedMaxFeePerGasGwei = round(suggestedMaxFeePerGasGwei, 9) # calculate the total gas fee totalGasFee = suggestedMaxFeePerGasGwei*estimateGasUsed # convert the value to gwei denomination totalGasFeeGwei = w3.fromWei(totalGasFee, "gwei") # [optional] round the amount totalGasFeeGwei = round(totalGasFeeGwei, 8) print(f""" PRIORITY: {key.upper()}\n MAX PRIORITY FEE (GWEI): {suggestedMaxPriorityFeePerGasGwei}\n MAX FEE (GWEI) : {suggestedMaxFeePerGasGwei}\n GAS PRICE (ETH): {totalGasFeeGwei} """) print("="*80) # guess what this does ? Note: here is the complete code for reference: gas fee estimation. OK, now, once you run the whole code, your result will look something like this, Tip: instead of displaying the gas fee estimates, you can modify the code and return the gas estimates.  Note that during times of high network traffic, there might be some difference between our estimates and that of MetaMask. You can, however, use these estimates for sending a transaction, as they fall within the “reasonable fee” range.  How to send a transaction?  Now that we have the gas estimates, let us use them to send a transaction: To send a transaction: Create a new Python file and import the web3.py library.Copy and store the MetaMask account addresses.Use the Chainstack node endpoint and establish a connection with the node. (I trust, by now, you are familiar with this part of the code!)  In addition to the addresses and the endpoint, we would also require the sender’s private key to sign the transaction. Under normal circumstances, you should never reveal the private key of your account. Even during development, explicitly stating the private key within your code is frowned upon! The right way to access your private key, during the development phase, would be to set it as an environment variable (you can use a .env file) and access those variables from within the code (the same procedure should also be used with the account addresses, as an added measure). But since this article is all about explaining the code, we will skip these measures for now.  You can get your account’s private key from MetaMask:  Once you have the private key, store it in your code.  By now, your code will look something like this: # import Web3 class from web3 module from web3 import Web3 # Setting node endpoint value CHAINSTACK_NODE_ENDPOINT = '<https://chainstack-node-endpoint>' # Setting account addresses # you can copy the account addresses from MetaMask FROM_ACCOUNT = "<FROM_ACCOUNT_ADDRESS>" TO_ACCOUNT = "<TO_ACCOUNT_ADDRESS>" # Setting the user private key SENDER_PRIVATEKEY = "<SENDER_PRIVATE_KEY>" # Connect to the node w3 = Web3(Web3.HTTPProvider(CHAINSTACK_NODE_ENDPOINT)) Now, to conduct the transaction, you also need some additional information like: chain ID, account nonce, the maximum fee per gas,the maximum priority fees,the ETH value that you wish to send.  You can get the fee details by running our gas estimation script, the ETH value can be any random number that the user chooses (do keep your MetaMask account balance in mind!). You can use the following code to get the chain ID and account nonce: # Setting the transaction variables # get the MAX_PRIORITY_FEE and MAX_FEE_PER_GAS values # by running the gas estimation script. # you can choose your preferred priority [low, medium, high] # and copy the corresponding values MAX_PRIORITY_FEE = 0 MAX_FEE_PER_GAS = 0 # Setting the ETH value that you wish to send ETH_VALUE = 0.05 # Getting the account-nonce value ACCOUNT_NONCE = w3.eth.getTransactionCount(FROM_ACCOUNT) # Setting the value for chainID CHAIN_ID = w3.eth.chain_id Now that we have all the values, let us create a transaction out of them. # While sending the transaction, # we must represent all the fee related values and # the ETH value in wei denomination. transaction = { 'nonce': ACCOUNT_NONCE, 'to': TO_ACCOUNT, # reciever's address 'value': w3.toWei(ETH_VALUE, "ether"), # maximum gas that can be used for the transaction execution 'gas': 210000, 'maxFeePerGas': w3.toWei(MAX_FEE_PER_GAS, 'gwei'), 'maxPriorityFeePerGas': w3.toWei(MAX_PRIORITY_FEE, 'gwei'), 'chainId': CHAIN_ID } Once you build the transaction, you can sign it using the sender’s private key and then send it using the following code: # signing the transaction using the sender's private key signedTransaction = w3.eth.account.sign_transaction( transaction, SENDER_PRIVATEKEY) # sending the signed transaction, # this will return the transaction hash in byte encoded format transactionHash = w3.eth.send_raw_transaction( signedTransaction.rawTransaction) # converting the byte-encoded transaction hash to hex string transactionHashHex = w3.toHex(transactionHash) print(transactionHashHex) Note: here is the complete code for reference: send transaction. You can use the web3.eth.wait_for_transaction_receipt function to confirm the inclusion of the transaction in a block. The function works by waiting for the specified transaction to be included in a block and once it gets added, the function returns the transaction receipt.  # waits till the transaction becomes a part of the block transactionReceipt = w3.eth.wait_for_transaction_receipt(transactionHashHex) print(f"Transaction Receipt : {transactionReceipt}") While running the code, the function will make the execution thread wait (sleep) until the transaction receipt is received. You can control the wait time by adding the timeout parameter to the function. This will make the function wait for the given number of seconds, before returning a TimeExhausted exception.  # waits 60 seconds for the receipt transactionReceipt = w3.eth.wait_for_transaction_receipt(transactionHashHex, 60) How to fix a stuck pending transaction? So far, we have looked at the priority-based gas fee estimations and transaction generation. Now, we need to figure out a way to get our transactions out of the mempool in case they get stuck. To help with the pending transactions, the first order of business would be to get the details of such transactions. In MetaMask, we were provided with tags that indicated whether a transaction is pending or confirmed (successful).  Of course, with web3.py, we have a more technical approach. Using the library, we can get the list of pending transactions, directly from the node (and its mempool). To do this, we can use something called the filter.  The basic purpose of a filter is to inform us of certain events that take place in the Ethereum network. The developers can leverage this feature and create specialized filters that inform us of events like the addition of a new pending transaction, new block creation, etc. You can use the following code to set up a filter that gets you the details of new pending transactions.  # setting a new filter that looks for new pending transaction pendingTransactionFilter = w3.eth.filter('pending') # check for new entries and return the transaction hash pendingTransactionList = pendingTransactionFilter.get_new_entries() print(pendingTransactionList) The get_new_entry function returns a list of transaction hashes in the byte encoded format. You can convert the byte encoded transaction hash into the corresponding hex value and use it to retrieve the pending transaction details. The function will return an empty list if there are no new entries (changes) since the last poll.  pendingTransactionDetail = w3.eth.get_transaction('<Pending_Transaction_Hash_Hex>') Once you have the details, you can use them to determine the cause of the delay. You can use our gas estimation script to check if we are using a low fee. You can also retrieve the nonce value of the transaction and see if there is a gap.  The following code demonstrates a nonce gap check: currentAccountNonce = w3.eth.getTransactionCount('<Account-Address') pendingTransactionDetail = w3.eth.get_transaction('<Pending_Transaction_Hash_Hex>') pendingTransactionNonce = pendingTransactionDetail['nonce'] #getting the nonce value # get the sender's address pendingTransactionSender = pendingTransactionDetail['from'] # check if the transaction has a higher nonce value if(pendingTransactionSender == '<Account-Address>' and currentAccountNonce < pendingTransactionNonce): print("Nonce Gap Detected !") Note: while looking for nonce gaps, know that, due to network traffic or broadcasting delays, transactions can take time to reach a particular node’s mempool, so make sure that you waited a reasonable amount of time (a couple of minutes) before trying to rescue a transaction. (Here is a little something that can help you test the speed of your node: speed-tester). OK, we have made sure that the transaction is stuck, and we saw how to look for the cause of it, so, now, how do we rescue the transaction?  Well, just like MetaMask, in order to “rescue” a pending transaction, you can either cancel it, speed it up or fill the nonce gap, if there is one.  Here’s how you can check for nonce gaps and “dynamically” fill them up by sending transactions carrying the previous account-nonce values. Get the pending transaction details and set the required values: # Getting the pending transaction details pendingTransactionDetail = w3.eth.get_transaction( '<Pending_Transaction_Hash_Hex>') # getting the current account nonce value currentAccountNonce = w3.eth.getTransactionCount("<FROM_ACCOUNT_ADDRESS>") # getting the nonce value pendingTransactionNonce = pendingTransactionDetail['nonce'] # get the sender's address pendingTransactionSender = pendingTransactionDetail['from'] Once you have the values, check for nonce gap > if yes, then reconstruct transaction > send transaction: # check if the transaction is from your account and # if it has a higher nonce value if(pendingTransactionSender == FROM_ACCOUNT and currentAccountNonce < pendingTransactionNonce): for nonce in range(currentAccountNonce, pendingTransactionNonce): # you can dynamically get the MAX_PRIORITY_FEE # and MAX_FEE_PER_GAS values by modifying gas_estimate.py script # to return the values corresponding to your priority MAX_PRIORITY_FEE = 0 MAX_FEE_PER_GAS = 0 transaction = { 'nonce': nonce, 'to': pendingTransactionDetail['to'], 'value': 0, # maximum gas that can be used for the transaction execution 'gas': pendingTransactionDetail['gas'], 'maxFeePerGas': w3.toWei(MAX_FEE_PER_GAS, 'gwei'), 'maxPriorityFeePerGas': w3.toWei(MAX_PRIORITY_FEE, 'gwei'), 'chainId': pendingTransactionDetail['chainId'] } # signing the transaction using the sender's private key signedTransaction = w3.eth.account.sign_transaction( transaction, SENDER_PRIVATEKEY) # sending the signed transaction, transactionHash = w3.eth.send_raw_transaction( signedTransaction.rawTransaction) transactionHashHex = w3.toHex(transactionHash) transactionReceipt = w3.eth.wait_for_transaction_receipt( transactionHashHex) print(transactionReceipt) Note: here is the complete code for reference: fill up the nonce gap. Now that the nonce gap is dealt with, we can try and help transactions with a lower gas fee. This would require us to send a separate transaction with the same nonce, higher gas fee and a zero or similar ETH value (based on whether you want to cancel the transaction or replace it). In the previous article, we talked about transaction replacement and how we need to increase our current gas fee by a certain percentage, in order to replace the pending transaction—remember the txpool.pricebump option in Geth client. In MetaMask, while trying to “speed up” a transaction, they recreate the transaction with a 10% increase in the MaxFeePerGas and MaxPriorityFee values. This increases the overall gas fee. For cancelling a transaction, they increase the values by 50%. But if we are dealing with an extremely low transaction fee, an increase in value (within the 10%-50% range) might still give us a “less than reasonable” fee. A solution to this would be to increase the values by the given percentage and then compare the values with the ones that are generated using our gas fee estimator script. You can then use the “more reasonable” values for sending the transaction. Here is how you can do it: Get the pending transaction details and set the required values: # get the pending transaction details using the hash value pendingTransactionDetail = w3.eth.get_transaction( '<Pending_Transaction_Hash_Hex>') # Set the Value for the percentage multipliers SPEEDUP_MULTIPLIER = 1.10 # 10 % increase CANCEL_MULTIPLIER = 1.5 # 50 % increase # you can obtain the values by running the gas estimation script # you can choose your preferred priority [ low,medium,high] # and copy the corresponding values maxPriorityFee = 0 maxFeePerGas = 0 # convert the estimated values to wei denomination maxPriorityFeeWei = w3.toWei(maxPriorityFee, 'gwei') maxFeePerGasWei = w3.toWei(maxFeePerGas, 'gwei') # generate the suggested MaxPriorityFee and # suggested MaxFeePerGas using the pendingtransationDetail # and the multipliers. # Here we are using the SPEEDUP_MULTIPLIER, # you can use the CANCEL_MULTIPLIER if you wish to cancel the transaction ## For rounding numbers,make sure you import the in-built "math" module suggestedMaxPriorityFee = math.ceil( pendingTransactionDetail['maxPriorityFeePerGas'] * SPEEDUP_MULTIPLIER) suggestedMaxFeePerGas = math.ceil( pendingTransactionDetail['maxFeePerGas'] * SPEEDUP_MULTIPLIER) # compare the values and choose the bigger one maxFeePerGas = suggestedMaxFeePerGas if suggestedMaxFeePerGas > maxFeePerGasWei else maxFeePerGasWei maxPriorityFee = suggestedMaxPriorityFee if suggestedMaxPriorityFee > maxPriorityFeeWei else maxPriorityFeeWei Reconstruct the transaction and send it: transaction = { 'nonce': pendingTransactionDetail['nonce'], 'to': pendingTransactionDetail['to'], # recever's address 'chainId': pendingTransactionDetail['chainId'], # 0 if you are canceling the transaction 'value': pendingTransactionDetail['value'], # maximum gas that can be used for the transaction execution 'gas': pendingTransactionDetail['gas'], 'maxFeePerGas': maxFeePerGas, 'maxPriorityFeePerGas': maxPriorityFee, } signedTransaction = w3.eth.account.sign_transaction( transaction, "<SENDER_PRIVATEKEY>") transactionHash = w3.eth.send_raw_transaction( signedTransaction.rawTransaction) transactionHashHex = w3.toHex(transactionHash) transactionReceipt = w3.eth.wait_for_transaction_receipt(transactionHashHex) print(transactionReceipt) Note: here is the complete code for reference: cancel or speed up transaction. And that takes care of the “low fee” conundrum. The circle is now complete  Over the course of these articles, we discussed some of the causes of transaction confirmation delays in blockchain networks. We were able to look at the causes of these delays and their solutions from different perspectives. The idea behind these articles is to help developers understand the inner workings of the transaction and its journey through the mempool.  If you have any queries or doubts regarding the things that we discussed, feel free to reach out to us!  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Blockchains: Here’s the proof of the pudding… By Laurent Dedenis Blockchain, that sneaky little thing. It tiptoed into our world through a mysterious cast, and today, it’s omnipresent. From conferences and boardrooms to academia, there is constant noise about this technology and its usefulness. But barring the hottest proof of its existence that is Bitcoin, the question remains: are companies actually using this technology, or is it vaporware? Let’s find out… Photo by Rod Long on Unsplash Supply chain and logistics The $16 trillion supply chain and logistics industry spans a complex ecosystem of corporations, intermediaries, and officials. When you find out that a single shipment of avocados from Mombasa to Rotterdam involves ‘30+ actors, 100+ people, and 200 information exchanges’, you cannot help but conclude that here is an industry that is in dire need of transformation. TradeLens, a joint venture between Maersk and IBM, aims to use blockchain to eliminate various barriers within the international supply chain such as time-consuming paper processes, duplication of information, errors in information exchange, and long-winded clearance processes. TradeLens, as of writing, is currently in beta and gradually approaching production scale processing a whopping 150 million events per day! Blockchains in the supply chain and logistics industry could be such a game changer that industry executives from all over the world have formed the Blockchain in Transport Alliance (BiTA). BiTA is carrying on the important task of blockchain standardization and education for the freight industry, and Chainstack is honored to be part of this forum of progressive supply chain professionals. Insurance Founded by EY and Guardtime, Insurwave is an enterprise consortium that brings together heavyweights such as Maersk, Microsoft, Willis Towers Watson, and XL Caitlin. The aim is to transform risk management in a notoriously siloed industry such as marine hull insurance by providing a single source of truth to all players in the value chain. On the consumer side, there’s Fizzy, a smart-contract powered app that’s making a small dent in the multi-trillion world of insurance. It covers the traveler for flight delay and indemnifies her almost instantly on such an event occurring. Fizzy takes the concept of parametric insurance to a whole new level of transparency allowing a third party (code in this case) to decide whether or not the insured party must be paid. Smart cities and IoT Waste management is an integral part of any city planning and costs millions of dollars. From collecting and managing to removing waste, waste management is a highly coordinated exercise that should be anything but wasteful. So how about combining two powerful technologies to address this growing problem? That’s exactly what Taipei City Government plans to do. No doubt still a PoC, it holds great promise for every city that aspires to be livable in the first place and, beyond that, smart. The solution comprises waste bins powered by sensors to record fill-levels of waste bins and recording data to IOTA (a tangle-based distributed ledger technology). This provides real-time visibility to all participants in the waste management ecosystem and facilitates automatic micropayments to service providers through smart contracts. Manufacturing Parts tracking and authenticity are major concerns across the manufacturing supply chain and cost companies billions of dollars in fraud, leakage, and information redundancy. Fortunately, there is a bunch of bold startups that is rising to the challenge. Chronicled, for instance, is combining AI, IoT, and Blockchain to address manufacturing supply chain inefficiencies. PartsPedigree is trying to tackle similar problems for aerospace and automotive. Tracking and authenticity are also major concerns in the pharma supply chain, and BlockPharma wants to make a difference by combining machine learning with blockchain. Finally, finance… MonetaGo, a New York-headquartered blockchain applications company, successfully implemented a blockchain platform in India to tackle fraud around accounts receivables financing. The accounts receivables financing industry already loans around USD 200 bn to small and medium-sized businesses, and there is a potential of another USD 188 bn if the issue of fraud is tackled. The blockchain provides a common platform with no single financial institution in control and provides participants, who are also competitors, transaction privacy. What happens when you are an investment advisory firm specializing in creating financial products, and the rug is pulled from under your feet? That’s what happened when Solidium Partners, a firm in catastrophe bonds, lost access to an intermediary clearinghouse. Solidium met this challenge by launching its $15 million catastrophe bond on a blockchain allowing participants to directly transact dollars and bond units. Since then, the firm has gone further and conducted an Insurance Linked Security trade on its blockchain without the use of a bank or broker-dealer and any fees. In summary… Admittedly, this is a whirlwind tour through the landscape of blockchain adoption. It does not do justice to the scores of cool projects being tested by corporations that are pushing the boundaries of their own business models. Nor can it document the ones that are silently active and making an impact. For what it’s worth, it’s my way of communicating that here is a piece of technology that’s compelling us to think in novel ways, and it’s slowly succeeding. Not a bad performance for something that sneaked into our world 10 years ago and is now changing corporate and individual mindsets globally. “Indeed, private blockchains should be considered for any situation in which two or more organizations need a shared view of reality, and that view does not originate from a single source. In these cases, blockchains offer an alternative to the need for a trusted intermediary, leading to significant savings in hassle and cost”. Dr. Gideon Greenspan Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### BNB Faucet – Claim Free BNB Smart Chain Testnet Tokens Introducing the BNB Smart Chain Testnet Faucet: Your Gateway to Testnet BNB. In the world of Web3 development, you will always need testnet tokens. Whether you’re experimenting with smart contracts, building decentralized applications, or refining your blockchain solutions, access to testnet tokens is necessary. We understand the challenges and frustrations that developers face when building DApps. That’s why we created the BNB Smart Chain Testnet Faucet, designed with Web3 developers like you in mind. Get Testnet BNB How to use the BNB faucet Once you’re registered and have an API key set up on the Chainstack platform, you can get up to 0.5 testnet BNB every 24 hours. Testnet BNB can be used to send transactions on the BNB Smart Chain testnet, deploy your smart contracts, and test their different functions before pushing them to mainnet, which involves real funds. For a step-by-step tutorial on how to request BNB from our BNB testnet faucet, watch the video demo below: Why do I need Mainnet ETH in order to request funds from the faucet? Our faucet requires you to hold 0.002 ETH in your wallet on the Ethereum Mainnet, in order to use it. This measure helps ensure a fair usage and prevents exploitation of the faucet. Why does it take so much time for my tokens to arrive? Usually, the process of receiving your tokens should be fast, but sometimes the network may be congested and you might need to wait a little while. If you do not get your tokens within 15 minutes, please contact us on Telegram or Discord. I get an error saying “The user can only receive funds every 24 hours.” In order to ensure an even distribution across the BNB Smart Chain developer community, we have capped the maximum amount of testnet BNB that you can request to a maximum of 0.5 per day. I get an error saying “Something went wrong. Check credentials and try again.” You might’ve entered an incorrect API key or wallet address. Please check them again, refresh the page, and try one more time. In order to generate your API key, you will need to sign-up via the Chainstack console first. Check out the video above to see how to generate your own API key and request testnet BNB from the faucet. If you are sure that the API key is valid, your wallet address is correct, and you still can not claim tokens, you can contact us on Telegram or Discord so we can assist you. Do you need help when using the faucet? You can contact us via Telegram or Discord and one of our team members will help you to get testnet tokens. Now that I have my funds, what shall I do next? Tell us about the DApp that you are building and tag our @ChainstackHQ X (Twitter) account in your post. We would like to learn more about your DApp. I want the best BNB Smart Chain nodes If you are looking for fast and reliable BNB nodes, you can sign-up on Chainstack and deploy one for free. We support over 20 different blockchains, and we also provide additional developer tooling. What is Chainstack? Chainstack is the limitless Web3 development stack for blockchain developers. Every protocol, every API, every tool that you’ll ever need to build any DApp at scale. Get Testnet BNB Where can I learn to build DApps? Our Web3 documentation is the perfect place to get you started. You will find everything you need in there from smart contract tutorials to APIs, and recipes. Let’s get you started with this quick glossary: What is a faucet? A faucet is a developer tool that gives you testnet tokens to use when testing your smart contracts or interacting with DApps on test networks. The Chainstack faucet gives you testnet BNB to test your smart contracts before deploying them to production. What is the BNB chain testnet? The BNB chain testnet is a test environment for BNB Smart Chain network, ran by the BNB Chain development community. Test networks are used for deploying smart contracts and testing their functions, ensuring that they work as expected, before pushing them to production. What is the meaning of drip? When it comes to Web3 faucets, the drip refers to the amount of testnet tokens that you can get from a faucet each day. In your case, that would be 0.5 testnet BNB daily. What are BNB Smart Chain testnet BNB tokens? A testnet BNB token is the gas fee token for the BNB Smart Chain testnet. Testnet tokens do not have real monetary value (these tokens are not like the “real” BNB), but they play an important role in covering gas costs. You will need them in order to deploy your smart contracts on the BNB testnet, and interact with those contracts through transactions. Do you want to ask us something else? Join our Telegram or Discord communities, so you can talk directly to our team members there. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### BonusTrade.AI: Unlocking real-time crypto market insights with Chainstack Chainstack infrastructure has enabled us to provide real-time trading insights with unparalleled accuracy. Their exceptional support and scalability have allowed us to grow our platform rapidly while maintaining a seamless user experience. The BonusTrade.AI team The importance of live data in cryptocurrency trading cannot be overstated. Having access to real-time trades can be a decisive factor in capturing profitable opportunities or missing them. However, the challenge lies in monitoring these transactions and interpreting the data for strategic decision-making. That is why, at Chainstack, we tailored our platform to be a potent tool that companies like BonusTrade.AI could use to do just that with ease. BonusTrade.AI is a crypto wallet tracking trailblazer, delivering insights accessible to both beginners and experts alike. Leveraging our robust managed blockchain services, BonusTrade.AI offers live trade tracking, unified wallet tracking, key visual insights, personalized alerts, and organized tracking like never before. And it has certainly been an exciting journey to support this innovative platform with resilient infrastructure on their way to the top. Let’s explore! What is BonusTrade.AI? BonusTrade.AI is a unique digital platform developed with a clear purpose—to empower both crypto trading enthusiasts and seasoned experts. By providing unparalleled access to live trading data, it makes a pivotal difference in the way users make their trading strategic decisions. But what sets BonusTrade.AI apart from other crypto wallet trackers is its innovative approach to data interpretation. Using strong infrastructural support from Chainstack, BonusTrade.AI offers features such as live trade tracking, unified wallet tracking, key visual insights, personalized alerts, and organized tracking—all in a user-friendly manner. The platform demonstrates its commitment to delivering a seamless experience by providing a streamlined view of tracked wallets and the live trades happening across the globe. This convenient and organized tracking system, coupled with personalized alerts for any wallet or token trade, helps users stay on top of their game. At the core of BonusTrade.AI’s offerings is the powerful application of artificial intelligence in tracking and ranking crypto wallet performance. The platform’s AI Score, a critical metric produced by deep learning models, offers a comprehensive view of a wallet’s trade performance and related on-chain data. BonusTrade.AI also boasts organized tracking capabilities, allowing users to sort and categorize their followed wallets into tailored folders. This personalized approach to tracking ensures that users can keep tabs on their preferred crypto signals in a way that best fits their trading style. But BonusTrade.AI could not offer such superior tracking and insights without the support of powerful node infrastructure—an element central to its operations and efficiency—and we at Chainstack were happy to answer the call. BonusTrade.AI’s innovative approach to crypto wallet tracking, combined with our robust infrastructure, has created a powerful platform that delivers real-time trading insights with exceptional accuracy and reliability. It’s been incredibly rewarding to support BonusTrade.AI’s mission and witness their growth. Eugene Aseev, CTO & Co-Founder, Chainstack How BonusTrade.AI started with Chainstack When BonusTrade.AI set out on its mission to create an unrivaled crypto wallet tracking platform, it faced a challenge familiar to many in the world of Web3 technologies—how to ensure reliable, real-time data from multiple blockchain networks simultaneously without compromising performance or scalability. BonusTrade.AI was facing several challenges at this early stage, common for many growing platforms. They required a reliable partner who could ensure consistent uptime, manage high volumes of data across diverse networks, and provide swift technical support. Luckily, as developers ourselves, we understood this and were thrilled at the prospect of contributing to BonusTrade.AI’s vision of providing accurate crypto tracking seamlessly in real-time. Chainstack was built precisely to assist ambitious projects like BonusTrade.AI, so we made sure the team had the support it needed to navigate any rough waters. Our team worked closely with them, providing prompt and effective technical assistance whenever necessary, ultimately helping them become a leading name in the crypto wallet tracking space. BonusTrade.AI on Chainstack in numbers Working alongside BonusTrade.AI, we have the privilege of managing 7 active Global Nodes for them, while the diversity of protocols utilized underpins the scope and scale of our collaborative efforts. From Arbitrum, Avalanche, and Base to BNB Smart Chain, Ethereum, Optimism, and Polygon, we’ve successfully handled 40.2M requests for BonusTrade.AI via Chainstack Global Nodes. And given the intensity of crypto markets, reliably handling such a volume of data is no small feat—an achievement that mirrors our commitment to delivering reliable, future-focused solutions for Web3 developers. Meanwhile, the distribution of protocol requests—5.9M for Arbitrum, 5.5M for Avalanche, 5.3M for Base, 6.5M for BNB Smart Chain, 6.8M for Optimism, 3.5M for Ethereum, and 3.3M for Polygon—illuminates how we’ve supported the company’s broad-spectrum operations. Figure 1: BonusTrade.AI full node RU allocation Each of these numbers represents a moment of engagement, a moment of informed decision-making, and, in many cases, moments of successful trades. Behind the stats, we’re proud to be part of each user’s journey, delivering the information needed to stay ahead in a dynamic market. That’s the true significance of BonusTrade.AI and Chainstack in numbers. Bringing it all together The future of trading lies in having the most accurate, comprehensive data at your fingertips, and understanding how to use it effectively. This future is already here, powered by companies like BonusTrade.AI and reliable blockchain infrastructure providers like ourselves at Chainstack. BonusTrade.AI, with its advanced AI-driven algorithms and comprehensive crypto tracking capabilities, delivers a seamless and reliable trading experience to its users, from seasoned professionals to those new to the world of crypto. And under the hood, it is Chainstack nodes that make this vision a reality. Our partnership with BonusTrade.AI shows how blockchain and AI can come together to offer a fresh new take on crypto trading—faster, better, stronger. We’re excited to see where these advances in technology will lead us next, as we provide more pioneers with the tools they need to do what they do best—paving the way to a decentralized future, one block at a time. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Brave new adventures in AI+Web3 with Eldarune and Chainstack  Resolving cross-chain woes for a seamless online gameplay Eldarune is taking Web3 gaming to new heights with AI  Eldarune is an ambitious RPG and arena game that immerses players in a Medieval fantasy world. With stunning high-resolution 4K graphics and play-to-earn game mechanics, this title brings another layer of realism to AI+Web3 gaming. It leverages the features of the blockchain for its own in-game token and to store all game assets as Non Fungible Tokens (NFT) on-chain.  Figure 1: Eldarune splash screen Pushing the boundaries of Web3 gaming, Eldarune introduces a game experience tailored to experienced gamers, as it combines sophisticated gameplay elements with an innovative use of NFT technology. In working to build a robust and sustainable in-game economy, Eldarune has created its native token ELDA for players to conduct transactions with each other. Players can earn ELDA by completing various quests and challenges in what is called a play-to-earn model of gaming.  Eldarune – Calm Before the Storm Figure 2: Eldarune promo video The team at Eldarune has sought out to create a complete package of a game, with top-tier gameplay and a storyline created to immerse players. The game features a multitude of levels, dungeons, and game bosses to defeat in order to earn in-game assets. There are additional player-vs-player battles to further test your gaming skills.  Combined with the power of the blockchain, Eldarune is not only raising the bar in gaming but they are also poised to bring an influx of new players into Web3 gaming. As the Eldarune team is successfully running its testnet stages as of this writing, they anticipate 10k unique players within the first six months of the full release. Medieval fantasy RPG meets Web3 and NFTs  While the play-to-earn model is common in GameFi, what really makes Eldarune unique is their team’s vision for gaming as it continues to gain momentum in Web3. Despite recent advances in game technology, there is still a long way to go before popular titles reach their full potential. Eldarune recognizes this and sets out to do just that—push AI+Web3 gaming to its potential. Figure 3: Eldarune combat in-game snapshot Eldarune’s focus on retention and engagement with their players has been a common practice in Web2 gaming, along with in-game currencies and virtual goods. Now with a transition to Web3, this has led the way to an exciting AI+Web3 ecosystem for players to create and generate value with their gaming achievements as they become NFTs. Here, the players have complete ownership of their in-game assets and achievements, where they can upgrade their NFTs and rent them out to other players for certain missions. Figure 4: Eldarune token economics; Source Eldarune  Now, just like traditional GameFi there’s the finance part. Eldarune offers active earning opportunities via PvP battles, campaigns, competitions, token drops, and NFT rewards. There are also passive earning options with staking ELDA, NFT lending, farming, and liquidity provision. All of this keeps players invested for the long term, which provides a sustainable economy within a virtual world but with real-world value.  Eldarune offers an unparalleled gaming experience, combining four unique and engaging game modes, real player-to-environment mechanics, massive NFT utility for characters, items, and upgrades—all within a fair play gaming environment.  Tackling multichain performance woes Eldarune is a multichain project, therefore the ability to create nodes for any blockchain must be a quick and intuitive process. Also, a game of this magnitude needs to operate smoothly for its players to be satisfied with the gaming experience. This means that any rate limits or bottlenecking needs to be resolved before that can happen. Even with a highly experienced team of developers at the helm, Eldarune needed a fast and reliable infrastructure to build their opus on.  Eldarune had previously tried other node provider services but were not getting what they needed. With their team’s background in defense and telecom, they made the matters of security and speed of paramount concern for their project.  A quick and easy fix with Chainstack  With Chainstack’s secure transactions and web socket system, these offerings matched the Eldarune development team’s priority of security and speed. Without any throttling or bottlenecking holding the development back, the team has been on track in their road map to create what could be the game that sets the standard for AI-Web3 gaming RPGs. Resolution summary Eldarune is a demanding game that requires fast and secure multichain support to process high volumes of real-time transactions to ensure smooth gameplay.  This led to bottlenecking and complicated node management, which created difficulties that even the most experienced development team struggled to resolve.  The Eldarune team connected with Chainstack to find a better solution, with an emphasis on security and speed.  Chainstack’s easy node management and high-powered web socket system proved to be the perfect remedy to address these needs.  This resolved the issues and gave the Eldarune development team the missing pieces needed to further progress in their project.  Eldarune has enjoyed a smooth development process since then, without any bottlenecking, which has led to success on the testnet.  At the time of this writing, Eldarune is still in their testnet stage and making strides in their progress to release the full version.  Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Brave Wallet: How Chainstack catalyzes effective cross-chain operations “Chainstack has been crucial in enhancing Brave Wallet’s multi-chain functionality and UX. Their reliable node infrastructure and responsive support have accelerated our innovation and security. We’re excited to continue this partnership that aligns with our commitment to making blockchain technology accessible for everyone.” James Mudgett, VP, Web3, Brave At Chainstack, it is our mission to empower the crypto pioneers pushing the envelope for Web3 with every block. This makes our work with Brave Wallet especially rewarding. This visionary crypto wallet, integrated directly into the Brave browser, has made a significant mark on the decentralized landscape. It provides a comprehensive platform for users to manage their crypto portfolios seamlessly, underpinned by features like native DApp browser functionality, multi-chain support, and self-custody. We are proud to contribute to their ambition of reshaping the crypto landscape and take pleasure in helping craft a solution that stands as a beacon of blockchain technology’s transformative power. Join us as we share the story of our work together in navigating the constantly evolving world of Web3. How Brave Wallet started with Chainstack From the moment Brave Wallet began considering its multi-chain support strategy, we found a unique opportunity to make a difference. Their team was exploring various providers but found our wide array of services and focus on supporting a diverse set of blockchains intriguing. Brave Wallet needed a robust, high-performing infrastructure that could effectively cater to multi-chain operations. Their particular inclination towards seeking tailored solutions for Bitcoin resonated with our beliefs. They had learned from past experiences that not all service providers could give equal attention to all blockchains, a concept we hold in high regard. Brave Wallet had been experiencing significant downtime with another provider for Solana. We understood their pain points and acknowledged their necessity for a more dependable and scalable infrastructure. Hence, we decided to step up and fill that void for them. We were able to convince them of our capabilities through our extensive range of chain support, mastery of latency and reliability, and superior performance during uncertain times for protocols like Solana. These factors set us apart from other providers and played a crucial role in placing us on Brave Wallet’s radar. Brave Wallet’s decision to partner with us wasn’t an immediate one. They carefully examined us, testing our services before reaching a final decision. Our consistently superior performance, combined with our responsive support and essential Bitcoin infrastructure, succeeded in winning them over. What sealed the deal for Brave Wallet were our tailored Bitcoin solutions and proactive partnership approach. Our ready assistance when needed led them to choose us as their provider and we’re glad to fulfill these expectations. With our support, they have been successful in achieving their expansion targets while optimizing their operations. Their plans align with our ultimate goal—to democratize access to blockchain technology. Together, we’ve made tremendous strides and accelerate the decentralized future. Brave Wallet on Chainstack in numbers Our partnership with Brave Wallet, which has a bourgeoning user base and an exponential growth trajectory, has been quite an eventful journey. Since the onset of our collaboration, we’ve worked together to elevate the capabilities of Brave Wallet, ensuring superior performance and reliability across their multi-chain operations. On our platform, Brave Wallet operates 12 active Global Nodes supporting a diverse range of protocols. These include Arbitrum, Aurora, Avalanche, Bitcoin, BNB Smart Chain, Ethereum, Optimism, Polygon, Solana, and the zkSync Era. This diversity alone paints a vivid picture of Brave Wallet’s expansive operation and the team’s commitment to achieving versatile functionality. In terms of requests, Brave Wallet’s figures are quite impressive—our Global Nodes have clocked in a staggering count of over 241M requests, representing a large majority. Zooming into protocol-specific requests, a significant number of 62.1M requests were made specifically for the Aurora protocol. Bitcoin saw 1.2M requests all via dedicated nodes in a testament to their reliability. Figure 1: Brave Wallet Full node RU allocation This story in numbers reveals that our resilient and scalable infrastructure plays an essential role in helping Brave Wallet meet the needs of its ever-growing users and cope with the explosive growth of multi-chain data. Together, we’re uniquely positioned to navigate the crypto world’s dynamic landscape and propel Brave Wallet’s vision for an accessible and inclusive blockchain-powered future. What is Brave Wallet? Brave Wallet is an innovative cryptocurrency wallet integrated into the Brave desktop browser. This strategic design allows users to manage, expand, and diversify their crypto portfolios from a single, easily accessible location. Unlike the majority of crypto wallets, which tend to function as extensions, Brave Wallet is browser-native. This unique feature eliminates the need for additional extensions, enhances safety and performance, and significantly mitigates security risks. As such, users can safely transact with virtually any kind of crypto asset, connect with other wallets, and engage with Web3 DApps. With Brave Wallet, users can interact with DApps across any EVM-compatible network, manage their portfolios with NFT and multi-chain support, and enjoy the easy importation of wallets from MetaMask and self-custody wallets. It also offers compatibility with Brave’s previous Crypto Wallets extension and hardware wallets such as Trezor and Ledger. Central to the Brave Wallet model is the ability to self-custody. This means users have complete control over the management or transaction of their assets. Brave Wallet users can send and receive assets, view live and historical market graphs, and find the best price match against a list of providers, all from their desktop browser. Another key feature of the Brave Wallet is the ability to connect to DApps on Ethereum and other EVM-compatible networks, as well as the Solana network. It also provides up-to-date prices of top crypto assets on the Market tab and makes it easy to connect, sign, and secure transactions with hardware wallets like Ledger and Trezor. Moreover, Brave Wallet stands out for its capacity to send and receive a variety of tokens from a multitude of supported chains for an aggregated view of your cryptocurrency and NFT portfolio. It also supports easy facilitation of swaps between Ethereum-based assets and those on Solana, all at the best prices. Figure 2: Brave Wallet comparison; Source: Brave Finally, Brave Wallet users can enjoy 100% ownership of their private keys. This means that, unlike other wallets, Brave is not able to access or manage their funds on their behalf, adding an extra layer of security for users. Not only is Brave Wallet an unfalteringly secure and versatile cryptocurrency wallet, but it’s also taking strides to better the world of crypto, laying the foundation for a more inclusive Web3 future. “Our work with Brave Wallet exemplifies Chainstack’s dedication to powering the next generation of Web3 DApps. By providing Brave with scalable and secure infrastructure, we’ve enabled their team to optimize multi-chain operations and improve user interactions.” Eugene Aseev, CTO, Chainstack Bringing it all together As we reflect back, our partnership with Brave Wallet has been a rewarding journey of empowerment and growth, showcasing the potential of true collaboration and the power of the resilient Web3 infrastructure. Despite the challenges and the daunting task of meeting the requirements of a vast array of chains with the need for a strong Bitcoin presence, we were able to rise to the occasion. Our approach towards overcoming challenges and meeting expectations head-on has resulted in Brave Wallet team being able to scale their operations effectively during peak demands. Especially during moments of instability for certain blockchains like Solana, our platform remained stable and dependable, something that we take great pride in. As we look ahead, we’re excited about the impact that our continued partnership with Brave Wallet will have on the wider Web3 developer community. Our collaboration is proof that with the right tools and a mutual commitment to innovation, we can make the crypto space more accessible, more efficient, and ultimately, more impactful. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Bridging algorithms and art: A look into generative NFTs Generative art, an artistic approach that has been part of human creative expression for decades, recently found a whole new dimension following the emergence of Non-Fungible Tokens (NFTs). This convergence breathed new life into generative art, propelling it into the limelight after nearly 60 years on the periphery. This intersection has not only revisited the way we perceive and value art but also unlocked remarkable financial prospects for artists. This exploratory blog post will demystify the union of generative art and NFTs, trace their individual and combined histories, uncover how they are crafted, and help us understand their exponential popularity. Stay with us as we journey through the captivating world of generative art NFTs, its impact on current artistic paradigms, and what it could mean for the future. This enlightening exploration will give you a well-rounded understanding of generative art, its evolution into the NFT space, and what makes it tick in the exciting world of art today. Understanding generative art Generative art refers to any art practice where the artist employs an autonomous system to make the artwork. These systems, guided by algorithms and geometry and animated by a degree of randomness, can independently generate a piece of art. The artist and the generative system become collaborators in the creative process, producing artworks that are unique and irreproducible. This profound artistic style traces its roots back to the 1950-60s, well before the advent of the internet and blockchain technology. But amidst the explosion of various artistic styles and concepts, such as Pop Art and Conceptual Art, generative art took a backseat. Fast forward to today; generative art has found a new home and audience in NFTs, allowing a whole new breed of artists to earn from selling algorithmic art. Figure 1: Early generative art—E. Kelly’s Spectrum colours arranged by chance II, 1951; Source: Crysalis This reincarnation of generative art through NFTs is more than a simple rekindling of an old flame. It’s a revolution — a new chapter in the artistic and income-generating landscape that could very well define the future of art. Evolution of generative art If you’ve ever lined up dominos to create a cascading effect or fashioned a digital caricature using an avatar creator, you’ve worked with generative systems. Generative systems, a blend of sophistication and randomness, lend themselves to limitless possibilities. In the realm of art, these systems birth generative art – a fascinating cross between science and creativity. When we talk about generative art, we refer to art that relies on self-running systems or algorithms to come to life. A generative artist functions as a sculptor of these systems, designing formulas or conditions that, when set into motion, generate an artwork. The essence of generative art often lies not in the final product but in the process that brings it to life. A critical factor that sets generative art apart from other forms of art is randomness. If an artist can determine every detail of the resulting piece beforehand, it doesn’t rightly qualify as generative art. Therefore, unpredictability is a significant feature of generative art, allowing every piece to present a unique end result. It is this chance factor that adds a mysterious allure to each artwork. Figure 2: Generative art systems; Source: Galanter, 2003 Today, however, generative art has been ushered into the limelight through the unlikely path of NFTs. This medium offers generative artists a plethora of opportunities for exposure and monetization. As a result, generative art is gradually emerging from obscurity, shaping itself as a key player in the digital art world. From generative art to generative NFTs As art continually evolves with time, technology seems to always influence its course. The inception of NFTs is the most recent testament to this phenomenon, and the realm that reaped the most significant benefits from this advancement is generative art. Generative Art NFTs are unique digital art pieces created through coded algorithms and stored as NFTs on the blockchain. When an artist conceives a generative art piece, the artwork’s uniqueness lies not in the final manifestation but in the algorithm or software that created it. This unique process and the diverse outcomes it produces set the stage for generative art to find a new home in the exploding NFT market. Since their inception in 2017, NFTs have seen a dramatic rise in popularity. By the end of 2021, NFT sales had reached $25 billion. Even amidst the 2022 crypto slump and the demise of numerous crypto exchanges, NFT transactions totaled $24.7 billion. These figures highlight the robust growth of the NFT ecosystem and the rising acceptance of digital representations of ownership. Figure 3: US Non-Fungible Token market 2020-2023; Source: Grand View Research Advantages of generative NFTs With the continuous upsurge in NFTs, generative art NFTs have emerged as a sought-after NFT art form. Their distinctive creation process and the unpredictable yet fascinating results it yields intrigue both art enthusiasts and collectors. Today, anyone with internet access can own a piece of generative art thanks to NFTs. NFTs have not only increased the accessibility of generative art but also substantially broadened its audience. The growing interest in generative art NFTs from art lovers and prospective investors alike could potentially catalyze the expansion of the overall generative art industry and further integrate it into mainstream art appreciation and collection. Generative art NFTs—an innovative blend of coding, algorithms, randomness, and digital artistry—chart a new avenue in the global art landscape. The mutually beneficial marriage of generative art and NFTs not only enriches digital artistry but also amplifies its financial viability in an increasingly digital world. Why people buy generative NFT art Generative NFT art has been rapidly gaining traction among collectors and enthusiasts alike. This phenomenon is attributable to several factors, including: Unique one-of-a-kind creations: Generative NFT art pieces are algorithmically crafted and coded, meaning that every creation is truly one-of-a-kind. This uniqueness adds a potential for the value of the artwork to appreciate over time, making it a highly attractive investment option. Self-expression: The varied styles and themes of generative NFT art offer a platform for self-expression. By purchasing such pieces, collectors can display their personal preferences and aesthetic tastes. The wide assortment of generative NFT art ensures that there’s something for everyone, allowing collectors to express their individuality authentically. Supporting artists: The rise of generative NFT art has provided artists with a platform to sell their creations directly to collectors, bypassing traditional intermediaries like galleries or auction houses. This direct selling model enables artists to maintain greater control over their work and retain a larger portion of the sales proceeds, fostering continual innovation in their artistic pursuits. Growing community: The generative NFT art landscape is fostering a rapidly expanding community of artists, collectors, and enthusiasts. Individuals are finding common ground over their shared interest in this emerging art form, enabling the formation of valuable connections and opportunities within this vibrant community. Storytelling: Each piece of generative NFT art is born out of a unique backstory and a complex creative process often involving intricate algorithms and programming. Owning such a piece allows collectors to immerse themselves in this story, providing an insight into the creative process and the inspiration behind the artwork. This experience helps to create a profound connection between the collector and the artwork, enhancing its emotional and sentimental value. The art of creating generative NFTs When stepping into the realm of creating generative art NFTs, one adapts the dual role of an artist and a technologist. While an artist visualizes and defines the concept, the technologist selects the appropriate AI tools and relevant blockchain to bring the idea to life. Figure 4: Generative AI timeline; Source: Sequoia Capital The creation of generative art NFTs commences with defining the traits of your NFTs. Traits are attributes that characterize your NFT, such as color, pattern, or theme. After delineating the primary traits, the artist designs one or multiple variations for each trait. These variations create diversity among generative NFTs and set the stage for the subsequent step – integrating smart scripts. Smart scripts are algorithmic codes that infuse unpredictability into the generative art NFTs. When these scripts are integrated with your NFT design, they generate numerous unique variations of NFTs. Furthermore, artists can restrict the total count of NFTs that can be generated using a certain smart script, thereby preserving the uniqueness of their generative NFTs. Curious to look under the hood of smart scripts and how they’re used in generative NFTs? Dig into the details with our dedicated tutorial: How to create generative NFTs? Making abstract art with code AI technology is the linchpin in assembling the elements of generative NFTs. It revolutionizes an artist’s ability to work in tandem with machines, enabling them to concoct distinct pieces of art. To aid this process, there is a large diversity of resources, software, and tutorials in the market targeting the creation of generative art NFTs. The role of AI in creating generative NFTs Artificial Intelligence, particularly in the form of machine learning, plays an instrumental role in the creation of generative NFT art. The art world mirrors the idea that machine learning algorithms, when fed with a substantial amount of image data, can generate original images just as a human artist would. Generative Adversarial Networks, or GANs, is one such technology that has greatly influenced the world of AI art. By using these algorithms, AI can learn from extensive periods of training, akin to an artist refining their skills over time. Consequently, AI has become capable of creating images that have never been drawn before. This concept applied in real-world scenarios is relatively straightforward. An artist may ideate a piece of art using keywords or phrases. This information then gets processed by the artificially intelligent model. The AI reviews a myriad of art styles, genres, and periods to produce a unique visual interpretation of the initial text. Figure 5: Creative AI art generation process; Source: Ali Elfa and Dawood, 2023 Bringing it all together The world of generative art has been quietly evolving since its inception in the 1960s, awaiting the catalyst that would propel it into the mainstream. That catalyst emerged in the form of Non-Fungible Tokens, which have opened up new avenues for artists to create, showcase, and monetize their works in unique ways. Generative art, with its emphasis on process, unpredictability, and the blend of artistic vision with algorithmic creation, has found a perfect home within the blockchain-based landscape of NFTs. With innovative tools and expansive resources now available, artists can push the boundaries of this genre like never before. The rising popularity of generative NFT art is attributable to several factors. From an investment standpoint, the uniqueness of each piece holds the potential for significant appreciation over time. Collectors find value in the self-expression that these pieces offer, as well as the sense of connection to a vibrant, growing community of like-minded enthusiasts. Moreover, purchasing generative NFT art directly supports artists, who retain a larger share of the proceeds from their work than in traditional art markets. In essence, the intersection of generative art and NFTs represents a significant evolution in both the art and blockchain domains. As this art form continues to thrive and innovate, it remains a captivating field for artists, collectors, and enthusiasts alike, promising a future where art and technology continue to intersect and inspire in ways that are yet to be imagined. The journey of generative NFT art is just beginning, but its impact is already undeniable. As we continue to explore and understand this fascinating domain, we look forward to witnessing the novel ideas and stunning creations that will undoubtedly emerge from this revolutionary intersection of art and technology. And as the curtain falls, it’s clear that we’re standing on the threshold of an exhilarating new chapter in the ever-evolving narrative of art. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Bringing the simplicity of Chainstack’s automated deployment to Hyperledger Fabric 2.0 Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Today, we are proud to announce that we are introducing Hyperledger Fabric 2.0 as the latest addition to Chainstack’s multi-protocol line-up. Now, users can spin up high-performing Fabric consortium networks in minutes, complete with Raft ordering service, ability to spin up any number of peers for any number of organizations, resource monitoring, network exploration, and more. Built on Hyperledger Fabric 2.0.1, Chainstack is the first managed service provider to enable enterprises to leverage the latest version of Fabric. Half of the largest blockchain projects are built on Hyperledger Fabric Launched in 2017, Fabric was the first project to be released under the Hyperledger greenhouse. It has since then been the protocol of choice for many blockchain-based consortia to date, including We.Trade, Tradelens, and Food Trust. Released a month ago, version 2.0 boasts new enhancements specifically designed to address the challenges that enterprises have faced while working with the first version of Hyperledger Fabric. It includes improvements such as heightened data privacy capabilities, increased performance, more granular controls, and greater flexibility for consortium management. One of the most exciting changes in 2.0 is that it now supports decentralized models of smart contract governance. This means that unlike release 1x, the majority of the participants can now be required to agree to the terms of a chaincode before it can be activated on a channel. As Hyperledger Fabric becomes more suited for the strict requirements of operating in enterprise contexts, it becomes easier for companies to implement blockchain-based solutions and leverage its key benefits. Access remains gated Hyperledger Fabric is known to be notoriously complex. Many companies struggle to build and manage their own infrastructure. While existing deployment tooling has provided some relief for developers’ infrastructure maintenance, many of these services are often costly, inflexible, or overly complex. Start building on Hyperledger Fabric 2.0 in minutes That’s why we’re excited to announce the availability of our managed Fabric service. We’re confident that we’ve found the simplest, most flexible, and cost-effective way for developers to start building solutions on top of the latest version of Fabric 2.0. Now, users can deploy multiple high-performing networks running Fabric 2.0 in the cloud or on-prem, complete with channels, multiple organizations, peers, ordering service, and more. Build and test chaincode, create channels, and build applications on top of an infrastructure layer that you can trust to grow as your network expands into production. Be agile Chainstack supports the widest variety of deployment configurations. Host your networks however you want—in public cloud or on-premise. Save time and cost Chainstack’s intuitive user interface abstracts away the complexity of implementation. By automating resource provisioning and network configuration, Chainstack allows you to save time and costs in deploying and managing complex network infrastructure. Forget about messy upgrades and downtime, we let you focus on what you do best. Build with confidence Have confidence in the availability and performance of your resources. Chainstack is designed to support your network and application development as you scale, empowering you to build with confidence. Flexibly grow a multi-cloud, multi-org consortium Chainstack helps budding consortia maximize network effects by providing members easy access to the network. Organizations can effortlessly scale up by deploying as many nodes as they need, on their cloud of choice, always with predictable pricing. With just an e-mail, users can invite new organizations to participate and get them started in minutes. A significant amount of complex orchestration takes place under the hood of the Chainstack engine. All with the goal of simplifying and accelerating the process of network creation and management. From setting policy configurations across the network, to certificate generation, resource allocation for nodes, and automated updates to channel configuration for every new organization and peer that joins. Network administrators and application developers alike can spend less time troubleshooting their infrastructure and spend their efforts in designing complex solutions and growing their network. Next steps So come see what we’ve built. If you are currently developing a solution on Hyperledger Fabric, we invite you to explore the enhancements in Fabric 2.0 in minutes on Chainstack. You can sign up for a starter Developer plan at console.chainstack.com or learn more on our docs site. For those of you at the Hyperledger Global Forum this week who would like to learn more, please come visit us at our booth SU6 or attend our Fabric 2.0 in 5 clicks session on Tuesday, March 3 to speak with a member from the Chainstack team. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Build better on TON with Chainstack At Chainstack, we know what Web3 developers want: blazing fast nodes, predictable infrastructure, and the freedom to build without hitting limits. That’s exactly why we’ve built our TON infrastructure to be global, scalable, and developer-first. With geo-load balanced endpoints across the US, EU, and Asia, your DApps run on a network that’s engineered for resilience and real-time performance. No downtime. No rate limit nightmares. No surprise bills. Chainstack is the backbone of your TON-powered applications—built for scale, built for builders. Why build on TON with Chainstack? When you choose Chainstack for your TON infrastructure, you’re not just getting RPC access—you’re getting a performance engine built to handle real production-grade DApps. Here’s what makes Chainstack the top choice for TON developers: Global geo-load balanced infrastructure: Automatically routes traffic through the closest and fastest node to minimize latency worldwide. Resilient by design: Every node is backed by redundant systems and self-healing architecture to stay online no matter what. Optimized for scale: Built to handle high RPS (requests per second) workloads, including archive calls and historical data lookups. Developer-friendly quotas: Generous free tier and high request ceilings across all plans so you can test, iterate, and grow. Flat and predictable pricing: No hidden costs. No multiplier surprises. Just transparent pricing that scales with you. Built-in performance visibility: Transparent real-time metrics via the Chainstack Compare Dashboard. TON-specific tooling: Native support for top TON SDKs and libraries in JavaScript, Python, Go, Rust, and more. Chainstack doesn’t just support TON—we’re optimized for it. Chainstack vs. QuickNode & TonCenter: Real-world performance Our Compare Dashboard gives you full transparency on RPC provider performance. Here’s how Chainstack stacks up on the TON network: Provider score (lower is better) Chainstack-Growth: 0.52 TonCenter-WithAPIKey: 0.58 Quicknode-Growth: 0.69 Figure 1: TON average provider score (lower is better); Source: Compare Dashboard runGetMethod ProviderMinMeanMaxTonCenter-WithAPIKey – EU247 ms433 ms985 msChainstack-Growth – EU224 ms454 ms828 msChainstack-Growth – SG258 ms480 ms3.86 sQuicknode-Growth – US West395 ms602 ms833 msQuicknode-Growth – EU473 ms691 ms3.55 sTonCenter-WithAPIKey – SG417 ms755 ms1.62 sTonCenter-WithAPIKey – US West390 ms793 ms5.60 sChainstack-Growth – US West407 ms867 ms3.33 sQuicknode-Growth – SG768 ms937 ms1.43 sFigure 2: TON runGetMethod historical response times; Source: Compare Dashboard Figure 3: TON runGetMethod historical response times graph; Source: Compare Dashboard getAddressBalance ProviderMinMeanMaxTonCenter-WithAPIKey – EU188 ms409 ms996 msChainstack-Growth – EU181 ms419 ms2.38 sChainstack-Growth – SG242 ms430 ms3.76 sQuicknode-Growth – US West391 ms566 ms757 msQuicknode-Growth – EU450 ms651 ms3.23 sTonCenter-WithAPIKey – SG377 ms722 ms2.23 sTonCenter-WithAPIKey – US West396 ms747 ms1.31 sChainstack-Growth – US West383 ms837 ms5.91 sQuicknode-Growth – SG734 ms897 ms1.90 sFigure 4: TON getAddressBalance historical response times; Source: Compare Dashboard Figure 5: TON getAddressBalance historical response times graph; Source: Compare Dashboard getWalletInformation ProviderMinMeanMaxChainstack-Growth – EU220 ms411 ms1.31 sTonCenter-WithAPIKey – EU168 ms414 ms5.58 sChainstack-Growth – SG222 ms419 ms3.72 sQuicknode-Growth – US West381 ms559 ms805 msQuicknode-Growth – EU480 ms642 ms1.77 sTonCenter-WithAPIKey – SG376 ms726 ms2.19 sTonCenter-WithAPIKey – US West401 ms749 ms1.60 sChainstack-Growth – US West361 ms829 ms3.00 sQuicknode-Growth – SG751 ms887 ms1.10 sFigure 6: TON getWalletInformation historical response times; Source: Compare Dashboard Figure 7: TON getWalletInformation historical response times graph; Source: Compare Dashboard getBlockTransactions ProviderMinMeanMaxTonCenter-WithAPIKey – EU208 ms395 ms2.63 sChainstack-Growth – EU221 ms416 ms1.04 sChainstack-Growth – SG243 ms422 ms3.77 sQuicknode-Growth – US West342 ms560 ms736 msQuicknode-Growth – EU420 ms646 ms1.83 sTonCenter-WithAPIKey – SG352 ms696 ms1.26 sTonCenter-WithAPIKey – US West385 ms733 ms3.75 sChainstack-Growth – US West376 ms832 ms2.94 sQuicknode-Growth – SG751 ms889 ms1.08 sFigure 8: TON getBlockTransactions historical response times; Source: Compare Dashboard Figure 9: TON getBlockTransactions historical response times graph; Source: Compare Dashboard getBlockHeader ProviderMinMeanMaxTonCenter-WithAPIKey – EU183 ms387 ms1.58 sChainstack-Growth – EU191 ms431 ms5.35 sChainstack-Growth – SG233 ms439 ms3.80 sQuicknode-Growth – US West318 ms576 ms741 msQuicknode-Growth – EU480 ms662 ms1.09 sTonCenter-WithAPIKey – SG342 ms700 ms1.98 sTonCenter-WithAPIKey – US West360 ms731 ms1.83 sChainstack-Growth – US West384 ms849 ms2.93 sQuicknode-Growth – SG751 ms909 ms1.16 sFigure 10: TON getBlockHeader historical response times; Source: Compare Dashboard Figure 11: TON getBlockHeader historical response times graph; Source: Compare Dashboard Chainstack leads on consistency, speed, and reliability—across all global regions and across all major TON methods. Developer-first tooling for TON Whether you’re building smart contracts, deploying Jettons, or integrating TON wallets, Chainstack gives you a complete dev stack. Supported languages and libraries: JavaScript: TonWeb, Ton.js Go: TonUtils, TonGo Rust: Tonlib-rs Python: TONsdk, PyTONLib, Pytoniq .NET: TonSDK.NET Explore our Ultimate Guide to TON APIs and Libraries to get started. Free TON Testnet tokens with the Chainstack Faucet Every great build starts with testing. That’s why we created the Chainstack TON Faucet—available on web and as a Telegram mini-app. Claim up to 1 TON testnet token every 24h Use for deploying smart contracts and test transactions No cost, no risk, full flexibility Custom RPC endpoints for TON wallets Chainstack makes it easy to set up custom TON RPC endpoints for your wallets. Here’s what that looks like across top TON wallets: WalletRPC via UISwitch Contract VersionsTestnet ModeOpen SourceTonkeeper❎ (via code)✅✅✅MyTonWallet❎ (via code)✅✅✅OpenMask✅✅✅✅TON Wallet❎ (via code)❎❎✅Figure 12: TON wallets custom RPC endpoint support; Source: Chainstack Read the full wallet integration guide to learn how. Build advanced TON DApps with Chainstack Whether you’re building a wallet, a marketplace, or an entire DeFi ecosystem—Chainstack has you covered. Deploy smart contracts on TON Develop NFTs Develop fungible Jettons Customize Jettons (capped supply, tokenomics) Further reading Build better with TON TON tool suite TON developer guide TON glossary Smart contract deployment guide Compare Dashboard TON APIs and libraries Custom RPC endpoints for wallets TON faucet Start building on TON with Chainstack today Chainstack is the easiest, fastest, and most reliable way to build and scale on the TON blockchain. With high-performance nodes, deep developer tooling, and transparent benchmarks, we give you the infrastructure edge you need. Deploy your first TON node for free on the Developer plan. Sign up and get started. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Build on Fantom using Chainstack high-performance, scalable, and secure infrastructure We are pleased to welcome Fantom to our platform and to announce full support for Fantom’s open-source smart contract platform for digital assets and decentralized applications (DApps). Using Chainstack’s extremely reliable and scalable infrastructure solutions, Fantom builders can focus on creating a more connected and efficient future. Because of its near instant finality and inexpensive transaction fees, Fantom has grown at an exponential rate. Fantom’s adoption stems from more than just the ability to perform. The blockchain network is also designed to provide high scalability and institutional-grade security. In May, it was reported that Fantom had crossed 3 million transactions and was the fastest blockchain platform. With a growing ecosystem, we see over 1,150,000 unique addresses today and process huge daily transactions on the platform. What is Fantom? Fantom is a fast, scalable, and secure layer-1 EVM-compatible platform built on a permissionless aBFT consensus protocol. On Fantom, transactions are processed on average in 1-2 seconds, costing just a few cents. Speed, low transaction costs, and high throughput make Fantom ideal for DeFi applications and real-world use-cases. Building on Fantom Fantom is a secure and fast environment to build decentralized applications. It is fully permissionless and open source. Powered by Fantom’s aBFT consensus algorithm, it leverages its speed and fast finality, and it’s ready for real-world use with no risk of congestion or extended confirmation times. Fantom has offered scalability for applications running in its fastest aBFT blockchain platform. Each application works seemingly similarly to running on different computers of the same network, with the ability to have its own custom tokens, tokenomics, and governance rules. Unlike traditional Proof-of-Stake systems, where some validators decide on the validity of the transactions, a leaderless Proof-of-Stake does not depend on the validators to determine which blocks are valid. Removing leaders significantly improves network security. The consensus process is very scalable, with the ability to operate over hundreds of nodes, allowing for more decentralization and institutional-grade security. The Fantom Opera mainnet is Ethereum Virtual Machine (EVM) compatible and supports full smart contract functionality and the Solidity language. Fantom’s modularity makes it extremely adaptable. Developers can quickly move their existing Ethereum-based dApps to the Fantom Opera mainnet, significantly improving performance and cutting expenses. Fantom on Chainstack The integration of Fantom on Chainstack is another step toward our objective of making Web3 accessible to everyone. This collaboration brings two teams together who are both committed to offering new solutions to the public while also increasing accessibility and scalability. Building a blockchain ecosystem necessitates infrastructure that can be relied on by developers and builders alike. Developers and builders in Web3 and DeFi can now build high-performing projects on Fantom, the “network of networks,” and overcome the limitations of previous generation blockchain platforms, thanks to Chainstack’s enterprise-grade infrastructure across multiple cloud networks and regions. Despite the industry’s progress in terms of maturity and usability, maintaining a blockchain node or network still necessitates addressing several key infrastructure challenges that divert attention away from product development and go-to-market strategies. Due to the intricacy and vast volume of data to download and process, the cost of labor and time to set up infrastructure and sync a node can be exorbitant. Thanks to a high degree of automation and top-quality engineering, Chainstack allows developers to install and sync their nodes in minutes, with predictable pricing that is industry leading. Chainstack blockchain managed services incorporate tools and services to facilitate constructing and maintaining a DApp, a blockchain analytics platform, or a trading bot, in addition to node management and operations. How to use Fantom on Chainstack Chainstack is a dependable and simple-to-use platform for quickly deploying nodes on a variety of hosting platforms, including fully managed public clouds like AWS, Azure, and GCP, as well as on-premises. Companies can now deploy Fantom nodes in the same easy and cost-effective way, without needing to invest precious time and resources in setting up enterprise-grade infrastructure. Chainstack allows companies to access to Fantom shared archive nodes or deploy dedicated archive nodes to query the entire history of the mainnet—starting with Business plan. And with Chainstack’s Bolt fast sync technology, node deployment is achievable within minutes instead of months. Developers may entrust their projects to Chainstack and significantly shorten their time-to-market while also benefiting from high-performing and dependable infrastructure. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack has a distinctive price advantage compared to other providers. This is reflected in the introductory pricing for Fantom for shared full nodes at $0/month on Developer plan with 3M requests included. Subscription tiers are well planned out to be highly cost efficient, supporting all projects and use cases in different stages and types. Growth plan will provide 8M requests and Business plan provides 20M requests. Unlimited requests will be available on all dedicated nodes deployed starting from the Business plan. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests; then $0.05 per 10K requests. See also the full pricing information and a handy calculator. Working together on making Web3 faster and better Fantom enables businesses to create high-performing, environmentally sustainable applications by leveraging blockchain technology that is engineered for performance, scalability, and security. The core mission of the Fantom Foundation is to help support an open-source, public ledger that is accessible, scalable, and user-friendly. Beyond our incentive programs, we seek to offer developers a wide array of tools and services, and Chainstack has an important role to play, helping teams and projects move seamlessly from the building phase to product launch. Chainstack shares our ambition to connect the world to Web 3.0, and we are absolutely thrilled that they now support Fantom.Michael Kong, CEO Fantom Foundation Thanks to enterprise-grade, easy-to-use infrastructure, tools, and services, Chainstack creates connectivity and interoperability between developers and innovative Web3 applications. Fantom is devoted to deliver developers with highly performing, secure, and scalable platform that supports Ethereum smart contracts, along with a vibrant community and environment that enables users to create highly functional decentralized applications. Chainstack has become a valued ally for Fantom’s community, assisting with innovation, growth, and versatility. Fantom developers now have a platform that is secure, features complete functionalities, and is trustworthy over numerous chains, thanks to its multi-chain design.Eugene Aseev, Founder and CTO of Chainstack Both teams will collaborate to create infrastructure for a more connected and efficient future where projects and end-users can benefit from the innovative power of decentralized and DeFi applications while also enjoying higher performance and lower gas fees in the same enterprise-grade infrastructure that thousands of companies trust every day around the world. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Build on Solana with Chainstack: Maximizing node infrastructure performance and reliability The blockchain world today is buzzing with a multitude of networks, each promising unique capabilities, high performance, and robust security. Among the many layers of this ever-expanding ecosystem lies Solana, a stand-out as an open-source project implementing a high-performance, permissionless blockchain. Solana’s essence lies in its mission—to bring blockchain to the masses. It’s not just about fostering economic efficiency, but also shaping a user-friendly experience for everyone. Be it power users who require high performance or new consumers stepping into the world of Blockchains, Solana aims to provide supportive experiences for all. Chainstack Solana Week: Celebrating Solana and its builders In an enthusiastic endeavor to bring communities together and embark on a deeper exploration of different blockchain protocols, we’re thrilled to kick off our Protocol Weeks series. We’re starting this journey with Solana Week, diving into the expansive Solana ecosystem, discussing crucial matters, and sharing insightful knowledge tailored to maximize the potential of Solana with Chainstack. The Solana Week stands on three core pillars geared towards enriching our community’s understanding of Solana and enhancing their projects’ flourish. Understanding Solana: This involves a deep dive into the hallmark advantages of Solana, its performance optimization, and ways to manage infrastructure costs effectively. You’ll get an opportunity to grasp the intricate matters surrounding Solana’s architecture and operations, helping you better utilize its capacities in your blockchain journey. Learning through sharing: During Chainstack Solana Week, we’ll be sharing a variety of guides, recipes, and best practices designed to accelerate your projects. From learning the nuances of DApp development on Solana to understanding its seamless transaction process, we seek to provide a comprehensive learning experience for Solana builders. Exclusive Solana Week offer: To make Solana Week even more exciting, we’re offering an exclusive deal. You can use the code “SOLWEEK” and get a staggering 98% off on our Growth Plan. This means for the first month: it’s only $1. This is not just a celebration; it’s a unique opportunity to find inspiration, upskill, and propel your project to new heights. We look forward to celebrating the vibrant Solana ecosystem with you, helping you envision, and realize new frontiers of innovation in the blockchain landscape. What makes Solana the go-to-choice for Web3 developers Among the key attributes that make Solana a highly desirable blockchain solution is its unprecedented transaction processing capacity. It has proven in practice that it is possible to optimally utilize a standard gigabit network to process up to 710,000 transactions per second, assuming the transactions do not exceed an average of 176 bytes. Notably, Solana manages this impressive feat without substantially compromising the transaction rate, even while maintaining high availability through replicating itself. This stems from leveraging the distributed system technique known as Optimistic Concurrency Control, ordinarily seen in powerful centralized databases. Perhaps most significant is Solana’s unwavering dedication to remain a decentralized network. The validation process for the Solana network is managed by thousands of nodes that operate independently of each other, ensuring that data is secure and resistant to censorship. Moreover, Solana has managed to minimize its environmental impact through its proof-of-stake network and other technical advancements. The energy consumed by each Solana transaction is equivalent to just a few Google searches, positioning it as a sustainable blockchain choice with zero net carbon impact. Exploring Solana use cases across the ecosystem The Solana blockchain isn’t merely a high-performance, scalable, and decentralized network; its real power comes to life through the diverse range of applications it hosts. From payments and gaming to NFTs, DeFi, and DAOs, Solana accommodates a broad spectrum of dynamic applications, all tapping into the network’s robust capabilities. Payments: Solana Pay, for instance, is revolutionizing transactions for millions of businesses via its Shopify integration. It offers lightning-fast USDC transactions, ultra-low fees, and negligible environmental impact, making it an appealing choice for businesses seeking to embrace blockchain-based payments. Gaming: In the gaming sphere, Solana powers games like Bladerite, a free-to-play melee battle royale game. Leveraging Solana’s robust blockchain, Bladerite offers an in-game item ownership system, providing players a unique blend of gaming and blockchain benefits. NFTs: NFTs are an integral part of the Solana network. Innovative platforms like Anybodies, which helps notable brands connect their products with digital assets, are pioneering unique use-cases for NFTs on Solana. DeFi: In the realm of DeFi, the Solana blockchain supports an opensource order book that democratizes finance for its users. Thanks to its low transaction fees and high speeds, Solana is attractive for DeFi applications seeking to offer seamless, efficient services. DAOs: DAOs also find a home on Solana. Organizations such as MonkeDAO, run by NFT holders, actively contribute to and bolster the network’s performance. As Solana continues to grow and innovate, the network’s potential for varied applications looks extremely promising. Given Solana’s commitment to scalability, speed, decentralization, and sustainable energy use, it is a choice venue for the development of next-generation applications. The opportunities are immense for developers innovating atop this high-performance blockchain. Figure 1: A slice of the Solana ecosystem; Source: Solana Chainstack infrastructure empowers Solana developers No Web3 developer needs to compromise performance for affordability, not on our watch! From the very beginning, our vision at Chainstack has always been to empower you with affordable infrastructure that delivers outstanding results. When we embarked on designing our Solana infrastructure, the focus was two-fold: power and flexibility. After all, Web3 developers like yourself understand top-notch infrastructure is critical for their blockchain applications. That’s exactly why we chose to optimize our platform for Solana. This powerful, high-performance blockchain is paving the way for a new generation of DApps, from DeFi and NFTs to GameFi and beyond. We recognized the potential of Solana early on and have been relentless in our mission to provide you with the robust, reliable node infrastructure you need to build exceptional Web3 experiences on it. And while performance and functionality form our core, we understand your need for cost-effectiveness. That’s why our Solana pricing is competitive and transparent—enabling you to deliver value without compromising on budget. Build on Solana cost-effectively with Chainstack One of the key aspects we focus on at Chainstack is ensuring that our services provide value to the Web3 developers. And a part of this commitment is delivering affordable yet robust infrastructure. When you look at our Solana pricing, you’ll notice we’re way ahead of the competition. Simply, you get to have your cake and eat it, saving 34%+ with a Growth Solana profile, while enjoying optimal performance with zero compromise. At Chainstack, we aim to provide you with unparalleled value, so you can scale your projects cost-effectively. Figure 2: Chainstack Solana Growth profile usage and pricing breakdown; Source: Chainstack We talk numbers because we believe in transparency and affordability. So, as a Web3 developer, you can rest assured that you’re getting plenty of bang for your buck and focus on what matters most—building groundbreaking Solana DApps. This is the Chainstack way! Unleash Solana speed and efficiency with Chainstack Global Nodes At Chainstack, we understand that for you, as a Web3 developer, node infrastructure is not just about spin-up times and availability. It’s about being able to count on a reliable, powerful infrastructure that can handle high workloads with ease. Built on award-winning architecture, our Global Solana nodes deliver lightning-fast response times with 99.9%+ uptime and have been playing an ever more instrumental role since their launch. Simply put, they enable you to focus on what matters most—creating value for your user base, no matter if you’re creating your first DeFi, an immersive in-game world, or an advanced trading algo. Chainstack Global Nodes run on globally distributed geo-load-balanced architecture that guarantees consistent performance. With an innovative rerouting system, we immediately transfer the workload to the closest best-performing node in the event of any network outage, establishing an effective fallback sequence. This guarantees smooth, efficient, and notably stable operations, so your DApp operates uninterrupted, even in tumultuous times. Figure 3: Unstoppable RPC Endpoint architecture; Source: Chainstack Chainstack Dedicated Nodes tackle resource-heavy operations with ease When exceptional performance is not just a demand but a necessity, it is time to switch over to our Dedicated Nodes. Available exclusively with our Business plan, these nodes are high-performance powerhouses equipped with processors specifically optimized for Solana. Offered in two configurations, the Large (LGR) and Standard (STD), each dedicated node is tailored to suit varied workloads. The LGR is most suited for the Solana Mainnet in handling hardware-intensive tasks. On the other hand, the STD promises equally impressive performance but is designed for a slightly lesser demanding environment, so it is best suited for the Devnet. With Chainstack Dedicated Nodes for Solana, you enjoy far more than a performance boost. You experience an environment sculptured for veritable high-impact operations with resources tailored to elevate your blockchain application journey. Secure uninterrupted performance, accelerate your operations, and conquer your development challenges with Chainstack Solana nodes. Comparing Global and Trader Nodes: What’s best for your Solana project? You’re ready to take your Solana project to the next level, but is your infrastructure? Depending on the scale of your project, Chainstack provides Global and Trader Nodes to match your needs. Our Global nodes are cost-effective and seamlessly scalable, making them ideal for projects with fluctuating workloads. On the other hand, Trader Nodes offer stricter isolation, more resources, and customization, so you can have maximum control over your infrastructure and how it behaves. Overall, Chainstack gives you access to Solana Nodes that surpass the recommended hardware configuration for Solana development by a large margin. Expect exceptional performance, memory, and storage capable of pushing your development to new heights. Supported Solana networks on Chainstack The rich diversity of Solana networks is one of its many strengths, and at Chainstack, we are invested in harnessing their distinct offerings. We support all Solana networks, each designed to cater to a unique set of needs within your development journey. Mainnet: This is Solana’s central processing realm where all transactions occur. It’s where the distributed ledger maintains everyone’s token balances. If you’re dealing with NFT transactions, you’ll be glad to know that we’ve enabled all three indexes (program-id, spl-token-owner, spl-token-mint) for quick and efficient transactions. Devnet: Are you looking to test and develop without risking real assets on the mainnet? Then Devnet is your playground. It provides access to all functionalities of the main net, helping you build and refine without any real-asset interactions. Choosing the right Chainstack Solana nodes hosting Where you host your nodes matters—it is crucial for maximizing the performance and reliability of your infrastructure. At Chainstack, we offer a wide range of location options to host your Solana nodes, each designed to deliver optimal performance for your specific context. Choose between US – Ashburn (ash1), and EU – Amsterdam (ams1) hosting options, each allowing you to deploy Global and Trader Nodes for both Mainnet and Devnet. Or just go global with Chainstack Global Nodes for Solana Mainnet: US – Ashburn (ash1) Mainnet and Devnet Global and Trader EU – Amsterdam (ams1) Mainnet only Global and Trader Worldwide (global1) Mainnet only Global only So, regardless if you’re aiming for maximum reach with the Solana Mainnet or focusing on development within the Solana Devnet, our flexible hosting options ensure that Chainstack always offers you impeccable performance, coupled with strong reliability and security. Make your choice and let our robust and reliable infrastructure take your Solana deployments to the next level. Understanding Chainstack Solana performance Performance is not just about speed; it’s about reliability, scalability, and efficiency. And when it comes to the Chainstack Solana infrastructure, we exceed on all fronts. Our Dedicated Nodes deliver a stellar performance, with the STD maintaining a record of approximately 1400 RPS, while LGR averages around 3000 RPS for common methods. Furthermore, for Full Nodes in Ashburn and Amsterdam locations under Global setups, the RPS levels up even higher to around an impressive 6200. Each type, whether it’s STD, LGR, or Master Node, has no set limits. This means that your operations never face an arbitrary cap allowing for uninhibited scaling. As for capacity, our setups range impressive in their offering, with up to 24 cores/48 threads available in Master nodes and Dedicated nodes. But high performance needs high power! Our Master nodes for Mainnet come equipped with a whopping 1TB of RAM, similarly provisioned for our large dedicated nodes. For Devnet, our standard dedicated nodes also stand strong with 512 GB of RAM. Significantly, such comprehensive performance metrics are seamlessly supported by a robust backbone infrastructure with NVME setups boasting a wide 3.8TB x2 space in every category. This ensures that every transaction is accommodated effectively, and your data storage concerns remain a thing of the past. In essence, we have engineered our Solana infrastructure to not just handle but blaze through high workloads, offering performance, precision, and power at every step. Whether you’re a new Web3 developer exploring its potential or a seasoned player pushing the envelope of decentralized applications, our Solana infrastructure is here to meet your needs and exceed your expectations. How Chainstack Cloud ensures optimal Solana node performance The power of Solana lies in its speed and throughput capabilities and at Chainstack, we ensure you experience this power at its best. Powered by Chainstack Cloud, a purpose-built bare-metal solution, our Solana RPC nodes are able to scale seamlessly without any network disruptions. This is our way of enabling developers to build powerful applications on Solana without worrying about infrastructure. Security is paramount, which is why our HTTP and WebSocket APIs are well-guarded. Need to boost your RPS performance to avoid traffic congestion? Our Solana nodes deliver impressively low latencies in Europe and the US, with maximum throughput, no matter your workload size. All-in-all Chainstack Cloud offers your Solana project unparalleled security through physical isolation and dedicated hardware for steady disk I/O performance. Bringing it all together In an era where the pace of innovation in the Web3 space is accelerating, Chainstack is your reliable partner. We provide you with the robust and scalable infrastructure you need to build groundbreaking applications on Solana, one of the fastest and most reliable blockchains in the world. With our Global and Trader Solana nodes, you can harness the full potential of this powerful blockchain. Meanwhile, our clear performance statistics, support for both Solana Mainnet and Devnet, as well as our flexible hosting options ensure that you have all the resources you need to thrive in the Web3 space. Our platform also opens the door to Solana’s historical data and an integrated marketplace that brings together the Solana community. Plus, our transparent and competitive pricing ensures that you can deliver game-changing solutions without breaking the bank. To the Web3 developers out there—Chainstack and Solana are here to power your blockchain journey. Experience the boundless potential of Solana with Chainstack and redefine the frontiers of Web3 today. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Building a decentralized music marketplace with Arweave, Bundlr, and Polygon File storage is one of those systems required in most complex web apps. You’re building an Instagram-clone app? You need a file storage system for the photos. A Youtube-like app? You need it for that as well. Almost any web2 app has a file storage system behind it. And all those applications use services like AWS S3 or Cloudinary that provide an easy way to upload and query files through simple-to-use APIs. However, these solutions have the same problem as any other web2 app: they’re not decentralized. In the web3 space, there are multiple projects building decentralized data storage systems like IPFS, Filecoin, and Arweave. In this article, we’ll talk about the latter and explain how to create a decentralized music marketplace that uses Arweave to store song files. Ready? Let’s get to it 🤘 What is Arweave (in a nutshell)? Arweave is a decentralized storage network (DSN) and it allows users to upload any type of file and pay a single fee at the time of uploading. This is one of the key differences with other protocols like IPFS, where you have to make repeated payments to keep your files online. In addition, Arweave stores data permanently, so your files are never deleted from the DSN. This has allowed different use cases, like the “permaweb”. You can use Arweave to host a website and, as the files are stored permanently, it’ll never be censored so your website will always be online. To upload files you need to pay using the Arweave native token, which you can buy from different exchanges. In this article, we’ll follow a different route using Bundlr. Let’s see how it works. Using Arweave with other tokens with Bundlr What is Bundlr network? A protocol built on top of Arweave that aims to solve some of Arweave’s native limitations. Using Bundlr you can upload files to Arweave paying with different tokens like ETH, SOL, MATIC, or AVAX to name a few. This gives users a lot more flexibility and opens up the protocol to users from all these different networks. In addition, Bundlr uses bundles (😉) to reduce to cost of uploading files, and even makes uploads free for files under 100kb. And finally, Bundlr network provides its own Javascript library that makes it super easy to interact with the protocol. Piece of cake 🍰 You can learn more about Bundlr in their docs. Transferring funds to Bundlr It’s important to mention that in order to upload files to Arweave using Bundlr, you need to transfer funds from your wallet to Bundlr. You can do this in advance using this app (not the greatest design but you can trust it 😉) or you can do it programmatically following this section of the docs. For the decentralized music marketplace, I decided to follow the lazy-funding approach. That means: check if the user has transferred the funds in advance and, if not (or if the funds are not enough), trigger the funding before actually uploading the file. Don’t worry, we’ll review that in detail later 😉 It’s also worth mentioning that you can withdraw your funds from Bundlr back to your wallet as well. Decentralized music marketplace overview To showcase how to use Arweave and Bundlr, we’re going to build a decentralized music marketplace app. Here is how it’ll work: Users will be able to upload MP3 files and list them for sale by a price. The songs will be uploaded to Arweave via Bundlr and the metadata (title, price, author, and download link) will be stored in a smart contract deployed in Polygon. Other users will be able to browse listed songs and buy them by paying with MATIC When a user buys a song, the MATIC will be sent to the author and the buyer will get a link to download the song or listen to it. We’ll limit this app to MP3 files. In addition, the songs will be bought and sold using MATIC only, but you can extend this app to work with other file types and multiple protocols if you want. We’ll give you some ideas at the end of this article 😉 Tech stack To build this project we’ll use the following tech stack: Solidity to write the smart contract. Javascript to write smart contract tests and deployment scripts. React / Next.js for the web app. You can find the whole code for this app in the following GitHub repository. Let’s start coding 👨🏻‍💻 Smart contract We need a smart contract to store the song’s metadata: title, price, author, and each song’s URL in Arweave. As we don’t want all users to be able to see the URL of every song, we’ll separate the metadata into two different mappings, one with the public information (title, price, and author) and another one private with the URL. // SPDX-License-Identifier: MIT pragma solidity ^0.8.4; contract MusicMarketplace { // Song struct struct Song { uint256 id; uint256 price; address author; address[] buyers; string title; } // array that stores all songs Song[] songs; // stores all songs URLs mapping(uint256 => string) private songDownloadURLs; // events event SongListed(uint256 indexed id, string title, uint256 price); event SongSold(uint256 indexed id, address buyer); //.... } To list a song for sale, users will provide a title, price, and the URL of the file in Arweave. Then we’ll just save that information in the songs and songDownloadURLs state variables as follows: // save song info to songs array function listSong( string memory _title, uint256 _price, string memory _arweaveURI ) public { Song memory song; song.id = songs.length; // save price and other info to song struct song.price = _price; song.author = msg.sender; song.title = _title; // create memory array to store buyers and // include the author address[] memory buyers = new address[](1); buyers[0] = msg.sender; // save buyers to song struct song.buyers = buyers; // save to list of songs songs.push(song); // save the file's arweave URI in private mapping songDownloadURLs[song.id] = _arweaveURI; emit SongListed(song.id, _title, _price); } Notice that we’re also saving the owner using the msg.sender variable and that we’re also including it in the buyers array. We’re doing this to make sure an author does not have to buy his/her own songs and to simplify things for our frontend 😉 To buy a song, we’d need a payable function that receives the amount of MATIC and the song id that the user wants to buy. We also need to do a few checks, like making sure the song id provided exists, that the buyer is not the author of the song and that the user has not bought the song already. For that, I created the following modifiers: // check if song id exists modifier songExists(uint256 _id) { require(songs.length >= _id, "The song does not exist"); _; } // checks if user is not the author of the song modifier isNotAuthor(uint256 _id) { require( msg.sender != songs[_id].author, "You are the author of this song" ); _; } // checks if msg.sender is included in buyers list of song _id modifier isNotBuyer(uint256 _id) { require(songs[_id].buyers.length > 0, "The song has no buyers"); bool userIsNotBuyer = true; for (uint256 x = 0; x < songs[_id].buyers.length; x++) { if (songs[_id].buyers[x] == msg.sender) { console.log("Found buyer: ", songs[_id].buyers[x]); userIsNotBuyer = false; } } require(userIsNotBuyer, "You already own this song"); _; } Then we can use them in our buySong function. It will check that the amount sent is valid, transfer the funds to the author of the song, and add the user’s wallet address to the buyers array in the song mapping: function buySong(uint256 _id) external payable songExists(_id) isNotAuthor(_id) isNotBuyer(_id) { // check if user sent enough funds require(msg.value >= songs[_id].price, "Not enough funds"); // transfer funds address payable receiver = payable(songs[_id].author); (bool sent, ) = receiver.call{value: msg.value}(""); require(sent, "Failed to send Ether"); // add sender to buyers array songs[_id].buyers.push(msg.sender); emit SongSold(_id, msg.sender); } The last important part of this contract is a function to retrieve the URL of the song’s in Arweave. To run this song I created another modifier to make sure that only users that have actually bought the song can retrieve the URL: // checks if msg.sender is included in buyers list of song _id modifier isBuyer(uint256 _id) { require(songs[_id].buyers.length > 0, "The song has no buyers"); bool userIsBuyer = false; for (uint256 x = 0; x < songs[_id].buyers.length; x++) { if (songs[_id].buyers[x] == msg.sender) { console.log("Found buyer: ", songs[_id].buyers[x]); userIsBuyer = true; } } require(userIsBuyer, "You do not own this song."); _; } Then we can use this modifier in the getDownloadLink function, which then will be pretty simple as all the checks are done in the modifiers songExists and isBuyer: function getDownloadLink(uint256 _id) public view songExists(_id) isBuyer(_id) returns (string memory) { // return url from state mapping return songDownloadURLs[_id]; } That covers most of the smart contract code. You can find the full code in this file in the repository and even some tests that you can run locally. Creating the web app This build the web app I used Next.js with the create-next-app command. I separated it into three different pages: index: a landing page with the button to connect Metamask. dashboard: page to upload song files and metadata. browse: page to browse available songs and listen to them. As we’ll access a lot of state variables from multiple pages, like contract and wallet interfaces, so we’d need to define them in the app entry point file _app.js and use a context provider to share them throughout the rest of the pages. Dependencies Apart from the default Next.js dependencies, we’ll need to use the Bundlr library to interact with Arweave through Bundlr and TailwindCSS to help style the app. @bundlr-network/client: library documentation tailwindcss: follow installation guide here The landing page: connect wallet and fetch balance The landing page has just a button to connect the user’s wallet that will trigger the initWallet below. As we’ll be using Bundlr to interact with Arweave, we’ll actually initialize a Bundlr instance using the Metamask provider, which is injected in window.ethereum by default: let provider // set the base currency as matic const [currency, setCurrency] = useState('matic') /** * Connects user's Metamask, initialise bundlr ineterface, * contract interface and retrieves balances */ async function initWallet() { // return if Metamask is not installed if (!window.ethereum) return await window.ethereum.enable() // check if current network is ok const networkOk = await checkNetwork() if (!networkOk) return // creates an Ethers provider from Metamask provider = new providers.Web3Provider(window.ethereum) await provider._ready() console.log('Provider Ready! > ', provider) // load Bundlr endpoint from env or use testnet by default // Mainnet is: 'https://node1.bundlr.network' // Testnet is: 'https://testnet1.bundlr.network', const bundlrEndpoint = process.env.NEXT_PUBLIC_BUNDLR_ENDPOINT || 'https://testnet1.bundlr.network' // initialise Bundlr wallet instance using the same provider const bundlr = new WebBundlr(bundlrEndpoint, currency, provider) await bundlr.ready() console.log('Bundlr provider ready') // saves Bundlr instance in app state setBundlrInstance(bundlr) bundlrRef.current = bundlr // await initContractInterface() // retrieves balance from Bundlr await fetchBalance() // redirect to browse page router.push('/browse') } With the fetchBalance function we will retrieve both the Metamask balance and the Bundlr balance so we can check if the user has enough funds to upload a song. Remember that we have to transfer funds to Bundlr to actually use it. // state variables to save balance const [bundlrBalance, setbundlrBalance] = useState(0) const [balance, setBalance] = useState(0) // Retrieve the user's metamask and bundlr balances async function fetchBalance() { // gets balance from Bundlr instance initialised earlier const bal = await bundlrRef.current.getLoadedBalance() console.log('Bundlr balance: ', utils.formatEther(bal.toString())) // parse balance to ETH format and save it in app state setbundlrBalance(utils.formatEther(bal.toString())) // retrieve balance from Metamask const balance = await provider.getBalance(bundlrRef.current.address) console.log('Metamask balance : ', utils.formatEther(balance.toString())) // parse balance to ETH format and save it in app state setBalance(utils.formatEther(balance.toString())) } Dashboard page: uploading songs and listing them for sale To list a song for sale, users will need to send two transactions: First, upload the song file to Arweave through Bundlr. After that, save the song title and price in our smart contract. That means our page will have two different forms. For that, I separated them into two different components, ArweaveUpload.js and SongMetadataForm.js. The ArweaveUpload component has a simple file input which I styled a little bit with TailwindCSS classes and a button that actually uploads the file. When the user selects a file to upload, the application automatically checks the cost of uploading it to Arweave with the following method: /** * Check cost to upload file to Arweave via Bundlr */ async function checkUploadCost(bytes) { if (bytes) { const cost = await bundlrInstance.getPrice(bytes) console.log('cost is:', cost.toString()) setFileCost(utils.formatEther(cost.toString())) if (cost.isGreaterThan(bundlrBalance)) { console.log('not enough balance') } else { console.log('enough balance') } } } Once the user knows the upload cost, he/she can click the upload button which will trigger the following uploadFile function: /** * upload the file to Arweave using bundlrInstace from * global state */ async function uploadFile() { setIsLoading(true) if (!file) return const tags = [ { name: 'Content-Type', value: 'audio/mpeg3' }, { name: 'App-Name', value: APP_NAME }, ] try { if (bundlrBalance < fileCost) { console.log('Insufficient funds in Bundlr, funding...') await fundBundlr(fileCost) } let tx = await bundlrInstance.uploader.upload(file, tags) setURI(`http://arweave.net/${tx.data.id}`) setFileUploaded(true) setIsLoading(false) } catch (err) { console.log('Error uploading file: ', err) setIsLoading(false) } } /** * transfers funds from the user's Metamask wallet to * his/her correspondent Bundlr account using bundlrInstance * from global state */ async function fundBundlr(amount) { try { console.log('funding bundlr with: ', amount) const res = await bundlrInstance.fund(parseInt(amount)) console.log('fund response: ', res) } catch (error) { console.error(error) } } Notice that I’m checking if the Bundlr balance is enough to cover the upload cost and, if not, call the fundBundlr function that will send an additional transaction to transfer funds from the user’s Metamask wallet to their correspondent Bundlr account. Once the upload transaction is settled, I’m saving the songs URI in the application global state using the default Arweave domain (http://arweave.net/) and the id returned by the upload transaction. You can find all the code for the ArweaveUpload component in the following file in GiHub. Once the song is uploaded to Arweave, the next step is to list it for sale by uploading the title, price, and Arweave URL to our smart contract. For that, I created a separate component named SongMetadataForm. It just contains two inputs for the title and sale price and a button that triggers the saveFileMetadata function: /** * saves the song metadata to Smart Contract using * contract instance and URI from global state */ async function saveFileMetadata() { try { if (!URI || !title || !sellPrice) return setIsLoading(true) console.log( `Listing song ${title} for ${utils.parseUnits( sellPrice, 18 )} and URI ${URI}` ) // save info in contract const tx = await contract.listSong( title, // parses price to ETH format utils.parseUnits(sellPrice, 18), URI ) // wait for transaction to settle const res = await tx.wait() console.log('res', res) // reset everything in form setTitle('') setSellPrice('') setURI('') setFileUploaded(false) setIsLoading(false) // update global state setMetadataSaved(true) // refresh list of songs listed for sale const files = await contract.getSongs() // redirect to browse page Router.push('/browse') } catch (err) { console.log('Error saving metadata: ', err) setIsLoading(false) } } This will request the user to sign another transaction and, once settled redirect the user to the browse page. As you can see we’re also refreshing the list of songs in the global state by calling the contract.getSongs() method. Browse page: buying and listening to songs The next step is to create a browse page in which users will be able to buy songs and listen/download them. So the first thing we need is a function to retrieve all the songs listed for sale from our smart contract. It’ll look like this: export default function Browse() { const { bundlrInstance, songs, getSongs, } = useContext(MainContext) // when app loads, fetch songs useEffect(() => { if (!bundlrInstance) Router.push('/') getSongs() }, []) /** * fetchs songs listed for sale from the app smart contract */ async function getSongs() { try { console.log('Retrieving songs') const songs = await contractGetter.getSongs() setSongs(songs) } catch (error) { console.error('ERROR GETTING FILE LIST: ', error) } } return ( // Render list of songs <div className="container mx-auto grid md:grid-cols-3 gap-4 mt-12"> {songs.length > 0 && songs.map((s) => <Song song={s} key={s} />)} </div> ) As we’re calling this function from both the browse and the dashboard pages, I actually declared it in the app entry file (_app.js) and pass it down using a MainContext Provider 😉 To render each song I created a separate component named just Song.js. In it, I’m displaying the song’s title, price, the number of buyers, and a dynamic button that allows users to buy the song or, if they’ve already done it (or if they’re the author), listen to it. Here is the code: import { utils } from 'ethers' import { useContext, useState, useEffect } from 'react' import { MainContext } from '../globalContext' export default function Song({ song }) { const { contract, address, getSongs, setAppMessage, setShowAppMessage, setAppMessageIsError, } = useContext(MainContext) // tries to retrieve song URL on load useEffect(() => { getSongURL() }, []) const [isLoading, setIsLoading] = useState(false) const [songURL, setSongURL] = useState('') const [canPlay, setCanPlay] = useState(false) /** * Retrieves songURL from Arweave. Only author/buyers can * call this method of the smart contract */ async function getSongURL() { try { const songURL = await contract.getDownloadLink(song.id) console.log('songURL', songURL) setSongURL(songURL) await getSongs() userCanPlay() } catch (e) { console.log('Error retrieving song URL >> ', e) } } function accShort() { return `${song.author.slice(0, 2)}...${song.author.slice(-4)}` } /** * Check if user is author or one of the buyers */ function userCanPlay() { console.log('Checking if songs buyers include ', address) console.log('song.buyers: ', song.buyers) console.log('user address ', address) if (song.buyers.includes(address) || song.author == address) { console.log('Buyer / author found!') setCanPlay(true) } else { setCanPlay(false) } } /** * Buys song for user using the contract interface * from app global state */ async function buySong() { try { setIsLoading(true) console.log(`Buying file ${song.id.toString()}`) // trigger buySong method from smart contract const tx = await contract.buySong(song.id.toString(), { value: song.price, }) const res = await tx.wait() console.log('Transaction completed') setAppMessage('Song bought! You can listen it now 🎧🎶') setShowAppMessage(true) setAppMessageIsError(false) // refresh state to change play/buy button await getSongs() console.log('Songs refreshed') userCanPlay() setIsLoading(false) } catch (err) { console.error(err) setAppMessage('Error buying song 🤕') setShowAppMessage(true) setAppMessageIsError(true) setIsLoading(false) } } return ( <div className="p-4 border border-blue-100 hover:shadow-xl mb-4 rounded-lg flex flex-col space-y-4"> <div className=""> <h4 className="text-xl font-medium"> <span className="text-base">{song.id.toString()}</span> | {song.title} </h4> <p className="text-sm my-4">by {accShort()}</p> <p className="text-sm font-medium"> Price: {utils.formatEther(song.price)} </p> </div> {canPlay ? ( <a className="w-auto px-4 py-2 border border-transparent text-sm font-medium rounded-md text-blue-700 bg-blue-100 hover:bg-blue-200 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-blue-500" href={songURL} target="_blank" > Listen song </a> ) : ( <button className="w-auto px-4 py-2 border border-transparent text-sm font-medium rounded-md text-orange-700 bg-orange-100 hover:bg-orange-200 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-orange-500" onClick={buySong} > {isLoading ? 'In progress...' : 'Buy song'} </button> )} <p className="text-sm my-4">{song.buyers.length} buyers</p> </div> ) } And with that, we have our decentralized music marketplace ready. You can give it a try here. What’s next? This app covers the basics of how to interact with Arweave using Bundlr but there are many things that you can do to extend this app. Here are a few ideas: Improve the music player. Make the site a permaweb by deploying it to Arweave using arkb. Add a section in the dashboard with all the songs a user has uploaded. Extend the accepted currencies to stablecoins in Polygon. Deploy the contract to different blockchains like Avalanche or BNB Smart Chain and accept different cryptocurrencies. Remember that you can find the full code of this app in the following repository on GitHub, so feel free to fork it, use it for your own project, or create a PR to improve it! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Building a Web3 AI trading agent from scratch The fusion of decentralized finance and artificial intelligence is no longer a speculative trend. It is unfolding in real-time, and nowhere is this more evident than in the rise of local-first, AI-driven trading agents on Web3 infrastructure. While much of the industry focuses on plugging pre-trained models into centralized services, a new generation of builders is embracing a more sovereign path that favors control, transparency, and full-stack understanding. Let us walk through the design and implementation of a complete Web3 AI trading agent. Built from the ground up to run locally and train custom models, the system exemplifies a methodical progression from manual DeFi interaction to fully autonomous agent behavior. 🤖 Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Learn more. An AI agent built the hard way The trading agent project is not about deploying a single model or slapping GPT responses onto trading APIs. Instead, it aims to teach and operationalize a complete AI trading pipeline on the BASE blockchain using Uniswap V4. Each component is built with intentional friction: there are manual steps, infrastructure choices, and fine-tuning workflows that force a deep understanding of what a “Web3-native AI” system actually entails. The project is local-first and stack-conscious. Wherever possible, operations run on the user’s machine, from Foundry-forked chains to Ollama-served LLMs. This decentralizes not just blockchain access but also AI model inference, a critical step toward privacy and resilience in Web3 intelligence systems. Figure 1: AI trading bot development pipeline architecture; Source: GitHub Web3 infrastructure stack The agent operates on BASE – an Ethereum Layer 2 that offers low fees and high throughput. This choice provides fertile ground for rapid trade execution without incurring the overhead of mainnet Ethereum. Uniswap V4 is the AMM of choice, featuring a singleton architecture where all liquidity pools are governed by a single contract instance. This design dramatically reduces contract sprawl and improves composability. Foundry serves as the core local blockchain toolkit. By forking the BASE mainnet, users can simulate and debug real-world trading scenarios without spending funds. It’s here that strategies can be tested and tuned before going live. From general AI models to specialization Model inference is handled locally through Ollama or Apple’s MLX-LM (for M-series chips). The stack is deliberately flexible, letting developers swap in different models, quantizations, and architectures as they see fit. Figure 2: Quantization options and trade-offs; Source: GitHub The core components are: Ollama: lightweight local inference MLX-LM: training and fine-tuning on Apple Silicon Gymnasium: reinforcement learning environments PyTorch: training GANs and custom nets The architecture follows a teacher-student distillation process. A larger model like QwQ-32B generates optimized outputs, which are used to train a smaller, resource-efficient model (e.g., Qwen 2.5 3B) tailored to local inference and fast trading decisions. From manual to agentic models The development path mirrors the broader evolution of Web3 trading: Manual trading: MetaMask swaps via Uniswap Scripted bots: programmatic swaps on Uniswap V4 via Chainstack Trader Node Stateless agents: LLM-powered decisions without memory Dynamic agents: stateful logic, memory, and historical strategy tracking Each layer adds complexity but also greater expressivity. Stateless agents offer quick insights based on live data, but stateful agents bring in learned behaviors, portfolio memory, and adaptive logic. Synthetic data and model fine-tuning Data scarcity in on-chain finance is a real challenge. To address this, the project uses GANs (Generative Adversarial Networks) to create synthetic ETH/USDC swap sequences modeled after Uniswap V4 behavior on BASE. These generated sequences are then validated and used for fine-tuning. The training loop includes positional encoding, multi-head attention, and transformer-based GAN architectures, allowing the models to internalize the temporal logic of market actions. For stability, Wasserstein GAN with Gradient Penalty is used, with additional techniques like gradient penalty, minibatch discrimination, and diversity loss. Figure 3: Gradient penalty in WGANs; Source: Arxhiv Knowledge compression via distillation Once synthetic data is generated, the distillation process begins. The system uses OpenRouter to access large teacher models like QwQ-32B and guides the training of a smaller model. Key here is the “Chain of Draft” approach—short, structured reasoning steps that improve inference time and preserve logical flow. The result is a lightweight, fine-tuned model that internalizes trading logic without relying on external APIs. Canary words such as “APE IN” (buy) and “APE OUT” (sell) verify that the trained model has truly absorbed task-specific knowledge rather than mimicking generic LLM behavior. AI reinforcement learning and strategy The final layer is a reinforcement learning module using Deep Q-Networks (DQN). The RL agent trains in a Gymnasium environment specifically designed to simulate Uniswap V4 market dynamics. Its reward structure balances profit optimization with risk and transaction costs. What’s particularly noteworthy is the reuse of RL decisions to further fine-tune the LLM. By converting the RL agent’s trade decisions into conversational prompts, the model gains another layer of training—a technique that fuses symbolic learning with language-based reasoning. Fusing the AI model and running the agent The final LoRA adapter, containing all the learned weights, is fused into the base model and optionally converted into GGUF format for Ollama. This creates a self-contained, production-ready model that can be served locally for real-time inference. Agents are launched through Python scripts that cycle through market evaluations, prompt the LLM, analyze rebalancing thresholds, and submit swap transactions on-chain. Whether operating in a dry-run fork or on BASE mainnet with Chainstack nodes, the agent retains full transparency. You can find the full project repo here. Building, not consuming This project isn’t about outperforming hedge funds or launching the next HFT unicorn. It’s about understanding. By walking through each step of AI trading agent construction, developers learn the nuances of on-chain data, trading strategy formulation, LLM behavior, and data generation theory. In a world increasingly flooded with opaque AI services and centralized automation, this project offers something radical: sovereignty over your stack. Whether you use it to learn, to experiment, or to deploy a custom system, the blueprint is now open. Browse the repo Explore the docs Watch the video Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### CBDCs on Chainstack: Leveraging enterprise-grade infrastructure in development  Central Bank Digital Currencies (CBDCs) are revolutionizing the financial landscape, offering increased efficiency, security, and accessibility in monetary systems. As central banks and financial institutions around the world explore the potential of CBDCs, reliable and secure infrastructure solutions become crucial for the effective development and implementation of these digital currencies.   In this article, we delve into the diverse use cases of CBDCs and how Chainstack’s cutting-edge infrastructure empowers organizations to launch, manage, and scale their CBDC projects with ease. From modular and auto-scalable infrastructure to seamless mobile wallet integration, Chainstack provides the tools and support needed for successful CBDC adoption.  What are CBDCs?  Central Bank Digital Currency (CBDC) is a digital form of a country’s fiat currency, issued and controlled by its central bank. Unlike cryptocurrencies such as Bitcoin, which operate in a decentralized manner, CBDCs are centralized and regulated, maintaining the stability and trust associated with traditional currencies. CBDCs are designed to offer the benefits of digital currencies, such as faster transactions, lower costs, and increased financial inclusion, while mitigating the risks and volatility often associated with cryptocurrencies.  As governments and central banks explore the adoption of CBDCs, the need for robust and secure infrastructure becomes paramount. Chainstack’s CBDC infrastructure solutions address this need, offering a suite of tools and services that help central banks, financial institutions, and enterprises to launch, manage, and scale their CBDC networks effectively. By leveraging Chainstack’s cutting-edge infrastructure, organizations can ensure a smooth transition to CBDC and harness the full potential of digital currencies in improving the efficiency, security, and accessibility of their monetary systems.  Why CBDCs?  CBDCs are gaining traction worldwide as governments and central banks recognize the potential benefits of leveraging digital currencies in their monetary systems. Here are some key reasons why CBDCs are becoming an essential consideration for modern financial ecosystems:  Faster transactions: CBDCs enable quicker, more efficient transactions compared to traditional payment methods. By eliminating the need for intermediaries, CBDCs can significantly reduce transaction times and costs, facilitating smoother domestic and cross-border payments.  Increased financial inclusion: CBDCs can help bridge the gap between the banked and unbanked populations. By providing a digital alternative to cash, CBDCs can offer access to financial services for individuals who are currently underserved by traditional banking systems.  Enhanced security: CBDCs leverage the security features of blockchain technology, making them more resilient to cyber-attacks and fraud. This heightened security can help protect both consumers and financial institutions from potential risks and losses.  Greater transparency: The use of CBDCs can increase transparency in the financial sector by providing real-time data on transactions and monetary flows. This improved visibility can assist in detecting illegal activities and enabling more effective regulatory oversight.  Reduced reliance on physical cash: The adoption of CBDCs can help reduce the dependence on physical cash, which can be expensive to produce, store, and transport. By offering a digital alternative, CBDCs can potentially lower the costs associated with cash management and circulation.  Monetary policy implementation: CBDCs can provide central banks with new tools for implementing monetary policy, including the ability to apply negative interest rates or conduct more targeted interventions in the financial system.  Interoperability: CBDCs can be designed to interoperate with existing financial ecosystems, making it easier for individuals and businesses to transition between digital and traditional currencies seamlessly.  As the interest in CBDCs continues to grow, Chainstack’s CBDC infrastructure solutions offer a robust and secure platform for central banks, financial institutions, and enterprises to develop and deploy their CBDC networks. By capitalizing on Chainstack’s expertise and cutting-edge technology, organizations can successfully navigate the challenges of CBDC implementation and harness the full potential of digital currencies in the modern financial landscape.  What types of CBDCs are there?  CBDCs can be classified into two main types: retail CBDCs and wholesale CBDCs. Retail CBDCs are designed for use by the general public, providing a digital alternative to cash for everyday transactions, while wholesale CBDCs are intended for use by financial institutions for interbank settlements and large-value transactions. When it comes to their design, they can be account-based and digital tokens:  Account-based CBDCs  Account-based CBDCs, also known as central bank electronic money, function similarly to general deposit accounts. Users set up an account that allows them to conduct transactions, send, and receive digital currency. These CBDCs require user identity verification for transactions, ensuring compliance with Know Your Customer (KYC) procedures.  Digital tokens  Digital token-based systems involve the transfer of objects of value between wallets. Unlike account-based CBDCs, digital tokens do not rely on user identity verification for sending and receiving payments. Transactions with digital tokens are authenticated using public-private key pairs and digital signatures between the sender and receiver. However, digital tokens face challenges, such as the lack of identity requirements and the potential loss of assets when tokens are misplaced.  Retail CBDCs  Retail CBDCs are used for payments between businesses and individuals or between individuals. They function as digital versions of conventional currency notes and are generally associated with low-value transactions. Retail CBDCs can be account-based or digital tokens.  The demand for retail CBDCs is driven by inefficiencies and complexities in existing electronic retail payment systems. Retail CBDCs can simplify transaction processes, improve transparency, and reduce transaction costs, particularly in cross-border payments.  Wholesale CBDCs  Wholesale CBDCs facilitate payments and settlement of transactions among financial institutions. While banks can already directly access electronic central bank money, wholesale CBDCs can improve efficiency and risk management in the settlement process. Wholesale CBDCs enable more financial market participants, including those who cannot currently hold central bank accounts, to access CBDCs.  Additionally, wholesale CBDCs can be used for asset transfers involving securities. For instance, two parties trading a security for cash could use a wholesale CBDC for instant payment and delivery of the asset.  Figure 1: A detailed comparison between Retail & Wholesale CBDC; Source: 101 Blockchains  What are some example use cases for CBDCs?  Central bank digital currencies (CBDCs) are being explored and tested by various countries for different use cases in the financial services sector. Some of the most promising CBDC applications include cashless retail payments, cross-border payments, programmable money, and virtual asset transactions.  Cashless retail payments  One of the primary use cases for CBDCs is facilitating cashless retail payments. For instance, the National Bank of Ukraine conducted a survey exploring the potential introduction of a CBDC-based system called e-hryvnia, which aims to support cashless retail payments. CBDCs in this context provide a reliable alternative to cash, not a replacement, and offer faster and more secure electronic transactions.  Cross-border payments  CBDC use cases also extend to cross-border payments, where they can significantly reduce transaction costs and increase the speed of international transactions. By leveraging the interoperability of CBDCs with foreign CBDCs or multi-CBDC platforms, cross-border payments could become more efficient, further promoting global economic integration.  Programmable money  Programmable money is another compelling use case for CBDCs. With the integration of smart contract technology, CBDCs can enable programmable payments, which can automatically execute transactions based on predefined conditions. This functionality can streamline various financial processes, such as the automatic payment of taxes, dividends, or other obligations, and lead to the development of more complex financial products.  Virtual asset transactions  Finally, CBDCs can be employed in virtual asset transactions, providing a secure and efficient means of transferring digital assets. This application can support the growth of emerging industries, such as cryptocurrencies and digital securities, by providing a stable and widely accepted digital currency for transactions.  In conclusion, CBDCs offer various use cases that can revolutionize the financial sector by providing a reliable alternative to cash, supporting digitization, and enabling advanced functionalities such as programmable payments and seamless cross-border transactions. As more countries explore the potential of CBDCs, it is likely that additional use cases will emerge, further shaping the future of digital currencies and the global financial landscape.  Launch your CBDC infrastructure with Chainstack  Embracing the future of national money is now more accessible than ever, thanks to Chainstack’s CBDC infrastructure solutions. Our platform is designed to support central banks, financial institutions, and enterprises in launching, managing, and scaling their CBDC networks with ease. Here’s how Chainstack can facilitate the effective development of your CBDC project:  Robust security: Our CBDC infrastructure nodes are built using the latest security protocols and best practices, ensuring that your CBDC network is safeguarded against cyber threats and attacks.  High performance: Chainstack’s infrastructure is optimized for speed and scalability, enabling you to handle high transaction volumes and support the growing user demand for digital currencies.  Flexibility and customization: Our platform can be tailored to meet your specific needs and requirements, whether you’re launching a new CBDC network or upgrading an existing one.  24/7 support: Our team of experts is available around the clock to provide technical support, troubleshooting, and advice, ensuring that your CBDC project runs smoothly and efficiently.  Easy integration: Chainstack’s nodes can be seamlessly integrated with other systems and platforms, including existing blockchain networks, databases, and APIs, facilitating a smoother transition to a CBDC ecosystem.  Rapid deployment: With Chainstack, you can launch your CBDC infrastructure in just a few clicks. Our platform automates the deployment process, allowing you to focus on building innovative CBDC applications while reducing time to market.  Cloud provider integration: Our platform’s integration with leading cloud providers enables you to launch your blockchain nodes on your preferred cloud provider in just a few minutes, ensuring a scalable and reliable infrastructure for your CBDC network.  By leveraging Chainstack’s CBDC infrastructure solutions, you can be confident in the success of your CBDC project. Our platform offers a range of benefits that will help you save time, reduce costs, and achieve your goals. Contact us today to learn more about our CBDC infrastructure services and discover how we can help you take your CBDC project to new heights.  Deploy blockchain networks in minutes with flexible and robust infrastructure  Embrace the future of CBDCs with Chainstack’s cutting-edge platform, which supports a wide range of blockchain networks, including Ethereum, Polygon, BNB Smart Chain, Avalanche, Arbitrum, and 20 others. Our platform offers flexibility, speed, and reliability for launching your CBDC infrastructure in just a few clicks.  Additionally, our platform also supports app chains such as Avalanche Subnets, Polygon Supernets, BNB Application Sidechains, and StarkEx Apps, offering flexibility, speed, and reliability for launching your CBDC infrastructure in just a few clicks.  To accommodate various use cases and requirements, Chainstack offers a diverse range of hosting options:  Chainstack-managed: Gain instant access to a fully-managed blockchain as a service, with an intuitive user interface, powerful orchestration capabilities, and white-label branding available on the Enterprise tier. No need to host or manage any software components yourself.  Chainstack Cloud: Maximize node performance with robust cloud infrastructure designed for handling resource-heavy operations. Ideal for DeFi, GameFi, and NFT applications, Chainstack Cloud offers lightning-fast network interactions and minimal latency.  Hybrid: Choose which components of the Chainstack infrastructure you’d like to manage and operate yourself while letting Chainstack take care of the rest. This option is perfect for customers concerned about self-sovereignty but don’t want to build their own tools for orchestration.  Self-hosted: License a self-hosted Chainstack solution to have full control over operating every component yourself. Great for clients interested in fully hosted solutions who have the capabilities to manage everything in-house.  In addition to supporting a wide range of blockchain networks, Chainstack seamlessly integrates with leading cloud providers, enabling you to launch your blockchain nodes on your preferred cloud provider in just a few minutes. This ensures your CBDC infrastructure is scalable, reliable, and ready to handle growing user demand.  Experience the power and flexibility of Chainstack’s platform as you develop and deploy your CBDC infrastructure with ease. Accelerate your CBDC project today with Chainstack’s versatile, user-friendly, and performance-driven solutions.  Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### CertiK slashes Ethereum archive costs by 70%+ while fortifying Web3 security Securing the Web3 ecosystem with comprehensive audits and real-time monitoring Working with Chainstack helped us cut our infrastructure costs by over 70%, all while tackling intricate challenges in Web3 security. They’ve been an invaluable asset every step of the way. Map Shen, Head of Platform at CertiK In the context of recent history’s digital transformation and the even more recent rise of blockchain technology, cybersecurity has taken on unprecedented importance. While blockchain technology offers elegantly simple solutions to complex problems, it also harbors intricate complexities—complexities that can sometimes lead to security vulnerabilities. Innovators like CertiK have emerged precisely because of these challenges. Established in 2018 by professors of computer science from Columbia and Yale, CertiK has rapidly become a cornerstone in blockchain security. Its foundational mission is to deliver uncompromising security solutions for the rapidly expanding Web3 ecosystem. CertiK specializes in exhaustive smart contract audits and provides innovative security tools such as Skynet. These initiatives are laser-focused on eradicating vulnerabilities and bolstering security protocols, all while fostering trust and reliability in the Web3 environment. Join us for an in-depth exploration as we scrutinize CertiK’s offerings, examine its challenges, and reveal the instrumental role of Chainstack. What is CertiK? CertiK stands as a major player in blockchain security, fortified by an expert team passionate about raising the standard of security and transparency across the Web3 world. Their comprehensive service suite ranges from meticulous smart contract audits to real-time monitoring via proprietary tools like Skynet. Central to CertiK’s operations is an exhaustive smart contract auditing process. Utilizing a unique methodology that combines thorough manual reviews with mathematical models, including formal verification, they identify vulnerabilities in blockchain code. Their rigorous approach has enabled the auditing of more than 4,460 projects, uncovering over 68,000 security issues. Beyond smart contracts, CertiK also specializes in auditing Layer 1 chains, paying close attention to underlying protocols. This holistic approach strengthens the security of entire blockchain ecosystems. Further augmenting their services, CertiK conducts robust Web3 penetration testing. This strengthens the security of wallets, exchanges, and DApps, while adhering to industry standards such as OWASP. Figure 1: Sample CertiK penetration test audit segments; Source: CertiK CertiK solutions beyond the audit stack A standout feature is Skynet, CertiK’s comprehensive security analysis platform. Operating continuously, Skynet monitors both on-chain and off-chain data, assisting projects in improving their security metrics and building community trust. Skynet is an advanced asset monitoring tool. With customizable alerts and round-the-clock support, Skynet empowers clients with unparalleled control over their digital assets. CertiK also emphasizes education, offering learning resources and risk detection tools that equip clients to preempt market risks effectively. In summary, CertiK serves as a blockchain security powerhouse, providing a broad array of services—from in-depth audits to real-time monitoring and educational resources. Figure 2: Sample CertiK Skynet dashboard and Security Score; Source: CertiK Why CertiK chose Chainstack as its RPC provider CertiK had already established a proven track record for itself. The challenge for us was to stand out among the other RPC providers they had previously engaged with. Our broad protocol support, reliable archive nodes, and exceptional price performance had initially caught CertiK’s attention based on positive reviews they had heard from their industry peers. Understanding the specific challenges CertiK faced, we realized that Chainstack’s offerings could be the perfect solution. Our pricing model and our highly-scalable archive nodes stood out as distinctive advantages and despite the fierce competition from renowned RPC providers, our value proposition resonated with CertiK’s needs. A critical component was our proactive move: repositioning the request units (RUs) CertiK required from full nodes to archive nodes, even before our new pricing model was officially rolled out. This flexibility, combined with our transparency in showcasing the true benefits of our services, was instrumental. As a result, CertiK recognized Chainstack as the right partner for them. Since forging this partnership, we’ve been collaborating more closely, unlocking new opportunities like exploring additional services such as Subgraphs. From a customer perspective, this partnership with CertiK means they can now offer a sturdier product portfolio to their clients, reinforce their security measures, and broaden their business horizons—all thanks to efficient cost modeling and our committed support. We take great pride in enabling CertiK to fully utilize the capacity of our platform and seeing them grow. CertiK on Chainstack in numbers What does the Chainstack and CertiK partnership look like in numbers? Let’s illustrate our story with usage stats accordingly. CertiK operates a significant number of 26+ active Chainstack Global Nodes, harnessing not one, but eight blockchain protocols. The traffic across these protocols is also spread out relatively evenly, with Arbitrum dominating with 2B+ requests, followed by Polygon in second place with half that at around 1.2B+, BNB Smart Chain in close third, sitting at 1B, plus Avalanche and Bitcoin together at 1B as well. Ethereum, Fantom, and Solana form the tail for a tally of approximately half a billion. The interplay between Chainstack and CertiK isn’t just diverse in the protocols used but also in geographic reach. Requests came in from several regions, including Ashburn, Dallas, multiple EU-based locations, and US East. The most significant requests came from the EU3 region, with a whopping 2.5B+ calls, then Dallas with 1.5B+, followed by Ashburn and London with roughly 1B+ each. Trailing at the back are France, US East, EU1, and Amsterdam, together forming a segment of just under half a billion as well. Our relationship with CertiK is not just about providing a service; it’s about empowering them to optimize their offerings and explore new lines of business. It’s crucial to us that CertiK can provide high-quality products backed by our reliable RPC infrastructure and the best measure of success is not just about what we do for CertiK, but about what CertiK has achieved using Chainstack infrastructure. Conclusion The Web3 space is fraught with security challenges, and CertiK’s work stands as a vital countermeasure. Our collaboration with them has not only resolved specific issues but also offered broader lessons for both parties. At Chainstack, we believe every challenge is an opportunity for growth and learning. This collaboration with CertiK is a testament to that belief — proof that no hurdle is too high when we put our joint efforts towards a solution. Navigating the world of Web3 security is no easy task. But with our collaborative efforts and commitment to providing holistic security solutions, we’re more confident than ever about our shared journey towards fostering a secure and vibrant Web3 ecosystem. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainlink VRF Tutorial with Foundry – How To Use Chainlink’s VRF Table Of Contents- • Introduction• Installing Foundry• Installing dependencies with forge• Setting up Remappings in Foundry• Creating a VRF Subscription• Writing the Smart Contract• Scripting in Foundry• Setting up our dotenv File• Deploying the Smart Contract• Fetching Random Values from VRF• Conclusion Introduction Foundry is one of the latest smart contract development toolchains currently in the market, and it allows users to compile contracts, write tests, deploy contracts, and much more through its command line interface. Foundry is written in Rust and promises faster compilation times and the convenience of writing tests and deployment scripts in Solidity, rather than JavaScript. Many Solidity developers have been looking forward to this for a long time since this will allow people to write smart contracts and their corresponding tests without having to switch between languages.Moreover, this would save people time and effort by no longer needing to learn JavaScript and Solidity. If you’re familiar with Hardhat, we have an article covering the main differences between the two in performance and developer experience. This article will teach you the basics of working with Foundry by building a smart contract that consumes Chainlink’s VRF (Verifiable Random Function). The smart contract will use a pre-paid ‘subscription’ to use Chainlink’s VRF services. We will compile, deploy, and verify our smart contract using Foundry, straight out of the command line. Without any further delays, let us get started. How To Install Foundry? To install Foundry, Linux and MacOS users can open their terminal and run- curl -L https://foundry.paradigm.xyz | bash This will download Foundryup. To install Foundry, run- foundryup If everything is installed correctly, your terminal will look like this- Windows users may need to download Rust before proceeding with the installation. If you face any issues during installation, you can refer to the official Foundry documentation.Once this is done, create an empty directory where you would like to set up your Foundry project. Open the directory in VS code, and then open the terminal.Run the command ‘forge init’ to initialize a Foundry project in the empty directory. Installing Dependencies with forge By default, Foundry manages installed dependencies as submodules, which means any GitHub repository can be directly installed as a dependency without having to use a package manager like npm or yarn, even though Foundry supports that too. So what exactly are we installing? To fetch random data from Chainlink, our deployed smart contracts need to be structured in a way that is compatible with Chainlink’s on-chain smart contracts. To do that we will need to import a few interfaces and smart contracts into our Solidity code.To do that we will be installing a repository that contains only Chainlink’s smart contracts. You can check out the repository on Github.We will install the repo into our project using the forge command. In your terminal, run- forge install smartcontractkit/chainlink-brownie-contracts The same command could be run by passing the exact URL of the repo instead of just the Github path. This will result in Foundry cloning the whole repo into our ‘lib’ folder. Setting up Remappings in Foundry While working with Foundry in VS Code, it is recommended that we precisely point Foundry towards the path of our installed dependencies. By default, Foundry makes some deductions. To check out those default remappings, run this command in your terminal- forge remappings This should show you the exact paths of the packages that we are using with Foundry, alongside the path of the Chainlink repo we installed.However, we wish to set up a custom remapping for our Chainlink repo. In your terminal, run- forge remappings > remappings.txt This will create a ‘remappings.txt’ file in your root directory and will fill it up with the default remappings that Foundry has. Add this line to your remappings file-chainlink/=lib/chainlink-brownie-contracts/contracts/src/ All the files that we will need to inherit from Chainlink reside in the ‘src’ folder of our Chainlink library. Remapping our dependencies like this will make it easier to import those files into our Solidity code later.To verify that Foundry has saved your new remapping, run the ‘forge remappings’ command once more. Your terminal should look something like this- How To Create a VRF Subscription? Chainlink’s VRF V2 service charges a small amount of LINK tokens for every randomness request. Chainlink’s subscription manager lets us create a ‘subscription’ and fund it with a set amount of LINK tokens. Only contracts authorized by the owner of that subscription can use that subscription to request randomness. We can authorize multiple contracts on a single subscription, which not only makes this process more convenient but also saves us gas since we are funding a subscription with a significant amount of LINK tokens in one go. To create a Chainlink VRF subscription on the Goerli testnet, follow these steps- Go to faucets.chain.link and connect your wallet to the page. Now you can make a request for some LINK and ETH tokens. Make sure that your Metamask is connected to the Goerli Testnet. Go to vrf.chain.link and connect the wallet with some Goerli ETH and LINK tokens to the website. Click on ‘Create Subscription’. Make sure that the subscription address is the same wallet address that has the required tokens. Now click on ‘Create Subscription’ and approve the Metamask transaction. Once this transaction is confirmed, add a few LINK tokens to the subscription. This is known as ‘funding the subscription. Chainlink will then allow you to authorize contract addresses that can consume VRF data through your subscription, but we will add that address later. This is what your VRF homepage should look like- Congrats! You now have your very own VRF subscription that you can use to fund the VRF requests that your smart contracts make. Writing the Smart Contract With our VRF subscription ready and our dev environment set up, we are now finally ready to write the smart contract code.Open the code editor where you set up your dev environment. Inside the src folder, create a new file:chainlinkVRF.sol Chainlink VRF example – Paste the following code inside the file // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "chainlink/v0.8/interfaces/VRFCoordinatorV2Interface.sol"; import "chainlink/v0.8/VRFConsumerBaseV2.sol"; contract VRFv2Consumer is VRFConsumerBaseV2 { VRFCoordinatorV2Interface COORDINATOR; // Your subscription ID. //hardcoded into the constructor uint64 s_subscriptionId; // Goerli VRF v2 coordinator address address vrfCoordinator = 0x2Ca8E0C643bDe4C2E08ab1fA0da3401AdAD7734D; // The gas lane to use, which specifies the maximum gas price to bump to. // Higher gas lane means higher price and lower confirmation times, // mainnets on chainlink VRF typically have multiple gas lanes, // but Goerli only has one gas lane. For more details, // see https://docs.chain.link/docs/vrf-contracts/#configurations bytes32 keyHash = 0x79d3d8832d904592c0bf9818b621522c988bb8b0c05cdc3b15aea1b6e8db0c15; //Goerli has a max gas limit of 2.5 million, //we'll cap out at 200000, enough for about 10 words uint32 callbackGasLimit = 200000; // The default is 3, but you can set this higher. uint16 requestConfirmations = 5; // Cannot exceed VRFCoordinatorV2.MAX_NUM_WORDS. //maximum number of random values is 500 for Goerli Testnet uint32 public numWords = 3; uint256[] public s_randomWords; uint256 public s_requestId; address s_owner; constructor(uint64 subscriptionId) VRFConsumerBaseV2(vrfCoordinator) { COORDINATOR = VRFCoordinatorV2Interface(vrfCoordinator); s_owner = msg.sender; s_subscriptionId = subscriptionId; } // Assumes the subscription is funded sufficiently. function requestRandomWords() external onlyOwner { // Will revert if subscription is not set and funded. s_requestId = COORDINATOR.requestRandomWords( keyHash, s_subscriptionId, requestConfirmations, callbackGasLimit, numWords ); } function fulfillRandomWords( uint256, /* requestId */ uint256[] memory randomWords ) internal override { s_randomWords = randomWords; } //function to change the number of requested words per VRF request. function changeNumOfWords(uint32 _numWords) public onlyOwner { numWords = _numWords; } modifier onlyOwner() { require(msg.sender == s_owner); _; } } A few things happened here. Let us quickly go over the important points to note in the code- Notice the Chainlink imports at the top. We didn’t have to specify the exact path of the files we are importing, since we had already defined it in the ’remappings.txt’ file. This makes importing files into our code cleaner.The subscription ID is the unique identifier of our subscription and is passed as a parameter in the constructor.Each VRF-supported chain has a unique contract address representing the main VRF V2 smart contract. This address is passed to both the inherited interface as a reference later. A key hash address is basically a measure of how much gas you are willing to pay to process your requests. The higher the ‘gas lane’, the quicker will your requests go through. Do note however that not every chain has high-speed gas lanes. Chainlink supports only one gas lane, whereas the Ethereum mainnet supports multiple gas lanes. You can read more about the exact specifications for each network from Chainlink’s official documentation. To supply random values to your smart contract, Chainlink basically uses a fallback function. We need to supply an adequate amount of gas so that our call does not fail. The exact amount of gas required can vary wildly depending on the instantaneous chain activity, but you can check out some rough estimates in the code’s comments. As a rule, you will be charged for the work already done if your callback function fails due to a lack of gas.The ‘requestConfirmations’ variable represents the number of block confirmations we want to wait for before accepting the returned random values from Chainlink. The higher this number, the more secure your data is. However, there are constraints placed upon the value of this variable, and you can read about the exact details in the docs. ‘requestRandomWords()’ sends a request to Chainlink’s V2 coordinator for a supply of random words. Every single one of these requests has a unique ID. The ‘fulfillRandomWords()’ function uses this unique ID to fetch our Random data. The last function simply manipulates the ‘numWords’ variable so that we can change the number of random values we can ask for in a single call. Once your contract is ready, save the files and run this command in the terminal- forge build This will compile all your contracts and generate ABIs for them. Scripting in Foundry Once our contracts have been successfully compiled, we need to create a simple script to deploy our contract. Under the ‘script’ folder, create a new file by the name of ‘chainlinkVRF.s.sol’. Inside the file, paste the following code- // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.0; import "forge-std/Script.sol"; import {VRFv2Consumer} from "src/chainlinkVRF.sol"; contract ChainlinkScript is Script { function setUp() public {} function run() public { vm.startBroadcast(); VRFv2Consumer VRFv2 = new VRFv2Consumer(1810); vm.stopBroadcast(); } } We don’t do a whole lot here. We first import the Script.sol contract from Foundry, which allows us access to all the scripting functionalities supported by Foundry. Secondly, we import our smart contract. Scripts are by default executed within the function run(). The two broadcast functions record any transactions happening between the two calls and record them to a special file. One thing to note here is the constructor we are passing to our smart contract. If you look carefully at the code, the ID of our Chainlink subscription is passed as a parameter. Copy the subscription ID from the subscriptions page and pass it as the parameter to your contract.Lastly, we create a new instance of our contract, which serves as the deployment command.We now have a script ready to run, but we still need to define our environment variables to correctly deploy our smart contract. Setting up our dotenv File This is the last thing we need to do before getting started with our smart contract. To deploy our smart contract, we will need to pass a few environment variables to Foundry. We could do this directly in the command line while deploying our contract, but it is recommended that we do so in a dotenv file. This way our sensitive data remains secure.In your terminal, make sure you are pointing to the root directory, and run the following command- touch .env This will create an empty dotenv file in your directory. Now we need to get some credentials to put into our dotenv file. Here’s how to do that- RPC URLs are needed to connect to the blockchain. You can either host your own node or connect to the blockchain using the RPC URL for the blockchain network you want to use. In this example, we are going to use Ethereum’s Goerli Testnet. You can either use a public Goerli RPC URL or Chainstack’s dedicated node provider service. That’s what I am doing here. Using Chainstack allows us to deploy our contracts and interact with them much more quickly and reliably. Get started from our signup page. A private key is what enables Foundry to access the tokens needed to be used as gas fees to deploy our contract. Pass in the private key for any of your accounts with some Goerli testnet tokens. Lastly, you need to go to Etherscan and sign up for an account if you haven’t already done so. Then create an Etherscan API key and paste it here. You will need this to verify the contract. In the end, your dotenv file should look something like this- RPC_URL=https://mc-12.p123yippy.com/12ase525c5012 PRIVATE_KEY=dlhj12342kjh4eslkh1pq4h1324kqwrekhwe ETHERSCAN_API_KEY=SDJKASL232KJ3SQINA11A5KQIUALKJ234G2CAEWYND Do note however that the keys shown here are fake and are displayed this way for your convenience. After configuring the dotenv file, save it once. Then open the terminal again, and run the command- source .env This command allows us to load our environment variables from the dotenv file to the terminal.Now we are finally ready to deploy our contract. Deploying the Smart Contract In your terminal, execute the following command- forge script script/chainlinkVRF.s.sol:ChainlinkScript --rpc-url $RPC_URL --private-key $PRIVATE_KEY --broadcast --verify --etherscan-api-key $ETHERSCAN_API_KEY -vvvv This command tells forge to run our script on the Goerli Testnet, and to verify our contract immediately after running the script. Please note that it may take a while to complete this transaction if the network is busy. You can mitigate some of that time if you are using a dedicated node.Also, the ‘-vvvv’ flag represents the amount of verbosity, i.e- the amount of details, you want in your transaction logs. Foundry allows us different levels of verbosity.Once your transaction is through, your terminal should look something like this- Open the goerli.etherscan URL and open the contracts page. You will see that your contract has already been verified, and that you can call your functions directly from the contract page. Your browser should look something like this- Fetching Random Values from VRF Congratulations on deploying a VRF-compatible smart contract. This smart contract is now capable of requesting provably random values from Chainlink. However, we still need to allow our smart contract access to the subscription we made earlier. Open your browser and go back to vrf.chain.link .Click on the subscription ID you passed to the contract as the constructor argument at the time of deployment. Copy the address of the deployed smart contract and add it as an authorized consumer of this subscription. This is what your screen should look like. Once this transaction is done, go to the write section of your verified contract page. Connect your Metamask wallet to Etherscan. Again, make sure it is the same wallet you deployed the contract with.Call the function ‘requestRandomWords’ and approve the transaction. This process takes a while. Chainlink not only generates a random number for us, but it also verifies its authenticity on-chain, and that takes a while to process. After a few minutes, go to the read section of your contract, and call the ‘s_randomWords’ variable by passing 0 as the array index. Note that Chainlink will return an array of random uint256 numbers whose length will be equal to the value of the ‘numWords’ variable.This is what your screen should look like. You can now use these random numbers in any of your projects without having to worry about the reliability of these values. Conclusion And that’s it. Congratulations if you made it this far. In this tutorial, we used Foundry to compile and deploy a smart contract to the Goerli Testnet. The contract I deployed can be found on etherscan. Feel free to check out Chainstack’s official blog for some other cool tutorials.Happy coding! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack + Ormi: Powering in TVL with subgraph infrastructure “Chainstack is what you see, what you get — enterprise-grade, high performance. It’s good to know that Chainstack has got our back.” — Victor Fei, Founder & CEO of Ormi The blockchain infrastructure landscape is maturing rapidly. As institutional players enter the space and AI agents begin handling financial transactions, the requirements for reliability, performance, and data accuracy have become non-negotiable. In this environment, two industry leaders — Chainstack, a veteran node provider with 8 years of experience, and Ormi, a specialized real-time blockchain data platform — announced a strategic partnership that reflects how the industry is evolving toward deeper specialization. The partnership between Chainstack and Ormi centers on subgraph infrastructure built for production-scale blockchain applications, where reliability, performance, and data accuracy are non-negotiable. Who is Ormi? Ormi is a real-time blockchain data platform specializing in subgraph infrastructure for high-throughput blockchain data indexing. The company provides the infrastructure that allows Web3 applications to query blockchain data quickly and reliably — powering everything from DeFi protocols to high-frequency trading platforms. Founded three years ago by Victor Fei, who previously worked on the Chromium browser kernel at Microsoft and studied semiconductor optimization at Cornell, Ormi focuses on solving one critical problem: extracting and serving blockchain data at scale. The platform currently supports over $50B in TVL across applications, processes$100B+ in transactions annually, and maintains 99.99% uptime across 70+ blockchain networks. Ormi’s core focus is solving the “read path” problem — extracting data from blockchains efficiently. While much attention in Web3 goes to the “write path” (executing transactions), the reality is that without fast, accurate indexing, applications simply can’t function regardless of transaction speed. Why Chainstack partnered with Ormi for subgraph infrastructure After launching Chainstack Subgraphs two years ago and gaining substantial traction, the company made a strategic decision in 2025: go laser-focused on nodes. The goal was clear — become the household name for blockchain node infrastructure, whether elastic, dedicated, cloud, hybrid, or on-premise. This specialization required finding a partner with deep expertise in subgraph infrastructure, capable of operating reliably at production scale. Ormi fit perfectly. “We just want to do whatever we do the best. We want to be the household name when you associate with blockchain nodes. Ormi popped up because they are hyper-specialized on subgraphs, and they just do this, and nothing else.” — Eugene Aseev, Co-Founder & CTO of Chainstack The migration wasn’t about offloading a product line — it was about ensuring customers received the absolute best service. In an industry where even 5 minutes of downtime can have serious consequences for financial applications, having a specialized partner meant customers would get dedicated expertise rather than divided attention. Chainstack’s infrastructure serves as the foundation for Ormi’s indexing, while Ormi handles the complex data extraction and serving layer. It’s a natural division of labor that plays to each company’s core strengths. How Ormi benefits from Chainstack’s RPC infrastructure For Ormi, the partnership solved a critical challenge: roughly 80% of subgraph infrastructure uptime depends on RPC performance and accuracy. Building and maintaining production-grade node infrastructure in-house requires a dedicated team to handle constant updates, edge cases, and the operational complexity that comes with supporting multiple blockchain protocols. “A core component of indexing for subgraph for uptime is actually nearly 80% RPC performance, RPC accuracy. There is no way that we would have not given the primary RPC usage to Chainstack.” — Victor Fei, Founder & CEO of Ormi The numbers tell the story of why this partnership works: Chainstack’s infrastructure processes over 500 billion requests through their Full and Archive nodes, maintains 99.99% uptime across all supported networks, and operates with SLA-backed guarantees 24/7. This reliability forms the foundation that allows Ormi to focus on what they do best — transforming blockchain data into queryable formats for applications. Ormi had run their own nodes initially, but recognized that sustainable growth meant focusing resources on their core competency — real-time blockchain data indexing. Partnering with Chainstack’s battle-tested node infrastructure allowed them to allocate engineering resources toward improving indexing performance rather than maintaining node operations. The technical synergy is clear: Chainstack provides the reliable data source, while Ormi transforms that raw blockchain data into accessible, queryable formats that applications need. Both companies can innovate faster in their respective domains without being stretched thin across the full infrastructure stack. Key insights for blockchain developers Indexing is Core Infrastructure, Not OptionalBlockchain nodes were designed for consensus, not serving data at scale. They use file-level databases optimized for block generation and peer-to-peer coordination, not high-throughput data queries. Modern applications require specialized indexing infrastructure that can handle thousands of requests per second reliably. Production Requirements Have Evolved DramaticallyThe industry has moved past the “experimental technology” phase. With real financial assets, institutional players, and AI agents on-chain, infrastructure downtime has concrete consequences. Missing a single transaction can impact user balances, point distributions, or trading outcomes. The tolerance for errors has dropped to near-zero. Specialization Beats GeneralizationThe partnership illustrates a broader trend: successful infrastructure companies are going deep rather than wide. Trying to be excellent at nodes, indexing, analytics, and other layers simultaneously spreads engineering resources thin. Companies that master one layer and partner for others can deliver better outcomes. Infrastructure Requires Deep ExpertiseBuilding production-grade blockchain infrastructure isn’t about spinning up a few scripts. It requires handling poorly documented protocols, debugging edge cases in Discord channels, building custom automation, and accumulating years of operational knowledge. This expertise creates a meaningful moat despite surface-level commoditization narratives. Real Use Cases Drive Sustainable GrowthThe maturation of blockchain infrastructure is tied to genuine applications emerging beyond speculation. Financial use cases — payments, trading, cross-border transfers, and now AI-powered transactions — require the programmable money and immutable ledger properties that blockchain uniquely provides. Infrastructure that serves these applications will see sustained demand. Conclusion and the future infrastructure plans Both companies see massive growth driven by two trends: tokenization of traditional finance with regulatory support, and AI-agentic workflows requiring reliable blockchain data. Chainstack is launching a self-hosted version for enterprises, while Ormi continues expanding its real-time indexing capabilities. The partnership demonstrates that blockchain maturity requires specialization. As Chainstack focuses on delivering enterprise-grade RPC infrastructure with 99.99% uptime, partners like Ormi build specialized data layers that developers rely on for mission-critical applications. For developers building next-generation blockchain applications, the foundation is ready. Start for free, connect your app to a reliable blockchain RPC endpoint, and build enterprise and stablecoin applications on infrastructure designed for scale, uptime, and compliance with Chainstack. More ways teams use Chainstack Trust Wallet increased ROI by up to 400% using a custom Chainstack gateway. CertiK slashed Ethereum archive costs by 70%+ while strengthening Web3 security. Nexo lowered Debug & Trace costs by 5X+ using Elastic Business data profiles. #### Chainstack 2.0: Empowering scalable blockchain ecosystems Chainstack stopped supporting Hyperledger Fabric and Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. We launched Chainstack 1.0 a bit more than a year ago. Since then, we have shipped new versions regularly, driven by our customers’ and partners’ feedback. Reaching Chainstack 2.0, however, is a special milestone for me personally, and for the entire Chainstack team. Today is the day Chainstack becomes whole. As a co-founder and CTO, the journey from 1.0 to 2.0 has been full of achievements and learning points, always guided by a customer-centric approach and precision engineering. The mission from day one has been to create the most accessible and scalable platform to enable teams to deploy, manage, and scale blockchain nodes, networks, and applications. The more mature the blockchain industry becomes, the more enterprise partners come on board embracing decentralization as a path to a more efficient and profitable business. At the same time, the more we embark on this path, the sharper the contrast becomes with the tools available to make all of this happen. This is the gap that Chainstack wants to fill. Seeing Chainstack grow into a complete suite of tools available to developers and innovators makes the bumpy road as an entrepreneur worthwhile. What was only a vision and an aspiration, today with the release of Chainstack 2.0 becomes a reality. To achieve this, the team at Chainstack has worked relentlessly, and I speak for everyone when I say that it was an enjoyable development journey. Today, we are thrilled to share the exciting new features of Chainstack 2.0, the most accessible and transparent way to deploy, manage, and scale blockchain applications. Our journey Having released version 1.0 over a year ago with Quorum, MultiChain, and Ethereum support—the latter with our lightning-fast sync mechanism, we went on to work on the more modular and complex networks—Hyperledger Fabric and Corda. We were the first to support Hyperledger Fabric v2 and the automated public Corda Network participation and node deployment. At the same time, we hardened the security of the platform, released Bitcoin protocol support and Ethereum archive node deployment, updated the pricing to make the platform much more affordable, partnered up with bloXroute and implemented their gateway to enhance the speed of our Ethereum nodes. We’ve been busy. What’s new in 2.0 Thanks to the release of the new features and marketplace, Chainstack 2.0 becomes a complete platform that will allow customers to run applications, complementary services, and development tools all in one place. This is a leap forward from the first version of the platform that primarily allowed users to manage blockchain networks and nodes. Let us delve into the details of each new feature. Platform API We are opening up a powerful platform API that allows customers and partners to programmatically create and manage projects, networks, nodes, identities, services, and applications. Developers can use Chainstack orchestration API to manage their blockchain infrastructure programmatically and build blockchain CI/CD pipelines to automate testing and delivery of their solutions. Partners can interact with Chainstack orchestration API to seamlessly manage blockchain deployments from their platforms, which allows them to programmatically operate and scale their networks. Microsoft Azure support We are adding one more cloud provider to our multi-cloud lineup. Now our customers can enjoy the deployment of consortium networks and shared public nodes in Azure UK South region. Anyone can spin up a decentralized network with nodes in three clouds in a few clicks. No user limit on all plans We are removing limits for organization collaborators… on all plans! Now our customers can invite as many users to their Chainstack organizations as they want to work together on exciting blockchain projects. Advanced node lifecycle We are introducing new ways to interact with nodes and networks on Chainstack. Now our customers can start and stop their nodes and networks at any time. It is useful when one wants to take a break from the project but preserve the state and avoid paying for the compute resources. Service nodes and estimated cost visibility We have always been committed to the best user experience and maximum transparency for our customers. Since day one, we have been absorbing the cost for service nodes like Corda Network Map Service and Hyperledger Fabric Orderer in consortium networks. Now all service nodes are visible in the platform so that our customers see exactly what their networks consist of. We also improved our network and node creation wizards to always show the estimated cost of deployed resources so that it is always clear what you pay for. Other updates As usual, we follow the latest development by all protocol engineering teams. In this release, we add support for Hyperledger Fabric 2.2 and Corda 4.5. The next steps Although a major achievement for Chainstack, this is only the first step towards widespread blockchain adoption. I would be thrilled to see blockchain technology so commonplace in the business world to be part of the legacy infrastructure. Equally, I would like to see decentralized ecosystems create new paradigms in how people relate to the world around them, and innovators scale up these solutions without any barrier. With the help of the entire Chainstack team and the growing community of innovators already using our platform, I believe this vision will become a reality much sooner than expected. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack 2.3: Faster and better public blockchain APIs For one and half years Chainstack has been providing unlimited access to shared Ethereum and Bitcoin nodes, meaning there was no throttling, rate, or request limits. On top of that, we’ve been providing the most affordable Ethereum archive node services, available on Chainstack Business plan at just flat $49 a month. This was a deliberate product decision, as we wanted to support the Web3 community and invest in the growth of decentralized projects. We saw the number and kind of unprecedented ideas appearing in DeFi, Layer 2, trading, and other spaces, and we wanted to boost this wave while taking a stance of a long-term decentralized infrastructure partner. Now, it’s time to welcome the new high-performing Chainstack shared public blockchain nodes services. As our community continues to grow and mature exponentially, so has the number of requests to our shared nodes that we are receiving every day. With Chainstack 2.3 we’re bringing additional robustness to the shared node infrastructure, as we’re improving our quality of service dynamically based on the current and forecasted node usage. Changes to shared node services pricing and billing To continue making this a widely accessible and equally best-in-class performing offer, we are introducing a plausible contribution from the heavy users of this shared infrastructure to keep it free for the vast majority of our users. We will start metering JSON-RPC requests to Ethereum and Bitcoin shared full nodes and to Ethereum shared archive nodes. All customers registered before April 6 will be billed for requests exceeding the amount included in the plan only starting from May 1. For them, usage of shared nodes in April will be completely free, provided no plan changes. The requests will be counted towards the monthly included request volume on every subscription plan as follows: Developer, $0 Growth, $19 Business, $49 Enterprise Full node requests included monthly 3,000,000 8,000,000 20,000,000 Custom plan — get in touch Archive node requests included monthly – – 3,000,000 Every extra request exceeding the monthly included volume will be billed per their tier: Extra requestsPrice 0 – 20M $0.10 per 10K requests ($0.00001 per request) 20M – ∞  $0.05 per 10K requests ($0.000005 per request) Take an amount of 25M extra requests as an example: the resulting cost would be a sum of the first 20M requests ($200), and the remaining 5M requests ($25) = $225. About 80% of our current customers will see no change in their monthly bill with the updated cost structure, as long as their usage remains the same. For the remaining ones, Chainstack will remain a long-term blockchain infrastructure partner at a highly competitive price. Our Ethereum and Bitcoin shared full nodes continue to be more than affordable than Infura, Alchemy or QuikNode API service most of the time, and our Ethereum shared archive node service still beats other service providers’ price several times. What is a request?  A request is a single JSON-RPC method call sent to Ethereum or Bitcoin shared node over an HTTP or a WebSocket endpoint. This will apply to other public blockchain protocols on Chainstack to come, except for Corda Network available on our Business plan. How do I check my current requests volume on the shared node that I am using? Navigate to Settings > Billing and scroll down to the Usage section. There you will find the number of requests your organization on Chainstack sends to the shared nodes, updated each hour. When do I get billed? Your monthly period for the included request volume will start on the day of the month you signed up for the Chainstack, and you will be billed for extra requests on a monthly basis. Cost examples as compared with Infura, Alchemy, and QuikNode To help you simplify the comparison across Ethereum and Bitcoin shared node providers, we have put together two tables that will give you an idea of where the new Chainstack shared nodes services stands next to Infura, Alchemy, and QuikNode. We’re assuming a full node request to be equal to 17 compute units, and an archive node request to be equal to 25 compute units on Alchemy. Please note that to prepare this comparison we used publicly available information, therefore you should treat this only as an estimate. Ethereum full node services Monthly requests Service cost Infura Chainstack Alchemy QuikNode 1M $0 $0 $0 $16 10M $225 $39 $437 $99 25M $225 $99 $1046.50 $134 100M $825 $292 $2788 $300 200M $1400 $292 $4828 $300 Ethereum archive node services Monthly requests Service cost Infura Chainstack Alchemy QuikNode 1M $250 $49 $0 $266 10M $475 $119 $709 $499 25M $475 $259 $1384 $384 100M $1075 $634 $3754 $749 200M $1650 $1134 $6754 $1249 Alice and Bob Alice registered on Chainstack on May 1, 2021 with Developer plan and used up 3,500,000 requests sent to Ethereum shared full node within the period of 1 month (May 1 – May 31). InfuraChainstackAlchemyQuikNodeSubscription$50$0$49$9Extra full requests$0$5$18$32Total cost$50$5$67$41 With Chainstack, Alice will have to contribute just $5 for 500,000 extra full requests and $0 for Developer subscription billed on June 1. Bob registered on Chainstack on December 1, 2020 with Business plan and used up 3,500,000 requests sent to an Ethereum shared archive node within the space of 1 month (May 1 – May 31). InfuraChainstackAlchemyQuikNodeSubscription$300$49$49$259Extra full requests$0$5$150$32Total cost$300$54$199$291 With Chainstack, Bob will need to contribute just $5 for 500,000 extra archive requests and $49 for Business subscription billed on June 1. We now accept payments in cryptocurrency Starting from April, Chainstack Enterprise customers will have the option to pay in advance for subscription, usage, and professional services fees using cryptocurrencies. Over the past few months, we have been discreetly testing with a number of beta customers and we are delighted to now be able to roll this service to all of our Enterprise customers. Pioneering Web3 infrastructure Chainstack remains the industry pioneer in multi-protocol, multi-cloud blockchain managed services. As the industry grows exponentially and blockchain applications become widely accepted in all aspects of business life, we want to continue to be a trusted ally for the Web3 community and support the growth of the industry. Our shared public blockchain node services will be even more high-performing and reliable than before, whilst remaining the most accessible option price-wise for anyone needing best-in-class infrastructure to build their applications on. The Chainstack community continues to grow, and we would not be here without your continued support and trust. We would love to hear your feedback about these upcoming changes and answer any questions you may have. You can get in touch through Chainstack Support or by reaching out on our website. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram groupSign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack 2.6: Tezos support and easier node access Tezos is deprecated on Chainstack and is no longer available for new deployments. Amazing developments have super charged the entire Web3 community in the past year. Now approaching the last quarter of 2021, the Chainstack platform and community have experienced explosive growth, launching and deploying thousands of nodes across public and consortium blockchain protocols in all continents. After announcing the launch of Polygon and Binance Smart Chain support in the past few months, the process of scaling our operations to meet customer demand is currently our highest priority. We stand by our mission to make Web3 for all and in doing so, we always maintain the highest standards in infrastructure management. Accessibility and reliability have always been our core aim. Our approach has helped us become an industry leading blockchain infrastructure provider, trusted and relied upon by some of the largest communities and projects in DeFi, Web3 and enterprise blockchain. As we grow our support across more and more blockchains, it is essential to keep developing increasingly better processes and systems to remain steadfast and dependable as a long-term decentralized infrastructure partner. This update brings better usability and customization options to our platform. In addition to that, we are bringing better security elements as well as on-demand features to our platform. Our Enterprise plans have also been reworked to be more affordable and cost-effective. Finally, we welcome Tezos to our highly selected portfolio of supported blockchains. Improved billing and customer experience We want you to experience a world-class product that is user-friendly and intuitive. In this upgrade, we have made a few quality-of-life changes for the betterment of your experience. We want you to know that our Developer plan will continue to be free forever. You can rely on our Developer plan for 3M requests every month to shared full nodes across our public blockchain protocols. New sign ups to Developer plan will benefit from a 7-day trial period with unlimited requests to all public shared nodes. Our billing process will start after 7 days and only if your usage exceeds 3M calls to full nodes within the month. At the same time, we provide you with max flexibility, so that you can upgrade your subscription to the most effective plan for you at any time. Our plans will remain without any traffic limits or throttling. Developer, $0Growth, $19Business, $49Enterprise, $990Full node requests included monthly3,000,0008,000,00020,000,000400,000,000Archive node requests included monthly––3,000,00060,000,000 Every extra request exceeding the monthly included volume will be billed per their tier: Extra requestsPrice0 – 20M$0.10 per 10K requests ($0.00001 per request)20M – ∞ $0.05 per 10K requests ($0.000005 per request) Check out our affordable and cost-effective subscription plans here: Pricing Key-based authentication Based on overwhelming demand from our community, we are introducing a new authentication option. In addition to the Basic access authentication we’ve had since our early releases, from today you can use key-based authentication for all public blockchain nodes as well as for the Quorum protocol. Key-protected endpoints ease the process of onboarding Chainstack to your Web3 applications, or of trading using infrastructure and tools like MetaMask, ethers.js and others. Find more about the changes and check connection code snippets in Chainstack Docs. More AWS locations & on-demand dedicated node deployments Transaction speed and stability are core requirements of node deployment, achieved also through strategic geographical spread of our cloud hosting. For this reason, based on our community feedback and requests, we are releasing Binance Smart Chain deployed in AWS Singapore as well as Polygon deployed in AWS US East. One of the most appreciated features on the Chainstack platform is the variety of node deployment locations available, with multiple cloud hosting options that improve latency and call speed. With the Chainstack 2.6 release, we are now making on-demand dedicated node deployments available upon request directly from the Chainstack console. Power-boosting your projects with an accessible Enterprise plan Alongside the growth of the Web3 community and the addition of more protocols to our highly selected portfolio, we have observed an increased demand for plans that can cater for the most demanding performance, monthly traffic, and enterprise-grade SLAs. For this reason, we have restructured our Enterprise plan to make sure it is even more powerful and accessible to the many, not just the few. We are updating the shared node limits, doubling the free monthly calls from 200M to full nodes and 30M to archive nodes, to 400M and 60M respectively. This will allow our community on Enterprise to get twice the number of calls to nodes as they wish to, across Ethereum, Polygon, Binance Smart Chain, and Tezos for one easy flat fee of just $990/month. Dedicated node deployments with our Enterprise plan will remain priced by usage costs that vary with different setups and blockchain protocols. We want to make it as easy and flexible as possible for you to select the best plan for your requirements, and we understand that things move fast in this environment. For this reason, we are now introducing a self-service upgrade of your plans within the platform, from Developer to Growth, Growth to Business and to Enterprise plan. Tezos now supported on Chainstack We are excited to announce that our community will now be able to deploy Tezos nodes seamlessly and reliably using Chainstack. This launch is the first step in a long-term collaboration that will bring together our two communities with the goal of making Web3 not just more accessible, but also more environmentally sustainable. As always, we want to make it very easy to manage your node infrastructure on Tezos and streamline your resources towards building, trading and exploring data on the Tezos mainnet chain or Florence testnet chain. Robust and reliable infrastructure is critical for the Tezos ecosystem. We are pleased to collaborate with Chainstack to make the blockchain experience seamless for users, enterprises, and developers. Om Malviya, Director, Tezos India. We will initially be offering shared full and archive nodes with hosting initially available in Google Cloud Platform, Singapore region with more options and customizability to come, including dedicated Tezos nodes for bakers. About Tezos Tezos is built with a deep commitment to security, formal verification, and governance. Tezos is a delegated proof-of-stake (DPoS) blockchain network that offers peer-to-peer transactions via is native XTZ cryptocurrency through it decentralized platform by deploying smart contracts. The Tezos blockchain facilitates the building of decentralized applications and is seen as a greener alternative to Ethereum. Tezos aims to offer infrastructure that is advanced — meaning it can evolve and improve over time without there ever being a danger of a hard fork. Tezos takes a fundamentally different approach compared to other blockchains, by creating governance rules for stakeholders to approve protocol upgrades that are then automatically deployed on the network. People who hold XTZ can vote on proposals for protocol upgrades that have been put forward by Tezos developers. Leading-edge Web3 infrastructure Chainstack remains the industry pioneer in multi-protocol, multi-cloud blockchain managed services. As the industry grows exponentially and blockchain applications become widely accepted in all aspects of business life, we want to continue to be a trusted ally for the Web3 community and support the growth of the industry. Our shared public blockchain node services will be even more high-performing and reliable than before, whilst remaining the most accessible option price-wise for anyone needing best-in-class infrastructure to build their applications on. The Chainstack community continues to grow, and we would not be here without your continued support and trust. We would love to hear your feedback about these upcoming changes and answer any questions you may have. You can get in touch through Chainstack Support from your console account, or by reaching out on our Telegram group or Discord server. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our community channels on Telegram and Discord. Sign up for a free Developer account. Explore the options offered by Growth or Business plans and look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack 3.0 is for scaling: Better plans, more included requests, brand new APIs Highlights: New pricing plans with new features and more requests included. Shared nodes are now called Global nodes to reflect the underlying architecture and scalable infrastructure. New high-speed transactions to win the mempool race, called Warp transactions. New APIs: MEV API on Ethereum to simulate transactions before sending them through the Flashbots relay. Debug and trace APIs on Global Ethereum archive nodes for low-level state inspection and transaction debugging. What’s new in Chainstack 3.0 Chainstack 3.0 is new, bigger, better, and more versatile than ever. This release is a leap forward from the previous version of the platform with the new features that have something for everyone, including: Users who need high-value near-instant transactions. Flashbots searchers who need to save milliseconds in bundle simulation. DApp builders who need to scale. Developers that do on-chain debugging. All in one platform. Chainstack has been providing fast, reliable, and robust blockchain node APIs right from the start. Following the evolution of Web3, we are always expanding our product offering. With this release, Chainstack customers get new and expanded APIs. At the same time, we are working on more features for our customers to build better with the Web3 stack. A sneak peek into the near future of Chainstack will include storage services, more advanced APIs, and easier DApp management. Vasily Rudomanov, Product Director, Chainstack Today, we are rolling out updated pricing plans with the expanded functionality that includes high-speed transaction propagation (called Warp transactions), MEV API, and debug & trace APIs on Global Ethereum archive nodes. Let’s have a quick run-down on all the changes and how they affect you. Quick overview New Growth and Business plans with expanded capabilities. Access to additional full and archive dedicated nodes in the Growth plan. More included requests in the Growth and Business plans. New features: Warp transactions on Ethereum, Polygon, and BNB Smart Chain. MEV API and debug & trace APIs on Ethereum. See the details on the pricing page. Warp transactions With this feature, the transactions sent to your node propagate through the bloXroute Blockchain Distribution Network (BDN) and are near-instantly available for validators to pick up and include in the next block. The bloXroute BDN utilizes a global network of servers optimized for network performance, providing you access to lightning speed and performance. The benefits of Warp transactions include the following use cases: Be more likely to win race scenarios like liquidating collateralized debt positions (CDPs). Be able to capture arbitrage opportunities in DeFi. Be able to outrun the competition in gaming projects. Increase chances of being included in the next block. Increase chances of beating fee congestion. Manage risk in market making more efficiently. Experience the fastest mempool service with Warp transactions. Now available on Ethereum, Polygon, and BNB Smart Chain starting from the Growth plan. MEV API With the Miner Extractable Value (MEV) API, your searcher will have its own reliable endpoint to simulate the transactions and win the time over the competition. MEV API lets you run the transactions against a Chainstack Ethereum node for bundle simulation before sending them through the Flashbots relay. Chainstack’s geographically distributed hosting infrastructure will help you shave the milliseconds off your Flashbots relay transactions to win the auction race. Available both on the Ethereum mainnet and the Goerli testnet, MEV API allows you to run tests and experiment before going to production. MEV API is available starting from the Growth plan. Debug and trace APIs With the debug and trace APIs, you can inspect the chain state, replay transactions on the chain in the exact same way as they were executed to retrieve the low-level data like opcodes, memory, and storage changes, and so on for the debugging and detailed logging purposes. With this release, the debug and trace APIs are available on: Global Ethereum archive nodes starting from the Business plan. Dedicated BNB Smart Chain full and archive nodes starting from the Business plan. Dedicated Ethereum, Polygon, Avalanche, Fantom, Harmony full and archive nodes starting from the Growth plan. In the near future, we will roll out the debug and trace APIs support on Global archive nodes for more protocols. Pricing changes Based on your valuable feedback, we are supercharging the existing Growth plan and introducing a brand new Business plan. Growth plan The plan now has exciting new features and an increased number of included requests to Global nodes: The Warp transactions feature is now available on Ethereum, Polygon, and BNB Smart Chain. MEV API is now available on the Ethereum mainnet and the Goerli testnet. The Global full nodes get an increase from 8M to 20M included requests per month. You can now use Global archive nodes with 3M included requests per month. You can now deploy full and archive dedicated nodes on all public chain protocols except for the BNB Smart Chain. The subscription rate changes from $19/month or $190/year to $49/month or $490/year. For dedicated public chain nodes, the node compute rate changes from $0.15/hour to $0.30/hour. Business plan A brand new plan with brand new features. The new Business plan is where most of your feedback was implemented. It’s the plan that has the biggest changes, including all our newest features, while remaining as affordable as possible. You can do a lot here—from scaling to dedicated BNB Smart Chain nodes to reducing latency for your Flashbots searchers on Ethereum to sending near-instant transactions on Ethereum, Polygon, and BNB Smart Chain to debugging on Ethereum. The Warp transactions feature is now available on Ethereum, Polygon, and BNB Smart Chain. MEV API is now available on the Ethereum mainnet and the Goerli testnet. Debug and trace APIs are now available on the Global Ethereum archive nodes. The Global full nodes get an increase from 20M to 200M included requests per month. The Global archive nodes get an increase from 3M to 20M included requests per month. You can now deploy dedicated BNB Smart Chain full and archive nodes. The subscription rate changes from $49/month or $490/year to $499/month or $4,990/year. For consortium networks, hybrid hosting node management is now available at the rate of $0.50/hour. For dedicated public chain nodes, the node compute rate changes from $0.30/hour to $0.40/hour. Facilitating the transition We are here to support you in making the transition smooth with the following items: All current Growth plan users are automatically upgraded to the new terms on July 7, 2022. The affected Growth plan users will enjoy a $30 monthly discount for the next 3 months. All current Business plan users are automatically transferred to the new Growth plan on July 7, 2022. The affected Business plan users will find the same features they enjoyed under the previous plan at no extra cost. The newly introduced features for the Growth plan will offer expanded capabilities for all affected users. Next steps This release is a major step forward for us, and we are thrilled to be a part of the blockchain technology becoming increasingly commonplace in the world. As always, Chainstack is committed to making Web3 and the underlying blockchain infrastructure more accessible to everyone—from builders to end users. We are building daily and shipping often. Have a look at our ideas portal and log the new features you would like to see implemented, or comment and vote on the already submitted ones. With the help of the entire Chainstack team and the growing community of innovators already using our platform, our vision will become a reality much sooner than expected. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack achieved ISO/IEC 27001 certification We’re proud to announce that as of this month, Chainstack has officially achieved ISO/IEC 27001 certification! We received the final Stage 2 audit report and certificate from our long-term compliance partner A-LIGN, closing out a process we committed to publicly earlier this year. Paired with the SOC 2 Type II we earned in December 2025, Chainstack is now one of a small number of blockchain infrastructure providers that can hand an enterprise compliance team both audit reports on the first ask. What ISO/IEC 27001 actually certifies ISO/IEC 27001 is the international standard for information security management. Unlike SOC 2, which attests that a defined set of controls operated effectively over a period of time, ISO 27001 certifies that an organization has built and continues to operate a full Information Security Management System (ISMS) — a governed, risk-driven program spanning policies, people, processes, and technology, aligned to the Annex A control set of the 2022 revision of the standard. In practice, the audit examined how Chainstack: identifies and treats security risks across our blockchain node infrastructure, APIs, and internal systems enforces identity and access controls — MFA, hardware tokens, role-based access with least-privilege, and privileged access management — for both customer-facing services and internal tooling protects data at rest (AES-256) and in transit (TLS), including secure erasure procedures handles change management, secure development (environment isolation, team segregation, multi-user code review), and vulnerability response — backed by automated dependency checks, IaC-based patching, and an active bug bounty program on HackenProof maintains business continuity, incident response, and supplier security across our global footprint runs internal audits, management reviews, and continuous improvement of the ISMS itself The certification was issued by A-LIGN, an ISO/IEC 27001 certification body accredited by the ANSI National Accreditation Board (ANAB) and the United Kingdom Accreditation Service (UKAS). For readers who want the deeper background on how SOC 2 Type II and ISO 27001 map to institutional due diligence for Web3, our earlier piece on SOC 2 Type II for blockchain infrastructure walks through it in detail. Why we did this “With ISO 27001 now in place alongside Chainstack’s SOC 2 Type II compliance, Chainstack covers the two audit-backed standards regulated teams expect from blockchain infrastructure. Customers get evidence they can take straight into their own risk process.” — Eugene Aseev, Founder, Chainstack Chainstack customers include wallets, exchanges, custodians, tokenization platforms, oracle networks, and a growing set of regulated financial institutions building on public and permissioned chains. For every one of them, the vendor security review is a real gate. Dual certification (SOC 2 Type II + ISO 27001) is what gets you through it. Getting through that gate on the first ask matters. It’s the difference between a two-week procurement cycle and a six-month one. A-LIGN, who conducted the audit, added: “Congratulations to Chainstack for earning ISO/IEC 27001 certification, a widely recognized signal of trust and security. It’s great to work with organizations like Chainstack, who understand the value of expertise in driving an efficient audit and the importance of a high-quality final report.” — Steve Simmons, COO, A-LIGN What this means for you If you’re a Chainstack customer, nothing changes operationally — the controls audited under ISO 27001 are the ones we’ve been operating against all along. What does change is what your security, risk, and procurement teams can now do with that: Vendor questionnaires — most SIG, CAIQ, and custom questionnaires map directly to ISO 27001 Annex A, which shortens vendor reviews. Regulatory filings — for MiCA, DORA, state money transmitter regimes, and equivalent frameworks, third-party infrastructure now comes pre-mapped to a control set your regulator already recognizes. Internal audit — our ISMS documentation and audit report are available under NDA through the Chainstack Trust Center, alongside our SOC 2 Type II report, independent penetration test report, and public SecurityScorecard rating. If you’re evaluating Chainstack and want the reports, reach out to your account team or contact us — we’ll get them to your compliance reviewer the same day. What’s next Compliance is a program, not a milestone. ISO 27001 doesn’t end the security work — it puts an independent auditor’s stamp on the fact that the work is real and continuous. Together with SOC 2 Type II, it confirms that Chainstack meets the audit standard regulated teams already require from the rest of their infrastructure stack. If you’re building stablecoin rails, RWA tokenization, custody, exchange infrastructure, DeFi, or AI-driven trading on Ethereum, Solana, BSC, Base, Arbitrum, or any of the 70+ networks we support, you can now do it on infrastructure your compliance team can sign off on. Create a Chainstack account and deploy your nodes on audited infrastructure. Welcome to the next level of secure Web3 building with Chainstack! 💙 #### Chainstack achieved SOC 2 Type II certification We are proud to announce that as of December 22, 2025, Chainstack has officially achieved SOC 2 Type II certification! This milestone marks a new high standard in our ongoing commitment to security and trust. By completing the rigorous Type II audit, Chainstack reinforces its promise of providing secure, reliable blockchain infrastructure for all users and enterprises. In this blog post, we’ll explore what SOC 2 Type II means, how the audit works (with a focus on security, availability, and confidentiality), why this certification matters for blockchain infrastructure providers, and the key benefits it brings to our customers. What is SOC 2 Type II certification? SOC 2 stands for System and Organization Controls 2, a security and compliance framework developed by the American Institute of CPAs (AICPA). It defines how service organizations should manage customer data based on five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. In essence, SOC 2 is an independent auditing procedure that ensures a service provider (like Chainstack) securely manages data to protect client interests. Importantly, SOC 2 reports come in two types. A Type I report evaluates the design of a company’s security controls at a single point in time. In contrast, a Type II report assesses how well those controls operate over a period of several months (typically 3–12 months). In other words, Type II goes beyond a snapshot; it proves that security measures aren’t just in place, but consistently effective in practice. According to industry guidance, a SOC 2 Type II offers greater assurance to customers, often regarded as the gold standard for demonstrating robust security and reliability. Achieving SOC 2 Type II certification means an independent auditor has thoroughly reviewed Chainstack’s systems and processes over time and found that we meet the stringent criteria for protecting customer data and maintaining service excellence. What the SOC 2 Type II audit evaluates (security, availability, confidentiality) A SOC 2 Type II audit entails a comprehensive examination of our internal controls across the chosen Trust Services Criteria. Security is always included in every SOC 2 audit, and for an infrastructure provider like Chainstack, availability and confidentiality are also critical focus areas. Here’s what each of these principles means and how they’re evaluated: Security: Security focuses on protecting system resources from unauthorized access. During the audit, an independent auditor reviews how we control access to systems, prevent data breaches, and ensure that only authorized personnel can interact with sensitive information. At Chainstack, this includes role-based access control (RBAC), multi-factor authentication for users and internal teams, as well as encryption and firewalls to protect data. These controls help prevent data alteration, theft, or misuse and ensure our infrastructure remains resilient against security threats. Meeting the Security criteria demonstrates that customer data and operations are well protected from unauthorized access. Availability: Availability evaluates whether systems and services remain reliable and accessible as promised, including compliance with uptime commitments and service level agreements. The SOC 2 audit reviews how we maintain uptime, respond to incidents, and recover from disruptions. Chainstack’s globally distributed infrastructure and redundancy planning are designed to minimize downtime, even during adverse events. We use continuous monitoring, automatic failover, and regular backups to keep services running reliably. As a result, Chainstack consistently delivers enterprise-grade availability with 99.99%+ uptime. Confidentiality: Confidentiality focuses on protecting sensitive data from unauthorized disclosure. The audit assesses how we restrict access to data, apply encryption, and enforce data handling policies. At Chainstack, all sensitive data at rest is encrypted using strong standards such as AES-256, and data in transit is protected with TLS encryption. Access to customer information is limited to authorized personnel only, and data that is no longer required is securely erased. By meeting the Confidentiality criteria, Chainstack ensures that private keys, transaction data, and other sensitive information remain secure and accessible only to the appropriate parties. It’s worth noting that a SOC 2 report can cover additional criteria like Processing Integrity and Privacy. Chainstack’s audit was comprehensive – addressing all five Trust Service Criteria in our controls – but security, availability, and confidentiality were especially pertinent given our role as a blockchain infrastructure provider. The audit process involved an accredited CPA firm scrutinizing our controls in these areas over several months, verifying not just that we have documented policies, but that we consistently follow them in daily operations. Passing this audit with flying colors means our safeguards in security, uptime reliability, and data protection are not only well-designed but also proven effective through real-world observation. Why SOC 2 Type II certification matters for blockchain infrastructure In the cloud and blockchain infrastructure industry, trust is paramount. Enterprises and developers rely on infrastructure providers to handle critical transactions, sensitive keys, and high-value data. Obtaining a SOC 2 Type II certification sends a strong signal that Chainstack meets an industry-leading standard of security and operational maturity. In fact, many security-conscious businesses now treat SOC 2 compliance as a minimal requirement when choosing a SaaS or cloud provider. This is especially true in finance, enterprise, and regulated sectors that are increasingly embracing blockchain technology. For blockchain infrastructure providers, the stakes are even higher. The decentralized nature of Web3 doesn’t eliminate the need for trust in the platforms that enable access to blockchain networks. By achieving SOC 2 Type II, Chainstack demonstrates to our customers and partners that we have been independently verified to uphold strict security controls, high availability, and confidentiality of data. This certification differentiates Chainstack in the Web3 ecosystem, showcasing our commitment to enterprise-grade best practices. It also aligns us with other top-tier infrastructure providers that have invested in compliance – essentially raising the bar across the industry. As a result, current and prospective customers can have increased confidence that Chainstack’s platform is built on a foundation of audited, trusted processes. SOC 2 Type II is often called a gold standard for assurance, and for us it’s a means to foster greater trust in blockchain adoption at the enterprise level. Whether you are a startup developer or a large financial institution building on Chainstack, you know that our security and reliability claims aren’t just marketing – they are validated by a reputable third-party audit. Benefits to Chainstack users and customers Chainstack’s SOC 2 Type II certification isn’t just an internal achievement – it delivers tangible benefits to all our users and customers: Peace of mind and trust: You can develop and deploy on Chainstack with confidence that our platform’s security controls have been independently vetted. The certification provides objective proof that we protect your data against unauthorized access and have resilient operations in place. This reduces the risk for your business, allowing you to focus on building innovation rather than worrying about infrastructure vulnerabilities. Reliability and uptime assurance: The audit’s emphasis on availability means that our customers benefit from a highly reliable service. Chainstack has demonstrated robust processes for incident management, disaster recovery, and redundancy. As a user, you can expect consistently high uptime and performance. Our commitment to a 99.99%+ uptime SLA is backed by the controls verified in the SOC 2 report, translating to fewer disruptions for your applications. Data confidentiality and compliance: For organizations handling sensitive or regulated data, Chainstack’s certified confidentiality measures provide an extra layer of compliance. All data you entrust to our platform is handled under strict encryption and access controls, as confirmed by the SOC 2 examination. This can help your own compliance efforts (for example, if you need to demonstrate due diligence in vendor security or adhere to privacy regulations). Using a SOC 2 Type II certified provider like Chainstack can streamline vendor risk assessments and audits on your side. Enterprise-ready credibility: Chainstack’s achievement of SOC 2 Type II reinforces that we operate with the level of discipline and excellence expected by enterprise IT and procurement teams. If you’re an enterprise customer, this certification simplifies the process of trusting and onboarding Chainstack as your blockchain infrastructure provider. It signals that we have best-in-class security practices and internal controls. For startups and developers, it means you’re scaling your project on a platform built to the highest standards—giving your stakeholders and end-users added reassurance. Ultimately, SOC 2 Type II certification brings our users the benefit of transparency and assurance. We don’t just claim to be secure and reliable – we have the audit report to prove it. (In fact, we’re happy to share a public preview of our SOC 2 report with customers, under NDA, for a closer look at the details.) This achievement strengthens the trust between Chainstack and our community, creating a more confident foundation for everyone building on our platform. Conclusion and next steps SOC 2 Type II certification confirms that Chainstack provides audited, enterprise-grade infrastructure for production workloads – where security, availability, and confidentiality are critical by default. If you’re building RWA, digital asset tokenization (DAT), or stablecoin infrastructure on Ethereum, Solana, BSC, Base, or Polygon, Chainstack offers a secure foundation designed for real-world value and scale. Security remains central to everything we do – from secure development and infrastructure access controls to continuous monitoring, backups, and data protection. Our platform operates on audited processes, encryption by default, and reliable security operations. If you’re looking for a robust infrastructure partner for your Web3 projects, now is a great time to get started. Experience the benefits of a SOC 2 Type II certified platform firsthand. Create a Chainstack account and deploy your blockchain nodes with confidence – knowing your infrastructure is built on trusted, audited foundations. Welcome to the next level of secure blockchain building with Chainstack! 💙 #### Chainstack and 1inch: A collaborative journey towards DeFi excellence Accessing accurate real-time DeFi data across multiple networks At 1inch Labs, our mission is to provide our users with the best possible DeFi experience in a permissionless and trustless manner building 1inch Network. We attribute part of our success to our valuable partnership with Chainstack. Their unwavering dedication to overcoming challenges and providing optimal and innovative solutions have empowered us to deliver more efficient SaaS products such as 1inch API. We are confident that our ongoing collaboration with Chainstack will continue to drive our mutual growth and redefine the future of DeFi. Sergej Kunz, Co-Founder, 1inch Network At Chainstack, we take pride in our ability to empower innovators in the decentralized finance (DeFi) space. As collaborators with market leaders like the 1inch Network, we help create a seamless DeFi experience for users worldwide. Through our expertise in managed blockchain services and a strong focus on addressing challenges and providing optimal solutions, we have forged a dynamic partnership with 1inch. Together, we are working to revolutionize the DeFi landscape, pushing boundaries and setting new industry standards. 1inch: DeFi access made easy Decentralized exchange (DEX) aggregators, like 1inch, are essential for the DeFi ecosystem as they consolidate liquidity from multiple DEXes and deliver the best possible rates for token swaps. This plays a critical role in simplifying access to DeFi services and enhancing the overall user experience. Figure 1: 1inch DeFi aggregator – how it works; Source: 1inch By harnessing the power of DEX aggregators, users gain the ability to execute their trades efficiently without manually searching for the best rates across various platforms. This not only saves users time but also ensures that they receive optimal pricing and execution for their transactions. 1inch empowers users to access the expansive world of DeFi with ease through its innovative Aggregation Protocol, ultimately driving the adoption and growth of decentralized finance. What is 1inch? 1inch is a leading DeFi platform that offers a comprehensive suite of services to its users, including a DeFi wallet, an aggregation protocol, a limit order protocol, and a liquidity protocol. With more than 383 liquidity sources, the platform has seen over $286 billion in total volume, 4 million wallets, and 29 million trades. The 1inch DeFi wallet allows users to buy crypto using their bank cards via partner providers, transfer crypto across different blockchain networks, and swap tokens at optimal rates. Users can also stake the platform’s native token, 1INCH, to participate in network governance. Figure 2: 1inch DeFi wallet; Source: 1inch Through its innovative aggregation protocol, 1inch sources liquidity from multiple DEXes, ensuring the best swap rates for users. The platform’s limit order protocol is regarded as the most innovative and flexible in the DeFi space. Additional offerings from 1inch include the 1inch API, which offers an advanced discovery and routing algorithm for non-custodial asset swaps at the best rates across major DeFi ecosystems, and the 1inch RabbitHole, a feature that protects MetaMask users from sandwich attacks. In line with its commitment to fostering network growth and incentivizing contributions, 1inch has established a grant program that provides grants and resources for developers just as well. The platform is committed to security and performance, evidenced by its status as the most audited project in DeFi. It employs sophisticated security measures to protect user funds during swaps on other DeFi protocols. 1inch’s smart contracts verify transaction execution in real-time to ensure user funds’ security. Token holders also have a say in key protocol parameter decisions, thanks to the 1inch DAO. 1inch has garnered significant usage across popular blockchains, including Ethereum ($243B volume, 130K monthly users), BNB Chain ($23.1B volume, 99K monthly users), and Polygon ($16.5B volume, 56K monthly users). How 1inch empowers users with cutting-edge solutions 1inch has revolutionized the DeFi landscape by offering a diverse range of products and services that cater to the needs of the community. Among the most recent releases is the Fusion upgrade, which enhances swap efficiency and security by aggregating liquidity from across the crypto market. Consequently, users can access the best rates when swapping their assets. Meanwhile, the 1inch RabbitHole safeguards MetaMask users from sandwich attacks. Together, all 1inch offerings work to create a robust and secure DeFi ecosystem for users. Figure 3: 1inch RabbitHole sandwich attack protection; Source: 1inch 1inch’s Limit Order Protocol boasts a suite of notable features, such as zero fees, dynamic pricing, conditional orders, extra RFQ support, multi-chain functionality, and various possible use cases including P2P orders, stop-loss orders, trailing stop orders, and auctions. The platform also offers a grant program for developers who are interested in building upon its protocols. Challenges of fetching smart contract data in real-time Accessing smart contract data in real-time can be a challenging task for decentralized finance platforms like 1inch, due to the following reasons: Querying token price, liquidity, and transactional data across multiple DEXes: In the rapidly expanding DeFi ecosystem, there are numerous DEXes, each with its own set of trading pairs, liquidity sources, and data points. Fetching real-time data from all these DEXes, while simultaneously aggregating the information, can be computationally intensive, making it problematic to ensure accurate, up-to-date data. Fetching data from native DEXes on various blockchain networks: As DeFi expands to encompass numerous blockchain networks, DEX aggregators like 1inch need to fetch data not only from DEXes on one blockchain network but also from native DEXes on multiple networks. This adds another layer of complexity, as it involves handling data from blockchain networks with differing characteristics, consensus mechanisms, and data formats. The importance of data freshness for DeFi users: DeFi users rely on platforms like 1inch to provide accurate, real-time data to make informed decisions. Data freshness is of utmost importance, as stale or incorrect data may lead to unfavorable trade executions or missed arbitrage opportunities. Maintaining user trust in the platform and the wider DeFi ecosystem hinges upon the ability to deliver reliable, up-to-date data. Due to these challenges, fetching smart contract data in real-time is a complex task. Nonetheless, platforms like 1inch continue to work diligently to overcome these hurdles, ensuring optimum service quality for users in the ever-growing DeFi space. Picking up after TheGraph Hosted Service sunset With the sunset announcement of TheGraph Hosted Service, we, the Chainstack team, fully appreciate the implications for various applications, particularly our partner, 1inch. Instead of seeing this transition as a hurdle, we viewed it as a golden opportunity to elevate our services and offer our clients ever more efficient solutions: Broadening blockchain network support: The switch from TheGraph Hosted Service can often be daunting, but at Chainstack, we thrive on challenges. With the introduction of Dedicated Subgraphs’ seamless migration tool, this transformation became a breeze. Our commitment was unwavering: we guaranteed that 1inch continued to enjoy unfettered data accessibility and robust query capabilities. Debunking complex pricing structure: TheGraph’s Hosted Service pricing has long been a complex maze. Recognizing the need for 1inch to balance cost estimations, budgeting, and focus on core operations, we, at Chainstack, stepped up to the plate. Our answer? A transparent, manageable pricing structure that took away the guesswork out of the equation, allowing 1inch to center their attention on key projects. Delivering uninterrupted support: The absence of 24/7 support from TheGraph Hosted Service had often led to uncertainties, especially in critical moments. This was precisely when Chainstack shined. Placing our client’s needs at the forefront, we committed to round-the-clock support, ensuring that 1inch’s operations flowed seamlessly and efficiently. The sunset of TheGraph Hosted Service brought to light the complexities of accessing smart contract data and managing substantial historical datasets. However, Chainstack stood ready to tackle these complexities head-on. We were enthusiastic about harnessing this shift to enhance our services for 1inch, guaranteeing them reliable and accurate data access in the rapidly advancing DeFi ecosystem. How 1inch queries cross-chain data in real-time with Chainstack Chainstack played a crucial role in empowering 1inch to efficiently query real-time data across various blockchain networks. Here’s how Chainstack achieved this impressive feat: Deployment of 28 subgraphs on Dedicated Subgraphs dedicated indexer: To ensure seamless data querying across multiple networks, 1inch has deployed 28 subgraphs on Dedicated Subgraphs. This deployment enables the platform to access critical and comprehensive information from numerous decentralized exchanges, blockchain networks, and other data sources. Support for popular protocols: Dedicated Subgraphs is designed to cater to multiple protocols, including some of the most popular choices such as Ethereum, BNB, Polygon, and Avalanche. This extensive network support enabled 1inch to gather data from diverse sources effortlessly and expand its services across these networks. Minimizing latency and enabling faster data response times: Chainstack prioritizes efficient data querying by minimizing latency and ensuring faster response times. This optimization is particularly crucial in the DeFi landscape, where real-time access to accurate data plays a pivotal role in enabling users to make well-informed decisions about their assets. Importance of uninterrupted data access in the fast-paced world of DeFi: In the rapidly evolving and competitive DeFi landscape, uninterrupted access to real-time data is paramount. Chainstack’s robust infrastructure upholds this access, allowing 1inch and its users to stay ahead of the curve and capitalize on emerging opportunities. Customizations and 24/7 support: Alongside its technical capabilities, Chainstack offers personalized customizations to cater to the specific needs of partners like 1inch. Moreover, Chainstack’s round-the-clock support guarantees assistance in addressing issues promptly, ensuring minimal disruptions in data access and query performance. Chainstack plays a crucial role in empowering 1inch by facilitating real-time data queries across various networks, a vital factor for the platform’s triumph in the rapidly interconnected DeFi ecosystem. By effectively fulfilling these core functions, Chainstack ensures the seamless operation of 1inch in leveraging real-time data from multiple networks, which is pivotal for the platform’s prosperity within the ever-evolving DeFi landscape. 1inch on Chainstack: Overcoming obstacles and driving success At Chainstack, our partnership with 1inch has been an exciting journey of collaboration, growth, and mutual success. As a leading provider of managed blockchain services, we have tackled various challenges faced by the 1inch team and worked closely together to provide the best solutions. Initially, 1inch brought up a latency issue they were experiencing when comparing us to a competitor. Determined to overcome this challenge, we conducted extensive tests in collaboration with 1inch to identify the source of high latency and devise improvements. This focus on creating better solutions not only addressed their concerns but also revealed our unwavering commitment to their success. As we improved the stability of our Dedicated Subgraphs offerings based on their feedback, we opened up new growth opportunities for 1inch, enabling them to access the Polygon and BNB chains. This achievement underscores the power of a collaborative and innovative approach to problem-solving. Recognizing 1inch’s unique needs, we have provided them with specialized support for Dedicated Subgraphs, which is integral to our premium support package. This ensures a seamless and customized experience with our services. Our fruitful collaboration with 1inch extends beyond technical support. We have actively explored marketing and co-sponsorship opportunities, creating a holistic partnership that adds value in multiple dimensions. Furthermore, in a show of commitment to their satisfaction, we have offered 1inch a 20% discount on our manual quotations, ensuring they receive the highest quality service at affordable prices. As we continue our partnership with 1inch, we remain focused on addressing their feedback and further refining our services. We are driven by a passion to meet their requirements without compromises and aim to consistently exceed their expectations. Resolution summary Our partnership with 1inch has been characterized by open dialogue and strong collaboration in addressing various challenges. Key areas where we have worked together include: Diagnosing and resolving latency issues to ensure optimal performance. Enhancing Dedicated Subgraphs product stability and opening new growth opportunities for 1inch on Polygon and BNB chains. Providing specialized support for Dedicated Subgraphs tailored to 1inch’s unique needs. Collaborating on marketing opportunities, including co-sponsorships and industry events. Offering a 20% discount on manual quotations to deliver high-quality service at affordable rates. Our determination to prioritize 1inch’s needs and exceed their expectations has strengthened our relationship and allowed both parties to benefit from this invaluable partnership. We are excited to continue working with 1inch and eagerly await the new challenges and successes that lie ahead. Conclusion In summary, Chainstack plays an instrumental role in empowering 1inch to aggregate data across multiple networks, delivering accurate and timely data to their end users. By providing a robust infrastructure, minimizing latency, offering customization options, and ensuring 24/7 support, Chainstack ensures that 1inch can continue to unlock the full potential of decentralized finance for its users. Consequently, 1inch is central to the advancement of the future of finance, and its success is a testament to what is possible in the world of DeFi. With innovative services, seamless integration, and an unwavering commitment to user satisfaction, 1inch continues to redefine and expand the boundaries of the DeFi landscape. Our close collaboration with 1inch is a driving force behind this success. Together, we are dedicated to the ongoing development of new solutions and technologies that cater to the evolving needs of the DeFi community. By harnessing our combined expertise and resources, we have established a strong partnership that will pave the way for further innovations in the decentralized finance ecosystem. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack and bloXroute come together to make Web 3.0 infrastructure more scalable and accessible Experience the enhanced speed, and build for the first time on a Web 3.0 without scalability bottlenecks. We are thrilled to announce that Chainstack will be the very first infrastructure provider to partner with bloXroute, leading Blockchain Distribution Network (BDN) that utilizes a global network of servers optimized for network performance. We might have built our technologies separately, but we were made for each other all along. Paired with Chainstack’s patent-pending Bolt technology enabling fast access to large datasets stored on blockchain nodes, bloXroute Gateways will empower our customers to have access to lightning speed and performance. Thanks to this partnership, Chainstack and bloXroute customers will have access to the fastest gateway on the market to build, deploy, and access decentralized applications. This is, however, just the first phase of a long-term collaboration as we embark on a journey together with the ambitious goal to solve Web 3.0 accessibility and scalability bottlenecks once and for all. Eyal Markovich, bloXroute Labs Co-Founder and COO, voiced his excitement for our new partnership: “We’re excited about the opportunity to partner with Chainstack to further develop a robust Web 3.0 infrastructure. “Chainstack’s focus on simplifying launching and scaling decentralized networks and applications, paired with bloXroute’s focus on simplifying and optimizing blockchain networking and scalability, merge to a common goal: drive blockchain adoption with smarter and faster infrastructure. “Deploying the BDN on Chainstack’s Ethereum nodes is just the beginning. We’re looking forward to working closely with Chainstack to grow their community through joint marketing programs and developing new offerings on a continuous basis.” What is bloXroute? The bloXroute Gateway is open-source software that acts as the entrypoint for blockchain clients such as Geth to bloXroute’s BDN, passing transactions and blocks between the blockchain client and the rest of the BDN. The Gateway talks to the blockchain client using the blockchain client’s native peer-to-peer communication protocol. From the perspective of the blockchain client, a gateway is simply another peer in the network. To use bloXroute, the Gateway should be installed on a server with low latency to the blockchain client and configured to communicate with it. Chainstack automated this process and made Gateway installation and configuration transparent and seamless for all Ethereum managed service customers. In Prof. Aleksandar Kuzmanovic, Co-Founder and Chief Architect, own words, “bloXroute’s uniqueness lies in the way it helps propagate information in a blockchain network. Contrary to first-generation relay networks, bloXroute propagates transactions among blockchain nodes. By propagating transactions on behalf of users, bloXroute manages to effectively index these transactions using much shorter IDs. Thus, when blocks are propagated through the network, bloXroute utilizes such IDs, effectively compressing the amount of data that needs to be carried through the network. Additionally, bloXroute optimally streams data through a well-provisioned dedicated network infrastructure and enables the processing of thousands of on-chain transactions per second.” What does this mean for the Chainstack community? Starting from the next platform release, the Chainstack community will enjoy complimentary bloXroute Gateway with all our dedicated Ethereum mainnet nodes, accessible via Chainstack Marketplace. This is just the beginning, as we will add more features and capabilities over time. Initially, bloXroute Gateway will enable faster propagation of transactions and blocks on the Ethereum nodes operated by Chainstack. Moving forward, we’re going to support advanced bloXroute functionality such as transaction streaming and sending transactions to the BDN, which means that Chainstack innovators will be able to hear of transactions and blocks faster, and send transactions faster. Benefits of bloXroute solution for the customers include but not limited to: Be more likely to win “race scenarios” like liquidating CDPs. Be able to capture arbitrage opportunities. Increase chances of being mined in the next block. Increase chances of beating fee congestion. Always be among the first to know the latest state, thus quickly identify new liquidation or arbitrage opportunities. Glean trading signals from pending transactions. Manage risk market making more efficiently. Be among the first to spot rising fee congestion. Experience the future of Web 3.0 The partnership with bloXroute, so crucial to scaling Web 3.0, marks a major milestone for us, as the first step towards building an ecosystem of tools and solutions for the entire community of DeInnovators. Our mission remains to create an ecosystem that empowers collaboration thanks to best-in-class synergetic products and cutting-edge engineering. The future of an accessible and scalable decentralized infrastructure is here, and by being part of the Chainstack community, you are leading the way. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Chainstack and POKT Network: Unfolding a new chapter in decentralized Web3 infra In an industrious move significant to the Web3 infrastructure landscape, Chainstack and POKT Network have forged a strategic partnership. Our work together is geared towards accelerating decentralization, delivering top-tier service, and enabling quicker onboarding of chains. Let’s explore the details! What are POKT Network Gateways? It’s no doubt an exhilarating time for both Chainstack and POKT Network. POKT Network’s recent announcement of the integration of three new Gateways marks an unprecedented progression in the road to decentralization. Developer DAO, Raid Guild, and we at Chainstack have joined forces with POKT Network, thus expanding the network’s reach from a single Gateway just seven months ago to a total of six. “Collaborating with Chainstack brings POKT Network’s infrastructure to new audiences, driving growth through underlying infra that is owned and governed by its users but accessed through one of the most professional service providers in Web3. We’re proud to under-dePIN their top tier service and features with the unmatched resilience and scalability of truly decentralized infrastructure.” The POKT Network Team Simultaneously, these Gateways are enabling a healthy development of services and features, improving performance and fostering demand through targeted offerings for specific use cases. The newly introduced Gateways are pioneers in a new era, ushering in demand-side decentralization, anticipated as the true business model innovation of DePINs. As the gatekeeper of the Universal RPC Infra Layer, POKT Network, in collaboration with Chainstack and other Gateway providers, is strategizing to disperse control and empower more entities, thereby encouraging diversity, speed, and competition while preserving quality. What is the Universal RPC Infra Layer? The Universal RPC Infra Layer stands as a pillar of resilience and versatility, and acts as the backbone of the innovative Gateway strategy, benefiting from its inherent capabilities of scalability and robustness. Gateways can tap into this resource-rich layer, which promises 100% uptime, <25ms latency, and easy connectivity to over 60 different chains via 15K+ nodes scattered across 22 countries. This allows startups a chance to bypass the race of infrastructure buildup and instead dedicate their resources to improving upon existing standards, fostering innovation and quality service provision. Such a layered approach curates more efficient, reliable, and versatile networks, which in turn translates into benefits for end consumers and businesses. As a POKT Network Gateway provider and part of this DePIN Universal RPC Infra Layer, Chainstack is already making its mark by already onboarding: Klaytn Moonbeam Celo More coming soon… Demand-side decentralization: DePIN’s business model Propelling Web3 infrastructure into a new era, our integration with POKT Network presents the novel concept of demand-side decentralization. This shift in focus from supply to demand decentralization is at the core of both Chainstack’s and DePIN’s business models. DePIN’s strategy revolves around encouraging multiple entities to become access points to the Universal RPC Infra Layer. The intention is to diversify the pool—creating space for more players to build front-end features, engage with clients, and provide customer support. By decentralizing control, we aim to nurture a vibrant ecosystem catering to a variety of customer needs. Instead of playing a game of catch-up, infrastructure startups can now rely on Chainstack and other DePIN Gateways on POKT Network’s Universal RPC Infra Layer. This liberates resources, allowing companies to introduce and scale innovative solutions faster. “Our partnership with POKT Network as a Gateway provider underscores Chainstack’s commitment to scalable and reliable Web3 infrastructure. This collaboration enhances our platform’s ability to support developers and enterprises with market-ready blockchain solutions, ensuring seamless access and driving innovation in a decentralized landscape.” Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together Overall, POKT Network’s expanded Gateway strategy represents a significant stride not just for the network itself, but for the evolution of Web3 infrastructure as a whole. The introduction of Chainstack into POKT Network’s DePIN Gateway portfolio underscores the potential and adaptability of the network. What the network envisages is not just an expansion in numbers but a radical transformation of the Web3 landscape. By pioneering the demand-side decentralization model and challenging traditional notions of infrastructure development, DePIN is shaping the future of Web3. Our partnership with POKT Network echoes this commitment to pushing boundaries and delivering superior service. With other integrations on the horizon, our growth story with POKT Network is an ongoing one. As we continue to revolutionize Web3, one thing is certain: Chainstack and DePIN is a force to be reckoned with in our decentralized future. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Aptos Today, the Chainstack team is thrilled to announce yet another addition to our growing list of supported chains by welcoming the Aptos protocol on our platform. This means you will have the option to deploy an Aptos node across all of our subscription plans. Thanks to this new integration, launching an Aptos node as a foundation to build and scale decentralized applications (DApps) has become more accessible than ever thanks to our reliable enterprise-grade infrastructure. So you can leave the burden of managing nodes with us and start allocating more of your precious time toward building and generating value with your Web3 project. We are thrilled to see Chainstack incorporate Aptos into their existing tech stack. With this integration, it is now easier for Aptos developers to get their products live on mainnet. Austin Virts, Director of Ecosystem, Aptos What is Aptos? The Aptos protocol is a layer 1 proof-of-stake (PoS) blockchain focusing on user experience, safety, and scalability – and is the lowest latency, highest throughput blockchain in the market. Aptos is able to achieve exceptional performance in terms of Time-to-Finality (TTF) and Transactions per second (TPS) through its modular architecture, which allows for decoupled transaction dissemination and consensus Building on Aptos The Aptos blockchain natively integrates the Move language. Move is an expressive and accessible programming language emphasizing security, and designed for safe asset management. Move brings to Web3 what Rust brought to infrastructure development – a safe, fast, and expressive method for mapping interactions. Move was initially designed for the predecessor of the Aptos blockchain, and many of the original Move creators work on the Aptos Labs team today. In the Move ecosystem, you will find a compiler, virtual machine, and other relevant developer tools. Aptos smart contracts Speaking of smart contracts, on Aptos, they are called “modules” instead. An Aptos module houses the bytecode (written in Move), where data types (structs) and procedures are declared. The language puts resource scarcity, preservation, and access control in the spotlight, while its modules outline their lifetime, storage, and access patterns in every resource. What is unique about Aptos and Move is that a module can depend on other modules like itself, which serves to enable code reuse. To facilitate this, modules are grouped into packages on-chain together with bytecode and package metadata. Based on this metadata, a package can be upgraded or immutable moving forward. Aptos architecture Move focuses on fast and secure transaction execution and is based on the Rust language, making data ownership explicit on the language level. In turn, the Aptos protocol leverages batch processing for transactions, execution, storage, and ledger certification phases to maximize efficiency every step of the way. At the same time, this also enables reordering, reduction of operations, and parallel execution. Unlike the Bitcoin and Ethereum protocols, finality is deterministic instead of probabilistic in Aptos, implying TTF matches block time, and one block is sufficient to mark an operation as final. This means that technically it is possible to reverse transactions but doing so is highly impractical economically speaking. As a result of these architectural decisions, the Aptos protocol is able to reach TTF in less than 1 second and a maximum TPS of 160K. BlockchainTickerTTFMax TPSCurrent TPSAptosAPT<1 second160,0002,100SolanaSOL2.5 seconds120,000 (710,000 on a 1GB network)2,600AvalancheAVAX0.15 (record) 1.3 – 3.4 seconds4,500 per subnet4.4FantomFTM1 second4,5007.3EthereumETH78 seconds (6 confirmations)4512.9BitcoinBBTC60 minutes (6 confirmations)73Figure 1: Aptos finality and transaction speed protocol comparison; Source: Pontem Network   How to use Aptos on Chainstack Getting started with Aptos on the Chainstack platform is both quick and easy: Log into the Chainstack console Pick an appropriate cloud provider Select a low-latency location to deploy your Aptos node And best of all: everything is available in a single, consolidated dashboard that allows you to manage all your nodes easily and efficiently. As such, deploying Aptos nodes on the Chainstack platform is truly as pleasant as a nice relaxing walk in the park. The time to claim your rightful place amongst Aptos early adopters has come! Start making the most of all the advantages this unique protocol brings to the table and complement your Web3 project with outstanding infrastructure from Chainstack. Pricing Thanks to Chainstack’s robust RPC infrastructure and best-in-class engineering, it’s now possible to reach maximum efficiency, while lowering the overhead costs of managing Aptos nodes. For you, this directly translates into commitments that are as flexible as they are affordable—a match made in heaven for your budget and project needs. Get the powerful feature set that Aptos offers with a commitment-free introduction rate for full elastic nodes with the Developer plan. While you’re at it, take advantage of up to 3M complimentary requests that ship together with the free subscription. Want to get more bang for your buck? Rest easy, as all Chainstack paid subscription plans are tailor-made to offer you just that. This means you get to deploy Aptos nodes for any project size or stage in a manner that is both adaptable and price-competitive. As a result, you will be pleasantly surprised to discover 8M or four times as many requests at your disposal should you opt-in for the Growth plan. Meanwhile, picking the Business plan will grant you even more–20M, or ten times more, and no limits whatsoever for dedicated nodes with this plan or higher. But what if you reach your limit for requests? Then simply claim some more at the affordable rate of $10 per 1M for the first 20M requests and half the price for those above at $5 per 1M. And if math and accounting are not in your CV just give our pricing calculator a try on its page here. Swift layer 1 transaction processing and finality At Chainstack, we make sure to bring optimal value with each new protocol we extend support to, and Aptos was a perfect match. Sporting outstanding transaction processing and finality that guarantee exceptional opportunities to scale any DApp, Aptos has earned its rightful place on the Chainstack platform. And in making it available to Web3 developers like yourself across the world, we are thrilled to place another block towards a better experience for all. As a fresh take on the scalability trilemma, Aptos has made steady waves across the Web3 landscape by delivering outstanding results in terms of transaction processing and finality. They have claimed a deserved spot among the top protocols available on the Chainstack platform. Eugene Aseev, Founder and CTO of Chainstack With the introduction of Aptos on Chainstack, taking advantage of the protocol’s exceptional performance is now more accessible than ever, supported by our reliable RPC infrastructure. And thanks to Aptos’s excellent throughput, Web3 developers on the Chainstack platform can enjoy building and scaling DApps of any size and project stage that much more. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Arbitrum It’s time for yet another awesome update, as Chainstack announces support for Arbitrum Nitro, following the official going live date on its first anniversary of August 31. This means you will be able to take advantage of this powerful upgrade with the option to launch your own Arbitrum Nitro RPC node, as part of the services offered under all existing plans. We’re happy to have Chainstack fully supporting Arbitrum One now that the migration of Nitro has been complete! We believe that to build an ecosystem, support is needed at all levels. With Chainstack’s full support we’re excited to keep empowering the Arbitrum ecosystem with infrastructure that will continue to provide for the community.A.J. Warner, Chief Strategy Officer of Offchain Labs What is Arbitrum Nitro? Arbitrum is a Layer 2 scaling solution for the Ethereum network that leverages optimistic rollups to introduce a number of efficiency improvements to transaction processing and their costs. To do this, Arbitrum bundles several off-chain transactions together in a batch, prior to parsing the result to the Ethereum network. At present, it is one of the most used solutions for scaling, generating a total value locked (TVL) of over $960M at the time of writing. Once launched, Nitro will offer even faster transaction processing, lower costs, and better UX to do just that. According to Offchain Labs, the company behind its development, Nitro serves as the “most advanced rollup stack ever built.” Building on Arbitrum Nitro In its essence, Nitro delivers a new prover that will replace Arbitrum’s typical interactive fraud proofs by means of a WebAssembly (WASM) implementation. In turn, this allows the Arbitrum L2 engine to be written and compiled using common languages and tools while removing the current custom in-house options used presently. The most interesting engineering factor behind Arbitrum Nitro is that it is essentially running Geth on Layer 2 on top of the Ethereum network, while proving fraud through the core Geth engine in a WASM implementation. To make this a reality, Arbitrum Nitro compiles the EVM engine that defines the Geth core and in doing so replaces the previous in-house EVM emulator. This translates into validators and nodes running the Nitro engine as a native code compilation and switching to WASM to serve fraud proof when needed. And the best thing about it? It will all feature a seamless migration to the Nitro stack, resulting in an uninterrupted experience for users, while kickstarting the benefits of lower fees, higher capacity, and a faster experience all across the board. At the same time, it is important to note that the upcoming Arbitrum stack is quite flexible just as well and makes building new scaling modes on top of it a walk in the park and a faster one at that too. The Nitro update offers a sneak-peek into the technology that powers Arbitrum AnyTrust chains, whose aim is to deliver a scaling solution that is as affordable as it is secure – a perfect fit for both gaming and social decentralized applications. How to use Arbitrum Nitro on Chainstack Using Arbitrum Nitro on Chainstack is just as easy as it is to launch any other node on the platform: Log into the Chainstack console.Select a cloud provider.Deploy the node in any preferred global location with low latency. This allows both developers and enterprises, interested in building on Arbitrum Nitro to deploy, run, and manage all the nodes they’ve launched within a single, seamless platform. With Chainstack’s help running blockchains at scale becomes truly effortless for any project, regardless of its use case or size. Take part as an Arbitrum Nitro early adopter and seize this opportunity to grab a quick win by attracting its first users. Kickstart your Web3 build on Chainstack today and put value generation at the forefront, with no compromise in terms of speed or security. Pricing With world-class engineering and lean infrastructure by its side, Chainstack provides exceptional affordability and flexibility, when it comes to pricing for Arbitrum Nitro nodes. Come to find this yourself, by taking a closer look at our Arbitrum Nitro introduction pricing package, offering elastic full node deployment starting completely commitment-free on the Developer plan, in addition to 3M requests. And should you be interested in getting more than what the free Developer plan entails, you will be pleasantly surprised to find all subscription tiers are custom-tailored with price competitiveness and cost-efficiency in mind. In turn, this gives projects access, regardless of their use case or the current stage they are in. For paid subscription tiers, the Growth plan offers 8M requests, while the Business one—20M. But what if that’s not enough to fit your needs? Worry not, for you can grab extra requests priced at $0.1 per 10K for the first 20M, followed by $0.05 per 10K for those above. No need to start calculating things yourself, either – just let our handy pricing calculator handle all the heavy-lifting for you, instead. Making Web3 easier and better It is Chainstack’s mission to offer secure and robust infrastructure that delivers utmost performance, when addressing the scalability woes of the many protocols and chains, in order to make Web3 truly accessible and available for every stakeholder involved in its development. Arbitrum is a match made in Heaven when it comes to the scalability and performance of projects within the Ethereum ecosystem. With their latest upgrade – Nitro, OffchainLabs further builds on top of their already exceptional solution and offers even better affordability, capacity, and UX at the same time. We are thrilled to extend support to Arbitrum Nitro at Chainstack and in doing so help developers scale their decentralized solutions more effectively while opening the Web3 doors even wider.Eugene Aseev, Founder and CTO of Chainstack With the help of Chainstack’s accessible enterprise-grade infrastructure, tools, and services, both developers and project teams can now enjoy some extra time on their hands that can be better put more towards generating value with their cutting-edge solutions with less friction and leaner operations. And by adding Chainstack’s high-performance infrastructure to Arbitrum’s exceptional ecosystem, we are thrilled to take part in the successful resolution of the obstacles standing before blockchain adoption. In turn, this helps pave the way to a future that is as efficient as it is connected, where projects and their users reap the benefits of the innovative power of decentralized applications while enjoying better performance and lower fees, just as well. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Aurora Aurora is deprecated on Chainstack and is no longer available for new deployments. Following NEAR’s recent addition to Chainstack’s list of supported networks, we are thrilled to bring you its tandem partner too—Aurora. This means that you are able to launch your own Aurora node as an available option under all subscription plans just as well. Deploying an Aurora node, building, and scaling decentralized solutions on top of it is now that much more accessible with the help of the reliable high-performance infrastructure that Chainstack brings to the table. So, let us lift the stressful burden that comes with running nodes yourself and free more time for efforts that are better put toward the progress of your project. Aurora Labs have always put the building and scaling of decentralized solutions through its infrastructure as a top priority. That has now become even more more accessible with the help of our new partner, Chainstack—that brings reliable high-performance infrastructure to the table which makes the processes more easier, faster and much more secure. Alex Shevchenko, Aurora Labs CEO What is Aurora? Ever since its first steps in 2021, Aurora has been making steady strides to reach its vision of delivering an end-to-end solution for Web3 builders, looking to drive further scalability and throughput toward their operations with complete EVM-compatibility. The platform’s exceptional performance delivers significant improvements to the cost of every interaction, creating a streamlined experience for all. Despite its rather recent entry, there is now more than $180M of total value locked within the protocol, generated from the active contribution of 179 projects that compose its ecosystem. That is why it should come as no surprise to find Aurora among the go-to choices for developers, searching for the means of powering demanding Web3 applications that avoid the dreaded network clogs. Building on Aurora With the SputnikVM fuelling its core, Aurora plays a crucial role in extending NEAR’s Nightshade sharding and the Doomslug BFT to fulfill the needs that many other EVMs may suffer from. Thanks to the wide cross-chain interoperability that the Rainbow Bridge is powering, Aurora builders can enjoy streamlined interactions with external networks just as well. The chain’s powerful set of features has successfully allowed it to achieve an average block time of a single second and finality in mere two. This lightning-fast transaction processing, brought even more stability and efficacy to the network. At the same time, the protocol provides developers with additional flexibility and freedom of choice when it comes to the language of their contracts just as well. While NEAR’s JavaScript, Rust, and AssemblyScript are great, Aurora’s Solidity would be a much more welcome sight amongst those looking to enjoy the same developer experience they’ve always known and loved, as Ethereum-natives. How to use Aurora on Chainstack You don’t need to be a rocket scientist to gain access to the Aurora network with Chainstack. Quite the contrary – all it takes is an easy action set of three: Log into the Chainstack console Pick a cloud provider Choose low latency location In turn, having these available within a single Chainstack dashboard creates a streamlined experience for both developers and enterprises to enjoy, while deploying, running, and managing the nodes that give them access to Aurora’s features. Take this chance to claim your rightful place amongst the early adopters of Aurora and supercharge your project operations with Web3 infrastructure that is as exceptional as it is robust. Pricing There is little need for compromise—enjoy affordable commitments matching both your budget and your needs with Chainstack. Thanks to avant-garde engineering and revolutionary infrastructure, reducing overhead costs of running Aurora nodes while maximizing their effectiveness is just a few clicks from becoming your reality. That is why we invite you to see it for yourself and take advantage of the commitment-free Aurora introduction rate for full elastic nodes under the Developer plan with 3M requests available as part of the bundle. Should you prefer to get a head-start, however, you will be happy to discover that all plan tiers are also tailor-made to give you plenty of bang for your buck. This makes node deployment for any project size or stage both flexible and price competitive. On one hand, the Growth plan grants you access to a set of 8M requests available at your disposal. On the other, opting for the Business one comes with 20M in total with the extra benefit of having no limits for dedicated nodes, which also applies to higher tiers. And should you reach the cap, you can always claim additional requests at $0.1 per 10K for the first 20M and half that price at $0.05 per 10K for amounts beyond the first 20M. Don’t start counting yet hop onto the dedicated pricing page, so our calculator works things out instead. A blockchain tandem for your scaling woes Chainstack aims to bring maximal value with every new addition that is brought to the table. That is why after introducing scalability powerhouse NEAR, making arrangements for its EVM partner was a given. And now with both protocols available on the platform, Web3 developers can make full use of the duo’s exceptional performance and bring it to an even wider range of networks. As the Web3 landscape grows in size so does the complexity of each solution built on top of it. Because of this there is a dire need for protocols that can outpace current demand and anticipate future DApp requirements. NEAR has already made significant progress in this avenue, which is why extending support to its EVM counterpart Aurora is a perfect opportunity to accelerate the pace and offer developers the tools they need to scale their endeavors well ahead of time. Eugene Aseev, Founder and CTO of Chainstack With Chainstack’s steadfast infrastructure powering Aurora, as well as NEAR nodes on the platform, developers now have fairer means of accessing the ecosystem swiftly and reliably. In turn, this allows them to leverage the potent scalability features brought forward by the both chains while having the freedom choose an EVM-based option to maximize the reach of their solutions. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Cronos Chainstack’s protocol streak keeps on going, as we’re happy to announce the addition of the Cronos chain to the list of supported networks on the platform. Because of this, you will soon be able to deploy a Cronos node as an available option under all subscription plans. With Chainstack, launching a Cronos node while building and scaling decentralized applications on top of it becomes much more accessible, thanks to our robust enterprise-grade infrastructure. That being said, it’s time to leave the cumbersome load of managing nodes yourself and instead start dedicating more time toward building and generating value with your project. Cronos was founded with the mission to bring mass adoption into Web3 and self custody experience. With over 300+ and growing Web3 applications deployed on Cronos, the ecosystem is excited to welcome Chainstack to bring low friction, enterprise grade node infrastructure to the Cronos developer community. Ella Qiang, Head of Ecosystem of Cronos Labs What is Cronos? Launched in November 2021, Cronos is the first EVM-compatible layer 1 blockchain network built on the Cosmos SDK, supported by Crypto.com, Crypto.org, and more than 300 app developers and partners. The protocol provides the means for affordable transaction fees, exceptional throughput, and swift finality, which further benefits builders and users alike. Cronos’s mission is to make it easy and safe for the next billion crypto users to adopt Web3, with a focus on DeFi and Web3 gaming. Building on Cronos The Cronos protocol is powered by Ethermint, which allows for the rapid porting of Dapps and smart contracts from Ethereum and EVM-compatible chains. Because of this and thanks to the Inter Blockchain Communications (IBC) protocol powered by Cosmos SDK, Cronos allows for interoperability between Cosmos and EVM ecosystems. Backed by Crypto.com, Cronos ecosystem provides a unique opportunity for Dapp builders to gain access to a retail user base of over 50 million, with a strong interest in crypto and Web3. Cronos ecosystem is also focusing on optimizing Web 3 product user experience by leveraging Crypto.com’s suite of products and services. How to use Cronos on Chainstack Starting to build on Cronos with Chainstack is just as easy as 1-2-3: Log into the Chainstack console Select a preferred cloud provider Pick a node location with low latency And the best thing about this? You can enjoy all these and more in the streamlined experience offered by the single Chainstack dashboard. This truly makes Cronos node deployment on the Chainstack platform a pleasant endeavor. So don’t wait! Claim your spot amongst the Cronos early adopters and start taking advantage of all the benefits the protocol has to offer for your project, supported by exceptional Web3 infrastructure. Pricing With the help of Chainstack’s world-class engineering and robust infrastructure, lower overhead costs of managing Cronos nodes at maximum efficiency are now a reality. This means you get to reap the benefits of flexible affordable commitments that are a match made in Heaven for your budget, as well as the needs of your project. Try it out yourself and start leveraging the powerful features that Cronos brings to the table with a commitment-free introduction rate under the Developer plan for full elastic nodes. Claim your fair share with up to 3M requests readily available with the subscription. And if you’re interested in getting more bang for your buck, you can rest easy knowing that all of Chainstack’s pricing tiers are custom-tailored to do just that. Because of this, deploying Cronos nodes for your project, regardless of its size and stage is as adaptable as it is price competitive. That is why you will find four times as many requests (8M) available at your disposal with the Growth plan. At the same time, should you opt for the Business tier, you get to enjoy even more – ten times, or 20M requests in total plus no restrictions for dedicated nodes for this option and above. There is no need to panic should you reach your limit either – just claim additional requests at an affordable rate of $0.1 per 10K for the first 20M and $0.05 per 10K for those beyond. But if math isn’t your strong suit, you won’t need to calculate it all yourself – all you have to do is hop on to our pricing page and leave that to our calculator. Scaling effectively on layer one Our goal at Chainstack is to ensure maximal value is brought to the table of our customers with every new protocol addition. That is why Cronos was a perfect fit, considering its exceptional capabilities in terms of scalability, interoperability, and swift finality. And by adding Cronos to our list of supported networks, we are happy to make the lives of Web3 developers like yourself that much better. With scalability being one of the key obstacles before the current state of Web3, Cronos has made stellar impressions by not only solving these woes but by doing that on layer one. This makes it a welcome addition to the Chainstack platform and an exciting opportunity for developers to accelerate the pace of adoption across the landscape. Eugene Aseev, Founder and CTO of Chainstack Now with Chainstack’s reliable infrastructure supporting the efforts of Cronos developers, leveraging the protocol’s powerful capabilities is more accessible than ever. And considering the network’s flexibility and efficiency, Web3 developers on the Chainstack platform can enjoy better means of building and scaling their decentralized applications, regardless of the size or stage of their project. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Fuse Fuse is deprecated on Chainstack and is no longer available for new deployments. Have you heard the news? The official inclusion of the Fuse network to the Chainstack list of supported networks is now confirmed as coming soon! Once live, this will give you a fresh new opportunity to deploy a Fuse RPC node for your use case under all subscription plans. Chainstack is the industry standard in delivering dependable and speedy blockchain infrastructure. The collaboration between Fuse and Chainstack is a major step forward in Fuse’s mission to provide excellent development and customer support for the fuse network, the leading open source money infrastructure that focuses on the creation of community-centric payment systems and settlements. The tools and application programming interfaces (APIs) from Chainstack are utilized for the development, operation, and scalability of fuse blockchain applications. We were able to install our blockchain infrastructure on a global scale, across many cloud providers, and with the assurance of a fully secure enterprise-grade solution, all thanks to the tools provided by Chainstack. We could not be more excited to commence on this journey of collaboration, which will result in an improved Fuse Network infrastructure. Mark Smargon, CEO and Co-Founder of Fuse.io Thanks to Chainstack’s robust infrastructure and exceptional performance, deploying a Fuse node is now more accessible to everyone than ever. So, take a break from the typical Web3 woes that come with running your own node and get a swift start into the Fuse network with Chainstack. What is Fuse? Starting its journey in 2019, Fuse embarked on a journey to deliver better access to mobile payments for communities worldwide. With a firm belief in open-source finance, the development team has made steady progress toward making this a reality. Now thanks to their efforts, launching and managing p2p networks has never been easier with simple and easy-to-use tools by your side. And to top it all off, the Fuse network sports a brief block interval of 5 seconds making transaction processing swifter and more affordable than many other alternatives. At present, it is capable of approximately 120 native token transfers or 60 ERC20 ones per second. That is why currently confirming a transaction on Fuse would only cost you roughly $0.01. Now isn’t that handy? Building on Fuse In order to provide adequate Sybil protection, the network takes advantage of delegated Proof of Stake (dPoS), powered by the AuRa algorithm to reach consensus. To secure it, Fuse relies on a diverse set of independent validators with just a single one being run by the core team. On the protocol level, Fuse uses its own in-house VM, which is compatible with EVM. This means you will be able to leverage the powerful set of features it brings to the table across a wider range of networks. Even better – you can deploy any Ethereum smart contract on top of Fuse without any further effort required on your end. And when it comes to cross-protocol connections, Fuse Network is connected to a range of major blockchains via leading third-party interoperability platforms, including Multichain, Connext, Allbridge, Elk Finance, as well as Fuse’s own bridge accessible via the interface on Voltage Finance. How to use Fuse on Chainstack Gaining access to the Fuse network with Chainstack is quite straightforward – log into the Chainstack console, pick a cloud provider you prefer, and deploy the node to any location around the world that fits your needs, especially considering latency. Developers and enterprises looking to leverage Fuse’s advantages can now easily deploy, run and manage all Fuse nodes they are running from a single seamless Chainstack dashboard. Because of this, the entire operations process and scaling it becomes truly a walk in the park for anyone. Seize the opportunity to become one of Fuse’s earliest adopters and grab this quick win in time. Build with Chainstack today and secure reliable high-performance infrastructure for your project with commitment that fits both your needs and budget. Pricing With the help of its cutting-edge engineering and enterprise-grade infrastructure, Chainstack can help organizations drastically reduce the costs of running Fuse nodes and do so at higher efficiency, resulting in pricing that is both affordable and flexible at the same time. But don’t take our word for it – try it yourself by checking out our special Fuse introduction rates that offer zero-fee elastic full nodes with the Developer plan and up to 3M requests available at no extra cost. And if you have some budget to spare too, you will be pleasantly surprised to discover that our subscription tiers are designed with price competitiveness in mind, so you can take advantage of a cost-effective deployment, regardless of the size of your project or the stage you are in. That is why enrolling in the Growth plan will give you access to a total of 20M requests, while having up to 40M under the Business plan. Subscribing to the latter plan or above will also unlock unlimited requests on all dedicated nodes deployed. Still not enough? Grab an extra set of 20M requests at $0.1 per 10K and $0.05 for quantities above that. No need to do the hard math yourself though, just let our pricing calculator do the heavy lifting for you instead. Robust and reliable solutions for Web3 Chainstack makes it easier and faster for enterprises, governments, and organizations to work with blockchain technology. With Chainstack, you can develop, govern, and deploy decentralized protocols and applications securely while reducing complexity, simplifying operations, and lowering costs. It is our mission to develop infrastructure solutions to make Web3 available and reliable for every developer, company, and user, which is why Fuse makes a perfect addition to the Chainstack list of supported networks: Scalability is one of the biggest Web3 woes the current landscape faces, which is why outstanding efforts, such as those brought forward by the Fuse network are certainly a welcome sight. That is why we are excited to begin supporting the valuable contributions of developers interested in building on the protocol, while we offer them the means to launch and scale their solutions faster, easier, and more affordable than what was possible before. Eugene Aseev, Founder and CTO of Chainstack By adding Chainstack’s enterprise-grade infrastructure to Fuse, both users and projects have access to a much faster, more reliable, and inexpensive entry into the network’s ecosystem. And in doing so, we open the door to a more efficient, interconnected tomorrow in which entrepreneurs and end-users alike can benefit from the powerful set of features Fuse brings to the blockchain table, while at the same time enjoying exceptional performance and costs that fit their budget. #### Chainstack announces support for Gnosis Chain We are excited to announce the upcoming addition of the Gnosis Chain to Chainstack’s list of supported blockchains. This means that you can launch your own Gnosis Chain RPC node as part of the available features under all subscription plans. Gnosis Chain is a stable and lean network with proven tailor-made technology that is built for performance. The chain’s faster block and epoch times allow for much greater effectiveness in processing transactions and in doing so minimizing overall network congestion. These traits make Gnosis Chain a powerful addition to any Web3 builder’s toolkit by creating better opportunities for cultivating solutions that can handle substantial transaction volumes with ease. And now with Chainstack’s secure and reliable Web3 infrastructure, accessing the Gnosis Chain network as a developer, researcher, trader, or enterprise is stress-free. What is Gnosis Chain? Established in 2018 as the xDai Chain, the now reformed Gnosis Chain aims to provide the means for value exchange without the risks of volatility. To accomplish this, Gnosis Chain leverages the predictable currency that is the xDAI stable coin for transactions, which has a 1:1 ratio in terms of value to Dai. Additionally, the two cross-chain bridges that Gnosis Chain ships with, will make sure all your network interactions are a truly smooth experience. Thanks to these connections, the network facilitates the transaction process even further, nurturing affordable, lightning-fast transactions, whose fees are paid in a single coin. Pairing all of this with the benefits of faster block and epoch times effectively eliminates any major boundaries, standing in the way of lower congestion and higher transaction stability. And in doing so, Gnosis Chain brings some welcome peace of mind for developers, while paving their way toward exceptional experiences with streamlined applications. Building on Gnosis Chain Gnosis Chain is an EVM-based blockchain network, so if you are an Ethereum-native you will be greeted by the familiar developer experience you know and love. At the same time, however, you also get to access all of the bonus capabilities and scalability features it carries with it. Because of its complete EVM compatibility and extensive cross-chain connections, Gnosis Chain fosters a perfect environment for developers to build exceptional streamlined experiences, regardless of how demanding or ambitious their use case really is. And to top it all off, Gnosis Chain also comes featuring the option for decentralized on-chain randomization with its RandomAuRa RNG contract which enables you to introduce verifiably random numbers into your applications, without having to rely on a centralized service to do it all for you. Pricing With best-in-class engineering and streamlined infrastructure, Chainstack is able to offer competitive, elastic full Gnosis Chain RPC node prices starting at $0/month on the Developer plan, which comes with 3M requests per month. Subscription tiers are thoughtfully designed to provide the lowest possible cost for individual developers and teams in various project stages, allowing all users to use the platform, regardless of their use case. The Growth plan supports 20M queries per month for elastic full node requests and 3M for elastic archive node ones, while the Business plan accommodates 200M and 20M respectively. For the Enterprise plan users, these would be 400M and 60M accordingly. For all additional requests beyond those included in the plan, the price amounts to $0.00001 per request for the first 20M and $0.000005 per request for each above that threshold. Gnosis Chain on Chainstack Gnosis Chain’s approach of delivering exceptional performance, when it comes to transaction processing is a great match for developers building effective solutions for demanding use cases. Thanks to the chain’s extensive cross-chain support, Gnosis Chain paves the way for even greater blockchain adoption in the future. It is certainly a pleasure to join forces with Gnosis Chain in delivering better access to the network’s features and reinforcing it with enterprise-grade blockchain infrastructure.Eugene Aseev, Founder and CTO of Chainstack Meeting the Gnosis Chain developer community There are plenty of Web3 builders leveraging the powerful scalability features of Gnosis Chain already. That is why it should come as no surprise to see some household names too. Some examples of such are Swarm—a decentralised storage and communication system, Chainlink—a decentralized blockchain oracle network, Curve—an exchange liquidity pool, as well as 1inch Network and SushiSwap—two of the most popular DEX platforms currently. That being said, it should become apparent that you will be in good company should you choose to start your developer journey on Gnosis Chain. And now that you know just how impactful this can be, there is little more to do than to take action. Now it’s your turn. Get ready to build! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Harmony We are ecstatic to announce that Harmony is now supported on Chainstack. Harmony developers now have the simplest method to acquire access to the Harmony blockchain, deploy dependable node access in seconds, and focus on building a more unified and efficient future thanks to Chainstack’s highly resilient and scalable infrastructure solutions. Harmony is an interoperable sharding protocol with secure bridges offering cross-chain asset transfers with Ethereum, Binance, and 3 other chains. Harmony is an open platform for assets, collectibles, identity and governance. Powered by the Harmony One token (ONE), the Harmony blockchain is an independent blockchain designed to enable ultra-fast transactions and interoperability as an advanced Layer 2 solution. Harmony makes it easy for developers to build and scale creative, intuitive decentralized applications (DApps) that enable frictionless, cross-chain token swaps. Harmony was established in 2018 and attracted nearly $20 million in funding from both private investors and Binance Labs to create the protocol. The mainnet launched in June 2019. To scale trust and create a radically fair economy, Harmony is granting $300 million to the open DAO community. The total funding will go toward a variety of projects and activities throughout Web3 aimed at connecting all networks and advancing hundreds of DAOs, which will help drive blockchain adoption. What is Harmony? Harmony was designed as an interoperable Layer 2 scaling solution for Ethereum. The interoperable sharded blockchain is built from the bottom up to address the constraints of security, scalability, and decentralization that continue to affect blockchains. Harmony uses a technique called sharding to split the blockchain’s network into parallel chains, called shards, to improve the speed and efficiency of the network—at a lower cost. Thanks to this strategy, Harmony’s fast and secure blockchain is designed for decentralized applications, producing blocks in 2 seconds with finality, allowing for trustless, irreversible transactions at lower fees, costing up to 100 times less than other blockchain transactions. Harmony’s sharding works not only on the network communication and transaction validation, but also on the blockchain state, making Harmony fully scalable on all three aspects of the blockchain: network, storage, and transaction processing. With secure bridges offering cross-chain asset transfers with Ethereum, Binance, and 3 other chains, Harmony provides developers and users with the ability of the frictionless shift of digital assets across the blockchain and bridged chains, greatly supporting the development of both Decentralized Finance (DeFi) and Non-Fungible Token (NFT) applications. Though Harmony is not yet completely decentralized, it is a fundamental project objective. Pangaea is Harmony’s plan for a decentralized, open network community of nodes. This effort furthers the Harmony project’s decentralization by establishing a devoted, linked community. Harmony’s strategic development areas and advancements are critical for mainstream adoption of the Harmony blockchain. Building on Harmony Harmony blockchain is a sharded blockchain with four shards: the beacon chain (shard 0), as well as shards one, two, and three. The production mainnet supports 4 shards of 1000 nodes contributing to the blockchain’s high transaction per second performance. Harmony is built to support cross-shard transactions to achieve composability of assets and smart contracts between shards. Harmony also features receipt-based asynchronous cross-shard communication mechanism which achieves eventual consistency, preventing double-spending between shards. Harmony is a Proof-of-Stake blockchain which is energy efficient and low-cost for node runners. Effective Proof-of-Stake (EPoS) is a unique consensus mechanism used by Harmony. The consensus mechanism incorporates improved innovations of the Practical Byzantine Fault Tolerance (PBFT) to create the Fast BFT (FBFT). This allows for near-instantaneous finality and reduced transaction costs. The purpose of EPoS is to improve network delegation and ensure correct reward compounding, without compromising the decentralization of the network. It allows validators to effectively stake tokens and secure nodes according to the value of those tokens. EPoS is able to randomly and evenly distribute the stakes among all shards, bringing greater decentralization and security to all shards. Harmony uses the Solidity programming language and supports the Ethereum tooling, which makes it essentially identical to Ethereum in terms of development. It features its own token standards, HRC-20 and HRC-721, for cryptocurrencies and non-fungible tokens, similar to Ethereum’s ERC-20 and ERC-721. Harmony on Chainstack Harmony’s integration on Chainstack is another step toward our goal of creating a genuinely multi-chain platform that allows the community to customize their experience while also boosting accessibility and scalability. Harmony and Chainstack’s collaboration will assist with both infrastructure scalability and the healthy expansion of on-chain utility and network features. Developers and builders in Harmony’s ecosystem will now have greater customization for alternative RPC service endpoints, WebSocket connections, and indexed datasets. Furthermore, Chainstack’s node infrastructure will enable improved responsiveness when interacting with the blockchain, bringing it closer to Harmony’s underlying 2-second on-chain finality with flexible deployment locations. Harmony developers and builders will now benefit from a lower latency connection and increased request throughput. Our partnership with Chainstack is a major step forward toward Harmony’s goals of adding an increasing number of partners that can help Harmony scale to billions more transactions per day. We’re thrilled that Chainstack is supporting the tremendous growth in demand for Harmony’s dataset enabling billion dollar TVL DeFi ecosystems and numerous GameFi and Metaverse projects being built on Harmony to now have access to blockchain dataset at scale. Using Chainstack’s game-changing infrastructure, many more projects can now get started and contribute to the Harmony Ecosystem’s growth. We’re excited to collaborate with Chainstack to ensure continuous innovation and growth of Harmony’s infrastructure, user experience, and interoperability.Jack Chan, Engineering and Partnerships, Harmony Chainstack allows developers to deploy and synchronize their nodes within minutes, with predictable pricing that is industry-leading, a high degree of automation, and enterprise-grade infrastructure and engineering. Web3 and DeFi developers and builders that want to build high-performing projects on Harmony now have the option to scale with enterprise-grade infrastructure that can be depended on across various cloud networks and locations. Chainstack blockchain managed services include developer tools and services that make building and managing a DApp, a DeFi platform, or an NFT marketplace easier, in addition to node management and operations. How to use Harmony on Chainstack Chainstack is a dependable and simple-to-use platform for quickly deploying nodes on a variety of hosting platforms, including fully managed public clouds like AWS, Azure, and GCP, as well as on-premises. Companies can now deploy Harmony RPC nodes in the same easy and cost-effective way, without needing to invest precious time and resources in setting up enterprise-grade infrastructure. Developers may entrust their projects to Chainstack and significantly shorten their time-to-market while also benefiting from high-performing and dependable infrastructure. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack has a distinctive price advantage compared to other providers. This is reflected in the introductory pricing for Harmony, which offers shared full nodes starting at $0/month on the Developer plan, along with 3M requests included. Subscription tiers are well planned out to be highly cost-efficient, supporting all projects and use cases in different stages and types. The Growth plan provides 8M requests and the Business plan provides 20M requests. Unlimited requests are available on all dedicated nodes deployed starting on the Business plan. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests; then $0.05 per 10K requests. See also the full pricing information and a handy calculator. Working together on making Web3 faster and better Chainstack is committed to delivering extremely powerful infrastructure solutions and addressing scalability issues with many protocols and chain types to make Web3 available to everyone. Harmony enables developers and builders to create high-performing and customizable applications by utilizing blockchain technology that is designed for interoperability and built in a way that is familiar to developers. Developing at a rapid pace and collaborating with the industry’s most recognized smart contract-enabled blockchains, transactions between the Harmony and other blockchains are almost instantaneous and nearly free, paving the way for a more connected Web3. Harmony’s focus on growing the network’s features is supported by an incredible community and ecosystem. The cross-chain architecture bodes well for the blockchain’s future and greater adoption. We’re delighted that Chainstack will now give Harmony developers and the community more access to on-chain utility with enterprise grade blockchain infrastructure, assisting them in addressing blockchain scalability challenges.Eugene Aseev, Founder and CTO of Chainstack Chainstack’s enterprise-grade, easy-to-use infrastructure, tools, and services enable developers and project teams to focus on developing breakthrough blockchain solutions and apps by reducing friction and improving operational operations. The addition of Chainstack’s enterprise-grade infrastructure to Harmony’s ecosystem accelerates blockchain adoption, paving the way for a more connected and efficient future in which projects and end-users can benefit from decentralized applications’ innovative power while also enjoying higher performance and lower fees. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for NEAR NEAR is deprecated on Chainstack and is no longer available for new deployments. We are excited to announce that Chainstack is now supporting NEAR protocol. Moving forward, developers and enterprises of all sizes will be able to deploy, run, and manage nodes on NEAR much more easily. NEAR champions initiatives that can bring more options for users, and help advance NEAR’s mission to bring about mass adoption. Chainstack’s goal to make running nodes simply aligns with that vision. Marieke Flament, CEO, NEAR Foundation With Chainstack, anyone can conveniently access a full elastic node on NEAR in just a few minutes, avoiding time-consuming, laborious infrastructure work and, most importantly–regaining the time to focus on building exciting and innovative tech for their projects. What is NEAR? NEAR was founded in August 2018 with the mission to offer a platform for developers that can be scaled to mass usage and is both user-friendly and climate and carbon neutral. NEAR is a Layer 1 protocol that combines a Proof-of-Stake consensus mechanism with a horizontal scaling approach through sharding. So, let’s take a better look at what this means for all developers wanting to build on NEAR. Building on NEAR NEAR combines a Proof-of-Stake consensus mechanism (called Doomslug) with a sharded infrastructure (called Nightshade) to scale transaction throughput. With sharding, NEAR splits the network into parallel sub-networks, or shards, and dynamically distributes the computation, yet it maintains a single chain of data; this allows for an overall greater network’s processing capacity. See Doomslug and Nightshade. Because of this, transaction fees are extremely low, typically at less than $0.01, and the finality is at near second time. Thanks to the Rainbow Bridge, NEAR allows users to transfer ETH back and forth between Ethereum and NEAR seamlessly. See Rainbow Bridge. With Aurora, an EVM-compatible Layer 2 scaling solution, NEAR enables all developers to launch and scale their Ethereum decentralized applications on NEAR’s network. See Aurora. Finally, NEAR provides all developers with an integrated developing stack of tools that features: A command-line tool to build and deploy smart contracts. See near-cli. An SDK in two versions–Rust and Assembly Script–to write the contracts themselves. See near-sdk-rs. A local node to set up a testing environment in which to write and execute tests. See near-sandbox. API libraries to interact with the protocol programmatically in various languages such as Javascript. See near-api-js. How to use NEAR on Chainstack To use NEAR on Chainstack, log into the Chainstack console, select a cloud provider, and deploy a node in any global location that best suits your needs—consider latency, for example. With Chainstack, developers and enterprises wanting to build on NEAR can now deploy, run, and manage their nodes all from one single, seamless platform. Chainstack makes running blockchains at scale truly effortless for everyone. Be one of NEAR’s earliest adopters and capitalize on this to win its first users. Start building with Chainstack today and add the value you need without compromising on speed or security. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack is able to provide extremely affordable and flexible pricing for NEAR nodes. Discover this yourself by exploring our introductory pricing for NEAR, which offers elastic full nodes starting at $0 per month on the Developer plan, along with 3M requests included. Subscription tiers are purposefully structured to be price-competitive and cost-efficient, supporting all projects and use cases in different stages and types. The Growth plan provides 8M requests, and the Business plan offers 20M requests. Unlimited requests are available on all dedicated nodes deployed starting on the Business plan. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests, then $0.05 per 10K requests. See the complete pricing information and try our handy price calculator. Making Web3 easier and better Chainstack’s mission is to deliver high-performance, secure, and robust infrastructure solutions to address the scalability issues of many protocols and chains in order to make Web3 truly available to everyone. NEAR is purposefully built with a focus on scalability, performance, and interoperability—with both users and developers in mind. At Chainstack, we are thrilled to be able to support all developers wanting to build on NEAR, providing them with a way to launch and scale their applications much more effectively and, ultimately—open the doors to Web3 for more people. Eugene Aseev, Founder and CTO of Chainstack Chainstack’s enterprise-grade, easy-to-use infrastructure, tools, and services enable developers and project teams to focus on developing breakthrough blockchain solutions and apps by reducing friction and improving operational operations. Adding Chainstack’s enterprise-grade infrastructure to NEAR’s ecosystem accelerates blockchain adoption, paving the way for a more connected and efficient future in which projects and end-users can benefit from decentralized applications’ innovative power while also enjoying higher performance and lower fees. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for Solana blockchain We are thrilled to announce that Solana is now fully supported on Chainstack. With Chainstack’s extremely robust and scalable infrastructure solutions, Solana developers now have the easiest way possible to gain access to the Solana blockchain, deploy reliable access within seconds and focus on building a more connected and efficient future. Solana is an open-source project that implements a new permissionless, high-performance blockchain. The Solana blockchain, which debuted in 2020, can execute up to 65,000 transactions per second at a cost of approximately $0.01 per transaction. Solana Labs raised $314.2 million early in 2021 from investors, including venture capital firm Andreessen Horowitz. Today, Solana already includes hundreds of Web3 apps. What is Solana? Solana is a permissionless network protocol with parallel smart contract processing functionality. A decentralized blockchain designed to provide the world with scalable, user-friendly apps. Solana has the status of being the industry’s fastest blockchain. Furthermore, Solana accomplishes this without sacrificing decentralization or security. Solana has the fastest growing blockchain ecosystem in crypto, providing the best environment for building hundreds of projects spanning DeFi, NFTs, Web3, and more. Solana has a unique proof-of-history feature that allows for decentralized, trustless transaction sequencing based on submission time, resulting in unprecedented speed and capacity. Validators can execute hundreds of smart contracts simultaneously, resulting in substantially faster block confirmations, more capacity, and lower transaction costs overall. Solana also has Ethereum compatibility thanks to a cross-chain bridge between the two chains. Scalable for global adoption. Solana maintains a single global state as the network expands, ensuring composability amongst ecosystem projects. By leveraging hardware and bandwidth, Solana RPC nodes can be tuned and adjusted to improve the network’s scalability, speed, and even lower fees. As a result of this competitive advantage, the network becomes faster as technology progresses. Solana is not just ultra-fast and low-cost, but it is also censorship-resistant due to its decentralized structure. Building on Solana The languages Rust C and C++ are used in Solana to create smart contracts that are deployed on-chain. Smart contracts, also known as programs in Solana, are essential for creating unique and powerful tools on the blockchain. These applications are created and distributed on-chain, and they are executed through the Solana Runtime, which keeps them running indefinitely. Developers may utilize the Solana ecosystem’s frictionless development tools to recreate the Solana user experience in their own decentralized apps (DApps). DApp development is quite similar to how Web2 and Web3 developers construct web apps in centralized applications, interacting with centralized APIs via 3rd party SDKs. There are many 3rd party SDKs that have also been built on top of the JSON RPC API such as Java, C#, Python, Go, Swift, Dart-Flutter and Kotlin. Furthermore, Solana Labs has designed an easy-to-use solana-web3.js SDK that allows developers to communicate with the blockchain and Solana programs in the same manner that you would with any other API. Solana on Chainstack Solana can achieve elevated levels of scalability and performance even without the use of layer-2 solutions. The inclusion and implementation of timestamps for each transaction using a proof-of-stake, proof-of-history consensus makes network synchronization remarkably simple, enabling high throughput. This was previously impossible until Solana. Solana’s capabilities make it simple to create thousands of projects in a variety of categories, including Web3, DeFi, and NFTs. The addition of Solana to Chainstack is yet another step toward our objective of building a truly multi-chain platform that gives the community more customizability while simultaneously improving accessibility and scalability. Scalability and transaction costs are two of the most frequently mentioned roadblocks to the development of blockchain-based ecosystems. To make Web3 accessible to all, Chainstack is determined to create incredibly powerful infrastructure solutions and resolve scalability challenges with various protocols and chain types. Chainstack allows developers to deploy and synchronize their nodes within minutes, with predictable pricing that is industry-leading, a high degree of automation and enterprise-grade infrastructure and engineering. We are excited to have Chainstack join the Solana ecosystem.Dan Albert, Executive Director, Solana Foundation Web3 and DeFi developers and builders that want to build high-performing projects on Solana now have the option to scale with enterprise-grade infrastructure that can be depended on across various cloud networks and locations. Chainstack blockchain managed services include developer tools and services that make building and managing a DApp, a DeFi platform, or an NFT marketplace easier, in addition to node management and operations. How to use Solana on Chainstack Chainstack is a dependable and simple-to-use platform for quickly deploying nodes on a variety of hosting platforms, including fully managed public clouds like AWS, Azure, and GCP, as well as on-premises. Companies can now deploy Solana RPC nodes in the same easy and cost-effective way, without needing to invest precious time and resources in setting up enterprise-grade infrastructure. Developers may entrust their projects to Chainstack and significantly shorten their time-to-market while also benefiting from high-performing and dependable infrastructure. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack has a distinctive price advantage compared to other providers. This is reflected in the introductory pricing for Solana, which offers shared full nodes starting at $0/month on the Developer plan, along with 3M requests included. Subscription tiers are well planned out to be highly cost-efficient, supporting all projects and use cases in different stages and types. Growth plan will provide 8M requests and Business plan provides 20M requests. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests; then $0.05 per 10K requests. See also the full pricing information and a handy calculator. Working together on making Web3 faster and better Solana is ideally positioned within the blockchain industry to gain widespread adoption of its impressive blockchain implementation. We’re thrilled that Chainstack enables developers’ greater access to numerous chain types and helps them deal with blockchain scalability issues, supporting Solana and its ecosystem to thrive.Eugene Aseev, Founder and CTO of Chainstack Solana enables developers and builders to create high-performing, interoperable and customizable applications by utilizing blockchain technology that is designed for performance and scalability. By minimizing friction and optimizing operational procedures, Chainstack’s enterprise-grade, easy-to-use infrastructure, tools, and services enable developers and project teams to focus on building breakthrough blockchain solutions and applications. The addition of Chainstack’s enterprise-grade infrastructure to Solana’s ecosystem accelerates blockchain adoption, paving the way for a more connected and efficient future in which projects and end-users can benefit from the innovative power of decentralized applications while also enjoying higher performance and lower fees. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack announces support for StarkNet We are excited to support StarkNet—the very first L2 rollup protocol on Chainstack. STARK, it’s in the name STARK stands for Succinct Transparent ARgument of Knowledge and is a proof system invented at StarkWare. ZK-STARK, or a zero-knowledge STARK, is the core of the software stack of the products by StarkWare. StarkEx is the first ZK-STARK product and is a permissioned standalone customizable scaling engine. It processes massive batches of transactions off-chain, and then sends a data update and a STARK proof to be accepted on Ethereum. StarkEx has been proven to successfully power the Web3, DeFi, and GameFi projects like ImmutableX, dYdX, Sorare, and DeversiFi, saving millions of USD worth in gas fees every week. In other words, StarkEx is a single operator app-specific rollup. StarkNet is the second ZK-STARK product and is a permissionless decentralized ZK-Rollup (or Validity Rollup). The current StarkNet network is in alpha and has been live on Goerli testnet since June 2021, and it has been live on Ethereum mainnet and since November 2021. From StarkEx to StarkNet Started as a single-operator single-app zero-knowledge scaling engine (StarkEx) that has been successful for the Web3 applications, the knowledge protocol implementation has moved to the single-operator multi-app rollup with the launch of StarkNet Alpha. In 2022, StarkNet is expected to open-source the engine to move on to the next implementation stage, which is a decentralized operators multi-app rollup to the Ethereum mainnet. The StarkNet architecture Currently, the StarkNet architecture consists of the following core components: Sequencer — a closed source component that decides what sequence of transactions will be included in the next block. The Sequencer sends the block to a Prover. This is done on L2.Prover — a closed source component that computes a proof of the L2 state and submits it to the Verifier. This is done on L2.Verifier — an open-source contract on Ethereum that verifies the proof. A StarkNet full node There is a read-only StarkNet full node implementation written in Rust by Equilibrium. The full node implementation is Pathfinder. With the Pathfinder node, you get the following features on StarkNet: Access to the full StarkNet state history, including contract code and storage, and transactions.State verification using the L1 contracts.Calculation of the StarkNet state’s Patricia-Merkle Trie root on a block-by-block basis and confirmation of the root against L1.Ethereum-like RPC API.Ability to run StarkNet functions without requiring a StarkNet transaction—execution against the local state. Building on StarkNet The core language powering StarkNet and the contracts that you can deploy on StarkNet is Cairo. Cairo is a Turing-complete production-ready language. See Cairo. OpenZeppelin is implementing the standard battle-tested contracts that it is known for in Cairo. OpenZeppelin is also building Nile—a development framework and a tool for StarkNet smart contracts in Cairo. You can also use the StarkNet CLI to interact with StarkNet—from querying the network to compiling and deploying contracts and submitting transactions to the Sequencer. The growing ecosystem The StarkNet ecosystem is rapidly expanding, and there are weekly additions of new projects joining the party: bridges, DAO, DeFi, GameFi, Governance, Infrastructure (you are here with Chainstack), NFT, payments, tools, and wallets. See: StarkNet ecosystemAwesome StarkNet StarkNet on Chainstack Chainstack’s integration of StarkNet is an important step in supporting the explosive growth of the StarkNet ecosystem of DApps, services, users, and developers. Chainstack is a leading provider of full-node services for blockchains. StarkNet’s partnership with Chainstack is an important step towards supporting the thousands of developers and billions of users we anticipate on StarkNet, the leading Validity Rollup on Ethereum. We are thrilled to embark on this joint collaborative journey that will improve StarkNet’s infrastructure.Eli Ben-Sasson, co-Founder and President at StarkWare How to use StarkNet on Chainstack Log into the Chainstack console and deploy a node with a cloud provider and in the location that best suits your needs—such as latency considerations. Be one of the earliest StarkNet adopters with Chainstack, start building today, and be among the first to win the users in the L2 wave of adoption that you know is coming and will be here before you know it. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack has a distinctive price advantage compared to other providers. This is reflected in the introductory pricing for StarkNet, which offers shared full nodes starting at $0/month on the Developer plan, along with 3M requests included. Subscription tiers are well planned out to be highly cost-efficient, supporting all projects and use cases in different stages and types. The Growth plan provides 8M requests, and the Business plan provides 20M requests. Unlimited requests are available on all dedicated nodes deployed starting on the Business plan. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests; then $0.05 per 10K requests. See also the full pricing information and a handy calculator. Making the L2 rollups happen en masse Chainstack is committed to delivering extremely powerful infrastructure solutions and addressing scalability issues with many protocols and chain types to make Web3 available to everyone. StarkNet is the very first ZK-Rollup (aka Validity Rollup) supported by Chainstack, and it is exciting to be providing the infrastructure to the growing DApp and service ecosystem on the innovative L2 solution. It’s amazing to see StarkNet and Equilibrium committing to the L2 ecosystem running on the zero-knowledge STARK protocol with enterprise-level infrastructure. These are very exciting times to be prepared to support the Cambrian explosion of DApps and services that about to happen. It’s a firehose of innovation.Eugene Aseev, Founder and CTO of Chainstack Chainstack’s enterprise-grade, easy-to-use infrastructure, tools, and services enable developers and project teams to focus on developing breakthrough blockchain solutions and apps by reducing friction and improving operational operations. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack awarded a $60K grant for Kubernetes automation from The Graph Foundation We are thrilled to announce that we have received a $60K grant from The Graph Foundation Grants program for Kubernetes automation, which will contribute to the growth of the ecosystem by radically simplifying the deployment of The Graph nodes and related infrastructure. Chainstack and The Graph The Graph is the indexing and query layer of the decentralized web. Developers build and publish open APIs, called subgraphs, that applications can query using GraphQL. The Graph currently supports indexing data from Ethereum, IPFS, and PoA with more networks coming soon. To date, over 8,000 subgraphs have been deployed by over 10,000 active developers for applications such as Uniswap, Synthetix, Aragon, Gnosis, Balancer, Livepeer, DAOstack, AAVE, Decentraland, and many others. The Graph Network has been live for three months now with over 160 Indexers and 6,000 Delegators onboard. Over 2.7B GRT (27% of all GRT) has been staked and delegated by Indexers and Delegators, equating to $4.3 Billion TVL—a testament to The Graph’s community and the participation in the network. Graph Node services that indexes Ethereum blockchain have been included in our Marketplace since 2020. The indexes (“subgraphs”) can then be queried with GraphQL API. Thanks to the grant received as part of the Wave 1 allocation, Chainstack will create a radically simple open-source Kubernetes automation setup. What is The Graph Foundation Grants program? The Graph Foundation Grants were introduced to steward The Graph ecosystem into the future by supporting the network participants and the community. Over the last three months, the Foundation has been focusing on creating a nurturing ecosystem and funding the most critical additions to the protocol and tooling, useful DApps and subgraphs, and expanding the community. The Foundation’s role is intended as a facilitator, bringing together the best builders and resources to improve the protocol and grow the ecosystem. To date, ~$3M has been budgeted for the year for Ecosystem Contributors who are aligned with the protocol’s long-term success, divided into Foundation Operations ($400K+), Bounties & Audits ($500K+), Community & Development ($500K), and Research ($1.4M). In total, ~$2.6M have been allocated in Wave 1 grants. Chainstack project for The Graph The grant won by Chainstack, chosen among over 200 grant applications from more than 10 countries, responds to the call to develop and open-source standardized deployment tooling and best practices for The Graph nodes using Kubernetes. Wave 1 applications were assessed based on their relative significance and urgency, expected impact and community feedback. Interviews were taken by over 15 Domain Experts from across the ecosystem who specialize in each grant category. The Graph Foundation Chainstack will develop, maintain and support automation to simplify the deployment of The Graph nodes and related infrastructures like IPFS/Ethereum nodes and PostgreSQL database. The end goal is for anyone to be able to deploy The Graph toolkit in their own infrastructure in a matter of minutes and not hours or days. The automation will be developed for Kubernetes as the leading infrastructure orchestration platform which allows sophisticated deployment similar to The Graph. Technical deliverables Getting into more technical details, Chainstack will develop a Kubernetes setup that includes proper setup of the Indexer Agent and Indexer Service (decentralized network components) as well as Graph Node. The Chainstack team will create Helm charts to perform the same infrastructure setup as their current Kubernetes manifest setup. This will provide another layer of abstraction and simplify the process to a few configuration lines and 1one or two commands. This set up will include PostgreSQL, IPFS node, index nodes, query nodes, and indexer components. Chainstack will also create an automated deployment for other cloud providers and on-premises Kubernetes configurations in addition to Google Cloud for which it already has detailed instructions. This will likely be delivered as a set of Terraform scripts with detailed documentation and potentially a CLI to control them. A new powerhouse for the growth of Web3 Our mission is to make blockchain network deployment and management radically simple, something that will be key to succeed in widening adoption and development for the Web3. In line with The Graph Foundation’s goal, easy-to-use and more affordable infrastructure will allow for blockchain data to be accessed by more builders and to be used to create better applications. Thanks to this grant, Chainstack becomes a new powerhouse for the growth of The Graph and the Web3 community as a whole. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack becomes the Wormhole Guardian Chainstack is now part of the Wormhole Guardian Network — the set of independent infrastructure operators that observe and sign messages for Wormhole, the cross-chain interoperability protocol. For us, this is a step into the verification layer of one of the most heavily used interoperability protocols in production, and a natural extension of the RPC infrastructure we already run across 70+ chains. What the Guardian Network actually does Wormhole connects 45+ blockchains across EVM, Solana, Sui, Aptos, Cosmos, and major L2s. It powers cross-chain messaging, token transfers, governance, and queries for protocols including Circle’s CCTP, Pyth, Uniswap, Lido, Sky (formerly MakerDAO), and tokenization platforms moving regulated assets across chains. The Guardian Network is what makes that work. Nineteen independent validator companies observe contract events on every supported chain and sign attestations using a t-Schnorr multisig scheme. Once a 13-of-19 supermajority has signed, the signatures are aggregated into a VAA (Verifiable Action Approval) that any destination-chain Core Contract can verify. No VAA, no cross-chain action. Consensus is reputation-based Proof-of-Authority rather than stake-weighted: every Guardian has equal weight, and the only thing standing between a bridged dollar and a stuck dollar is whether enough honest operators saw the same event. Some chains (Ethereum, Solana) are observed directly by all 19 Guardians. Others use a delegated subset, with Canonical Guardians waiting for delegate quorum before signing — a setup that keeps operational overhead manageable without lowering the effective 13-of-19 security threshold. That makes the operational quality of each Guardian a structural property of the protocol, not a vendor metric. What we’re operating As a Guardian, our responsibilities cover: Running the Guardian stack. The guardiand software deployed with redundant hardware, continuous signing, and isolated key management — backed by the same MFA enforcement, hardware tokens, and privileged access management used across our platform. Direct on-chain observation. Full nodes for the chains where we participate in observation, so we sign on events we’ve seen ourselves rather than relayed attestations. 24/7 monitoring and incident response. The same on-call discipline and observability practices we apply across our infrastructure, with a dedicated rotation for the Guardian deployment. Source: Wormhole Dashboard The Guardian deployment is isolated from our customer-facing RPC infrastructure, which matters: a Guardian must be able to fail safely without dragging anything else down with it, and vice versa. Why this matters for builders For developers shipping cross-chain features, a Guardian set composed of operators with deep multichain infrastructure experience is the difference between a VAA that arrives in seconds and one that doesn’t arrive at all. The 13-of-19 threshold protects against any one Guardian going down, but it depends on the rest of the set actually being available. For institutions and tokenization platforms moving regulated assets across chains, the audited-controls side of the Guardian role matters as much as the technical one. The same SOC 2 Type II and ISO 27001 posture, key management, and access controls we apply to our institutional and regulated client base extend to the Guardian deployment. For end users, the effect is invisible and that’s the point: cross-chain transactions that keep settling, even as message volume grows. About Wormhole Wormhole is an interoperability protocol connecting 45+ blockchains across EVM, Solana, Sui, Aptos, Cosmos, and major L2s. It powers cross-chain messaging, token transfers, governance, and queries for protocols including Circle’s CCTP, Pyth, Uniswap, Lido, Sky (formerly MakerDAO), and tokenization platforms moving regulated assets across chains. Security is anchored by the Guardian Network: 19 independent validator companies that observe and sign every cross-chain message under a 13-of-19 t-Schnorr multisig threshold. The current Guardian set is publicly visible on the Wormhole Dashboard. Connect with us Join our Discord, Telegram, and follow us on X Sign up for a free Developer account or explore our plans here #### Chainstack Dedicated Nodes cross-protocol and cloud environment benchmark test At Chainstack, we believe in delivering superior performance that sets us apart in the blockchain space. Our dedicated nodes form the backbone of our network, each replicating the entire blockchain data structure and keeping the information up-to-date. By verifying and validating new information broadcasts, these nodes enhance the network’s security, providing robust and reliable service. In this comprehensive blog post, we’re peeling back the layers to disclose an in-depth benchmark analysis of Chainstack Dedicated Nodes, part of our latest study. Focusing on key protocols such as Ethereum, Polygon, BNB Smart Chain, and Solana, our nodes underwent a rigorous assessment to measure their performance, highlighting their exemplary efficiency and capacity. Let’s get to it! Get Full Report Understanding the load test methodology To ensure that our blockchain node services stand up to the test of real-world demands, we at Chainstack embarked on an extensive performance assessment journey. Our methodology involved emulating realistic user interactivity patterns by employing specialized load test profiles. The purpose of load test profiles is to recreate the rigorous conditions that nodes often face in real-life situations. These profiles enable us to simulate diverse user interactions and request loads that our nodes might encounter, thereby providing us with data that truly reflects the capacity and potential of our dedicated nodes. Our study stretches beyond just load tests. We also considered various configurations and cloud environment settings to better grasp how these factors might affect the performance of each node. This multipronged approach assured broader coverage of potential scenarios, thereby adding depth and perspective to our analysis. The cloud environments included in our study were Chainstack Cloud Latitude, Virtuozzo (VZO), Amazon Web Services (AWS), and Chainstack Cloud environments (AMS and NYC), each with its unique characteristics carefully considered during testing. Our mission was twofold: to maximize the realism of our tests to ensure the results had practical applicability and to explore a broad spectrum of cloud environments to help our clients understand how different scenarios could impact node performance. Get Full Report Key findings across protocols Our thorough examination encompassed several blockchain protocols, each demonstrating unique characteristics and performances under various testing conditions. Here’s a summary of our vital findings: Ethereum In the Chainstack Cloud Latitude environment, our dedicated Ethereum nodes excelled, showcasing a remarkable transaction-handling capacity with a maximum RPS of 1670, significantly outperforming other environments. This demonstrated superior response times and efficient resource consumption. Figure 1: Ethereum dedicated node Chainstack Cloud Latitude environment performance On the Virtuozzo (VZO) platform, these nodes exhibited robustness under load, managing a maximum RPS of 740. This performance underlines their dependability with appreciable response times and peak resource utilization. Figure 2: Ethereum dedicated node VZO environment performance When tested on Amazon Web Services (AWS), the Ethereum nodes achieved compelling results, especially notable was their performance in response times, with a maximum RPS of 677.6, the best average response time amongst all tested environments. Figure 3: Ethereum dedicated node AWS environment performance Polygon Our dedicated Polygon nodes showcased exceptional transaction throughput in the Chainstack Cloud Latitude environment, achieving the highest rate of 800 RPS. They maintained optimal response times, effectively balancing efficiency with substantial resource utilization. Figure 4: Polygon dedicated node Chainstack Cloud Latitude environment performance In the VZO environment, these nodes consistently handled a moderate throughput of 550 RPS with minimal fluctuations in response time, emphasizing stability. Figure 5: Polygon dedicated node VZO environment performance In the AWS environment, Polygon nodes demonstrated endurance, supporting a throughput of 460 RPS, closely matching the VZO’s upper performance limits and indicating robustness under various operational conditions. Figure 5: Polygon dedicated node AWS environment performance BNB Smart Chain In the Chainstack Cloud Latitude environment, the dedicated nodes for BNB Smart Chain registered an exceptional maximum RPS of 910, the highest among environments, showcasing efficient handling of peak loads while keeping resource consumption relatively low. Figure 6: BNB Smart Chain dedicated node Chainstack Cloud Latitude environment performance When tested in the VZO environment, they depicted reliable performance with a throughput of 460 RPS, demonstrating resilience under varying transactional demands. Figure 7: BNB Smart Chain dedicated node VZO environment performance In the AWS environment, the BNB Smart Chain nodes highlighted consistent performance with a robust throughput of 710 RPS, maintaining stability across operational stresses. Figure 8: BNB Smart Chain dedicated node AWS environment performance Solana In the Chainstack Cloud AMS environment without GPA, the transaction processing capabilities were tested, yielding an average RPS of 1389. This measurement gives insight into the base performance of the nodes in handling transactions without the complexity added by the GPA feature. Figure 9: Solana no GPA dedicated node AMS environment performance Conversely, when GPA was enabled within the AMS setting, the average RPS was slightly lower at 1811. This indicates the additional computational overhead that GPA introduces, affecting the transaction throughput but potentially enhancing other aspects of node performance, such as security or data consistency. Figure 10: Solana Staking GPA dedicated node AMS environment performance Turning to the NYC environment, the impact of not utilizing GPA was significant, allowing the nodes to achieve a much higher average RPS of 5906.84. This showcases the environment’s robust capacity to handle transactions at a high velocity, emphasizing the efficiency of the nodes under less complex operational demands. Figure 11: Solana no GPA dedicated node NYC environment performance With GPA activated in the NYC environment, the average RPS was recorded at 2203.62. Although this is a decrease compared to the non-GPA scenario, it still demonstrates considerable processing power, underscoring the trade-offs between system stability and transaction speed when GPA is utilized. Figure 12: Solana Staking GPA dedicated node NYC environment performance Get Full Report Response times and resource consumption Exploring the correlation between response times and resource consumption gives us insightful data relating to system efficiency and transaction handling capacity. Here’s an overview of our findings: Ethereum Our dedicated Ethereum nodes in the Chainstack Cloud Latitude environment demonstrated superior performance, with response times recorded at 320 ms for the 95th percentile and 800 ms for the 99th percentile of requests. Resource consumption in this environment peaked at 20 GB of RAM and 6.92 CPU cores, showcasing efficient scaling capabilities and an excellent balance between response times and resource usage. Figure 13: Ethereum dedicated node Chainstack Cloud Latitude environment resource usage On the Virtuozzo (VZO) platform, the nodes provided an average response time of 240 ms for the 95th percentile and 820 ms for the 99th percentile of requests. Peak resource utilization was measured at 9.86 GB of RAM and 6.61 CPU cores, indicating robustness under load and optimally balanced load handling. Figure 14: Ethereum dedicated node VZO environment resource usage In the AWS environment, these nodes achieved the best average response times among the environments tested, clocking at 180 ms for the 95th percentile and 590 ms for the 99th percentile of requests. With resource usage peaking at 15.9 GB of RAM and 5.4 CPU cores, these nodes are an excellent choice for applications sensitive to response times. Figure 15: Ethereum dedicated node AWS environment resource usage Polygon Our dedicated Polygon nodes in the Chainstack Cloud Latitude environment demonstrated substantial throughput while maintaining optimal response times of 160 ms for the 95th percentile and 960 ms for the 99th percentile of requests. These nodes showcased an impressive capacity for high transaction throughput without sacrificing response times, highlighting an inverse relationship between these factors. Resource utilization in this environment included 11.7 CPU cores and 37.6 GB of memory. Figure 16: Polygon dedicated node Chainstack Cloud Latitude environment resource usage In the VZO and AWS environments, Polygon nodes displayed a well-balanced performance between response times and throughput. The VZO environment recorded response times of 270 ms for the 95th percentile and 1400 ms for the 99th percentile, with resource use peaking at 12.7 CPU cores and 89.9 GB of memory, emphasizing a high-capacity operation mode. Figure 17: Polygon dedicated node VZO environment resource usage Similarly, the AWS environment achieved response times of 310 ms for the 95th percentile and 1400 ms for the 99th percentile, with peak resource consumption at 14.1 CPU cores and 39.1 GB of memory. This consistency makes them a reliable choice for applications requiring dependable performance. Figure 18: Polygon dedicated node AWS environment resource usage BNB Smart Chain Our BNB Smart Chain nodes, particularly in the Chainstack Cloud Latitude environment, showcased exceptional handling of peak loads. The nodes achieved a maximum response time of only 230 ms for the 99th percentile of requests, while keeping resource consumption low at 21.4 GB of memory and 13.5 CPU cores. Figure 19: BNB Smart Chain dedicated node Chainstack Cloud Latitude environment resource usage In the VZO and AWS environments, these nodes displayed robust performance tailored to diverse operational demands. In the VZO environment, nodes showed a response time of 300 ms for the 95th percentile and 640 ms for the 99th percentile, with resource consumption peaking at 82.3 GB of memory and 13.9 CPU cores. Figure 20: BNB Smart Chain dedicated node VZO environment resource usage Meanwhile, the AWS environment maintained consistent performance, with response times of 320 ms for the 95th percentile and 860 ms for the 99th percentile, and peak resource usage at 88.4 GB of memory and 12.4 CPU cores. These attributes make them an optimal solution for a variety of operational needs. Figure 21: BNB Smart Chain dedicated node AWS environment resource usage Solana In the Chainstack Cloud AMS environment without GPA, the Solana nodes demonstrated a median response time of 67 ms. Despite this quick response rate, the 99th percentile response times reached up to 3400 ms, indicating how the system handles intense load conditions without the complexity of GPA. Resource utilization in this setup peaked at 1070 GB of memory, which, combined with a reduced average CPU usage of 18.0, suggests a focused distribution of computational resources, aimed at maintaining performance stability under varied load conditions. Figure 22: Solana no GPA dedicated node AMS environment resource usage With GPA enabled in the AMS environment, the nodes showed slightly slower median response times of 69 ms, and 99th percentile response times stretched to 3300 ms. This setup required more extensive resource usage, peaking at 1060 GB of memory, indicating that GPA inclusion significantly influences the operational demands on system resources. This higher resource utilization reflects the additional processing load that GPA entails, which is crucial for handling more complex queries and enhancing node stability. Figure 23: Solana Staking GPA dedicated node AMS environment resource usage In the NYC environment, the performance of the Solana nodes without GPA was notably more efficient, exhibiting a median response time of 66 ms and a much lower 99th percentile response time of 2000 ms. Resource usage in this scenario was also lower, with a maximum memory usage of 860 GB. These figures highlight the enhanced processing capabilities and resource efficiency achieved when GPA is not active, allowing for faster transaction processing and reduced system strain. Figure 24: Solana no GPA dedicated node AMS environment resource usage Conversely, when GPA was active in the NYC environment, the nodes managed a median response time of 55 ms, demonstrating rapid initial responses to queries. However, under heavy load conditions, the 99th percentile response times soared to 5000 ms. Resource consumption was substantially higher in this setting, with CPU usage peaking at 42 and memory usage reaching up to 880 GB. This increased resource demand underlines the significant impact of GPA on the node’s ability to manage complex operations, ensuring stability but at the cost of higher resource consumption and potential delays during peak loads. Figure 25: Solana Staking GPA dedicated node AMS environment resource usage Get Full Report Implications of GPAs on efficiency and transaction processing The getProgramAccounts or GPA, an integral part of Solana’s protocol, is crucial in enhancing stability and handling peak transaction loads. However, how does GPA impact the node’s efficiency and transaction processing capabilities? We’ve laid out our key findings here: Efficiency with GPA enabled In the Chainstack Cloud NYC environment with GPA enabled, we observed rapid median response times of 55 ms. Although the 99th percentile response times peaked at 5000 ms under maximum loads, the overall CPU utilization peaked at 42, and memory usage reached 880 GB, demonstrating a significant resource commitment to maintain stability even under heavy loads. Efficiency without GPA enabled Without GPA, the Solana nodes in the NYC environment displayed a remarkable average RPS of 5906.84, maintaining excellent median response times of 66 ms. This configuration demonstrated superior performance and efficiency, highlighting the trade-off between transaction speed and the stability provided by the more complex queries involved in GPA. Comparison across environments The NYC and AMS environments offered distinct performance metrics. NYC consistently outperformed AMS in terms of RPS, achieving faster transaction speeds regardless of whether GPA was enabled. This underscores the location-specific advantages of the NYC setting. Conversely, AMS, while demonstrating substantial memory usage with an average of 1005 GB with GPA and 1040 GB without, had lower CPU utilization, indicating different resource management strategies. This contrast highlights the nuanced approaches in managing resources between the two locations. The inclusion or exclusion of GPA, along with the choice of cloud environment, plays a crucial role in determining node efficiency and transaction processing capabilities. This insight enables us to strategically tailor our solutions to optimize both stability and performance, offering more effective and customized solutions to our clients. Strategic implications for node infrastructure planning Our comprehensive research offers crucial insights that pave the way for strategic decisions regarding node deployment and infrastructure planning. Here’s what we’ve learned: Optimal environment selection Our testing across various environments—Virtuozzo (VZO), AWS, and Chainstack Cloud—highlighted distinct advantages and constraints. For instance, Ethereum nodes performed best in the Chainstack Cloud Latitude environment with the highest RPS and efficient resource utilization, suggesting that environment selection should be tailored to optimize specific blockchain protocols. Resource management Insights into resource utilization across different settings assist in efficient resource allocation. For example, the BNB Smart Chain’s low resource use combined with high transaction rates in the Chainstack Cloud Latitude environment suggests that computational efficiency can significantly enhance performance. Such data help balance robust transaction handling capacity against resource demands to ensure optimal performance under peak loads. Efficiency vs. stability Our exploration into the effects of enabling or disabling getProgramAccounts (GPA) provides a framework for managing the trade-off between operational efficiency and stability. The choice to use GPA will depend on the specific needs of clients, influenced by how different load profiles affect performance outcomes. Location-specific deployment Our findings underline the significance of location-specific advantages. The NYC and AMS environments demonstrated notable differences in handling transactions, with NYC consistently outperforming AMS in terms of RPS. This can inform strategic decisions on where to deploy nodes to maximize transaction processing efficiency. Our commitment to understanding every aspect of our dedicated blockchain nodes’ performance enables us to deliver unparalleled service. By leveraging this detailed analysis, Chainstack is well-positioned to offer optimized, efficient, and robust blockchain solutions, precisely tailored to meet diverse client needs. Get Full Report Bringing it all together Our journey into the depths of Chainstack Dedicated Nodes’ performance is testament to our commitment to delivering superior services. In adopting a meticulous approach through specialized load tests and simulating real-world interactions, we’ve uncovered invaluable insights on performance, resource efficiency, and scalability. Our exploration stretched across multiple protocols—Ethereum, Polygon, BNB Smart Chain, and Solana—and diverse cloud environments. We’ve unpacked how varying environments influence nodes’ performance and how the inclusion or exclusion of getProgramAccounts (GPA) affects node operation and transaction load management. In scaling these heights, we’ve paved the way for optimized infrastructure planning and precise node deployment. Moreover, our findings underline the flexibility, resilience, and remarkable efficiency of Chainstack Dedicated Nodes. They’ve shone a light on the significance of understanding response times, resource consumption, and efficiency in transaction handling capability. At Chainstack, these findings represent more than just data. They demonstrate our dedication to offering efficient, secure, and robust solutions tailored specifically to our client’s needs. This extensive study lays a strong foundation for the future, enabling us to continue advancing and offering unmatched blockchain services. We work tirelessly in our pursuit of maximizing the potential of blockchain technology because we believe in the capacity of our dedicated nodes. We believe in delivering solutions that revolutionize how business is done. And as we continue to innovate and drive forward, we invite you to join us on this exciting journey. Get Full Report Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Arc testnet support We’re excited to announce that Chainstack now supports Arc — Circle’s Layer 1 blockchain purpose-built for stablecoin finance. Starting today, you can deploy production-ready Arc testnet nodes on Chainstack in under two minutes. Why build on Arc? Arc is an open, EVM-compatible Layer 1 built by Circle — the issuer of USDC — and designed from line one for stablecoin-native finance, tokenized assets, and institutional-grade financial coordination. Its public testnet went live in October 2025 with 100+ institutional participants including BlackRock, Visa, HSBC, Goldman Sachs, and Mastercard, ahead of mainnet beta in 2026. USDC as native gas: Fees are dollar-denominated and predictable — no volatile native token to hedge or budget around. This alone makes Arc uniquely suited for payments, treasury, and fintech workloads where cost stability matters more than speculation. Purpose-built for stablecoin finance: Arc narrows its design scope to payments, settlement, FX, and tokenized assets rather than chasing every general-purpose use case. A built-in FX engine with 24/7 PvP onchain settlement targets institutional flows that no general-purpose L1 handles natively. Instant finality: Sub-second deterministic finality powered by the Malachite consensus engine — the settlement guarantees enterprise finance actually needs. Full EVM compatibility: Solidity contracts, ethers.js, viem, Foundry, Hardhat — everything you already use for Ethereum works on Arc with a config change. No new toolchain to learn, no ecosystem cold-start. Circle’s full stack, natively integrated: USDC, EURC, CCTP, and Gateway are first-class citizens on Arc, keeping stablecoin liquidity unified across Ethereum, Solana, and every other chain Circle already supports. For developers, Arc testnet is the on-ramp to what may become the settlement hub for onchain finance — with the institutional backing to make that a real possibility rather than a pitch deck. Build better with Arc on Chainstack Running Arc testnet on Chainstack gives you reliable access and predictable performance for any workload — from stablecoin payment integrations and FX applications to RWA tooling and onchain analytics. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access Dedicated Nodes — isolated resources across all Chainstack locations (Ashburn, Frankfurt, London, Los Angeles, New York, Tokyo, Singapore, Dallas) for teams that need single-tenant infra in a specific region Full and Archive nodes — recent state or full history from genesis, matched to your workload Debug and trace on archive — debug namespace methods for transaction replay,call tracing, and smart-contract debugging. Standard Ethereum JSON-RPC compatibility — HTTPS and WebSocket endpoints that workwith any EVM toolchain you already have How to get started with Arc on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select Arc as your blockchain protocol Choose Testnet, and pick Global for shared geo-balanced access or Dedicated for isolated resources Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints Get testnet USDC and EURC from the official Circle faucet to start transacting on Arc For deeper reference: Arc methods Debug and trace APIs Start building on Arc → Bringing it all together With support for Arc testnet, Chainstack extends its infrastructure coverage into the emerging stablecoin-finance stack — a category that’s quickly becoming one of the most institutionally-backed narratives in Web3. Whether you’re building payment rails, FX applications, tokenized asset platforms, or any product that touches Arc, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence — from the first testnet call today to mainnet beta in 2026. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Base support We at Chainstack are continuously in pursuit of ground-breaking solutions to bolster our platform and furnish our users with unmatched tools to deliver and govern their blockchain projects. This ongoing passion has led us on an exciting path to the latest addition to our ecosystem—Base. As an Ethereum L2, Base bridges the gap between developers and users, setting the bar higher when it comes to security, adaptability, and scalability. By minimizing development costs and paving the way for cutting-edge Ethereum features, Base promises to usher in a new era for DApp creators and developers on Ethereum L1, Coinbase, and other interoperable chains. Let’s explore what makes Base a match made in Heaven for developers. What is Base? Base stands as a robust and secure Ethereum L2 solution, designed with a vision to usher the next billion users into the world of on-chain solutions. At its core, it is a comprehensive mix of security, stability, and scalability, specifically crafted to amplify the power of DApps. Being constructed as an Ethereum L2, Base promises unrivaled potential, letting developers seamlessly deploy any EVM codebase. It facilitates a smooth onboarding process for users and assets from Ethereum L1, Coinbase, and other interoperable chains, thereby expanding the reach and adaptability of DApps. Arguably one of its most striking features is its affordability. Base guarantees access to the EVM environment at a significantly reduced cost. Early access comes along with exclusive Ethereum features like account abstraction (ERC-4337). The platform also features intuitive developer APIs for gasless transactions and smart contract wallets, making it builder-friendly and cost-effective. Building atop an Optimistic base A noteworthy detail about Base is its underlying tech foundation. Powering it is Optimism’s open-source OP Stack. As the second Core Dev team working on the OP Stack, Base aims to ensure the stack remains a public utility available for all. Furthermore, it contributes a portion of sequencer revenue to fund public goods, reflecting its commitment to the larger blockchain ecosystem. Arguably one of the standout features of Base is its strategic partnership with Coinbase. Through this alliance, Base enables seamless integration of decentralized apps with Coinbase’s products and distribution network. This provides easy access to fiat onramps and a massive asset base of $130B on the Coinbase platform. But the promise of Base doesn’t stop with reduced costs and broader access. It also delivers Ethereum’s best features at a price that’s ten times cheaper. Developers don’t need to code changes as Base is EVM equivalent, which means all the tools, codes, and infrastructure work perfectly right out of the box. Harnessing the rollup architecture, Base reduces costs for users by an impressive 10x factor. Building on Base Base is not just a new addition to your Ethereum L2 solutions. It is a beacon of unique features, benefits, and advantages that redefine the landscape for developers and users alike. The core objective of Base is to provide a scalable, versatile, and secure Ethereum L2 solution. It achieves this vision by strategically integrating the best aspects of Ethereum L1 and Coinbase—the security of Ethereum, the scalability of L2 solutions, the feature-rich environment of early Ethereum access, and the extensive reach of Coinbase’s distribution network. The heart of Base beats with the ambitious goal of bringing the next billion users on-chain. It is a solution that lives up to the grandeur, stability, and scalability that this goal entails. With its low-cost environment, Base incentivizes developers to bring their DApps onboard, thus making Ethereum more accessible than ever. Affordability, accessibility, and scalability, fused with powerful APIs Base empowers developers with early access to Ethereum features like account abstraction (ERC-4337). Developer APIs crafted for gasless transactions and smart contract wallets are additional attractions that make Base a solution well worth considering. With Base, you get the best aspects of Ethereum at a price that’s 10x cheaper than Ethereum. It doesn’t require any code changes because it is EVM equivalent, a feature that ensures all your tools, codes, and infrastructure work out of the box. In essence, Base brings to the table a unique mix of affordability, accessibility, scalability, and extensive features. It allies with an established blockchain giant, advocates for public goods, and breathes life into the true potential of on-chain platforms. With Base at the helm, the future of on-chain development looks immensely bright. With this, we now move on to how this partnership between Chainstack and Base will change the game for our users. Empowering accessible privacy-compliant development The addition of Base to our suite of products is a significant milestone in Chainstack’s ongoing journey. With this partnership, we aim to redefine the value we deliver to our users through an exceptional blend of technological excellence, cost-effectiveness, scalability, and accessibility. Base’s vision aligns seamlessly with Chainstack’s commitment to scale and secure on-chain platforms. Through this collaboration, we bring to our users the best features of Ethereum L2 solutions—a secure, scalable, and low-cost environment. With Base, our users now have an Ethereum equivalent platform that reduces costs by a whooping 10x factor. The integration of Base opens a new chapter for Chainstack. We are now equipped more than ever to support our users with the right tools for rapid, cost-effective, and privacy-compliant DApp development. We eagerly look forward to the blockchain innovation this partnership will inspire. Eugene Aseev, Founder and CTO, Chainstack By bringing Base onboard, Chainstack enables developers to confidently deploy any EVM codebase. It further provides an easy on-ramping path for users and assets from Ethereum L1, Coinbase, and other interoperable chains. This heightened level of integration fuels our ability to support a wider range of requirements, thereby promoting enhanced decentralization in the blockchain world. Feature highlights Effective L2 solution: Base offers a robust, efficient, and secure environment for building dapps. Security, stability, and scalability: This trifecta forms the foundational pillars of Base, ensuring a user-friendly and reliable platform for developers. Cost-effective: Base makes Ethereum features accessible at a fraction of the cost, providing a major relief for developers. Its rollup architecture reduces costs by 10x for users. Early access to Ethereum features: Developers using Base get early access to Ethereum features like Account Abstraction (ERC4337), making it an attractive platform for development. Developer-friendly APIs: Base features intuitive developer APIs for gasless transactions and smart contract wallets, which add to its overall user experience. Seamless integration: Base ensures smooth integration for developers, allowing them to deploy any EVM codebase and easily onboard users and assets from Ethereum L1, Coinbase, and other interoperable chains. Powered by Optimism: Base is built on Optimism’s open-source OP Stack and contributes a portion of sequencer revenue to fund public initiatives. Coinbase integration: Base comes with seamless Coinbase integrations, easy fiat onramps, and access to the $130B assets in the Coinbase ecosystem. EVM-compatible: Base is EVM compatible, so all of your code, tools, and infrastructure work out of the box. Bringing it all together Through the introduction of Base, Chainstack embarks on a new chapter in its journey towards creating a diverse and inclusive blockchain landscape. Designed as an Ethereum L2 solution, Base brings to the fore a powerful blend of security, stability, and scalability. Its myriad of features offers a platform where developers can seamlessly integrate their DApps, onboard their users, and transition assets from Ethereum L1, Coinbase, and other interoperable chains, all at a fraction of the cost. But the power of Base goes far beyond cost-effectiveness. Its underpinning by Optimism’s open-source OP Stack and its resultant contribution to funding public goods are testaments to Chainstack’s dedication to forging a future where blockchain expenditure is as beneficial to its users as to the broader blockchain ecosystem. With Coinbase integrations, seamless fiat onramps, and access to robust assets in the Coinbase ecosystem, Base is poised to be a game-changer for developers. The integration of Base into the Chainstack ecosystem marks a significant milestone in our enduring mission to provide users with the best on-chain development tools. This latest advancement stands as a testament to our unwavering commitment to drive growth, innovation, and progression within the blockchain space. As Base Protocol ushers in an era of more efficient, secure, and inclusive blockchain development, Chainstack continues to stand at the forefront, ready to tap into its potential and deliver value to our users. At Chainstack, we are excited about this new beginning and we remain committed to our mission to empower developers and organizations with the most versatile and accessible blockchain infrastructure. As we refine, innovate, and refine again, the future of blockchain development looks brighter than ever. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces early access Reth support for Dedicated nodes Reth is set to redefine Ethereum nodes, and Chainstack’s support is a significant milestone in our journey to elevate blockchain performance and reliability. Georgios Konstantopoulos, CTO, Paradigm We are thrilled to announce that Chainstack is now offering early access support for Reth on our Dedicated nodes. As innovators in the blockchain infrastructure space, we recognize that performance and efficiency are paramount for Web3 developers like you. That’s why we’ve integrated Reth—a next-generation Ethereum client—into our platform to help you build, deploy, and scale your DApps more effectively than ever before. Leveraging the power of Rust, Reth delivers unparalleled speed, reliability, and safety features, revolutionizing your interaction with Ethereum, BNB Smart Chain, Optimism, and Base. Let’s explore! Unlock superior performance with Reth Navigating the complexities of blockchain networks can be challenging. Each chain has its own set of technical requirements, making node management and data synchronization time-consuming tasks. That’s where Reth comes in. Our team at Chainstack has been diligently working to bring you the most efficient Ethereum client available. Reth significantly outperforms traditional clients like Geth and Erigon, offering you up to 16K RPS, with latency as low as 1ms even under load. Multi-chain by design Reth is not just limited to Ethereum. It’s available on Dedicated nodes for leading protocols like: Ethereum BNB Smart Chain Optimism Base This allows you to leverage Reth’s exceptional performance across different ecosystems seamlessly. Full, archive, and Debug & Trace support Whether you’re running a Full node or an Archive one, Reth doubles its performance. This means less waiting and more building. Moreover, Reth brings the Debug & Trace API to full power, reaching over 500+ RPS, which is 10 times faster than the Erigon client. This accelerates your development process by providing faster and more reliable debugging tools. Reth performance benchmarks In extensive testing on the Ethereum network, Reth consistently outperforms other clients: Reth Full node: 3,221.67 RPS Geth Full node: 1,670 RPS Reth Archive node: 9,680.7 RPS Erigon Archive node: 3,999 RPS Reth Debug & Trace: 564.39 RPS Erigon Debug & Trace: 48.3 RPS Figure 1: Reth RPC benchmark; Source: Paradigm Research on Reth Performance Why choose Reth on Chainstack? Future-proof infrastructure: Stay ahead with the latest advancements in Ethereum. Enhanced developer experience: Build more, wait less with superior performance. Scalable solutions: Expand without limits with multi-chain Reth support on Chainstack. How to get started with Reth on Chainstack? Ready to experience the difference? We’re offering early access to Reth on our Dedicated nodes. Follow our step-by-step guide to deploy your node: Sign up for early access: Visit our early access page to register your interest to participate. Choose your network: Select Ethereum, BNB, Optimism, or Base for your Dedicated node. Configure your node: Customize your node settings based on your project’s requirements. Deploy and sync: Launch your node and benefit from Reth’s rapid sync times. Start building: Leverage Reth’s superior performance to develop and scale your DApps. Bringing it all together At Chainstack, we’re committed to empowering the builder community with cutting-edge tools and infrastructure. By integrating Reth into our platform, we’re taking a major step towards improving your experience as a Web3 developer even further. Our goal is simple: to optimize your workflow and DApp’s performance, as well as open up new avenues for innovation across multiple ecosystems. Join us in this exciting journey and be among the first to unlock the full potential of Reth on Chainstack. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Forta support Chainstack continues to break new ground, as the Forta protocol becomes available within the list of supported networks on the platform. With this new addition to the Marketplace, you will soon be able to launch a Forta scan node with Chainstack infrastructure under all subscription plans. This makes deploying a Forta scan node to enhance security and threat detection to build and scale decentralized applications that much more accessible. So, forget about all the woes that come with managing nodes yourself and start putting more time towards generating value with your project. What is Forta? Launched in late 2021, Forta is a real-time detection network whose purpose is to enhance security and operational monitoring of blockchain activity. In its goal to offer decentralized monitoring as a network, Forta serves to identify threats and anomalies in DeFi, NFT, governance, bridges, and other Web3 applications as they happen live. Forta network real-time detection bot Under the hood of Forta, lies a decentralized network of independent node operators that perform scans on all transactions, as well as state changes in each block for anomalous transactions and threats. Once an anomaly is detected, node operators parse alerts to relevant subscribers about the potential risks, in turn allowing them to take appropriate action. At present, Forta supports a wide range of networks, including Ethereum, Avalanche, Polygon, BNB Chain, Fantom, and Arbitrum, among those also available on the Chainstack platform. This extensive interoperability allows Web3 developers to take advantage of its vast security and monitoring capabilities, regardless of the protocol in question. Building on Forta To start using Forta, you first need to subscribe to its data feeds, which can be accomplished via the Forta App, OpenZeppelin Defender, or via the public Forta API directly. When it comes to running your own detection bots atop the Forta network, you can do so via the SDK, which also offers various templates and examples, so, you don’t have to start from scratch. You can also hire a development team to create a bot for your project via the Bot Development Marketplace. Forta network bot wizard The bots themselves are composed of a set of code scripts stored in a Docker container and serve the purpose of processing blockchain data to identify anomalies from preset conditions. These can be, for example, flash loan attacks, or an account balance falling below a particular threshold. Once a bot detects an anomaly, it sends out alerts to the users subscribed to it. The execution of each bot’s code is performed by scan nodes. Scan nodes are something that is inherent to the Forta network. As mentioned previously, they execute the code of detection bots for each new transaction and block that is committed on a particular chain. The goal of a scan node is to manage the bots’ activities like in the case of instantiating, running, and restarting them, should they stop responding. Additionally, it serves as a parser of blockchain data to the bots running on top of it. Claim your Forta noderunner rebate Running a Forta scan node already? Or just about to pick up the habit? Come claim your special Forta noderunner introduction rate and get started more affordably than ever! Enjoy lightning-fast node performance and synchronization across an ever-growing list of supported networks with a 10% slash to your subscription costs under the Business and Enterprise plans. Get the extra requests that your project needs without even reaching for your wallet – just use the rebate to claim whatever’s necessary. Reach new heights as a Forta noderunner and leverage robust Chainstack infrastructure to start scaling up your project from a more accessible position. Your future as a noderunner is now only but a click away. Claim your special Forta promo rate here today. 10% discount will be applied manually by Chainstack after the account has been set up. Get Forta exclusive 10% discount NOW How to use Forta on Chainstack Getting started with Forta on Chainstack is as straightforward as counting 1-2-3: Log into the Chainstack console Select a preferred cloud provider Pick a node location with low latency Too good to be true? Just let this video do the talking: Deploying a Polygon node with the Chainstack console And now that you know just how easy it is to get the ball rolling, you will be even more pleasantly surprised to hear that all details and operations are available within a single seamless Chainstack dashboard. Deploying a Forta scan node is truly a walk in the park with the Chainstack platform and something you are sure to enjoy as a Web3 developer. So, take point! Reserve your spot among the early adopters of the Forta network and start leveraging the priceless security and threat detection features it brings to the table. There is so much you can do with Forta once you have a reliable Web3 infrastructure partner to support you every step of the way. Pricing Chainstack’s exceptional engineering and sturdy infrastructure now make lower overhead costs and optimal efficiency when running Forta scan nodes a reality for all. Reap the benefits of flexible affordable commitments that are a perfect fit for your budget, use case, and the needs of your project. Give it a shot and take advantage of the critical security and threat detection features the Forta network offers with a commitment-free introduction rate for full elastic nodes via the Developer plan. And while you’re at it, make use of up to 3M requests that come with the subscription. Want to get more bang for your buck? Chainstack’s pricing tiers are designed with maximum efficiency in mind, so you can get everything you need at a predictable rate that fits your budget. This adaptable and price-competitive structure makes Forta scan node deployment with Chainstack a perfect opportunity for a project of any size, or stage. Chainstack pricing plans Even with the most affordable subscription plan – Growth, you get to enjoy a whopping four times as many requests (8M). And should you prefer to up the ante, you will discover 20M or 10x more requests available with the added bonus of having no restrictions for dedicated nodes with the Business plan and above. Reached your limit? Worry not, for you can always snatch some more at the affordable rate of $0.1 per 10K for the first 20M extra requests you claim. And should you want some more, you get to reap a 50% discount or $0.05 per 10K for every request above the first 20M. Too much math? Just let our handy pricing calculator do the talking. Get a custom power-user quote Let’s face it – as a high-roller or a large enterprise, it is often the case that the preset mold just doesn’t quite fit your needs and setup. Instead, it just leaves you craving for that much more… And that’s okay! At Chainstack, we understand your drive to break new ground with every step you take, which is why we have a dedicated team of Web3 pros standing at the ready for your case. Come talk to us about your use case and share more about your woes, so we can help you move closer to your goals. Get a priceless consultation that will point you in the right direction and start from pole-position with a custom-tailored quote that is sure to offer you the best we have in stock. Gain access to robust enterprise-grade infrastructure and dedicated nodes with unlimited requests for your demanding use case. And while you’re at it, take a moment to enjoy absolute freedom in selecting the cloud provider that will suit you best. Snatch your golden ticket with a custom quote that will take you to the forefront. Make the most out of every resource that we have at our disposal, just so you can squeeze the absolute max of every node you have deployed on Chainstack. Embrace the power of hybrid hosting Ever wanted to have your very own data center to house your entire blockchain operation? Well… now you can! But that’s not even half the story – you will get to have your cake and eat, as an expert team of Chainstack engineers will be there to lift the burden of managing it all yourself. Chainstack cloud hosting options So, grab a cold drink and kick your feet up on the table, as you witness the problem taking care of itself right before your very eyes. With Chainstack’s hybrid hosting, this will no longer be a distant dream for you but a welcome sense of reality knocking on your door to get things started. Don’t believe us? Start a convo here and we will gladly show you just how deep the Chainstack rabbit hole goes… Detecting on-chain anomalies in real-time It is our mission at Chainstack to provide maximal value for Web3 builders across the world with every new protocol available on the platform. Considering just how rampant blockchain exploits, hacks, and anomalous activity can be, especially as of late, we saw Forta as a perfect fit for the needs of our customers. And by adding it as a possible option for you to take advantage of, we are thrilled to offer you, as a Web3 BUIDLer another priceless tool that will help your project, security-wise. Forta network 12 000 nodes milestone With exploits, hacks, and other malicious activity plaguing protocols or DApps from day one, having access to a set of security and detection tools is becoming ever more critical to a Web3 developer. This makes Forta a critical contributor to the healthy functioning of any project and a welcome addition to Chainstack’s list of supported protocols. Eugene Aseev, Founder and CTO of Chainstack With Chainstack’s robust infrastructure reinforcing the efforts of Web3 developers using Forta, taking advantage of its powerful security and detection features is now more accessible than ever. And with the protocol’s priceless toolset in your pocket, you can now rest easy and enjoy your journey as a BUIDLer that much more, knowing that on-chain anomalies will steadily become a thing of the past. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Hoodi testnet support We’re thrilled to announce that Chainstack now fully supports the Hoodi Ethereum testnet—Ethereum’s latest long-term, merged-from-genesis testnet designed to streamline infrastructure, staking, and protocol development. Launched on March 17, 2025, Hoodi replaces Holesky as the primary environment for testing Ethereum’s upcoming Pectra upgrade, following challenges encountered on previous testnets. Why build on Hoodi? Hoodi is engineered to provide a stable and comprehensive testing ground for Ethereum’s evolution. Key features include: Merged-from-genesis architecture: Ensures a unified and consistent testing environment from the outset. Proof-of-Stake consensus: Facilitates realistic staking and validator operations, mirroring mainnet conditions. Full Pectra upgrade integration: Allows developers to test the complete suite of Pectra features, including smart contract enhancements and validator exit mechanisms. With the successful activation of the Pectra upgrade on Hoodi, Ethereum developers are poised to deploy these enhancements to the mainnet, pending final evaluations. Build better with Hoodi on Chainstack Deploying and managing Hoodi nodes is seamless with Chainstack’s enterprise-grade infrastructure. Benefits include: High-performance throughput: Ensures smooth scaling as user activity grows. No daily request limits: Provides unrestricted API access for high-volume operations. Optimized latency: Global endpoints ensure minimal response times. Transparent, predictable pricing: Simple Request Unit (RU) pricing eliminates unpredictable costs. How to deploy Hoodi nodes on Chainstack Launching your Web3 project on Hoodi is straightforward: Deploy a Hoodi RPC node: Hop on to the Chainstack console to deploy your node. Leverage Ethereum developer tools: Utilize JSON-RPC and Web3 libraries for seamless integration. Build, launch, and scale: Tap into Ethereum’s DeFi, NFT, and Web3 gaming ecosystem to push the boundaries of innovation. Bringing it all together By integrating with Hoodi, Chainstack empowers Web3 builders to deploy high-performance decentralized applications with confidence. Whether you’re developing DeFi protocols, NFT marketplaces, GameFi applications, or next-generation decentralized services, Chainstack’s Global Hoodi RPC Nodes provide the robust infrastructure needed to scale effectively. Start building on Hoodi with Chainstack today. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack Introduces Kenshi Oracle Network We are excited to announce the addition of Kenshi to our fast-growing list of supported networks and protocols! With Kenshi listed on Chainstack, the web3 developer community can now easily enjoy the lightning-speed networks of secure oracles. Combined with Chainstack’s robust infrastructure, it’s a match made in heaven for web3 developers worldwide. Kenshi is your one-stop shop for all your trustless oracle needs. It provides easy and secure access to real-world data points and lets you create custom oracle solutions for any blockchain protocol. Kenshi is a comprehensive starting point for developers looking to build trustless systems that run safely and efficiently. With Kenshi’s reliable and performant oracle infrastructure backed by Chainstack, developers can focus on what matters the most: creating value with their projects. Kenshi’s oracles are designed to integrate seamlessly with any blockchain protocol, from the most prominent smart contract platforms, like Ethereum and BNB, to upcoming projects in their early stages. This allows developers to easily access reliable real-world data without having to code their own custom oracle solution. With Kenshi, developers will have access to a secure, efficient, and robust oracle infrastructure that can be used for any type of blockchain project supported by Chainstack, including Ethereum, BNB, Polygon, Avalanche, and Fantom, to name a few. What is Kenshi? First and foremost, Kenshi’s products are made for developers by developers. A technology startup with a core team of industry experts, Kenshi closely collaborates with a network/ecosystem of partners and protocols to achieve its goals. Their mission is to accelerate and empower blockchain development by helping the builder community solve complex development challenges. How will Kenshi help you? 1. By providing a rich ecosystem of blazing-fast, easy-to-use, secure, and robust oracles, which will allow you to focus on innovation instead of reinventing the wheel The Kenshi Oracle Network provides high-speed, reliable access to real-world data points like the price of cryptocurrencies and other assets, fiat currency exchange rates, commodity prices, and more. As a leader in blockchain oracle technology, Kenshi is dedicated to bringing true decentralization to trustless systems that are safe, efficient, and accessible for everyone. 2. By indexing blockchain data flows and turning them into an easy-to-use data layer This will enable you to query the blockchain data efficiently and use webhooks so that you can be notified of a specific event happening on the blockchain. Now, developers can store and query blockchain data seamlessly. This helps to eliminate the need for manual processes and reduces development costs by providing an easy-to-use interface to access blockchain data. 3. By allowing you to outsource your custom development challenges when reliable, safe, and fast delivery is needed The team at Kenshi works hard to ensure that the platform meets today’s security and scalability standards so that you can be sure your data is fully protected. By leveraging cutting-edge blockchain technology, Kenshi provides developers with a secure and robust infrastructure to build any application. Deep Index Kenshi provides various services for retrieving, querying, and processing blockchain data. The system provides access to the full blockchain, allowing users to explore real-time data, query transactions, and contract states, construct custom indexes, analyze transaction trends, and more. Deep Index consists of three main services: Sync, Query, and Reverse-API. Sync You can use sync to retrieve, store, and index data on the Kenshi data clusters. It’ll enable you to securely manage data and resources across all your environments, ensuring that the right information is accessible at any time. Additionally, Kenshi provides tools for continuously monitoring data sources, making it possible to detect patterns and insights in real-time. Query Kenshi also allows querying the blockchain with GraphQL & MQL. This means that developers can create custom applications that interact with the blockchain by making use of Kenshi’s GraphQL & MQL endpoints. These applications can be used to send and receive payments, track transactions, execute smart contracts, and more. Reverse-API (R-API) Push notifications are sent to users when a particular blockchain event, such as a transaction or block, is created. This ensures that users remain updated about their transactions and other activities on the blockchain. Furthermore, Kenshi also provides an API for developers to integrate their applications with the blockchain easily. Verifiable Random Function (VRF) This function allows users to receive a random value that is publicly verifiable by all network participants. It can be used for applications such as secure lotteries, voting systems, and consensus algorithms. The VRF also ensures that the cryptographic keys used for generating random values remain private and can only be accessed by the user who owns them. This security measure helps prevent malicious actors from manipulating the output of the VRF, ensuring that all network participants receive the same random value. Generating randomness for the blockchain This additional security measure ensures that the blockchain remains untampered with and unpredictable. This helps to guarantee that no one can predict what will happen next on the blockchain, helping to protect your data and assets from malicious actors. Custom services for clients Kenshi’s team includes a few experienced business consultants who specialize in helping clients develop effective strategies for their companies. Additionally, they offer custom project development, and on-chain services, such as Deep Index and the Oracle Network.  Where does Chainstack come into play? Our partnership will see Chainstack provide Kenshi project builders and web3 developers with the advantage of having a geographically distributed powerful blockchain node infrastructure and node APIs capable of handling high throughput without compromising on scalability. Just to put it in perspective, Kenshi runs 90M monthly lambda executions and 1.5M daily blockchain requests on ten networks to ensure quality, near real-time results. Naturally, they had some concerns about the high volume of requests becoming a problem, which would have resulted in gaps in their indexing services and subsequently, incomplete results. Since an oracle is a crucial link to the “real world” for querying data found outside the blockchain, we understood the importance of providing them with the highest uptime possible. To resolve this matter, Chainstack gave Kenshi an exclusive, dedicated gateway. Because we understood the importance of setting Kenshi up with a server in their geographic region to get the best latency. The gateway is built on our private network, with dedicated connectors to various blockchains. The main function of this gateway is to act as a bridge between Kenshi and the “real world”, providing an extra layer of security by enabling clients to query data from external sources without compromising their privacy. Oracles play an integral part in bridging blockchain technology with real-world data. This factor alone puts projects like Kenshi in the spotlight and further emphasizes their role as key contributors to the development of blockchain technology. And as Kenshi oracles become available on Chainstack, we move further on our mission to deliver exceptional means for web3 BUIDLers and help them create more value with their projects. Eugene Aseev, CTO & of Chainstack Contributing towards a swifter web3 for all As a result of this partnership, Kenshi’s services are now fully integrated with the Chainstack RPC nodes. Kenshi now saves 15000 hours of computation time (90M monthly lambda executions * 600ms) and gets an increase of up to 80% in execution speed. VRF results are also 10-20% faster, not to mention the RPC node response time that is now consistently under 100ms. Our partnership with Kenshi has been extremely beneficial for both companies. It provides Kenshi with the blockchain infrastructure to run its operations optimally and gives Chainstack the opportunity to demonstrate the scalability of its node infrastructure. We are thrilled about this opportunity to further our collaborations in the web3 space and explore other use cases of blockchain technology in the future. With Chainstack’s innovative node infrastructure and Kenshi’s cutting-edge technology, we are committed to making web3 better and even faster. By leveraging the combined power of our two teams, we are confident that the development of this space will continue to thrive. We believe that together, our companies have what it takes to drive the growth of web3 and unlock its full potential. At Kenshi, we believe developing on the blockchain should be fast and accessible to all developers. We’re excited to have Chainstack as our service provider to help us carry this mission! Pouya Eghbali, Founder and CEO of Kenshi Pricing Thanks to Chainstack’s innovative engineering and next-generation infrastructure, you can now significantly reduce your overhead by integrating Kenshi. So you can reap the benefits of flexible and affordable commitments, friendly to your budget, and able to take care of all your project needs. Give it a try and start harnessing the unique features Kenshi brings to the table with an introductory plan for developers. No commitment is required. Enjoy up to 3M requests once you start your first subscription. And if you’re interested in getting the most out of your money, don’t worry! All of Chainstack’s pricing tiers are custom fit for your specific needs and requirements. If you go with the Growth plan, you will get up to 20M requests. However, you can get 200M requests if you opt for the Business tier, with no restrictions on dedicated nodes. You don’t need to be a math whizz to get our competitive pricing. All you have to do is check out our pricing page and let the calculator do its thing. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces MegaETH support We’re excited to announce that Chainstack now supports the MegaETH — Ethereum’s fastest Layer 2, capable of processing up to 100,000 TPS with sub-10ms latency. Starting today, you can deploy a production-ready node in under two minutes, with no infrastructure overhead. Why build on MegaETH? MegaETH is designed to push Ethereum scalability to the limit while remaining fully EVM-compatible. It delivers significantly higher throughput and lower latency compared to Ethereum mainnet, enabling applications that require real-time responsiveness. High throughput: Designed to process transactions at scale for demanding applications. Low latency execution: Optimized for near real-time transaction confirmation. Full EVM compatibility: Existing Ethereum smart contracts and tooling work without modification. Ethereum security model: As a Layer 2, MegaETH leverages Ethereum for settlement and security. For developers, MegaETH provides a scalable execution environment that preserves Ethereum’s developer experience while dramatically improving performance. Build better with MegaETH on Chainstack Running MegaETH on Chainstack means reliable access and predictable performance at any scale. Whether you’re building DeFi protocols, analytics platforms, wallets, or infrastructure services, Chainstack provides: Global Nodes for scalable geo-balanced RPC access Dedicated Nodes with isolated resources for production workloads Reliable, low-latency RPC endpoints Full compatibility with standard Ethereum JSON-RPC methods How to get started with MegaETH on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select MegaETH as your blockchain protocol Deploy the node Open Access/Credentials and copy your HTTPS and WebSocket endpoints Connect your tools: Use familiar EVM toolchains such as ethers.js or web3.py. MegaETH Chainstack tooling MegaETH RPC methods Start building on MegaETH → ⚠️ Network availability: MegaETH Mainnet is available on Global Nodes and Dedicated Nodes, while MegaETH Testnet is currently available on Dedicated Nodes. Bringing it all together With support for MegaETH, Chainstack expands its infrastructure offering for high-performance Ethereum Layer 2 networks. If your application demands speed, scalability, and EVM compatibility, MegaETH on Chainstack provides the foundation to build and scale with confidence. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Oasis Sapphire support The Chainstack team is excited to announce its support of Oasis Sapphire, the confidentiality-enabled EVM network runtime on the Oasis Network, adding the first of its kind to our list of supported chains. Thanks to this, you now have the possibility to deploy an Oasis node under any of our subscription plans. This integration with our robust, enterprise-grade infrastructure makes it more accessible than ever to build and scale cutting-edge DApps, freeing you from the burden of managing nodes, so you can focus fully on creating value with your Web3 project. “We couldn’t be more thrilled about Chainstack incorporating Oasis into their tech stack. This partnership represents a major milestone for both projects. By launching seamlessly on the Oasis Sapphire mainnet, Oasis developers are now poised to unlock a world of new possibilities and opportunities. The result of this collaboration will be a more convenient and efficient development process for all involved, leading to even greater innovation throughout the entire community. We can’t wait to see what exciting new projects will emerge as a result of this game-changing partnership.” William Wendt Oasis Ecosystem Growth Manager What is Oasis? The Oasis Network is an L1 proof-of-stake (PoS) blockchain supporting parallel runtimes designed for scalability, interoperability, and privacy. Their latest implementation, Oasis Sapphire, is the first ever EVM network to support confidential smart contracts, enabling encrypted smart contract states. Its aim is to provide a privacy layer to Web3 that allows developers to foster on-chain confidentiality in their DApps, making them ideal for real-world use cases. With a secure, high throughput architecture, and unique privacy features at its core, the Oasis Network sets a new standard in Web3, effectively propelling the entire Web3 industry forward and providing the robust, flexible, and functional privacy that is needed direly. And to top it all off, the introduction of Tokenized Data—a new digital asset type intends to give users even more control over their data, with the additional benefit of earning staking rewards for locking liquidity in DApps. In turn, this serves to further highlight of the main objective here, being to create the first responsible data economy that puts its users in complete charge of their data. Figure 1: Oasis Network Data Tokenization for a responsible data economy; Source: Oasis Network Building on Oasis Sapphire Oasis Sapphire is a state-of-the-art solution that enables developers and users to personalize the confidentiality parameters and extensions of the applications built atop the network with utmost attention to the needs of both the software and its users. These confidentiality-enabling features allow for the development of ever more complex and sophisticated smart contracts, boasting exceptional user experiences that rival those of their well-established Web2 counterparts. That being said, Oasis Sapphire aims to be more than just an environment for native confidentiality-enabled smart contracts. Quite the contrary—it aims to become the privacy layer for Web3, allowing DApps on any EVM network to offload their confidential compute needs to the Sapphire network. To do this, it leverages messaging bridges and gas relayers to connect the network with any DApp’s home chain. In addition to its EVM compatibility and end-to-end confidentiality support, the Oasis Sapphire Network too brings the powerful additional features that make it a premium network for developers, including: Native confidential randomness support (without the need for off-chain oracles) High scalability, supporting hundreds of transactions per second Low cost—99% lower transaction fees than those of Ethereum Cross-chain bridges that enable complete multichain interoperability Sapphire enacts Oasis’ avant-garde privacy technology, which enforces the use of a secure computing technology called a Trusted Execution Environment (TEE) by every network node. TEEs are analogous to a black box for smart contract execution. Figure 2: Oasis Network Trusted Execution Environment; Source: Oasis Network By implementing secure and reliable key management, encrypted data streams into the black box (known as the Secure Enclave) along with the smart contract, where the data is decrypted, and processed by the smart contract before it is re-encrypted and parsed further down the line from the Secure Enclave. This process ensures the data remains confidential and avoids it being disclosed to any node operator or application developer. How to use Oasis Sapphire Getting started with Oasis on Chainstack is a swift and easy process. You just need these three steps to get started: Open the Chainstack console and log into it. Select a cloud service provider that is suitable for your needs. Select a location with low latency for your Oasis Sapphire node to be deployed at. The Chainstack platform offers many advantages for the deployment of your Oasis Sapphire nodes, and perhaps one of the best ones is having access to everything you will ever need within a single seamless dashboard. This makes node management both painless and efficient for the absolute pleasure of developers like you. This makes it the perfect time to take your rightful place as one of Sapphire’s leading early adopters. Take advantage of all the protocol has to offer for the betterment of blockchain technology and leverage it to put your project at the forefront of Web3, as you build atop the sturdy foundation Chainstack laid for you. Pricing Leveraging Chainstack’s state-of-the-art engineering and cutting-edge infrastructure, managing Oasis nodes for optimal efficiency becomes reality. Enjoy the blessings of our cost-effective solutions that are tailor-made to fit both your budget and your project’s needs with minimal overhead costs for this match that’s truly made in Heaven. Discover Oasis Sapphire and its awe-inspiring characteristics for yourself—no commitment needed, just sign up for the complimentary Developer plan and its special introduction rate for elastic infra. With up to 3M requests available with your subscription, you are sure to claim your fair share. And in case you’re looking for some even great value, worry not, for Chainstack’s flexible pricing structure is there to make sure of it truly. Deploy Oasis Sapphire nodes for whatever project size and stage it may ever be and revel in its feasibility and candor. In need of a more premium solution? Look no further than the Chainstack Growth plan that will bring you over twice the number of requests with 20M available at your disposal. And while you’re at it, why not take things even further with the Business tier, here to reward you with a staggering 200M requests, as it lifts such restrictions for your dedicated nodes. Rest easy should you reach your limits too—you can always snatch all the extra you will ever need at a mere $5 per million, beyond the first 20M. Just use our handy pricing calculator to quickly gauge how much you get to save once you go for Chainstack infra. Take part in establishing the privacy layer of Web3 The Oasis Network heralds a new era in blockchain technology, transcending the limitations of existing solutions and empowering developers to create groundbreaking DApps. With its scalable, confidentiality-enabled EVM network infrastructure, Oasis elevates the potential of decentralized applications to brand-new heights. This innovative protocol is meticulously designed to not only deliver exceptional performance and greater levels of privacy but to also simplify cross-chain interoperability, ensuring a seamless transition towards tackling the Web3 workloads of tomorrow. Its streamlined architecture makes DApp development a real breeze, accelerating your project’s time-to-market while fortifying its overall security. Oasis is the ultimate choice for enterprises seeking reliable, cutting-edge blockchain solutions that swiftly and securely propel their workloads with zero compromise for the privacy and integrity of any user data. Embrace Oasis Sapphire, and the network’s rapidly-evolving ecosystem with an unwavering commitment to privacy, and join forces with countless developers and enterprises unlocking boundless opportunities with scalable, privacy-enabled DApps that run on Chainstack infrastructure. Together, the ever brighter future of the blockchain landscape is a given, as we pave the way towards it one Oasis block at a time. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Optimism support The Chainstack team is excited to announce the integration of the Optimism protocol onto our platform, adding it to our list of supported chains. This provides you the opportunity to launch an Optimism node on any of our subscription plans. The integration makes it easier to build and scale DApps with our dependable, enterprise-grade infrastructure, allowing you to focus more on creating value for your web3 projects and less on managing nodes. What is Optimism? The Optimism protocol is a layer 2 scaling solution for Ethereum that aims to increase the network’s transaction speed and reduce its costs. It uses a system of smart contracts and off-chain transactions to increase the efficiency of the Ethereum network. Building on Optimism Optimistic rollups, which the Optimism network runs on is a scaling solution for Ethereum that enables the execution of transactions off-chain while still leveraging the security of the Ethereum network. It involves using a smart contract on Ethereum as a coordinator to batch and verify transactions before committing them to the Ethereum blockchain. This reduces the load on the Ethereum network and enables faster, cheaper transactions. The security of the transactions is ensured through fraud proofs, which allow for any malicious activity to be detected and rolled back. Optimism smart contracts As a true optimist, Optimism takes everything about Ethereum and turbocharges it. Ethereum tooling is seamless at all levels of the stack. Transactions are inexpensive and almost instantaneous, so what’s not to love about Optimism? As few lines of code as possible separate Optimism from Ethereum’s battle-tested infrastructure, ensuring streamlined compatibility every step of the way. Therefore, all Ethereum tools and apps will work out of the box and the same goes for your Ethereum-native expertise. Users can send arbitrary messages between smart contracts on Optimism and Ethereum with the help of Optimism too. The exact mechanism through which this communication occurs varies depending on the direction in which messages are being sent. Optimism under the hood A state commitment is published into Ethereum as part of an Optimistic rollup without any proof that these commitments are valid. Rather than being considered pending, these commitments remain pending for a period of time (referred to as the challenge window). The state commitment becomes final once it has gone unchallenged for the duration of the challenge window (which currently lasts seven days). The Ethereum platform accepts withdrawal proofs regarding the state of Optimism based on a commitment that has been confirmed as final, and smart contracts can safely accept withdrawal proofs regarding that commitment. In the event that a state commitment is challenged, a fault proof process (formerly referred to as a fraud proof) may be used to invalidate it. A successful challenge of a commitment will result in its removal from the StateCommitmentChain, which will eventually be replaced by a new one. Should Optimism be successfully challenged, the published commitments about the chain will be rolled back rather than the Optimism chain itself. How to use Optimism on Chainstack Getting started with Optimism on the Chainstack platform is a quick and easy process. Here are the steps you need to take: Open the Chainstack console and log into it Select a cloud service provider that is suitable for your needs Select a location with low latency for your Optimism node to be deployed at There are a number of advantages to deploying Optimism nodes with the Chainstack platform, but perhaps the best of all is having everything available in a single consolidated dashboard. This makes managing nodes both easy and efficient – a real walk in the park! The time to claim your rightful place as one of Optimism’s early adopters has come! Start making the most of all the benefits the protocol offers and complement your web3 project with outstanding infrastructure from Chainstack, designed for innovative projects. Pricing With Chainstack, you can now achieve maximum efficiency while lowering your overhead costs as you manage Optimism nodes, thanks to our robust RPC infrastructure and best-in-class engineering. You, on the other hand, can benefit from commitments that are as flexible as they are affordable—a match made in heaven for your project needs and budget. Take advantage of the powerful feature set that Optimism offers with a commitment-free Developer plan introduction rate for full elastic nodes. Make the most of up to 3M complimentary requests that come with this subscription. Looking for more than just the basics? Worry not, for all of Chainstack’s subscription plans are custom-tailored to do just that. So, go out there and deploy Optimism in a way that is as adaptable as it is price-competitive, regardless of the size or stage of your project. Because of this, you will be pleasantly surprised to uncover that by opting for the Growth plan, you will be met with 20M or roughly seven times more requests at your disposal. The Business plan, on the other hand, will grant you even more—200M, or close to a whopping 50x extra requests with zero limits for such made to dedicated nodes. And when your request count reaches its limit, you can simply claim more at the affordable rate of $10 per 1M for the first 20M requests and then half this price at $5 per 1M requests for those above the first 20M. For those without a background in math or accounting, you can try out our pricing calculator here. A supercharged Ethereum experience on L2 As part of Chainstack’s commitment to bringing optimal value to its users, we make sure to bring optimal support for each new protocol we add to our family, and Optimism was an obvious choice. With the protocol’s exceptional L2 scaling feature set and swift transaction processing, you are bound to discover and apply fresh new opportunities to make your DApp run even smoother. And with this new tool, made available at your disposal, we are pleased to place another block in the journey towards creating a better experience for web3 developers across the world. The scalability trilemma is quite the hot topic in web3 and having a solution for it, coming out from core Ethereum developers directly is a surefire way to make some heads turn. Pairing it with the same familiar Ethereum-native developer experience everyone knows and loves is just the icing on the cake. Eugene Aseev, Founder and CTO of Chainstack As a result of the release of Optimism on Chainstack, it is now easier than ever to take advantage of the protocol’s exceptional performance, with our reliable RPC infrastructure as the foundation. In turn, this makes building and scaling DApps of any size and stage for web3 developers like yourself a much more Optimistic experience. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Polygon zkEVM support The Chainstack team is thrilled to declare the integration of the Polygon zkEVM protocol into our platform, making it one of our supported chains. This feature enables you to launch a Polygon zkEVM node on any of our subscription plans. The integration simplifies the process of constructing and expanding DApps using our reliable, enterprise-level infrastructure. This allows you to concentrate more on generating value for your Web3 projects and less on node management. The new zkEVM L2 requires a strong infrastructure to support the high throughput of the network with the best experience for the DApps. We are pleased to collaborate with Chainstack to make the zkEVM equivalence seamless for users and developers. David Schwartz – Co-founder Polygon Hermez and Polygon ID What is Polygon zkEVM? Over the past few years, several layer 2 solutions have been introduced to enhance the scalability of the Ethereum network, specifically in terms of transaction throughput. These solutions are aimed at reducing gas fees for users of the Ethereum network, while still maintaining decentralization and security. One of these solutions is the Polygon zkEVM, a layer 2 Rollup solution that combines data availability and execution verification in layer 1 of the Ethereum blockchain to ensure L2 state transition security and reliability. The infrastructure that Polygon has designed and implemented for its zkEVM, with a particular focus on providing an overview of the components utilized in the development of the zkEVM Protocol is composed of the following: Trusted Sequencer Trusted Aggregator Consensus Contract (PolygonZkEVM.sol, deployed on L1) Figure 1: Polygon zkEVM Architecture; Source: Polygon  Trusted Sequencer The responsibility of the Trusted Sequencer component is to receive L2 transactions from users, organize them in a particular order, form batches, and then save them to the storage slots of the Consensus Contract in the form of sequences. After generating the batches, the Sequencer executes and sends them to L2 network nodes for quick finality and to minimize costs that arise due to high network usage. This occurs before the batches are even submitted to L1. To achieve this, the Trusted Sequencer must operate a zkEVM node in Sequencer mode and possess an Ethereum account that is enforced by the Consensus Contract. Trusted Aggregator The Trusted Aggregator component can compute the L2 State by utilizing batches of L2 transactions executed by the Trusted Sequencer. In contrast, the primary responsibility of the Trusted Aggregator is to receive the L2 batches that have been committed by the Trusted Sequencer and generate Zero-Knowledge proofs that verify the batches’ computational integrity. This is done by the Trusted Aggregator utilizing a special off-chain EVM interpreter. The Zero-Knowledge proofs are then authenticated by the logic of the Consensus Contract, leading to the zkEVM inheriting the L1 security. Prior to submitting new L2 State roots to the Consensus Contract, validation is necessary. A confirmed proof is indisputable evidence that a specific sequence of batches resulted in a particular L2 state. To accomplish this task, the Trusted Aggregator must operate a zkEVM node in Aggregator mode and control a particular Ethereum account that is enforced in a Consensus Contract. Consensus Contract The contract employed by both the Trusted Sequencer and the Trusted Aggregator in their communication with L1 is known as the PolygonZkEVM.sol contract. The Trusted Sequencer can submit batch sequences to L1 and save them in the PolygonZkEVM.sol contract, resulting in a chronicle of sequences. Furthermore, the PolygonZkEVM.sol contract allows the Trusted Aggregator to publicly authenticate the transitions between L2 State roots. The Consensus Contract achieves this by verifying the ZK-proofs provided by the Trusted Aggregator, which attests to the appropriate execution of transaction batches. Building on Polygon zkEVM The Polygon zkEVM is an innovative zero-knowledge scaling solution that operates on an equivalent level to the EVM. It supports all current developer tools, smart contracts, and wallets without any issues. With the utilization of zero-knowledge proofs, Polygon zkEVM can considerably reduce transaction expenses and raise throughput while still retaining the security of Ethereum. Creating decentralized apps on the zkEVM network is identical to that of Ethereum. By transitioning to the zkEVM RPC, developers can easily construct their DApps on a network with improved performance and lower fees. The Polygon zkEVM provides a seamless EVM-like experience for both developers and users, and there’s no need for special tools or new wallets to use or create on the zkEVM network. Developers have the option of deploying their present contracts to the zkEVM network, and users can deposit their assets from Ethereum and execute off-chain transactions. These transactions are organized into batches, with each transaction’s validity verified by zero-knowledge proof. zkEVM nodes and execution modes A zkEVM node is a software bundle that contains all of the necessary components for running a zkEVM network. It can be executed in three distinct modes: Sequencer, Aggregator, or RPC. Figure 2: Polygon zkEVM circuit; Source: Polygon  Sequencer mode The node in Sequencer mode performs multiple functions, including holding an instance of L2 State, managing batch broadcasting to other L2 network nodes, and featuring a built-in API to handle L2 user interactions, such as transaction requests and L2 State queries. Additionally, it includes a database to temporarily store pending transactions and all the necessary components to interact with L1 to sequence transaction batches and maintain its local L2 State. Aggregator mode When in Aggregator mode, the node possesses all the necessary components to carry out transaction batches, compute the resulting L2 State, and produce Zero-Knowledge proofs of computational integrity. Additionally, it can obtain transaction batches that have been committed in L1 by the Trusted Sequencer and invoke the functions required to publicly validate the L2 State transitions on L1. RPC mode When operating in RPC mode, the zKEVM node has a restricted range of functions. Its main role is to maintain an up-to-date instance of L2 State, first with batches that are broadcast by the Trusted Sequencer, and then with sequences of batches obtained from the Consensus Contract. The node regularly interacts with L1 to ensure that its local L2 state is current and to verify the synchronization of L2 state roots. By default, the synchronizer is programmed to synchronize every 2 seconds, unless otherwise specified in the configuration. Pricing With Chainstack, you can now optimize your cost efficiency while managing Polygon zkEVM nodes using our robust RPC infrastructure and world-class engineering. You can take advantage of flexible and affordable subscription fees that are tailored to meet your project needs and budget. The Developer plan offers a commitment-free introduction rate for full elastic nodes, allowing you to leverage the powerful feature set that Polygon zkEVM provides. This subscription also includes up to 3M complimentary requests. If you need more than just the basics, don’t worry. All of Chainstack’s subscription plans are customized to meet your requirements. You can deploy Polygon zkEVM in a way that is both adaptable and price-competitive, regardless of the size or stage of your project. With the Growth plan, you’ll have access to 20M requests, which is seven times more than the Developer plan. The Business plan, on the other hand, provides even more requests—200M, which is almost 50x more than the Developer plan, and with no limits for dedicated nodes. If you reach your request limit, you can simply purchase more at an affordable rate of $10 per 1M requests for the first 20M requests, and then half this price at $5 per 1M requests for those beyond the first 20M. You can try out our pricing calculator here if you need assistance with the math behind it. Zero-Knowledge L2 scaling with full EVM compatibility Chainstack is dedicated to delivering optimal value to its users by providing excellent support for each new protocol we add to our family. The addition of Polygon zkEVM was an obvious choice because of its exceptional L2 scaling feature set, paired with Zero-Knowledge proofs for swift transaction processing capabilities. Together, these enable you to explore and apply new opportunities to improve your DApp’s performance. Polygon’s zkEVM is a game-changer for Web3 enabling fast, secure, and scalable transactions while preserving decentralization. It’s a powerful tool for building the next generation of decentralized applications that can deliver real-world solutions to the world’s most pressing problems. We are thrilled to be among the first to offer support for it and provide developers with ample means of accessing it on the Chainstack platform. Eugene Aseev, Founder and CTO of Chainstack With the release of Polygon zkEVM on Chainstack, it’s now easier than ever to leverage the protocol’s exceptional performance with our reliable RPC infrastructure as the foundation. This provides a more seamless experience for Web3 developers like you to BUIDL and scale DApps of any size and stage, making Polygon zkEVM a much more pleasant experience. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Robinhood Chain support We’re excited to announce that Chainstack now supports Robinhood Chain — an Ethereum Layer 2 for finance and tokenized real-world assets, built on the Arbitrum Orbit stack with the Nitro client. Starting today, you can deploy production-ready nodes on Chainstack in under two minutes — on both Mainnet and Testnet, with debug and trace APIs enabled. Why build on Robinhood Chain? Robinhood Chain is a permissionless, Ethereum-compatible Layer 2 built to bring traditional financial assets onchain — starting with tokenized U.S. equities and extending to a broader class of real-world assets. It’s the infrastructure layer behind Robinhood’s push to move brokerage-grade financial products onto public blockchain rails. Purpose-built for tokenized RWAs: The chain ships day-one with Robinhood’s Stock Tokens (tokenized U.S. equities), onchain lending, and agentic trading — designed around the operational realities of tokenized securities rather than retrofitting a general-purpose L2 for the job. Arbitrum Orbit architecture: Robinhood Chain runs the same Nitro client that powers Arbitrum One, inheriting a battle-tested execution environment and full EVM compatibility. Existing Solidity contracts and Ethereum tooling work without modification. Ethereum settlement, L2 performance: Robinhood Chain settles to Ethereum for L1-grade security while delivering ~100 ms transaction confirmations via Arbitrum Nitro preconfirmations — orders of magnitude faster than L1 block times. Access to Robinhood’s distribution: Robinhood is positioning Robinhood Chain as the onchain layer that connects a mainstream retail brokerage user base to open financial infrastructure — a distribution channel no other RWA-focused L2 currently matches. For developers, Robinhood Chain offers a familiar EVM environment optimized for one of the fastest-growing narratives in Web3 — finance and tokenized RWAs — without the ecosystem cold-start problem that new L2s typically face. Build better with Robinhood Chain on Chainstack Running Robinhood Chain on Chainstack gives you reliable access and predictable performance for any workload — from brokerage integrations and RWA dashboards to onchain analytics and portfolio tooling. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access Dedicated Nodes — isolated resources for production workloads with strict performance requirements Self-Hosted — production-grade nodes on your own infrastructure, with your data never leaving your perimeter Full and Archive nodes — recent state or complete chain history, matched to your workload Debug and trace APIs — Nitro-native debug_* methods for transaction replay, call tracing, and smart-contract debugging Mainnet and Testnet support — deploy against production or iterate safely against the testnet from a single dashboard Standard Ethereum JSON-RPC compatibility — use MetaMask, ethers.js, viem, web3.py, Foundry, Hardhat, Remix, or any Ethereum-compatible tool you already have How to get started with Robinhood Chain on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select Robinhood Chain as your blockchain protocol Choose Mainnet (chain ID 4663) or Testnet (chain ID 46630), and pick Global for shared geo-balanced access or Dedicated for isolated resources Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints Get free testnet ETH from the Robinhood Chain Testnet faucet to fund your Testnet deployments. For deeper reference: Available clouds, regions & locations Robinhood Chain tooling Robinhood Chain API reference Debug and trace APIs on Robinhood Chain Robinhood Chain Testnet faucet Start building on Robinhood Chain → Run Robinhood Chain on your own infrastructure with Chainstack Self-Hosted For teams that need full control over their data and stack, Robinhood Chain is also available on Chainstack Self-Hosted — production-grade blockchain nodes you run on your own infrastructure, whether that’s your cloud account, on-premise servers, or hybrid environments. Robinhood Chain Mainnet and Sepolia Testnet are both supported on Self-Hosted — feature parity with our managed Global and Dedicated Nodes. What changes is where the infrastructure runs: your VPC, your cost model, your operational control. Self-Hosted deployment includes one-click install from a snapshot, pre-configured node setups tuned for Robinhood Chain, monitoring and observability out of the box, and automatic node recovery — designed for teams who want the reliability of managed nodes without the vendor dependency. Get started with Robinhood Chain on Self-Hosted → Bringing it all together With support for Robinhood Chain, Chainstack extends its infrastructure coverage into one of the most consequential shifts in Web3 — the migration of traditional financial assets onto public blockchain rails. If you’re building tokenized-equity products, RWA analytics, brokerage integrations, or any application that touches Robinhood Chain, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence — whether that’s a managed endpoint or a self-hosted node on your own infrastructure — from the first testnet call to millions of Mainnet requests per day. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Ronin support At Chainstack, our dedication to innovation is rooted in our ongoing pursuit to provide blockchain developers with the latest advancements in Web3. This time, our journey has brought us to Ronin. Ronin is an EVM blockchain custom-tailored for gaming with a distinct advantage in its ability to seamlessly accommodate a high volume of daily active users. This makes it a highly-coveted choice among Web3 game developers. With the introduction of Ronin to Chainstack, we mark a pivotal moment in our commitment to providing cutting-edge tools for Web3 developers. In doing so, we open up new and thrilling opportunities for everyone building atop reliable Chainstack infrastructure. Let’s explore Ronin and what it brings to the table. What is Ronin? Ronin is an EVM-compatible blockchain designed from the ground up to cater directly to the gaming industry. Born from the creative minds at Sky Mavis, makers of the popular Web3 title Axie Infinity, Ronin has proven its mettle by servicing millions of daily active users and handling large volumes of transactions effortlessly, totaling over $4B in NFT volumes alone. Figure 1: Ronin Total Volume; Source: Nansen These staggering statistics single out Ronin as the go-to option for Web3 game developers, thanks largely to its lightning-fast transactions and minimal fees that facilitate uninterrupted, smooth in-game interactions. Ronin eliminates the unnecessary jargon and bloat found in other permissionless blockchains, putting in the hard yards to selectively feature high-quality apps, ensuring maximum quality and uptime for games. Why Ronin? Ronin is an EVM-compatible blockchain designed from the ground up to cater directly to the gaming industry. Born from the creative minds at Sky Mavis, makers of the popular Web3 title Axie Infinity, Ronin has proven its mettle by servicing millions of daily active users and handling large volumes of transactions effortlessly, totaling over $4B in NFT volumes alone. Figure 1: Ronin Total Volume; Source: Nansen These staggering statistics single out Ronin as the go-to option for Web3 game developers, thanks largely to its lightning-fast transactions and minimal fees that facilitate uninterrupted, smooth in-game interactions. Ronin eliminates the unnecessary jargon and bloat found in other permissionless blockchains, putting in the hard yards to selectively feature high-quality apps, ensuring maximum quality and uptime for games. Figure 2: The Ronin Ecosystem; Source: Ronin A supersonic EVM blockchain built for gaming The integration of Ronin into our platform marks a significant step in empowering blockchain developers, like yourself, with the cutting-edge tools you need to create exceptional Web3 gaming experiences. Ronin’s outstanding scalability, low fees, and fast processing times open up new horizons for you to BUIDL and scale blockchain games more accessibly and effectively than ever. Our integration with Ronin equips users on our platform with a proven industry-leading tech that facilitates easy, efficient, and cost-effective blockchain game development. With Ronin’s impressive track record and performance, developers are better positioned than ever to deliver quality Web3 games that scale just as well. Eugene Aseev, Founder and CTO, Chainstack This new addition is a match made in Heaven, empowering blockchain developers to redefine the boundaries of gaming and user interaction. By elevating the gaming landscape, Ronin not only provides richer user experiences but also Feature highlights Built for gaming: Ronin is a dedicated EVM blockchain designed specifically for gaming. Users enjoy lightning-fast transactions and minimal fees, cradled in a secure, stable network suitable for all types of gaming DApps. Scalable and reliable: In 2021 alone, Ronin handled 15% of global NFT trading volume, becoming the go-to platform for all Axie Infinity assets, notably Axies, Land, SLP, and AXS. It stands second only to Ethereum in terms of NFT sales volume, displaying a robust platform for high-volume transactions. User-centric: Attention to player satisfaction is key in Ronin’s design. By minimizing bloat and focusing on delivering quality gaming experiences with minimum latency and high uptime, it guarantees an optimized and satisfying Web3 experience for all. Credible backing: With support from industry giants Sky Mavis, creators of the top-rated NFT project Axie Infinity, Ronin comes with great credibility and advisory, ensuring a powerful and reliable platform for blockchain game developers. DApp ecosystem: Ronin hosts a plethora of DApps from the Ronin Wallet to Katana, a decentralized exchange, providing a comprehensive solution for both users and developers. Bringing it all together In an industry where competition is intense, and the demand for innovation never ceases, we at Chainstack are constantly looking to integrate technologies that enhance our platform’s capabilities and give you an edge as a user. This mission has led us to Ronin—a blockchain solution that is nothing short of groundbreaking for the gaming sector. Whether you’re considering Ronin’s proven ability to scale a single game to accommodate millions of daily active users or its unique approach focused specifically on gaming, it’s not hard to see why Ronin is considered a formidable presence in the blockchain gaming scene. Backed by Sky Mavis, a company that knows a thing or two about successful NFT projects, with Axie Infinity under its belt, Ronin comes with the assurance of expertise, support, and a network that promises to deliver top-tier performance. With increased security measures and a zero-trust approach, users can rest assured knowing their projects are in safe hands. In the dynamic landscape of blockchain gaming, it’s essential to have solutions that deliver on the promise of scalability, reliability, and security. With Ronin now part of our ecosystem, we are taking a giant leap in that direction. We can’t wait to see the stunning gaming DApps our talented developer community will create with Ronin in their arsenal. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Scroll support At Chainstack, innovation is at the heart of everything we do. We continuously strive to provide our users with robust and scalable solutions to support the development and management of their blockchain projects. In line with this commitment, we’re thrilled to announce the newest addition to our ecosystem—Scroll. Scroll is a zkEVM-based zkRollup on Ethereum. It promises to bring native compatibility for existing Ethereum applications and tools to the next level. Scroll uses the Ethereum base layer for posting succinct proofs of correctness on-chain after conducting transactions off-chain. This significantly enhances throughput, reduces costs, and makes Scroll an exciting asset in our arsenal. Now, let’s delve deeper into what Scroll is and explore its capabilities and potential. We are excited to share how this original product can redefine the way you approach blockchain and Ethereum applications. Our integration with Chainstack mirrors Scroll’s vision to revolutionize Ethereum applications by enhancing speed, reducing costs, and ensuring seamless EVM compatibility. As we fuse our unique off-chain operations model with Chainstack’s robust infrastructure, we’re geared up to redefine blockchain’s future. Together, we’re pushing the boundaries of blockchain to make it more secure, efficient, and accessible to all. The Scroll Team What is Scroll? Scroll is a remarkable zkEVM-based zkRollup on Ethereum, which is primarily designed to enhance the compatibility of existing Ethereum applications and tools. One of its fundamental principles is expandability. Scroll conducts transactions off-chain and subsequently posts succinct proofs of validity on-chain. This unique feature significantly increases throughput and reduces costs as opposed to the Ethereum base layer. If you are familiar with Ethereum, you will find developing on Scroll strikingly familiar since it mirrors Ethereum in functionality. Furthermore, any smart contract that falls in the realm of EVM compatibility can be smoothly deployed on the Scroll network. Putting a high premium on transparency and security, Scroll’s protocol is currently undergoing multiple third-party audits. The intention lies in bringing exposure to the protocol’s strengths and vulnerabilities if any, thereby reassuring the user community of its robustness. Scroll isn’t merely a protocol; it constitutes its own Layer 2 network, built on Ethereum, more precisely, a zero-knowledge rollup. It is designed diligently to bring interoperability with EVM bytecode and simulates the experience of developing on Ethereum. Therefore, for those skilled at developing on Ethereum, your existing code, dependencies, and tools are instantly compatible with Scroll. While the above are just broad strokes on what Scroll is, each of these aspects unfolds various features that make Scroll an exciting part of our ecosystem. As we move forward, let’s take a look at the unique features and benefits of developing with Scroll. Building on Scroll The inclusion of Scroll into the Chainstack ecosystem signifies a pivotal step forward in providing our user community with robust, scalable, and innovative solutions. Let’s delve into the unique features that make Scroll an exceptional product. Throughput enhancement – Scroll enhances Ethereum’s secure block space, enabling more network activity and reducing congestion thanks to ZK Rollups. By harnessing Ethereum’s security that uses zero-knowledge proofs to validate network activity, Scroll processes a higher number of transactions without sacrificing decentralization. Cost efficiency – Scroll vastly reduces gas fees for users on Ethereum, where elevated transaction costs result from competition for block space. By adopting the most recent advancements in zero-knowledge proofs and hardware acceleration, Scroll significantly broadens secure block space and reduces transaction costs for its users. Improved performance – Post the merge, Ethereum blocks confirm reliably every 12 seconds. In stark contrast, Scroll performs block minting every 3 seconds. Less risky operations consider transactions final once included in a block. This quick response time paves the way for new opportunities for on-chain interaction, especially in social and gaming applications. Aligned vision – Scroll shares Ethereum’s vision and aims to enhance it rather than compete against it. The core ethos of the protocol relates to decentralization, permissionlessness, censorship resistance, and community ownership. This ethos guides the team’s roadmap, with a focus on open-source software. Scroll closely collaborates with Ethereum Foundation’s Privacy and Scaling Exploration team to assist their work on a zkEVM that might be integrated into Ethereum’s core sometime in the future. Community-centric approach – Scroll is dedicated to connecting users and developers. The team understands the challenges of building in the open and seeking user engagement before the mainnet release. With a blossoming community of users and developers along with a discord community of over 100,000 members eager to test applications on the testnet, the Scroll team is actively bridging the gap between developers and users for potent real-world feedback. Advanced developer tooling – Scroll introduces a blockchain bridge, effortlessly linking the Goerli Testnet and Scroll Alpha Testnet. Its zkEVM-based zkRollup seamlessly integrates with existing Ethereum applications. The active Alpha Testnet marks a significant milestone in their journey, becoming the testing ground for zero-knowledge rollups built on Goerli. These unique features and advantages of Scroll allow Chainstack to deliver optimal value to our users. The true potential of Scroll becomes apparent when one comprehends the core concept and realizes how it delivers a futuristic and efficient solution to handle Ethereum applications. A lightning-fast highly secure L2 scaling with Scroll The partnership between Chainstack and Scroll not only illustrates our shared vision but also our belief in building a more resilient and effective ecosystem for developers building on Ethereum. By incorporating Scroll into our ecosystem, we strive to provide better throughput, increased efficiency, and significant cost reductions for users. As a zkEVM-based zkRollup on Ethereum, Scroll broadens the horizons of Ethereum applications, providing our users with an advanced and potent tool to develop, deploy, and manage their applications with native compatibility. Moreover, Scroll’s robust Layer 2 network, which employs a zero-knowledge rollup, enhances the expandability of Ethereum applications. It facelifts Ethereum’s potential by creating a pathway that consistently aligns with EVM bytecode, thereby simulating the experience of developing on Ethereum. At Chainstack, we harness Scroll’s underlying principles of expandability, EVM compatibility, and safeguarding to give our users the upper hand in the state-of-the-art blockchain development landscape. Our mission always remains to be the go-to platform for anyone seeking to explore and unlock the immense potential of blockchain, and the collaboration with Scroll takes us one step further in that direction. “The introduction of Scroll’s protocol signifies a landmark moment for Chainstack. As we incorporate their highly secure and efficient Layer 2 scaling solution, we are more equipped than ever to provide our users with the tools they need for fast, cost-effective, and privacy-preserving DApp development. We eagerly look forward to the further innovation this integration will unlock in the blockchain space.” Eugene Aseev, CTO and Co-Founder, Chainstack Integrating Scroll is a testament to our commitment to providing the best tools for our users to build and scale DApps of any size and stage. We eagerly look forward to the fascinating innovations this integration will bring to the blockchain landscape. Feature highlights Incorporating Scroll into our platform brings an influx of features that amplify the performance and potential of Ethereum-based applications. Here are some key feature highlights that Scroll brings to Chainstack: Expandability: Scroll conducts transactions off-chain, then posts concise proofs of correctness on-chain. This significantly enhances throughput and reduces costs compared to the Ethereum base layer. EVM-compatibility: Development on Scroll mirrors that on Ethereum. It means any smart contract compatible with EVM can be seamlessly deployed to Scroll’s network. Auditable security: Scroll’s protocol is currently under multiple third-party audits to ensure its security. Throughput enhancement: Scroll enhances Ethereum’s secure block space, enabling more network activity and reducing congestion thanks to ZK Rollups. Cost efficiency: Scroll significantly reduces gas fees for users on Ethereum. Increased efficiency: Scroll’s blocks are minted every 3 seconds, paving the way for new opportunities for on-chain interaction in social and gaming applications. Community-centric approach: Scroll is actively bridging the gap between developers and users for potent real-world feedback. Advanced developer tooling: Scroll introduces a blockchain bridge, effortlessly linking the Goerli Testnet and Scroll Alpha Testnet. These features highlight the core advantages of developing with Scroll on Chainstack, with each one contributing to making Ethereum applications more efficient, potent, and secure in their own unique way. Bringing it all together The introduction of Scroll into the Chainstack ecosystem is an exciting milestone in our constant pursuit of innovation. Our users now have access to a highly secure, efficient, and compatible solution for developing Ethereum applications. The distinctive features and benefits of Scroll, including EVM compatibility, increased throughput, cost efficiency, community-centric approach, and advanced developer tooling, make it an incredible asset for anyone engaged in blockchain development. At Chainstack, we remain committed to delivering the most robust, scalable, and innovative solutions to our users. Our collaboration with Scroll is just another step towards realizing this commitment, and we can’t wait to see the amazing creations that will emerge from this union. We are more than thrilled to welcome Scroll to our ecosystem and are looking forward to the immense value it is set to bring to our user community. Let’s embrace the future of blockchain development with Scroll, and together, let’s redefine the approach to Ethereum applications. Stay tuned to see how Scroll reshapes the Ethereum landscape within the Chainstack ecosystem. As always, we are incredibly thankful to our dedicated community of developers and users, without whom none of this would be possible. Together, let’s continue to explore the vast potential of blockchain technology. Thank you for being part of this exciting journey. Your constant support and feedback are what drives us to strive for excellence and keep innovating. Here’s to a future of more ground-breaking developments and exciting innovations with Chainstack and Scroll. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Sonic support We are excited to announce that Chainstack now fully supports Sonic, the highest-performing EVM Layer 1 blockchain. With real-time confirmations, sub-second finality, and ultra-low transaction costs, Sonic is redefining DeFi by combining speed, incentives, and cutting-edge infrastructure. At Chainstack, we are committed to providing the best blockchain infrastructure so you can build and scale seamlessly. Now, with our Global Sonic RPC Nodes, developers can leverage Sonic’s unparalleled speed and performance at the best price in just a few clicks. Why Sonic? Sonic is designed for high-performance blockchain applications, offering unprecedented scalability and storage solutions for developers while ensuring a seamless user experience. Unmatched speed and performance: Sub-second finality with real-time confirmation. Low costs: Average transaction cost of just $0.001. 100% EVM compatibility: Develop with Solidity and Vyper effortlessly. Advanced infrastructure: SonicVM, SonicDB, and Sonic Gateway enhance execution speed, security, and interoperability. Incentives for builders: With Fee Monetization, developers can earn 90% of their app’s fees, directly benefiting from increased on-chain activity. Figure 1: How the Sonic Gateway works; Source: Sonic Build better with Sonic on Chainstack Running Sonic nodes has never been easier. With Chainstack’s high-performance infrastructure, you can launch Sonic RPC nodes in minutes and focus entirely on building. Reliable Sonic Mainnet infrastructure Chainstack ensures robust and scalable Sonic nodes so you can interact with Sonic Mainnet instantly. We handle the heavy lifting so you can deploy, analyze, and scale with ease. Global Sonic RPC Nodes Our Global Sonic RPC Nodes provide highly available, geo-distributed, and secure API endpoints, allowing for instant interaction with Sonic Mainnet. Key features: Best throughput: No resource limitations—scale as needed. No daily request limits: Enjoy class-leading request volumes with no daily caps. Global endpoint locations: Geo-load balancing ensures optimal performance and latency. Flat-rate pricing: No method-specific fees—only predictable Request Unit (RU) billing. How to get started with Sonic on Chainstack Launching your Sonic infrastructure is seamless on Chainstack. Here’s how: Deploy a Sonic RPC node: Choose between Global or Dedicated Sonic Mainnet RPC Nodes. Use Sonic tooling: Interact with your node effortlessly using JSON-RPC and Web3 libraries. Build and earn: Explore the Sonic ecosystem and take advantage of Fee Monetization. Bringing it all together By integrating with Sonic, Chainstack empowers developers to build high-performance DeFi applications, DApps, and infrastructure at unprecedented speed and scale. Whether you’re developing a DeFi protocol, NFT marketplace, or high-throughput application, Chainstack Sonic Global Nodes provide the reliability and efficiency you need. Start your Sonic journey with Chainstack today and experience the future of ultra-fast, scalable blockchain development. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Stable Mainnet support We’re excited to announce that Chainstack now supports Stable — a stablecoin-native Layer 1 blockchain purpose-built for USDT payments and settlement. Starting today, you can deploy production-ready Stable Mainnet nodes on Chainstack in under two minutes. Why build on Stable? Stable is an EVM-compatible Layer 1 designed from line one for stablecoin finance, with USDT0 as the native gas token. Where general-purpose chains bolt stablecoin support on top of a volatile native asset, Stable inverts the model — stablecoins are first-class citizens, and the network is optimized around the operational realities of dollar-denominated onchain activity. USDT0 as native gas: Fees are dollar-denominated and predictable — no volatile native token to hedge, budget, or explain to your finance team. This makes Stable uniquely suited for payments, treasury, and fintech workloads where cost stability matters more than speculation. Purpose-built for stablecoin settlement: Rather than chasing every general-purpose use case, Stable narrows its design scope to stablecoin payments and settlement — the fastest-growing category in Web3 and the one traditional finance is actually adopting at scale. Full EVM compatibility: Solidity contracts, ethers.js, viem, Foundry, Hardhat — everything you already use for Ethereum works on Stable with a config change. No new toolchain to learn, no ecosystem cold-start. Tether-aligned: USDT is the world’s largest stablecoin by market cap and daily volume, and Stable is positioned as the L1 built around that liquidity — a distribution reality no purpose-built payments chain can match from scratch. For developers, Stable Mainnet is the on-ramp to a chain where every fee, transfer, and settlement operation is denominated in a currency your users already understand — dollars. Build better with Stable on Chainstack Running Stable Mainnet on Chainstack gives you reliable access and predictable performance for any workload — from stablecoin payment integrations and merchant tooling to RWA platforms and onchain analytics. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access to Stable Mainnet Full and Archive nodes — recent state or full history from genesis, matched to your workload Debug namespace on archive — debug_* methods including debug_traceCall and debug_traceTransaction for transaction replay, call tracing, and smart-contract debugging Standard Ethereum JSON-RPC compatibility — HTTPS and WebSocket endpoints that work with any EVM toolchain you already have How to get started with Stable on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select Stable as your blockchain protocol Choose Mainnet and Global Node Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints Start building on Stable → Bringing it all together With support for Stable Mainnet, Chainstack extends its infrastructure coverage into the stablecoin-finance stack — a category that’s quickly becoming one of the most consequential shifts in Web3. Whether you’re building payment rails, merchant checkout, remittance flows, or any product that touches Stable, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Stellar support We’re excited to announce that Chainstack now supports Stellar — a payments-focused Layer 1 with native JSON-RPC APIs and Soroban smart contracts. Starting today, you can deploy production-ready Stellar nodes on Chainstack as Global or Dedicated deployments, on both Mainnet and Testnet. Why build on Stellar? Stellar is a payments-focused Layer 1 blockchain launched in 2015 by the Stellar Development Foundation. Like XRP Ledger, it treats payments as the core primitive rather than one workload among many — but Stellar pairs that with Soroban, a full smart-contract platform, giving builders native payment rails and programmable logic on the same chain. Payments as the core primitive: the Stellar Consensus Protocol (SCP) reaches ledger close in roughly 5 seconds, with sub-cent transaction fees and native path payments and offers routed through a built-in decentralized exchange — no smart contract required for a basic currency swap. Soroban smart contracts: Rust-based, WASM-executed contracts sit alongside the native payment layer, so escrows, DeFi protocols, and RWA logic can be built without leaving Stellar’s payments-native security model. Battle-tested since 2015: over a decade of continuous production operation, secured by a federated network of validators who each choose their own trusted quorum — no single global validator list to coordinate. Native, not EVM: Stellar exposes its own JSON-RPC API via stellar-rpc rather than the Ethereum eth_* interface. Methods like getLedgers, getLedgerEntries, sendTransaction, and simulateTransaction match how Stellar and Soroban actually work. Note that stellar-rpc has no WebSocket listener — all access is JSON-RPC over HTTPS. For developers, Stellar is the on-ramp to a chain built for cross-border settlement and remittances from day one, with Soroban available the moment you need more than a native payment operation. Build better with Stellar on Chainstack Running Stellar on Chainstack gives you reliable access and predictable performance for payment integrations, remittance flows, Soroban contract deployment, and onchain analytics. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access to Stellar Mainnet and Testnet Dedicated Nodes — isolated stellar-core infrastructure across all Chainstack locations for teams that need single-tenant nodes in a specific region Full stellar-rpc method coverage — getHealth, getNetwork, getVersionInfo, getLatestLedger, getLedgers, getLedgerEntries, sendTransaction, getTransaction/getTransactions, simulateTransaction, getEvents, and getFeeStats JSON-RPC over HTTPS — no WebSocket endpoint on this client, so every integration talks to a single HTTPS URL rather than juggling separate subscription infrastructure How to get started with Stellar on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select Stellar as your blockchain protocol Choose Mainnet or Testnet, and pick Global for shared geo-balanced access or Dedicated for isolated resources Deploy the node Open Access and credentials and copy your HTTPS endpoint Start building on Stellar → Bringing it all together With support for Stellar, Chainstack extends its infrastructure coverage into one of the longest-running payments-native blockchains in Web3 — now with Soroban smart contracts alongside the native payment rails. Whether you’re building payment rails, remittance flows, or Soroban-based DeFi and RWA products, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, XRP Ledger, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group. Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Apechain We’re excited to announce that Chainstack now supports the Apechain network, a Layer 2 blockchain developed by Yuga Labs, designed to power the next generation of NFT and gaming ecosystems. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Apechain faster than ever—without worrying about costly infrastructure overhead. Why build on Apechain? Apechain is a purpose-built gaming and NFT chain, optimized for throughput, composability, and Ethereum compatibility. Built for game economies and creator tools, it offers: Scalable architecture: Designed for fast-paced NFT minting and in-game transactions. Full EVM compatibility: Deploy smart contracts using familiar Ethereum tooling. Yuga Labs ecosystem: Backed by the team behind Bored Ape Yacht Club, Otherside, and more. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Apechain on Chainstack Running Apechain nodes is now NFT-native and performance-optimized with Chainstack. Whether you’re launching gaming assets or building Otherside integrations, Chainstack offers: Dedicated Apechain RPC infrastructure for NFT + game logic Zero per-call billing—simple, predictable pricing Cloud deployment in regions closest to your players Get started: Build better with Apechain How to get started with Apechain on Chainstack Spin up a node: Request Apechain infrastructure via the Chainstack console or Sales. Connect with tools: Use EVM-compatible SDKs to access Apechain’s RPC endpoints. Build and deploy: From NFT minting to multiplayer mechanics, you handle gameplay—Chainstack handles scale. See our pricing plans Bringing it all together With our support for Apechain, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re crafting the next hit Web3 game or an immersive NFT experience, Chainstack Apechain infrastructure is here to support you every step of the way. Start building with Apechain today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Astar We’re excited to announce that Chainstack now supports the Astar network, a multi-chain smart contract platform that supports both EVM and WASM environments for next-gen DApp development. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Astar faster than ever—without worrying about costly infrastructure overhead. Why build on Astar? Astar is a Polkadot parachain and smart contract hub. Built for multi-chain apps, NFTs, and on-chain governance, it offers: Dual VM support: Run smart contracts in EVM and WASM side-by-side. Native Polkadot integration: Secure and scalable via the Polkadot relay chain. DApp staking: Developers get rewarded by users directly through protocol-level staking. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Astar on Chainstack Running Astar nodes is now seamless with Chainstack. Whether you’re deploying WASM contracts, cross-chain DeFi protocols, or multichain apps, Chainstack offers: Dedicated, EVM + WASM-compatible Astar node infrastructure Flat pricing—no method-based billing or usage caps Globally distributed deployment for optimal latency Get started: Build better with Astar How to get started with Astar on Chainstack Spin up a node: Request via the Chainstack console or Sales to launch your Astar node. Connect with tools: Use EVM-compatible RPCs or WASM toolkits provided by Astar. Build and deploy: Whether it’s a DeFi hub or WASM-powered DApp, you stay focused on development—not infra. See our pricing plans Bringing it all together With our support for Astar, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re targeting the Polkadot ecosystem or building on both EVM and WASM, Chainstack Astar infrastructure is here to support you every step of the way. Start building with Astar today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for B² We’re excited to announce that Chainstack now supports the B² Network, a zero-knowledge rollup Layer 2 built on Bitcoin—bringing zk verification commitments, Ethereum compatibility, and novel challenge mechanisms to the world’s most secure blockchain. With this integration, developers can now explore the frontier of Bitcoin-based rollups using Chainstack’s scalable, test-friendly infrastructure. Why build on B²? B² is a practical Bitcoin Layer 2 network, purpose-built to bring smart contract programmability and rollup efficiency to Bitcoin. Key features include: ZK verification commitments on Bitcoin: A novel commitment system using Taproot, enabling fraud-proof–driven challenge mechanisms. EVM compatibility: Deploy Ethereum-style smart contracts and dApps using both Bitcoin and Ethereum address formats. Low cost, fast, and trust-minimized: Rollup efficiency meets Bitcoin-level security for scalable DeFi and infrastructure. B² is the first zk-powered Bitcoin rollup to introduce a full challenge-based trust system, combining the best of Ethereum’s L2 architecture with Bitcoin-native design. Build better with B² on Chainstack Running B² nodes is now zk-native and protocol-flexible with Chainstack. Whether you’re verifying rollup proofs, running fraud challenge simulations, or testing Bitcoin-compatible smart contracts, Chainstack offers: Dedicated B² RPC infrastructure for zero-knowledge rollup experimentation Transparent flat-rate pricing—ideal for test-heavy cycles and low-overhead builds Cloud-deployable anywhere with deep regional support for performance tuning Get started: Build better with B² How to get started with B² on Chainstack Spin up a node: Request your a B² node using the Chainstack console or contact our Sales team. Connect with tools: Use standard EVM SDKs or B²-specific commitment and challenge frameworks. Build and deploy: From zk circuits to fraud-proof simulations—Chainstack powers Bitcoin-native innovation. See our pricing plans Bringing it all together With support for B², Chainstack is enabling a new wave of developers to bring Ethereum-style execution to Bitcoin while pioneering next-gen zk verification. If you’re building at the edge of Bitcoin Layer 2 innovation, Chainstack B² infrastructure is here to support you every step of the way. Start building with B² today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Bitlayer We’re excited to announce that Chainstack now supports the Bitlayer network, a Bitcoin Layer 2 solution aiming to bring smart contract functionality to the Bitcoin ecosystem. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Bitlayer faster than ever—without worrying about costly infrastructure overhead. Why build on Bitlayer? Bitlayer is a smart contract-enabled Layer 2 chain that inherits Bitcoin’s base layer security. Built for DeFi, bridges, and developer tools, it offers: Bitcoin-native Layer 2: Enables Solidity smart contracts on BTC-secured infrastructure. EVM compatibility: Build using Ethereum tools and migrate DApps seamlessly. ZK-rollup architecture: Ensures scalable throughput and privacy. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Bitlayer on Chainstack Running Bitlayer nodes is now Bitcoin-aligned and smart contract–enabled with Chainstack. Whether you’re building BTC-backed DeFi or bridging between Bitcoin and EVM, Chainstack offers: Dedicated Bitlayer infrastructure secured by Bitcoin’s base layer Flat, RU-based billing—no fee surprises or hidden multipliers Global infrastructure with support for zk-rollup scaling Get started: Build better with Bitlayer How to get started with Bitlayer on Chainstack Spin up a node: Request a Bitlayer node via the Chainstack console or contact Sales. Connect with tools: Use Solidity-compatible tooling or Bitlayer SDKs. Build and deploy: Whether extending Bitcoin or launching zk-powered DApps, your backend just works. See our pricing plans Bringing it all together With our support for Bitlayer, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. If you believe Bitcoin should be programmable, Chainstack Bitlayer infrastructure is here to support you every step of the way. Start building with Bitlayer today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Botanix We’re excited to announce that Chainstack now supports the Botanix network, a Layer 2 solution for Bitcoin that brings Ethereum-style smart contracts and programmability to the world’s most secure base layer. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Botanix faster than ever—without worrying about costly infrastructure overhead. Why build on Botanix? Botanix is a Bitcoin Layer 2 designed to unlock smart contract logic on BTC without sacrificing decentralization. Built for DeFi, programmable assets, and financial primitives, it offers: Bitcoin security with Ethereum UX: Full Solidity and Web3 compatibility on BTC-backed Layer 2. Bridge-free user onboarding: No wrapped assets or centralized intermediaries required. Open EVM execution: Launch DApps directly on the Bitcoin economic layer. For developers, it means the first fully decentralized BTC smart contract experience—with all the tooling you’re used to from Ethereum. Build better with Botanix on Chainstack Running Botanix nodes is now Bitcoin-rooted and Solidity-ready with Chainstack. Whether you’re enabling smart contracts on BTC or bridging cross-chain DeFi, Chainstack offers: Dedicated Botanix RPC infrastructure with BTC-layer integration Flat pricing—no hidden call multipliers or per-request surcharges Global availability with performance-tuned backend for financial apps Get started: Build better with Botanix How to get started with Botanix on Chainstack Spin up a node: Request your Botanix node through the Chainstack console or our Sales team. Connect with tools: Use Ethereum-standard libraries or Botanix-native endpoints. Build and deploy: From BTC DeFi to programmable payments—launch fast, scale globally. See our pricing plans Bringing it all together With our support for Botanix, we’re continuing our mission to enable scalable, reliable, and forward-compatible Web3 development across both new and established ecosystems. If you’re ready to bring programmable finance to Bitcoin, Chainstack Botanix infrastructure is here to support you every step of the way. Start building with Botanix today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Cardano We’re excited to announce that Chainstack now supports the Cardano network, a research-driven, sustainability-focused Layer 1 blockchain built on peer-reviewed academic foundations. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Cardano faster than ever—without worrying about costly infrastructure overhead. Why build on Cardano? Cardano is a highly secure and energy-efficient blockchain designed for DeFi, governance, and identity use cases. Built for long-term scalability, it offers: Ouroboros PoS consensus: Secure, energy-efficient, and provably fair. Formal verification: Mathematically verifiable smart contracts for mission-critical applications. Modular architecture: Supports upgrades without compromising core stability. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Cardano on Chainstack Running Cardano nodes is now frictionless with Chainstack Dedicated Node. Whether you’re supporting DeFi protocols, building NFT marketplaces, or running analytics, Chainstack offers: Dedicated, high-performance Cardano node infrastructure No per-request billing—pay only for compute and storage Global deployment on the cloud and region of your choice Get started: Build better with Cardano How to get started with Cardano on Chainstack Spin up a node: Request from the Chainstack console or contact Sales to deploy a Cardano node. Connect with tools: Use Cardano’s CLI, GraphQL, or REST interfaces. Build and deploy: From smart contract execution to NFT minting—build without infrastructure bottlenecks. See our pricing plans Bringing it all together With our support for Cardano, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building public goods, launching sustainable finance apps, or innovating on governance, Chainstack Cardano infrastructure is here to support you every step of the way. Start building with Cardano today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Centrifuge We’re excited to announce that Chainstack now supports the Centrifuge network, a DeFi protocol designed to bring real-world assets (RWAs) on-chain, enabling businesses to unlock liquidity using tokenized collateral. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Centrifuge faster than ever—without worrying about costly infrastructure overhead. Why build on Centrifuge? Centrifuge is a pioneer in RWA tokenization and creator of the Tinlake protocol. Built for asset originators, institutions, and DeFi lenders, it offers: On-chain RWA tokenization: Real estate, invoices, and other off-chain assets brought into DeFi. Protocol-level compliance: Frameworks for KYC, disclosures, and legal structuring. Interoperability with major DeFi protocols: Integrations with MakerDAO, Aave, and more. For developers, it means building at the intersection of DeFi and traditional finance—with real yield and real-world collateral. Build better with Centrifuge on Chainstack Running Centrifuge nodes is now real-world-asset–ready and Substrate-native with Chainstack. Whether you’re tokenizing invoices, real estate, or credit, Chainstack offers: Dedicated Centrifuge infrastructure for asset-backed DeFi No API usage multipliers—stable, RU-based billing Enterprise cloud deployment with global access and uptime guarantees Get started: Build better with Centrifuge How to get started with Centrifuge on Chainstack Spin up a node: Request via the Chainstack console or contact Sales to deploy a Centrifuge node. Connect with tools: Use Substrate RPC, Polkadot.js, or Tinlake interfaces. Build and deploy: Whether launching RWAs or integrating TradFi partners—Chainstack runs the rails. See our pricing plans Bringing it all together With our support for Centrifuge, we’re continuing our mission to enable scalable, reliable, and real-world-ready Web3 development. If you’re building the financial rails for asset tokenization, Chainstack Centrifuge infrastructure is here to support you every step of the way. Start building with Centrifuge today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Core We’re excited to announce that Chainstack now supports the Core network, a Layer 1 blockchain designed with a strong emphasis on security, decentralization, and Bitcoin compatibility. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Core faster than ever—without worrying about costly infrastructure overhead. Why build on Core? Core is a Bitcoin-powered L1 that blends Ethereum virtual machine compatibility with Bitcoin security. Built for DeFi, security-focused DApps, and BTC-backed use cases, it offers: Bitcoin hash power–secured consensus: Satoshi Plus combines PoW and DPoS for optimal decentralization. EVM compatibility: Supports Ethereum tooling, libraries, and Solidity contracts. Cross-chain operability: Bridges BTC-native assets into smart contract logic. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Core on Chainstack Running Core nodes is now Bitcoin-secured and EVM-compatible with Chainstack. Whether you’re building BTC-backed DeFi or deploying trust-minimized applications, Chainstack offers: Dedicated Core infrastructure secured by Satoshi Plus consensus Flat-rate billing—no hidden fees, no per-method surprises Globally distributed node support for top-tier performance Get started: Build better with Core How to get started with Core on Chainstack Spin up a node: Request your Core node via the Chainstack console or Sales. Connect with tools: Use EVM-compatible SDKs or Core-native APIs. Build and deploy: Whether bridging BTC or launching secure DApps, Chainstack powers your scale. See our pricing plans Bringing it all together With our support for Core, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. If you’re building trust-minimized, Bitcoin-aligned applications, Chainstack Core infrastructure is here to support you every step of the way. Start building with Core today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Corn We’re excited to announce that Chainstack now supports the Corn network, the BTCFi-native Layer 2 built on Arbitrum Orbit—bringing Bitcoin-backed yield, decentralized incentives, and permissionless interoperability to Ethereum’s DeFi landscape. With this integration, developers can now launch Bitcoin-enabled DApps using Chainstack’s scalable infrastructure and help usher in a new era of DeFi powered by BTC liquidity. Why build on Corn? Corn is purpose-built for Bitcoin DeFi (BTCFi). It merges Bitcoin’s liquidity and security with EVM-based programmability and native L2 incentives. Key innovations include: BTCN as gas: A 1:1 Bitcoin-backed gas token ($BTCN), enabling BTC-native UX across Ethereum dApps. popCORN System: A veTokenomics-inspired voting and bribe market that lets $CORN holders direct yield to aligned protocols. Bitcoin Clearing House: A mechanism for minting and stabilizing BTCN, inspired by MakerDAO’s PSM. With integrations from Coinbase, BitGo, LayerZero, and Babylon, Corn acts as a bridge between Bitcoin and the most advanced DeFi ecosystems. Build better with Corn on Chainstack Running Corn nodes is now BTCFi-native and high-performance with Chainstack. Whether you’re deploying tokenized BTC apps, building staking logic, or launching incentive markets, Chainstack offers: Dedicated Corn RPC infrastructure built for low-latency DeFi and high-throughput Bitcoin-backed apps Flat-rate pricing—no gas spikes, no surprises Global cloud availability with fast access to BTC liquidity layers Get started: Build better with Corn How to get started with Corn on Chainstack Spin up a node: Request your Corn RPC node from the Chainstack console or our Sales team. Connect with tools: Use EVM-standard SDKs or native Corn APIs. Build and deploy: Whether it’s minting BTCN, building bribe markets, or integrating LayerZero—Chainstack powers your backend. See our pricing plans Bringing it all together With support for Corn, Chainstack enables developers to tap into Bitcoin’s deep liquidity and pair it with Ethereum-grade programmability. If you’re building for BTCFi, Chainstack Corn infrastructure is here to support you every step of the way. Start building with Corn today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Dogecoin We’re excited to announce that Chainstack now supports the Dogecoin network, a top-tier, community-driven blockchain known for its strong merchant adoption and vibrant culture. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Dogecoin faster than ever—without worrying about costly infrastructure overhead. Why build on Dogecoin? Dogecoin is a proof-of-work blockchain launched as a fun, approachable alternative to Bitcoin. Built for peer-to-peer payments, tipping, and lightweight commerce, it offers: Strong community support: One of the most active and loyal user bases in crypto. Broad merchant adoption: Accepted by thousands of online retailers and payment platforms. Low transaction fees: Optimized for micro-transactions and fast confirmations. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Dogecoin on Chainstack Running Dogecoin nodes is now limitless with Chainstack Dedicated Node. Whether you’re building high-throughput DApps, scaling infrastructure, or powering analytics, Chainstack offers: Dedicated, high-performance Dogecoin node infrastructure No per-request billing — pay only for compute and storage Global deployment on the cloud and location of your choice Get started: Build better with Dogecoin How to get started with Dogecoin on Chainstack Spin up a node: Request via the Chainstack console or our Sales team to deploy a Dogecoin node. Connect with tools: Use Dogecoin’s JSON-RPC interface to integrate seamlessly. Build and deploy: Whether it’s a tipping bot, micropayment wallet, or meme-powered DApp, focus on code—not node maintenance. See our pricing plans Bringing it all together With our support for Dogecoin, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building a meme-fueled micro-economy or a real-world payment platform, Chainstack Dogecoin infrastructure is here to support you every step of the way. Start building with Dogecoin today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Etherlink We’re excited to announce that Chainstack now supports the Etherlink network, a Layer 2 solution focused on improving Ethereum’s data availability and reducing congestion through innovative modular design. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Etherlink faster than ever—without worrying about costly infrastructure overhead. Why build on Etherlink? Etherlink is a modular Ethereum-compatible L2 that offloads data availability while preserving full smart contract functionality. Built for scalable DApps, bridges, and modular data layers, it offers: Improved data availability: Reduces L1 congestion via efficient off-chain storage models. Full EVM support: Seamlessly deploy Ethereum contracts with no rewrites. Optimized for throughput: Lower fees and faster finality for high-frequency use cases. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Etherlink on Chainstack Running Etherlink nodes is now modular and data-optimized with Chainstack. Whether you’re building streaming data DApps, DA layers, or hybrid rollups, Chainstack offers: Dedicated Etherlink RPC infrastructure for scalable data availability Flat pricing—no variable fees per method or bandwidth used Global deployment options for real-time performance Get started: Build better with Etherlink How to get started with Etherlink on Chainstack Spin up a node: Request an Etherlink node through the Support ticket or our Sales team. Connect with tools: Use Etherlink’s SDKs, APIs, or EVM-compatible interfaces. Build and deploy: From data-heavy DApps to L2 extensions, focus on your stack—not the infra. See our pricing plans Bringing it all together With our support for Etherlink, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most technically advanced networks. If you’re building the next evolution of modular, data-driven Web3 DApps, Chainstack Etherlink infrastructure is here to support you every step of the way. Start building with Etherlink today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Fraxchain We’re excited to announce that Chainstack now supports the Fraxchain network, a stablecoin-native Layer 2 solution focused on enabling next-gen DeFi scalability and capital efficiency. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Fraxchain faster than ever—without worrying about costly infrastructure overhead. Why build on Fraxchain? Fraxchain is a modular, Ethereum-compatible Layer 2 built by the team behind FRAX, the first fractional-algorithmic stablecoin. Built for DeFi protocols and stablecoin operations, it offers: Frax-native gas economy: Pay gas fees in FRAX for stable cost execution. EVM compatibility: Use Solidity, Web3 libraries, and MetaMask out of the box. Low fees, high throughput: Optimized for high-volume stablecoin movement. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Fraxchain on Chainstack Running Fraxchain nodes is now DeFi-native and stablecoin-ready with Chainstack. Whether you’re building on-chain liquidity markets or gasless FRAX payment rails, Chainstack offers: Dedicated Fraxchain RPC infrastructure optimized for stablecoins No per-call costs—flat pricing for compute and storage Globally deployed nodes for latency-sensitive financial apps Get started: Build better with Fraxchain How to get started with Fraxchain on Chainstack Spin up a node: Request your Fraxchain node from the Chainstack console or contact Sales. Connect with tools: Use JSON-RPC and Ethereum tooling with native FRAX gas support. Build and deploy: Launch payment flows, swap apps, or stablecoin DeFi—all without infra headaches. See our pricing plans Bringing it all together With our support for Fraxchain, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re scaling stablecoin finance or reshaping liquidity flows, Chainstack Fraxchain infrastructure is here to support you every step of the way. Start building with Fraxchain today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Hashkey We’re excited to announce that Chainstack now supports the Hashkey network, a blockchain platform associated with institutional-grade digital asset infrastructure, offering compliant and secure solutions for Web3 builders. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Hashkey faster than ever—without worrying about costly infrastructure overhead. Why build on Hashkey? Hashkey powers an ecosystem of regulated DeFi and tokenization solutions designed for institutions and enterprises. Built for stablecoin issuance, tokenized finance, and Web3 identity, it offers: Regulatory-grade infrastructure: Built to comply with financial regulations in key jurisdictions. Secure digital asset custody: Enterprise-grade mechanisms for token operations and storage. EVM compatibility: Supports Ethereum-based smart contracts with enhanced security overlays. For developers, it means better compliance, stronger guarantees, and access to a finance-first blockchain stack. Build better with Hashkey on Chainstack Running Hashkey nodes is now institution-grade and compliant-ready with Chainstack. Whether you’re building regulated DeFi platforms or tokenized asset systems, Chainstack offers: Dedicated Hashkey RPC infrastructure with enterprise security Predictable pricing—no usage spikes or hidden method costs Cloud deployment aligned with regulatory zones and uptime SLAs Get started: Build better with Hashkey How to get started with Hashkey on Chainstack Spin up a node: Request via the Chainstack console or contact Sales to launch a Hashkey node. Connect with tools: Use EVM-compatible SDKs and institutional APIs. Build and deploy: Whether launching digital asset platforms or secure wallets, focus on compliance—not servers. See our pricing plans Bringing it all together With our support for Hashkey, we’re continuing our mission to enable compliant, high-performance Web3 development that can thrive under institutional demands. If you’re bridging traditional finance and DeFi, Chainstack Hashkey infrastructure is here to support you every step of the way. Start building with Hashkey today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Hyperliquid We’re excited to announce that Chainstack now supports the Hyperliquid network, a cutting-edge, performance-driven blockchain focused on ultra-fast, decentralized trading and execution. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Hyperliquid faster than ever—without worrying about costly infrastructure overhead. Why build on Hyperliquid? Hyperliquid is a next-generation decentralized order book chain. Built for real-time DeFi, DEX infrastructure, and algorithmic trading, it offers: Low-latency execution: Optimized for sub-second finality in high-frequency trading environments. Native order books: A unique model supporting trustless market-making and CEX-grade performance. Fast-growing ecosystem: Powering new classes of decentralized trading platforms. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Hyperliquid on Chainstack Running Hyperliquid nodes is now high-performance and ready for scale with Chainstack. Whether you’re enabling fast transaction settlement or powering real-time analytics, Chainstack offers: Dedicated, low-latency Hyperliquid node infrastructure Flat pricing—no per-request penalties or bandwidth surprises Global availability with customizable cloud deployment Get started: Build better with Hyperliquid How to get started with Hyperliquid on Chainstack Spin up a node: Request via the Chainstack console or contact Sales to deploy a Hyperliquid node. Connect with tools: Use Hyperliquid’s API suite and client SDKs. Build and deploy: Whether building a perpetuals UI or market analytics engine, focus on UX—not node ops. See our pricing plans Bringing it all together With our support for Hyperliquid, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building high-frequency trading systems or real-time price discovery apps, Chainstack Hyperliquid infrastructure is here to support you every step of the way. Start building with Hyperliquid today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Ink We’re excited to announce that Chainstack now supports the Ink platform, a Rust-based smart contract language built specifically for Substrate-based blockchains, unlocking secure, efficient, and composable on-chain logic. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their Ink-based contracts faster than ever—without worrying about costly infrastructure overhead. Why build with Ink? Ink is the native smart contract language for Polkadot, Kusama, and Substrate ecosystems. Built for performance and safety, it offers: Rust-native language: Compile secure, low-level smart contracts with robust tooling. Substrate compatibility: Power any parachain or standalone Substrate runtime. WASM output: Deploy to chains supporting WebAssembly smart contracts. For developers, it means lower risk, better tooling, and a powerful gateway into Polkadot-based ecosystems. Build better with Ink on Chainstack Running Ink smart contracts on Chainstack is now Substrate-native and WASM-secure. Whether you’re building advanced logic for parachains or launching low-gas apps, Chainstack offers: Dedicated Ink-compatible infrastructure for Polkadot and Substrate Flat compute-based pricing—no request inflation Custom cloud deployment with Substrate tooling pre-integrated Get started: Build better with Ink How to get started with Ink on Chainstack Spin up a node: Request an Ink node via the Chainstack console or contact Sales. Connect with tools: Use the Rust-based toolchain and Substrate API endpoints. Build and deploy: From pallets to smart contracts, build secure, performant DApps on-chain. See our pricing plans Bringing it all together With our support for Ink, we’re continuing our mission to enable scalable, secure, and modern Web3 development across the most flexible ecosystems. If you’re building the future of decentralized infrastructure, Chainstack Ink support is here to back you every step of the way. Start building with Ink today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Katana We’re excited to announce that Chainstack now supports the Katana network, a DeFi-first Layer 2 blockchain incubated by Polygon Labs and GSR, purpose-built to unify liquidity and deliver sustainable, real yield across decentralized finance. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale DeFi applications on Katana—with high-speed performance and no infrastructure friction. Why build on Katana? Katana is a production-grade Ethereum Layer 2 rollup tailored for DeFi. Built using a custom OP Stack (cdk-opgeth) and integrated with Polygon’s AggLayer, Katana aims to solve some of DeFi’s hardest challenges—fragmented liquidity, capital inefficiency, and yield sustainability. It offers: Unified DeFi liquidity: Native integrations with Sushi (DEX), Morpho (lending), and Vertex (perpetuals) to streamline access and amplify capital flow. Sustainable yield strategies: Yield is generated across lending, trading, and derivatives protocols—designed for long-term alignment. Advanced infra stack: Built with cdk-opgeth and OP Stack, connected to Polygon’s AggLayer, and enhanced with zero-knowledge proofs from Succinct SP1 and Plonky3. Governance via veKAT: The KAT token allows users to lock for veKAT to vote on protocol emissions and incentive structures. For developers, it means building yield-driven dApps on composable, high-performance rails with deep liquidity by default. Build better with Katana on Chainstack Running Katana nodes is now seamless and high-performance with Chainstack. Whether you’re building a trading protocol, yield optimizer, or DeFi dashboard, Chainstack offers: Dedicated, performance-optimized Katana RPC infrastructure Flat-rate billing with no request-based fees or network surge pricing Full support for Katana’s OP Stack and ZK-proof integrations Get started: Build better with Katana How to get started with Katana on Chainstack Spin up a node: Launch your Katana node in the Chainstack console. Connect with tools: Use EVM-compatible libraries and Katana’s specialized OP Stack + AggLayer toolchain. Build and deploy: From next-gen trading protocols to yield strategies, focus on building—let us handle the infra. See our pricing plans Bringing it all together With support for the OP-based DeFi Layer 2, Chainstack continues its mission to empower the next generation of DeFi builders with infrastructure that scales. If you’re building high-throughput, yield-generating DApps on Katana, Chainstack is the fastest path to production. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Kroma We’re excited to announce that Chainstack now supports the Kroma network, a user-friendly Layer 2 solution that emphasizes performance, simplicity, and developer experience on top of Ethereum. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Kroma faster than ever—without worrying about costly infrastructure overhead. Why build on Kroma? Kroma is a Type 3 zkEVM rollup with an emphasis on streamlined UX and plug-and-play development. Built for DApps, wallets, and games, it offers: Simplified onboarding: Fast developer setup and low-friction integration. Low fees, fast finality: zkEVM-backed performance for real-world DApp usability. EVM compatibility: Migrate existing Ethereum contracts with no code changes. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Kroma on Chainstack Running Kroma nodes is now developer-first and latency-optimized with Chainstack. Whether you’re building lightweight consumer DApps or high-frequency DeFi apps, Chainstack offers: Dedicated Kroma RPC infrastructure with zkEVM support Transparent pricing—no method weight tricks or request limits Global deployment with fast setup and easy scaling Get started: Build better with Kroma How to get started with Kroma on Chainstack Spin up a node: Request from the Chainstack console or Sales to launch your Kroma node. Connect with tools: Use Ethereum-compatible libraries, RPCs, and tooling. Build and deploy: Whether for wallets, games, or DeFi, focus on UX—not infrastructure. See our pricing plans Bringing it all together With our support for Kroma, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. If you’re building intuitive, UX-optimized DApps, Chainstack Kroma infrastructure is here to support you every step of the way. Start building with Kroma today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Lens We’re excited to announce that Chainstack now supports the Lens network, a decentralized social graph protocol that enables developers to build composable, user-owned Web3 social apps. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Lens faster than ever—without worrying about costly infrastructure overhead. Why build on Lens? Lens is a Web3-native protocol for social media and creator ecosystems. Built for identity, reputation, and decentralized content, it offers: User-owned profiles: Social identity lives on-chain, not in a siloed database. Composable social graph: Easily build on top of any Lens-based app or interaction. NFT-native architecture: Every action is tokenized, enabling monetization and portability. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Lens on Chainstack Running Lens nodes is now creator-friendly and reliable with Chainstack. Whether you’re building Web3 social feeds, NFT drops, or decentralized identity layers, Chainstack offers: Dedicated Lens node infrastructure with social graph indexing support No per-API call costs—flat billing, no surprises Global deployment options for performance across regions Get started: Build better with Lens How to get started with Lens on Chainstack Spin up a node: Request from the Chainstack console or Sales to deploy a Lens node. Connect with tools: Use Lens SDKs and Graph APIs to build your app layer. Build and deploy: Whether it’s a decentralized social app or community gateway, Chainstack handles the backend. See our pricing plans Bringing it all together With our support for Lens, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re reshaping content, community, or creator economies, Chainstack Lens infrastructure is here to support you every step of the way. Start building with Lens today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Linea We’re excited to announce that Chainstack now supports the Linea network, a zkEVM Layer 2 solution from Consensys that aims to bring scalable Ethereum compatibility without compromising performance or developer experience. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Linea faster than ever—without worrying about costly infrastructure overhead. Why build on Linea? Linea is a zk-rollup using Type 2 zkEVM, ensuring seamless support for Ethereum smart contracts. Built for DeFi, NFTs, and low-cost transactions, it offers: Native EVM compatibility: Write and deploy Solidity contracts as-is. Fast finality and low fees: Leverages zk-rollup efficiency for production-grade performance. Backed by Consensys: Integrates tightly with tools like MetaMask, Infura, and Truffle. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Linea on Chainstack Running Linea nodes is now zkEVM-optimized and battle-ready with Chainstack. Whether you’re deploying Ethereum-native contracts or scaling DApps with lower fees, Chainstack offers: Dedicated Linea zkEVM infrastructure with sub-second finality No per-method costs—flat usage-based pricing Global deployment across low-latency regions Get started: Build better with Linea How to get started with Linea on Chainstack Spin up a node: Request your Linea node from the Chainstack console or our Sales team. Connect with tools: Use JSON-RPC, gRPC, and MetaMask directly with Linea. Build and deploy: From gas-optimized DApps to large-scale L2 operations, focus on building—leave the infra to us. See our pricing plans Bringing it all together With our support for Linea, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. If you’re building DApps with Ethereum UX but need better cost and performance, Chainstack Linea infrastructure is here to support you every step of the way. Start building with Linea today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Mantle We’re excited to announce that Chainstack now supports the Mantle network, a modular Layer 2 blockchain purpose-built to enhance Ethereum scalability and lower on-chain costs for builders. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Mantle faster than ever—without worrying about costly infrastructure overhead. Why build on Mantle? Mantle is a Layer 2 rollup chain powered by EigenDA and designed for ultra-low gas fees. Built for DeFi, gaming, and general-purpose DApps, it offers: Modular architecture: Combines OP Stack and EigenLayer for performance and flexibility. Low transaction fees: Optimized for user adoption and cost-effective scaling. Ethereum compatibility: Full EVM support with easy DApp migration. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Mantle on Chainstack Running Mantle nodes is now effortless with Chainstack Global and Dedicated nodes. Whether you’re building modular L2 tooling or deploying high-throughput DApps, Chainstack offers: Enterprise-grade, high-performance Mantle node infrastructure No request multipliers—just transparent, usage-based billing Global deployment optimized for latency and throughput Get started: Build better with Mantle How to get started with Mantle on Chainstack Spin up a node: Access the Chainstack console or contact Sales to launch your Mantle RPC node. Connect with tools: Use Mantle’s JSON-RPC and Ethereum-compatible libraries. Build and deploy: Launch DApps with confidence, from DeFi to DAOs—Chainstack handles the backend. See our pricing plans Bringing it all together With our support for Mantle, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building DeFi protocols or open-world economies, Chainstack Mantle infrastructure is here to support you every step of the way. Start building with Mantle today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Merlin We’re excited to announce that Chainstack now supports the Merlin network, a new EVM-compatible blockchain focused on enhancing smart contract functionality and unlocking next-gen developer experiences. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Merlin faster than ever—without worrying about costly infrastructure overhead. Why build on Merlin? Merlin is a performance-first blockchain purpose-built for developers seeking more control and flexibility. Built for DApps, DeFi, and modular contracts, it offers: Enhanced EVM compatibility: Supports advanced Solidity patterns and improved tooling. Optimized for builders: Minimal overhead and faster deploy-test-iterate loops. Secure, scalable core: Designed to handle high-volume Web3 use cases. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Merlin on Chainstack Running Merlin nodes is now EVM-optimized and dev-focused with Chainstack. Whether you’re building smart contract platforms, automation engines, or tokenized protocols, Chainstack offers: Dedicated Merlin RPC infrastructure with advanced dev tooling Transparent usage-based pricing with no method multipliers High-availability deployment across leading cloud providers Get started: Build better with Merlin How to get started with Merlin on Chainstack Spin up a node: Request a Merlin node via the Chainstack console or contact Sales. Connect with tools: Use EVM RPC, Solidity dev frameworks, and Merlin APIs. Build and deploy: Whether it’s protocol orchestration or contract automation—Chainstack has you covered. See our pricing plans Bringing it all together With our support for Merlin, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most promising and creative ecosystems. If you’re building flexible, modern DApps, Chainstack Merlin infrastructure is here to support you every step of the way. Start building with Merlin today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Metis We’re excited to announce that Chainstack now supports the Metis network, a Layer 2 Ethereum scaling solution designed to support decentralized autonomous companies (DACs) and accelerate mainstream Web3 adoption. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Metis faster than ever—without worrying about costly infrastructure overhead. Why build on Metis? Metis is a hybrid Layer 2 rollup that combines scalability with advanced governance and identity tooling. Built for DAOs, DeFi, and open economies, it offers: DAC-friendly framework: Enables native tooling for decentralized business operations. Low fees with high throughput: Optimized for real-world application scalability. EVM compatibility: Build with familiar tools and easily migrate existing Ethereum contracts. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Metis on Chainstack Running Metis nodes is now frictionless with Chainstack Dedicated Node. Whether you’re building DAC tooling, smart contract infrastructure, or analytics dashboards, Chainstack offers: Dedicated, high-throughput Metis node infrastructure No per-method billing—consistent pricing for all requests Global, enterprise-ready deployment across top cloud regions Get started: Build better with Metis How to get started with Metis on Chainstack Spin up a node: Request your node via the Chainstack console or contact Sales. Connect with tools: Use Metis’s RPC endpoints, SDKs, and EVM-compatible libraries. Build and deploy: From DAC platforms to EVM-native DApps, Chainstack takes care of uptime and scale. See our pricing plans Bringing it all together With our support for Metis, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. If you’re building the next generation of decentralized companies, Chainstack Metis infrastructure is here to support you every step of the way. Start building with Metis today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Mind We’re excited to announce that Chainstack now supports the Mind network, a Web3 data layer designed to support privacy-preserving and decentralized mental health services. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Mind faster than ever—without worrying about costly infrastructure overhead. Why build on Mind? Mind Network is a privacy-centric chain combining decentralized data ownership with healthcare-grade security. Built for mental health, self-sovereign identity, and encrypted AI data applications, it offers: Zero-knowledge data privacy: Share without exposing user data on-chain. On-chain encrypted storage: HIPAA-grade compliance for healthcare use cases. EVM compatibility: Use Ethereum developer tooling with strong privacy primitives. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Mind on Chainstack Running Mind nodes is now privacy-first and AI-ready with Chainstack. Whether you’re building encrypted health DApps, secure messaging, or AI data vaults, Chainstack offers: Dedicated Mind RPC infrastructure with zero-knowledge support Fixed pricing—no per-call surprises or dynamic usage costs Global deployment for compliant, performant health-grade apps Get started: Build better with Mind How to get started with Mind on Chainstack Spin up a node: Request a node in to the Chainstack console or contact Sales for a Mind node. Connect with tools: Use Mind’s APIs, SDKs, and ZK-enabled libraries. Build and deploy: From mental health DApps to secure data oracles—build confidently on privacy-first infra. See our pricing plans Bringing it all together With our support for Mind, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting and meaningful use cases. If you’re building decentralized tools to protect mental health and user privacy, Chainstack Mind infrastructure is here to support you every step of the way. Start building with Mind today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Mint We’re excited to announce that Chainstack now supports Mint Blockchain, a high-performance Ethereum Layer 2 built on the OP Stack and focused on unlocking the next wave of NFT and AI innovation. With this integration, developers can now tap into secure, scalable, and EVM-compatible infrastructure to deploy DApps that push the boundaries of asset ownership and intelligence. Why build on Mint? Mint is a Layer 2 network developed by NFTScan Labs and MintCore. As part of the Optimism Superchain, it delivers low fees and fast finality while remaining fully Ethereum-compatible. Core benefits include: OP Stack architecture: Native Layer 2 scaling secured by Ethereum’s consensus. NFT-native infrastructure: Tools like Mint Studio, IP Layer, and NFT-AI Agent support dynamic digital asset experiences. AI + NFTs vision: Designed to connect users and AI agents through decentralized ownership of NFTs. Mint is the go-to L2 for anyone building at the intersection of collectibles, content, and AI. Build better with Mint on Chainstack Running Mint nodes is now seamless and creator-optimized with Chainstack. Whether you’re launching NFT DApps, AI-integrated assets, or media protocols, Chainstack offers: Dedicated Mint RPC infrastructure tailored for NFT and AI workflows Flat-rate billing—no mint-based usage surprises Cloud-agnostic deployment with low-latency endpoints globally Get started: Build better with Mint How to get started with Mint on Chainstack Spin up a node: Request via the Chainstack console or contact Sales for your Mint node. Connect with tools: Leverage standard Solidity frameworks or Mint-specific infrastructure SDKs. Build and deploy: From generative NFTs to tokenized agents—build freely, deploy securely. See our pricing plans Bringing it all together With support for Mint, Chainstack empowers builders to create the next wave of AI-native and NFT-rich applications on a fast, affordable L2 network. If you’re building the future of decentralized ownership and intelligent digital assets, Chainstack Mint infrastructure is here to support you every step of the way. Start building with Mint today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for multi-chain subgraph deployment ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. Subgraphs migrated to Ormi. See migration details Say hello to the newest addition to Chainstack’s suite – Dedicated Subgraphs. Thanks to this new service, you will soon be able to launch your very own subgraph to query blockchain data of all shapes and sizes. What is Dedicated Subgraphs? Imagine working on a cool DApp that needs to calculate the total volume of a token from on-chain data. As the blockchain is organized in a time-ordered structure, you will first need to aggregate the data by going through each block and fetching the appropriate values for all transactions. While it is possible to do this for 10, 100, or even 1,000 blocks, it is increasingly more difficult to scale block by block as the DApp grows and so does the data it requires. The fact that most blockchains have millions of blocks already doesn’t offer much condolence either, rather deeming such manual labor quite unnecessary. And this does not even consider the monumental effort it would take to tidy up and organize the data in a queryable format just so you can make it that much easier to handle. This is where Dedicated Subgraphs comes into play. It removes the complexity of extracting and processing data from archive nodes and delivers an intuitive experience for Web3 BUIDLers to filter and query with ease. Thanks to this, you can enjoy setting complex query criteria and picking the granular data you need to generate even more value with your project from a single seamless Chainstack interface. How does Dedicated Subgraphs work? With Dedicated Subgraphs you can index all successful hits to your query criteria and then store the results in a PostgreSQL database making it accessible via a subgraph endpoint. You can use the same endpoint to access both recent and historical data from a particular subgraph, which is synced to the latest block with near-zero latency. Deploying a subgraph from scratch is quite simple – no need to endure cumbersome workflows as all it takes is but a single CLI command to make it a reality. And the best thing about it? The same applies to existing subgraphs too! So, stop worrying about tedious maintenance and lengthy service interruptions, when you can be BUIDLing in the meantime instead. Plug’n’Play subgraph deployment Dedicated Subgraphs is a Plug’n’Play solution that offers a fast and reliable means of accessing Web3 data via a seamless interface for nodes. Say goodbye to stale data, and network disruptions. Chainstack’s robust infrastructure ensures near-zero latency syncs and high availability in just a few clicks. You won’t even have to pay for the archive nodes you are using for your subgraph calls! By using Dedicated Subgraphs, you can effectively eliminate major challenges and deal-breakers like maintaining node health, syncing, and network availability that are a given for any casual setup. Start BUIDLing with confidence by signing up here and just deploying the service directly from the Chainstack console. On top of that, you get to take advantage of Chainstack’s robust infrastructure to power all your indexing operations. This means you will have timely access to critical information and enterprise-grade support, without even lifting a finger – all of which are instrumental to the success of your project. Additionally, the Dedicated Subgraph service supports a wide range of protocols for you to perform queries on – Elastic Indexer beginning with Ethereum, Polygon and BNB Smart Chain and Dedicated Indexer with 13 chains, while offering a seamless migration from the hosted alternative. These chains are Fantom, Near, Aurora, Cronos, Gnosis, Harmony, Fuse, Polygon, Avalanche, Ethereum, BNB Smart Chain, Optimism, and Arbitrum.  Seamless hosted subgraph migration Thanks to the Plug’n’Play integration of Dedicated Subgraphs, you can migrate any hosted subgraph you are using currently in a seamless manner. This directly translates into swift satisfaction for any blockchain data query needs you will ever have, so you can focus on what you do best – BUIDLing awesome DApps. Don’t miss the opportunity to leverage on-chain data seamlessly into your use case and supercharge your Web3 project’s operation every step of the way. You can find detailed information on how to work with Dedicated Subgraphs in the documentation. Pricing Using Dedicated Subgraphs is just as affordable as it is user-friendly – our flexible and transparent plan commitments are a perfect fit for both your budget and your project needs. And the best thing about it? You won’t even need to stake a single token to deploy and access your subgraph. The same goes for subgraph hosting just as well. Instead of a fixed cost, you can enjoy an adaptable usage fee structure at the affordable rate of $0.1 per hour for a subgraph or $73 monthly. And, should you ever wish for more requests, you can always claim some extra for a mere $0.00025 per unit. You will be pleasantly surprised to learn you will have the means to deploy up to three subgraphs under the most affordable Growth plan. Opting for this plan will also grant you a pool of 50K requests. Should you prefer to go for a higher plan, for example, the Business one, these capabilities will be extended to ten subgraphs, including up to 350K requests. And if that isn’t enough why not take advantage of the Enterprise one? It removes the deployment limit for subgraphs and sports even more requests – up to 1M. Get an adequate cost estimate for your use case via the pricing list available here. Swifter data indexing for your Web3 project With this new addition to Chainstack’s services, we have made another vital step towards maximizing the value of our platform for Web3 developers worldwide. Thanks to Dedicated Subgraphs, you as a BUIDLer now have swifter and easier access to critical data that your Web3 project needs to operate effectively. They say data is the oil of the digital economy and the same goes for Web3 as well. By offering better means to access blockchain data with Dedicated Subgraphs, we are paving the way for developers to leverage essential information that is vital for creating seamless DApp experiences for everyone. Eugene Aseev, Founder and CTO of Chainstack Now that Chainstack’s robust infrastructure supports subgraph operations, Web3 developers like yourself can take full advantage of its powerful indexing features. Because of this, you will now be better able to leverage on-chain data to generate value, while BUIDLing the next generation of blockchain applications. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Polkadot We’re excited to announce that Chainstack now supports the Polkadot network, a top-tier, developer-centric multichain platform known for its interoperability, shared security, and parachain architecture. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Polkadot faster than ever—without worrying about costly infrastructure overhead. Why build on Polkadot? Polkadot is a layer 0 blockchain protocol designed to enable secure, scalable, and interoperable multi-chain applications. Built for DeFi, governance, and cross-chain services, it offers: Parachains for specialization: Run application-specific chains that scale independently. Interoperability through the relay chain: Connect and secure multiple blockchains in one network. Shared security: Parachains inherit Polkadot’s robust relay chain consensus, reducing attack risk. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Polkadot on Chainstack Running Polkadot nodes is now limitless with Chainstack Dedicated Node. Whether you’re building high-throughput DApps, scaling infrastructure, or running analytics, Chainstack offers: Dedicated, high-performance Polkadot node infrastructure No per-request billing—pay only for compute and storage Global deployment on the cloud and location of your choice Get started: Build better with Polkadot How to get started with Polkadot on Chainstack Getting up and running takes just a few minutes: Spin up a node: Request a Polkadot node from the Chainstack console or our Sales team. Connect with tools: Use Polkadot’s JSON-RPC, gRPC, or SDKs to integrate seamlessly. Build and deploy: From parachain tooling to DeFi protocols, focus on development—not infrastructure management. See our pricing plans Bringing it all together With our support for Polkadot, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re pushing the limits of DeFi, innovating in the NFT world, or building the next killer DApp, Chainstack Polkadot infrastructure is here to support you every step of the way. Start building with Polkadot today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Shibarium We’re excited to announce that Chainstack now supports the Shibarium network, a Layer 2 blockchain developed by the Shiba Inu community to enable low-cost, fast, and user-friendly Web3 applications. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Shibarium faster than ever—without worrying about costly infrastructure overhead. Why build on Shibarium? Shibarium is a community-built Layer 2 focused on reducing Ethereum gas fees and expanding the Shiba ecosystem. Built for microtransactions, NFTs, and meme-powered apps, it offers: Ultra-low fees: Ideal for small transactions and mass adoption use cases. Full Ethereum compatibility: Deploy with your existing Solidity-based tools. Vibrant community: Backed by one of the most active meme-based ecosystems in Web3. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with Shibarium on Chainstack Running Shibarium nodes is now low-cost and high-capacity with Chainstack. Whether you’re building microtransaction services or community DeFi, Chainstack offers: Dedicated, scalable Shibarium node infrastructure Zero per-request fees—just simple compute + storage pricing Cloud-agnostic deployment across multiple regions Get started: Build better with Shibarium How to get started with Shibarium on Chainstack Spin up a node: Request from the Chainstack console or Sales to deploy a Shibarium node. Connect with tools: Access RPC endpoints via standard EVM-compatible libraries. Build and deploy: From tipping systems to meme-fueled DApps, build at speed and scale. See our pricing plans Bringing it all together With our support for Shibarium, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building community-first products or creative blockchain experiments, Chainstack Shibarium infrastructure is here to support you every step of the way. Start building with Shibarium today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Soneium We’re excited to announce that Chainstack now supports the Soneium network, a public Layer 2 blockchain developed by Sony Group and built on the OP Stack to bridge Web2 and Web3. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Soneium faster than ever—without worrying about costly infrastructure overhead. Why build on Soneium? Soneium is a production-ready Ethereum Layer 2 optimistic rollup that aims to bring Web3 into everyday life by connecting Sony’s ecosystem—including gaming, entertainment, finance, and electronics—with decentralized technology. It offers: Built on OP Stack: Leverages Optimism’s Bedrock framework to ensure compatibility, scalability, and modularity. Part of the Superchain: Seamless interoperability with other OP Stack-based Layer 2 chains. Sony ecosystem access: Developed by Sony Block Solutions Labs, opening new doors for entertainment and digital IP. For developers, it means deploying real-world DApps that merge the scale of Web2 with the trustless backbone of Web3. Build better with Soneium on Chainstack Running Soneium nodes is now high-throughput and dev-friendly with Chainstack. Whether you’re building entertainment apps, payment rails, or IP-powered platforms, Chainstack offers: Dedicated, performance-optimized Soneium RPC infrastructure Flat-rate billing—no per-request spikes or congestion fees Cloud-agnostic deployment with full access to the Ethereum L1 bridge layer Get started: Build better with Soneium How to get started with Soneium on Chainstack Spin up a node: Request your Soneium node in the Chainstack console or from our Sales team. Connect with tools: Use EVM-compatible tools, OP Stack libraries, and Soneium’s RPC endpoints. Build and deploy: Whether it’s a Sony-integrated game, a payment app, or a new social experience—focus on building, not infra. See our pricing plans Bringing it all together With support for Soneium, Chainstack continues its mission to support high-impact, scalable Layer 2 ecosystems that make Web3 accessible to billions. If you’re building real-world use cases on top of Sony’s IP or the OP Superchain, Chainstack Soneium infrastructure is here to support you every step of the way. Start building with Soneium today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Sui We’re excited to announce that Chainstack now supports the Sui network, a high-performance Layer 1 blockchain developed by Mysten Labs. With this integration, developers can now build, test, and scale their Sui applications on battle-tested Chainstack infrastructure—purpose-built for performance and reliability. Why build on Sui? Sui is a next-gen Layer 1 designed to deliver lightning-fast performance and developer flexibility. Its object-centric design and Move-based smart contracts unlock new ways to build secure, responsive DApps at scale. Sui offers: Massive throughput: Capable of handling up to 297,000 transactions per second (TPS) under test conditions—making it one of the fastest blockchains to date. Low latency: Finality in ~400 milliseconds enables real-time user experiences. Parallel execution model: Sui’s object-based architecture allows transactions to run concurrently—dramatically improving efficiency. Move language for smart contracts: Offers secure, resource-aware programming with formal verification tools. Frictionless user onboarding: Features zkLogin for Web2-style logins and supports sponsored transactions to minimize wallet UX barriers. For developers, this means building DApps with better performance, security, and accessibility from day one. Build better with Sui on Chainstack Running Sui on Chainstack is the fastest way to go from prototype to production. Whether you’re building games, wallets, finance apps, or experimental protocols, Chainstack gives you: Dedicated, performance-optimized Sui RPC infrastructure Flat-rate pricing—no hidden request fees or usage spikes Full compatibility with Sui’s object-centric model and Move tooling Interoperability support for cross-chain integrations via Sui’s modular design Get started: Build better with Sui How to get started with Sui on Chainstack Spin up a node: Deploy your Sui node instantly through the Chainstack console. Connect your tools: Integrate with Move-compatible development frameworks and Sui-native libraries. Build and deploy: Focus on delivering user-facing value while we handle the infrastructure. See our pricing plans Bringing it all together With support for Sui, Chainstack strengthens its commitment to high-performance, developer-centric blockchain ecosystems. If you’re building next-gen Web3 apps on a scalable Layer 1 with parallel execution and advanced smart contracts, Chainstack’s Sui infrastructure is here to power your vision. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for WeMix We’re excited to announce that Chainstack now supports the WeMix network, a blockchain gaming platform focused on building the next era of play-to-earn economies, interoperable game assets, and metaverse ecosystems. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on WeMix faster than ever—without worrying about costly infrastructure overhead. Why build on WeMix? WeMix powers some of the largest blockchain games in Asia and beyond. Built for gaming studios, metaverse builders, and NFT projects, it offers: High TPS Layer 1 chain: Optimized for game logic and interactive DApps. Game token integration: Native tools for minting and managing in-game economies. Cross-game interoperability: Assets move freely across supported WeMix titles. For developers, it means scaling to millions of players with infrastructure built specifically for Web3 gaming. Build better with WeMix on Chainstack Running WeMix nodes is now game-ready and ultra-scalable with Chainstack. Whether you’re launching play-to-earn titles, NFT drops, or metaverse assets, Chainstack offers: Dedicated WeMix RPC infrastructure built for gaming throughput Flat-rate billing—no penalties for high-frequency game logic Global cloud deployment optimized for player latency and uptime Get started: Build better with WeMix How to get started with WeMix on Chainstack Spin up a node: Request your WeMix node via the Chainstack console or contact our Sales team. Connect with tools: Use WeMix’s APIs, SDKs, or EVM-based libraries. Build and deploy: From PvP game economies to NFT marketplaces—Chainstack powers scale and reliability. See our pricing plans Bringing it all together With our support for WeMix, we’re continuing our mission to empower scalable, immersive, and player-owned Web3 game ecosystems. If you’re building the next big title or redefining metaverse value, Chainstack WeMix infrastructure is here to support you every step of the way. Start building with WeMix today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for XLayer We’re excited to announce that Chainstack now supports the XLayer network, a Layer 2 blockchain designed for seamless cross-chain communication and asset transfers, enabling fluid interoperability across ecosystems. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on XLayer faster than ever—without worrying about costly infrastructure overhead. Why build on XLayer? XLayer is a high-performance L2 focused on interoperability. Built for bridging assets, cross-chain messaging, and real-time settlements, it offers: Cross-chain bridging framework: Built-in tooling to connect to multiple L1s and L2s. Fast and cheap transactions: Ideal for latency-sensitive use cases like trading or gaming. EVM compatibility: Write contracts using Solidity and integrate existing Ethereum tooling. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with XLayer on Chainstack Running XLayer nodes is now cross-chain and bridge-native with Chainstack. Whether you’re building token bridges, liquidity protocols, or composable cross-chain DApps, Chainstack offers: Dedicated XLayer RPC infrastructure with interoperability features Flat compute pricing—no bridge usage upcharges Worldwide deployment to minimize transfer lag and sync time Get started: Build better with XLayer How to get started with XLayer on Chainstack Spin up a node: Request your XLayer node using the Chainstack console or contact Sales. Connect with tools: Use XLayer SDKs and RPCs for cross-chain logic. Build and deploy: Whether you’re moving tokens or syncing data—just focus on code, not infrastructure. See our pricing plans Bringing it all together With our support for XLayer, we’re continuing our mission to enable scalable, reliable, and truly interoperable Web3 development. If you’re bridging the fragmented blockchain world, Chainstack XLayer infrastructure is here to support you every step of the way. Start building with XLayer today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for zkLink We’re excited to announce that Chainstack now supports the zkLink network, a zero-knowledge Layer 2 protocol built to power interoperable, cross-chain DApps with enhanced security and efficiency. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on zkLink faster than ever—without worrying about costly infrastructure overhead. Why build on zkLink? zkLink is a multi-chain zk-rollup that abstracts away chain-specific complexity. Built for asset bridges, DeFi aggregation, and multi-chain UX, it offers: ZK-rollup security: Inherits Ethereum’s security while enabling scalable operations. Cross-chain liquidity access: Bridge and compose assets from multiple chains. Unified interfaces: Users interact with DApps without switching chains. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards innovation and performance. Build better with zkLink on Chainstack Running zkLink nodes is now interoperable and efficient with Chainstack. Whether you’re building cross-chain DEXs, asset bridges, or zk-powered infrastructure, Chainstack offers: Dedicated zkLink node infrastructure with zero-knowledge support Flat-rate billing—no gas multipliers or usage limits Globally distributed deployment with enterprise-grade uptime Get started: Build better with zkLink How to get started with zkLink on Chainstack Spin up a node: Request via the Chainstack console or Sales to launch your zkLink node. Connect with tools: Use zkLink’s APIs and Ethereum-compatible SDKs. Build and deploy: Whether it’s a multi-chain aggregator or private zk app, stay focused on innovation—not infrastructure. See our pricing plans Bringing it all together With our support for zkLink, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most exciting networks in the space. Whether you’re building a cross-chain protocol or a next-gen privacy tool, Chainstack zkLink infrastructure is here to support you every step of the way. Start building with zkLink today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces support for Zora We’re excited to announce that Chainstack now supports the Zora network, a creator-focused protocol for minting, managing, and monetizing NFTs—built for artists, curators, and collectors in the decentralized era. With this integration, Web3 developers can now leverage battle-tested Chainstack infrastructure to deploy, test, and scale their applications on Zora faster than ever—without worrying about costly infrastructure overhead. Why build on Zora? Zora is a hyperstructure protocol optimized for on-chain media, creator royalties, and NFT experiences. Built for NFT marketplaces, creator platforms, and social minting, it offers: Zero platform fees: Artists and developers retain full value on minting and sales. On-chain royalties: Creator-first model built into the protocol. Permissionless tools: APIs and contracts anyone can use and fork. For developers, it means greater flexibility, faster time to market, and a growing ecosystem that rewards creativity and autonomy. Build better with Zora on Chainstack Running Zora nodes is now creator-native and royalty-locked with Chainstack. Whether you’re launching NFT marketplaces, minting engines, or social mint flows, Chainstack offers: Dedicated Zora node infrastructure optimized for media + metadata No request caps or method premiums—flat-rate RU pricing Global deployment support to serve collectors and creators anywhere Get started: Build better with Zora How to get started with Zora on Chainstack Spin up a node: Request a node via the Chainstack console or contact Sales for your Zora node. Connect with tools: Access minting contracts, RPCs, and Zora SDKs. Build and deploy: Whether for open editions or remixable NFTs, build without infrastructure delays. See our pricing plans Bringing it all together With our support for Zora, we’re continuing our mission to enable scalable, reliable, and fast Web3 development across the most creator-driven ecosystems. If you’re empowering artists, collectors, and curators, Chainstack Zora infrastructure is here to support you every step of the way. Start building with Zora today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces TON support We are thrilled to share that we have expanded our list of supported networks with TON. As pioneers in pushing the boundaries of decentralized technology, we understand that for Web3 developers like you, every tool and chain counts. Hence, we’ve tailored our product updates to help you build, deploy, and scale your DApps on TON more efficiently than ever. Built on our passion for innovation and extensive experience in Web3, this improvement is designed to provide robust and secure interactions with the TON Network. Let’s explore! We’ve been building Portfel on Chainstack, and the service level has really stood out. It’s clear the infrastructure is built for stability and performance.  Nodes are responsive and uptime’s been outstanding overall. Dmitry Kisel, CTO at Portfel How to interact with the TON Network on Chainstack? Navigating through the turbulent seas of blockchain networks might seem daunting. Numerous chains, each with its own nuances and technicalities, can make interaction and data management a burdensome task. That’s where we step in. Our phenomenal team at Chainstack has been working relentlessly to provide a smooth and secure API service for interacting with the TON blockchain. This impeccable service offers you easy and convenient access to various TON APIs. Find the details in our guide here. With Chainstack, we’re equipping you with a trusted companion that allows you to explore the depth of the TON Network, without worrying about going in too deep. What is the TON Center API v2? What does the TON Center API v2 bring to the table? It provides real-time access to the TON blockchain, enabling seamless interaction with the network. With a robust set of features, you can easily access account details, explore block and transaction information, run smart contract methods, and send data to the blockchain. Whether you’re retrieving wallet balances, packing/unpacking addresses, or estimating transaction fees, TON Center API v2 brings this wealth of blockchain data directly to your application in real time. It also offers JSON-RPC support for advanced interaction, making it an indispensable tool for developers looking to build reliable, high-performance applications. What is the TON Center Index API v3? Data is the lifeline for developing innovative and complex Web3 applications, and we understand it more than anyone else. The TON Center Index API v3 redefines how you access and analyze blockchain data by providing indexed access to information stored in a PostgreSQL database. This API offers instant access to detailed blockchain data, including transactions, NFT collections, and Jettons. Unlike v2, which provides real-time data directly from the blockchain, v3 is designed for more complex queries and historical analysis, allowing you to retrieve transaction details, analyze token movements, and explore detailed block and transaction relationships. Its specialized support for NFTs and Jettons enables developers to query collections, items, transfers, and burns with ease, while advanced transaction queries help you fetch adjacent transactions, transactions by message, and more. The streamlined, indexed approach of v3 ensures efficient and organized data retrieval, making it a powerful tool for building data-driven applications on the TON Network. TON Center API v2 vs v3 To help you decide which API is best suited for your project, here’s a comparison of TON Center API v2 and v3 based on their core functionalities and use cases: FeatureTON Center API v2TON Center Index API v3PurposeReal-time interaction with the TON blockchain.Indexed access to structured blockchain data for complex queries and analysis.Data sourceDirect data from the TON blockchain.Indexed data stored in a PostgreSQL database.FocusReal-time queries for account info, transactions, blocks, smart contracts.Advanced querying for historical data, NFTs, Jettons, and complex transaction queries.Use casesBest for immediate interaction, sending transactions, checking balances, running smart contract methods.Ideal for retrieving historical data, analyzing NFTs/Jettons, and performing advanced analytics.Smart contract interactionSupports running get methods and sending BOCs.Supports running get methods, sending messages, and estimating fees.NFT and Jetton supportLimited to general blockchain interactions.Full support for querying NFT collections, items, transfers, and Jetton-related data.TransactionsFetches real-time transaction details and block-specific transactions.Allows querying of transactions by block, message, adjacent transactions, etc.Special featuresJSON-RPC support for advanced blockchain operations.Extensive support for NFTs, Jettons, and historical transaction analytics.EfficiencyReal-time data access with straightforward queries.Indexed database allows for faster, more complex querying of historical data.Best forApplications requiring up-to-date blockchain state and real-time interactions.Data-heavy applications needing detailed, historical blockchain analysis. Summary: TON Center API v2 is perfect for real-time blockchain interaction, providing access to current accounts, transactions, blocks, and smart contract methods. TON Center Index API v3 is optimized for data-driven applications, offering an indexed view of blockchain data, ideal for historical analysis, NFTs, and Jettons. Each API serves a different set of use cases, making it easy to choose the one that fits your needs based on whether you prioritize real-time interaction or complex data analysis. Chainstack Global Nodes advantages in the TON ecosystem As a developer in the Web3 space, you understand the importance of scalability, flexibility, and efficiency. Hence, we’re thrilled to introduce Chainstack Global Nodes—The cornerstone of agile blockchain development in the TON ecosystem. Our Global Nodes are like flexible building blocks that you can scale and adjust according to your needs. Whether you’re experimenting with new concepts or ready to deploy a large-scale application, Global Nodes can effortlessly handle varying load pressures and expansion needs, keeping performance and efficiency paramount. Embracing Chainstack Global Nodes means saying ‘yes’ to enhanced transaction speeds, ‘yes’ to spiked productivity, and ‘yes’ to a redefined TON ecosystem interaction experience. How to run a Chainstack node on TON? Excited to dive into the world of the TON Network? We’re here to guide you every step of the way. Whether you’re aiming to run a Full Node or an Archive Node, our step-by-step guide will ensure seamless deployment. Bringing it all together As we make our mark in the progress of blockchain technology, we are proud to announce these enhancements that we hope will significantly aid our dedicated community of Web3 developers. The goal is simple: to simplify your developmental workflow, enhance scalability, and open up the world of TON Blockchain to your innovation. We are excited to see the phenomenal applications and projects you create with TON on Chainstack. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces TRON support We’re excited to announce that Chainstack now fully supports the TRON network, one of the fastest-growing and most widely adopted blockchain networks. With over 294M+ accounts, 10B+ transactions, and a robust ecosystem of DApps and DeFi protocols, TRON provides Web3 builders with an ultra-fast, scalable, and cost-efficient foundation. At Chainstack, we are committed to delivering high-performance blockchain infrastructure that enables developers to build and scale effortlessly. Now, with Global TRON RPC Nodes, you can seamlessly deploy, interact, and test on TRON for the win. Why build on TRON? TRON is designed to support large-scale Web3 applications, offering unmatched speed, cost efficiency, and developer flexibility. Key benefits for builders include: High throughput: TRON’s DPoS consensus mechanism enables significantly higher TPS compared to traditional proof-of-work chains. Instant finality: Near-instant transactions and block confirmations make it ideal for DeFi, gaming, and real-time applications. EVM compatibility: Effortlessly migrate and deploy Ethereum-based DApps using familiar development tools like TronBox, Tron-IDE, and TronWeb. Extensive DeFi and NFT ecosystem: Power decentralized finance applications with JustLend DAO, SunSwap, and JustStable, and explore NFT integrations with APENFT Marketplace. Cross-chain capabilities: Leverage BTTC (BitTorrent Chain) for seamless interoperability across multiple blockchain networks. Figure 1: TRON 2025 Roadmap; Source: TRON Build better with TRON on Chainstack Deploying and managing TRON nodes has never been easier. With enterprise-grade Chainstack infrastructure, you can spin up TRON RPC nodes in minutes and focus on building scalable, production-ready DApps. Chainstack ensures highly available, secure, and scalable TRON nodes, eliminating the complexities of node management so builders like you can focus on innovation. Our Global TRON RPC Nodes provide geo-distributed, high-performance access to TRON’s network, ensuring seamless, low-latency interactions for all your DApp needs. Key benefits High-performance throughput: No resource bottlenecks, ensuring smooth scaling as user activity grows. No daily request limits: Build freely with high-volume, unrestricted API access. Optimized latency: Global endpoints ensure optimal connectivity and minimal response times. Transparent, predictable pricing: Simple Request Unit (RU) pricing, minus unpredictable costs. How to deploy TRON nodes on Chainstack Launching your Web3 project on TRON is seamless with Chainstack. Here’s how: Deploy a TRON RPC node: Choose between Global or Dedicated TRON Mainnet RPC Nodes. Leverage TRON developer tools: Utilize JSON-RPC, gRPC, and Web3 libraries for fast and seamless integration. Build, launch, and scale: Tap into TRON’s DeFi, NFT, and Web3 gaming ecosystem to push the boundaries of innovation. Bringing it all together By integrating with TRON, Chainstack makes another step in empowering Web3 builders to deploy high-performance DApps with low fees, high throughput, and seamless cross-chain capabilities. Whether you’re developing DeFi protocols, NFT marketplaces, GameFi applications, or next-gen decentralized services, Chainstack Global TRON RPC Nodes provide the infrastructure you need to scale with confidence. Start building on TRON with Chainstack today. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Unichain support We’re thrilled to announce that Chainstack now supports Unichain, the new OP Stack–based Layer 2 from Uniswap Labs, designed to solve DeFi’s biggest scaling and UX challenges head-on. With this integration, developers can now deploy, scale, and optimize DeFi DApps on Unichain—backed by Chainstack’s high-performance, low-latency RPC infrastructure. Why build on Unichain? Unichain is a production-grade Layer 2 blockchain developed by Uniswap Labs and built on the OP Stack. It’s purpose-built to unlock the next evolution of DeFi by addressing core challenges around speed, cost, and fragmentation: Low cost, highly decentralized: Reduces transaction fees by ~95% compared to Ethereum L1 by moving execution to Layer 2—while preserving Ethereum’s decentralization model. Fast transactions, lower MEV loss: One-second block times at launch, with sub-250ms latency and TEE-enabled block building on the roadmap. Seamless cross-chain UX: Native interoperability via the Superchain and support for ERC-7683 enables simple, single-click swaps across L2s. Unichain also introduces innovations like a decentralized validation network (UVN), support for Uniswap v4 hooks, and open-source architecture aligned with Ethereum’s long-term roadmap. Build better with Unichain on Chainstack Running Unichain nodes is now fast, efficient, and MEV-aware with Chainstack. Whether you’re deploying DeFi protocols, Uniswap v4 hooks, or liquidity layers, Chainstack offers: Dedicated, high-throughput Unichain RPC infrastructure No method-based billing—predictable usage-based pricing Low-latency global endpoints for real-time trading and LP execution Get started: Build better with Unichain How to get started with Unichain on Chainstack Spin up a node: Request your Unichain node via the Chainstack console or contact Sales. Connect with tools: Use Uniswap SDKs, RPC endpoints, and OP Stack libraries. Build and deploy: From stablecoin flows to token launchers and LP incentives—go live fast and scale faster. See our pricing plans Bringing it all together With support for Unichain, Chainstack continues its mission to power real-time, decentralized finance at scale. Whether you’re building Uniswap v4 hooks, deploying novel DeFi primitives, or optimizing liquidity, Chainstack Unichain infrastructure is here to support you every step of the way. Start building with Unichain today Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces Unichain support We’re excited to announce that Chainstack now supports the Unichain network, a DeFi-native Layer 2 blockchain developed by Uniswap Labs and built on the OP Stack. With this integration, developers can now build, test, and scale high-performance DeFi applications on battle-tested Chainstack infrastructure—purpose-built for Unichain’s ultra-fast execution layer. Why build on Unichain? Unichain is designed from the ground up to be the next-generation platform for decentralized finance. As part of the Optimism Superchain, it delivers unmatched speed, fairness, and cross-chain liquidity. Key features include: 1-second block times: Built for speed with future upgrades targeting 200ms finality via Flashblocks technology. ~95% lower fees: Transactions cost a fraction of Ethereum Layer 1—perfect for high-frequency DeFi protocols. TEE-based block building: Built with Flashbots, Unichain uses Trusted Execution Environments to ensure verifiable, transparent transaction ordering. Validator-driven incentives: The Unichain Validation Network (UVN) allows validators to stake UNI and earn 65% of protocol revenue. Superchain interoperability: As part of the OP Superchain, Unichain supports seamless cross-rollup communication and liquidity. For developers, Unichain provides a programmable, high-throughput base layer built for the next evolution of DeFi. Build better with Unichain on Chainstack Running Unichain on Chainstack means rapid deployment and consistent performance—at any scale. Whether you’re launching a DEX, aggregator, lending platform, or arbitrage bot, Chainstack provides: Dedicated, performance-optimized Unichain RPC infrastructure Flat-rate pricing—no request-based billing or congestion fees Full compatibility with Unichain’s OP Stack, TEE tech, and Flashblocks sequencing Interoperability support through the Optimism Superchain ecosystem Get started: Build better with Unichain How to get started with Unichain on Chainstack Spin up a node: Deploy your Unichain node instantly via the Chainstack console. Connect your tools: Use standard EVM toolchains alongside Unichain-specific enhancements. Build and deploy: From high-frequency trading to gas-abstracted wallets—focus on shipping, not infrastructure. See our pricing plans Bringing it all together With support for Unichain, Chainstack expands its commitment to the future of programmable finance. If you’re building next-gen DeFi protocols that demand speed, fairness, and composability, Chainstack’s infrastructure for Unichain gives you the foundation to move fast and scale faster. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces World Chain Mainnet support We’re excited to announce that Chainstack now supports World Chain — an OP Stack Layer 2 rollup built to prioritize verified humans onchain. Starting today, you can deploy production-ready World Chain Mainnet nodes on Chainstack in under two minutes, with full debug and trace namespace support. Why build on World Chain? World Chain is an EVM-compatible Layer 2 rollup built on the OP Stack and part of the Optimism Superchain, designed from line one for applications that benefit from verified-human participation. Where general-purpose L2s optimize for throughput and treat every address the same, World Chain inverts the model — verified humans are first-class citizens, and the network’s economics reflect that. Priority for verified humans: Users who verify with World ID receive priority blockspace and partial gas subsidies, protecting the network from bot-dominated activity and giving real users a smoother onchain experience. Zero-knowledge proof-of-humanness: World ID uses zero-knowledge proofs so users can prove they’re unique humans without revealing their identity — a primitive that unlocks sybil-resistant airdrops, one-person-one-vote governance, and human-gated applications that weren’t possible before. Ethereum-secured through the Superchain: World Chain settles to Ethereum through the OP Stack, inheriting Ethereum’s security guarantees while giving developers L2 economics and shared interoperability with Optimism, Base, and every other Superchain member. Full EVM compatibility: Solidity contracts, ethers.js, viem, Foundry, Hardhat — everything you already use for Ethereum and Optimism works on World Chain without modification. Any OP Stack contract ports directly. Reach real users at scale: World Chain is home to World App, giving developers a distribution channel to over 15 million verified people across 160 countries — the largest verified-human user base onchain. For developers, World Chain Mainnet is the on-ramp to a chain where sybil resistance is a protocol-level primitive, not something you have to solve at the application layer. Build better with World Chain on Chainstack Running World Chain Mainnet on Chainstack gives you reliable access and predictable performance for any workload — from mini-app deployments and identity-gated applications to indexing, analytics, and consumer-facing dApps. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access to World Chain Mainnet Full and Archive nodes — recent state or full history from genesis, matched to your workload Full debug and trace namespaces on archive — debug_* and trace_* methods for transaction replay, call tracing, and smart-contract debugging Standard Ethereum JSON-RPC compatibility — HTTPS and WebSocket endpoints that work with any EVM toolchain you already have How to get started with World Chain on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select World Chain as your blockchain protocol Choose Mainnet and Global Node Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints Start building on World Chain → Bringing it all together With support for World Chain Mainnet, Chainstack extends its infrastructure coverage into the Optimism Superchain — and specifically into the emerging category of identity-native applications. Whether you’re building mini apps, sybil-resistant DeFi, identity-gated grants, or any product that touches World Chain, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces XRP Ledger support We’re excited to announce that Chainstack now supports XRP Ledger — a payments-focused Layer 1 with native JSON-RPC and WebSocket APIs. Starting today, you can deploy production-ready XRP Ledger nodes on Chainstack as Global, Dedicated, or Self-Hosted deployments, on both Mainnet and Testnet. Why build on XRP Ledger? XRP Ledger is one of the longest-running production blockchains in Web3, designed from line one for payments and cross-border settlement. Where general-purpose chains treat payments as one workload among many, XRP Ledger inverts the model — payments are the core primitive, and every other feature is built around low-latency, low-cost value transfer. Payments as the core primitive: 4-6 second consensus, sub-cent transaction cost, and native support for path-finding across order books and AMMs. XRP Ledger doesn’t compete for blockspace with NFTs, games, or general-purpose DeFi — it stays focused on value movement. Battle-tested since 2012: Over a decade of continuous production operation across billions of transactions, secured by 120+ validators from universities, exchanges, and businesses worldwide. Longevity is a feature. Built-in DEX and path-finding: XRPL ships a native decentralized exchange with automatic path-finding across order books — no smart contract or third-party liquidity venue required. Currency-to-currency payments route through the DEX transparently. Native, not EVM: XRP Ledger uses its own JSON-RPC and WebSocket API rather than the Ethereum eth_* interface. Methods like account_info, account_tx, submit, book_offers, and ledger are first-class citizens — the API surface matches how XRPL actually works, not how EVM chains work. For developers, XRP Ledger is the on-ramp to a chain where the payments infrastructure is the protocol, not an application built on top of it. Build better with XRP Ledger on Chainstack Running XRP Ledger on Chainstack gives you reliable access and predictable performance for any workload — from payment integrations and DEX applications to remittance flows and onchain analytics. Chainstack provides: Global Nodes — geo-balanced RPC endpoints for scalable, low-latency access to XRP Ledger Mainnet and Testnet Dedicated Nodes — isolated rippled infrastructure across all Chainstack locations for teams that need single-tenant nodes in a specific region Self-Hosted — run xrpld in full mode on your own infrastructure with Chainstack orchestration, monitoring, and one-click deployment Full XRPL method coverage — account_info, account_tx, tx, ledger, submit, book_offers, server_info, and the rest of the public XRPL API JSON-RPC over HTTPS and WebSocket — HTTPS endpoints for standard queries, WSS for real-time subscription and streaming (XRPL subscription methods are WebSocket-only) How to get started with XRP Ledger on Chainstack Log in to the Chainstack console (or create an account) Create a new project Select XRP Ledger as your blockchain protocol Choose Mainnet or Testnet, and pick Global for shared geo-balanced access, Dedicated for isolated resources, or Self-Hosted to deploy on your own infrastructure Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints Start building on XRP Ledger → Bringing it all together With support for XRP Ledger, Chainstack extends its infrastructure coverage into one of the most established production blockchains in Web3 — and the one most explicitly built for payments infrastructure. Whether you’re building payment rails, remittance flows, DEX integrations, or any product that touches XRPL, Chainstack provides the low-latency, production-grade RPC infrastructure to scale with confidence. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack introduces zkSync Era∎ support At Chainstack, we’re always looking for innovative solutions to enhance our platform and provide our users with the best tools to develop and manage their blockchain projects. We’re excited to introduce the latest addition to our ecosystem—the zkSync Era protocol. As a Layer 2 solution, zkSync Era opens up new possibilities for scalability and efficiency within the Ethereum network. This trustless protocol employs cryptographic validity proofs, performing most computations and data storage off-chain, offering users transaction security equivalent to Ethereum’s. What is zkSync Era? zkSync Era is a Layer 2 scaling solution built on Ethereum. It stands out as a trustless protocol that uses cryptographic validity proofs, also known as Zero-Knowledge (ZK) proofs, to offer scalable and cost-efficient transactions on the Ethereum network. This protocol conducts most computation and data storage off-chain, while still preserving the high security of the Ethereum network. This is achieved by submitting cryptographic proofs of all transactions on the Ethereum mainchain. Such a design significantly enhances Ethereum’s scalability while ensuring that the security is not compromised. In terms of functionality, zkSync Era closely resembles Ethereum but with considerably lower transaction fees. It supports Ethereum’s primary smart contract languages, Solidity and Vyper, and is compatible with existing Ethereum wallets and clients. As of now, zkSync Era is operated and run by the zkSync team’s servers, rendering it centralized. However, a transition to a decentralized system is planned soon. The operation cycle within zkSync Era is designed for efficiency and seamless interactions. It enables users to deposit, transfer, and extract assets with ease. An integral part of this process is the operator, who compiles the transactions, calculates a zero-knowledge proof for accurate state transition, and stimulates this state transition by collaborating with the rollup contract. This streamlined workflow forms the core operational foundation of zkSync Era. The main aim of zkSync Era is to tackle the most pressing issue of scalability on the Ethereum network without compromising on security. It presents a robust infrastructure for developers, making it possible to create scalable, secure, and cost-efficient large-scale applications. The protocol is also anticipated to introduce new features that will open up vast opportunities for experimentation with applications previously not feasible on Ethereum. Why zkSync Era? zkSync Era comes with a multitude of benefits that equip it to meet most applications on Ethereum. With more features scheduled for future releases, it is expected to provide developers with a vast design space to experiment with applications that were not feasible on Ethereum before. Among existing Layer 2 scaling solutions, zkSync Era stands out remarkably due to its enhanced security and usability. Thanks to advanced cryptography and on-chain data availability, ZK rollups, the core network of zkSync, are the only Layer 2 scaling solution that doesn’t require any operational activity to keep the funds safe. This means users can go offline and still be able to withdraw their assets safely when they return, even if the ZK rollup validators are no longer operational. zkSync Era brings to the table numerous benefits such as mainnet-like security without reliance on third parties, permissionless EVM-compatible smart contracts, a standard Web3 API, preservation of key EVM features such as smart contract composability, and the introduction of new features like account abstraction. Key features of zkSync Era include: zkStack: A modular, open-source framework designed to build custom ZK-powered L2s and L3s. Native support of ECDSA signatures: zkSync Era requires no special operation to register the user’s private key, allowing any account to be managed on Layer 2 (L2) using the same private key that’s used for Layer 1 (L1). Solidity 0.8.x support: Developers can deploy their existing codebase on zkSync Era with minimal changes. Web3 API compatibility: zkSync Era seamlessly integrates with existing indexers, explorers, and more due to its full compatibility with Ethereum’s Web3 API. Support for Ethereum cryptographic primitives: zkSync natively supports cryptographic operations like keccak256, sha256, and ecrecover. Enhanced security and usability: Thanks to advanced cryptography and on-chain data availability, zkSync Era provides a unique L2 scaling solution with superior security. Users can withdraw their assets safely even after being offline for a significant period. Mainnet-like security without reliance on third parties: zkSync Era offers the same level of security as the Ethereum mainnet without the need for third-party intermediaries. Permissionless EVM-compatible smart contracts: zkSync Era supports the development and deployment of permissionless smart contracts that are fully EVM-compatible. Preservation of EVM features: zkSync Era retains key EVM features like smart contract composability, providing developers with a familiar and efficient environment for building their applications. Introduction of new features: zkSync Era introduces innovative features like account abstraction, expanding the possibilities for developers to experiment with new application designs. One of the most significant future upgrades is zkPorter. This feature will give users a choice between a zkRollup account, which offers high security and a 20x fee reduction compared to Ethereum, or a zkPorter account with stable transaction fees of just a few cents and a different security model. Building on zkSync Era The advent of zkSync Era brings about a new paradigm of possibilities for developers aiming to create large-scale applications on the Ethereum network. This Layer 2 solution not only maintains the look and feel of Ethereum but does so with reduced fees, presenting a familiar environment for developers accustomed to building on Ethereum. zkSync Era supports the widely used smart contract languages, Solidity and Vyper, making it easy for developers to write and deploy smart contracts. It is compatible with existing Ethereum wallets and clients, eliminating the need to learn new tools or platforms. Developers can seamlessly transition their existing contracts onto the zkSync Era network, thanks to its EVM compatibility. This means any existing codebase can be deployed with minimal changes. Furthermore, zkSync Era offers a unique workflow that aids efficient operation execution. It includes user operations such as depositing, transferring, and withdrawing assets. It also introduces an operator role responsible for bundling transactions together, computing zero-knowledge proof of correct state transition, and interacting with the rollup contract to facilitate the state transition. Developers can build applications that allow users to execute off-chain transactions. These transactions are grouped into batches, each of which is verified through a zero-knowledge proof. This not only helps increase the transaction speed but also makes transactions more cost-effective by reducing gas fees. In summary, building on zkSync Era offers developers a familiar, efficient, and cost-effective environment to create scalable applications. The platform’s future upgrades, such as the introduction of zkPorter, present exciting opportunities for developers to experiment with applications beyond the current possibilities of Ethereum. Robust and scalable zkSync Era infrastructure with Chainstack The introduction of zkSync Era brings promising future enhancements that could revolutionize how developers build applications on Ethereum. With native support for ECDSA signatures, Solidity 0.8.x, and full compatibility with Ethereum’s Web3 API, developers can seamlessly integrate their existing codebase and tools into the zkSync Era ecosystem. Our partnership with zkSync Era signifies a landmark moment for Chainstack. As we incorporate their highly secure and efficient Layer 2 scaling solution, we are now more equipped than ever to provide our users with the tools they need for fast, cost-effective, and privacy-preserving DApp development. We look forward to supporting further innovation in the blockchain space that this integration will unlock. Eugene Aseev, Founder and CTO of Chainstack At Chainstack, we’re thrilled to announce alpha support for zkSync Era on our platform. As we strive to provide developers with robust and scalable infrastructure for their journey, we believe that zkSync Era will significantly enhance their ability to build and scale DApps of any size and stage. We look forward to seeing how our users will leverage this innovative protocol to drive the future of decentralized applications. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack joins Pocket Network as a trusted node provider to help build a more resilient Web3 We are thrilled to announce that from today we will be an active force in the growth of the Pocket Network community. We will do so by making blockchain infrastructure more accessible, and by providing ongoing support to any developer wanting to engage with the ecosystem.   What is Pocket Network? The mission of Pocket Network is to provide reliable, blockchain-agnostic, decentralized infrastructure to Web3 applications. Pocket coordinates requests through a decentralized relay network of diverse full-node operators in order to guarantee Web3 applications the censorship-resistance, resilience, and redundancy they need to be truly unstoppable. To fulfil this mission, Pocket Network created an incentive layer that completely changes how node operators are compensated for providing infrastructure services. When registering an application on the Pocket Network, developers will be able to connect and relay data to any blockchain currently supported by Pocket Network’s protocol. Reaping the benefits of a redundant-by-design, decentralized architecture, developers will benefit from a resilient infrastructure without single points of failure. Ensuring the creation of resilient and accessible Web3 applications As a trusted Pocket Network node provider, we will expand our existing support for the community. Since January we have been running 10 nodes as part of the Pocket Network Bootstrap Program, and we will now begin a wider campaign to make nodes available to the Pocket Network community: Starting today, it will be possible for anyone to become an independent Pocket Network node operator on our platform with preferential pricing, and without the need and cost of running the underlying full Ethereum node separately. We are further lowering the barrier to take part in the Pocket Network community by opening to the public low-code option to deploy Pocket nodes-as-a-service via our managed blockchain services’ Marketplace. Pocket Network significantly reduces centralization risk, decentralized application development costs, and lowers the barrier for developers to create peer-to-peer applications for any blockchain. Chainstack has been a wonderful trusted ecosystem participant in Pocket Network! They’ve been running nodes since the beginning of the year. Alongside the long-tail of individual node runners, having a diverse set of enterprise-grade node infrastructure providers, like Chainstack, not only ensures a high degree of resiliency but also establishes an industry-leading baseline quality of service for Web3 applications. We’re thoroughly excited that Chainstack will be extending its services to our community by offering cost-effective Ethereum full-nodes for those that want to become a Pocket node runner and lowering the barrier to entry for anyone to participate in Pocket Network with a low-code option. Michael O’Rourke, Co-Founder CEO of Pocket Network “We are a developer-first platform, rooted in precision engineering, radically simple, and built by a team of pioneers in the blockchain DevOps industry.” says Eugene Aseev, Co-Founder and CTO of Chainstack. “Becoming a trusted node provider of Pocket Network is a great step forward because it reinforces our commitment to the decentralized community to support the creation of a resilient and accessible Web3. Our platform remains the most developer-friendly out there, and we will keep adding new applications, services and developer tools to continuously improve the experience of innovating using Chainstack.” The addition of Pocket Network to our Marketplace will mark a new frontier in merging enterprise and Web3 deployment, offering a sophisticated and mature decentralized alternative. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack joins the Blockchain Game Alliance (BGA) Chainstack is now a Gold member of BGA, supporting the growth of blockchain-integrated gaming alongside Ubisoft, Polygon, AMD, Immutable, and others. Chainstack is the first managed blockchain services provider to join the Blockchain Game Alliance (BGA). At Chainstack, we aim to accelerate Web3 and blockchain adoption by staying on the industry’s bleeding edge and providing the backbone Web3 infrastructure to thousands of builders and innovators. Blockchain gaming, metaverse, NFTs, play-to-earn, and other blockchain gaming models are on a steep trajectory rise with almost infinite growth potential. The recent Messari report on blockchain gaming shows that the number of global gamers is growing and is currently at three billion, with the latest highest gaming interaction on blockchain peaking at one million users per day—less than half a percent of global gamers. At the same time, 72% of the current game developers are considering integrating blockchain technology into their projects, and with the VC funding growing 40x and led by the well-known firms like Sequoia, SoftBank, a16z, Paradigm, and many more. Chainstack is thrilled to support and provide blockchain infrastructure to the rapidly growing industry as a Gold member in the company of Ubisoft, Polygon, AMD, Immutable, Sushi, Binance, Unstoppabledomains, and many others. Current gaming projects on Chainstack In the four years of running blockchain infrastructure, Chainstack has become a trusted partner for protocols and projects, currently serving nodes to 10k+ projects, many of which are major GameFi: Netmarble, Workinman Interactive, Splinterlands, World of DeFish, LookLabs, and Gamerse. Chainstack solutions From idea to market, faster than ever before: Chainstack’s managed blockchain services platform made its mark across the Web3 space by creating an accessible way for developers and enterprises to launch and scale decentralized applications. Robust infrastructure with powerful features—Chainstack provides high-performance enterprise-grade node APIs that work for the developers with even the strictest requirements, regardless of their size and location. From protocol support to node customizations and load balancing, Chainstack offers a rich feature set, making it very easy for projects to scale—all complete with fully transparent and predictable pricing. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack launches complete Avalanche support accelerating performance and customizability We are thrilled to welcome Avalanche to our platform and to announce that Avalanche’s smart contract platform for digital assets and decentralized applications (DApps) is now fully supported. Avalanche builders can focus on creating a more connected and efficient future with Chainstack’s exceptionally stable and scalable infrastructure solutions. What is Avalanche? Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality. It is blazingly fast, low cost, and eco-friendly. It is compatible with the Ethereum smart contracts and tooling, enabling Ethereum users and developers to quickly access high-performance DApps. Since launching in September 2020, Avalanche is one of the fastest organically growing ecosystems in crypto. It now has over 350 projects building on the platform, including top-tier DeFi projects like Aave, Curve, BENQi, Sushi, and Chainlink, and enterprise applications for leaders in culture and sports with Topps and Andretti Autosport. Avalanche is seeing all-time highs in user activity, including transaction volume, unique addresses (now over 1.5M), and assets transferred from Ethereum to Avalanche over the Avalanche Bridge ($5.4B). The Avalanche network can achieve high throughput, estimated to reach over 4500 transactions per second. Transactions are finalized in under a second while being able to scale to unprecedented levels of decentralization consisting of tens of thousands of nodes, even upwards to a million nodes—all participating in consensus at the same time. Lightweight and sustainable, the protocol allows for high transactions per second (TPS) throughput while having low latency, and consumes extremely little energy, switching to a low-energy-consumption state when there is no activity. Building on Avalanche Avalanche is a platform of platforms, ultimately consisting of thousands of subnets to form a heterogeneous interoperable network of many blockchains that takes advantage of the revolutionary Avalanche consensus to provide a secure, globally distributed, interoperable, and trustless framework offering unprecedented decentralization. Avalanche allows anyone to create their own tailor-made application-specific blockchains, supporting multiple custom virtual machines such as the EVM, WASM, Bitcoin VM, Privacy VM, and more. This virtual machine can then be deployed on a custom blockchain network, called a subnet, which consists of a dynamic set of validators working together to achieve consensus on the state of a set of many blockchains where complex rulesets can be configured to meet regulatory compliance. The primary subnet consists of three blockchains currently, the X-Chain, P-Chain, and the C-Chain. The C-Chain uses the Ethereum Virtual Machine and is compatible with all key Ethereum tooling that has fueled decentralized finance’s (DeFi) growth to date, working seamlessly with Solidity and the widely used dev tools such as MetaMask, web3.js, Remix, Truffle Suite, Embark, and so on. The Avalanche and Ethereum interoperability allow assets to be exchanged across ecosystems and projects to extend their user base by expanding across various ecosystems. On Avalanche, transaction costs are rarely more than a few cents; even complex computations are executed consistently within the dollar range. Avalanche on Chainstack The Ava Labs team is extremely successful in forming new partnerships and bringing on new projects, allowing Avalanche network users to experience a more application-rich environment. High performance, security, and customizability—these features of Avalanche allow organizations, businesses, and individuals to develop decentralized applications that can be used in the real world across a wide range of industries. The addition of Avalanche to Chainstack is yet another step toward our goal of making Web3 universally accessible. This integration unites the two teams dedicated to providing innovative solutions to the community while also advancing accessibility and scalability. Chainstack allows developers to deploy and sync their nodes in minutes, with predictable pricing that is industry-leading, thanks to a high degree of automation and top-quality engineering. Developers and builders in Web3 and DeFi looking to run high-performing projects on Avalanche now have the option to overcome existing limitations and scale with the enterprise-grade infrastructure that can be relied on across multiple cloud networks and regions. In addition to the node management and operations, the Chainstack blockchain managed services include developer tools and services to make building and managing a DApp, a blockchain analytics platform, or a trading bot easier. How to use Avalanche on Chainstack Chainstack is a dependable and simple-to-use platform for quickly deploying nodes on a variety of hosting platforms, including fully managed public clouds like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), as well as on-premises. Companies can now deploy Avalanche nodes in the same easy and cost-effective way, without needing to invest the precious time and resources in setting up enterprise-grade infrastructure. Developers may entrust their projects to Chainstack and significantly shorten their time-to-market while also benefiting from the high-performing and dependable infrastructure. Pricing Thanks to its world-class engineering and lean infrastructure, Chainstack has a distinctive price advantage compared to other providers. This is reflected in the introductory pricing for Avalanche for shared full nodes at $0/month on Developer plan with 3M requests included. Subscription tiers are well planned out to be highly cost-efficient, supporting all projects and use cases in different stages and types. The Growth plan provides 8M requests and the Business plan provides 20M requests. Unlimited requests are available on all dedicated nodes deployed starting on the Business plan. For all requests beyond those included in the plan, the price for the first 20M extra requests is $0.1 per 10K requests; then $0.05 per 10K requests. See also the full pricing information and a handy calculator. Working together on making Web3 faster and better Avalanche is a powerful and innovative protocol that allows flexibility and performance by combining compatibility, fast transaction throughput, and long-term scalability that is sustainable in design. We’ve always admired Avalanche’s robustness in the blockchain space, creating connectivity and interoperability. Absolutely thrilled and proud to support Avalanche on Chainstack and to provide Avalanche node deployment to all developers and builders throughout Web 3.0 and DeFi. Eugene Aseev, Founder and CTO of Chainstack By employing blockchain technology that is developed for compatibility, performance, and scalability, Avalanche enables businesses to construct high-performing, ecologically friendly apps. Chainstack’s enterprise-grade, easy-to-use infrastructure, tools, and services let developers and project teams focus on creating breakthrough blockchain solutions and applications by reducing friction and streamlining operational processes. Both teams collaborate to accelerate blockchain adoption for a more connected and efficient future in which projects and end-users can benefit from the innovative power of decentralized applications while also enjoying higher performance and lower gas fees in the same enterprise-grade infrastructure that thousands of companies use every day. Have you already explored what you can achieve with Chainstack? Get started for free today. About Avalanche Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality, and has the most validators securing its activity of any proof-of-stake protocol. Avalanche is blazingly fast, low cost, and green. Any smart contract-enabled application can outperform its competition by deploying on Avalanche. Don’t believe it? Try Avalanche today. Website | Whitepapers | Twitter | Discord | GitHub | Documentation Forum | Telegram | Facebook | LinkedIn | Reddit | YouTube Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack launches support for Ethereum scaling solution Polygon What is Polygon? Polygon is a protocol and a framework for building and connecting Ethereum-compatible blockchain networks. Aggregating scalable solutions on Ethereum supporting a multi-chain Ethereum ecosystem, Polygon solves pain points associated with other blockchains without compromising on security, low transaction fees, and transaction speed.  In addition to technology innovation, Polygon has made building on Ethereum more accessible thanks to campaigns like the $100M #DeFiforAll fund to attract the next million DeFi participants. Introducing Polygon support on Chainstack We officially welcome Polygon to our platform and launch complete support for Polygon PoS mainnet and Mumbai testnet. This new offering will help developers build applications on reliable infrastructure engineered for scale in the easiest way possible on all the major public cloud providers (Amazon Web Services, Microsoft Azure, and Google Cloud Platform) and geographies. Developers will now be able to easily get access to Polygon APIs and deploy their own nodes in minutes, thereby reducing the costs associated with blockchain infrastructure and their time to market. Having gained wide adoption within the Web3 community, the Polygon ecosystem is growing fast. Chainstack is a highly accessible and secure platform that helps businesses incorporate layer two solutions, boosting Ethereum’s transaction capacity. Polygon’s community has now a trusted ally in Chainstack to help power up experimentation, adoption, and scalability.Eugene Aseev, Founder and CTO of Chainstack Why Polygon on Chainstack is the right choice? Chainstack makes running a blockchain node radically simple so that developers can focus on building their applications instead of worrying about node availability, costly maintenance, and upgrades. Chainstack as a reliable infrastructure provider is a major step forward for the Polygon ecosystem as it will allow blockchain projects to: Get instant access to reliable Polygon mainnet and Mumbai testnet infrastructure.Add advanced capabilities to any Polygon infrastructure with applications, developer tools, and services available on Chainstack Marketplace like Hardhat, The Graph, and IPFS.Start fast with shared Polygon nodes with multiple hosting locations, near-instant deployment, and secure HTTP and WebSocket endpoints.Access Polygon mainnet archive data starting at $49 per month.For request-intensive workload, deploy and sync dedicated Polygon nodes in minutes thanks to Chainstack-patented technology Bolt. The rapid adoption of Polygon has resulted in the need for strong infrastructure that can support the high-throughput on-chain transactions from 300+ DApps on Polygon. We are pleased to collaborate with Chainstack to make the blockchain experience seamless for users and developers.Sandeep Nailwal, Co-Founder and COO, Polygon Snapshot of Polygon growing ecosystem Having gained wide adoption within the Web3 community, the Polygon ecosystem is growing fast. Learn about the 300+ projects now on Polygon divided into a broad range of categories, with the help of these maps. Power boosting Polygon builders The addition of Polygon protocol in our ecosystem will mark a new frontier in Web3 deployment, offering enterprise-grade infrastructure support and flexible hosting options to one of the fastest Ethereum scaling solutions in the industry. To access a time-limited promotion and learn more about Polygon on Chainstack click here. Connect with the community Explore more about using Polygon on Chainstack here.To start building on Polygon, follow our ERC-20 bridging tutorial.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack partners with Digital Asset to widen go-to-market options for blockchain innovators Chainstack stopped supporting Hyperledger Fabric and Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. We are thrilled to announce the addition of DAML, an open-source smart contract language created by Digital Asset, to our multi-protocol partner ecosystem that spans a comprehensive range of consortium and distributed ledger technology (DLT) protocols, including Bitcoin, Corda, Ethereum, Hyperledger Fabric, MultiChain, and Quorum. The partnership helps enterprises and developers build and deploy DAML applications and networks across multiple projects with hybrid configurations quickly and cost-effectively, through the Chainstack platform. The first phase, starting today, will see DAML made available on Chainstack for Corda as an early access feature, with other protocols and platforms to be added over time, including Corda Enterprise and Hyperledger Fabric. Making blockchain deployment for enterprises and developers more accessible DAML is a state-of-the-art framework for building connected applications that span data silos and trust boundaries, changing how businesses collaborate across industries. It allows developers to focus entirely on the application logic without worrying about the underlying technology—blockchain, cloud, or database technologies. While systems integrators are typically used to facilitate the process, there are additional options for smaller sized enterprises and individual developers. The partnership between Chainstack and Digital Asset is designed to further democratize go-to-market strategies and options for all innovators, regardless of size and existing infrastructure. With Chainstack’s intuitive console and turnkey deployment feature, the integration of DAML on the Chainstack platform will allow enterprises and developers to embed blockchain applications and networks speedily with existing legacy systems. We are excited that Chainstack has integrated DAML into its offering. Developers can now build DAML applications on a very innovative and intuitive platform that supports multiple blockchain networks. Chainstack’s platform agnostic approach is a great fit for DAML-built applications that can be written once and deployed anywhere. Chris Clason, Director, Strategic Alliances at Digital Asset The DAML difference Traditional programming languages do not automatically isolate the business logic from the system code. Without a clean separation, developers interweave infrastructure code within their business application, resulting in fragile solutions that lack interoperability and portability. DAML provides everything you need to develop, test, and ship the ambitious applications you thought were years away. A radically simpler architecture allows your team to focus on business logic, not boilerplate, delivering more differentiated features to your customers faster. Rapid time to market: Describe the behavior of your application in an easy to read and write smart-contract language, and let DAML take care of infrastructure and integrations. Interoperability: Seamlessly interoperate and execute atomic transactions with other networks using DAML. Ledger portability: Never worry about platform lock-in again. DAML applications are completely portable without any changes on multiple persistence layers (blockchain or database). Automate businesses processes with rights, obligations, and fine-grained authorization built into the language, accelerating development of your organization’s single source of truth. Create new opportunities with a privacy by design framework. DAML ensures data is only visible to those who have a right to see the data including blinding transactions from the network operator for platforms that support this capability. Building a specialized ecosystem to make deployment simple The announcement is yet another step towards developing a robust ecosystem of partners that will add specialized best-in-class offerings to Chainstack’s advanced engineering platform. “Both Chainstack and Digital Asset are bringing together the most active communities of developers worldwide in the quest for close industry collaborations, innovation and democratization of technology,” said Eugene Aseev, CTO of Chainstack. “We are excited by the potential of this collaboration and share the common vision of simplifying blockchain deployments for faster business outcomes.” Would you like to find out more about using DAML on Chainstack? Visit the Chainstack Marketplace here. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack partners with Polygon Village providing Polygon infrastructure for developers We are happy to announce that Chainstack is now supporting Polygon’s DAO initiative called Polygon Village – a full stack ecosystem that aims to help developers along their Web3 journey by providing access to the best blockchain infrastructure to build and grow their future projects on Polygon. At Chainstack, it is our goal too to provide developers—and enterprises of all sorts with access to the most reliable and scalable blockchain infrastructure, so they can build their projects in much more convenient and simpler ways, effectively speeding up Web3 mass adoption. We are glad to have Chainstack supporting Polygon Village. To achieve a full-stack ecosystem that empowers our incredible Polygon community, developers, and projects to build and achieve sustainable growth, it is important to include access to dependable and scalable node infrastructure.Marco Grendel, DAO Lead, Polygon Seeing the dedication of the countless new developers coming to build on Polygon truly excites us, so we are certainly excited to be able to support this Polygon’s DAO initiative (Polygon Village). We believe every developer must be able to rely on robust and dependable blockchain infrastructure, so they are able to build the best tech and Chainstack will help developers who are part of Polygon Village do just that. Thanks to this partnership, all Polygon Village participants will be able to redeem a unique voucher to access Chainstack’s managed blockchain services for one entire month at the commitment-free special rate of $0 per month. It is always exciting to be able to assist developers in making their endeavors more successful. In our goal to create a better Web3 tomorrow, we are delighted to be supporting the DAO’s initiative and work with the Polygon Village to assure increased growth and scalability of next-generation Web3 builders and projects.Eugene Aseev, Founder and CTO of Chainstack. Free Polygon infrastructure for developers All grantees (Polygon Village developers) will enjoy the following major benefit: Access to the Chainstack Growth plan for 1 month at the special rate of $0 The Chainstack Growth plan unlocks up to 8M RPC requests to elastic full nodes without the need to deploy, run, or manage a node yourself, which is an extremely cost-efficient, time-saving solution everyone can use to future-proof and accelerate the growth of their projects. To benefit from all this, grantees will need to go through a few simple steps: Apply and submit a voucher application at Polygon Village.To redeem the voucher, you will receive instructions to:Follow us on TwitterJoin our community on TelegramJoin our Discord channelCreate an account on the Chainstack console What is the Polygon DAO Village? Polygon Village is a Polygon DAO initiative aiming to decentralize, grow, and innovate the Polygon community. The projects which are part of Polygon Village have access to several highly practical solutions, such as hosting, audit services, infrastructure & API-related services, talent discovery, and much more. Polygon Village provides all participants with welcome vouchers (e.g., Chainstack growth plan vouchers), shared grants, education sessions (Village Talks), a job board, and a bounty board. Read more here. What is Chainstack & how to use Polygon on Chainstack? Chainstack is a leading Node-as-a-Service provider that offers developers and enterprises of all shapes and sizes a single seamless way to launch and scale their Web3 projects. Backed by a bright team full of experts, Chainstack’s all-in-one, easy-to-use platform allows you to deploy, run, and manage an elastic full node without having to worry about any infrastructure work – enabling you to focus on building next-level tech for your projects instead. Use Polygon on Chainstack and get instant access to:   The most reliable Polygon mainnet and Mumbai testnet infrastructure.Elastic full Polygon nodes including personal, geographically diverse, and protected HTTP and WebSocket endpoints.Polygon mainnet archive data to query the entire history of Polygon mainnet.Chainstack’s patented Bolt technology to sync your nodes in 3 hours or less.Dedicated nodes to help you handle request-intensive workloads. Plus, you can integrate advanced capabilities to your Polygon infrastructure with the applications, developer tools, and services available on the Chainstack Marketplace. Learn more about Polygon on Chainstack here. Discover a wealth of information for Polygon on Chainstack  Explore more about using Polygon with  ChainstackLearn about deploying elastic or dedicated Polygon archive or full node on mainnet and testnetTo start building on Polygon, follow our ERC-20 bridging tutorialSign up for a  free Developer accountExplore the options offered by Growth or Business plans and look at our pricing tiers using a handy calculator to estimate usage and number of nodes.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack redefines RPC nodes at the ETHGlobal hackathon At Chainstack, we are on a mission to push the envelope of blockchain infrastructure with novel solutions. Our latest recent achievement in this regard, the Next-Gen RPC Node, has been turning heads in the industry and beyond. Born and honed at the esteemed ETHGlobal hackathon in Istanbul last month, this state-of-the-art technology has already earned an array of awards, including the Filecoin — Pool Prize, as well as the Filecoin and Arbitrum Sponsor Prizes. This is not just a technological marvel, but a proven reality that’s powering Chainstack Global Nodes. Our load-balanced Next-Gen RPC Node brings an unprecedented level of capability and performance to a myriad of EVM-compatible chains including Ethereum, Polygon, Scroll, Gnosis Chain, Mina, Arbitrum, zkSync, Filecoin EVM, NEAR’s Aurora EVM, Starknet, Mantle, Base, Neon EVM, and Aztec, among others. By bypassing the limitations set by public RPC nodes, we are handing Web3 developers an RPC endpoint that is not just omnipresent, but also optimally performing. Let’s explore the details. How you benefit as a Web3 developer One of the fundamental goals of our Next-Gen RPC Node project was to improve the availability of RPC endpoints. With our service’s ability to ensure that an endpoint is always accessible and optimally performing, downtime can be minimized if not downright eliminated. This uplift in availability combined with greater performance allows you as a developer to focus on building exceptional Web3 experiences without worrying about backend struggles. The Next-Gen RPC Node lets you customize your DApps more profoundly while maintaining a high level of security. Our solution incorporates the ability to add customized logic into the very architecture of the RPC Node, resulting in a highly flexible and powerful tool that improves UX. Ultimately, efficient transactions are at the heart of every successful blockchain project. Our Next-Gen RPC Node takes significant strides towards this efficiency. From aggregating and optimizing node selections to leveraging Cloudflare infrastructure, we have left no stone unturned in our quest to boost your project’s efficiency. https://stream.mux.com/c3EJu4bvbEzJX9zM94OLhtEBZ3UQNVlOW00VqC00iFnGI/high.mp4 Figure 1: Chainstack Next-Gen RPC Node project pitch video; Source: ETHGlobal The challenge: Conventional RPC nodes While RPC nodes play an integral role in the realm of blockchain technology, conventional RPC nodes present specific obstacles that impact overall performance and efficiency. And this hinders your work as a Web3 developer, unfortunately, preventing you from fully utilizing your potential. Without reliable and efficient infrastructure, it is no surprise you’d face setbacks in your projects. Latency and service interruptions lead to delays, lower operational performance, and ultimately a less user-friendly experience for your users. Without the ability to implement custom RPC logic, you’d have a hard time addressing challenges related to security, scaling, and customization too. Customizable logic in RPC endpoints allows you to fine-tune the function and performance of your applications. By pinpointing specific IP addresses or HTTP Referrer origin values, you can achieve an unmatched level of control over your DApp’s operations. In the current landscape, you are forced to use pre-defined logic, degrading your ability to deliver what truly caters the unique requirements of your project. Figure 2: Chainstack Next-Gen RPC Node project idea slide; Source: ETHGlobal The solution: Chainstack’s Next-Gen RPC Node The Next-Gen RPC Node is a comprehensive service that potentates the aggregation of multiple RPC endpoints hailing from various providers, geographical regions, and cloud services. Its primary purpose is to intelligently reroute to the optimal node by precisely verifying if a node is operational, accessible, and possesses the latest block height. Our service goes beyond merely providing a node. It delivers a foolproof strategy that leverages customizable logic to its potential by exhibiting a controlled selection of nodes based on their availability and performance. In other words, only the optimal nodes come into play. This strategy is accomplished by implementing precise access-list capabilities through the whitelisting of IP addresses or HTTP Referrer origin values and setting custom rate-limiting and throttling parameters. Figure 3: Chainstack Next-Gen RPC Node project solution slide; Source: ETHGlobal But how does this fare against traditional RPC nodes? Here are the top advantages: Higher availability: The Next-Gen RPC Node significantly improves upon traditional node services by ensuring high availability and access to the most up-to-date chain data. Up-to-date data: Developers can trust in the reliability of data with the Next-Gen RPC Node, which guarantees the latest information is always at hand. Congestion prevention: With intelligent resource allocation, the Next-Gen RPC Node prevents traffic bottlenecks, allowing for smoother RPC operations. Optimal scalability: The service elevates the scalability and reliability for web3 developers, making it a crucial component for applications on all EVM-compatible chains. Indispensable tool: The Next-Gen RPC Node is more than an upgrade; it’s a necessary tool that enhances user experience and expands the possibilities in web3 development. The Next-Gen RPC Node under the hood The soul of our service lies in the integration of Cloudflare Workers. Cloudflare Workers offer a lightweight, serverless execution environment that allows us to augment existing applications or create entirely new ones without configuring or maintaining infrastructure. Our project harnesses the power of Cloudflare’s KV Storage plugin and Caching API, both central to handling and storing the requests passing through our service. Find the source code in the project’s dedicated GitHub repo here. Figure 4: Chainstack Next-Gen RPC Node project architecture slide; Source: ETHGlobal While Cloudflare forms a key part of the infrastructure for our service, the role of our in-house RPC nodes embedded in the Chainstack can’t be overlooked. They handle the processing and redirection of requests, ensuring that every transaction that goes through our service is accurate, secure, and efficient. We’re continuously evolving this architecture, conducting rigorous tests, and updating our nodes to deliver unrivaled performance in the world of Web3 development. See the latest milestones here. Bringing it all together In conclusion, we’re proud of the transformative impact our Next-Gen RPC Node is already making for Web3 developers. From addressing the limitations of public RPC nodes to offering a high-performance, always-available endpoint, our Next-Gen RPC Node is set to be a pioneer for the industry. Its customizability and secure architecture not only enhance operational efficiency but also reduce development roadblocks for Web3 developers like you significantly. In the ever-evolving landscape of EVM-compatible chains, our robust service equips you with all the necessary tools for smoother, faster, and more efficient development processes. While we have come a long way in the journey of blockchain connectivity, the path to even more innovative solutions continues. At Chainstack, we stand committed to our mission to deliver Web3 infrastructure that pushes boundaries. Join us as we pave the way to a more connected and efficient on-chain world one block at a time. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack secures strategic investment to accelerate Web3 infrastructure development Chainstack, a frontrunner among the top three global Web3 infrastructure providers, has successfully secured a strategic investment from SBI Ven Capital, Sygnum, Azimut Group, Unicorn Factory Ventures, and Ventech Ventures. This investment will enable significant advancements in the company’s product offerings, particularly focusing on enhancing core product offerings, customer usability, and automation. In just two and a half years, Chainstack has transformed from a promising startup into a profitable global enterprise, marking its territory as a foundational player in the ever-evolving Web3 landscape. This journey has not only positioned Chainstack among the top three Web3 infrastructure providers but has also showcased its robust platform, unwavering commitment to quality, and the deep trust it has cultivated within the developer community. Chainstack’s offerings are extensive, encompassing integrations with over 25 public blockchains, four appchain frameworks, four consortium protocols, and partnerships with all major cloud providers. This diverse range of options serves more than 100,000 Web3 developers, ensuring they have the essential tools to innovate and scale their projects without constraints. This approach underscores Chainstack’s pivotal role in shaping the future of blockchain technology, enabling developers to push boundaries and create transformative applications. Geographically, Chainstack’s operations span 12 regions, aligning its infrastructure with the distribution of its user base. This strategic placement allows the company to efficiently handle over 100 billion requests each month while maintaining an impressive 99.99% uptime. Such reliability and performance optimization are critical for developers building DApps on the platform, ensuring seamless functionality and enhanced user experiences. Beyond infrastructure, Chainstack is deeply committed to enhancing customer usability and automating processes. The team continuously strives to set new industry standards for performance, reliability, cost-efficiency, and developer support. The securement of additional capital not only celebrates the company’s past achievements but also sets the stage for future innovations. This influx of resources is poised to catalyze revolutionary changes in how blockchain technologies are utilized globally, promising exciting developments in the Web3 domain. Chainstack is clearly on a path to not just participate in the future of blockchain but to significantly shape it. “Chainstack’s exceptional ability to simplify blockchain infrastructure for both Asia and the global market is setting new standards for the industry.” Kevin Low, SVP at SBI Ven Capital The investment will be strategically deployed to enhance Chainstack’s core product offerings and to bolster its position as a trusted, foundational blockchain infrastructure provider. This will center on refining and expanding the fundamental functionalities that have positioned Chainstack as a leader in blockchain infrastructure. Such focus aims to enhance and build upon the established foundations that make Chainstack a preferred choice for blockchain solutions. Other key areas of investment include: Customer usability: Making the platform even more user-friendly, based on direct feedback from users and the demands of the market. Automation: Increasing the automation of processes to streamline operations and improve efficiency across its services. These initiatives reflect Chainstack’s commitment to building a robust and user-friendly platform that not only meets but anticipates the needs of its users. “As a fund deeply rooted in Web3, we recognize Chainstack’s potential to revolutionize decentralized technology. Chainstack’s infrastructure solutions are poised to drive unprecedented growth and innovation for the industry.” Anton Vasilev, Managing Partner, Unicorn Factory Ventures. The current state of Web3 is a harbinger of fresh capital and growth opportunities. At Chainstack, the team is optimistic about this trend, recognizing its potential to catalyze their customers’ success and, in turn, their growth. And as they embark on this exciting new chapter, your invitation to join them on an exciting journey to redefine the digital asset infrastructure of tomorrow is already in your hands. “This investment marks a milestone in Chainstack’s journey, confirming our position as a sustainable Web3 infrastructure leader. Looking ahead, we’re invigorated to continue on our mission to simplify blockchain technology for builders all across the world, driven by customer feedback and our commitment to exceptional developer experience. Moreover, we anticipate a significant shift in the blockchain infrastructure market towards commoditization, which we believe will lead to better price performance and enhanced accessibility, greatly benefiting users and developers alike.” Jan-Jaap Jager, CEO, Chainstack In conclusion, Chainstack’s recent influx of strategic investments underscores a significant shift toward enhancing performance and reducing costs in Web3 infrastructure. The capital will be primarily directed towards refining Chainstack’s core functionalities, improving system efficiencies, and optimizing operational costs. This focus aims to meet the dual goals of sustaining high performance and progressively lowering prices. Such strategic initiatives are expected to not only benefit Chainstack’s extensive user base by delivering superior value but also strengthen Chainstack’s position as a leader in the blockchain infrastructure market. By driving these innovations, Chainstack is set to shape the future landscape of blockchain technology, ensuring that it remains both cutting-edge and accessible to developers across the globe. Learn more about Chainstack and how it simplifies blockchain for developers here. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack set to ensure easy access to XDC, the first digital currency built on the public Corda Network Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. From today, enterprises, financial institutions and innovators of any size can deploy Cordite XDC nodes using Chainstack’s turnkey blockchain managed services platform thanks to its partnership with the Cordite Society. Chainstack and Cordite Society are today announcing a partnership to make Cordite XDC nodes available to enterprises and innovators of any size through the Chainstack’s turnkey blockchain managed services platform. XDC is a revolutionary finance grade, enterprise-ready and regulatory friendly digital currency, the first one to be built on the Corda Network public blockchain. Today’s announcement quickly follows yesterday’s launch of XDC by the Cordite Society Ltd, a co-operative society registered in the UK which leverages the existing UK legal structures for mutual societies to operate a digital currency, providing the first onshore legal structure for decentralised finance (DeFi). Membership of the co-operative is open, and to join members simply need to operate an open source Cordite XDC node on the public Corda Network, which can now be done in a few easy steps using Chainstack’s turnkey platform. Unlike other cryptocurrencies, the money supply of XDC can be increased over time by democratic vote of the co-operative members. Members vote on minting proposals using their Cordite XDC node and any new money supply minted is evenly distributed amongst the voting members. This can now be done in an intuitive way on Chainstack. We are delighted that Chainstack are offering hosting services for XDC. Chainstack has made it simple, intuitive, seamless and cost-effective for members to run their XDC node. Richard Crook, Director of Cordite Society Limited XDC sets out to improve on the failures of early cryptocurrencies – fixed supply, inefficient media of exchange, high transaction fees, and virtually non-existent unit of account. Thanks to XDC, financial institutions can now build enterprise-grade DeFi platforms, such as decentralised exchanges or automated liquidity provision, like Uniswap. XDC case study also demonstrates Corda’s suitability for building CBDCs and stablecoins as banks look for solutions in light of shifting regulatory environment. While BCB Prime Services will provide OTC liquidity and custody services for XDC for their corporate and institutional clients, Chainstack will be the first blockchain managed service to enable low-code deployment of Cordite XDC nodes which are necessary for the voting on minting proposals of XDC tokens among other things. Chainstack’s mission is to create the most accessible and easy to use platform to build, run and scale blockchain applications in order to help accelerate the adoption of blockchain technology. The addition of Cordite XDC nodes to the Chainstack Marketplace, an ecosystem of application, services and developer tools, is yet another step to make the deployment and management of blockchain applications as easy as sending an email. This new partnership is testament to Chainstack’s commitment to remain at the cutting edge of blockchain engineering, both at infrastructure and application level, and to continue to remain a leading technical partner for enterprise innovation. We are thrilled to add Cordite Society to our partners, and we look forward to working together to make XDC as accessible as possible to blockchain innovators of any size. Eugene Aseev, CTO of Chainstack Connect with the community Just during CordaCon 2020, you can get 6 months Business plan for free by following these instructions. Don’t miss out on this exclusive promotion! TTo learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack to contribute to Polygon’s $150M #DeFiforAll Fund to help accelerate Web3 adoption We are officially joining hands today with the Polygon network to add our contribution to Polygon’s $150M #DeFiforAll Fund that was announced earlier this year. Our combined support is targeted at making DeFi more accessible and cost-effective, to bring the next million users to DeFi.  In our mission to make Web3 more accessible and efficient, Chainstack will provide free infrastructure to all the #DeFiforAll Fund’s grantees and grants alumni. Chainstack is determined to help developers build applications on reliable infrastructure built for scale in the easiest way possible.  We are glad to have Chainstack with us on our journey to make #DeFiforAll and support Polygon’s incredible community. Sustainable growth is what we want to promote with this grant program, and this must include reliable and cost-effective node infrastructure. Arjun Kalsy, VP of Growth at Polygon  This initiative with Polygon will help provide entrepreneurial developers who are just starting up on their journey to build a new Polygon project with access to robust and scalable infrastructure. We are excited to see the community and ecosystem thrive and will extend our support to all projects to become the next mightiest Web3 projects such as QuickSwap and The Graph.  Chainstack is on a mission to make Web3 for everyone and ensure the next generation of the Internet is inclusive and diverse. We are thrilled to support the #DeFiforAll Fund and collaborate with the Polygon team to achieve this.  Alex Albano, Chief Growth Officer at Chainstack What can you expect from us?   Grantees will receive the Chainstack Growth plan completely free for one month, unlocking up to 8M call requests to full shared nodes at absolutely no cost. Chainstack is committed to providing highly targeted advisory to ensure the most effective, reliable and cost-effective setup for each team, power-boosting their growth trajectory and accelerating their success.  In addition, our stellar team of best-in-class mentors at Chainstack will be providing strategic mentorship to all the teams part of the grant program to help them kickstart the journey in creating incredible projects and products, or to scale effectively their existing setup. The program we have created will be held on a monthly basis with infrastructure and DevOps clinics over 4 months.  What is the #DeFiforAll Fund?  Polygon’s #DeFiforAll Fund was set up with the objective of bringing the benefits of DeFi, farming and lending to a larger user base that was traditionally completely priced out of the revolution. Polygon have committed up to 2% MATIC total supply ($150M at the time of writing) for a long-term fund to continually grow and support DeFi over the next 2–3 years. As part of this program, Polygon have supported leading projects such as Aave and Curve with massive liquidity mining programs and hopes to support the best DeFi protocols from the DeFi fund and take their incredible products to the masses and Polygon’s incredible community.  Learn more about the #DeFiforAll Fund here. Making Polygon network even more accessible  Polygon is a Layer 2 scaling solution created to help bring mass adoption to the Ethereum platform. Aggregating scalable solutions on Ethereum supporting a multi-chain Ethereum ecosystem, Polygon solves the pain points associated with other blockchains without compromising on security, low transaction fees, and transaction speed. The well-structured, easy-to-use platform for Ethereum scaling and infrastructure development is managed by its core component, Polygon SDK, a modular, flexible framework that supports building and connecting Secured Chains like Plasma, Optimistic Rollups, zkRollups, Validium etc and Standalone Chains like Polygon POS, designed for flexibility and independence.  In addition to technology innovation, Polygon have made building on Ethereum more accessible thanks to campaigns that promoted widespread adoption and attract the next million DeFi participants. Learn more about Polygon here. Choosing Polygon on Chainstack  Chainstack makes running a blockchain node radically simple so that developers can focus on building their applications instead of worrying about node availability, costly maintenance, and upgrades.  Deploy Polygon on Chainstack and get:   Instant access to reliable Polygon mainnet and Mumbai testnet infrastructure.  Start fast with shared Polygon nodes with multiple hosting locations, near-instant deployment, and secure HTTP and WebSocket endpoints.  Access Polygon mainnet archive data starting at $49 per month.  For request-intensive workload, deploy and sync your dedicated Polygon nodes in minutes thanks to Bolt technology. Add advanced capabilities to your Polygon infrastructure with applications, developer tools, and services available on Chainstack Marketplace. Get started with Chainstack with amazing options  Polygon ecosystem have over 600+ projects on the network divided into a broad range of categories. Join the widely adopted and fast-growing Polygon network using Chainstack.  Ideal for starting with Polygon, get Growth plan subscription at $19/month for 8M calls to shared full nodes per month. Ideal for request-intensive use, get Business plan subscription at $49/month for 20M calls to shared full nodes and 3M calls to shared archive nodes per month. Get up to 400M calls to Polygon, BNB Smart Chain and Ethereum shared full nodes and 60M calls to shared archive nodes per month on our Enterprise Web3 Pro package at $990/month all inclusive. #DeFiforAll Fund grantee and grant alumni? Drop us a message here to access the free plan and register your interest for our mentorship program.  Learn more about Polygon on Chainstack click here. Discover a wealth of information for Polygon on Chainstack  Explore more about using Polygon on Chainstack here. Learn about deploying shared or dedicated Polygon archive or full node on mainnet and testnet here. To start building on Polygon, follow our ERC-20 bridging tutorial. Sign up for a  free Developer account. Explore the options offered by Growth or Business plans and look at our pricing tiers using a handy calculator to estimate usage and number of nodes.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack unveils Unstoppable RPC Endpoint at the ETHBelgrade hackathon In the rapidly evolving world of blockchain technology, hackathons have become the crucibles where innovative solutions are forged. These events draw together the brightest minds in the industry, each team daring to challenge the status quo and elevate the technological landscape. Among these events, the ETHBelgrade hackathon has distinguished itself as a prestigious platform where creativity, innovation, and technological prowess converge. This year, the event lived up to its reputation, with a remarkable array of teams from across the globe showcasing groundbreaking projects. Each project brought a unique perspective and a fresh approach to the table, attempting to address real-world problems using the transformative potential of blockchain technology. One of the highlights of this year’s event was a game-changing solution presented by Chainstack. Led by our Product Director Vasily Rudomanov, our team was honored to be among those contributing to the vibrant tapestry of innovation. Our entry, the Unstoppable RPC Endpoint project, aimed to simplify and enhance the Web3 development process. Tackling the problems faced by traditional RPC endpoints Traditional RPC endpoints, such as those offered by us at Chainstack, as well as Alchemy and Infura, are limited by their infrastructure, which leads to lower uptime, higher latency, and the lack of custom logic for an RPC endpoint. Problem Figure 1: Unstoppable RPC Endpoint problem definition; Source: ETHBelgrade hackathon slides We conceived the Unstoppable RPC Endpoint project to address these issues by aggregating multiple RPC endpoints from different providers, regions, and cloud services. Based on various factors like availability, block height, latency, and serving capacity, our service intelligently redirects requests to the most suitable node. Intelligent aggregation of multiple RPC endpoints Our Unstoppable RPC Endpoint solution stands out by intelligently aggregating multiple RPC endpoints from various providers, regions, and cloud services. By assessing different factors like availability, block height, latency, and serving capacity, our service can determine the most optimal node for a given request. This approach ensures that our users enjoy higher uptime, lower latency, and better overall performance. Idea Global Load Balancer for multiple RPC endpoints with blackjack and courtesans: Health checks Load checks Block height checks Latency checks And get: Instant failover Allow list (by IP or Origin) Caching Universal RPC for both full and archive data behind Optimal rerouting based on availability, latency, and serving capacity We understand that the availability, latency, and serving capacity of nodes play a crucial role in creating a seamless Web3 experience. That’s why our Unstoppable RPC Endpoint project has been designed to dynamically reroute requests to the most suitable node based on these factors. This ensures that we maximize the performance and reliability of RPC endpoints, making them truly unstoppable. Solution Leverage Cloudflare Workers’ serverless functions Run a middleware layer between an end-user and a set of RPC endpoints Detect what RPC endpoints are eligible to participate in load-balanced proxied traffic Provide a custom logic how to serve traffic Extend functionality for filtering by IP-addressed and HTTP Origin Cache requests to minimize latency and utilization of nodes even better Enhanced security and optimization features In addition to the innovative aggregation and rerouting mechanisms, we also prioritized advanced security and optimization features when developing our Unstoppable RPC Endpoint project. We’ve incorporated access-list capabilities to whitelist IP addresses or HTTP referrer origin values, custom rate-limiting and throttling parameters, and redirection mechanisms based on the type of data (full or archival). This focus on security and optimization raises the bar for the performance and robustness of RPC endpoints. Architecture Figure 2: Unstoppable RPC Endpoint architecture; Source: ETHBelgrade hackathon repo Commercial white-glove offering For those who seek a more premium, hands-off experience, we have crafted a commercial white-glove service based on our Unstoppable RPC Endpoint technology. This offering caters to users who prefer a tailored, fully managed solution without the need for in-house technical expertise. Impact on DApp projects and EVM-compatible chains Our primary motivation for creating the Unstoppable RPC Endpoint project was to simplify the life of Web3 developers by redesigning traditional RPC endpoints. By offering intelligent aggregation and rerouting to the most suitable nodes, we’re able to help developers focus on building innovative DApps without worrying about the complexities of managing and optimizing RPC endpoints. Why is it different? Figure 3: Unstoppable RPC Endpoint differentiation; Source: ETHBelgrade hackathon slides The Unstoppable RPC Endpoint project is poised to be a game-changer for DApp projects and EVM-compatible chains. Our focus on performance, security, and resource optimization has yielded an open-source tool that promises to uplift the Web3 user experience. We are confident that Unstoppable RPC Endpoint has the power to redefine the future of Web3 development, boosting the efficiency, reliability, and security of RPC interactions. With our steadfast commitment to innovation and refinement, we envision a more streamlined and effective environment for the flourishing of the Web3 community. Future plans Intelligent distributed caching, so the solution will share cached requests between all workers in each region Integration with block builders for private transactions implementation (avoid MEV/sandwich/snipping) Statistics for analytic firms to show end-users location and used methods Securing transactions by validating sender/receiver within databases of malicious actors Checking if API methods have proper structure, so no useless/nonsense transactions “We’re immensely proud to have been recognized at the ETHBelgrade hackathon for our Unstoppable RPC Endpoint project. Our primary motivation was to simplify the life of Web3 developers by redesigning traditional RPC endpoints. By offering intelligent aggregation and rerouting to the most suitable nodes, we’ve not only maximized performance but also enhanced security and optimization features.” Vasily Rudomanov, Product Director at Chainstack, shared. “This open-sourced tool is a gift to every DApp project and EVM-compatible chain, geared towards enriching the Web3 user experience. Additionally, for those seeking a premium, hands-off solution, we’ve created a commercial white-glove offering based on the same innovative technology. We’re excited to facilitate a smoother, more efficient future for the Web3 community,” he concluded. Team Vasily RudomanovProduct Director Nikita YugovEngineering Lead MOU LarionovInfrastructure Lead More about the Unstoppable RPC Endpoint Project page To learn more about the project, visit the hackathon page, where you’ll find detailed information on our innovative solution, the juries and the tokens staked in favor of our Unstoppable RPC Endpoint submission. Pitch video For a more visual perspective of the Unstoppable RPC Endpoint project, watch the pitch video, where our team passionately demonstrates the benefits and capabilities of our solution, as well as its impact on the future of Web3. GitHub repo Interested in taking a deep dive into the technical details of our project? Then dig into the GitHub repo and discover how you can start leveraging the magic of the Unstoppable RPC Endpoint to supercharge your Web3 project operations. ETHBelgrade hackathon media Bringing it all together As we look ahead, we’re confident that our Unstoppable RPC Endpoint will have a significant influence on the way Web3 is developed and experienced. By simplifying the development process and offering more robust, secure, and optimized RPC endpoints, our project is set to become an essential tool for developers working on DApp projects and EVM-compatible chains. The ETHBelgrade hackathon has once again showcased its ability to serve as a catalyst for blockchain innovation, bringing together some of the brightest minds in the field to create groundbreaking projects. We are honored to have made our mark with our Unstoppable RPC Endpoint, and we remain committed to driving innovation and developing state-of-the-art solutions that revolutionize the Web3 community. Project highlights Intelligent aggregation: Chainstack’s Unstoppable RPC Endpoint intelligently aggregates multiple RPC endpoints from different providers, regions, and cloud services, ensuring high availability and performance. Open-source accessibility: Reflecting our commitment to the Web3 community, we have made Unstoppable RPC Endpoint an open-source tool. This allows developers, DApp projects, and EVM-compatible chains to not only benefit from its advanced features but also contribute to its further development. Optimized Web3 development: By simplifying infrastructure-related concerns and offering custom logic options, this solution greatly enhances the Web3 development process, leading to improved user experiences. Advanced security features: Incorporating IP address whitelisting and HTTP referrer origin value checks, Chainstack’s solution prioritizes security and reduces potential points of failure. Resource utilization optimization: Unstoppable RPC Endpoint intelligently reroutes requests to the best-performing and least congested node, ensuring a more efficient and reliable RPC experience. Premium commercial offering: For users seeking a seamless, hands-off experience, we offer a commercial white-glove service based on our Unstoppable RPC Endpoint technology. This service provides a tailored, fully-managed solution without requiring in-house technical expertise. Enhanced blockchain ecosystem: This open-sourced project has the potential to significantly impact the way DApp projects and EVM-compatible chains are developed, promoting a more user-friendly and efficient Web3 community. Potential future impact: We believe Unstoppable RPC Endpoint could shape the future of Web3 development by improving the performance, reliability, and security of RPC interactions. We are committed to ongoing innovation and refinement to facilitate a smoother and more efficient landscape for the Web3 community. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack vs Infura vs Blockcypher vs Alethio – How do they fare? As the Ethereum ecosystem grows and the number of smart contract developers increases, a new business opportunity has appeared. Smart contracts are pieces of code that live on the blockchain. The deployment of a smart contract first involves a developer sending the smart contract to a node along with a small amount of gas, which will then include the smart contract into the mempool. As miners mine more blocks, smart contracts with a high enough gas included as a fee will eventually be included in a new block. Thus, a new smart contract is born on the blockchain. To interact with a smart contract, requests have to be made to a node, and a similar process of including the request in a mempool is done by the node. Thus, nodes represent a link between the outside world and the Ethereum Virtual Machine, and it’s no surprise that many enterprises have made progress into contributing and monetising this sector of blockchain deployment. Chainstack vs Infura vs BlockCypher vs Alethio, and now Cloudflare More and more companies are joining and offering Blockchain-as-a-Service (BaaS). The right BaaS allows small businesses and even enterprises to quickly deploy smart contracts, and then provide a highly resilient, low latency API that is not limited as more users interact with DApps. These businesses can be split into three types: Managed Node Provider (Chainstack) Ethereum Gateways (Infura, BlockCypher, Cloudflare) Ethereum Analytics (Alethio) Managed Node Providers & Ethereum Gateways are very similar. Both allow you to deploy smart contracts via a node or interface. Ethereum Analytics such as Alethio is mostly used to pull statistical data that is happening on the Ethereum blockchain; thus you cannot deploy or interact with smart contracts by connecting to the Alethio API. Function calls & latency We will test for a set of function calls to these Ethereum providers and then measure the latency.  The sender & contracts for these calls will be at the addresses below for the Ropsten testnet : contractAddress = '0xBbE54fADCCf0037d7ca7573a4238a4637ba26b98' senderAddress = '0xC836Fef5464cDFAec026111aF8E504FEaEC40dff' For all load tests, I will be using Artillery and run a test script. Every second, 50 users will be making a request to the API endpoints, for a total of 10 seconds. These requests will be made from my local machine. One of the capabilities of using Chainstack is that we can choose the location of our nodes. I’ve chosen my nodes to be located in Asia-Pacific (Singapore) which is where I’m located at. You’ll see the big difference in performance just by changing geographical locations in the next section. Get account balance Get transaction count Contract deployment The benefits of having nodes located nearby to your development team is crucial. Companies like Infura & BlockCypher do not allow developers to choose the location of their nodes resulting in high latency when making function calls to the Ethereum node. Chainstack allows developers to choose the location of their nodes, ensuring low latency during development. On top of that, Chainstack is cloud-agnostic, we currently provide support for Google Cloud Platform and Amazon Web Services with many more cloud solutions planned in our development pipeline. Namespaces Ethereum nodes represent the point of contact between developers and the blockchain. Ethereum has a JSON-RPC API that allows developers to interact with smart contracts that live on the blockchain. Let’s take a look at how we can deploy a simple contract, Hello.sol pragma solidity 0.5.0; contract Hello { constructor() public {} function getHello() external view returns(string memory){ return 'Hello World'; } } Let’s send this to an Ethereum node via the JSON-RPC API. We’ll have to create a params object with the contractBytecode in as the data parameter: params: [{ "from": "FROM_ADDRESS", "to": "TO_ADDRESS", "gas": "0x76c0", // 30400 "gasPrice": "0x9184e72a000", // 10000000000000 "value": "0x9184e72a", // 2441406250 "data": contractBytecode }] Let’s then make a request to our Ethereum node: curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' Alternatively, all this can be abstracted using Web3: const contract = await new web3.eth.Contract(abi) contract.deploy({ data:bytecode }).send({ from:account.address, gas:450000, gasPrice:100, }).then((result) => { console.log(result) }) If you try to use the code snippet above while using Infura and the Web3 provider, the transaction will be rejected by the node. This is because at the end of the day, Web3 is merely a JSON-RPC library, and it is dependent on the namespaces that are exposed by the node.  For example, .send() is actually wrapping around the “eth_sendTransaction” RPC method, which is not exposed by Infura as per the documentation. Instead, transactions have to be sent using “eth_sendRawTransaction”.  Web3 offers a valuable layer of abstraction in making things simpler, and Infura just removed it. API gateways The reason why Web3 does not work well with many of these BaaS is because a middle-layer API gateway, is implemented to prevent users from direct access to the Ethereum node. This API Gateway serves many purposes: Allows BaaS companies to track and monitor usage Expose only certain functions for safety Implement rate-limiting to prevent abuse Enterprise DApps cannot rely on many of these BaaS companies as the rate limits imposed will prevent future scalability. API gateways are also inconsistent. DApps built with Infura in mind will have to be modified before they can be used for BlockCypher.  By allowing direct access to an Ethereum node, Chainstack allows DApps to work as intended. Centralization Many Blockchain-as-a-Service platforms almost exclusively host on AWS. This represents a single point of failure should AWS decide to prevent the hosting of nodes on their servers. Chainstack is cloud-agnostic, ensuring that the decentralised Ethereum network is not reliant on centralised companies. We don’t run just on AWS as well. We’ve chosen a compromise between centralisation and convenience. Chainstack lets users choose from GCP as well, with future support for Microsoft Azure.  Shared vs dedicated nodes Technically, shared nodes are the same as dedicated nodes except that multiple developers are using this node at the same time.  Dedicated nodes offer higher performance compared to shared nodes because access to these nodes is held exclusively by you.  Shared nodes are sufficient if they are for hobbyist projects for the independent developer. Enterprise DApps, however, should not be using shared nodes because data can be intercepted and modified by other participants. It requires you to trust that the shared node is not being attacked by other participants. Chainstack offers both shared & dedicated nodes. We’re targeting all spectrums of DApp developers, ranging from hobbyists to enterprise users. This means that the shared node option has to exist as we recognise that a dedicated node is simply too excessive for the hobbyist.  Say hello to Chainstack Chainstack is a UI-driven platform, making node deployment an enjoyable and stress free experience.  Chainstack provides direct access to your own node, and this means that you’ll never get rate limited. Make as many calls via HTTPS/Websockets as you wish. Our nodes will always use the latest, most stable Ethereum client and we will handle all future upgrades, so you don’t have to. We also fully support Geth’s PUB/SUB allowing your applications to watch for events being fired on the blockchain. Bolt — our proprietary node spin-up technology allows our nodes to be created in just under 5 minutes from scratch. This makes it extremely trivial to deploy and delete nodes on the fly, making Chainstack the perfect solution to prototype & experiment on. Being cloud-agnostic also allows us to quickly deploy nodes in your location of choice, be it in Asia, America or Europe with GCP or AWS allowing redundancy for developers. We offer a free 7-day trial over at the console, so do give us a try! Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack vs QuickNode vs Alchemy: Which blockchain API is most cost-effective in 2026 Intro Choosing a blockchain API provider often comes down to pricing mechanics, request limits, and how usage scales under real workloads.In this comparison, we break down how Chainstack, QuickNode, and Alchemy price API usage across EVM and Solana, with a focus on request unit models, method-based multipliers, and cost predictability.By looking at common production workloads and real pricing structures, this article highlights where costs diverge and what developers should account for when selecting a blockchain API provider. How blockchain API pricing models affect costs Blockchain API providers calculate usage in distinct ways: Chainstack: Employs a 1:1 Request Unit (RU) model, ensuring costs align directly with usage, free of multipliers. QuickNode: Uses API Credits, with multipliers from 20x to 120x depending on the method. Alchemy: Relies on Compute Units (CUs), with multipliers between 10x and 60x. Helius: Applies its own request model, with multipliers ranging from 1x to 10x. A single request costing 1 RU on Chainstack could translate to 20–120 API Credits on QuickNode, 10–60 CUs on Alchemy, or 1–10 units on Helius, amplifying expenses significantly for demanding applications. EVM API cost: Method multiplier impact The table below outlines the method multipliers applied by Chainstack, QuickNode, and Alchemy for various EVM RPC methods—key factors that determine the true cost of API usage. Each multiplier reflects how many request units (or equivalent) a single call consumes, significantly influencing expenses for high-throughput applications. While Chainstack maintains a flat multiplier of 1 across all methods, QuickNode and Alchemy apply higher multipliers—ranging from 10 to 60—depending on the method’s complexity. This comparison sets the stage for understanding how these differences translate into real-world pricing. MethodChainstackQuickNodeAlchemyeth_call12026eth_getTransactionReceipt12020eth_getBalance12020eth_getLogs12060eth_blockNumber12010eth_getBlockByNumber12020eth_chainId120–eth_getTransactionCount12020eth_getTransactionByHash12020eth_getStorageAt12020eth_getFilterChanges12020eth_getBlockReceipts12020eth_getUncleByBlockNumberAndIndex12020eth_getCode12020eth_gasPrice12020eth_estimateGas12020eth_feeHistory12010eth_sendRawTransaction12040eth_maxPriorityFeePerGas12010eth_getBlockByHash12020net_version120–web3_clientVersion12020eth_syncing120–eth_accounts12010trace_block24020trace_transaction24040debug_traceTransaction24040debug_traceBlockByNumber24040debug_traceCall24040debug_traceBlockbyHash24040Figure 1: Chainstack vs QuickNode and Alchemy – EVM workload method multipliers To assess cost efficiency, we’ll look at a typical EVM workload—a balanced set of common RPC methods used in high-demand applications. This includes contract calls, transaction lookups, event indexing, and gas estimation, all essential for DeFi platforms, NFT marketplaces, and blockchain analytics tools. By comparing how Chainstack, QuickNode, and Alchemy manage this usage, we can observe how their pricing adjusts in real-world situations. This analysis reveals how method-based multipliers affect overall expenses and shows why Chainstack’s Pro plan provides the most consistent and budget-friendly option for EVM developers. Figure 2: Chainstack vs QuickNode and Alchemy – EVM workload price impact; Source: Chainstack Chainstack Pro is priced at $199/month for 80M request units, including an additional 25M units at no extra cost and no hidden multipliers. Additional usage is available at $12.5 per 1M RU. In comparison, QuickNode’s Scale plan costs $703/month, consisting of a $499 base fee plus $204 in usage charges. Alchemy’s PAYG model comes in at $666/month, with pricing determined entirely by usage. Solana API cost: Method multiplier impact The table below compares the method multipliers for Solana RPC methods across Chainstack, QuickNode, and Helius, revealing how each provider weights API calls in terms of resource usage. These multipliers—indicating the request units (or equivalent) per method—play a pivotal role in shaping costs, especially for applications with heavy demands. Chainstack keeps it simple with a uniform multiplier of 1, while QuickNode’s range spans 30 to 120, and Helius fluctuates between 1 and 10 based on method type. This sets up a clear lens for assessing their pricing in action. MethodChainstackQuickNodeHeliusgetProgramAccounts16010getTokenAccountsByOwner1301getSignatureStatuses1301getAccountInfo1301getBalance1301getTokenAccountBalance1301getStakeActivation1301getLatestBlockhash1301getFeeForMessage1301getConfirmedTransaction1301getSignaturesForAddress1301getInflationRate1301getVoteAccounts1301getEpochInfo1301getMultipleAccounts1301getBlock1301getTokenSupply11201logsSubscribe1301getBlockHeight1301getSlot1301getMinimumBalanceForRentExemption1301simulateTransaction1301getRecentBlockhash1301getTransaction1301sendTransaction1301Figure 3: Chainstack vs QuickNode and Helius – Solana workload method multipliers To gauge cost efficiency, we’ll explore a standard Solana workload—a realistic combination of frequent RPC methods key to high-performance applications. This encompasses account lookups, transaction status queries, and token ownership checks, all integral to DeFi platforms, NFT marketplaces, and blockchain analytics tools. By examining how Chainstack, QuickNode, and Helius process this demand, we can understand how their pricing plays out in practical settings. This comparison highlights the effect of method-based multipliers on overall expenses and illustrates why Chainstack’s Pro plan delivers the most dependable and economical solution for Solana developers. Figure 4: Chainstack vs QuickNode and Helius – Solana workload price impact; Source: Chainstack Our Pro plan costs $199/month for 80M request units, free of extra usage fees or concealed multipliers, with additional usage at $12.5 per 1M RU. Meanwhile, QuickNode’s Scale plan reaches $941/month, combining a $499 base fee with $442 in usage costs. Helius’s Growth plan totals $755/month, featuring a $49 subscription fee plus $706 in added usage charges. Further reading Introducing the new Pro plan: Power, Performance, Simplicity Nexo: 5X lower Debug & Trace costs Trust: 400% ROI with custom gateways CertiK: 70% lower Ethereum archive costs Bringing it all together When comparing blockchain API providers, cost efficiency is ultimately determined by how pricing behaves under real, sustained workloads—not by headline prices or advertised limits. Across both EVM and Solana, Chainstack consistently delivers the lowest and most predictable costs thanks to its flat 1:1 Request Unit pricing model. In contrast, QuickNode, Alchemy, and Helius rely on method-based multipliers that cause costs to scale disproportionately as request volume and workload complexity increase. Why Chainstack stands out in practice: No multipliers: A flat 1:1 RU model keeps costs directly aligned with actual request volume, unlike the variable and often high multipliers used by competitors. Lower total cost at scale: For production EVM and Solana workloads, Chainstack results in hundreds to thousands of dollars in monthly savings compared to QuickNode, Alchemy, and Helius. Predictable scaling: Additional usage at $12.5 per 1M RU enables straightforward capacity planning without unexpected cost spikes. Production-proven: trusted by DeFi protocols, stablecoin infrastructure providers, enterprise teams, and analytics platforms operating high-throughput workloads. For teams running production-grade Web3 applications where cost predictability and scalability matter, Chainstack is the most cost-effective blockchain API provider across both EVM and Solana ecosystems — start for free and spin up production-ready RPC endpoints with predictable pricing and no multipliers. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Chainstack welcomes Nils Hueneke as new CEO Chainstack has appointed Nils Hueneke as CEO, bringing in a leader with deep experience scaling infrastructure and cloud platform businesses. Across his career, he has consistently turned technically complex products into offerings that are operationally simple and commercially scalable. Nils spent over five years at WebPros as Chief Strategy Officer, and before that served as CEO of Plesk, leading the product through its carve-out as a standalone company. Earlier in his career, he held senior commercial roles at Parallels and SWsoft. Across each role, his focus stayed consistent: building infrastructure products that scale commercially without adding operational burden. “Over the past eight years, Chainstack has built and scaled global blockchain infrastructure across major networks, supporting developers and enterprises worldwide and I’m excited to take part in this next chapter together with the Chainstack team," - Nils Hueneke. Chainstack has spent the past eight years building global blockchain infrastructure across major networks, supporting developers, startups, and enterprises with reliable node access and production-grade operations. Customers increasingly expect blockchain services to be delivered with the same predictability, automation, and commercial structure as traditional cloud and hosting products. Under Nils’s leadership, Chainstack will sharpen how it brings infrastructure to market — with clearer commercial models, more structured onboarding, and faster paths from evaluation to production. Continued investment in Self-Hosted remains central to this strategy, giving infrastructure providers and enterprise teams direct control over deployment environments without the operational overhead that has historically made blockchain infrastructure complex to run at scale. #### Chainstack x HackenProof: Last Catch of Summer From August 25 to September 25, we’re joining HackenProof’s “Last Catch of Summer” bug bounty event! Test our stack, hunt for bugs, and earn rewards up to $2,000. The best way to find bugs is to let the people who love finding them take a shot. That’s why we’re joining HackenProof’s Summer Security: Last Catch Event, a month-long bug bounty open to anyone who wants to dig in and get rewarded for what they find. Security at Chainstack We build with security in mind from the ground up. On our side, that means: SOC 2 Type II and ISO 27001 certification, so our operations are independently audited and verified. Access Rules, to control exactly who can use your endpoints and how. 2FA and SSO for stronger account security. But even with all that, the best test is letting people test our stack. That’s why we’re opening it up in HackenProof’s Last Catch of Summer. About the Summer Security: Last Catch Event The Summer Security: Last Catch Event runs from Aug 25 – Sept 25, 2025 on HackenProof, the expert Web3 bug bounty and crowdsourced audit platform. Open to all security researchers, you can jump into bounty programs from multiple projects, including ours at Chainstack. Every valid report earns bounties, Pearl Bug Tokens, and the chance to win exclusive prizes in HackenProof’s holiday contest. We’re putting Chainstack’s Console, APIs, and infrastructure in scope with rewards up to $2,000. How to participate (step-by-step) Head to the event page Register, pick your target, and start hunting Every valid report earns bounties and Pearl Bug Tokens for exclusive prizes. Wrap-up Security improves when it’s tested from every angle. We build with it in mind, and programs like this help us keep improving. #### Chainy: Chainstack’s pivoting proxy solution Chainstack has built a strong reputation in RPC infrastructure, offering support for 25+ protocols, and a globally-distributed geo-load-balanced node network that is highly customizable. However, our commitment to providing flexible and sophisticated solutions continues to grow, adapting to the unique demands of each client. Here are some examples of tailored customer solutions: Custom request filtering based on headers, IPs, and smart contract addresses Budget control with spending limits for predictable costs High-speed transaction propagation with Warp Transactions Efficient JWT authorization with flexible rules In the heart of our technology at Chainstack, you’ll find Chainy. Developed internally as a custom solution, Chainy is a flexible network proxy. Goal: Smart contract address filtering A customer needed request filtering for specific smart contract addresses, typically using JSON-RPC over HTTP or WebSocket. This required work at the ingress controller level (Nginx), which lacks the flexibility for such tasks: HTTP requests: Filtering might seem simple—parse the body, find a smart contract address, and return an error if needed. However, handling batched JSON-RPC requests in a single HTTP payload requires parsing and filtering each request individually, which is complex and time-consuming. WebSocket traffic: WebSocket messages are seen as raw TCP traffic by Nginx, needing initial parsing to access JSON-RPC payloads. Filtering requests and sending error responses back through WebSocket adds further complexity. The ideal solution is to use Nginx as a simple entry point and delegate advanced functionality to a more specialized system. Going modular with Chainy plugins Each business requirement is broken into individual “plugins,” which are arranged sequentially in Chainy—hence the name. This design makes Chainy highly adaptable, as plugins can address specific needs while maintaining modularity. How Chainy simplifies our development work Chainy serves as a proxy between the ingress controller and the blockchain node. It enables custom plugins for various business requirements, with unique configurations for each blockchain node. Chainy abstracts complexities like HTTP, WebSocket, and JSON-RPC batching, allowing developers to focus purely on business logic without worrying about transport-layer intricacies. Observable usage results Chainy’s ability to analyze incoming traffic allows it to extract key metrics. These metrics power Grafana dashboards, providing insights like RPS, response time, response size, and RPC errors, segmented by method and node ID. Real-time monitoring is available for both HTTP and WebSocket. More details will be covered in a separate article. How Chainy supports Chainstack node operations Chainy has been deployed ahead of every Chainstack node, handling over 30,000 RPS. Its integration has enabled Chainstack to quickly implement new features, including: Request forwarding: A flexible all-in-one endpoint, currently forwarding heavy eth_getLogs requests to our internal Logs API. Warp Transactions: Routes requests through bloXroute for the fastest transaction propagation across the network. Rapid node Initialization: Enables instant creation of Chainstack Global Nodes, compared to minutes for regional nodes. Origin-based filtering: Protects client endpoints from unsolicited traffic. Fixed usage ceilings: Allows customers to set spending limits based on their plans, ensuring predictable costs. Conclusion Chainy has transformed Chainstack’s ability to deliver innovative and reliable features, solidifying our leadership in the industry. Its flexibility and extensibility have streamlined development, resulting in efficient, high-quality outcomes. As the backbone of our tech solutions, Chainy fosters continuous innovation and supports a productive work environment for our engineers. At Chainstack, we deeply value the skills and contributions of every team member, working together to maintain cutting-edge solutions and a culture of excellence. Power-boost your project on Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### ChartEx on Chainstack: Handling 1 billion requests per month with peace of mind ChartEx is leveraging the globally distributed Ethereum, Polygon and Binance Smart Chain node infrastructure on Chainstack as its trading data source. Having started with shared Ethereum nodes, ChartEx moved to Chainstack Enterprise plan running dedicated Ethereum, Polygon and Binance Smart Chain nodes. ChartEx provides technical analysis to over 26 thousand investors and analysts every day, responding to 865 million monthly requests across its platform, and attracting 370 thousand unique visitors each month. What does ChartEx do? ChartEx is a platform that provides tools, analytics, and full candlestick charting for Uniswap, the largest decentralized exchange running on the Ethereum network, and for any direct descendant of Uniswap like SushiSwap, SafeSwap, SwipeSwap, LinkSwap, and more. ChartEx allows end-users to use a familiar interface to interact with charts, customize them, annotate with indicators and drawing tools. ChartEx supports Ethereum, Binance Smart Chain and Avalanche networks with Polygon support launching soon. Traders and analysts enjoy full-fledged access to technical analysis indicators, drawing tools, and charts for market data. Thanks to ChartEx, traders can quickly filter trading pairs by the output of a number of popular trading indicators such as being oversold, near trendlines or support, crossing moving averages (MA) or prices breaking through Bollinger Bands, and more. How did ChartEx come across Chainstack? Looking for an infrastructure partner, the ChartEx team discovered Ethereum managed services on Chainstack in September 2020. In addition to affordable service costs, what caught ChartEx’s eye was the availability of Ethereum nodes in multiple geographical locations. Within the community of traders and data analysts, it is well known that this is a strong contributing factor to fast data retrieval and solution resilience. How does the Chainstack offer match the ChartEx needs? By offloading the maintenance of Ethereum, Polygon and Binance Smart Chain node infrastructure to Chainstack, ChartEx team was able to focus on product development and enhance service capabilities with additional features. ChartEx chose Chainstack so they could prioritize developing their core products and delivering value for their users. Today, ChartEx’s mean time to recovery (MTTR) is lower by 95% and their engineers are spending 100% of their time building the product. Chainstack nodes have been reliably handling more than 1 billion API requests, which advanced ChartEx’s growth. ChartEx started with shared Ethereum nodes, then moved to Chainstack Enterprise plan running dedicated Ethereum, Polygon and Binance Smart Chain nodes. Outcome 370 thousand unique monthly platform users 865 million monthly platform requests 95% lower mean time to recovery 1 billion monthly blockchain API requests ChartEx requires the use of the fastest blockchain nodes and to build on a robust infrastructure so that their system can function optimally and handle unlimited queries. Proven, rock-solid infrastructure means users get lightning-fast speed with zero downtime. ChartEx team used to spend many hours a month addressing issues related to infrastructure. Now, they can stay focused on building their products while Chainstack works behind the scenes, providing expertise, real-time support, and peace of mind. What does ChartEx like about Chainstack? With Chainstack as an infrastructure partner, the difference in performance was remarkable. Having a reliable source for blockchain queries saves time, money, and hustle. Our systems experienced 95% reduction in the mean time to recovery, which in turn allowed us to make availability commitments. The Chainstack support has been incredible, their team went beyond to help solve issues and enable additional functionality, resulting in improved ChartEx’s customer experience and adoption. ChartEx founder and CEO What does Chainstack like about ChartEx? ChartEx provides a robust product offering and addresses critical charting needs specific to the automatic market maker (AMM) DEX trading and the data analysis community who are critical to the growth of the Web3 ecosystem. ChartEx team has been a pioneer in trading analytics right from the beginning, working on the cutting edge by filling the gap in the market for tools and analytics that support traders on decentralized markets on Uniswap. ChartEx’s drive to continuously improve the offerings in order to better focus on customer requirements resonates with the core values of the team at Chainstack. This is recognized by the volume of requests generated daily and the exponential growth of the ChartEx community. What is the most interesting engineering challenge in working together? Due to the exponential growth of the Binance Smart Chain ecosystem, the network has experienced significant strain, putting the performance and capacity of the participating nodes to the test multiple times recently. As one of the most popular blockchains, Binance Smart Chain processes more than 220 transactions per second during peak times. ChartEx and Chainstack’s engineering teams worked closely together to achieve production-grade reliability and ensure Chainstack consistently outperformed other node providers in the market. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cloud hosting blockchain nodes: Why Chainstack is your ultimate choice for Web3 infrastructure Innovation doesn’t wait. Neither should you. In the rapidly evolving world of Web3 development, staying ahead means choosing partners who won’t slow you down. That’s where Chainstack comes in. With us, not only do you get the most innovative blockchain hosting solutions, but also a partner dedicated to your success. Powerful and intuitive hosting services not only streamline operations but also drive the performance and potential of Web3 applications. As a leader in the provision of advanced blockchain technology, Chainstack is uniquely positioned to cater to these needs. At Chainstack, we understand the intricacies of Web3 development. The complexities revolving around speed, security, scalability, sovereignty, latency, and more shape the ecosystem in which developers operate. Recognizing these challenges, we have designed our blockchain hosting services with an emphasis on customization, flexibility, and ease of use. What is Chainstack Node-as-a-Service? At the core of our offerings is powerful Node-as-a-Service model that provides full-featured, convenient, and scalable solutions to meet your unique Web3 development needs. It represents a robust set of building blocks that can shape the trajectory of your projects, driving growth in both scope and business impact. With Chainstack, you gain instant access to a realm where blockchain node hosting becomes an effortless and intuitive task. Our aim is to give you the right tools and the freedom to focus more on the developmental side of your projects, while we deal with the heavy lifting of node management and efficient running. Our range of cloud hosting options for nodes, from Chainstack-managed and Hybrid to Chainstack Cloud and Self-hosted and Bring your own Cloud solutions, offer a diverse palette to fit your Web3 project’s needs and preferences. We forge ahead with the implication of the hosting capabilities of our robust Node-as-a-Service, designed to meet every aspect of your blockchain developer journey. Plug and Play nodes with Chainstack-managed hosting Get a taste of a fully-managed blockchain service with our Chainstack-managed hosting. Designed for those who seek a ready-to-deploy solution, this service brings you an impressive orchestration of features without the need for self-management. Whether you’re a small-scale developer or an expansive enterprise, our intuitive user interface makes the process ten times easier. Access new features as soon as they’re out, while staying worry-free about platform performance and uptime. We also offer white-label branding on our enterprise tier for those looking for a more personalized touch. Supported cloud providers and locations We understand that the location of your nodes significantly impacts your application’s functionality. That’s why we’ve partnered up with leading cloud providers like Amazon Web Services, Microsoft Azure, Google Cloud Platform, and Virtuozzo. Simultaneously, we offer quite a range of location options, including US, UK, Singapore, Japan, Germany, and the Netherlands to name a few. If you still can’t find the location you need, reach out to us, and we’ll be more than happy to accommodate you. Figure 1: Chainstack-managed hosting supported cloud providers and locations; Source: Chainstack Hybrid hosting: A perfect blend of control and convenience Our Hybrid Hosting is another powerful offering targeting developers prioritizing self-sovereignty of nodes, keys, and infrastructure. With the perfect balance of our managed services and your control over some components, developers gain the freedom to operate certain parts of the infrastructure as their project or regulatory compliance may require. This option allows you to select which parts of the Chainstack infrastructure you wish to manage yourself. On the other end, we’ll take care of the implementation, ensuring that you focus on what truly matters most—creating value with your project. A perfect blend of control and convenience. It’s a great fit for developers who are keen on self-sovereignty of nodes, keys, and infrastructure but don’t want to roll their own orchestration. A typical such use case scenario is when a software provider uses Chainstack through the platform’s UI or API as a management dashboard to oversee nodes, networks, and services operating seamlessly within their own bespoke infrastructure. Chainstack-managed vs. Hybrid hosting How you plan to use blockchain technology for your project impacts the hosting choice you make. While both Chainstack-managed and Hybrid hosting options provide excellent capabilities, it’s important to understand the most suitable circumstances for each. In Chainstack-managed hosting, you enjoy complete node monitoring including node availability and health, full logging, access to daily automated backups, and more. All these are aimed to provide an effortless experience. On the contrary, Hybrid hosting focuses on giving you more control with partial node monitoring and availability to use your backup solution, billing only for the subscription and node management fee, and allowing flexibility to use your cloud infrastructure. If your focus is ease of operation, low operational costs, and near-instant node availability, Chainstack-managed hosting is the go-to choice. On the other hand, Hybrid hosting is suitable when the blockchain needs to run in your cloud—a requirement often driven by compliance-related concerns or to reduce DApp latency by collocating the DApp and node on the same server. Here’s a comprehensive overview comparing the Chainstack-managed and Hybrid hosting options: Figure 2: Chainstack-managed and Hybrid hosting options comparison; Source: Chainstack Chainstack Cloud for maximum node performance When it comes to resource-heavy operations in the world of Web3, performance is an absolute must. Enter: Chainstack Cloud. Tailored to process a substantial number of queries effortlessly and providing settings for minimal latency, handling demanding operations has never looked so elegant. Chainstack Cloud service brings powerful infrastructure suited for heavy compute loads and flexible node deployment, guaranteeing exceptional performance. It caters perfectly to the increasingly demanding use cases in the realms of DeFi, GameFi, and NFT applications. Whether it’s about maintaining high security, achieving optimal performance, flexible locations, or ensuring top-notch reliability, Chainstack Cloud delivers on every front. From Amsterdam to Ashburn, we’ve got numerous data centers providing flexible and efficient node deployment. With our state-of-the-art Chainstack Cloud, your entire Web3 operation can benefit from physical isolation for maximum security and dedicated hardware that ensures consistent disk I/O performance. And thanks to our patented Bolt technology, deploying and syncing nodes is hardly ever a matter of days but rather a few brief moments, allowing you to start building immediately. Deploy Chainstack Global Nodes to deal with demanding applications Efficiency should know no bounds and with Chainstack Cloud hosting our award-winning Global Nodes, this is a given. Delivering exceptional performance across the world, they ensure your requests are handled in the shortest possible time frame by the closest most fitting node available. This creates an effective and globally-distributed fallback chain, manifesting our commitment to 99.9% uptime. Enjoy outstanding performance and minimal latency, irrespective of geographical location. Our robust Global infrastructure is perfectly suited for enterprise-grade results, when (and where) you need it the most, even on shared hosting. FIgure 3: Unstoppable RPC Endpoint architecture; Source: Chainstack Go Self-hosted and assume direct control Fully controlling your Web3 infrastructure components can give you a unique sense of sovereignty—something our self-hosted Chainstack solution provides. This is most beneficial for developers interested in fully hosted solutions with in-house management capabilities. We pack all components for hosted installation, allowing you to leverage your infrastructure and integrate existing functions like billing, creating a seamless experience. This option is particularly beneficial to service providers aiming to provide managed blockchain services to their clientele. Bring your own Cloud Focusing on delivering maximum flexibility and customization, Chainstack offers a Bring your own Cloud option. Opting for this alternative lets you have the freedom to host your Web3 projects even outside our typical clouds and regions. This means that whether you are already working with a cloud solution or have special hosting requirements, we’ve got you covered. Choose from over 20+ regions available on Amazon EKS via private hosting. Can’t find the cloud or region you prefer? Let us know and we’ll handle the details. Enjoy the freedom to BUIDL on 25+ supported chains Chainstack is a one-stop platform for all your blockchain projects, offering you a wide variety of protocols for you to deploy your nodes on. By using Chainstack, you don’t have to be locked into a single protocol for your project. You can easily transit between Ethereum, Avalanche, Solana, Scroll, Ronin, or 20+ other leading chains supported on our platform. Deploying a node to a public network or creating a consortia can be done with just a few clicks. Now isn’t that handy? Employing multiple protocols expands the breadth of your blockchain projects, offering you the flexibility to adopt the advantages that each unique protocol presents. The more resources and tools you have at your disposal, the less limitations there will be on innovating and building forward. Figure 4: Chainstack supported chains; Source: Chainstack Simple, reliable, and convenient Web3 development At Chainstack, we understand the intricate complexities of blockchain development. Our mission is to simplify this process, empowering you to focus on creating exceptional Web3 experiences, while we take care of the heavy lifting. We make sure you gain unprecedented access to an intuitive user interface, outstanding performance, and consistent uptime, without the need to shoulder the burden of managing nodes yourself. We believe that reliability shouldn’t be a plus—it should be a given. Our commitment to delivering a 99.9% uptime ensures your vital applications continue to deliver value to your users without missing a beat. We achieve this using an innovative geo-load-balanced architecture that effortlessly adapts to changing network health without disrupting service. Built by individuals who understand the hustle of blockchain, the Chainstack team acknowledges the challenges you and other Web3 developers face and aims to not just mitigate them, but also facilitate convenience, agility, and flexibility. Open new opportunities, diversify your creations, and watch as every change propels you further in the Web3 sphere with Chainstack. Bringing it all together Every Web3 developer desires a set of reliable tools to navigate the complexities that come with building blockchain projects. Chainstack’s robust blockchain hosting solutions are designed to meet this aspiration of yours, providing flexibility, control, and most importantly, simplicity. By providing a comprehensive range of Web3 infrastructure services from Chainstack-managed to Hybrid and Chainstack Cloud to Self-hosted, we offer options fit for any and all projects, regardless of their size, stage, use case, or requirements, without compromising on speed, performance, and security. This much choice and control paves your way to limitless potential in Web3 development. Moreover, our commitment to continuous innovation is the driving force, ensuring our offerings remain the preferred choice for you as a Web3 developer, navigating the decentralized landscape. With Chainstack, you’re not just leveraging advanced technology; you’re tapping into a community committed to your success. The future of the web is decentralization—it’s fast, robust, and always getting better. And with our unparalleled blockchain hosting services, we’re proud to play a crucial role in supporting Web3 developers like yourself, who are making this future a reality. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cloud vs self-hosted blockchain nodes: a trade-off guide (2026) The internet has a bad habit of turning infrastructure decisions into holy wars. Cloud wins. Self-hosted wins. Managed is for lazy teams. Bare metal is for serious engineers. The reality is less satisfying: there is no universal winner. The right choice depends on your latency budget, your ops team size, your data compliance posture, and how close your nodes need to be to the rest of your stack. This guide lays out the trade-offs honestly, so you can make the call for your specific situation rather than someone else’s. What this guide covers What cloud-managed nodes actually give you (and what they quietly take away) What self-hosted nodes actually give you (and what the ops burden really looks like) The five dimensions that should drive your decision Where Chainstack Self-Hosted fits — and why it changes the calculus for some teams A decision matrix you can apply today Managed cloud nodes: the real trade-offs Cloud-managed blockchain infrastructure — whether that’s Chainstack, Alchemy, Quicknode, or Infura — offloads the operational complexity of running nodes. You get an endpoint, you call it, someone else handles syncing, patching, client upgrades, and disk management. That is genuinely valuable. The ops burden of a production blockchain node is non-trivial. What cloud gives you Low time-to-production. You can have a working RPC endpoint in minutes. No server provisioning, no client configuration, no sync wait. For teams prototyping or running low-traffic workloads, this matters more than almost anything else. Ops abstraction. Client upgrades happen automatically. Hardforks don’t require a 2am maintenance window. Disk expansion isn’t your problem. The engineers who would otherwise be on-call for node health are free to build product instead. Geographic distribution. Good cloud providers serve requests from nodes close to the caller. Chainstack’s Global Nodes use geo-balanced routing across regions — meaning a user in Singapore gets routed to a node in Asia, not one in Frankfurt. Horizontal scale without pre-planning. Traffic spikes don’t require you to have provisioned the right hardware six weeks ago. Cloud RPC absorbs load without requiring ops intervention. What cloud takes away Latency predictability. When your application and the node live on different infrastructure — potentially in different regions — you’re paying a network tax on every RPC call. For most applications this is acceptable. For MEV bots, high-frequency traders, and latency-sensitive DeFi strategies, shared cloud node overhead can be the difference between a profitable trade and a missed one. Data residency. When you call a cloud node, your transaction data, IP address, and call patterns leave your perimeter. For teams under GDPR, financial regulations, or enterprise data policies, this is not a theoretical concern — it’s a compliance requirement. Customization. You can’t choose your execution client. You can’t tune EVM parameters. You can’t attach custom indexers to the node process. What the provider configured is what you get. Rate limit ceilings. Most cloud plans have request-per-second limits that become real constraints at scale. Burst traffic requires plan upgrades or load-shedding logic in your application layer. Cost at scale. Cloud RPC pricing is roughly linear with call volume. At low traffic, it’s negligible. At production scale — millions of calls per day — the bill grows in ways that can surprise teams who didn’t model it upfront. Self-managed nodes: the real trade-offs Self-managed (self-hosted) means you own the machine, the client, and the responsibility for keeping everything running. That ownership is the point — and it’s also the burden. What self-managed gives you Latency you control. When your application and your node run in the same datacenter — or on the same physical host — RPC latency drops to single-digit milliseconds. For latency-sensitive workloads, this isn’t a nice-to-have; it’s a hard requirement. A MEV searcher co-locating with validators has fundamentally different infrastructure needs than a portfolio tracker. Data stays in your perimeter. Nothing leaves your environment. Your transaction patterns, query volume, wallet data — all of it stays on infrastructure you control. This is the baseline requirement for serious institutional deployments, regulated fintech, or any team that’s been through a security review. Full customization. You choose the execution client (Geth, Nethermind, Erigon, Besu). You configure the archive depth. You run custom middleware. You attach Prometheus scrapers, custom log pipelines, or chain-specific indexers. The node is yours to configure. Predictable costs at scale. Hardware is a fixed cost. A server running a full Ethereum node doesn’t care whether you make 100,000 RPC calls or 10,000,000. At sufficient call volume, owning the hardware is substantially cheaper than paying per-request cloud rates. No rate limits. Your internal team can hammer the node without hitting plan ceilings or triggering throttling. What self-managed takes away Ops time. This is the real cost teams underestimate. Client upgrades require coordination. Hardforks require maintenance windows. Disk fills up. A node that falls behind sync becomes a source of stale data. Someone on your team owns all of this, indefinitely. Initial setup complexity. Getting from a blank server to a healthy, synced, monitored node takes hours to days — longer for chains with large state. Every chain you add is another sync, another client pair, another monitoring configuration. Multi-chain ops multiply. Running nodes for two chains is roughly twice the work. Five chains is genuinely heavy ops unless you have tooling to standardize deployment, monitoring, and update workflows across clients. Backup and redundancy are your problem. A cloud provider handles failover. If your self-hosted node dies at a bad time, your application goes down until you restore it — unless you’ve built your own redundancy layer. Five dimensions that should drive your decision 1. Latency budget If your workload tolerates 20–80ms RPC overhead, cloud is fine. If it doesn’t — MEV, HFT, latency-sensitive DeFi, real-time price feeds — self-hosting co-located with your application is the only answer. There’s no cloud routing optimization that eliminates cross-datacenter latency. Signal: self-hosted if you’ve ever blamed latency for a missed opportunity or degraded user experience. 2. Ops team capacity Cloud-managed nodes effectively convert ops headcount into a subscription fee. If your engineering team is lean and blockchain infrastructure isn’t a core competency, paying that fee makes sense. If you have dedicated infrastructure engineers who want control, the ops burden becomes manageable. Signal: cloud if every engineer who might own node ops is already fully allocated to product. 3. Data residency and compliance This is binary. If your organization has data residency requirements, a compliance policy that prohibits data leaving your environment, or a security posture that can’t accommodate third-party infrastructure for transaction data — you self-host. Cloud RPC is not an option regardless of how good the provider’s SLA is. Signal: self-hosted if you’ve had a legal or security review that touches RPC data. 4. Scale and cost trajectory At what call volume does owning hardware become cheaper than paying per-request? For most teams, that inflection point is somewhere between 500,000 and 5,000,000 calls per day depending on chain and provider. Teams on the left side of that curve benefit from cloud. Teams on the right side should be running their own nodes. Signal: self-hosted if your monthly cloud node bill is growing faster than the revenue from the product it serves. 5. Customization requirements Most applications don’t need custom node configuration. But if you’re building an indexer, running a custom mempool analysis tool, operating a validator alongside your node, or need to expose non-standard APIs — cloud won’t give you what you need. You need root access to the node process. Signal: self-hosted if your use case requires anything a standard RPC endpoint doesn’t expose. The trade-off matrix DimensionCloud winsSelf-managed winsTime to first endpoint✅ Minutes❌ Hours to days (sync time)RPC latency❌ 20–80ms cross-region overhead✅ <5ms co-locatedOps burden✅ Near-zero❌ Ongoing — upgrades, disk, monitoringData residency❌ Data leaves your perimeter✅ Stays on your infrastructureCost at high call volume❌ Linear with calls✅ Fixed hardware costCustomization❌ What the provider configured✅ Full client and config accessMulti-chain scaling✅ Add a chain in one click❌ Multiplies ops complexityFailover and redundancy✅ Handled by provider❌ Your responsibility No column wins cleanly. That’s the point. Where Chainstack Self-Hosted changes the calculus The traditional framing of this decision treats cloud and self-hosted as the only two options. In 2026, that’s no longer the complete picture. Chainstack Self-Hosted is a third path: you run nodes on infrastructure you own and control, but the deployment, configuration, self-healing, and lifecycle management are handled by Chainstack’s tooling. You get the data residency, latency, and customization benefits of self-hosted infrastructure — without inheriting the full ops burden. What it actually delivers One-click deployment across all major protocols — select the protocol, network, and node type, and you’re live in minutes. Right-sized node configurations are applied automatically based on your hardware and protocol requirements. Snapshots significantly reduce initial sync time, cutting what used to take days down to hours. Self-healing and automated updates — nodes monitor themselves and recover automatically from failures. When client updates are available, you get notified and control when they’re applied. No manual coordination, no maintenance windows that turn into incidents. Configurable zero-downtime failover — set failover to a secondary node, the Chainstack high-performance cloud RPC endpoint, or any endpoint you specify. Your applications stay online during updates or unexpected failures. Integrated monitoring, alerts, and observability — real-time node performance data, without building a monitoring stack from scratch. Your data never leaves your environment — nodes run in secure, isolated environments with encryption and strict access controls. Chainstack Self-Hosted is SOC 2 and ISO certified. How it compares to doing it yourself DIY self-hostingChainstack Self-HostedInfrastructure ownershipUser managedUser managedDeploymentManual setup and scriptingOne-click, minutes to hoursFailure recoveryManual intervention or custom toolingSelf-healing and automatic recoveryFailoverCustom implementation per setupConfigurable out of the boxUpdates and maintenanceManual upgrades and coordinationAutomated update workflowsMonitoring and alertsSelf-built monitoring stackIntegrated monitoring and alertsTime to productionDays to weeksMinutes to hours Where you can run it Chainstack Self-Hosted deploys onto any Linux server — cloud VPS, virtual machines, bare metal, or local environments. It also ships pre-installed on partner infrastructure: BreezeHost — Get 50% off servers for the first month with code CHAINSTACK50 Serverside.com — 10% off servers Velia — Get 80% off servers for the first month with code CHAINSTACK80 HOSTKEY — pre-installed The partner server option reduces setup to the absolute minimum: pick a server, Chainstack Self-Hosted is already there. The cost angle Cloud managed RPC fees scale with call volume — at production scale, those fees are substantial. Chainstack Self-Hosted is a flat subscription on top of your own hardware costs. For teams crossing into high call volumes, the economics shift materially. The headline numbers from the product page: 99.99% operational uptime, 5x faster path to production vs. DIY self-hosting, 24/7 automated operations. Who should choose what Choose cloud-managed nodes if: You’re in early development or running low-to-medium traffic Your team has no dedicated infrastructure capacity Latency in the 20–80ms range is acceptable for your use case Data residency isn’t a compliance requirement You need to add or drop chains quickly without ops overhead Choose self-managed (DIY) nodes if: Latency is a hard competitive requirement and you have the ops team to match You have specific customization needs that cloud RPC can’t meet You have dedicated infrastructure engineers comfortable with blockchain client operations You want maximum control and are willing to own the full lifecycle indefinitely Choose Chainstack Self-Hosted if: You need the data residency or latency benefits of self-hosting, but your team is too lean to absorb the full DIY ops burden You’re scaling to call volumes where cloud pricing becomes a significant cost line You want the flexibility to run on your own hardware, a partner server, or bare metal — with consistent tooling across all of it You’ve been putting off self-hosting because of the operational overhead Conclusion The cloud vs self-hosted debate is the wrong frame. The real question is: what does your workload actually require, and what’s your team capable of maintaining? Cloud managed nodes are the right default for most early-stage and mid-traffic applications. They compress time-to-production and eliminate ops overhead at a cost that’s reasonable until scale becomes a factor. Self-managed nodes are the right answer when latency, data residency, or customization requirements make cloud insufficient. The ops burden is real — but it scales with how much tooling you’re willing to invest in. Chainstack Self-Hosted exists at the intersection: the data control and latency of self-hosted infrastructure, with ops overhead that doesn’t require a dedicated infrastructure team and a time-to-production measured in minutes, not weeks. There’s no clear winner. There are trade-offs. Pick the one that fits where you actually are. Run nodes on your own infrastructure — without the ops overhead. Explore Chainstack Self-Hosted → FAQ Is self-hosting blockchain nodes cheaper than cloud? At low call volumes, cloud is usually cheaper when you factor in hardware, bandwidth, and engineer time. The break-even point varies by chain and provider, but typically sits somewhere between 500K and 5M daily RPC calls. Above that threshold, owning the hardware is often substantially cheaper. How much latency difference does self-hosting actually deliver? Cloud nodes in the same geographic region typically add 20–80ms of round-trip overhead. A self-hosted node co-located with your application can deliver sub-5ms RPC latency. For MEV, HFT, and latency-sensitive DeFi, that gap is the difference between a competitive and non-competitive strategy. What’s the actual ops burden of running a self-managed blockchain node? The main ongoing costs are: client upgrades (especially around hardforks), disk management (archive nodes grow continuously), monitoring and alerting setup, and incident response when nodes fall behind sync. DIY self-managed typically takes days to weeks to reach production. Chainstack Self-Hosted compresses that to minutes to hours, with automated maintenance thereafter. See the full DIY vs Chainstack Self-Hosted comparison for a detailed breakdown. Can I start with cloud and migrate to self-hosted later? Yes, and this is a common trajectory. Most teams start on managed cloud RPC, identify latency or cost pressure at scale, then migrate. The migration requires syncing nodes and updating endpoint configurations, but doesn’t require downtime if you switch endpoints atomically. Does Chainstack Self-Hosted work on my own hardware? Yes — it deploys onto any Linux server: cloud VPS, virtual machines, bare metal, or local environments. It also ships pre-installed on partner providers including BreezeHost, Serverside.com, Velia, and HOSTKEY. See the installation guide for requirements and setup. What chains does Chainstack Self-Hosted support? Check the Chainstack documentation for the current supported protocol list, as it expands regularly. The managed cloud offering covers 70+ chains. Is self-hosted compliant with GDPR and financial data regulations? Self-hosted nodes keep your data on infrastructure you control, which is a necessary precondition for most compliance frameworks. Chainstack Self-Hosted is SOC 2 and ISO certified. Whether it’s sufficient for your specific regulatory requirements depends on your overall architecture — self-hosting the node removes the third-party data processor concern from the node layer specifically. Additional resources Chainstack Self-Hosted — product page Self-hosted blockchain node: challenges and solutions Self-hosted blockchain node: DIY vs Chainstack Self-Hosted Blockchain node hosting: how to choose the best setup in 2026 Top 5 Ethereum node setup tools in 2026 Top 5 easiest ways to run an Ethereum node in 2026 Chainstack documentation — Self-Hosted quick start #### Coin98 on Chainstack: Fostering an ecosystem of Web3 applications across blockchain protocols Coin98 Labs is a builder of DeFi solutions with a core focus on creating an ecosystem of protocols, Web3 applications and NFTs across various blockchains. As an Open Infrastructure Financial Services developer, Coin98 Labs aims to fulfil untapped demand and enhance the current DeFi experience for users. What does Coin98 do? Coin98’s primary mission is to resolve common obstacles to mass adoption such as the case of high complexity in interaction with DApps and various DeFi protocols. It does so by developing a palette of innovative products such as the Coin98 Super App, Coin98 Exchange, Coin98 SpaceGate, Saros Finance, and other initiatives, currently in incubation. These products combined form the Coin98 Ecosystem as a comprehensive solution that caters to all aspects of the DeFi experience across multiple blockchain protocols. While the Super App provides secure non-custodial storage for various digital assets, the Exchange powers instant swaps by aggregating liquidity with L2 access via Space Gate, and Saros offers low-cost staking and investment opportunities for their users. Ever since 2020, Coin98 has garnered a significant user base of more than 2,000,000 across its products, generating over 3,000,000 transactions and $750,000,000 worth of trading volume. Not only that but throughout its journey Coin98 Labs has managed to integrate 50+ blockchain protocols already, making steady progress in bringing the Web3 space closer together. How did Coin98 come across Chainstack? On their way to successfully integrating over 50 blockchain protocols, Coin98 was looking for a robust Web3 infrastructure provider to meet the challenge of the ever-increasing user flow that came with it. That was especially true for EVM-based blockchains and hardware-intensive implementations on the Solana network. Without a reliable partner that could help them tackle these challenges, the Coin98 team would have faced a snowballing issue, in terms of dropped requests and preventable service downtime. Not only that but because of the hindered delivery of services, Coin98 could have incurred significant damages to its reputation and thus creating more obstacles to its goal of mass adoption. After polling for possible solutions, the Coin98 team came across Chainstack, as a reliable provider that could help them resolve such challenges on the go. Coming as a highly accessible, secure, and recommended platform, Coin98 reached out to us to support their efforts across the Web3 space. How does the Chainstack offer match Coin98 needs? To create a seamless user experience across their Web3 stack, Coin98 was in dire need of a high-performance infrastructure provider that could adhere to the demanding requirements of their use case. With Chainstack’s help, the Coin98 team was able to successfully scale their position up on the DeFi landscape. Working side-by-side with our team, Coin98 managed to apply our services to their implementations on Ethereum, Fanton, Polygon, BNB Smart Chain, and Solana in streamlining their initiatives there. This effectively solved the performance bottlenecks they faced and paved the way toward an outstanding user experience. In doing so, Chainstack’s offer became a match made in heaven for Coin98 as it allowed the team to focus on creating value with their product, instead of investing significant resources into doing everything by themselves. There was little need to reinvent the wheel, after jumping on the Chainstack bandwagon after all. Outcome Following the successful implementation of Chainstack’s reliable infrastructure across the Coin98 Web3 stack, the team noticed significant improvements to the effective delivery of core services. Some of the most impactful changes occurred in areas relating to native swap, balance loading, tokens transfer, on-chain tracking, and other critical features of the Coin98 ecosystem. With our help, Coin98 was able to meet the ever-increasing demand for their services and do so without compromising security and reliability. Chainstack’s resilient infrastructure allowed them to continue on their journey to provide exceptional value and user experience with every product in their ecosystem. In addition to the outstanding service deployment, our team was responsive and worked with Coin98 in resolving any challenges that occurred during the implementation process. This all culminated in the successful enhancement of the stability of Coin98’s stack and allowed them to further scale their efforts more securely and efficiently than ever before. What does Coin98 like about Chainstack? Our team is constantly on the lookout for prospective projects that might assist us in improving Coin98 Super App performance and user experience on multi-chain. Chainstack is the ideal solution, with a stellar reputation for automation, standardization, and compatibility, rooted in low-latency & precision engineering. Chainstack infrastructure is capable of high-traffic stable transactions that result in a better product experience and performance for end-users. Coin98 Super App can rely on Chainstack to strengthen our core services, removing friction and allowing us to focus on developing essential product optimization. Vinh The Nguyen, Coin98 Finance Co-Founder. What does Chainstack like about Coin98? One of the major obstacles before mainstream blockchain adoption is by far a seamless user experience for both the tech-savvy and the not. Seeing projects making steady waves in resolving such challenges is always a welcome sight, which is what makes it exciting to work with projects like Coin98 that push development in that direction. Eugene Aseev, Founder & CTO, Chainstack What is the most interesting engineering challenge in working together? Considering the explosive growth of the Coin98 Super App in terms of adoption, user base, protocol integration, transactions, and swap volume, being able to cater to its need for high-performance infrastructure was an interesting challenge in itself. And as the product matured further these requirements scaled up with the demand. By implementing Chainstack’s robust offering, Coin98 was able to fine-tune critical metrics, prior to delivery to the millions of users they serve on a regular basis. Working together with our team, Coin98 successfully improved core metrics such as their native swap, balance loading, token transfer and on-chain tracking. In the end, with the help of Chainstack’s game-changing technology, Coin98 managed to take significant steps forward in fulfilling its vision of “Your Crypto Everything App.” And in doing so, Chainstack took the vital role of supporting the blockchain innovations brought forward by the Coin98 team by delivering the utmost system performance and user experience across protocols. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Compare Dashboard now tracks Arbitrum and BNB Smart Chain At Chainstack, we are committed to providing Web3 developers and enterprises with full transparency into blockchain infrastructure performance. Since the launch of the Chainstack Compare Dashboard, our goal has been to empower developers with real, actionable data—helping them make informed decisions about their infrastructure providers based on measurable reliability and performance. Today, we are expanding the dashboard with the addition of two highly demanded networks: Arbitrum BNB Smart Chain (BNB) With this update, Web3 developers building on Arbitrum or BNB can now access real-time infrastructure performance metrics—including API success rates, response times, and reliability—collected continuously from real network traffic. Arbitrum RPC infrastructure benchmarking Arbitrum has emerged as the leading Ethereum Layer 2 rollup, offering faster transactions and lower fees while inheriting Ethereum’s security guarantees. However, like all blockchain networks, Arbitrum infrastructure varies significantly across providers—especially under high network load. By integrating Arbitrum into the Chainstack Compare Dashboard, developers can now benchmark infrastructure performance in real time and evaluate key metrics that directly impact application stability and user experience. Figure 1: Chainstack Compare Dashboard Arbitrum Provider Score extract; Source: Chainstack BNB Smart Chain real-world RPC performance BNB Smart Chain remains one of the highest-traffic blockchain networks globally, supporting a vast ecosystem of decentralized applications. However, with scale comes complexity—and infrastructure performance on BNB varies considerably across providers and regions. Figure 2: Chainstack Compare Dashboard BNB Smart Chain methodology; Source: Chainstack With this latest update, the Chainstack Compare Dashboard now tracks BNB, providing Web3 developers with full visibility into how providers handle production workloads—allowing for data-driven infrastructure decisions. A data-driven approach to provider selection The Chainstack Compare Dashboard is purpose-built to bring transparency to Web3 infrastructure. It operates through a distributed, multi-region architecture that: Continuously queries blockchain networks using real API calls. Collects and aggregates performance metrics across providers. Visualizes success rates, response times, and reliability in real time. This enables developers to move beyond theoretical benchmarks and evaluate infrastructure based on real-world conditions. Figure 3: Chainstack Compare Dashboard ARB eth_call & eth_getBalance historical; Source: Chainstack To learn more about how the dashboard operates, read our original announcement or explore the open-source repository powering the system. Benchmark your ARB and BNB RPC in real time Arbitrum and BNB Smart Chain are now fully integrated into the Chainstack Compare Dashboard, joining existing support for Ethereum, Solana, Base, and TON. Figure 4: Chainstack Compare Dashboard ARB eth_call & eth_getBalance regional; Source: Chainstack We encourage all developers and enterprises building on Web3 to explore the Dashboard, validate their infrastructure choices, and ensure they are building on a foundation that meets the highest standards of reliability. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. Building on BNB Smart Chain? Deploy your BNB Smart Chain node on Chainstack → Building on BNB Smart Chain? Deploy your BNB Smart Chain node on Chainstack → #### Complete Guide to Lens Protocol—A decentralized social media network You probably use Twitter, YouTube, and other social media platforms, but did you know that you don’t own your data, posts, videos, or anything else you share on these social media apps? All Web2 social media apps have the right to delete your posts, your content, or even your account. However, Lens Protocol solves this problem.   What is Lens Protocol?   Lens Protocol is a decentralized and composable social graph that allows developers to build their own decentralized social media platforms on the Polygon blockchain.  Why is DeSo (decentralized social) important? Decentralization means the users have the complete right to their content. It means instead of centralized entities owning the content, ownership gets distributed amongst users.  It is built by the same team behind Aave, the leading lending platform on Ethereum. Lens Protocol enables creators to take ownership of their content.   How does Lens Protocol work?  Every profile in the Lens Protocol is unique and users need to first create and publish their profile. After creating their profiles, users can post, discuss, and share content on any site that is built on top of Lens, such as Lenster, Lenstube, and many others. Modules play a vital role in Lens Protocol, they allow every profile owner to include custom functionality on their profiles. There are mainly 3 modules i.e: Follow, Collect, and Reference.  Each task on Lens Protocol is tokenized into an NFT, thus if I follow someone, I will have an NFT that proves that I am doing so.   Now that you have a good understanding of Lens Protocol, let’s build a simple app using Lens API and see how it works.   Lens protocol tutorial – Prerequisites  For this tutorial, you would need  Basic knowledge of React.js, APIs, and Web3.  An RPC endpoint, you can sign up with Chainstack to deploy your own node and get the endpoint. Have Node.js and NPM installed on your machine.  Setting up the project  The first step is to set up the project, for this tutorial we will be using React.js, Tailwind CSS, and Lens API. You can run the below command in your terminal to create a simple react project.  npx create-react-app lens-app Once it is completed, you should see a new directory named lens-app. Now it is time to add Tailwind CSS to our application.   Adding TailwindCSS  Tailwind CSS is a utility-first CSS framework for building user interfaces rapidly. Run the below command to install tailwindcss, postcss, and autoprefixer.  npm install -D tailwindcss postcss autoprefixer The -D flag is the shortcut for: –save-dev which installs the package as a dev dependency.  Once the dependencies are installed, we need to initiate the Tailwind CSS. To do that, run the below code in your terminal.  npx tailwind init -p The above command will generate two files named tailwind.config.js and postcss.config.js. These two are the configuration for the styling of our app.  Update the tailwind CSS configuration file by adding two file paths in the contents array.  module.exports = {   content: [     "./src/**/*.{js,jsx,ts,tsx}",   ],   theme: {     extend: {},   },   plugins: [], } At last, include the tailwind CSS styling in the index.css file so we can use the Tailwind CSS styling in your app.  @tailwind base; @tailwind components; @tailwind utilities; Add the below snippet in the App.js file to check whether the Tailwind CSS integrated successfully or not: <div className="flex flex-co items-center justify-center h-screen"> <h1 className="text-4xl font-semibold mb-4">Lens App</h1> </div> Run npm start to start the server, if everything is integrated successfully, you should see a similar page.  Installing Ethers, RainbowKit and WAGMI  Now that your project is integrated successfully with TailwindCSS, it’s time to add Web3 support to it. To add the Web3 functionality we will be using: Ethers.js — a JavaScript library that allows us to interact with the blockchain and smart contracts. RainbowKit — one of the best connect wallet libraries with a beautiful UI. WAGMI — provides us with hooks that make integration with ethers easier.  You can install these three dependencies by running the command below in your terminal.  npm install @rainbow-me/rainbowkit wagmi ethers Once the dependencies are installed, open index.js and replace it with the below code.  import React from "react"; import ReactDOM from "react-dom/client"; import "./index.css"; import App from "./App"; import reportWebVitals from "./reportWebVitals"; import "@rainbow-me/rainbowkit/styles.css"; import "@rainbow-me/rainbowkit/styles.css";   import { getDefaultWallets, RainbowKitProvider } from "@rainbow-me/rainbowkit"; import { chain, configureChains, createClient, WagmiConfig } from "wagmi"; import { jsonRpcProvider } from "wagmi/providers/jsonRpc";   const { chains, provider } = configureChains(   [chain.polygon],   [     jsonRpcProvider({       rpc: (chain) => ({         http: "YOUR_CHAINSTACK_RPC",       }),     }),   ] );   const { connectors } = getDefaultWallets({   appName: "My Lens App",   chains, });   const wagmiClient = createClient({   autoConnect: true,   connectors,   provider, });   const root = ReactDOM.createRoot(document.getElementById("root")); root.render(   <React.StrictMode>     <WagmiConfig client={wagmiClient}>       <RainbowKitProvider chains={chains}>         <App />       </RainbowKitProvider>     </WagmiConfig>   </React.StrictMode> );   reportWebVitals(); In the above code, we have imported RainbowKit and WAGMI and then we have provided the chains. Since Lens is deployed on the Polygon blockchain, we have only included the Polygon Mainnet.  At last, we have wrapped our main component with WAGMI and Rainbow providers. Make sure to replace “YOUR_CHAINSTACK_RPC” with your RPC which was mentioned about.   You can also import Connect Button that is provided by RainbowKit by default in the app.js. Once you have imported it, you can add it below the h1 tag. Finally, this is how you index.js code should look like.  import { ConnectButton } from "@rainbow-me/rainbowkit"; import React from "react"; export default function Home() {   return (     <div className="flex flex-col items-center justify-center h-screen">       <h1 className="text-4xl font-semibold mb-4">         Lens App       </h1>       <ConnectButton />     </div>   ); } Save the files and reload the page, you should see a connect button. Click on it and you should be able to connect your wallet and see your wallet address. Integrating Lens API  Now that you can connect your wallet and we have added Web3 support to our application, it’s time to integrate the Lens API into our application. However, before that, we need to set up GraphQL in our app since Lens provides GraphQL APIs.  GraphQL is an open-source query language that offers flexible and user-friendly syntax to describe the data requirements and interactions. As an alternative to REST,  developers can create GraphQL requests that include data from various sources from a single API call.  Setting up Apollo GraphQL  In this article, we will be using Apollo GraphQL which is a powerful and simple GraphQL client that can be used with React, React Native, Next, and other frameworks and libraries.  The first step is to install Apollo GraphQL using the below command: npm install @apollo/client graphql Once the dependency is installed, create a new file named client.js inside the src directory and add the below code to it.  import { ApolloClient, InMemoryCache } from "@apollo/client"; const client = new ApolloClient({   uri: "<https://api.lens.dev>",   cache: new InMemoryCache(), }); export default client; Now we have a GraphQL client we can use within the application, and we’re ready to query for some data.  Interacting with Lens API  Finally, now it is time to use Lens API in our applications. Replace the below code inside of your App.js file.   import { gql } from "@apollo/client"; import { ConnectButton } from "@rainbow-me/rainbowkit"; import React, { useEffect, useState } from "react"; import client from "./client";   export default function Home() {   const [users, setUsers] = useState([]);     const fetchUsers = async () => {     let query = gql`       query ExploreProfiles {         exploreProfiles(request: { sortCriteria: MOST_FOLLOWERS }) {           items {             id             name             handle             picture {               ... on NftImage {                 uri               }               ... on MediaSet {                 original {                   url                   mimeType                 }               }             }             stats {               totalFollowers               totalFollowing               totalPosts             }           }         }       }     `;     client.query({ query }).then(({ data }) => {       setUsers(data.exploreProfiles.items);     });   };   useEffect(() => {     fetchUsers();   }, []);   return (     <div className="flex flex-col items-center justify-center h-screen">       <h1 className="text-4xl font-semibold mb-4">         Lens x React.js x Chainstack       </h1>       <ConnectButton />       {users.map((user) => (         <div key={user.id}>           <p>{user.handle}</p>         </div>       ))}     </div>   ); } In the above code, we have imported the client from the src folder and created a state named users. Next, we created a function that fetches the user details using the Lens API. We have provided the query string and with the help of the Apollo client, which we declared on the client file, we are querying the API and updating the state using the API response. We use the useEffect hook to invoke this function upon page load. At last, we are mapping the user’s array and rendering the user’s handle on the page.   Once you refresh the browser, you should be able to see a similar page. The styling in our app needs some improvement, so let’s style this user’s list using Tailwind. Create a new folder named components and inside of it create a new file named card.js. Add the below code inside of the card.js file. import React from "react";   export default function Card({ user }) {   return (     <div className="flex flex-col items-center justify-center  w-1/2 rounded-md p-10 mt-4 shadow-lg">       <img         src={user.picture?.original?.url || "https://placekitten.com/200/200"}         className="w-24 h-24 rounded-full mr-4"       />       <h2 className="text-2xl font-semibold mt-4">         {user.name} (@{user.handle})       </h2>       <p className="mt-4">         <span className="font-semibold">{user.stats.totalFollowers}</span>{" "}         Followers         <span className="font-semibold ml-4">           {user.stats.totalFollowing}         </span>{" "}         Following         <span className="font-semibold ml-4">{user.stats.totalPosts}</span>        Posts       </p>       <p className="text-center mt-4">{user.bio}</p>     </div>   ); } In the above component, we have passed user objects as a prop,s and then with help of Tailwind CSS we have created a simple card component that shows users’ data, such as image, name, handle, and stats. Now in the App.js replace your return function with the below code and import the card component from the components folder.   return (     <div className="flex flex-col items-center justify-center ">       <h1 className="text-4xl font-semibold mb-4">Lens App</h1>       <ConnectButton />       {users.map((user) => (         <Card user={user} />       ))}     </div>   ); And now if you refresh your web page, you should see a better-looking user’s card, similar to the below image.   Conclusion  That is it for this tutorial. From What is Lens Protocol to querying the Lens API, we have covered in this tutorial. We have also learned about GraphQL and how to use GraphQL APIs in a React.js application.  We hope that this article gives a good understanding of Lens Protocol, how it works, and how to use Lens API in a react app.  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Corda automation testing with Nightwatch.js and CircleCI Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Testing is an integral part of software development. In Chainstack, we do not only test the platform but also ensure all blockchain protocols work perfectly. In this post, I will share how we carry out end-to-end continuous Corda integration with Nightwatch.js and CircleCI. The code in Corda is written using Kotlin, a programming language from JetBrains, and Nightwatch.js is a Node.js powered end-to-end testing framework. Our challenges are to connect to a node, initiate a flow, and have it signed by relevant parties using JavaScript. We have a few ideas to do this: Run a Corda web server in our Docker image, and write JavaScript to interact to the CorDapp. Set up GraalVM (a high-performance polyglot VM) in our Docker image, write a Java function in Nightwatch.js. Interact with Corda Standalone Shell client by executing a shell script in Node.js, then verify the output of the shell script. The first two ideas seem possible, but we need to include CorDapp source code in the test, which is non-optimal and inconvenient. Eventually, the last one is better and simpler. We use No ticket scalping CorDapp for our test. You may want to explore it before moving to details. Technology stack These are the details of programming languages, tools, and frameworks we used in the test: Nightwatch.js 1.3.2 / Node.js 11 / shell script; Docker; CircleCI 2.0; OpenJDK-8; Corda Standalone Shell client; No ticket scalping CorDapp installed on two Corda nodes, running on Chainstack. I assume that you are familiar with the Nightwatch.js framework, so I won’t focus on the structure as well as the test case code. Besides the Corda Standalone Shell client, Chainstack also provides Chainstack standalone shell, which is a containerized version of Corda Standalone Shell, and which helps you interact with the CorDapps. You can learn more about it in our official documentation. Node details and credentials in Chainstack. Install OpenJDK-8 in Docker image You need to install OpenJDK-8 to run Corda Standalone Shell client; add the following lines into your Docker file. # Install OpenJDK-8 RUN apt-get update && \ apt-get install -y openjdk-8-jdk && \ apt-get install -y ant && \ apt-get clean; # Fix certificate issues RUN apt-get update && \ apt-get install ca-certificates-java && \ apt-get clean && \ update-ca-certificates -f; # Setup JAVA_HOME -- useful for docker commandline ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/ RUN export JAVA_HOME You may need to build your Docker image again. docker build . Write a shell script to interact with No ticket scalping CorDapp You can learn the prerequisites to run Corda Standalone Shell client at Chainstack Docs. The below script will do the following things: Connect to Corda Node 1. Print out all flows in Node 1. Start noScalpFlow flow to distribute 99 tickets of event Chainstack live concert from Node 1 to Node 2. Verify the transaction by executing the vaultQuery command. Exit the Corda Standalone Shell client. # location of binary files CORDA_CLI="corda-tools-shell-cli-4.3-all.jar" CORDAPP_DIR="../my-cordapps/" # node 1 credentials NODE1_HOST="nd-255-728-694.rg-837-380.int.chainstack.com" NODE1_PORT="10201" NODE1_USER="vibrant_ptolemy" NODE1_PASS="*****" # node 2 legal name NODE2_LEGALNAME="OU=Chainstack-ND-026-270-261, O=Chainstack, L=Singapore, C=SG" # command to connect to Corda node 1 START_CORDAPP="java -jar $CORDA_CLI --host=$NODE1_HOST --port=$NODE1_PORT --user=$NODE1_USER --password=$NODE1_PASS --cordapp-directory=$CORDAPP_DIR" # launch the Corda Standalone Shell client and run flow commands { echo "flow list" echo "start noScalpFlow eventName: 'Chainstack live concert', ticketQuantity: 99, toDistributor: '$NODE2_LEGALNAME'" echo "run vaultQuery contractStateType: com.noScalpDapp.states.noScalpState" echo "bye" } | $START_CORDAPP Save as a start_cordapp.sh file, and run it in the terminal. Interact with CorDapp in terminal. Checking the output, there should be a transaction. You can use this information to verify whether the test passed or not. Flow completed with result: SignedTransaction(id=C98A2B49358B9FC6C1C8EEBAA99DF36238E9E4F97CF492905C2A1EF25B1B9639) Execute the shell script by Node.js and verify the output In the below code, I write a function to start the noScalpFlow flow, print out, and verify its result. In Node.js, the child_process module provides the ability to spawn child processes. Then, I combine child_process.exe() and util.promisify() to create an async function which returns a boolean Promise. // Nodejs utils to execute the shell script asynchronously const { promisify } = require('util'); const exec = promisify(require('child_process').exec); /** * Run noScalpFlow flow and verify the result * @param {Object} node1 First node * @param {Object} node2 Second node */ async function verifyFlow(node1, node2) { const CORDA_CLI = 'corda-tools-shell-cli-4.3-all.jar'; const CORDAPP_DIR = '../my-cordapps/'; const START_CORDAPP = `java -jar ${CORDA_CLI} --host=${node1.host} --port=${node1.port} --user=${node1.user} --password=${node1.pass} --cordapp-directory=${CORDAPP_DIR}`; // launch the Corda Shell client and run flow commands const { stdout } = await exec(` START_CORDAPP="${START_CORDAPP}" { echo "flow list" echo "start noScalpFlow eventName: 'Chainstack live concert', ticketQuantity: 99, toDistributor: '${node2.legalName}'" echo "run vaultQuery contractStateType: com.noScalpDapp.states.noScalpState" echo "bye" } | $START_CORDAPP `); // Print out the output console.log(stdout); // Verify the output return stdout.includes('Flow completed with result: SignedTransaction'); } After that, you need a test scenario using the Nightwatch.js framework. // Node 1 credentials const node1 = { host: 'nd-255-728-694.rg-837-380.int.chainstack.com', port: '10201', user: 'vibrant_ptolemy', pass: '*****', }; // Node 2 legal name const node2 = { legalName: 'OU=Chainstack-ND-026-270-261, O=Chainstack, L=Singapore, C=SG', }; module.exports = { '@tags': ['runCorDappFlow'], 'Run CorDapp flow'(browser) { const { page } = browser; const corda = page.nodes.corda(); // Run flow and verify result browser.perform(async () => { await corda.verifyFlow(node1, node2); }); browser.end(); }, }; Commit your code and run the workflow in CircleCI; it will take a few minutes to complete. In my scenario, I get the credentials of Node 1 and Node 2, run the noScalpFlow flow, and verify the output. You can see the results in the below screenshot. Running CorDapp flow in CircleCI. Before writing this post, I have done a lot of research to find the best solution for Corda automation testing as most of the resources from the Internet focus on building CorDapps. I believe this post will help your team to test, speed up, and secure your Corda applications like what the Chainstack team is doing. You can try Chainstack for free at https://console.chainstack.com. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Corda Bootcamp post-mortem: Winging it in the B2D space Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Come for the bootcamp, stay for the fun It’s been years since the word blockchain first came into existence, and yet the pace at which the industry is moving is fast, and the stride of the development in this space is significant. When anything you put out in production has any degree of decentralization, it’s basically taming the chaos. An issue that’d be a small bump on the road in a controlled environment is multiplied by a hundred when you have an autonomous system of entities—live people—acting as people and generally being independent. That’s why there are things happening in the blockchain space daily, hardly a month goes by without an experiment, and that’s why it’s fun. What’s also extremely fun is being a company with a developer-first approach in what’s essentially the nascent industry of experimenting developers. And being the business-to-developers (B2D) company that we are, we love the attitude, the experiment, and sharing the post-mortems. B2D is a tag that we wear proudly, so what follows is a complete write-up on the Corda bootcamp that we had, how it came about, what happened and what should have happened, and generally all the useful experience you get out of a post-mortem. An idea This was not our first bootcamp and not our first fun one either. See Behind the scenes of the Fabric Bootcamp. For this one, running on our long-standing relationship with R3—exemplified by Chainstack being the first company to offer managed Corda services—we teamed up with Corda to do the bootcamp. All we needed was an idea to join our forces around. The objectives People—especially in business—generally do things for a reason, so we had our objectives for the bootcamp too. For you—to be a part of a hands-on blockchain experiment that involves decentralization, get to use Corda and Chainstack, and learn something new. All for free. For R3—to get you familiar with Corda. There’s so much to learn about Corda and the opportunities it creates with its blockchain model. For us—to get you, the developers, familiar with Chainstack. We are quite proud of how easy to use and stable our platform is. We love getting developers to try it. It’s a win-win-win. (Yes, a triple one). The idea After a bit of back and forth, we came up with the idea that should cover all the win-win-win points and be risky enough not to be boring. Risky as in when the power to control the experiment belongs to the people and no one at the same time. Together with the Corda team, we decided to use their tutorial CorDapp that they had recently produced—eAuction—and attempt the following scenario: eAuction structure and flow Create an auction on Corda. The auction must feature a number of items. The bootcamp participants must be able to bid on the items on the auction. There must be a clear result to the auction that’d give the participants the extra push to be a part of the scenario. It’s a simple enough four-point run but executing it is where the details come pouring in. Let’s run through it again. Create an auction on Corda What this involves is: There must be a consortium Corda network running. There must be Corda nodes that belong to the bootcamp participants—to maintain the true sense of ownership. The Corda nodes that belong to the participants must be a part of the deployed Corda network. Each of the nodes must have a CorDapp installed. Each CorDapp is a two-component entity: a workflow and a contract. So each node must have both the workflow and the contract installed by each node owner. As you see, the very first step of the idea has already grown very complex. But that’s exactly where Chainstack shines the most—all of the steps that’d otherwise require hours and hours (or even days) of crazy coordination, communication, and non-trivial knowledge from the participants, is a 15-minute breeze through the UI on Chainstack. The auction must feature a number of items This is an easy part—we decided to do three items that would correspond to three real-world charities. And whichever charity would get the most bids, both Chainstack and R3 would donate an amount of real money to the charity. The charities we picked—Save the Children, UNHCR, and WWF. So that people who care for people can bid on Save the Children and UNHCR, and those who prefer animals can go with WWF. Going back to the eAuction CorDapp at this point, what is an auction really? There must be an asset, there must be a flow for this asset, and there must be participants triggering the flow. There are three assets—Save the Children, UNHCR, WWF. Because each of the assets must be auctioned off, there must be three auctions. Which, in turn, means there must be three flows—one per auction—for the participants to interact with. Okay, so far so good. The bootcamp participants must be able to bid on the items on the auction For the concept of bidding to work, there must be at least two requirements fulfilled: Participants must have something to bid with. A currency. Participants must have a finite amount of currency. There’s no endgame with an infinite amount of cash. To issue some currency and distribute it to participants, there must be a CorDapp that does that—and there is, it’s called Corda finance. Each CorDapp is a workflow and a contract, and each participant must install both on their node. Which brings us to point one—two more installations on the node. Chainstack can handle that easily, just a few extra clicks in the UI. There must be a clear result to the auction At this point, our little auction is shaping up to be less of a real auction but more of a point distribution contest: The participants have a finite amount of cash. We settled on 100 USD (imaginary). Each of the participants must be able to distribute their 100 USD between the three auctioned assets as they see fit. The asset that gets the most cash wins. So it’s not really bidding but a very similar framework nonetheless. The Corda team modified the eAuction CorDapp to accommodate the bootcamp requirements: Remove the requirement that each new bid must be higher than the previous one. Each bid can now be whatever the participants bid. The only limit is their finite amounts of issued cash. Instead of making the highest bid win the auction and not keeping the past bids logged, make each bid add up on the auctioned asset. Voila, that’s how you turn an auction into a decentralized voting contest. If you want to get fancy, you can even go ahead and call it a Decentralized Autonomous Organization prototype. The preparation At this point, we have our bootcamp set up. In theory. The two missing ingredients for the scenario by now are the obvious ones: Testing Documentation We went ahead and did a run through the scenario a few times with several nodes up and running—a vanilla environment and something that is never happening in blockchain. And then we prepared the documentation in the project’s README on GitHub. Not everyone comes prepared for a bootcamp, but some will. So we made sure those that like to plan and prepare in advance—the most passionate and interested really—have the pre-bootcamp instructions that they can use. There are two sides to learning—theory and practice. Now that we have the practical part lined up and tested, it’s a good idea to add some theory in. A bit of theoretical knowledge and a challenge in the form of a quiz will push people on the exploration path and will get them to learn more than they would with a hand-holding practical experiment. So we prepared a quiz. And then we added in the correct answer explanations. Have a look: Test your knowledge: Corda. The preparation Things done and ready: A modified auction CorDapp Documentation Testing Quiz The bootcamp You can watch the recording of the actual bootcamp. Since this is a post-mortem, you don’t have to watch the whole thing. Instead, here’s a schematic representation of the entire sequence: Deploy a consortium Corda network ✅ Get participants to deploy the nodes in the network ✅ Get participants to install the two CorDapps—or four JAR files—on their nodes ✅ Get participants to connect to their nodes ✅ Create three assets—Save the Children, UNHCR, WWF ✅ Start three auctions for the three assets ✅ Issue 100 USD to each of the participating nodes ✖ Even in vanilla environment, things don’t always work right, but in a real experiment that involves decentralization, a small bump can (and will) send the whole thing haywire. The CorDapp stopped at the issue-and-distribute-cash to all participants part. This put an end to the whole experiment. So what happened there? The command itself is start IssueCash amount: 100 USD—this is the entirety of the command that starts the cash issuing flow. Can you spot what’s not exactly production-ready with it? It’s missing the list of participants to distribute the cash to. Instead, it just issues the cash to each node on the network one by one. And if there’s at least one node on the network down, the flow goes into pending forever, and the cash distribution basically grinds to a halt. This makes sense, and it’s something that will always happen in a real live network. There’s simply no universe in which a node in a network does not go down. And it’s also something that other developers have brought up. However, even with that, a node randomly going down is not what actually happened during the bootcamp. What did happen is the cool feature of Chainstack that lets you stop your nodes to save the resources. A participant deployed their node before the bootcamp by following our carefully crafted instructions, then—apparently experimenting with what else was there—stopped the node. The CorDapp attempted to issue cash to a node that was stopped and thus rendered down, which halted the whole experiment. And because there was no way to issue cash to a list of nodes instead of everyone on the network, there was no way to proceed with the experiment. Conclusion Blockchain is fun, and so is being a B2D company in a highly experimental space and writing post-mortems. When things go wrong in a decentralized experiment, they really go wrong. The CorDapp has since been modified to do the cash distribution to a list of nodes instead of every node on the network. What follows a complete walkthrough. Try it, see what it’s like. And also fork the bootcamp auction project and create your own version of the CorDapp. Walkthrough See the video on the Chainstack YouTube channel for the complete walkthrough as well. Deploy a Corda network See Deploy a consortium network. Add a couple of nodes to the deployed network See Add a node to a network. Create a cordapps directory On your local machine, create a directory called cordapps. You will need this directory to interact with the CorDapps when connected to your nodes. Download the auction CorDapp Download the workflow and the contract JAR files from the Releases tab of the project repository. Put them in the cordapps directory. Download the Corda finance CorDapp Download the workflow and the contract of the Corda finance CorDapp: Corda finance contract Corda finance workflow Put them in the cordapps directory. Install the auction CorDapp Install the bootcamp auction workflow and contract one after the other on your Corda node. See Installing a CorDapp. Install the Corda finance CorDapp Install Corda finance workflow first on your node. Then install the Corda finance CorDapp on your node. It’s important that you install the workflow first and only then the contract. Otherwise the installation will not work. See Installing a CorDapp. Connect to your node Connect to one of your nodes as described in Corda tools. Note that you will need to have either Java 8 installed or Docker as described in the documentation. For the Java version, see Corda standalone shell; for the Docker version, see Chainstack standalone shell. To ensure you did everything correctly, once connected to your node, run the flow list command. The output should show you all the CorDapps installed. Create an asset Run: start CreateAssetFlow title: WWF, description: World Wildlife Fund Desc, imageURL: none Get the asset ID Get the created asset ID: run vaultQuery contractStateType: net.corda.samples.states.Asset Start the auction Start the auction for the asset: start CreateAuctionFlow basePrice: 10 USD, auctionItem: 73f5d1cd-b784-4845-9517-dbc3c6e832db, bidDeadLine: 2020-11-14T15:45:01.000Z Where auctionItem is the asset ID you have queried earlier and bidDeadLine is when the auction ends. Replace both values with your own. Issue cash Issue cash to all the nodes that you want to take part in the bidding: start IssueCash amount: 100 USD, recipients: ["PartyA", "PartyB", "PartyC"] Where PartyA, PartyB, PartyC and so on are the Legal name values of your nodes. See View node access and credentials. Connect to a different node See Corda tools. Check currency on the node Check that you have the issued amount: run vaultQuery contractStateType: net.corda.finance.contracts.asset.Cash$State Bid Run: start BidFlow bidAmount: 20 USD, auctionId: d9032f99-c86c-4863-85a3-17737ddd958d Where auctionID is the auction ID you can query with run vaultQuery contractStateType: net.corda.samples.states.AuctionState. Check the auction state Check the auction state to see that your bid has been logged: run vaultQuery contractStateType: net.corda.samples.states.AuctionState Check totalBids value in the output. That’s it. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cordaptor, an embeddable REST API tool for CorDapps, is now on Chainstack Chainstack stopped supporting Corda nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. We are partnering with B180.tech, a wholly-owned business of Bond180 Limited, to add Cordaptor to our Marketplace. Cordaptor is an open-source tool that out-of-the-box generates REST APIs for your CorDapps which makes it easy to integrate Corda into other applications and systems. What is Cordaptor? Cordaptor is a way to instantly add Corda to any application stack that helps to improve the availability, reliability, and flexibility of the overall system architecture. Cordaptor automatically creates fully featured REST APIs for any CorDapp running on a Corda node, complete with OpenAPI 3 JSON specification and Swagger UI. Chainstack prides itself on being able to offer the most accessible and scalable platform to enable teams to deploy, manage, and scale blockchain nodes, networks, and applications. The platform allows users to save tens of thousands of dollars per year on average spent on setting up, securing, and maintaining their own infrastructure that is required to operate distributed ledger nodes across protocols. We believe product teams should concentrate on bringing value to end-users through innovation, and not on infrastructure operations, and the platform team is constantly looking out for ways to streamline the development experience. Therefore, we were very excited to learn about Cordaptor, a new open-source initiative by B180.tech. Cordaptor is an open gateway for Corda, simplifying client application integrations and accelerating Corda adoption through creating open APIs for any Corda application (or CorDapp). It provides out of the box the capabilities that are beneficial in any Corda application architecture, freeing up valuable engineering time to focus on product features. Cordaptor scans a Corda node for installed CorDapps and automatically generates REST API for all available functions. It also creates OpenAPI JSON specification, which is widely supported by integration tools across many technology stacks, so that integrations can be created with very little effort. Bond180 has recently launched its technology business B180.tech to deliver best-in-class technology solutions designed to increase the adoption of nascent technology and to accelerate network creation. We are delighted to partner with Chainstack who mirrors our aspirations, and alongside Chainstack we look forward to supporting innovation-focused businesses to succeed with their applications without the worry of infrastructure development. Bond180 is focused on further developing its technology community through B180.tech as we aim to make data sharing easier in financial services through technology. Phil Holbrook, CEO of Bond180 Limited We are delighted to announce a partnership with B180.tech, that will make Cordaptor available on the Chainstack cloud platform through the marketplace. We hope to be able to offer it on our hybrid and self-hosted platforms in due course as well. Development teams utilizing Corda can use our rich set of self-servicing tools to provision fully managed Cordaptor gateway for their Corda nodes, and accelerate Corda adoption. B180.tech will join our partners panel as a technology and professional services provider able to offer such services as developing and supporting Corda solutions, developing bespoke integrations for distributed Corda applications for consortia members, and advising on technology strategy and enterprise architecture. We are thrilled about the partnership and the fact that Cordaptor is now listed on our Marketplace. Both our solutions are enterprise-grade, blockchain-agnostic and share the same objective of making developers’ life easier. We are a developer-first platform, and we will keep adding new applications, services and developer tools to continuously improve the experience of innovating using Chainstack. Eugene Aseev, Co-Founder and CTO of Chainstack Get started with Cordaptor on Chainstack Go to the Chainstack’s plug and play Marketplace to access Cordaptor that will help you to build and grow your CorDapps. Highlight features Zero-configuration deployment option as an embedded CorDapp bundle great for development and integration testing. Docker-friendly standalone deployment option configurable via environment variables and compatible with Kubernetes Secrets management. Comprehensive REST API allowing vault queries and synchronous or asynchronous execution of Corda flows. Flexible API security with PAC4J allowing a variety of authorization models such as API keys, OpenID Connect, SAML 2, or just about anything else, great for integrating managed services like AWS Cognito or Azure AD. Cordaptor also comes with support for SSL out of the box. Extensible architecture allowing bespoke features to be added as simply as dropping a JAR file into a directory. Comprehensive API for node vault queries. Embedded Swagger UI for exploring the API in your browser. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cordium, the most powerful developer tool for Corda, is now on Chainstack Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. We are partnering with Reneo DLT to add Cordium, the only all-in-one tool built by developers for developers, to our Marketplace. This will make looking under the hood of Corda networks quick and easy. Cordium improves the visibility over the Corda ledger and allows developers to analyze and monitor what is happening to each Corda node over time in a quick and easy way. The creators of Cordium are real pioneers in Corda development. Richard Green wrote the first-ever CorDapp and was formerly part of the developer relations team at R3 back in 2016. Patrick Kuo is the creator of the network management component (Doorman) of the Corda network and of the Corda Firewall. Leading a highly experienced team at Reneo DLT, Richard and Patrick first created a developer solution for their own internal use, and then realized this could be of use to the entire Corda ecosystem. Today they are making it available for free on Chainstack, with the plan to add more features over time. What is Cordium? Cordium is the most powerful all-in-one tool created to look under the hood of Corda nodes, and is available starting today on the Chainstack Marketplace. Cordium allows developers to debug more quickly and easily, access the Node Explorer, deploy Flow Hospital, maintain a Key Store Explorer, among other things. Cordium integrates many useful developer tools in one place, rather than requiring developers to jump from one to the other in order to confirm what is happening inside the node (for example, from the shell to a JDBC viewer, to an IDE). We at Reneo are delighted to be committed to this partnership that helps accelerate the tempo of developers and engineers that use distributed ledgers for solving the ever-increasing complexity of modern-day transactional requirements. Richard Green, Co-founder of Reneo DLT This innovative collection of analytics and development tools under the same roof allows Corda innovators to have full visibility, access and control over what goes on at the ledger level, something that could not be done before. The partnership with Reneo DLT and the addition of Cordium to the Chainstack Marketplace further widens a growing ecosystem of applications hand-picked to make running blockchain networks on Chainstack as easy as sending an email. We are a developer-first platform, rooted in precision engineering, and built by a team of pioneers in the blockchain DevOps industry. Our platform remains the most developer-friendly out there, and we will keep adding new applications, services and developer tools to continuously improve the experience of innovating using Chainstack. Eugene Aseev, Co-Founder and CTO of Chainstack Get started with Cordium on Chainstack Go to the Chainstack Marketplace and start looking under the hood of your Corda network by requesting early access to Cordium on your Corda node. Highlight features: Node Explorer Corda Interactive Shell SQL Console Flow Hospital State Machine Manager Key Store Explorer Node Log Viewer JMX MBean Viewer Checkpoint Viewer Corda App Store Experience full control and visibility over on-chain data and node performance, for the more advanced blockchain engineering experience with Chainstack. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Covalent on Chainstack: Connecting developers to billions of Web3 data points We’re thrilled to share our partnership with Covalent, a game-changing API that lets you, as a Web3 builder, effortlessly fetch historical balances, transactions data, NFT data, and event logs, all with one API call, across 100+ chains. Covalent’s mission is to achieve incredible time-savings for developers by providing a suite of Web3 API that is the easiest to use and requires no maintenance. Now available in our Chainstack Marketplace, the Covalent API provides a seamless way for you to access billions of full historical Web3 data points. This partnership and integration with the Chainstack Marketplace represents a fantastic opportunity to expand our reach and make our Premium API even more accessible to Web3 developers worldwide.Chainstack’s robust platform and commitment to fostering innovation in the decentralized ecosystem perfectly align with our mission to provide developers with the essential data and tools they need to create exceptional Web3 experiences. Erik Ashdown, Head of Ecosystem Growth, Covalent What is Covalent? Covalent is a leading Web3 data provider that specializes in offering a powerful and comprehensive Unified API, giving blockchain developers like yourself access to billions of Web3 data points spanning across more than 100 blockchains and alternative sources, such as app-chains and Layer 2 solutions. Covalent’s data collection process is designed to ensure low latency, allowing you to access the most recent information with minimal delay. By streamlining the process of data retrieval from various blockchains, Covalent has become an invaluable resource for the ever-growing Web3 developer community. Figure 1: The Flow of Web3 Data Through the Covalent Network; Source: Covalent By providing detailed, granular, and up-to-date information of on-chain activity, Covalent’s API has become the go-to solution for Web3 builders like yourself, aiming to harness the full potential of blockchain technology. Additionally, the platform boasts an impressive breadth, covering a wide range of protocols and alternative sources, as well as extensive depth – allowing you to examine data from the genesis block and beyond. Why choose Covalent? Serving a community of over 40,000 developers and parsing data for more than 5,000 applications, Covalent’s Unified API is widely utilized in creating innovative multi-chain solutions. Examples of such applications include crypto wallets, NFT collections, analytics dashboards, investor tools, and many others. The Covalent API has become a trusted resource for prominent applications across Web3, such as 0x, Zerion, Rainbow Wallet, Rotki, Bitski, and many others. By providing developers like yourself with the tools and data necessary to create and scale decentralized applications, Covalent plays a crucial role in fostering innovation and growth within the ecosystem. How can Covalent help you? Thanks to our partnership with Covalent their Premium API is now available via the Chainstack Marketplace, providing Web3 developers across the world with seamless and efficient means of accessing billions of data points. The Premium API also brings higher endpoint rate limits, allowing you to spend less time on data retrieval and more on building exceptional Web3 experiences for your users. Figure 2: Covalent overview; source Covalent  With the Covalent Premium API via the Chainstack Marketplace, you can access comprehensive blockchain data quickly, enjoying a rate of 50 requests per second instead of the 4 that come by default. This minimal latency offering includes historical token balances for all native tokens, ERC20s, and NFTs, as well as all historical transactions for wallets and smart contracts, empowering builders like yourself to create greater value with your projects. By making Covalent’s Premium API available via the Chainstack Marketplace, it is our absolute pleasure to provide Web3 developers across the world with the powerful toolset and resources that they need to create and scale comprehensive decentralized solutions for any use case. In turn, this partnership helps accelerate the adoption and development of blockchain technology by connecting developers like yourself with vital Web3 infrastructure and data. Pricing Covalent is available via the Chainstack Marketplace at an accessible monthly subscription fee that accommodates the needs of developers like yourself, as well as those of business and enterprise across the Web3 landscape. The Premium API is yours for the taking for just $50 a month and comes with a 12.5x higher rate limit of 50 requests per second, a significant increase from the initial offering’s 4. With the Premium API, you benefit from swifter access to Covalent’s comprehensive blockchain data, including historical token balances for native tokens, ERC20s, and NFTs from genesis and beyond. And thanks to the affordable monthly commitment, developers like yourself can give their utmost attention to the BUIDL. Feature highlights  Powerful Unified API: Access billions of Web3 data points across 90+ blockchains and alternative sources from the genesis block and beyond.  Low latency: Fetch the latest data with minimal delay and explore historical token balances for native tokens, ERC20, and NFTs   High request rate: Enjoy Covalent 12.5x more with 50 requests per second offered via the Chainstack Marketplace, instead of the 4 that come with the default offering.  Trusted by developers: Join the ranks of 40,000+ developers and 5,000+ applications using Covalent. Affordable pricing: Gain access to the Premium API with just a $50 monthly subscription.  Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Create your own blockchain: A guide to Appchains and how to deploy them on Chainstack As we venture deeper into the world of Web3, the need for effective solutions to handle network resources is more significant than ever before. With the increase in users and transactions, networks often struggle with lowered performance and escalated transaction fees. If you’ve ever faced an expensive or failed transaction during a popular NFT drop or on a DEX during a bullish market, you’d relate to this issue. Modern problems require modern solutions—and Appchains aim to be just that. Developed as a counteractive measure to the limitations of using a public blockchain as the base layer for decentralized applications, Appchains offer dedicated chains for DApps. They are becoming a vital element that could propel us to the next stage of Web3 adoption. And, at Chainstack, we could not be more excited to provide you with the infrastructure to BUIDL on them effectively. Rise of Appchains in Web3 development As Web3 draws more users globally, blockchain developers increasingly need an ever more efficient way to create applications that will influence our digital future. However, without developer-friendly tools and infrastructure for their projects, many revolutionary Web3 ideas might never see the light of day. To accomplish this, developers like you need specialized resources to harness their creativity fully and create innovative solutions. Appchains are a substantial step forward in Web3. They allow you to build and scale DApps on application-specific blockchains. This fundamental shift means that each DApp can operate as its own specialized chain, providing a robust foundation with improved security, scalability, and in some cases, interoperability with other established infrastructure. Transactions on Appchains are processed out of their individual mempool, and gas fees can be as low or as high as you consider suitable. These factors enable Appchains to process transactions much faster than any Layer 1 can. With these speed and cost advantages, DApps built on Appchains are well-positioned to attract the next wave of Web3 users. On their own, Appchains already offer a powerful platform for decentralized applications, providing them with dedicated resources that maximize efficiency and performance. This means no more fighting over shared computational or storage resources on the network—freeing you up to focus solely on creating exceptional Web3 experiences. What are Appchains? Appchains are more than just add-ons to an existing blockchain; they are application-specific blockchains designed to perfectly suit the needs of a specific DApp. These chains are also Layer-2 solutions, acting as a secondary framework on top of an existing blockchain—Layer 1—to boost transaction capabilities and decrease latency. Each Appchain operates independently, which significantly isolates risk—an issue on one Appchain will not affect others. Moreover, Appchains can adapt their security model, accommodating application-specific assets and logic. This high degree of modularity gives you as a developer a grand canvas to design, fostering innovation and expansion in Web3. Another substantial benefit is that these Appchains can share consensus—security is pooled and network effects are captured. This ‘shared security’ model is a distinctive feature of Appchains that allows multiple chains to run in parallel without compromising the security of the entire system. Essentially, the benefits of using Appchains over traditional blockchains are multifold—scalability, lower fees, customization, and more. Appchains are on their way to taking Web3 applications to the next level of evolution, as they provide the perfect combination of traditional blockchains’ trustless nature with boosted efficiency and application-specific customization. Appchain architecture Essentially, an Appchain is a specialized layer of architecture where each application runs on its own dedicated blockchain, consensus algorithm, data models, network protocol, and more. It uses modular architecture, meaning you can select from a diverse set of existing modules while creating your Appchain, or design and implement one that matches your unique use case yourself. How do Appchains differ from smart contract platforms like Ethereum? In essence, the architecture of Appchains sets them apart from traditional smart-contract platforms. The difference lies in flexibility and efficiency—Appchains are more runtime-flexible and efficient because they can choose their architecture and rulesets. And speaking about Appchain architecture, let’s break it down into its five core layers: Network layer: This layer determines the network protocol that communicates with the nodes, setting the foundation of the Appchain. Data layer: An important layer that defines all transactional data standards and structures. Consensus layer: Decides the consensus algorithm for the Appchain, instrumental for ensuring the reliability of the network. Application layer: This layer represents the application-specific code that runs on the Appchain. It includes both the front-end user-facing software and back-end processes. Smart contract layer: This optional layer allows developers to deploy smart contracts on their Appchain, taking advantage of programmable blockchain functionalities. With Appchains, you’re not limited by the constraints of the base-layer blockchain. Instead, you can devise an architecture that’s optimally designed for your application, giving you unprecedented flexibility and control over your DApps. Figure 1: The architecture of an appchain; Source: Chainstack Appchain advantages The rapid rise of Appchains comes from their ability to solve the critical challenges that have slowed the mass adoption of blockchain technology—scalability, fees, and customization: Scalability: Appchains operate individual chains for each application, avoiding the resource competition seen in traditional L1 chains and enabling independent scaling. Flexible fees: You can set custom transaction fees in Appchains, offering predictability and potentially lower costs that benefit users. Modularity: Appchains provide you with the flexibility to customize your blockchain’s features, including the base protocol, consensus algorithm, network architecture, and more. Security and privacy: Offering dedicated blockchains for each application, Appchains improve security and privacy through industry-standard protocols and modular design to mitigate risks. Fundamentally, Appchains help us envision a future where each application can exist in its perfect environment. This ecosystem’s optimization paves the way for the broader adoption of blockchain applications, as more developers have the necessary tools to create excellent user experiences. Create your own blockchain with Avalanche Subnets on Chainstack As we delve deeper into the world of Appchains, one technology making a lot of waves is Avalanche Subnets. Subnets are a unique feature of Avalanche that enables you to create your customized blockchain. This powerful feature provides significant flexibility and control, whereby you can enforce specific virtual machines, validation schemes, and incentive structures per Subnet. A Subnet consists of a subset of Avalanche validators achieving consensus on one or more blockchains. Each blockchain is validated by a unique Subnet, but a Subnet can validate multiple blockchains. The Avalanche Primary Network, a special Subnet, runs three main blockchains: the Platform Chain (P-Chain), the Contract Chain (C-Chain), and the Exchange Chain (X-Chain). Advantages of Avalanche Subnets Independent networks: Subnets offer customizable execution logic, fee structures, and security, with performance unaffected by other Subnets’ activity. Native interoperability: Enabled by Avalanche Warp Messaging, Subnets are interoperable by default, which allows for seamless cross-chain communication between Subnets. Application-specific customization: Subnet validators can be obliged to meet certain hardware requirements before they are able to validate a Subnet to maintain its optimal performance. Compliance and privacy: Subnets support setting compliance and privacy policies for geo, license, and KYC/AML filtering, as well as private Subnets visible only to approved validators. Validator sovereignty: In a heterogeneous network of chains validators can pick only the Subnets they are interested in validating, significantly reducing their computational load. Create your own blockchain with Avalanche Subnets on Chainstack: Customize your Subnet chain config Customize your Subnet with blockchain configuration parameters to define the operational limits and economic model of your Subnet. These parameters control aspects such as block production rate, transaction costs, and gas consumption, allowing for a tailored blockchain environment. Here’s a list of what’s available for you to tweak: gasLimit: Defines the maximum amount of gas consumed per block, limiting computation per block and maximum gas usage for a single transaction. targetBlockRate: Determines the desired rate of block production in seconds, influencing block issuance and base fees. minBaseFee: Establishes a floor on the EIP-1559 base fee of a block, effectively setting a minimum transaction gas price. targetGas: Targets a specific amount of gas to be consumed within a 10-second window, adjusting base fees based on actual network activity. baseFeeChangeDenominator: Modulates the base fee adjustment rate, with larger values indicating slower changes and smaller values allowing quicker fee adjustments. minBlockGasCost: Sets the minimum gas charge for producing a block, with the C-Chain typically setting this to 0. maxBlockGasCost: Caps the gas charge for block production. blockGasCostStep: Adjusts the block gas cost based on the time elapsed since the previous block, increasing or decreasing gas costs relative to the target block rate. Avalanche Subnets provide a flexible and scalable solution for deploying bespoke blockchain networks, offering privacy, interoperability, and customization to meet diverse application needs. Create your own blockchain with Avalanche Subnets on Chainstack: Deploy an Avalanche Subnet on Chainstack Creating an Avalanche Subnet with Chainstack is quite straightforward. Here’s how you can do it: Sign up on the Chainstack console to access the deployment and management tools. Create a new project in the Chainstack console, open it, and then click “Join Network.” In the node deployment wizard, pick “Avalanche” and “Testnet” or “Mainnet.” Fill in your “Node name,” then click on “Advanced,“ when it comes to “Configuration,” then select “Dedicated,” as your node type, as well as your preferred cloud provider and location. Confirm your settings in the final step of the wizard to deploy your dedicated Avalanche node. Stand by as your node is being deployed, and Voila! Your Avalanche subnet is ready to launch! Deploying your Avalanche Subnet with Chainstack takes just a few clicks, and with that, you open the doors to a completely customized and controlled blockchain platform. Don’t know how to set your Subnet up? Be sure to check out our tutorial on “Creating an Avalanche Subnet and a blockchain,” or simply ask Support for help! Create your own blockchain with Avalanche Subnets on Chainstack: Secure validator stake funding for your Avalanche Subnets with Benqi Ignite When it comes to validators and the stake required to deploy your Avalanche Subnets, Chainstack and the Benqi Ignite program play pivotal roles. We simplify the validator deployment process, allowing you to launch your Avalanche Subnets validators with just a simple click. Meanwhile, the Benqi Ignite program is designed to supply you with the necessary staking collateral to launch your Subnets. The program offers a much more cost-effective and accessible solution, via validator stake rentals, than the traditional approach, which asks for a significant upfront financial commitment. Understanding that these costs might be prohibitive for many, we are excited to support the Benqi Ignite program in lowering the entry barriers for emerging Web3 developers and innovators eager to step into the world of Appchains by deploying their very own Avalanche Subnets. Secure validator stake funding for your Avalanche Subnets with Benqi Ignite: Get started Access public Subnets and run validator nodes on Chainstack Stepping into the world of Appchains with Avalanche Subnets opens up a variety of opportunities. Chainstack helps you access not only your Subnet but also the public Subnets on Avalanche, opening up a number of potential blockchain solutions to explore. Our platform provides a user-friendly interface for accessing public Subnets, which enables you to: Connect to public RPC nodes: We provide a list of active nodes in the public Subnet. You can connect to any one of these nodes to interact with the subnet. Monitor network health: Our console’s dashboard provides valuable information about the health of the node to which you’re connected, like node status, recent block creation, and more. Beyond connecting to public Subnets, we also provide tools for running validator nodes: Become a validator: You can choose to become a validator, whose role is to confirm transactions into blocks, maintaining the security and efficacy of the network. Detailed validator information: You can find a detailed overview of the validator’s working set, rewards, and more in the console’s node details screen. Manage validator nodes: You can start, pause, resume your nodes, upgrade them, and more. With Chainstack, you have all you need to harness the power of Avalanche Subnets. Create your own blockchain with Avalanche Subnets on Chainstack: Index and query Avalanche Subnets with Dedicated Subgraphs They say data is the new oil and Appchains aren’t falling behind on this either.. This does bring up a very valid question too—How can you explore vast amounts of Avalanche Subnets data effectively? And this is where Dedicated Subgraphs come in! By providing a powerful, reliable, and easy-to-use solution for indexing and querying smart contract data, Dedicated Subgraphs enables you to harness the full capabilities of your Avalanche Subnets, by enabling up-to-date information of on-chain activity. In turn, you can then use such data for a variety of use cases, ranging from DeFi and GameFi to research and DApp analytics. For example, asset prices, liquidity pools, and transaction volumes would serve DeFi Subnets well, whereas, in GameFi, you’d be tracking in-game transactions, NFT trades, and player achievements. In the former, you’re making use of real-time data to unlock portfolio tracking and trading insights, as brand-new feature sets, while in the latter—realistic in-game economies and player leaderboards. Whether you’re looking to develop sophisticated DeFi platforms, immersive player-driven worlds, or any other application on Avalanche Subnets, Dedicated Subgraphs offers you the means to do just that. And do that with both the confidence and speed that comes with 99.9% Subgraphs availability and 2X faster indexing than the competition. Deploy Dedicated Subgraphs for your Avalanche Subnets: Get started Launch your own zkEVM network with Polygon CDK on Chainstack After exploring the exciting capabilities of Avalanche Subnets, let’s switch gears and delve into another revolutionary technology—Polygon CDK chains. The Polygon CDK is a versatile, open-source toolkit designed to simplify the creation and customization of blockchain architectures. It enables developers to launch new Layer L2 chains on Ethereum and provides the framework for transitioning existing L1 chains to L2 solutions. The CDK supports a range of open-source components for customizing chain architectures, including ZK rollups that directly post transaction data on Ethereum and Validiums that post only the transaction hash. “ZK” refers to “Zero-Knowledge”, a branch of cryptography that enables one party to prove they know a piece of information without revealing that information, whereas “zkEVM,” is a virtual machine that is compatible with both Ethereum architecture and ZK-proof computations. zkEVM networks, like the ones you can deploy via the Polygon CDK, leverage this technology to enhance transaction efficiency and interoperability. Launch your own zkEVM network with Polygon CDK on Chainstack: Get started Advantages of Polygon CDK chains Modular design: Polygon CDK chains provide a flexible framework for ZK-powered L2 development, allowing for precise chain customization according to project specifications. Scalable architecture: Designed for enhanced transaction speeds, CDK chains support scalable solutions that cater to growing transaction demands without compromising performance. Dedicated data reliability: With its own data availability layer, CDK chains ensure reliable and independent off-chain data access, enhancing data integrity and resilience. Future-proof interoperability: An upcoming interoperability layer promises seamless L2 to L2 transactions, making CDK chains an integral part of a unified liquidity ecosystem. Rapid transaction finality: Leveraging cryptographic security, CDK chains achieve near-instant transaction finality, ensuring robust security without the reliance on full nodes. Extensive ecosystem support: CDK chains benefit from a wide range of development, integration, and deployment tools provided by leading service providers in their ecosystem. Polygon CDK stands at the forefront of Layer 2 blockchain development, providing developers with the tools needed to build scalable, secure, and interoperable blockchain solutions tailored to their specific requirements. Launch your own zkEVM network with Polygon CDK on Chainstack: Get started Customize your Polygon CDK chain config Customize your Polygon CDK chain with blockchain configuration parameters to set its functional boundaries and economic framework. These settings govern key elements like the rate of block creation, transaction fees, and gas usage, enabling you to customize the blockchain to your specific requirements. Below is a selection of parameters you have the flexibility to adjust: maxFeePerGas: Dictates the upper limit of fees per gas unit that transactions can incur, serving as a cap on transaction costs. maxPriorityFeePerGas: Specifies the highest priority fee per gas unit, directing validators to the premium for faster transaction processing. multiplierGas: Modifies gas prices via a multiplier, enabling adjustment of transaction fees in response to network conditions. minDelayTimelock: Determines the minimum waiting period, in seconds, that the timelock contract enforces before execution of actions. trustedAggregatorTimeout: Sets the deadline, in seconds, for the trusted aggregator to submit data, influencing network operations. pendingStateTimeout: Establishes the period, in seconds, after which a pending state is deemed outdated, affecting transaction finality. Polygon CDK chains offer a versatile and expandable platform for creating unique blockchain networks, ensuring confidentiality, seamless interaction between different systems, and adaptability for a wide range of applications. Launch your own zkEVM network with Polygon CDK on Chainstack: Get started Deploy a Polygon CDK chain on Chainstack So, how do you launch a Polygon CDK chain on Chainstack? Register on the Chainstack console for access to deployment and management features. Start a new project within the Chainstack console, navigate to it, and select “Join Network.” Use the node deployment wizard to choose “Polygon” followed by “Testnet” or “Mainnet.” Enter a “Node name,” proceed to “Advanced” under “Configuration,” and opt for “Dedicated” as your node type. Also, pick your preferred cloud service and location. Review and confirm your configuration in the wizard’s final step to initiate your dedicated Polygon node deployment. Await your node deployment. Congratulations! Your Polygon CDK chain is set for activation! Launching your Polygon CDK chain via Chainstack is a straightforward process, enabling immediate access to a fully customizable and autonomously governed blockchain network. Launch your own zkEVM network with Polygon CDK on Chainstack: Get started Build your own modular chain with zkSync Hyperchains on Chainstack zkSync Hyperchains are part of the ZK Stack, a flexible and highly modular open-source framework for creating sovereign ZK-powered Ethereum rollups. This innovative approach allows for the development of custom L2 and L3 Hyperchains, drawing on zkSync Era’s foundational code. It emphasizes sovereignty and seamless connectivity, enabling creators’ full customization rights and the ability to interlink chains through Hyperbridges for trustless and efficient interoperability. Advantages of zkSync Hyperchains Enjoy flat transaction fees, irrespective of gas price fluctuations. Benefit from default privacy settings across transactions. Access cost-effective oracles and other high-frequency protocols. Utilize ultra-low-cost Validium accounts for efficiency. Get free zkSync ETH from the Chainstack Faucet! Build your own modular blockchain with zkSync Hyperchains on Chainstack: Get started Customize your zkSync Hyperchains chain config Chain mode: Choose from rollup, Validium, or Volition configurations to suit your needs. Layer: Deploy as either a Layer 2 or Layer 3 blockchain. giving you greater use case flexibility. Transaction sequencing: Opt for centralized, decentralized, or shared sequencing methods to balance between latency, security, and decentralization, with the option to employ external protocols for additional customization. Data availability: Leverage Ethereum’s ZK-rollup for secure and censorship-resistant data availability, or explore third-party options like zkPorter for economical transactions, Validium for auditability and privacy, and various ZK-rollup policies for application-specific requirements. Data visibility: Set your zkSync Hyperchains as public or private, with Validium mode offering out-of-the-box privacy for enterprise, and specialized L3 privacy protocols for user-level privacy. Gas token: Choose between using Ether, operating gaslessly, or integrating a custom gas token, providing flexibility in transaction fee management. zkSync Hyperchains represent a paradigm shift in blockchain development, offering unparalleled customization, scalability, and privacy options. This makes them an ideal platform for developers looking to build innovative, efficient, and secure blockchain solutions. Build your own modular blockchain with zkSync Hyperchains on Chainstack: Get started Deploy a zkSync Hyperchain on Chainstack Building and managing your own zkSync Hyperchains on Chainstack is just a few steps away: Access the Chainstack console by signing up to access the deployment and management tools. Create and enter a new project on the Chainstack console, then click on “Join Network.” In the node deployment wizard, select “zkSync” and then decide between “Testnet” or “Mainnet.” Fill in your “Node name,” move to “Advanced” under “Configuration,” and choose “Dedicated” for your node type, including your desired cloud provider and location. Finalize your setup in the last step of the wizard to begin deploying your dedicated zkSync node. Await the deployment of your node. Your zkSync Hyperchain is now ready for its debut! Chainstack puts you in control—build, launch, and manage zkSync Hyperchains for a tailor-made, efficient Layer 2 blockchain solution. Build your own modular blockchain with zkSync Hyperchains on Chainstack: Get started Deploy your own L3 protocol with Starknet Appchains on Chainstack Are you looking to break free from the limitations of Layer 1 chains or the restrictions of Ethereum’s contract functionality? This exciting journey can commence with Starknet Appchains, and managing this sophisticated technology becomes seamless with Chainstack. Starknet Appchains are dedicated blockchains crafted to meet the specific needs of an application. Powered by ZK-STARKs, they utilize advanced cryptographic proofs and algebra to safeguard the integrity and privacy of blockchain computations, much like the Starknet mainnet does. Such chains allow for extensive customization, including unique hash functions and consensus mechanisms, all the while inheriting the robust security features of their foundational L1 or L2 networks. Deploy your own L3 protocol with Starknet Appchains on Chainstack: Get started Advantages of Starknet Appchains Rapid development: Appchains facilitate quick protocol updates, enabling developers to roll out new features, without being tied down by the broader public L2 development timeline. Autonomous governance: Retain full authority over your Appchain’s development path, enabling swift integration of new features without the need for governance consensus. Cost-effective operations: Operating on L3, Appchains significantly reduce operational costs—by up to 1M times compared to L1—making complex applications more economically viable. Balanced security: Despite some compromises, like lesser censorship resistance, the fundamental security features of Appchains remain intact and reliable. Network congestion mitigation: Appchains are protected from the main network’s congestion, ensuring stable and predictable transaction environments, ideal for real-time processing. Privacy advancements: Serving as a platform for privacy-focused innovations, L3 Appchains can implement such policies as anonymous transactions or encrypted messaging solutions. Innovation sandbox: Appcchains offer a testing ground for experimenting with groundbreaking features or consensus models, potentially influencing broader Layer 2 advancements. All-in-all, Starknet Appchains provide a versatile, cost-efficient, and secure platform for innovation, presenting an ideal balance between flexibility and foundational blockchain security. Deploy your own L3 protocol with Starknet Appchains on Chainstack: Get started Customize your Starknet Appchain chain config Transaction fees: Enable or disable transaction fees through the DisableTransactionFee parameter, where True is cost-free, while False retains the standard fees. Nonce validation: Enable or disable transaction order and security by validating the nonce, using the DisableNonceValidation parameter, in order to safeguard against replay attacks. Transaction execution limits: Set the complexity of transactions that can be executed, where the InvokeTxMaxNSteps parameter caps the number of steps for transaction invocation, while ValidateMaxNSteps , the validation steps, optimizing performance and preventing abuse. Deploy a Starknet Appchain on Chainstack Starknet provides you with a Layer 2 capacity to build your standalone Appchain, removing existing limitations, and providing complete sovereignty, security, privacy, and scalability to your DApps. Let’s look into the steps to deploy Starknet Appchains on Chainstack: Sign up via the Chainstack console to unlock deployment and administrative capabilities. In the Chainstack console, create a new project, access it, and hit “Join Network.” Within the node deployment wizard, select “Starknet” along with either “Testnet” or “Mainnet.” Specify your “Node name,” then navigate to “Advanced” in “Configuration,” choosing “Dedicated” for your node type, and selecting your cloud provider and location preference. Validate your choices in the wizard’s concluding step to deploy your dedicated Starknet node. Patiently wait as your node is deployed. And there you have it! Your Starknet Appchain is prepared for launch! Starknet Appchains running on Chainstack can bring vast improvements to the scalability, privacy, and security of your blockchain ventures. Alongside, Chainstack ensures a simple interface and robust infrastructure to run everything smoothly. Deploy your own L3 protocol with Starknet Appchains on Chainstack: Get started Bringing it all together As we explore new avenues in the world of Web3, our role at Chainstack is to empower developers, innovators, and creators to leverage the power of decentralized networks. The advent of Appchains reflects a significant shift in blockchain protocols. Instead of adhering to the ‘one-size-fits-all’ design of traditional blockchain networks, Appchains allow developers to utilize application-specific chains. By working with Appchains, we offer applications an optimal environment for operation. This leads to enhanced performance, a seamless user experience, and a more robust protocol. With Chainstack’s user-friendly console and powerful in-built tools, deploying and managing your appchain has become more efficient and streamlined. Our interface simplifies every stage of the Appchain deployment process—from inception to management. Whether you’re deploying Avalanche Subnets, operating zkSync Hyperchains, or any other Layer 2 solution, we, at Chainstack, provide you the control to create, customize, and manage your networks tailored to suit your application’s unique requirements. Revolution begins with a single step. Take that leap today into the world of Appchains by starting your next project. Join us at Chainstack as we build the future of Web3 together! As we conclude, we at Chainstack want to thank you for your interest in Appchains and our role in supporting their deployment. You now have a solid foundation to kickstart your journey into the world of appchains. Remember, we’re always here to help. Let’s create the future, together. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Creating a public blockchain node with Chainstack Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Introduction Chainstack is the leading suite of services connecting developers with Web3 infrastructure, powering applications in DeFi, NFT, gaming, analytics, and everything in between. We provide you with highly scalable infrastructure and solutions that allow you to scale your DApp quickly without having to worry about handling all the traffic to and from the blockchain network. In this short tutorial, you will learn how to quickly create a blockchain node with Chainstack in less than 5 minutes. Signing up First, you need to create an account with Chainstack if you don’t already have one. Go to the Chainstack console page to create a new account. Chainstack Console Fill out all the required details and sign up. You will see a pricing panel on the right side. Choose whatever plan best fits your needs. You will be required to enter the details of a credit/debit card, but don’t worry, you won’t be charged if you sign up for a developer plan. Our developer plan allows you to send 3 million free requests per month to the blockchain through your exclusive Chainstack endpoints. This means you can give our services a good try before having to spend your money. You can find more details about our pricing on our website. We also have a usage cost calculator on our pricing page that allows you to look at your expenses as per your subscribed plan and usage. After this, you will receive a confirmation mail at your registered email address. Click on the link to verify your account, and you are now ready to create your first project. Creating a new project Once you log in to your Chainstack account, you will see an empty dashboard. Click on the Get started button to create your first project. Chainstack allows you to create two types of projects: A public blockchain project which allows you to connect to all the major blockchains like Ethereum, Polygon, and Binance Smart Chain. These are all the public blockchains that are available to everyone with an internet connection. A consortium project which allows you to deploy blockchain nodes to semi-private networks like Hyperledger Fabric or Corda, which typically focus on private transactions, and are not permissionless. For this tutorial, we will create a public chain project. Give your project a name, and a description if you so wish, and then click on Create. Creating a new project Click on your new project in the dashboard. You are now ready to join a blockchain network. Joining a network Once inside a project, click on Get started. Let us first choose the network we want to connect to. Chainstack supports more than a dozen major public blockchains, along with their corresponding testnets. You can read more about the supported protocols from our docs. For this tutorial, we will be deploying a node to the Polygon mainnet. Joining a Network Click on Next. This will take you to the node deployment window where you can configure the exact features you want out of your node. Let us look at all the options we have here: Configuring the Node Elastic nodes vs dedicated nodes An elastic node allows you to access a very fast, highly scalable blockchain node through your exclusive Chainstack endpoints. A dedicated node on the other hand is a new node deployed to the blockchain that is exclusive to you. Nobody else has the credentials to access your dedicated node. Full nodes vs archive nodes A blockchain network is basically a sequential production of new blocks. All of those blocks have their own data, and to query the data of older blocks, you need an archive of their historical states. A full node stores the data of the recent states, meaning you can easily query the data of these latest blocks in your application. If you need to query data older than this though, you need an archive node that will allow you to query data right up to the genesis block. Warp transactions We have partnered with bloXroute to offer Warp transactions to our users. A warp transaction is like any other transaction, except that it is distributed to the entire network through bloXroute’s high-speed relay network. This will allow your transactions to be picked up by the validators much more quickly when it really counts. Hosting Chainstack gives you many options to configure your node deployment. You can either choose one of the many cloud providers we offer across multiple regions, or you can opt into privately hosting your node. Private hosting is however available only with our Business/Enterprise plans, and you need to get in touch with us so that we can offer you the engineering help you will need to host your own node privately. Scroll to the bottom and give your node a name. Click Next. Create a blockchain node with Chainstack The summary window will show you all the configurations of the node you are about to deploy on a single page. Here is how it looks for me. Node Summary Verify everything and click on Join network. Your node may take a few moments to deploy. Once that is done, click on your now running node to view your exclusive endpoints, as well as your node’s running history. Node Dashboard Our node dashboard shows you the node’s entire performance history, along with a detailed chart. You can view your access credentials by scrolling to the bottom of the page. Check out our blog to learn how to use these credentials to create some cool projects. Conclusion The idea of this article was to show our users how they can quickly get up and running with a highly scalable blockchain node with Chainstack. We are continuously working on bringing support for more and more protocols and extending the scope of our services for our users. Feel free to go through our docs, or to reach out to us. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Crouton Finance: How Chainstack empowers TON DeFi pioneers Chainstack’s infrastructure has proven to be a solid foundation for our DeFi solutions on TON. Their support and reliability allow us to focus on what we do best—developing exceptional financial products that advance the ecosystem and serve our community. The Crouton Finance Team In the sprawling decentralized finance landscape of TON, we embarked on a remarkable journey with Crouton Finance—a formidable player advancing DeFi infrastructure innovation. Acting as a lynchpin, Crouton Finance introduces a high-performing decentralized exchange and a versatile synthetic assets protocol. As developers yourself, you’re familiar with the pain points of inefficient trade mechanisms and the challenges that synthetic assets pose. Crouton Finance addresses this by offering a cutting-edge decentralized exchange platform and a unique synthetic assets protocol on the TON blockchain—all backed by robust, scalable, and dependable Chainstack infrastructure. Let’s explore the details of our journey with Crouton Finance! How Crouton Finance started with Chainstack From our first discussions with Crouton Finance, their ambition was clear: they envisioned revolutionizing the TON DeFi landscape through an efficient DEX and a unique synthetic assets protocol. To achieve this, they were on the lookout for a strategic infrastructure partner who could provide reliable, high-performance RPC services capable of managing the demands of their DEX and synthetic assets offerings. It was immediately evident that Chainstack could meet these requirements head-on. We offered Crouton Finance not just a dependable RPC provider, but an ally committed to supporting their goals of advanced DeFi solutions on TON. The initial pain points of Crouton Finance revolved around high price impacts witnessed on trades through other DEX platforms such as StonFi or DeDust, and a lack of robust infrastructure to support synthetic assets effectively. They needed a partner who could deliver high-frequency, low-latency trading, and seamless interactions with the TON Network—exactly where we came in. Our high-performance RPC services met their demands for robust uptime and low-latency transactions and our seamless integration with the TON ecosystem offered support for both real-time and historic data queries. From the word go, our partnership with Crouton Finance was built on shared visions and mutual dedication. With our services facilitating real-time, low-latency interactions with the TON blockchain, Crouton Finance was able to focus on delivering its innovative trading and synthetic assets offerings on TON. What is Crouton Finance? Crouton Finance, in essence, serves as a pivotal DeFi cornerstone within the TON landscape. At Chainstack, we’ve had the privilege of glimpsing the transformative work they’ve spearheaded firsthand. Their acute focus on crafting a powerful decentralized exchange coupled with a sophisticated synthetic assets protocol has been nothing short of inspiring. Their goal? To fuel the area of crypto asset trading with heightened effectiveness. The inception of Crouton Finance has been marked by a clear yet grand vision—sketching a financial ecosystem on the TON blockchain that presents its traders with enticing, seamless opportunities. The feathers in their cap extend from facilitating competent stablecoin and volatile assets trading with minimum price impact—a rarity in conventional AMM DEXs—to aiding the issuance of synthetic assets, such as BTC and USD, on the TON Network. Remember those instances where swapping 1000 TON to stTON via StonFi or DeDust resulted in substantial price impact? That’s precisely what Crouton Finance has set out to rectify—with their optimized AMM formula, reminiscent of Curve.fi’s strategy, they’ve considerably reduced trading friction. So, what exactly does Crouton Finance offer to TON traders? Three key things: Trading efficiency: Traders can engage with stablecoins and volatile assets through the platform, experiencing extremely low price impacts compared to traditional AMM DEXs. This efficiency is game-changing for traders who no longer have to worry about high price impacts that eat into trading profits. Synthetic asset trading: In addition to the trading of stablecoins, traders can also issue and trade synthetic assets like BTC and USD, as well as other derivatives on the TON blockchain. This ability to access non-native assets on TON broadens the horizons of what’s possible within the ecosystem. High Annual Percentage Rates (APRs): Traders have the chance to maximize their returns through Crouton Finance’s high APR offerings. This feature stands as a testament to Crouton’s commitment to rewarding its user base. Why does this matter? For traders, every transaction matters. Even minor price impacts can stack up to significant losses. By tackling this issue head-on, Crouton is filling a significant gap in the TON DeFi ecosystem. Not only does their optimized AMM formula address this, but they’re also expanding the ecosystem by bringing synthetic BTC, ETH, and other non-native assets, enhancing its overall offering and appeal. Simply put, through a combination of its synthetic assets protocol, refined tokenomics, and an efficient AMM model, Crouton Finance offers attractive opportunities for traders, liquidity providers, token holders, and indeed, the entire TON ecosystem. And given the impressive quality of their solutions, we couldn’t resist the opportunity to support Crouton Finance in its mission, thus beginning our journey as partners in this dynamic space. Partnering with Crouton Finance has been a thrilling journey for us at Chainstack. Their innovative approach to DeFi on TON pushes the boundaries of what’s possible, and we’re proud our infrastructure supports their vision for a seamless, high-performance crypto trading experience. Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together At Chainstack, we understand the challenges faced by Web3 projects such as Crouton Finance, particularly in the decentralized finance realm. Focusing on these, we offer solutions tailored to ensure our partners’ success. Our collaboration with Crouton Finance is a shining example of that commitment. By providing them with infrastructure that ensures robust uptime, low latency, and reliable handling of complex transactions, Crouton Finance has been able to leverage their innovative TON trading and synthetic assets protocol. Crucially, this pair-up has provided traders with a smoother trading experience and access to synthetic assets like BTC, USD, and other derivatives on the TON Network. As such, traders can enjoy efficient trades and be rewarded with high APRs for their efforts—a win for them and the TON DeFi community. In the vast and rapidly evolving DeFi landscape, collaborations like ours with Crouton Finance excite us. We are proud to play our part in their journey, supporting their mission of revolutionizing TON’s DeFi infrastructure. Remember, as a Web3 developer or DeFi enthusiast, having the right infrastructure in place is the foundation you need for success. And we, at Chainstack, are ready to provide the support and solutions you need to make your DeFi journey an impactful one. Get started building on TON with Chainstack today! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Crypto Wallets 101: Hot wallets vs. cold wallets explained Navigating the vast and complex realm of hot and cold crypto wallets can be daunting, with infinite options and each boasting distinct features. Our in-depth article is designed to unravel the complexities surrounding hot and cold wallets, equipping you with the knowledge to make a well-informed decision to safeguard your precious crypto. By comprehending these essential aspects, you can fine-tune your crypto wallet selection based on your specific investment approach, risk appetite, and long-term financial objectives. Grasping the fundamental principles underpinning the hot wallets vs. cold wallets debate is vital, as it will dictate the optimal crypto wallet choice for your specific use case. Our guide will empower you to securely and confidently traverse the ever-evolving landscape of cryptocurrencies. So, without further ado, let’s dive in! What are hot wallets? Hot wallets are any blockchain wallet that connects to the internet and runs as software on your computer or mobile phone. They are a popular choice for managing and accessing cryptocurrencies, as they provide the convenience of constantly being connected to the internet. They give you quick and easy access to your crypto assets at the expense of potentially exposing your private keys to hackers if you are not careful. There are several types of hot wallets, including: Web wallets Accessible through browser plugins or directly on a website, centralized cryptocurrency exchanges (CEXs) such as Binance offer custodial wallets as a hassle-free way of storing multiple cryptocurrencies. Your private keys are entirely hosted on their remote servers, ensuring a more user-friendly experience but placing the security of these keys solely in the hands of the CEX. However, web wallets such as Argent are non-custodial, storing your private keys directly on your hard drive, usually in your browser’s database. Mobile wallets As the name suggests, mobile wallets are smartphone applications that store your private keys on your mobile device. They offer the convenience of managing and accessing your cryptocurrencies on the go but can be vulnerable if your device is compromised. Trust Wallet is an excellent example of a mobile-centric wallet that supports multiple cryptocurrencies and provides an intuitive user interface. Desktop wallets Desktop wallets are software applications installed on your personal computer. They store your private keys on your local hard drive or an encrypted file, providing easy access while your computer is online. However, they can be vulnerable to malware or hacking if your computer’s security is compromised. Exodus is a well-known desktop wallet that offers a user-friendly interface and supports a wide range of crypto. Pros of hot wallets 1. Convenience – Hot wallets are easily accessible, allowing users to quickly access and manage their cryptocurrencies without going through additional steps or hardware. 2. User-friendly – They often feature intuitive interfaces, making them suitable for beginners and those looking for a simple way to manage their digital assets. 3. Suitable for small amounts – Hot wallets are ideal for storing small amounts of cryptocurrencies that you frequently use for daily transactions or trading. Cons of hot wallets 1. Vulnerability to cyberattacks – As hot wallets are connected to the internet, they are susceptible to hacking, malware, and phishing attacks, which can compromise the security of your private keys and, ultimately, your digital assets. 2. Dependence on third-party security – In the case of custodial web wallets, users rely on the security measures implemented by the service provider, which can vary in effectiveness and quality. Hot wallets are a convenient and user-friendly option for managing cryptocurrencies but come with inherent security risks due to their constant connection to the internet. It is essential to consider these risks carefully when deciding between a custodial or a non-custodial hot wallet to store your digital assets. What are cold wallets? Cold wallets are a more secure alternative to hot wallets for storing private keys, as they keep your digital assets offline and away from potential online threats. They are offline storage solutions that keep your private keys disconnected from the internet, minimizing the risk of hacking, malware, and phishing attacks. There are several types of cold wallets, including: Hardware wallets These are dedicated physical devices, often resembling USB drives, specifically designed to store private keys securely. They employ advanced security features and encryption methods to protect your digital assets, and they only connect to a computer or mobile device when needed for transactions. Some popular hardware wallets include Ledger, Trezor, and KeepKey. Paper wallets Paper wallets are physical documents containing your private keys, either printed as plain text or as QR codes. While low-tech, they offer a simple and cost-effective method for keeping your private keys offline, provided that the paper wallet is stored securely. Pros of cold wallets 1. Enhanced Security – By keeping your private keys offline, cold wallets provide a higher level of security against online threats such as hacking, malware, and phishing attacks. 2. Greater Control – Cold wallets, mainly hardware wallets, give you complete control over your private keys without relying on third-party services for security. 3. Ideal for Long-Term Storage – Cold wallets are well-suited for storing large amounts of cryptocurrencies you don’t need to access frequently, making them a better choice for long-term investments. Cons of cold wallets 1. Less Convenience – They can be less convenient for frequent transactions, as they require connecting a hardware wallet to a device or scanning a paper wallet’s QR code to access your assets. 2. Physical Security Concerns – Cold wallets, especially paper ones, require secure physical storage to prevent theft, damage, or loss. This may involve using a safe deposit box or other secure storage methods. 3. Higher Initial Cost – Hardware wallets can be more expensive than hot wallet solutions due to the specialized hardware and technology involved. However, this cost can be justified by the increased security provided. Cold wallets offer a more secure way to store private keys and protect digital assets, particularly for long-term storage and more significant amounts of cryptocurrencies. While they may be less convenient for frequent transactions, the enhanced security, and control they provide make them an essential consideration for anyone serious about the safety of their digital wealth. Closing thoughts The choice between hot and cold wallets ultimately depends on your specific needs, preferences, and, most importantly, your level of risk tolerance. Hot wallets offer convenience and ease of use, making them a good option for smaller amounts of crypto and frequent transactions. However, they come with a much higher vulnerability to online threats. On the other hand, cold wallets provide enhanced security and control for long-term hodling, especially for whales, as they hoard substantial amounts of cryptocurrency. Understanding the pros and cons of each wallet type is essential to selecting the most suitable storage solution for your crypto assets. Now that we’ve gone over the hot wallets vs. cold wallets dilemma, remember that the best strategy often involves a combination of hot and cold wallets to balance convenience, accessibility, and security. Stay informed about industry news, be vigilant, and always prioritize safety when handling crypto. FAQ Is Coinbase a hot or cold wallet? Although Coinbase is primarily a centralized cryptocurrency exchange, it also offers a non-custodial blockchain wallet to store and manage cryptocurrencies. Since Coinbase’s wallet is accessed over the internet using a browser or mobile app, it is considered a hot wallet. Are hot wallets risky? Hot wallets are riskier compared to cold wallets because they are constantly online. This connection makes them more susceptible to hacking, malware, and crypto phishing attacks. However, if you take the necessary security precautions and only store small amounts of cryptocurrencies for frequent transactions, hot wallets are still a good choice. Is MetaMask a hot or cold wallet? MetaMask is defacto a hot wallet, as it is a browser extension that allows you to access and manage your cryptocurrencies on various blockchains through web-based applications. You can ensure the security of your MetaMask account by using strong passwords and enabling additional security features, such as hardware wallet integrations. Can cold wallets be hacked? Cold wallets are always more secure than hot wallets because they keep your private keys offline and away from potential online threats at all times. While it is challenging to hack cold wallets, they are not entirely immune to risks. Physical theft, damage, or loss of a hardware or paper wallet can happen to anyone. Therefore, it is crucial to be proactive, store your cold wallet securely, and always create backup copies of your private keys. #### Crypto Wallets 101: How to store private keys securely The accelerated growth and mainstream adoption of cryptocurrencies have led to an ever-increasing need for secure and reliable methods for managing your digital assets. With major cryptocurrency hacks frequently appearing in the media,  many newcomers to the blockchain space are wondering exactly where and how to store private keys safely these days. At the heart of this challenge lies the proper storage and protection of private keys, which are the primary means of accessing and controlling your crypto holdings. With adequate management of these keys, you can avoid losing your precious digital assets to hackers, theft, or simply due to human error. So read on and start stashing your crypto like a pro, as our comprehensive guide will teach you how to store private keys securely, from the basics to more advanced safety techniques. Understanding private keys First, we need to understand what private keys are in the first place. A private key is a fundamental component of the cryptographic systems that underpin most cryptocurrencies. In essence, it is a long and unique alphanumeric code that serves as the basis for accessing and managing your digital assets. To better understand the importance and role of private keys, let’s dive deeper into their primary functions and characteristics: Digital signatures Private keys enable users to create digital signatures for transactions. These signatures act as a secure means of verifying the authenticity and integrity of a transaction, ensuring that only the rightful owner of the private key can authorize the movement of assets. Public key derivation Each private key has a corresponding public key derived through a one-way cryptographic function. This public key is shared freely with others, allowing them to send cryptocurrency to your wallet without exposing your private key. Ownership and control Possessing a private key is tantamount to owning and controlling the associated digital assets. Anyone with access to your private key can manage your cryptocurrencies, so keeping your private keys confidential and secure is essential. Irrecoverable if lost One critical aspect of private keys is that they cannot be recovered if lost since no central authority or support service can help you retrieve a lost private key. As a result, losing your private key equals irreversably losing access to your digital assets. Vulnerability to theft or loss If your private key is exposed to malicious actors or stolen, your digital assets become susceptible to theft or loss. Protecting your private keys from unauthorized access is crucial, as ensuring they are stored securely minimizes the risk of such incidents. As the saying goes, “not your keys not your wallet,” and once you lose access to them, there is no way to recover them once they are gone. Think of private keys as the linchpin of crypto security, allowing users to access, manage, and control their cryptocurrencies. Understanding the importance of private keys and the need to keep them secure is vital for anyone involved in crypto and Web3. Tips for storing blockchain wallet private keys Create strong and unique passwords for your wallets. Use two-factor authentication (2FA) to enhance security. Regularly back up wallet data and store backups in multiple secure locations. Encrypt backups to protect against unauthorized access. Secure physical access to your wallets and backup locations. Protect your devices against malware and phishing attacks by installing reputable security software. Avoid using public Wi-Fi and devices for managing your wallets. Keep your wallet software and security tools up to date. Ensure your wallet’s secret recovery phrase is always offline. Encrypt your PC hard drive using FileVault for Mac or Bitlocker for Windows. Use password managers like KeePass, and never reuse passwords for your wallets. Don’t install untrusted wallet software since it can steal your data instead. Advanced security measures In addition to following best practices for storing private keys, you can implement advanced security measures to enhance the protection of your crypto assets even further. These measures aim to minimize the risk of unauthorized access and strengthen the overall security of your private keys: Use multi-signature wallets Multi-signature wallets, or “multisig” wallets, require multiple private keys to authorize a transaction. These wallets interact with different parties, devices, or locations, providing an additional layer of security. Multisig wallets help protect your digital assets if one of the private keys is compromised by requiring multiple approvals per transaction. They can also be helpful for businesses or organizations that want to ensure a consensus before moving funds. Utilize dedicated hardware devices for key management As mentioned earlier, hardware wallets are secure, offline devices specifically designed to store private keys. Used dedicated hardware devices for key management, such as hardware keys (FIDO2) or trusted platform modules (TPMs). These devices offer advanced encryption and security features, minimizing the risk of unauthorized access, tampering, or key extraction. Integrating these devices into your key management strategy can significantly enhance the protection of your private keys. Implement a hardware security module (HSM) for enterprise-grade key storage For businesses or organizations managing large amounts of digital assets, a hardware security module (HSM) can provide a robust and secure solution for key storage. An HSM is a specialized, tamper-resistant hardware device that generates, stores, and manages cryptographic keys. They perform various cryptographic operations while ensuring that the private keys never leave the secure confines of the device. By implementing an HSM, enterprises can achieve higher security levels for their private keys, reducing the risk of theft, loss, or unauthorized access. Recovery and contingency plans In the world of cryptocurrencies, unexpected events such as loss, theft, or personal incapacitation can have severe consequences for the security and accessibility of your digital assets. As such, it is essential to create a recovery and contingency plan to prepare for such scenarios and mitigate potential risks: Document your recovery process and store it securely A well-documented recovery process is vital for ensuring you or your trusted individuals can regain access to your digital assets in emergencies. This process should include details on how to access your private keys, backups, and any relevant security measures in place. Make sure to store this documentation securely in encrypted digital form or as a physical copy in a safe location. Remember, this information is sensitive and should only be accessible to those you trust. Educate trusted individuals on your recovery plan In case you become incapacitated or unable to manage your digital assets, it’s crucial to have trusted individuals who understand your recovery plan and can step in to help. Choose people you trust and educate them on the specifics of your recovery process, ensuring they know how to access and manage your digital assets if necessary. This might involve sharing your recovery documentation or providing them with instructions on how to use your recovery tools, such as hardware wallets or backup seed phrases. Regularly review and update your recovery plan Regularly reviewing and updating your recovery plan is essential as your crypto asset holdings grow and your security measures evolve. This helps ensure that your plan remains practical and up-to-date with your current security practices and asset holdings. Make a habit of reviewing your plan at least annually or whenever there is a significant change in your crypto portfolio or security measures. Also, remember to inform those you trust of any updates or changes to your recovery plan. Establishing a recovery and contingency plan is crucial to managing your digital assets and securing your private keys. In the world of cryptocurrencies, you should always be ready for unexpected events and prepare for the worst. Final thoughts Managing and securing your crypto can be a challenging endeavor for beginners. As your own bank, you’re entirely responsible for safeguarding your digital assets and ensuring their security. Unlike the traditional financial system, no bank manager or customer service rep can address your concerns or reverse your ill-advised transactions. Therefore, properly securing your private keys is critical to managing your digital wealth in the crypto space. By implementing advanced security measures, you can significantly mitigate the risks of losing or exposing your private keys. In the ever-evolving Web3 space, staying informed about potential security threats and adopting innovative strategies to protect your assets is crucial. Remember that securing your cryptocurrencies rests solely in your hands, and prioritizing the security of your private keys is vital in safeguarding your digital wealth. Always stay vigilant and proactive in securing your digital assets, as the future of your crypto wealth depends on your ability to adequately manage and protect your private keys. FAQ How do I store a private key safely? To safely store a private key, consider using a cold wallet such as a hardware or paper wallet. These offline storage solutions keep your private keys disconnected from the internet, minimizing the risk of hacking or theft. Additionally, follow best practices like strong passwords, regular backups, and encryption to enhance security. Is it safe to store private keys in a database? Never store private keys in a database, as it makes them vulnerable to hacking, data breaches, or unauthorized access. Instead, opt for secure offline storage solutions like hardware wallets, paper wallets, or encrypted files. Where should private key certificates be stored? Store private key certificates securely so unauthorized individuals cannot access them. For enhanced security, choose cold storage options like a hardware or paper crypto wallet. How to store private keys securely in Linux? Consider using a hardware wallet or an encrypted file with restricted access to store private keys securely in Linux. Ensure you have a strong and unique password for the encrypted file and follow best practices like regular backups and updates to your security tools. Additionally, avoid using public Wi-Fi or devices when managing your private keys. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Crypto Wallets 101: Web3 security best practices As blockchain technology and decentralized applications evolve, the Web3 era has generated an increased demand for secure and user-friendly ways to manage digital assets. Crypto wallets are at the forefront of this movement, serving as essential tools for storing, managing, and transacting with cryptocurrencies and other digital assets. Not only do they serve as personal banks for individual users, but they also play a critical role in connecting people to the decentralized world of Web3. With the growing popularity of cryptocurrencies and digital assets, the need for robust security measures has never been more crucial. Cybercriminals constantly seek ways to exploit vulnerabilities and gain unauthorized access to users’ wallets, often losing valuable assets. By following best practices and Web3 security guidelines, you can significantly reduce the risks associated with crypto asset management and ensure that your investments remain far from the clutches of the bad actors in the blockchain world. To recap April’s crypto security month, we’ve put together an article that delves into Web3 and crypto security best practices, providing valuable tips and insights to help users navigate the digital landscape securely. Web3 and crypto security best practices 1. Regularly updating wallet software Keeping your wallet software up-to-date is essential for maintaining security and optimal performance. Developers frequently release updates to fix vulnerabilities, enhance features, and improve user experience. Ensure that you’re using the latest version of your wallet software to benefit from these enhancements and protect your digital assets from potential threats. 2. Using strong and unique passwords A strong and unique password is your first line of defense against unauthorized access to your crypto wallet. Avoid using easily guessable passwords, such as names, dates, or common phrases. Instead, opt for a combination of upper and lowercase letters, numbers, and special characters. Use different passwords for each platform or service to prevent a single compromised password from jeopardizing all your digital assets. 3. Activating Two-Factor Authentication (2FA) Two-Factor Authentication (2FA) adds an extra layer of security to your wallet by requiring a second form of verification, such as a one-time code sent to your mobile device. Activating 2FA makes it significantly more difficult for attackers to access your wallet, even if they have your password. Most wallet providers offer 2FA, and enabling this feature for added protection is highly recommended. 4. Recognizing phishing attempts and avoiding scams Cybercriminals often use phishing attacks and scams to trick users into revealing sensitive information or downloading malicious software. Be cautious when clicking on links or opening attachments from unknown sources. Always double-check the URL of websites, especially when entering your wallet credentials or other sensitive information. Look for red flags like misspelled words, unusual domain names, or suspicious email addresses. 5. Utilizing hardware wallets for long-term storage Hardware wallets, or cold wallets, provide an additional layer of security for storing digital assets. These wallets store your private keys offline on a physical device, making them less vulnerable to hacks and cyber-attacks. While hot wallets are convenient for everyday transactions, hardware wallets are recommended for long-term storage and larger amounts of cryptocurrencies. 6. Storing backups of wallet data in secure locations Backing up your wallet data ensures you can recover your digital assets in case of device failure, theft, or loss. Make copies of your wallet’s private keys, seed phrases, and secret recovery phrases, and store them in secure locations, such as a safety deposit box or encrypted cloud storage. Remember, losing access to your private keys or recovery phrases may result in permanently losing your digital assets, so keeping them safe and secure is crucial. Secret recovery phrases vs. seed phrases Secret recovery phrases Secret recovery or mnemonic phrases are human-readable words representing a wallet’s private keys. The wallet software generates these phrases and serves as a backup for recovering your digital assets if you lose access to your wallet. By entering the secret recovery phrase into a compatible wallet software, you can restore your wallet and regain control of your digital assets. Seed phrases Often used interchangeably with secret recovery phrases, seed phrases are essentially the same thing. Both terms refer to a sequence of words that allow users to recover their wallets in case of device loss, theft, or failure. Seed phrases are generated using a standardized algorithm, making them compatible with various wallet software applications. They allow you to recreate your wallet’s private keys and access digital assets from different devices, if necessary. To ensure the security of your secret recovery and seed phrases, follow these best practices: Write down your phrases on paper and avoid storing them digitally to minimize the risk of hacks or data breaches. Make multiple copies of the phrases and store them in secure locations, such as a safety deposit box, locked drawer, or secure home safe. Do not share your phrases with anyone, as possessing them grants full access to your wallet and its contents. Consider using a metal backup solution, such as a Cryptosteel or Billfodl, to protect your phrases from fire, water, or other physical damage. Regularly check the condition and legibility of your stored phrases, and create new backups if necessary. See our extensive guide on the safekeeping of private keys and recovery phrases to ensure the security of your digital assets. Exploring crypto wallets Crypto wallets can be broadly categorized into two types: hot wallets and cold wallets. Hot wallets are connected to the internet and provide easy access to digital assets for daily transactions. Examples of hot wallets include desktop, mobile, and web-based wallets. On the other hand, cold wallets store digital assets offline and provide higher security. Hardware wallets and paper wallets are examples of cold wallets. Hot wallets vs. cold wallets Hot wallets offer several advantages, including convenience, user-friendliness, and easy access to digital assets, making them suitable for day-to-day transactions. However, they also come with disadvantages, such as increased vulnerability to online attacks, hacks, and potential issues arising from software vulnerabilities or user errors. On the other hand, cold wallets provide enhanced security for long-term storage, making them less susceptible to online attacks and hacks. They are ideal for storing large amounts of digital assets. Despite their security advantages, cold wallets can be inconvenient for regular transactions, and the risk of physical damage or loss could result in the permanent loss of digital assets. As for security considerations, it’s essential to recognize the differences between hot and cold wallets. While hot wallets offer convenience, they are more susceptible to online threats. It’s crucial to use strong passwords, enable 2FA, and follow other security best practices to minimize the risks associated with hot wallets. Though more secure, cold wallets require proper storage and handling to avoid physical damage or loss. Combining hot wallets for daily transactions and cold wallets for long-term storage can be an effective strategy for maintaining convenience and security. Check out our detailed comparison of hot and cold wallets, examples, and more in-depth information. Non-Custodial Wallets Non-custodial wallets allow users to maintain complete control over their private keys and by extension, their digital assets. Unlike custodial wallets, which store users’ private keys on a third-party server, non-custodial wallets ensure that the user is responsible for the security and management of their digital assets. The benefits of using non-custodial wallets for security purposes include the following: Full control: Users have complete control over their private keys, preventing third parties from accessing or mismanaging their digital assets. Reduced risk of hacks: Since private keys are not stored on a centralized server, non-custodial wallets are less susceptible to large-scale hacks and security breaches. No single point of failure: Non-custodial wallets decentralize the storage of private keys, eliminating a single point of failure that could jeopardize users’ digital assets. Increased privacy: Users can maintain a higher level of privacy and anonymity, as non-custodial wallets do not require users to share personal information with third-party providers. To find a suitable non-custodial wallet, start by researching the wallet’s reputation and history by looking for reviews from trusted sources and feedback from the community. Next, ensure the wallet offers robust security features, such as strong encryption, 2FA, and open-source code that the community can audit. Then verify that the wallet supports the cryptocurrencies and tokens you wish to store and is compatible with your preferred devices or platforms. Finally, look for wallets that provide straightforward backup and recovery options, such as seed phrases or secret recovery phrases, to ensure you can regain access to your digital assets in case of device failure or loss. For the full scoop on non-custodial wallets, their features, and how they differ from custodial wallets, refer to our in-depth article on non-custodial wallets. Smart contract wallets Smart contract wallets, also known as programmable or contract-based wallets, are non-custodial wallets that leverage smart contracts’ power to provide additional security features and functionalities. Unlike traditional wallets, smart contract wallets enable users to set customized rules, conditions, and logic for managing their digital assets. Smart contract wallets offer several advantages over traditional crypto wallets. They provide enhanced security by implementing multi-signature authorization, daily withdrawal limits, and time-locked transactions, which help prevent unauthorized access. These wallets also allow users to define custom rules and conditions, enabling greater control and personalization in digital asset management. Another key advantage is their interoperability with decentralized finance (DeFi) platforms, allowing users to interact seamlessly with various DeFi services and applications. To learn more about smart contract wallets, their features, and how they differ from traditional wallets, explore our guide here. Common crypto scams and how to identify them Junk tokens (Shit coins?) and rug pull schemes A widespread cryptocurrency scam involves the promotion of junk tokens. Scammers tempt investors with a lesser-known digital asset with limited supply but promise massive returns. Although these tokens can be purchased, they are created solely to inflate their value before scammers cash out, leaving investors with valueless assets. To avoid such scams, thoroughly research the tokens you plan to invest in and only invest what you can afford to lose. In some cases, tokens can be “honey pots,” where you never have a chance to withdraw them at all! Fraudulent investment proposals In this scam, con artists approach potential victims with seemingly attractive business or real estate opportunities that require cryptocurrency payments. Despite the alluring benefits promised, these opportunities are nothing more than a ruse, and the scammer will pocket any crypto sent. Remember that legitimate organizations are unlikely to contact you unexpectedly about your cryptocurrency holdings. Extortion and social engineering scams Scammers may target individuals through social media or email by initiating a romantic relationship or claiming to possess damaging information about them. In online romance scams, fraudsters establish trust before requesting cryptocurrency transfers for various reasons. In extortion scams, they threaten to release sensitive information unless a ransom is paid in crypto. To avoid falling for these ploys, remain vigilant and be cautious when interacting with people online. Social media messaging scams Scammers often attempt impersonation by mimicking trusted email addresses or social media accounts. Verifying that the account name or email address matches the authentic source is crucial. You can check the destination of a link by hovering your mouse over it on a computer or tapping and holding it on mobile devices. This type of scam is especially prevalent on platforms like Telegram and Discord, where malicious actors thrive. Be cautious when dealing with attachments in emails or messages from unknown or first-time senders, as they could be part of a phishing attempt. Furthermore, scammers may impersonate reputable companies like Binance, providing clickbait links and falsely claiming that assets can be returned after paying a fee. They might even create fake images to make the scam appear more credible. Final thoughts Protecting your digital assets is paramount in the rapidly evolving world of Web3 and cryptocurrencies. By following the crypto security best practices discussed in this article, you can significantly reduce the risks associated with digital asset management. Always remember to stay alert, DYOR, and maintain a healthy skepticism when interacting in the crypto space. As the blockchain landscape expands, staying being proactive in safeguarding your crypto assets is essential for keeping them safe. Stay informed about the latest security trends, developments, and potential threats in the crypto space. By staying one step ahead of cybercriminals and continually adapting your security practices, you can ensure that your investments remain safe and secure in the Web3 era. FAQ What is a Secret Private Key Recovery Phrase? A secret private key recovery phrase is a sequence of 12 or 24 words that grants complete access to your private key wallets. This recovery phrase is an essential security feature in the world of cryptocurrencies. It serves as a backup for situations where you may forget your password or when your device is lost or damaged. By utilizing this phrase, you can regain access to your account and crypto assets, ensuring that your investments remain secure despite unexpected challenges. Storing this recovery phrase safely and confidentially is crucial to preventing unauthorized wallet access. What is Two-Factor Authentication (2FA)? Two-Factor Authentication (2FA) is a vital security measure that requires users to provide two separate forms of identification to access an account or perform sensitive actions, such as a unique, time-sensitive code generated by an authenticator app or sent via SMS. Biometric authentication, like fingerprint or facial recognition, may also be used. The importance of 2FA in the crypto sphere is multifaceted. First and foremost, it enhances security by making it more difficult for unauthorized users to access your account, even if they have your password. It also protects against phishing attacks, as cybercriminals would need both login credentials and the second form of identification to compromise your account. Additionally, 2FA mitigates the risk of human error related to weak or reused passwords. What is phishing? Phishing is a prevalent cyber threat where scammers attempt to deceive you into sharing personal information, granting them access to your accounts. While some phishing attempts are easily detectable due to misspelled words, bad grammar, or strange writing, scammers continuously evolve their tactics and become more sophisticated. These attacks come in various forms, but the ultimate goal is for the criminal to gain access to your sensitive information. This can be achieved by tricking you into providing login credentials or downloading malicious software that compromises your data. Phishing can occur through emails, direct messages, or text messages you did not initiate and may request sensitive information. To protect yourself against phishing attacks, be cautious when encountering unsolicited messages requesting personal details or encouraging you to click on links or download files. Always verify the source and remember that legitimate organizations typically do not ask for sensitive information through unsolicited messages. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Crypto Wallets 101: What are non-custodial wallets? With so many crypto wallets available these days, it can be difficult to decide which one to use. With each boasting unique features and security measures, the choices are endless. The difference is whether the private keys are in your possession or held on a centralized exchange (CEX), such as Binance. Every crypto wallet uses private keys to grant you control over your digital assets. Self-custodial wallets are always the best option for highly security-conscious people who hoard a lot of crypto and NFTs. On the other hand, CEX wallets and “hot wallets” offer a more accessible user experience for beginners but expose your cryptocurrencies to potential security breaches, not to mention increased regulatory scrutiny. Our in-depth guide will explain exactly what are non-custodial wallets and help you on the quest to keep your crypto assets safely in your hands, from the basics to more sophisticated methods. How do non-custodial wallets work? Non-custodial wallets provide complete ownership of your digital assets- full responsibility and control of your private keys. They are your link to the blockchain network, allowing you to interact directly with your cryptocurrencies and Web3 applications (dApps). Unlike custodial wallets, where a third party holds your private keys, non-custodial wallets grant you unfettered access to your crypto and NFT holdings anytime. Advantages of non-custodial wallets Non-custodial wallets provide many benefits catering to cryptocurrency users’ needs who value autonomy, security, and privacy. Complete control of your private keys Non-custodial wallets give users complete control over their private keys, ensuring exclusive access to their digital assets. This level of control allows users to manage their cryptocurrencies independently and securely. Enhanced security and privacy By eliminating the need to trust a third party with the management of private keys, non-custodial wallets offer higher security and privacy. Users are in control of safeguarding their private keys, reducing the risk of exposure to potential security breaches or hacks targeting third-party service providers. Lower risk of centralized failure Everyone has already heard on the news what happened to FTX and other centralized crypto exchanges over the years. Non-custodial wallets decentralize the responsibility of asset management, reducing the risk of losing funds due to a centralized service provider’s failure. This mitigates the chance of losing your crypto to exchange hacks, rug pulls, exit scams, bankruptcy, or regulatory shutdowns. Censorship resistance Non-custodial wallets empower users to transact freely without intermediaries, ensuring censorship-resistant transactions. Users can send and receive cryptocurrencies without fearing a central authority blocking or monitoring their transactions. Disadvantages of non-custodial wallets While non-custodial wallets offer numerous benefits, they also come with certain drawbacks that users should consider before opting for this type of wallet. Sole responsibility for security The primary disadvantage of non-custodial wallets is that users must be responsible for their private keys’ security. Losing or compromising private keys could result in the irreversible loss of funds. Users must adopt proper security measures to protect their assets. Higher technical knowledge required Non-custodial wallets may require a higher level of technical knowledge to set up and use, as they often need more user-friendly interfaces and features offered by custodial wallets. Users must understand essential concepts, such as private keys and seed phrases, to manage their assets effectively. Limited customer support Given the decentralized nature of non-custodial wallets, users might find customer support limited or pretty much nonexistent. In case of any issues or challenges, you may need to rely on community forums, social media, guides, or DIY to troubleshoot problems. What are the different types of non-custodial wallets? Hardware wallets Hardware wallets are devices designed to store private keys securely offline, providing high security for digital assets. These wallets typically feature a screen, buttons, and a USB or Bluetooth connection, enabling users to interact with their cryptocurrencies without exposing private keys to the internet. Pros High level of security due to offline storage Immune to malware and keylogging attacks Suitable for long-term storage of cryptocurrencies Cons More expensive than other wallet types Requires physical possession to access funds Limited support for specific cryptocurrencies Popular choices Ledger Nano S and Nano X Trezor One and Model T KeepKey Software wallets Software wallets are applications installed on desktops, laptops, mobile devices, or as browser extensions, allowing users to manage their cryptocurrencies digitally. These wallets create and store private keys on the user’s device, balancing convenience and security. Just keep in mind that some wallets are native to their cryptocurrency. For example, you can only use the Phantom wallet to interact with the Solana ecosystem, whereas some wallets support multiple blockchains. Pros User-friendly interfaces and features Accessible across various platforms Quick and convenient transactions Cons Vulnerable to hacks, malware, and device failures Security varies depending on the specific wallet software Not ideal for long-term storage of large amounts of cryptocurrency Popular choices MetaMask(web-based and mobile) Argent (web-based and mobile) Electrum (desktop and mobile) Exodus (desktop and mobile) MyEtherWallet (web-based and mobile) Trust Wallet (web-based and mobile) Paper wallets Paper wallets physically represent private keys, typically in QR codes or alphanumeric sequences printed on paper. These wallets allow users to store their digital assets securely offline by creating and storing private keys on a physical medium. Pros Highly secure due to offline storage Inexpensive and easy to create No risk of digital hacks or device failures Cons Susceptible to physical damage, loss, or theft Inconvenient for frequent transactions Requires careful handling and storage What non-custodial wallet should I choose? Committing your precious digital assets to a wallet is a significant financial decision, so you must always DYOR before transferring your hard-earned crypto assets to a new wallet. Here are some essential factors to consider before you make a decision: Level of security The most crucial aspect when choosing a non-custodial wallet is the security it offers. Consider the wallet’s reputation, track records, and security features, such as two-factor authentication, PIN codes, or biometric authentication. Remember, you are responsible for your private keys’ security, so choose a wallet with robust security measures. Ease of use If you’re new to cryptocurrencies, look for a wallet with a user-friendly interface and straightforward functionality. It should be easy to navigate, provide clear instructions, and enable you to send, receive, and manage your digital assets without hassle. Supported cryptocurrencies Ensure that your chosen wallet supports the cryptocurrencies you own or plan to acquire. Some wallets cater specifically to one cryptocurrency, while others support multiple digital assets. Selecting a wallet that meets your current and future needs is best. Compatibility with other blockchains Non-custodial wallets integrate with decentralized exchanges, staking platforms, or other blockchain platforms. These integrations can offer added convenience and functionality, enabling you to access various features directly from your wallet. Crypto wallets like Metamask(interlink) support multiple blockchains, making it an excellent choice for many beginners in blockchain and Web3. How to start using a non-custodial wallet? Create and set up your first crypto wallet by following these quick steps. Choose a non-custodial wallet that meets your requirements in terms of security, ease of use, supported cryptocurrencies, and cost. Download and install the wallet software on your device, or purchase a hardware wallet from a reputable manufacturer. Follow the wallet’s setup instructions, including creating a new wallet or importing an existing one using a seed phrase. For beginners, software wallets like Trust Wallet offer a user-friendly interface, support for various digital currencies, and adequate security. Intermediate users with larger holdings may prefer hardware wallets like Ledger Nano S or Trezor One for enhanced protection and offline storage of private keys. Advanced users can maximize security and flexibility by using a combination of wallet types: hardware wallets for long-term storage and software wallets for day-to-day transactions. Creating and securing your private keys Next, you will be prompted to generate a private key or seed phrase during the wallet setup process. This critical piece of information provides access to your digital assets. Ensure you securely store your private key or seed phrase offline by writing it down on paper or using a secure backup method, such as a hardware wallet or encrypted USB drive. Don’t forget to keep multiple copies of your private key or seed phrase in secure locations to avoid loss or damage. Also, remember never to share your private key or seed phrase with anyone, as doing so could result in unauthorized access to your funds. Transferring and managing your crypto Navigate to your wallet’s “receive” or “deposit” section to obtain your public address or QR code. Share this address with the sender or input it into the originating wallet or exchange platform. Double-check the address to ensure accuracy before confirming the transaction. Monitor the incoming transaction in your non-custodial wallet to verify its completion. To send funds, navigate to your wallet’s “send” or “withdraw” section, enter the recipient’s public address, and specify the amount you wish to transfer. Confirm and authorize the transaction using your wallet’s security features, such as a PIN code or biometric authentication. Staying updated on wallet security best practices Regularly update your wallet software to the latest version, as updates may contain essential security enhancements and bug fixes. Follow the wallet provider’s official communication channels and stay informed about potential security risks or emerging threats. Always use strong, unique passwords for any accounts associated with your wallet, and enable two-factor authentication whenever possible. Remain vigilant against phishing attacks, scams, and social engineering attempts by verifying the legitimacy of any communication or websites related to your wallet. Educate yourself on wallet security best practices and continually assess the security measures you have in place to protect your digital assets. Final thoughts As the world of cryptocurrencies continues to evolve and expand, it’s important to stay up to date on the latest tools and technologies. The increasing popularity of MPC wallets this year, for instance, might result in them gradually supplanting multisig wallets due to the enhanced flexibility they provide to developers. Web3 technology never stands still, as it continuously reshapes and redefines itself. To stay ahead in this ever-changing landscape, it’s crucial to be in tune with the latest breakthroughs and advancements that fuel the industry’s growth. We always encourage you to research and explore the crypto wallet options discussed in this post and always DYOR to find what works for you. By proactively safeguarding your crypto assets, you not only embrace the decentralized spirit of the cryptocurrency revolution but also transform into an informed and self-reliant player in the new digital economy. FAQ Is MetaMask a non-custodial wallet? Yes, MetaMask is a non-custodial wallet. This means that users have full control over their private keys and are responsible for the security of their digital assets. MetaMask does not store users’ private keys on its servers, ensuring they retain sole control over their cryptocurrencies. What crypto wallets are non-custodial? A wide range of non-custodial wallets is available to manage cryptocurrencies, including MetaMask, a browser extension and mobile wallet that supports Ethereum and ERC-20 tokens. Trust Wallet is a versatile mobile wallet that accommodates multiple cryptocurrencies like Ethereum, Binance Smart Chain, and many more. Exodus is a user-friendly software wallet for desktop and mobile devices, while MyEtherWallet is a popular Ethereum wallet that supports ERC-20 tokens and smart contract interactions. For enhanced security, hardware wallets like Ledger Nano S/X, Trezor One/Model T, and KeepKey offer offline storage of private keys and compatibility with various cryptocurrencies. Coinomi, another multi-cryptocurrency wallet, allows users to exchange assets within its mobile and desktop interfaces. It’s essential to consider factors such as security, ease of use, and cryptocurrency compatibility when choosing a non-custodial wallet. What is a smart contract wallet? Smart contract wallets are an innovative development in cryptocurrency, offering unique features that make managing digital assets more user-friendly and secure. One of the key technologies enabling these benefits is account abstraction, which allows for the separation of the wallet’s control logic from the user’s funds. A good example of a smart contract wallet is Argent, also available on mobile. Argent offers a range of features to enhance the user experience, such as batched transactions, which save on gas fees and optimize transaction execution. The wallet also provides a free ENS address, making it simpler to remember and share. With seamless access to lending and borrowing services, users can earn interest or take out loans as needed directly from the app. How to create a paper wallet? Creating a paper wallet typically involves the following steps: Use a reputable paper wallet generator, such as WalletGenerator.net or BitAddress.org. Disconnect your device from the internet to ensure security. Follow the generator’s instructions to create your wallet and print your private and public keys on paper. Store the paper wallet securely, preferably in a fireproof and waterproof container or a safe deposit box. To use the funds, import the private key into a software or hardware wallet to access your digital assets. Power boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Crypto Wallets 101: What is a smart contract wallet? Meet smart contract wallets, the key to unlocking a host of innovative features for managing your crypto assets. As the cryptocurrency landscape continues to grow and blockchain technology becomes increasingly integrated into our daily lives, smart contract wallets have emerged as essential tools for protecting and streamlining digital asset management. So, what is a smart contract wallet? Imagine being able to bundle transactions, customize your recovery options, pay gas fees with non-native tokens, and maintain your privacy**—**all within a single wallet! Smart contract wallets are transforming how we engage with cryptocurrencies and blockchain networks by harnessing the power of self-executing agreements, known as smart contracts, to deliver more secure, flexible, and user-friendly solutions. Though not every smart contract wallet eliminates externally owned accounts (EOAs), the future offers promising possibilities. Now we have ERC-4337, an account abstraction approach seeking to liberate users from centralized relayers and EOAs. This approach could establish a universal standard addressing security concerns, but it necessitates further infrastructure development. Join us as we delve into the realm of smart contract wallets and uncover their crucial role in the rapidly evolving digital economy and the expansive Web3 ecosystem. What are smart contract wallets? A smart contract wallet is a decentralized application (DApp) built on a blockchain that enables users to manage their digital assets using smart contract technology. These contracts are self-executing, programmable scripts that automatically enforce the terms and conditions of an agreement. This functionality offers users higher control and security than traditional wallets, as smart contracts enable unique features like multisig, access controls, and customizable transaction logic. Some of the key benefits of using a smart contract wallet include the following: 1. Enhanced security: Smart contract wallets utilize blockchain technology and encryption protocols to protect users’ assets from theft or unauthorized access. For example, a user’s private key is securely stored and encrypted within the wallet, making it extremely difficult for hackers to access the user’s funds. 2. Customizable features: Smart contracts enable advanced functionality, such as multisig transactions, spending limits, and programmable rules, which can be tailored to users’ needs. For instance, a user can set a daily spending limit to mitigate the risk of excessive or unauthorized transactions. 3. Decentralization: Unlike traditional wallets that rely on a centralized authority, smart contract wallets leverage the power of decentralization, reducing the risk of single points of failure and censorship. This can be exemplified by a decentralized exchange (DEX) wallet that allows users to trade tokens directly from their wallets without needing a centralized exchange’s approval or intervention. 4. Transparency and auditability: All transactions and smart contract codes are recorded on the blockchain, accessible and verifiable by anyone, fostering trust and confidence in the system. For example, if a user suspects fraudulent activity, they can quickly verify their transaction history on the blockchain to confirm the accuracy of their wallet’s records. Smart contract wallet examples Some popular smart contract wallets include InstaDApp, Zerion, Poketto Cash, Argent, and Braavos. These wallets offer you various features such as borrowing, lending, token swapping, liquidity provision, interaction with decentralized applications (DApps), instant payments, and integration with decentralized exchanges. Some also provide user-friendly interfaces, low fees, and support for non-fungible tokens (NFTs), making them popular choices among users in the crypto space. Practical use cases for smart contract wallets include: Secure asset management: Individuals and organizations can use smart contract wallets to manage their digital assets securely, leveraging features like multisig and customizable access controls. For example, a company can use a smart contract wallet to ensure that only authorized personnel can access and manage its digital assets, providing an additional layer of security. Collaborative decision-making: Teams, companies, or groups can use smart contract-based wallets to ensure that spending decisions are made collectively, fostering transparency and accountability. As an illustration, a non-profit organization can use a multisig smart contract wallet to require multiple board members’ approval before releasing funds, ensuring the decision-making process is more democratic and transparent. Access to DeFi services: Users can use smart contract wallets’ integration capabilities to access various DeFi platforms, allowing them to participate in decentralized finance (DeFi) directly from their wallets. For instance, users can link their smart contract wallet to a decentralized lending platform, allowing them to lend or borrow assets without relying on a traditional financial institution. What are multi-signature smart contract wallets? Multisig, short for multi-signature, refers to a smart contract-based wallet requiring multiple parties’ approval before a transaction can be executed. A multisig wallet operates on the principle of “m-of-n” signatures, meaning that “m” out of the “n” designated signatories must approve a transaction before it can be processed. The value “n” represents the total number of designated signatories, each possessing a unique private key for approving transactions. The higher the “n” value, the more distributed and secure the wallet becomes. Meanwhile, the value “m” denotes the minimum number of signatures these signatories require to authorize and execute a transaction. An “m-of-n” multisig wallet necessitates at least “m” signatures out of the “n” signatories for a transaction to be deemed valid, with “m” ranging from 1 to the total number of signatories (“n”). For example, a 2-of-3 multisig wallet would involve three signatories (n = 3) and require at least two of them (m = 2) to approve a transaction before it can be processed. In this configuration, any two of the three signatories must provide their signatures using their private keys for the transaction to be executed. Multi-signature smart contract wallets utilize smart contracts to enforce multi-signature schemes, requiring numerous signatures for transactions, providing an extra layer of security, and making them especially resistant to hacks. The role of multi-signature smart contracts in Web3 In the Web3 ecosystem, multi-signature smart contracts are essential in enhancing security and control over digital assets, ensuring that a single individual cannot make unilateral decisions or take actions without the consent of other designated parties. One of the top benefits of multi-signature smart contracts is their enhanced security which reduces the risk of theft or unauthorized access, as numerous approvals are required before a transaction can be processed. Another is the higher level of control they deliver by involving multiple parties in the governance process, helping distribute ownership, and reducing the risk of single points of failure. Thanks to their high degree of customizability, users can tailor the parameters of the multi-signature smart contract to meet their specific needs, such as setting the number of required signatures or establishing a hierarchy of permissions. Additionally, multi-signature smart contracts encourage accountability and transparency among participants. All actions are recorded on the blockchain and can be audited by anyone, providing clear insight into decision-making processes. Use cases for multisig wallets Multisig wallets are useful for a wide range of personal and business applications that require the utmost security, including: Collaborative organizations or teams: Businesses, non-profits, or other groups can use multisig wallets to ensure that any spending decisions require consensus, reducing the risk of fraud or unauthorized transactions. Escrow services: Multisig wallets can act as intermediaries for secure transactions between buyers and sellers, where the release of funds depends on the approval of all involved parties. Personal security: Users who want to reduce the risk of asset loss due to theft or mismanagement can distribute the required signatures among trusted peers. Pros of multisig wallets 1. Enhanced security: By requiring consensus before key actions, multisig wallets minimize the risk of unauthorized access, making it more difficult for bad actors to steal your funds. 2. Accountability: The need for multiple approvals helps promote transparency and accountability among wallet users, ensuring that your spending decisions are made collectively. 3. Backup and recovery: Since the required signatures can be distributed among trusted individuals, the risk of losing access to your wallet due to mishandling a single private key is minimized. Cons of multisig wallets 1. Complexity: Setting up and managing multisig wallets can be more complex than traditional crypto wallets, which might deter some users. 2. Coordination: As multisig wallets require approvals from multiple parties, transactions can take longer to process, especially if the involved parties are in different time zones or have conflicting schedules. 3. Compromised signatories: If one or more signatories become unresponsive, compromised, or disreputable, it can become difficult to execute transactions or recover funds. How do multisig wallets work? Using a typical multisig wallet smart contract involves the following steps: 1. Wallet creation: The wallet owner deploys a smart contract specifying the number of required signatures (m) and the designated signatories (n). 2. Funding the wallet: Users deposit funds into the wallet’s smart contract address. 3. Proposing a transaction: When a transaction needs to be executed, one of the signatories creates a transaction proposal, specifying the recipient address, amount, and any additional data. 4. Approval process: The designated signatories review and either approve or reject the transaction proposal. 5. Transaction execution: Once the required number of approvals (m) is reached, the smart contract executes the transaction automatically, transferring the funds to the specified recipient. Multisig wallets powered by smart contracts offer increased security and flexibility, making them an excellent choice for those who prioritize asset protection and collaborative decision-making. One of the more popular multisig smart contract wallets is Gnosis Safe, which offers advanced features like module-based customization and integration with other DApps. Gnosis Safe Gnosis Safe is a popular multisig smart contract wallet built on the Ethereum blockchain. It offers a modular architecture, enabling seamless integration with other DApps and allowing users to leverage a wide range of features such as: Multisig security: Gnosis Safe requires multiple signatures for transactions, providing a higher level of security for your assets compared to single-signature wallets. Modular design: The wallet’s modular architecture allows you to add or remove features and integrations, catering to their specific requirements. DeFi integration: Gnosis Safe supports integration with popular DeFi platforms, enabling you to access financial services directly from your wallet, such as lending, borrowing, and trading. Hardware wallet support: Gnosis Safe can be connected to hardware wallets like Ledger or Trezor, offering you an additional layer of security by keeping private keys offline. Customizable transaction rules: This wallet lets you set custom transaction conditions, such as spending limits, time locks, and whitelisting addresses. User-friendly interface: Thanks to Gnosis Safe’s clean and intuitive interface, you can manage your assets, view transaction history, and interact with DApps with ease. Practical use cases Asset management for organizations: Your company or organization can use Gnosis Safe to securely manage its funds, with built-in access controls and approval processes. DAOs (Decentralized Autonomous Organizations): If you are part of a ****DAO, you can use Gnosis Safe to manage the treasury, allowing members to decide on fund allocation and investment decisions collectively. Family trust: Your relatives can also set up a Gnosis Safe wallet with multisig functionality to manage a shared family fund so that impactful financial decisions are only made collectively. Argent wallet Built on the Ethereum blockchain, Argent is a smart contract wallet designed for simplicity. It is an accessible entry point into digital asset management, even for the less tech-savvy. This makes it an ideal choice for those making their first steps into Web3, especially since it also comes with handy safety features like: User-friendly interface: This wallet’s clean and intuitive design makes it a real walk in the park for both you and your non-crypto native peers to manage assets, interact with DApps, and access DeFi services. Recovery options: Argent eliminates the need for you to keep long and complex seed phrases safe by providing recovery options through designated “guardians,” such as your friends, family, or even hardware wallets. Daily transaction limits: With Argent, you can set daily transaction limits to protect your funds from theft, unauthorized access, and general mismanagement. Integration with DeFi platforms: Thanks to its high degree of interconnectivity with leading DeFi protocols like Compound, Maker, and Aave, you will have no trouble accessing the platforms of your choice and will do so safely, directly from your wallet. Non-custodial: As a non-custodial wallet, Argent ensures you retain full control of your private keys so that the security and safety of your assets are always in your hands, for better or for worse. Fee-free transactions: To put the cherry on top, you also have the chance to commit transactions entirely for free, which will help break down any cost barriers that prevent you from transacting with your holdings and interacting with DApps. Practical use cases Beginner-friendly asset management: Argent’s simplicity makes it an excellent choice for any freshman seeking to manage their assets without being forced into a steep learning curve, as with some other wallets. DeFi in the palm of your hand: Argent’s comprehensive integration with DeFi platforms is sure to come in handy when accessing various financial instruments to engage in lending, borrowing, and earning interest, among the many, across Web3. Token and NFT storage: Argent’s extensive support for storing and managing a wide range of ERC-20 tokens and NFTs genuinely makes it a one-stop shop for all your digital asset needs. Final thoughts Smart contract wallets offer a powerful and flexible solution for managing digital assets, providing users with enhanced security, customizability, and access to a growing ecosystem of decentralized applications and services. It is crucial to carefully research and compare the available options to find the wallet that best aligns with your requirements. Those seeking a wallet with multisig functionality and extensive DeFi integration might choose Gnosis Safe, while beginners seeking a simple and easy-to-use wallet may opt for Argent. If you are a beginner, you can use Argent to set up a wallet effortlessly and not ever have to worry about losing your keys by appointing a trusted family member or a hardware wallet as recovery guardians. This means you can always transact freely without the need to deal with the intricacies of traditional seed phrases and private keys. On the other hand, if you are one of five co-founders or generally part of the staff with access to the treasury, you can use Gnosis Safe to manage company funds safely by requiring 3 of the 5 signatures for any action. Using this approach, you will never leave a single person with the keys to the entire kingdom. Additionally, you can enforce spending limits, mandating that any transaction above a certain threshold has approval from all five signatories, enhancing both security and collective action. As the Web3 ecosystem grows and develops further, it is only natural for new paradigms to emerge in smart contract wallet technology. This includes new hot and cold wallet types, stricter security measures, broader DApp integration, and more streamlined user experiences for novices and seasoned users. This constant evolution is pivotal for the mass adoption of smart contract wallets in the fast-paced realm of decentralized finance. FAQ What is account abstraction? ERC-4337 account abstraction is a groundbreaking approach that eliminates the need for third-party relayers, layer-2 smart contracts, and changes to the consensus layer. This allows you to manage a smart contract wallet without relying on externally owned accounts (EOAs), as is the case traditionally. This innovative method bears fruit by introducing a new standard for transaction messaging. Rather than executing transactions individually or transmitting the metadata of authorized transactions to a relayer, smart contract wallets can send a series of interactions to a bundler. This streamlines the overall transaction process, improving efficiency and accessibility in managing digital assets from the smart contract wallet interface. Is MetaMask a smart contract wallet? While MetaMask is a cryptocurrency wallet that supports various digital assets, it is not a smart contract wallet in the strictest sense. It’s a versatile wallet initially focused on Ethereum-based tokens (ERC-20). As a browser extension, MetaMask enables you to interact with DApps across a wide range of networks. It has since expanded its support to include more networks and Layer-2 protocols, with BNB Smart Chain, Polygon, Optimism, Arbitrum, and recently zkSync Era as some of the most notable examples. While MetaMask allows users to interact with smart contracts when using DApps, it is not a smart contract wallet per se. Instead, it is an interface that helps you manage assets and engage with DApps and smart contracts, available on its supported protocols. How to create a smart contract wallet? Pick a smart contract wallet: Choose a reputable provider that meets your needs, such as Gnosis Safe and Argent. Research your options by evaluating their security, reputation, accessibility, and compatibility with the networks you plan to interact with. Install the wallet software: Depending on your chosen platform, download and install its application on your computer or smartphone. Some wallet providers may offer a browser extension instead, allowing you to interact with DApps without interrupting your experience. Set up a new wallet: Launch the wallet software and follow the on-screen instructions of the setup wizard to create a new wallet. You will likely be prompted to generate a new set of private and public keys or import existing ones, should you already have such. Backup your wallet: Make sure to store your wallet’s recovery phrase or seed phrase securely. It comprises a series of words you can use to recover access to your wallet in case you lose or mismanage it. Do your best to write this phrase down and place it in a safe and secure location, such as a safe deposit box, to avoid the worst-case scenario. Also, it is wise to use a hardware wallet as an extra layer of security. Customize your wallet: Configure the wallet settings to meet your requirements. This can range from setting up the multi-signature functionality, enforcing daily transaction limits, or whitelisting specific addresses as further security measures. Fund your wallet: Transfer any digital assets from an existing wallet or exchange account to your new smart contract wallet. To do this, you will first need the public key of your wallet, also known as your address, which you will find within the wallet interface. Interact with DApps and start transacting: With your smart contract wallet set up and funded, you can now interact with DApps and perform transactions to send and receive cryptocurrency assets or engage with more complex financial instruments offered by various DeFi platforms. Can a smart contract drain your wallet? A smart contract itself cannot directly drain your wallet, as it cannot access your private keys. However, there are potential risks associated with smart contracts that could lead to loss of funds. Among some of these risks are: Vulnerabilities in smart contracts: If the smart contract you interact with has potential security vulnerabilities, bad actors can exploit them to steal funds from the contract or manipulate the contract’s behavior to their advantage. Scams and malicious contracts: Individuals with malicious intent, like scammers, may create smart contracts designed to appear legitimate to fool unsuspecting visitors. But in reality, they are far from it, having the ability to siphon funds from those that make the poor decision of interacting with them instead. Incorrect or flawed code: If the smart contract you interact with has errors in its code, it may not function as intended, which could lead to unexpected behavior, loss of funds, and any unforeseen consequences. Loss of access: Some smart contracts may ask you to lock your funds up for a while. This is not necessarily bad, but if the contract doesn’t function properly, there is a chance you may lose access to your funds permanently. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cut RPC costs with a hybrid self-hosted and cloud setup Run your own Ethereum node for the everyday RPC traffic, and let eRPC transparently forward the heavy historical (archive) queries your node can’t serve to a Chainstack Cloud archive node. One endpoint for your apps; recent RPC served by your own node; archive only when you actually need it. This walkthrough uses Ethereum Hoodi (a testnet) as a low-cost, reproducible example. It’s a mechanics demo — the exact same setup on Ethereum mainnet or Base is where the cost savings land. Why A full node keeps recent state and is cheap to run. An archive node keeps all historical state and is expensive (big disk, slow to sync). Most apps are 95% recent-state traffic and only occasionally need archive (trace_*, debug_*, balances/state at old blocks). So: self-host the cheap full node, and route the rare archive calls to a managed archive node. eRPC sits in front of both as a single endpoint and decides per request. Architecture The routing split: eRPC decides per request whether it goes to your self-hosted node or Chainstack Cloud archive. Client applications see one endpoint. Self-hosted node — primary. It runs as Kubernetes pods (reth execution + prysm consensus) managed by Chainstack Self-Hosted. Its RPC is internal only — never exposed to the internet. Chainstack Cloud archive node — the failover/archive upstream. Billed only for what the full node can’t serve. eRPC — runs on the same box (Docker). One endpoint; routes by method, fails over on error, and caches finalized data so repeat archive hits don’t re-bill Cloud. Get and secure a server We used a Velia bare-metal box (Ubuntu 24.04, 12 vCPU / 32 GB RAM) ordered with the Chainstack Self-Hosted management option — which ships the Control Panel pre-installed, so the whole k3s/cpctl install is done for you. Promo ChainstackSH80 gives 80% off the first month. For Hoodi you need very little: ~8 vCPU, 32 GB RAM, ~500 GB disk. Mainnet needs much more (see System requirements). If your box does not ship with the Control Panel pre-installed, scripts/provision.sh installs the base tooling (k3s, helm, yq, cpctl) and stops before the interactive cpctl install — follow Quick start from there. SSH key access Use a key, not a password. Generate one locally and attach the public half to the server: ssh-keygen -t ed25519 -f ~/.ssh/hoodi_key # add ~/.ssh/hoodi_key.pub to the server (provider panel, or /root/.ssh/authorized_keys) ssh -i ~/.ssh/hoodi_key root@<SERVER-IP> Harden the box (do this before anything else) A fresh public server is scanned by bots within minutes. Minimum hardening: # firewall: deny all inbound except SSH; keep Kubernetes internals working apt-get install -y ufw fail2ban ufw default deny incoming ufw default allow outgoing ufw allow 22/tcp ufw allow in on lo ufw allow from 10.42.0.0/16 # k3s pod CIDR ufw allow from 10.43.0.0/16 # k3s service CIDR ufw allow from <SERVER-IP> # node talks to itself ufw --force enable # SSH: key-only cat >/etc/ssh/sshd_config.d/99-harden.conf <<'C' PasswordAuthentication no PermitRootLogin prohibit-password C systemctl reload ssh # ban brute-forcers systemctl enable --now fail2ban The Control Panel UI (Traefik) is published on ports 80/443 by k3s via a hostPort, which bypasses ufw’s INPUT chain. Block it from the internet at the raw table (find your public NIC with ip route get 8.8.8.8): iptables -t raw -I PREROUTING -i <PUBLIC-IF> -p tcp -m multiport --dports 80,443 -j DROP Reach the Control Panel later over an SSH tunnel instead: ssh -i ~/.ssh/hoodi_key -L 8080:localhost:80 root@<SERVER-IP> → http://localhost:8080. ⚠️ Also change your server’s IPMI/BMC password — it’s separate hardware and a common takeover vector. Put chain data on NVMe (do this before deploying the node) This bit matters for sync speed. k3s’s default local-path storage lives on the OS disk. On many bare-metal boxes that’s a SATA SSD, while the fast NVMe drives ship raw and unused — so a node deployed with defaults syncs on the slow disk. Point k3s storage at NVMe first. With two raw NVMe drives, stripe them (RAID0) for max throughput and repoint local-path: # RAID0 across both NVMe -> one fast 1.9 TB volume (RAID0 = no redundancy; fine for a resyncable node) apt-get install -y mdadm mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1 --run mkfs.ext4 -F /dev/md0 mkdir -p /mnt/chaindata && mount /dev/md0 /mnt/chaindata echo '/dev/md0 /mnt/chaindata ext4 defaults,nofail 0 0' >> /etc/fstab mdadm --detail --scan > /etc/mdadm/mdadm.conf mkdir -p /mnt/chaindata/storage # repoint k3s local-path default to the NVMe volume (affects newly-created PVCs) kubectl -n kube-system get cm local-path-config -o jsonpath='{.data.config\.json}' # note current path # edit nodePathMap paths -> ["/mnt/chaindata/storage"], then: kubectl -n kube-system rollout restart deploy local-path-provisioner A single NVMe (skip RAID) is plenty for Hoodi; RAID0 just doubles throughput. For a Chainstack-blessed multi-disk setup, use LVM + TopoLVM per Environment setup. Do this before Create node so the node’s volume is provisioned on NVMe from the start (changing it later means deleting and resyncing the node). Deploy the self-hosted Hoodi node Chainstack Self-Hosted deploys nodes through the Control Panel UI (cpctl manages the platform, not nodes). Log in (user root, the bootstrap password from your provider email), then: Nodes → Create node Protocol Ethereum → Network Hoodi → preset Light (4 vCPU / 16 GiB) Create node Node type selection in the Chainstack Self-Hosted Control Panel. Light preset (selected) is sufficient for Hoodi testnet; mainnet needs Standard or larger. It spins up reth (execution) + prysm (consensus) pods in the control-panel-deployments namespace. The node’s RPC is a ClusterIP service (*-reth-rpc, port 8545) — internal only. The node then syncs. reth uses staged sync (headers → bodies → sender-recovery → execution → …); eth_blockNumber stays 0x0 until the final stage, and eth_syncing returns false when caught up. Deploy the Chainstack Cloud archive node In the Chainstack console: create/choose a project → Deploy node → Ethereum → Hoodi → Node type: Archive → Create. Copy the HTTPS endpoint (includes the auth key). Verify it’s archive-capable: curl -s https://ethereum-hoodi.core.chainstack.com/<KEY> -H 'Content-Type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"trace_block","params":["0x1"]}' # returns a result (not -32601 method not found) Configure and run eRPC eRPC is open-source and runs from a single Docker image. Install Docker if needed (curl -fsSL https://get.docker.com | sh). erpc/erpc.yaml: logLevel: info # server defaults to :4000 (RPC) and :4001 (metrics) — do NOT set server.port/metrics.port, # the current eRPC image rejects those fields. database: evmJsonRpcCache: connectors: - id: memory driver: memory memory: { maxItems: 100000 } policies: - { network: "*", method: "*", finality: finalized, connector: memory, ttl: 0 } - { network: "*", method: "*", finality: unfinalized, connector: memory, ttl: 5s } projects: - id: main networks: - architecture: evm evm: { chainId: 560048 } # Ethereum Hoodi failsafe: - matchMethod: "*" timeout: { duration: 30s } retry: { maxAttempts: 2, delay: 200ms } # primary errors -> fail over to Cloud hedge: { delay: 3000ms, maxCount: 1 } upstreams: - id: self-hosted-eth # primary: local node endpoint: ${SELF_HOSTED_RPC_URL} evm: { chainId: 560048 } ignoreMethods: ["trace_*", "debug_*"] # archive-only methods never hit the full node failsafe: [{ matchMethod: "*", timeout: { duration: 10s } }] - id: chainstack-cloud-eth # archive + failover endpoint: ${CLOUD_RPC_URL} evm: { chainId: 560048 } tags: ["tier:fallback"] failsafe: [{ matchMethod: "*", timeout: { duration: 20s } }] The three routing behaviors: method routing (ignoreMethods keeps trace_*/debug_* off the full node → they go to Cloud), error failover (retry promotes a request to Cloud when the self-hosted node errors, e.g. pruned old state), and finality cache (finalized results cached forever). Note that error failover is reactive: the first read of an old block still hits the self-hosted node, burns one failed attempt plus the 200 ms retry delay, and only then gets served by Cloud. The cache absorbs repeats — a read at an old block is finalized data, so it’s cached forever after the first hit. If your workload reads old state often, declare the node’s serving window instead so eRPC routes by block height and skips the wasted attempt: set evm.blockAvailability.lower.latestBlockMinus: 10064 on the self-hosted upstream — reth’s full-node pruning keeps account and storage history for roughly the most recent 10,064 blocks. (You may also see evm.maxAvailableRecentBlocks in older configs; it’s deprecated in favor of blockAvailability.) This tutorial keeps the reactive setup because it’s simpler and it’s exactly the behavior verify.sh proves. Run eRPC on the same box with host networking, so it reaches the node over the cluster network and the Cloud over the internet while its own ports 4000 and 4001 stay firewalled from outside. Point it at the node’s reth-rpc ClusterIP, which is routable from the k3s host (kube-proxy programs it into the host’s iptables). Prefer this over kubectl port-forward — a port-forward is a foreground process that dies on every disconnect and silently drops the self-hosted upstream: # reth-rpc ClusterIP (stable while the node exists; re-read it if you redeploy the node) SVC_IP=$(kubectl -n control-panel-deployments get svc -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.spec.clusterIP}{"\n"}{end}' | awk '/reth-rpc/{print $2}') cat > erpc.env <<E SELF_HOSTED_RPC_URL=http://${SVC_IP}:8545 CLOUD_RPC_URL=https://ethereum-hoodi.core.chainstack.com/<KEY> E docker run -d --name erpc --restart unless-stopped --network host \ -v $(pwd)/erpc.yaml:/erpc.yaml --env-file erpc.env ghcr.io/erpc/erpc:main Changing an upstream URL later? docker restart erpc does not re-read --env-file — the env is fixed when the container is created. Edit erpc.env, then docker rm -f erpc and docker run … again. A plain restart leaves the old URL baked in and eRPC keeps hitting the stale endpoint. eRPC boots with both upstreams and the network ready: upstreamId=self-hosted-eth ... bootstrapped evm state poller upstreamId=chainstack-cloud-eth ... bootstrapped evm state poller networks bootstrap completed Test and prove the split scripts/test-routing.sh fires representative calls; scripts/verify.sh reads eRPC’s Prometheus metrics (erpc_upstream_request_total) and asserts which upstream served each. The archive path works immediately, even while the node is still syncing: curl -s http://localhost:4000/main/evm/560048 -H 'Content-Type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"trace_block","params":["0x1"]}' # served via the Cloud upstream ✓ Full split (recent → self-hosted, archive → Cloud) requires the self-hosted node fully synced (eth_syncing=false) — until then eRPC treats it as unhealthy and routes everything to Cloud. Once synced: ./scripts/test-routing.sh && ./scripts/verify.sh # PASS: recent call served by self-hosted # PASS: archive call served by Cloud Output from a real run, with the node at tip (eth_syncing=false): $ curl -s http://<reth-rpc ClusterIP>:8545 -d '{"jsonrpc":"2.0","id":1,"method":"eth_syncing","params":[]}' {"jsonrpc":"2.0","id":1,"result":false} $ ./scripts/test-routing.sh && ./scripts/verify.sh == recent (expect served by self-hosted) == { "jsonrpc": "2.0", "id": 1, "result": "0x306a42" } == archive method (expect served by Cloud) == == old-state read (expect failover to Cloud on pruned state) == { "jsonrpc": "2.0", "id": 1, "result": "0x0" } PASS: recent call served by self-hosted PASS: archive call served by Cloud The split is confirmed in eRPC’s own metrics: erpc_upstream_request_total{upstream="self-hosted-eth", category="eth_blockNumber",finality="realtime"} increments on recent reads, while {upstream="chainstack-cloud-eth",category="trace_block"} carries the archive calls. Use it from your machine Your code doesn’t have to live on the server. eRPC’s ports stay firewalled, so reach them over an SSH tunnel — encrypted, no firewall changes, and no need to bolt authentication onto eRPC: ssh -i ~/.ssh/hoodi_key -N -L 4000:localhost:4000 root@<SERVER-IP> While the tunnel is up, anything on your machine — a bot, a script, curl — uses the hybrid endpoint as if it were local: http://localhost:4000/main/evm/560048 Add -L 4001:localhost:4001 to the same command if you also want the Prometheus metrics. Two notes: Every request makes a round-trip to the server, so this is for development and testing. A latency-sensitive app belongs on the box, next to eRPC. Avoid opening port 4000 to the internet instead: this config has no authentication on the endpoint, so exposing it publicly hands your node — and the Cloud key behind it — to anyone who finds it. Going further On mainnet / Base, the full node is bigger (2–3.5 TB NVMe) but the archive-offload savings are real — you avoid self-hosting a fast-growing archive and pay Cloud only for the slice you can’t serve. Same eRPC config, different chainId. The pattern generalizes to any EVM network supported by Chainstack Self-Hosted, such as Optimism, Base, Unichain, or Zora. Conclusion One server, two RPC upstreams, one endpoint your applications talk to. Recent traffic hits hardware you own at flat cost; archive traffic hits Chainstack Cloud and bills only for the slice your full node can’t serve. eRPC routes and caches between them without touching application code. The full repo includes the erpc.yaml, the provisioning script, and the verification scripts referenced above. Fork it, swap chainId for your chain, and point the two endpoint env vars at your own nodes. Deploy Chainstack Self-Hosted → FAQ What is a hybrid RPC setup? A self-hosted node handles the majority of your traffic (recent state, standard reads) while a managed provider handles archive-heavy or method-specific requests, both behind a single endpoint. Applications see one URL; the router decides which upstream serves each request. Do I still need a Chainstack Cloud account if I self-host? Yes, for the archive side. Chainstack Cloud provides the archive endpoint for trace_*, debug_*, and old-state reads that a full node can’t serve. The self-hosted node handles everything else at flat hardware cost. What happens when my self-hosted node goes offline? eRPC’s retry policy promotes the request to Chainstack Cloud after the primary times out or errors. Applications keep working; the visible change is a small latency increase per request while the self-hosted node recovers. Chainstack Self-Hosted’s built-in monitoring alerts on the node, and pods restart automatically on most failure modes. Which methods route to which endpoint? Recent-state methods (eth_call, eth_getBalance, eth_getBlockByNumber at recent blocks, eth_getLogs, transaction submission) go to the self-hosted node. Archive methods (trace_*, debug_*, deep historical state reads) go to Chainstack Cloud via ignoreMethods on the primary upstream. Edit ignoreMethods in erpc.yaml to change the split. Can I use this pattern on Solana or non-EVM chains? Not with eRPC — it routes EVM JSON-RPC only. The general pattern applies to any chain, but the router changes. How is this different from just running my own node with bash scripts? Chainstack Self-Hosted provides a Kubernetes-native control plane with automated deployment, snapshot sync, integrated monitoring (Prometheus, Grafana), and coordinated client updates. Running the same node from scratch with bash is possible; the operational overhead is what makes teams abandon self-hosting. See DIY vs Chainstack Self-Hosted for the full comparison. Related reading Self-hosted blockchain node: challenges and solutions DIY vs Chainstack Self-Hosted Deploy a Chainstack Self-Hosted Ethereum node Chainstack Self-Hosted documentation eRPC upstream project Full repo: chainstacklabs/self-hosted-erpc-hybrid #### Cutting down on time-to-market with SPARK+ How can Web3 developers maximize their impact on the blockchain ecosystem? We’ve been asking ourselves the very same question, as developer success is directly tied to ours as an infrastructure provider. And above anything else, actively contributing and collaborating with each other to grow and BUIDL innovative solutions, stands out well above the rest. By sharing their knowledge and expertise, Web3 developers can take the central stage in shaping the next big break in decentralized technology. That is why, we are excited to officially unveil our partnership with SPARK+, whose primary purpose is to do just that—to empower blockchain developers and contribute to their continued growth and success. Fusing robust Chainstack infrastructure on the hardware side with SPARK+’s proficiency in specialized software development for Web3, we seek to equip developers with the tools and resources they need to truly unleash their creativity and ingenuity in full. What is SPARK+? SPARK+ stands at the bleeding edge of today’s tech frontier, providing blockchain developers like yourself with the tools and platform you need to excel across the Web3 landscape. With expertise spanning every aspect of blockchain development, including tokenization, DApps development, smart contract and protocol development, SPARK+ brings unparalleled expertise to the table. More than just a service provider, SPARK+ positions itself as a valuable mentor guiding you along your journey through the decentralized landscape. Their unique consultancy process features to-the-point market research to help you navigate common pitfalls, so you can focus on core business challenges, marketing, business development and driving the organization forward. But perhaps most promising is SPARK+’s wide array of turnkey, market-ready solutions. Thanks to these, you won’t have the need to start from scratch, allowing you to cut down on time-to-market and ship faster than you ever could at your own pace. This is especially true, considering the comprehensive set of verticals they cover: Crypto banking, wallets, and payments Web3 social media Document issuance and verification DeFi and NFTs Asset tokenization and fractionalization Lotteries and gaming Voting and ballots DAO and crowdfunding  E-commerce Travel and tourism Workforce development And as a Web3 developer, looking for a break-through in any of these fields, this could very well be your hidden ace under the sleeve that gives you the edge you need to overcome the competition. Connecting key partners SPARK+’s impact doesn’t just reside in its innovative blockchain solutions. Its influence reverberates through the global blockchain scene, evidenced by its strong partnerships and collaborations with recognized players like Chainlink, Stripe to name a few, and now Chainstack too. This solid network provides SPARK+ with a global panoramic view, enabling the team to anticipate trends, locale-specific requirements, and the bleeding-edge that decentralized technology has to offer. For developers like you, this means tapping into this expanded global network and getting priceless market insights, business intelligence, and breakthrough tech. SPARK+’s collaborative record stands as a testament to its team’s commitment, ability, and determination. Backed by this profound collaborative network, SPARK+ provides you with the means to break new grounds and create a lasting impact on Web3 that sets the stage for blockchain’s next defining moment. Chainstack x SPARK+ And this is exactly what makes our partnership with SPARK+ especially significant for blockchain developers worldwide—it’s not just about our individual strengths but rather how we apply them together in synergy. We are converging our collective insights, expertise, and award-winning solutions towards one shared mission—giving the tools Web3 developers need to push the boundaries of decentralized applications. And in doing so, we ensure a smooth, productive, and inspiring developer experience , facilitating quicker time-to-market and higher efficiency for everyone. This means bringing together SPARK+’s wide array of market-ready whitelabel solutions and our robust and reliable infrastructure, creating a conducive, innovative, and seamless ecosystem for blockchain developers. Thanks to this, Web3 developers like yourself now have the power to leverage this collaborative initiative to create exceptional Web3 experiences, and make your mark in the fast-evolving world of decentralized technology. Bringing it all together As the horizon of decentralized technology continues to expand, the need for collaborations that genuinely foster growth and innovation becomes paramount. Our partnership with SPARK+ is a testament to this belief, marking a significant milestone in our commitment to empower Web3 developers. Together, we are laying down a foundation that brings together the best of both worlds—Chainstack’s unmatched infrastructure and SPARK+’s in-depth expertise. As we unite our strengths, we pave the way for a brighter, more collaborative future in the Web3 landscape. We invite every Web3 developer to be a part of this journey, leveraging this powerful alliance to sculpt the next chapter of blockchain evolution. Together, let’s build, innovate, and shape the future of decentralized applications one block at a time. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Cyvers nets up to 335% ROI on Archive Nodes with Debug & Trace Accelerating Web3 security with AI-driven automated proactive protection. Chainstack’s reliable elastic infrastructure, combined with powerful debug and trace tools, has been instrumental in our operations. We’ve achieved an impressive 300%+ ROI on archive nodes, setting new standards in the Web3 security landscape. Meir Dolev, Co-Founder & CTO, Cyvers As we sail through an era where cryptocurrencies are spearheading the fintech world and blockchain technology is revolutionizing traditional infrastructure models, the importance of ensuring high-level security has escalated. Among the pioneers in augmenting this path to safety is our esteemed client, Cyvers, a frontrunner in proactive Web3 security. Our partnership with Cyvers, which excels in real-time detection and prevention of crypto attacks, has been a journey worth noting to say the least. Cyvers’ strategy extends beyond just security provision. With their AI-based platform, they identify patterns and anomalies across Web3 in real-time, thereby spearheading proactive mitigation. Their portfolio, impressively broad, caters to everything from DeFi protocols and custodians to established financial institutions and crypto services. We’re excited to share how Cyvers has leveraged Chainstack’s robust infrastructure and broad chain coverage to optimize their operation. Let’s explore the details. Why Cyvers chose Chainstack as its infrastructure partner When Cyvers first approached us, they were in search of a reliable, low-latency RPC provider that could guarantee dependable data delivery. They needed a round-the-clock assurance to ensure that no transactions or blocks on the blockchain were lagging behind with their synchronization—a key requirement for a company that proactively safeguards against crypto attacks. Their impression of us was significantly positive, especially after they had realized the fantastic results during their testing phase with Chainstack. Despite running simultaneous tests with various data providers, Cyvers found a distinct resilience and reliability in our offerings. Initially, Cyvers approached us to help them establish a full tolerance system. Moreover, they were looking to delegate the intricate and often tedious task of node maintenance, thus allowing them to focus more time and resources on their core competencies. We offered a range of advanced features that particularly caught their attention. Our clean interface and broad chain coverage, coupled with debug and trace capabilities, made it easy for them to make the most of our platform. Moreover, our affordable pricing model, specifically for archive data, made us a perfect fit for them, resulting in 67% lower costs than competitors. In turn, this has netted them an incredible ROI on archive nodes of 335%. Cyvers on Chainstack in numbers Cyvers currently employs a solid 11 active elastic nodes, deployed across multiple protocols like Arbitrum, Avalanche, BNB Smart Chain, Ethereum, and Polygon to ensure expansive coverage across a broad spectrum of chains. And since Debug & Trace was primarily what they were after, a staggering 95% of all requests were processed by archive nodes. Our multi-chain flexibility allows Cyvers to distribute requests across multiple chains. We saw about 37% of requests went to BNB Smart Chain, 33% to the Polygon network, just below 14% went to Avalanche, while Arbitrum and Ethereum both got roughly 8% each. These numbers are a testament to the value Cyvers found in their partnership with Chainstack, and it highlights how they’ve efficiently used our extensive multi-chain coverage, affordability, intuitive interface, and extensive Debug & Trace capabilities to streamline their operations. What is Cyvers? Cyvers is an industry leader when it comes to providing proactive security for Web3 platforms. They have built a solid reputation in the crypto industry, specifically in the prevention and real-time detection of crypto attacks. At the heart of their operations is the vision to ensure that Web3 applications and transactions are secure, thereby contributing to the credibility and robustness of the blockchain ecosystem at large. They specifically offer advanced protection mechanisms to an array of clients—from DeFi protocols and cryptocurrency exchanges to financial institutions and asset custodians. Beyond just detecting incidents, they are quick to respond and often proactive enough to spot anomalies and risks even before they occur. Figure 1: Cyvers H2, 2023 detections above $1M; Source: Meir Dolev Anchoring their services is their unique, AI-based platform—VigiLens. The platform identifies patterns and anomalies across blockchains in real time. In turn, this allows for continuous monitoring, on-the-fly mitigation, while ensuring all-round visibility and insights on their clients’ assets. Figure 2: Cyvers blockchain traceability; Source: Cyvers In addition, their suite of products, including the real-time detection software AddresShield and the Malicious Contract API, break new ground in cross-chain monitoring, transaction scrutiny, and proactive risk mitigation strategies. Cyvers is undoubtedly leading the charge in blockchain security, making it a perfect partner for institutions stepping into or stepping up their game in the digital assets arena. Bringing it all together In the world of Web3, security isn’t an option, but a compulsory lifeline that ensures the smooth sailing of blockchain and cryptocurrency ventures. For a company like Cyvers, remaining one step ahead is not a catchphrase, but an everyday reality, a necessity even. Their journey with us at Chainstack has been about constant vigilance. From the moment they came onboard, Cyvers actively utilized our elastic archive nodes, and benefitted from our broad chain coverage and debug trace functionalities. Our partnership has armed Cyvers with the necessary tools and functions to provide the best possible proactive Web3 security in the business. What stood out, in the end, was more than just the offerings. They expressed appreciation for our straightforward pricing model, emphasis on underlying usage rather than complicated calculations, great customer support, and above all, the peace of mind that comes with the assurance of reliable data for their critical security operations. Thanks to this Cyvers was able to reach 67% higher cost-effectiveness for an archive infrastructure ROI of 335%. As we keep forging ahead in our partnership with Cyvers, we remain motivated by our shared vision—securing the world of Web3. We do this one block at a time, cementing a safer and brighter future. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Darkpool Liquidity on Chainstack: Boosting competitiveness of new projects in crypto markets Darkpool Liquidity is a crypto-focused market-making firm that has serviced over 150 clients and crypto startups in the industry. The firm offers algorithmic market-making, advisory, and a treasury management service using proprietary trading software. What does Darkpool Liquidity do? Darkpool Liquidity is a digital asset market-making firm that is mostly known for creating the Binance API, one of the most advanced and widely used APIs in the blockchain ecosystem today. Darkpool Ventures is the venture capital and incubation arm of Darkpool Liquidity, focused exclusively on early-stage venture capital investment and advisory deals. Darkpool Liquidity brings an extreme advantage to clients with their trading and market-making operations. Utilizing proprietary trading software, Darkpool Liquidity confidently generates consistent profit under any market conditions. Providing sustainability as a core service, Darkpool prioritizes its strategy in promoting the growth of working capital over time and the ability to recover any quote currency invested at a profit, recovering funds for teams and investors without affecting the market price. The Darkpool Liquidity key advisory service has helped numerous clients to be well positioned to capitalize on current or future market conditions. The Darkpool advisory strategy effectively elevates investors’ confidence in any project. By maintaining tighter spreads and creating a liquid market with Darkpool Liquidity, market makers can leverage greater visibility to potential investors and simultaneously generate consistent profits and grow operationally. How did Darkpool Liquidity come across Chainstack? The team at Darkpool Liquidity believes in providing the highest quality of service to their clients, and when it comes to their own blockchain infrastructure needs, nothing but the best makes the cut. They initially trialed a self-managed setup but quickly realized that they needed the help of a highly skilled team who could customize and optimize continuously to ensure the best performance, no slippage, and reliable uptime. After evaluating several other managed blockchain service providers, the team at Darkpool Liquidity realized that Chainstack was the perfect match. How does the Chainstack offer match Darkpool Liquidity needs? After looking at several options available on the market, the team at Darkpool Liquidity chose Chainstack due to the high level of experience of the Chainstack engineers in optimizing node performance for fast transaction listening and execution. This, paired with very accessible pricing, made Chainstack top the list and become a long-term partner for Darkpool Liquidity. Chainstack could provide highly performant infrastructure for Ethereum, BNB Smart Chain, and Polygon with dedicated node infrastructure deployed on multiple fully managed public cloud hosting options, and optimized for low-latency, production-grade workloads with the fastest transaction propagation possible. The Chainstack high-availability architecture allows for seamless scaling and failure-resilient infrastructure thanks to nodes capable of high traffic and stable transactions. This reliability has helped the team at Darkpool scale their platform and achieve operational excellence with ease. On top of that, Chainstack professional services helped Darkpool with integrating marketplace tools and services; the Chainstack infrastructure was highly compatible with setting up blockchain distribution networks such as bloXroute’s BDN gateway; and Chainstack priority support provided experienced builders and engineers to work closely with Darkpool at every step. Chainstack consistently maintains deep industry partnerships with leading blockchain platforms, staying on top of emerging networks in the constantly evolving landscape of blockchain. This means that Darkpool can rely on Chainstack to be a modular infrastructure platform that is built for the future. Outcome Powered by the Chainstack platform and managed services, Darkpool can automate the infrastructure network operations with databases and the blockchain application all on a single platform. Having uncompromised connectivity, security, and performance, Darkpool doesn’t need to waste time worrying about maintenance or upgrades to nodes. The affordable and predictable pricing structure of Chainstack allows Darkpool to accurately allocate resources to improve its core services, focusing on developing the important product optimization and products in the betterment of Darkpool’s trading and market-making operations. The partnership with Chainstack has opened avenues to a wider range of customization options that help Darkpool improve the performance and utility of its platform. Services such as GraphQL and bloXroute have transformed and streamlined multiple operational processes and business functions. Supported by Chainstack’s experienced team, Darkpool can develop on various networks and protocols with ease, integrating blockchain distribution networks and tools, expanding Darkpool’s platform at scale in a short period of time. What does Darkpool Liquidity like about Chainstack? Having the infrastructure, database, and blockchain application running on one platform made it so much easier for us to expand our platform very quickly and at scale. With Chainstack, networking and backup are highly automated, so our lean development team are more focused on business solutions that add value to our customers. Jon Eyrick, CTO of Darkpool Liquidity What does Chainstack like about Darkpool Liquidity? Darkpool Liquidity has been a trusted liquidity solution provider and advisory firm to various esteemed projects in the cryptocurrency and blockchain market. Darkpool’s solutions has helped projects from incubation stages to being listed on the largest centralized and decentralized exchanges. Chainstack’s dedication to bring success to customers has perfectly aligned with Darkpool attention-to-detail, sustainable and performance-focused market-making strategy. The partnership of two highly experienced service providers brings the cutting-edge innovative technology solutions that accelerate the growth of all customers and stakeholders on the market. What is the most interesting engineering challenge in working together? Darkpool facilitates liquidity in the market, ensuring the true value of assets and raising awareness and confidence of investors thanks to deep expertise and proprietary trading technology. The commitment to service excellence and advancement of technology innovation is similar to how Chainstack strives to remain a technology leader for enterprise blockchain and Web3. Galvanized by the challenge of supporting a fast-growing platform at scale that could support a wider market, Chainstack has provided direct support in the testing and development of a tailored solution that would meet Darkpool’s infrastructure requirements. The one-size-fits-all solution is not the answer when it comes to various working functions on the network especially in Web3. Thanks to Chainstack’s dedicated support, the combined partnership has led to exponentially beneficial optimization on the platform. The customizability and integrated services have proven highly effective in bringing incremental improvements to Darkpool Liquidity and transformed the business moving forward. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Decentralized Business Process Management (BPM) for entire ecosystems Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Organizations have many internal processes—either standalone or inter-related—that operate within single business units or are cross-functional. Externally, organizations also work with entities within vast, complex value chains and are embedded within a web of multi-level business or governmental networks, such as suppliers, customers, partners, banks, shippers, regulators, and even competitors. Managing internal and external processes and workflows in such an environment is complicated. Business process management and business process management software defined  The discipline of Business Process Management (BPM) has been used by many organizations in the past few decades to model, automate, execute, control, measure, and optimize processes and workflows in support of organizational goals. Business Process Management Software (BPMS) is a technological suite of tools designed to help BPM professionals and business architects accomplish their goals in: optimizing processes and workflows; reducing costs and turnaround times; increasing flexibility, agility, compliance, and collaboration between entities.  While a workflow facilitates the simple routing of tasks or activities between parties with the aid of automation to support a process, BPMS—a superset of workflows—also connects disparate systems, offers analytics insights across business capabilities, and offers modeling tools with rules management. New technologies and trends supporting BPM Modern-day BPMS solutions leverage new technologies that offer organizations more automation and intelligent routing, which catches errors early in the process and reduces the need for manual intervention from humans. Some examples of these new developments are: Robotic Process Automation (RPA) or bots which deal with task automation that mimics human behavior for common, repetitive, manually intensive activity, e.g., scraping, copying and pasting data between applications, or chatting to users to determine their needs before routing them to the correct workflow. RPA can be optimized by using cognitive-based technologies such as Machine Learning (ML), natural language recognition, and speech recognition.   Adaptive Case Management (ACM) to support users with alternate, more effective decisioning for business processes in a changing environment. Low Code Development Platforms (LCDP) which allow users to quickly create, customize, and deploy functional, cross-functional, and cross-organizational business processes. These tools may have drag and drop UIs which allow a user to visually design and implement a business process.  Internet of Things (IoT), where external devices trigger business processes based on events generated from remote devices.  Artificial Intelligence (AI) to automate routine tasks, improve user interfaces, analyze large amounts of data, and aid decision making. BPM challenges  With all these new technologies, organizations still have handovers of information in different formats between multiple central systems, using various middleware solutions and intermediaries, with a combination of manual and automated steps in a trust-less environment.   There are also “shadow business processes” where no organizational policies or rules exist for activities that must be done. Gartner predicts that 20% of these “shadow business processes” are supported by BPM cloud platforms—e.g., spreadsheets, routing of emails using rules, phone call routing, messenger solutions, etc. This can lead to: Duplicate transactions. Stale or unconcluded transactions. Sidestepping of processes, which allows for fraudulent submissions and signatures. Bottlenecks and delays in processes. Half implementations, where multiple manual or off-chain processes are necessary. Man-in-the-middle attacks. Reconciliation solutions—systems or operational staff—are required to handle exceptions, anomalies, and errors. Distributed Ledger Technology addresses multiple BPM challenges across industries  I see a perfect opportunity for Decentralized Ledger Technology (DLT) to benefit BPMS implementations and offer the industry-wide digital transformation benefits we are all seeking across our value chains. Modern business requires dynamic collaborations among organizations, where globalization, increasing regulation and competition urges the need for: Accuracy; Speed;   Privacy and security;  Reliability and flexibility; Scalability and agility; and trust.  Multiple DLT technologies are currently available, and at Chainstack we believe that there is no single DLT solution that is best suited for all use cases. Based on the use case you are addressing, you should select a technology and protocol considering the attributes, such as scalability, speed, privacy, confidentiality, developer-friendliness, fault tolerance, interoperability, and agility. R3 Corda That said, I see R3’s Corda a natural fit for the needs of enterprise and governments, where a BPM or Business Architecture discipline may be in operation to optimize inter- and intra-organizational processes between multiple parties. Corda is a DLT platform that allows multiple parties running their own nodes—running their own CorDapps, applications with their own vault and database—can exchange data or value with each other on the same network while benefiting from the following features: This flow framework is where I really see the natural fit of Corda’s DLT benefiting the BPM discipline. Richard Gendal Brown, CTO at R3, recently highlighted how many of their customers are, in fact, using Corda to manage “Market-Level” business processes. Key Corda components  These are the key components within Corda’s solution architecture that relate to the management and execution of business processes, and retain a record of it.  CorDapps, or Corda Distributed Applications, are distributed applications that run on the Corda platform. The goal of a CorDapp is to allow nodes to reach an agreement on updates to the ledger. They achieve this goal by defining the flows that Corda node owners can invoke over RPC. Flows are embedded within CorDapps and deployed to a participant’s node for execution. A flow encodes a sequence of steps that a node can perform to achieve a specific ledger update. By installing new flows on a node, we allow the node to handle new business processes. They enable complex multi-step, multi-party business transactions and interactions, without the need for an intermediary.  Transactions in Corda are the atomic units of change that update the ledger. Contracts define the rules and conditions on what transactions constitute a valid ledger update.  States are an atomic unit of information in Corda. They are never changed, are current, and are known by one or more Corda nodes.  Corda and BPM  Corda’s flows can be used to manage business processes between entities where they introduce trust, reliability, and accuracy of the atomic tasks and transactions. Third-party validators or notaries—individual or a group—can observe and sign transactions to ensure the uniqueness and validity before it is recorded on the ledgers of only those parties involved in the transaction, which ensures confidentiality is maintained.  With Corda, every party involved in a transaction within these consortia knows with certainty what happened, when it happened, and can confirm the other parties are seeing the same thing, with no need for an intermediary to provide assurance, and without having to reconcile multiple copies of data afterwards. This results in no need for a reconciliation solution to manage duplicates, exceptions, or mismatched records stored in the databases of each party. Business Processes that are supported by smart contracts on Corda can be executed faster as activities can be executed automatically if certain conditions within the flow are met. The specific features that Corda customers are leveraging to manage their Market-Level business processes are listed on this slide from Richard Gendal Brown at CordaCon 2019: Corda is not going to replace modern-day BPMS solutions. Like RPA, ML, ACM, LCDP, IoT, AI, and other emerging technologies, I believe Corda offers multiple benefits that contribute to the BPM discipline, and I look forward to seeing them integrated into BPMS suites and more business implementations.   To facilitate the rapid deployment of new business processes, I believe R3 should consider adding or integrating with an LCDP in the future. This will enable process analysts, business and process architects with minimal or no coding experience to visually design and deploy process changes easily. Consortia running Corda  Multiple consortia have already formed between a number of entities globally, where Corda has been selected as the DLT to support the complex business processes and interactions around various industry use cases. MarcoPolo: 19 institutions, trade and working capital finance;  Voltron: 18 institutions, trade finance and documentary trade;  MonetaGo: 20 institutions, ports fraud mitigation; Ubin: 16 institutions, central bank digital money;  B3i Tech: 18 institutions, insurance and reinsurance; Tradle: 15 institutions, KYC. Corda can be used to support solutions in any industry that has organizations sharing data between internal or external entities. Getting started with Corda  Chainstack offers a Blockchain Platform as a Service solution that allows you to create, deploy, and manage a number of DLT networks, including Corda, onto a choice of cloud platforms in mere minutes, from its simple control panel that requires no coding.  Multiple companies can be participants on a consortium project on a Corda network, working together with different members on the network to streamline various business processes, reduce costs, processing time, conflicts and errors with their own self-defined network standards. No business can operate without a foundation of sound, stable yet flexible business processes, and Corda, with its upgradable CorDapps and an advanced flow framework, supports these needs. Register and launch a Corda network for free Build a CorDapp with Chainstack References  Smarter BPM with AI, by Laura Perez Prepare Now for AI & BPM, by K2.com The History of BPM Software, by Elizabeth Quirk BPM vs Workflow: What’s the Difference? by Sascha Cutura Flows can do anything, by David Newton When Is BPM Not BPM? Business Processes and Workflow are More than Buzzwords, by BP Logix 5 Trends of Business Process Management (BPM) by Comidor Business process management, Wikipedia Business Process Management (BPM), Gartner Glossary Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Decoding smart contract composability and why it matters for Web3 developers Smart contracts are the cornerstone of most blockchain networks, particularly those offering decentralized applications. They represent the rules and operations that facilitate transactions and interactions on the blockchain. When we discuss smart contract composability, we highlight the ability of these contracts to interact and collaborate, creating a network of contracts that can work together to create more complex and powerful applications. This composability is the key advantage of smart contract platforms and forms the backbone of exciting domains like DeFi, GameFi, DAOs, and more. What is smart contract composability? At its core, smart contract composability is the robust characteristic of blockchain tech that allows different smart contracts to seamlessly interact and work together, creating complex systems from simpler building blocks. Smart contract composability can be likened to Lego blocks—just as you construct unique structures using the same Lego pieces, smart contracts provide the same opportunity for building over pre-existing contracts to birth novel applications or systems. Simply, imagine each smart contract as a unique Lego block, compatible and ready to be a part of some larger structure without needing any modification. This software stacking potential reaches its zenith on platforms like Ethereum where every smart contract turns into a valuable building block. Composability’s essence lies in its drive to ease the lives of Web3 developers, enabling them to create novel applications without always having to start from scratch. This paves the way for swifter developments and innovative breakthroughs with developers building on the top of each other’s work. Composability in Ethereum, thus, acts as the foundation of numerous path-breaking DApps and decentralized systems. Smart contract composability advantages The importance of composability in the exciting world of blockchain and smart contracts cannot be stressed enough. It presents considerable advantages that facilitate rapid development and innovation. Let’s explore a few: Faster development One significant advantage is the pace at which developers can build new products when they do not have to start from the ground up. Code reuse enables software lifecycles to get significantly faster and efficient, turning the wheels of development quickly. Effective problem-solving Composability indirectly fuels ingenuity. With composable code, developers spend lesser time resolving repeated issues but focus more on new, unique problems. This paves the way for breaking novel grounds and inventing unique solutions which can be a game-changer in Web3 development. Easy integration Composable systems enable easier integrations. With increasing interoperability, plugging into different tools, DApps, or other software integrations becomes seamless ensuring a smooth user experience. Shorter development cycle From the perspective of decentralized applications specifically, composability significantly reduces developers’ workload. With freely available smart contracts to solve diverse issues, developers can add extra functionalities to existing software libraries for generating new DApps. This leads to a shorter development cycle—an advantage every developer appreciates. Greater innovation One of the hallmarks of a conducive development environment is its capacity to foster innovation. Composability does precisely that. Reuse, modification, and integration of open-source code drive development teams to experiment more with new features, thereby encouraging remarkable innovations. Smart contract composability challenges While composability lends several advantages, it also presents a few challenges that could potentially hinder its full potential. Let’s delve into some of these challenges. Value capture: One of the primary challenges with open-source, composable code is the question of value capture. Since everyone has access to the code, profiling unique selling propositions that distinguish your product could be a challenge. That calls for ingenuity in identifying new defensible “moats” like a DAO community, for instance. Scaling: The theory of composability is perfect, but practical implementation, especially in the contemporary multi-chain world, can prove complicated. Composability becomes considerably intricate and difficult to execute as scaling occurs—via layer two blockchains, alternative layer ones, and sharding. It may result in issues like fragmented liquidity across chains, turning into a potential surface of attack or, at the least, an inconvenience for token swaps. Security: An overlooked aspect of composability between chains and layers can become a severe security risk. When bridging assets, you are locking those assets in a smart contract. These contracts can become significant targets for attacks. Brief history of composability on the web Composability has played a significant role in shaping the internet we know today. Let’s trace back its course through the evolution of the web. The web’s evolution can be broadly categorized into three phases, often termed as Web1, Web2, and Web3. Web1: Open-source and composable Web1 was the initial phase of the internet which can be termed as the “Read” phase. During this era, webpages were static without any interaction capacity. The Web1 internet was built by an extensive, grassroots movement where open-source was at the core. Everything was public, composable, and open-source remnant of the early days of the internet. Web2: Mostly closed-source and not composable As the internet evolved into the “Write” phase or Web2, large companies started to lock things down. This phase saw the rise of closed-source code, restricted APIs, alongside a growth in Intellectual Property. To make money and outpace their competitors, companies began to rely on closed-source software and non-composable systems for distinctiveness. Web3: Open-source and composable The advanced Web3 phase brought back the tradition of composability and open-source, marking the advent of the “Own” phase in the internet’s evolution. It touted ‘forking,’ where a project takes up code from another project, makes modifications as needed, and develops it as their own product. The fact that everything on the blockchain is transparent by default reinstates that the code is open. How does smart contract composability work? Composability works based on a few core principles that allow for the seamless integration and operation of different smart contracts or software components. Elements of a composable smart contract There are three defining elements of a composable system: Modularity: Each component should ideally perform one thing well. Software components wrap multiple actions into a package, breaking them down into handy modules. Autonomy: Composable components should function independently. They are self-contained, meaning that if one thing is pulled out of the system, the whole system doesn’t collapse. Discoverability: The software elements are published somewhere that others can quickly find, like a GitHub repo or other website. Understanding these principles and elements provides a foundation of understanding how composability operates in smart contracts and the Ethereum network. Subsets of smart contract composability There are different types of composability handling various aspects of Web3 interactions. They are: Syntactic smart contract composability Syntactic composability is when all software elements can be forked, remixed, and used by everyone with an internet connection. In Ethereum, every smart contract on the open protocol can be called by any other. This means that developers need to solve new problems only once, after which the software becomes open for reuse by everyone else in the ecosystem. This approach significantly increases the efficiency of Web3 building, allowing teams to focus on building the missing components of their projects. Atomic smart contract composability Atomic composability is about bundling several operations or software elements into one. In the realm of DeFi, this means that multiple actions across different DApps can be packaged into a single transaction, to be executed concurrently. If one operation within the bundle fails, the entire transaction also fails. This approach minimizes the risk of partial failures and streamlines complex operations. Morphological smart contract composability Morphological composability refers to the use of standard languages or specifications—such as the ERC20 token standard—to port elements into other contracts. This composability type allows for tokens and other blockchain elements to interact with multiple different applications, moving freely within the Web3 world. Examples of smart contract composability Smart contract composability in action is best understood with a few examples. Here are some use-cases: Token swaps: Token swaps are a classic application, wherein a DApp might require transactions to be made in Ether, but users can pay in any ERC-20 tokens. The app’s smart contracts can just employ a swapping logic to automatically convert the tokens to Ether before executing the transaction. This swap logic could simply be another contract interfacing with a DEX like Uniswap. Governance: The realm of Governance offers another perspective. Building bespoke governance systems for a DAO can be quite challenging and time-consuming. Here, composability can come in handy by using open-source governance toolkits for rapid deployment of a governance framework. NFT gaming: In the gaming world, NFTs make use of morphological composability. An NFT from one game can be ported to another because of the standard language they both understand. This is especially useful because digital properties, represented by these gaming NFTs, are truly owned by the users, who can transfer them freely between games, trade them in secondary markets, or perhaps even use them as loan collaterals. Identity management: Identity management is yet another use-case for composability. Instead of building a custom authentication system or relying on centralized providers, you can integrate decentralized identity (DID) tools to manage user authentication. We can see that composability facilitated by smart contracts has played a vital role in shaping the current utility spectrum of Web3. This will continue to evolve as we uncover new ways to leverage composability in the decentralized context. Bringing it all together Indeed, composability stands as one of the most influential factors that power the capabilities of decentralized applications, propels the advancement in blockchain technology, and catalyzes a multitude of breakthroughs in the world of Web3. As we continue to explore the boundless horizon of decentralization, composability, as exhibited through smart contracts, will continue to mold the path we tread and define the world of blockchain. On this note, it’s also important to remember that while composability helps us build the remarkable, it also poses certain challenges—like maintaining security in a continuously evolving landscape and efficiently navigating the multichain realm. But as we watch developments unfold, we can only imagine the realms and corners this concept will illuminate, revolutionizing the path to a more decentralized world. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Dedicated node RPC pricing: what providers won’t share (2026) TL;DR Ask most of the biggest managed RPC platforms what a dedicated node costs and the answer is the same: talk to sales. Dedicated and enterprise infrastructure tiers across the market are typically sales-gated — no public number, no way to budget before a call. Chainstack publishes the formula instead: $199/month Pro plan, from $0.50/hour compute, $0.01 per 20GB/hour storage. A full Ethereum node — Reth + Prysm, ~2TB steady-state storage — comes out to roughly $1,279/month: a number you can calculate yourself, from three public figures, before you ever get on a call. Ethereum is the expensive end of the range — for a long list of other protocols, Chainstack’s actual dedicated node price comes in under $1,000/month and below the tracked market average for that same protocol. The real numbers are below, not projected. Why dedicated node pricing matters Shared RPC works until it doesn’t. Rate limits, noisy-neighbor latency spikes, and per-request billing that scales unpredictably with traffic are the three reasons teams move from a shared endpoint like Global Nodes to a dedicated node. At that point the infrastructure decision stops being about request quotas and starts being about isolated hardware, guaranteed throughput, and a monthly number that doesn’t move with usage. That’s exactly the point where most of the biggest managed RPC platforms stop publishing prices. What “dedicated” means across the market Most large managed RPC platforms offer some version of single-tenant node infrastructure — isolated hardware, guaranteed throughput, automatic failover. Pricing for this tier is almost never listed on the public site; the standard path is “talk to our team.” A few providers publish a range instead of a firm number — enough to signal scale, not enough to budget against. Independent pricing trackers that follow the space estimate these dedicated add-ons anywhere from the low hundreds to several thousand dollars a month depending on scope, which says more about how wide the negotiation range is than what any specific team would actually pay. Chainstack is the exception: Dedicated Node pricing is a published formula — a $199/month Pro plan (required to unlock the feature), plus from $0.50/hour compute, plus $0.01 per 20GB/hour storage. You can build the exact monthly number yourself before signing up — no sales call required to find out what you’d owe. Comparison table Provider typeDedicated pricing published?Full Ethereum node, estimated monthlyRequires sales call to get a numberChainstackYes — formula published~$1,279/mo (Pro plan + compute + ~2TB storage)NoLarge managed RPC platform (typical)NoCustom quote onlyYesProvider with public range onlyPartial — range, not a numberThird-party estimates: low hundreds–$5,000+/moUsually Chainstack’s figure is a calculated example (Pro plan + from $0.50/hr compute × 720 hours + $0.01/20GB/hr × ~2,000GB × 720 hours, matching the ~2TB steady-state storage Chainstack’s own docs specify for an Ethereum Mainnet full node), not a discounted or promotional rate. Actual compute cost can run above the $0.50/hour floor depending on configuration. Competitor figures reflect general market patterns and third-party pricing trackers as of mid-2026, not any single named provider; since most of the market doesn’t publish dedicated pricing, verify directly with a given vendor’s sales team before budgeting. Real numbers: dedicated nodes under $1,000/month that beat the market average The Ethereum figure above is the headline case because Ethereum is the most storage-heavy chain Chainstack supports — it’s not the typical bill. Across the protocols Chainstack prices, a wide set land under $1,000/month on the same $199 Pro plan + compute + storage formula, and come in below the tracked market average for that exact protocol, network, and mode. These aren’t projected estimates: they’re Chainstack’s current price for that configuration, set against the average of tracked competitor prices for the same protocol/network/mode combination. ProtocolNetwork / modeChainstack price/moTracked market avg/moChainstack vs. marketStablemainnet, full$730$2,430233% cheaperRoninmainnet, archive$547.5$1,800229% cheaperZoramainnet, full$445.3$1,235.33177% cheaperUnichainmainnet, full$562.1$1,220117% cheaperCelomainnet, full$766.5$1,541.67101% cheaperPolkadotmainnet, full$562.1$1,062.6789% cheaper Tracked market avg is Chainstack’s own tracked competitor pricing for that exact protocol/network/mode combination — the number of competitors behind each average varies by chain, so treat this as directional for your specific protocol, not a universal claim across the whole market. Figures current as of September 2026 and subject to change; confirm your exact configuration with the pricing formula above or the Chainstack pricing page before budgeting. Two more worth flagging even without a market figure to compare against: Robinhood Chain and Tempo are both available on Dedicated Node and come in cheap on their own. On Chainstack’s pricing calculator, Robinhood Chain (mainnet, full, ~550GB) comes out to $569.40/month; Tempo (mainnet, archive, ~500GB) to $547.50/month. Not a “cheaper than market” claim — just a real, checkable number on its own. Or skip the subscription entirely: Chainstack Self-Hosted Every number above still sits on top of a paid plan — the $199/month Pro tier is the floor before compute and storage get added. If Dedicated Node is still more than you want to pay, the direct answer is Chainstack Self-Hosted: $0 in licensing, the same deployment, monitoring, and self-healing automation, running on infrastructure you provide and control. There’s no $199 Pro plan requirement and no per-hour compute or per-GB storage line item billed by Chainstack — you pay your own infrastructure bill, not a Chainstack subscription. It’s the closest thing on this list to a self-managed dedicated node for free. Why most of the market doesn’t publish a number Enterprise sales-led pricing isn’t unique to Web3 infrastructure — it’s a common model when a product bundles custom SLAs, negotiated volume discounts, and dedicated account management. The trade-off is that you can’t budget against it until you’ve already had the conversation, and the same workload can plausibly land anywhere in a multi-thousand-dollar range depending on who you talk to and when. That’s a reasonable model for some products. It’s a harder sell for a line item you might want to comparison-shop before committing engineering time to a migration. How to choose Do you need a number today, not after a sales call? Chainstack is one of the only providers in the category with a published formula for dedicated infrastructure — you can compute your own estimate before signing up anywhere. What does your actual config cost? The formula is chain- and mode-specific: storage requirements vary a lot by protocol (an Ethereum full node runs ~2TB; a lighter chain or a pruned/light preset can come in well under that). Check the supported deployments storage figures for your chain before estimating, and see how Request Units billing works if you’re comparing against a shared plan. Do you already have an enterprise relationship elsewhere? If you’re already deep into a competitor’s ecosystem with negotiated enterprise pricing, the switching cost may outweigh the transparency gain — model both before moving, or see what Chainstack Enterprise offers on negotiated terms of its own. Would you rather skip a subscription entirely? Chainstack Self-Hosted runs the same deployment, monitoring, and self-healing automation on infrastructure you control, at $0 for the control plane itself. Getting started with Chainstack Dedicated Node Log in to the Chainstack console (or create an account) and click Deploy new node. Pick your protocol and network (mainnet or testnet). Select Dedicated Node as the node type — a Pro, Business, or Enterprise plan is required, with an estimated monthly price shown inline as soon as you select it. Choose full or archive data mode, the protocol client, and a region on Chainstack Cloud (or connect your own infrastructure instead). Name the node, assign it to a project, and review the summary — Dedicated Node ships with unlimited RPS. Submit — deployments go through review, live within up to 72 hours once approved, with pay-as-you-go billing enabled automatically. Automating this instead? The Platform API covers the same deployment. Need mempool access? Dedicated Node supports the txpool_* namespace on full or archive nodes, but it isn’t on by default — request it at deployment. Not ready for dedicated yet? Global Nodes covers the same 70+ chains on shared infrastructure — deployable from the console or straight from an AI assistant via Chainstack MCP — and Archive Data gets you full historical state without committing to a dedicated instance first. Conclusion Most providers in this category sell some version of “dedicated node.” Very few tell you what it costs before you talk to anyone. Chainstack’s published formula puts a full Ethereum node at roughly $1,279/month — a real, checkable number built from three public figures, where most competitors offer none at all. If the goal is a dedicated node with a price you can verify yourself before signing up, that’s the whole comparison in one sentence. Need a number you can check right now → Chainstack Already have negotiated enterprise pricing elsewhere → compare the actual contract, not the list price Want the same automation without any subscription → Chainstack Self-Hosted Explore Chainstack Dedicated Node → Frequently asked questions Why doesn’t most of the market publish dedicated node pricing? Most treat dedicated/enterprise infrastructure as a sales-led product bundled with negotiated SLAs and support, which is common for enterprise tiers industry-wide but means you can’t get a number without a conversation. Are there Chainstack dedicated nodes under $1,000/month? Yes. A meaningful set of protocols — Zora, Unichain, Celo, Stable, Ronin, and Polkadot among them — come in under $1,000/month on the same published formula, and below the tracked market average for that protocol. Ethereum’s ~$1,279/month sits higher because Ethereum’s storage footprint is large, not because the formula itself is expensive by default. Is $1,279/month typical across chains, or specific to Ethereum? That figure is for an Ethereum full node on the Pro plan with ~2TB of storage, matching Chainstack’s documented steady-state requirement for Ethereum Mainnet (Reth + Prysm). Storage and compute needs vary a lot by chain — archive nodes and heavier chains will cost more; lighter chains meaningfully less. Can I get a dedicated node on Chainstack’s Developer (free) plan? No — Dedicated Node requires a Pro, Business, or Enterprise plan ($199/month and up). The free Developer plan gives you shared Global Nodes access instead. How reliable are third-party estimates for competitor dedicated pricing? Take them as a range, not a quote. Different trackers report different numbers because the actual price is negotiated per customer, so any published range reflects that spread, not a fixed rate. What if I need multi-region failover or archive data — does the $1,279/month figure still hold? No. That number is a baseline full-node config. Multi-region deployments and archive storage both add cost on top of it — model those separately. Is Chainstack Self-Hosted a substitute for Dedicated Node? It’s a different trade-off, not a strict substitute. Self-Hosted gives you the same automation for $0 in licensing, but you provide and manage the underlying hardware yourself; Dedicated Node runs on Chainstack-provisioned or hybrid infrastructure. Additional resources Best dedicated node RPC providers (2026) Chainstack Dedicated Node Chainstack pricing Chainstack Self-Hosted Chainstack Global Nodes Chainstack Archive Data Chainstack Enterprise Platform API reference — create node Request Units documentation Chainstack MCP #### Deep dive into eth_call Eth_call is one of Ethereum’s standard JSON-RPC methods. It is a powerful development tool, but not many developers – even the most experienced ones – understand how it works. In this article, you will deep dive into eth_call. You will learn how EVM works behind the scenes; why you should use eth_call, and what the possible reasons that it fails to execute are. There are 4 parts in this article: Ethereum is a state machine…wait, what is a state machine? What are transactions and blocks? Eth_call use cases with example Conclusion Ethereum is a state machine…wait, what is a state machine? To understand how eth_call works, the first concept to learn is Ethereum’s data structure. Ethereum defines itself as a distributed state machine. So…what is a state machine? Every Ethereum clients keep the holistic information of the whole chain. This information includes: The account addresses Other information that is related to the account Balance Nonce storageRoot – for smart contract codeHash – for smart contract This information is known as the global state. The global state represents the condition that every Ethereum account is in at a specific time. It is consistently updated whenever a new block is generated. Ideally, all Ethereum nodes are synced to have the same state at all times. Figure 1: Ethereum nodes sync on state data Ethereum adapts PATRICIA MERKLE TREES for data storage. It has four tries implemented: State trie storage trie receipt trie transaction trie. The global state is stored in the state trie. The storage trie contains data for smart contracts. Each Ethereum account owns a separate trie, which is referenced by the storageRoot field from the global state trie. Figure 2: Ethereum data tries The transaction and receipt tries contain data for finalized transactions. They are updated whenever a block is created. Since a block is considered finalized after it is validated, these two tries are never modified after creation in normal circumstances. For simplicity, Ethereum clients keep two types of data: State data Historical transaction data The availability of state data is one of the most important factors to consider before sending an eth_call. What are transactions and blocks? Essentially, any transaction (including calling smart contracts) on Ethereum can be seen as a state update. Fund transfer A fund transfer is the most basic type of transaction. In terms of state change, a successful fund transfer causes a deduction in balance for one account and an increment in balance for another. The miner/validator receives the transaction’s gas fee too. Calling a smart contract There are two types of smart contract callings, read and write. Contract read methods retrieve information from a node. There is no real transaction happening, hence no state update for read calls, with no gas fee either. Write methods, e.g. storing information on chain, are considered an attempt to update the global state. Therefore, the sender must pay a gas fee to send a real transaction. If the transaction is successfully validated, the storage trie will update. For complex calls involving multiple internal transactions, the smart contracts are called and modified in sequence. Transaction failing What if a transaction fails during execution? The transaction will be void. Ethereum reverted to its original state. The sender loses the gas fee but nothing else. Pending transactions A pending transaction has nothing to do with the state. It just travels the network waiting to be validated. What is a block In practice, Ethereum’s state doesn’t change for a single transaction, the state only changes when a block is validated. A block consists of multiple transactions packaged together by a validator. After it is validated, it propagates to all nodes in the Ethereum network. When a node receives a new block, it updates its state information accordingly. Since blocks are usually immutable and Ethereum’s state only changes when a new block is validated, Ethereum’s state is usually referenced by the block number or block hash. Eth_call example + use cases So, what is eth_call? Eth_call immediately executes a new message call without creating a transaction. Its most fundamental use case is using it to execute read methods of a smart contract, but it can do a lot more: For example, many applications use eth_call to “simulate” the result before sending the actual transaction It can be used to check a token balance in the past You can also use it to check the outcome of a pending transaction It is also good for testing unpublished smart contracts Try it with Chainstack In this tutorial, the sample code is developed and tested with a Chainstack endpoint — it is highly recommended for the following reasons: Free 3 million requests. Eth_call available on all nodes Supports both Erigon and Geth Archive node available from $49/month, with 20 million requests Seamless node deployment. Follow these steps to deploy a node: Sign up with Chainstack. Deploy an Ethereum node. Get the deployed node’s endpoint. There are slight differences between a Geth node and an Erigon node. You can check your node type on the project page. To deploy an Erigon node, simply turn on the debug and trace APIs option when you deploy a node. Eth_call So what is eth_call? Eth_call is an Ethereum API method that executes a new message call immediately without creating a transaction on the blockchain. Parameters: object — the transaction call object with: from — (optional) the string of the address, the transaction is sent from to — the string of the address, the transaction is directed to gas — (optional) the integer of the gas provided for the transaction execution gasPrice — (optional) the integer of the gas price used for each paid gas, encoded as hexadecimal value — (optional) the integer of the value sent with this transaction, encoded as hexadecimal data — (optional) the string of the hash of the method signature and encoded parameters, see the Ethereum Contract ABI (opens new window). quantity or tag — the integer block number, or the string with: latest — the latest block that is to be validated. The Beacon Chain may reorg and the latest block can become orphaned safe — the block that is equal to the tip of the chain and is very unlikely to be orphaned finalized — the block that is accepted by two-thirds of the Ethereum validators earliest — the genesis block pending — the pending state and transactions block Returns: data – the return value of the executed contract What is eth_call There are two main types of eth_call: read contract calls and write contract calls. Read contract call A read contract call is probably the simplest eth_call. Try it out with the following sample code, remember to change the HTTPS endpoint: For Curl: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","data":"0x1526fe270000000000000000000000000000000000000000000000000000000000000001"},"latest"],"id":1}' https://your-end-point-url.p2pify.com/ABCDabcd It returns: {"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000397ff1542f962076d0bfe58ea045ffa2d347aca00000000000000000000000000000000000000000000000000000000000001d4c0000000000000000000000000000000000000000000000000000000000f5277800000000000000000000000000000000000000000000000095ad6b3115e07f95"} This example calls the poolInfo method from SushiSwap’s smart contract. It returns the liquidity pool state of SushiSwap. For example, if the input is 1, it returns the current state for the USDC-WETH pool. The call data is encoded, you can learn how the data objected is constructed from this article. No gas fee is needed for reading contract calls. You can use any address as the “from” address, or simply without specifying it. Write contract call This sample code is based on a successful withdrawal transaction from SushiSwap. Sample curl command: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},"0xF52579"],"id":1}' https://your-end-point-url.p2pify.com/ABCDabcd Output: {"jsonrpc":"2.0","id":1,"result":"0x"} Different from a read contract call, write contract calls require the account to have enough balance to pay for the gas fee, even though no actual gas will be consumed. This example is called on block “0xF52579”, which is the block this transaction was executed; running it on a non-archive node will likely result in an error. By now you may have a fair guess why this error occurs; If you don’t, reading on will help you understand how eth_call works better. Common questions Q. When you send an eth_call against an old block, what is the value returned? A. The value is based on the old state. For example, if you send a read contract eth_call to Uniswap checking the balance of a specific token, but the block you specify is two years old; You will get the token balance from two years ago. The same applies to a write contract eth_call: If you are calling against an old block, it only tells you if the call would pass/fail based on the historical state. Not the current state. Q. I send an eth_call with a transaction that was successfully executed before, but it fails. Why? A. This is most likely related to the previous question. The state data changes constantly. It is totally normal for a successful transaction to fail in a new state. For example: The sender may not have enough balance to pay for the gas fee The receiver may be blacklisted The smart contract may be modified So please remember to choose the block number carefully. Q. Can eth_call be used to simulate a fund transfer? A. Yes. For valid fund transfer, it returns: {"jsonrpc":"2.0","id":1,"result":"0x"} else it will return {"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"insufficient funds for gas * price + value: address 0x5FFFFFFF…………… have 1234 want 1234567890"}} For a fund transfer, you need to specify the “from” address, “to” address, gas, gasPrice, and the value to transfer. A curl sample with Chainstack endpoint: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"from":"0x5b10c7ea7c186495c84c2266a7f1f775afce342a","to":"0x5b10c7ea7c186495c84c2266a7f1f775afce342a","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Q. What does it mean by “missing trie node” error A. It simply means that the state is not available. The block number you enter is either invalid or does not exist anymore on the node. An Ethereum full node by default only keeps the most recent 128 blocks of data (AKA tries). You can learn more in this article. Q. To send eth_call, user can specify the block as a number/hash, “latest”, ”earliest” or “pending”. What are they? A. If you specify a number/hexadecimal string, the client will run it against an old block state with the specific block number. “Latest” block for the current state. The “Earliest” block is the earliest block available. For a full node, it is usually 128 blocks from the current block. The “Pending” block is an imaginary block that will likely be validated next. However, it is not guaranteed. Normally, the real block validated differs from the “pending” block. Q. Does the block number represent the state before block execution or after? A. After. To rerun a successful transaction in block 100, you need to specify the block as 99. Q. What does it mean by “cannot unmarshal number into Go value of type string” error A. This means one of the value inputs is supposed to be a string, but the input is a number. Please take note that for an Erigon client, the block number can be either a hexadecimal string or a number; For a Geth client, the block number must be hexadecimal. Q. If I run eth_call, then another eth_call, would the result of the second call be based on the first call? A. Nope, multiple eth_call requests are executed independently. However, if you need to run eth_call in sequence, Erigon’s trace_callMany may be the method you are looking for. State override A non-standard feature both Geth and Erigon support is state override. State override allows the user to run eth_call with customized states. State override set The state override set is an optional address-to-state mapping, where each entry specifies some state to be ephemerally overridden prior to executing the call. Each address maps to an object containing: FieldTypeBytesOptionalDescriptionbalanceQuantity<32YesFake balance to set for the account before executing the call.nonceQuantity<8YesFake nonce to set for the account before executing the call.codeBinaryanyYesFake EVM bytecode to inject into the account before executing the call.stateObjectanyYesFake key-value mapping to override all slots in the account storage before executing the call.stateDiffObjectanyYesFake key-value mapping to override individual slots in the account storage before executing the call. The goal of the state override set is manyfold: It can be used by DApps to reduce the amount of contract code needed to be deployed on chain. Code that simply returns internal state or does pre-defined validations can be kept off chain and fed to the node on-demand. It can be used for smart contract analysis by extending the code deployed on chain with custom methods and invoking them. This avoids having to download and reconstruct the entire state in a sandbox to run custom code against. It can be used to debug smart contracts in an already deployed large suite of contracts by selectively overriding some code or state and seeing how execution changes. Specialized tooling will probably be necessary. state override parameters for eth_call For example, the below transaction will fail because of insufficient funds: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xFFFFFFFFFFFFFFFFFFF"},"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd With state override, we can set the account balance to any number for testing purposes: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xFFFFFFFFFFFFFFFFFFF"},"latest",{"0x1111111111111111111111111111111111111111":{"balance":"0xFFFFFFFFFFFFFFFFFFFF"}}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Conclusion This is the end of this article. Hope you will find it useful. Thanks for reading. If you have any questions, feel free to ping me on Twitter/Telegram/Discord. Happy coding. Cheers! #### Deep Dive into Ethereum debug_trace APIs At the time of writing (Nov 2022), there are 7,000+ Ethereum nodes running in the world. 79% of them are Geth and about 21% are other types of clients. Figure 1: Ethereum node distribution Geth and Erigon are the two most popular Ethereum clients on the market. Both of them implement a special set of APIs for debugging transactions–the trace API. This article explains what are debug_trace APIs and how to use them with code examples for each method. There are some concepts you should know before deep diving into tracing: What is transaction What is state What is block What happens when you call a contract If you are unsure about these terminologies, please check out this article about eth_call. It explains how transactions are executed by Ethereum, which is fundamental for tracing. If you have difficulty understanding the concepts and terms in this article, reading the eth_call article may help. What is tracing? A blockchain transaction may fail due to various reasons, for example: The sender account runs out of ether for gas There is a bug in one of the smart contracts. A user is blacklisted. The CPU use exceeds its limits during call execution Tracing can help to identify the root cause of failure, on which step it fails, and the possible reason for that. When an Ethereum client executes a transaction, the global state updates, for example: Account balance will change Some on-chain information may be modified New contract may be uploaded Tracing collects the return data, state changes, and execution logs from transaction calls. It can be a contract call, a fund transfer, or a block execution. Figure 2: Trace data collected during a transaction What is a state? In order for a node to re-execute a transaction and to get the trace data, all the old state data accessed by the transaction must be available. This means transactions that can be traced are limited by the type of a node: An archive node retains all historical data back to genesis. It can therefore trace arbitrary transactions at any point in the history of the chain. A full node only retains the most recent 128 block states in memory. The older states are represented by a sequence of snapshots starting from genesis. The intermediate states can be regenerated from the snapshots, but it usually takes a long time to execute. A snap synced node is like a full node, but it only stores snapshots starting from its initial sync instead of genesis. A light node doesn’t store historical data, it only retrieves data on a need-to-use basis. Even though in theory, it can regenerate historical states through heavy computation; in practice, we can’t assume its data availability. Figure 3:Chain history stored according to node type More details can be found in this article. debug_trace using Geth & Erigon For Geth, trace methods are in the debug_ namespace; for Erigon, trace methods are in both debug_ and trace_ namespaces. In this article, we will discuss both Geth and Erigon’s trace methods. Common trace methods available in both Geth and Erigon: debug_traceCall debug_traceTransaction debug_traceBlockByNumber debug_traceBlockByHash 4 unique methods available on Geth: debug_traceBlock debug_traceBlockFromFile debug_traceBadBlock debug_traceChain 9 unique methods available on Erigon: debug_traceCallMany trace_call trace_callMany trace_replayBlockTransactions trace_replayTransaction trace_block trace_filter trace_get trace_transaction Try it with Chainstack All of the code samples mentioned further are developed and tested with a Chainstack endpoint—it is highly recommended to use one for the following reasons: 3 million free requests Supports both Erigon and Geth Seamless node deployment Simply follow these steps to deploy a node: Sign up with Chainstack Deploy an Ethereum node Get the deployed node’s endpoint You can check your node type on the project page. The default option is Geth. Figure 4: Chainstack platform node type display location Erigon is only available on an archive node starting from the Business plan. To deploy an Erigon node, simply turn on the debug and trace APIs option when you deploy a node. Figure 5: Chainstack platform debug and trace APIs settings location Deep dive into tracing methods debug_trace methods available on both Geth and Erigon debug_traceCall This method executes an eth_call with tracing enabled. {"method": "debug_traceCall", "params": [callObject, blockNumberOrHash, traceOption]} The first two parameters are exactly the same as eth_call. This is a basic fund transfer example of traceCall: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd This returns an empty log since there is no actual operation involved. This is a basic write contract trace call example: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Tracing method in debug module supports various trace options, which gives huge flexibility on what types of data to collect: disableStorage: BOOL. Setting this to true will disable storage capture (default = false). disableStack: BOOL. Setting this to true will disable stack capture (default = false). enableMemory: BOOL. Setting this to true will enable memory capture (default = false). enableReturnData: BOOL. Setting this to true will enable return data capture (default = false). tracer: STRING. Name for built-in tracer or Javascript expression. See below for more details. If set, the previous four arguments will be ignored. If set, the previous four arguments will be ignored. timeout: STRING. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},"latest",{"disableStorage": true, "disableStack":true,"enableMemory": false,"enableReturnData":false}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Please take note that Erigon has a slightly different setup. GethErigonenableMemory: falsedisableMemory:trueenableReturnData:falsedisableReturnData:trueTable 1. Trace option on Geth vs Erigon You can either override a block data or state data by specifying “blockoverrides” (number, timestamp) or “stateOverride”(balance, nonce). Note the difference in the capital letter “O”, that is not a typo. It may be fixed in future development. Below is a state override example for a fund transfer transaction: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xFFFFFFFFFFFF"},"latest",{"stateOverrides":{"0x1111111111111111111111111111111111111111":{"balance":"0xFFFFFFFFFFFFFF"}}}],"id":1}' ' https:// nd-123-456-789.p2pify.com/ABCDabcd debug_traceTransaction Just like how debug_traceCall traces a call, this method reruns a specific transaction identified with the transaction hash. Tracing a single transaction also requires re-executing all preceding transactions in the same block. Therefore, the historical state must be available. Sample call: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceTransaction","params":["0x09d2acb16d30e2017813b532392d0749e871c6ac3b8759424b2923c953928172"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Same as debug_traceCall, this method supports trace options and overriding. debug_traceBlockByNumber When you trace a block, you are basically tracing all transactions from a block in sequence. You can either specify it with the block number or a tag like “latest”. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceBlockByNumber","params":["latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd State overrides and block overrides are supported too: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceBlockByNumber","params":["latest",{"stateOverrides":{"0x1111111111111111111111111111111111111111":{"balance":"0xFFFFFFFFFFFFFF"}},"blockoverrides":{"number":"0x50"},"disableStorage": true, "disableStack":true,"disableMemory": true,"disableReturnData":true}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd debug_traceBlockByHash This method is like debug_traceBlockByNumber but uses a block’s hash instead of block number. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceBlockByHash","params":["0x77419be3c23ba236fb940d13f15a2ae26d1ec45e6bdb8c11822cde8bc75a6e94"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Geth unique debug_trace methods debug_traceBlock The traceBlock method will return a full stack trace of all invoked opcodes of all transactions that were included in a block. The transactions are executed in sequence. To use traceBlock, two conditions must be fulfilled: The parent state of the block must be presented The RLP of the block is needed An RLP is a serialized data of a block. It can be obtained by using debug_getBlockRlp method. To use debug_traceBlock with the latest block, firstly you can use eth_getBlockByNumber to obtain the block number. {"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", false],"id":1} Please take note that the block number obtained here is in hexadecimal format and you need to convert it to an integer for the next step: {"jsonrpc":"2.0","method":"debug_getBlockRlp","params":[123456],"id":1} A sample RLP would be: Figure 6: Sample RLP output Paste the RLP data into debug_traceBlock and run it. Just as other trace methods, it supports various trace options. {"method": "debug_traceBlock", "params": [TheBlockRLP, traceOption]} debug_traceBlockFromFile Similar to debug_traceBlock, traceBlockFromFile accepts a file that exists on the node and contains the RLP data of a block. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceBlockFromFile","params":["blockRLP.txt",{}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd debug_traceBadBlock When Geth fails to execute a block, it puts the “bad block” into a pool for investigation. This method returns the trace logs for the bad block. The blockhash needs to be sent with the request. To get a list of bad blocks, use: debug_getBadBlocks Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_ traceBadBlock ","params":[blockHash,{}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd debug_traceChain A chain is multiple consecutive blocks. This method will re-execute every block in a chain and return the trace information. This method returns the structured logs created during the execution of EVM between two blocks (excluding start) as a JSON object. This endpoint must be invoked via debug_subscribe as follows: const res = provider.send('debug_subscribe', ['traceChain', '0x3f3a2a', '0x3f3a2b']) debug_traceChain example A sample use case with wscat: Figure 9: Sample debug_traceChain output with wscat Erigon unique debug_trace methods Erigon’s trace API is equivalent to openEthereum’s trace module. It doesn’t support trace options and state overrides, instead, it supports 3 different trace modes. trace: Transaction trace. An equivalent trace to that in the previous section. vmTrace: Virtual Machine execution trace. Provides a full trace of the VM’s state throughout the execution of the transaction, including for any sub-calls. stateDiff: State difference. Provides information detailing all altered portions of the Ethereum state made due to the execution of the transaction. The data return from trace module APIs is in general cleaner and better structured. Hence easier to interpret. The trace mode traces the operation results of all internal transactions for a call. The gas usage, input data, and the result of execution. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_call","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},["trace"],"0xF52578"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Sample output: Figure 9: Sample Erigon internal transaction trace operation output The vmTrace mode traces the state of the virtual machine during transaction. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_call","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},["vmTrace"],"0xF52578"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Sample output: Figure 10: Sample vmTrace operation output The stateDiff mode traces the state difference between each internal transaction. For example, changes in accounts’ balance, its storage data, etc. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_call","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},["stateDiff"],"0xF52578"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Sample output: Figure 11: Sample stateDiff operation output trace_call This is a mirror method of debug_traceCall. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_call","params":[{"from":"0xe7e8569267c4a3278be75a2d86fd1a9e0a6818d8","to":"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd","gas":"0x1E9EF","gasPrice":"0x2C2F7FD5E","data":"0x441a3e70000000000000000000000000000000000000000000000000000000000000010300000000000000000000000000000000000000000000000000c6c3eca729cb9e"},["trace"],"0xF52578"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_callMany This is a handy method that doesn’t exist on Geth. This method allows a user to send multiple transactions in a batch to oversee the executions. These transactions are executed in sequence, every transaction depends on the resulting state of previous transactions. The parameters: The parameter structure: Figure 12: Sample trace_callMany parameters Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_callMany","params":[[[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]],[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]],[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]]],"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_replayBlockTransactions This is a mirror method of debug_traceBlockByNumber. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_replayBlockTransactions","params":["0x2ed119",["stateDiff"]],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_replayTransaction This is a mirror method of debug_traceTransaction. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_replayTransaction","params":["0x09d2acb16d30e2017813b532392d0749e871c6ac3b8759424b2923c953928172",["stateDiff"]],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_block Instead of re-executing a block like debug_traceBlockByNumber and trace_replayBlockTransactions, this method returns the actual trace data collected during block execution. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_block","params":["0x2ed119"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_transaction Instead of re-executing a transaction like debug_traceTransaction and trace_replayTransaction, this method returns the actual trace data for transaction execution. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_transaction","params":["0x09d2acb16d30e2017813b532392d0749e871c6ac3b8759424b2923c953928172"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_filter This method returns the traces that match the given filter. Object – The filter object fromBlock: Quantity or Tag – (optional) From this block. toBlock: Quantity or Tag – (optional) To this block. fromAddress: Array – (optional) Sent from these addresses. toAddress: Address – (optional) Sent to these addresses. after: Quantity – (optional) The offset trace number count: Quantity – (optional) Integer number of traces to display in a batch. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_filter","params":[{"fromBlock": "0x2ed0c4","toBlock": "0x2ed128","toAddress": ["0x8bbB73BCB5d553B5A556358d27625323Fd781D37"]}],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd trace_get This call returns the specific trace of a transaction. Hash – Transaction hash. Array – Index positions of the traces. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"trace_get","params":["0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3",["0x0",]],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd debug_traceCallMany This is a mirror method of trace_callMany exposed in a debug module. Sample code: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"debug_traceCallMany","params":[[[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]],[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]],[{"from":"0x1111111111111111111111111111111111111111","to":"0x2222222222222222222222222222222222222222","gas":"0x493E0","gasPrice":"0x37E11D600","value":"0xF"},["stateDiff"]]],"latest"],"id":1}' https:// nd-123-456-789.p2pify.com/ABCDabcd Conclusion  This is the end of this tutorial. I hope you will find it useful. Thanks for reading.  If you have any questions, feel free to ping me on Twitter/Telegram/Discord.  Happy coding.  Cheers #### Deep dive into Monad: Speed, performance and more Monad is an EVM-compatible L1 engineered for high throughput through parallel execution, superscalar pipelining, and an optimized JIT-based EVM. Its position as the first token sold on Coinbase’s Token Sales platform drew attention, but the protocol’s real value lies in its architecture: an execution environment that preserves Ethereum compatibility while significantly increasing speed and scalability. Founded in 2022 by Keone Hon, James Hunsaker, and Eunice Giarta, is an EVM-compatible layer-1 that rethinks Ethereum’s performance constraints at the systems level. The chain’s design focuses on parallel transaction execution, a compact and asynchronous state database (MonadDB), and an EVM runtime with a JIT compiler that optimizes opcode execution globally rather than step-by-step. After surpassing 102M daily testnet transactions and targeting a Nov 24 mainnet launch, Monad positions itself as a high-performance L1 that maintains full EVM bytecode compatibility. This article details how Monad’s architecture works, how it preserves decentralization while scaling execution, and what developers gain from an environment designed for low-latency, high-throughput smart contract workloads. Earlier in November 2025, Coinbase, the second-largest cryptocurrency exchange, announced the launch of its token sale platform that lets both institutional and retail investors buy new crypto assets before they are listed for public trading on the exchange.  Monad, with ticker MON, became the first token launched on the platform, sparking interest in the blockchain. An X post announcing that Monad’s protocol token (MON) will hold its first public sale on Coinbase’s Token Sales platform. Monad is an Ethereum Virtual Machine (EVM)-compatible blockchain but also a separate Layer-1 (L1) with a unique architecture that improves speed, performance, and scalability compared to Ethereum and the EVM. Monad launched its testnet in February 2025, with over 102 million transactions daily to date, and plans to go live on the mainnet on November 24, 2025, following its token sale. Inspired by its founders’ motivation and as outlined in its mission, its three pillars are the driving force in its technical architecture: Ethereum Virtual Machine (EVM) compatibility  Speed, performance, and scalability Decentralization This article explains what a Monad is, how it maintains these three pillars without compromising the others, and how developers can benefit from using a Monad. EVM-compatibility Monad’s overarching goal is to redesign Ethereum to unlock high-performance applications, not to completely overhaul the Ethereum developer onboarding experience, as the Ethereum ecosystem has the most developers and transaction activity. Monad founder Keone Han recently explained in a BitGo interview that’s why Monad is EVM-compatible, rather than a non-EVM-compatible L1.  @Monad in Motion Smart Contracts Developing smart contracts on Monad is the same as on Ethereum; however, running them is quicker. Developers can explore the top Monad contracts, recognizing that they adhere to the same standards and formats on Ethereum. An example of the USDC stablecoin smart contract on Monad, viewed in the Monad explorer. Source: MonVision  Already-compiled Ethereum smart contracts can deploy directly to Monad using popular tools such as Hardhat and Foundry, as exemplified in these tutorials. They do not need to be recompiled or modified, as Monad is compatible with EVM bytecode up to the Cancun hard fork. Contracts already compiled to Monad are then cached and not recompiled unless heavily used. Monad executes new smart contracts faster by using a Just-In-Time compiler that analyzes the entire code and finds the optimal execution path. In contrast, Ethereum executes code line by line. For example, with these opcodes or instructions converted from code, Ethereum would run each instruction one at a time, charging gas for each instruction.  PUSH1 0x2PUSH1 0x3ADD The Monad compiler would detect and optimize the PUSH codes into a single line before execution, saving time. PUSH1 0x5ADD The Monad compiler also improves performance by identifying the location of each opcode on the EVM machine and choosing the fastest way to access it. The smart contract development process on Monad is quicker and more gas-efficient, yet remains familiar to Ethereum developers. Speed, Performance, and Scalability Using Monad is also meant to be faster, not only for developing smart contracts. Monad implemented an architecture that enhances each lifecycle blockchain process, from data storage to transaction execution and consensus on block creation, and enables them to run each stage in parallel.  Parallel execution Many blockchains execute transactions one by one, causing delays as they scale. In contrast, Monad executes transactions in parallel, enabling multiple transactions to run concurrently while still preventing the typical issues associated with parallel execution. First, a blockchain data store must support efficient, simultaneous reads and writes, as transactions require current data on the user’s account and result in updated data. MonadDB, Monad’s built-in database, enables simultaneous reads and writes of the blockchain state via asynchronous I/O, allowing other processes to continue while a read or write completes. MonadDB is more efficient than the Ethereum data store because it compresses historical data. It also uses a more compact data structure (the Patricia Trie) than Ethereum does (the Merkle Patricia Trie). Example of a Patricia Trie: root├── “a”│     ├── “1” → X│     └── “3” → Y└── “b”      └── “7” → Z Example of the same data represented in a Merkle Patricia Trie, which incorporates additional data types within each child: root├── ext(“a”) → branch│                 ├── child[1] = leaf(“1”, X)│                 └── child[3] = leaf(“3”, Y)└── ext(“b”) → leaf(“7”, Z) Optimistic parallel execution in a Monad prevents a common transaction conflict issue, where transactions to and from the same account might conflict if they occur around the same time. For example, suppose Alice, who initially has 1000 USDC, sends Bob 100 USDC, and immediately afterward, sends him another 100 USDC. The second transaction might fail because the system expects Alice to have 1000 USDC, but she should now have 900 USDC. With optimistic parallel execution, Monad recognizes that both transactions occurred and then commits the final state, showing Alice with 900 USDC. The system reviews the overall transaction data and the results of the data before finalizing the blockchain state. Monad founder Keone Han also makes an alternative explanation here. The full technical implementation of the execution client is available here. Consequently, with parallel execution, Monad can process significantly more transactions. For example, Ethereum processes an average of 18.2 transactions per second (TPS), while Monad approximates that it can handle 10,000 TPS and recently processed 2,000 TPS. Optimizing execution and consensus One reason Monad is faster and more scalable is that execution and consensus can happen simultaneously.  Monad uses superscalar pipelining, dividing blockchain processes into multiple stages and running them concurrently. This allows several lifecycles to happen simultaneously. A real-life example is doing multiple loads of laundry at once, with washing, drying, folding, and storing different loads all happening at the same time. The implementation also allows Monad to scale because it does not have to fit so many processes into the required 400-millisecond window to create a block.  Many blockchains utilize interwoven execution, requiring both execution and consensus to occur within a set block time. Often, execution is limited to just 50 milliseconds out of the total 400 milliseconds. While it might seem advantageous that the entire process takes only 400 milliseconds and execution takes 50 milliseconds, this restriction is actually limiting. It prevents increases in block gas, contract complexity, or transactions per block; otherwise, the system risks crashing because it cannot execute transactions within 50 milliseconds. Instead, Monad separates execution via asynchronous execution, allowing it to run concurrently with consensus. Securing block creation Besides execution speed, Monad uses a different consensus model, MonadBFT, to ensure more secure and efficient block creation. In standard Byzantine fault-tolerant systems, such as those on Ethereum, validators may collude by intentionally going offline or refusing to validate others’ proposals, leading to invalid block proposals. The subsequent validator can then reorder transactions within the block, facilitating a miner-extractable value (MEV) attack that is specifically called tail-forking. To address this issue, MonadBFT stores the metadata of a proposed block by an honest leader who received at least a majority of votes from other honest validators, and guarantees that it will eventually be finalized and not abandoned. In such cases, the new leader reaffirms the current proposal to keep it active. If they propose something new, they need to submit signed attestations showing that most validators didn’t receive the previous block. MonadBFT also streamlines the distribution of blocks to all validators. Because blocks can be large, RaptorCast, an enhanced messaging layer, splits the block into many smaller chunks using erasure coding instead of sending the entire block to all nodes. For example, a 1000 kb block encoded with a factor of 3 results in about 150 chunks of 20 kb each, with any 50 or so chunks sufficing to rebuild it. These validators then relay their chunks through a two-step process. The leader sends a chunk to the assigned validator, and the assigned validator then sends it to the rest of the network. The number of chunks each validator manages is proportional to its stake. The full technical implementation of the consensus client is available at Monad GitHub. Decentralization Monad prioritizes performance and scale, while avoiding the sacrifice of decentralization. Their hardware requirements for becoming a validator or participating in transaction validation on Monad meet performance needs while staying affordable for many individuals. The hardware needed to run a qualifying node with the required specifications costs around $1,500. On the Monad testnet, 174 validators are spread across 53 cities in 25 countries, without any specific regional focus. A Nakamoto coefficient, a metric that measures how decentralized a blockchain is and how distributed its validator network is, will be released when Monad launches its mainnet. Conclusion Earlier in November 2025, Monad attracted significant interest when Coinbase announced it as the first protocol token to launch on its Token Sales Platform. Monad is unique due to its dual nature as both an L1 and an EVM-compatible.  Monad’s vision is to redesign Ethereum to be faster, more performant, and scalable, without completely changing the developer or user onboarding experience, or compromising decentralization. Therefore, it is EVM-compatible. However, to achieve its vision, it needed to build a completely different architecture from Ethereum and become its own separate L1. Parallel transaction execution, dynamic and compact data storage via MonadDB, and pipelining make it super fast, while MonadBFT, its consensus protocol, ensures that it is secure and scalable. You can get started with Monad today via Chainstack. Chainstack gives you the performance and consistency required for production systems. Deploy a Monad RPC endpoint in seconds and scale globally with automated orchestration, uptime guarantees, and developer-friendly tooling. How to create a Monad RPC node Set up a Monad RPC node on Chainstack: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Pick the Monad chain and choose mainnet. Deploy a node configured for RPC access. Once deployed, your private RPC URL is available in the node dashboard. Create Monad RPC endpoint Additional Resources Monad Developer Documentation Monad Developer GitHub (including examples, tutorials, and explanations) Monad source code MonVision — Monad Block Explorer #### DeFiato on Chainstack: Resolving technical barriers for Web3 adoption DeFiato serves as an accessible bridge that simplifies DeFi interactions for the end-user by reducing technical barriers and financial risk that is typically associated with dApps. With simplicity and user-friendliness at its core, DeFiato users gain access to practical services, such as yield farming in a single click. To accomplish this, the platform redirects all cumbersome processes for its users to the backend, like transaction payments or approval, and in doing so is able to deliver a 10-step procedure within one click of a button. What does DeFiato do? The DeFiato platform’s primary goal is to resolve some of the key obstacles to mainstream blockchain adoption, such as lowering the barrier of entry and streamlining gas fees. It does so by offering a seamless user experience across the platform with its proprietary one-click-to-farm technology and pairing it with exceptional support. Thanks to DeFiato’s implementation users can fulfill the entire farming process, consisting sometimes of as many as 12 to 16 transactions in a single swoop. And while this is certainly a welcome sight already, the platform continues building on top of this steady foundation by offering a new NFT staking capability unlike any other DeFi/CeDeFi platforms out there, as well as an upcoming fiat on-ramp. The on-ramp will allow users from all over the world would be able to transfer USD directly to the bank based in the US, and onboard their fiat directly into crypto. On the other hand, the new NFT staking capability allows DeFiato to work together with the plethora of NFT projects available on the market to introduce new functionalities to their products and enhance their roadmaps. When it comes to supported chains, DeFiato fosters cross-chain functionality just as well, effectively bridging assets across the Ethereum, BNB Smart Chain, Polygon, Avalanche, Solana, and Harmony networks. Because of this, DeFiato has enjoyed swift growth in its user base, hosting as many as 100,000 registrations in the brief period since its IDO in early February 2022. How did DeFiato come across Chainstack? Considering the multi-chain support of DeFiato, their development team set out on a search for an easy-to-use platform that could help them integrate the blockchain stack they were looking to target. But that would hardly be enough, should the infrastructure provider fall short of delivering a stable performance across their desired networks. That is why, the provider they were looking for had to have a reputation for low downtime, regardless of protocol. Such provider would ensure that DeFiato team could work efficiently, allowing them to provide exceptional service to their users and help achieve its vision to be the leading DeFi platform. After evaluating all the available options, DeFiato found our services standing out from the rest when it came to stability for all supported networks. This led their team to see a robust and trustworthy partner in Chainstack that is there to help them achieve exceptional performance. How does Chainstack’s offer match DeFiato needs? DeFiato was happy to discover just how easy it is to use the Chainstack platform in deploying blockchain infrastructure quickly and effectively. Without the complicated setup that usually comes with such processes, the DeFiato development team could shift valuable resources towards delivering a seamless user experience with every product iteration. And the best thing about it? They did not have to choose between stability, protocol support, and cost, thanks to the flexibility of Chainstack’s services and pricing. In turn, this allowed DeFiato to significantly reduce the time to market for their services and do stress tests in just a few clicks. What does DeFiato like about Chainstack? “Chainstack simplifies our integration process by providing us the infrastructure that we need to work seamlessly. Truly a reliable solution to blockchain integration with reasonable pricing.”  Sung Nguyen, CTO, DeFiato What does Chainstack like about DeFiato? “Improving accessibility is a crucial factor for the successful development of blockchain technology. That is why initiatives such as that of DeFiato play a key role in moving the entire Web3 landscape forward.” Eugene Aseev, Founder & CTO, Chainstack Outcome DeFiato leveraged Chainstack’s robust infrastructure to create more opportunities for scaling up their operations and do so at a reasonable cost that fits their budget. Because of just how accessible node deployment is on the platform, the development team was able to streamline the integration process and thus enjoy a significant boost to their overall time-to-market delivery.  Chainstack delivered on the expectations of their team, bringing much relief, considering stability was one of the top priorities. In turn, this allowed them to expand the platform’s capabilities and support multi-chain operations with ease. DeFiato saw few obstacles in integrating the platform with our services. With comprehensive documentation and exceptional node performance, their team has not experienced any bottlenecks during operations, successfully handling everything internally.  Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Definitive fulfills Subgraphs multi-chain coverage with Debug & Trace ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. Elevating DeFi engagement with robust and scalable user-focused solutions. Using Dedicated Subgraphs has transformed our operations. Their exceptional performance and Debug & Trace capabilities have streamlined our processes, elevating our ROI on blockchain data infrastructure to 400%+, marking a milestone in our DeFi journey. Blake Arnold, Co-Founder, Definitive In the ever-evolving landscape of decentralized finance, finding an efficient, user-centric platform that offers an end-to-end solution can sometimes seem out of grasp. That’s not the case, however, for Definitive, a DeFi platform that has essentially transformed the way users engage with DeFi. Offering non-custodial smart contracts and powerful automation services across an array of DeFi protocols, Definitive hasn’t just created an integrated solution; it has given its users a distinct competitive edge. Join us as we delve deeper into our journey with Definitive. Together, we will discover how we tackled operational challenges together head-on, explore their platform’s unique advantages, and delve into the solutions that make a real difference in the world of DeFi. Why Definitive chose Chainstack as its infrastructure partner When Definitive first approached us at Chainstack, they were on the lookout for a robust, scalable blockchain data platform that could handle large volumes and do so effortlessly. Our initial task seemed clear-cut—offer a sturdy foundation for Definitive’s multi-user vaults, and provide efficient data indexing and reporting. Before their integration with Chainstack, Definitive had encountered significant scalability issues, primarily due to the limitations of their private dedicated vault system. The sudden surge in their user base as their platform opened to the public exposed these inefficiencies. Their initial approach to resolve this via the GraphQL hosted service, proved ineffective. It lacked debugging capabilities and offered subpar customer service that unnecessarily prolonged issue resolution. Their exploration for a sturdier solution led them to us. Chainstack stood out with our extensive range of supported protocols for Dedicated Subgraphs that fully covered Definitive’s needs, as well as our debugging capabilities, and responsive customer support. Switching to Chainstack addressed their scalability issues, streamlined the process of deploying new smart contracts and managing user vaults. In doing so, Definitive effectively lowered costs by 45% to 85% compared to other providers for an ROI on Subgraphs infrastructure up to 425% and improved the overall efficiency of their platform. And at the end of the day, it was the unique advantages that we presented, such as swift subgraph deployment, comprehensive documentation, and multi-chain support that ultimately sealed the deal for our ongoing work together. With our flexibility and thorough understanding of how to effectively manage computational demands in blockchain operations, Chainstack proved to be exactly the partner Definitive had been seeking in the first place. Definitive on Chainstack in numbers Since the start of our collaboration, we’ve seen Definitive make impressive use of what our platform has to offer, especially when it comes to Dedicated Subgraphs. Currently hosting 14 active Subgraphs for the platform, we’ve observed their integration with a diverse set of data sources for a wide-range of use cases, underlining just how applicable blockchain data is in real-world scenarios. Simultaneously, we‘ve helped to enable the indexing of seven high-profile DApps, like Messari Convex, Balancer V2, Curve, Sushiswap, Uniswap V3, as well as both V2 and V3 of Pancakeswap, into Definitive’s DeFi strategies. Furthermore, we’ve ensured the optimization of yields and trade executions across multiple protocols, including Arbitrum, Avalanche, Base, Ethereum, Optimism, and Polygon. The dedicated subgraphs we offer for each of these protocols have played an instrumental role in this endeavor. Lastly, by providing an active account balances subgraph, we’ve been part of Definitive’s initiative to monitor all user positions round the clock, reinforcing the transparency and security aspects of their platform. In essence, these numbers stand as a testament to the integral role Chainstack plays in Definitive’s operations, supporting them to offer an optimal DeFi experience to their end users. What is Definitive? Definitive is not just another DeFi platform. It’s a complete end-to-end solution that’s been thoughtfully designed to give users an edge when engaging with decentralized financial products. Definitive provides an execution platform along with an API for DeFi, offering non-custodial smart contracts and automation services across numerous respected DeFi protocols. This unique fusion of on-chain and off-chain components enables Definitive to streamline DeFi execution for end users—it simplifies everything from complex yield strategies to high-frequency trading algorithms. Two flagship products a user can access directly via the Definitive platform are Advanced Yield and Trade Execution, both of which can also be integrated into third party apps via the Definitive API. These offerings confer simplified access to sophisticated, institution-grade DeFi strategies and allow execution of advanced order types on all DeFi trading venues with optimal slippage and minimal price impact per trade. Figure 1: Definitive real-time monitoring; Source: Definitive Definitive stands out with a unique value proposition that includes non-custodial services, an automated low-latency engine, configurable positions to meet unique client needs, and a fully auditable activity history. Aimed specifically at the institutional-grade DeFi execution segment, this premier non-custodial platform is functional across a wide variety of use cases—yield management, trade execution, leverage usage, and more. Bringing it all together Our journey with Definitive is a testament to how innovation and collaboration can drive new efficiencies in the DeFi landscape. By successfully leveraging Chainstack infrastructure, Definitive could comprehensively improve their operations and service offerings for their users. However, our partnership goes beyond mere operational efficiency or data handling. It’s about enriching the user experience, offering an optimal range of services, and providing a thoughtfully designed platform that gives users an advantage when engaging with DeFi. As the architects behind this infrastructure, we’re incredibly proud of the role we have played in Definitive’s success story. As we conclude this article, we look forward to a future brimming with collaboration, where scalability is not a hurdle but a given, and impactful solutions pave the way for more significant advancements in the world of DeFi. We, at Chainstack, are committed to shaping this future, and our partnership with Definitive is a clear sign of what we can achieve. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Demystifying Zero-Knowledge Proofs: The future of Web3 privacy In the vast landscape of cryptography and blockchain technology, Zero-Knowledge Proofs (ZKPs) emerge as a beacon of privacy and security. Their concept, though born out of academically dense theories presented in 1985, have matured to significantly impact how we approach and solve modern-day privacy concerns. As our world becomes increasingly interconnected through digital networks, privacy becomes both a luxury and a necessity. We conduct transactions, share sensitive information, and authenticate identities over networks teeming with potential threats. In such a landscape, how can we preserve our privacy while performing these crucial activities? ZKPs may hold the key. Let’s see why: What are ZKPs? ZKPs are not merely another cybersecurity model. Instead, they redefine how we perceive privacy in the digital realm. They allow for the novel act of confirming a statement’s truth without revealing any additional information – like proving you know a password without ever disclosing what it is. Such innovative applications make ZKPs a fascinating field of exploration and a tool to power our increasingly digital world. The concept of Zero-Knowledge Proofs was first introduced in a groundbreaking 1985 paper by Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The initial revelation sparked a deluge of interest and subsequent research in the field of cryptography. Over the past three decades, ZKPs have significantly evolved and have found valuable applications in various real-world scenarios, especially in the realm of blockchain technology. As we delve into the world of ZKPs, we begin to appreciate their strategic importance and potential in modern-day information sharing and privacy protection. Figure 1: Zero Knowledge Proofs timeline; Source: Circularise Comparing ZKPs and zero trust It is essential to distinguish between ZKPs and “zero trust.” The latter is a cybersecurity model that treats every person and device as a potential threat, necessitating continuous authentication and authorization. On the other hand, ZKPs constitute a method that enables one party (the prover) to confirm the truth of a statement without revealing any information about the statement’s contents to another party (the verifier). Notably, ZKPs can function within a zero-trust framework, providing a secure mechanism for authentication without necessitating the exposure of personal details. The role of ZKPs in preserving privacy In an era where information is pivotal, preserving privacy has become more critical than ever before. Conventional methods of verifying claims, such as showcasing your passport or driver’s license, tend to expose personal information to third parties, increasing the vulnerability to potential hacks and identity theft. This is where ZKPs step in, eliminating the need to disclose information while still providing a proof of the claim’s validity. With ZKPs, it is possible to establish the truth of a statement without exposing any of the information required to validate it. Understanding ZKPs At the core of ZKPs are three fundamental criteria that they must satisfy: completeness, soundness, and zero knowledge. Completeness ensures that if a statement is valid, the protocol will always return ‘true.’ This ensures the reliability of the verification process and instills confidence in the underlying system. Soundness refers to the impossibility of fooling the system. If a statement is false, it is impossible for a prover to convince the verifier that it is true, enhancing the system’s integrity. The final criterion, Zero-knowledge, guarantees that the verifier learns nothing about the statement beyond its validity or falsity. This means that the validation process does not reveal any additional or unnecessary information, thus protecting the system’s security. Figure 2: Conceptual example of how ZKPs work; Source: Chainlink Understanding interactive vs. non-interactive ZKPs ZKPs can be interactive or non-interactive, depending on the style of communication required. Interactive ZKPs entail an ongoing, back-and-forth communication between the prover and verifier. This becomes akin to a game, where the verifier challenges the prover, who then provides responses that convince the verifier of the statement’s truth. In contrast, non-interactive ZKPs demand only a single round of communication—the prover generates and sends the proof to the verifier. The verifier can then independently authenticate the proof using a shared key and a verification algorithm. Notably, non-interactive ZKPs are more efficient and reduce the potential for errors, as they eliminate the need for continuous interaction. Types of ZKPs Several variants of ZKPs have emerged over the years, each tailored to specific applications or optimized for certain challenges. Notable among these are ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge), PLONKs, and Bulletproofs. ZK-SNARKs involve a succinct proof and verification process, requiring little communication between the prover and verifier and enabling efficient proof verification. However, ZK-SNARKs necessitate a trusted setup, potentially introducing vulnerabilities if this process is compromised. In contrast, ZK-STARKs sacrifice compactness for transparency, removing the need for a trusted initial setup. They are also more scalable than ZK-SNARKs, able to handle larger computational statements while maintaining relative efficiency. At the core of both PLONKs and Bulletproofs is the commitment to reduce computational and proof size requirements, making these types of ZKPs highly efficient. Benefits and use cases of ZKPs types Each type of ZKP comes with its benefits and use-cases, decided by their unique characteristics. ZK-SNARKs are highly efficient, requiring shorter proofs and less computation, making them ideal for scalability and for applications demanding quick proof and verification. ZK-STARKs, on the other hand, offer greater security and universal verifiability, as they do not rely on a trusted setup. This feature makes ZK-STARKs suitable for applications that prioritize security and transparency over efficiency. PLONKs generalize the concept used in ZK-SNARKs, resulting in a simpler protocol and broadening their use-cases. Meanwhile, Bulletproofs are designed to enable efficient confidential transactions in cryptocurrencies. Figure 3: Examples of projects using ZKPs; Source: Chainlink ZKPs applications in a Web3 context Enhancing privacy and transparency The marriage between blockchain networks and ZKPs has opened up a world of possibilities for enhancing both privacy and transparency in digital transactions. By utilizing ZKPs, blockchain users can prove possession of a specific piece of knowledge or fulfilment of a particular condition without revealing any details about it. This provides a layer of privacy, shielding information from other users on the network, while maintaining the transparency characteristic of blockchain technology. For instance, consider individuals performing a transaction on a public blockchain. Through ZKPs, these individuals can anonymously prove to the rest of the network that they have enough cryptocurrency for a transaction, without showing exactly how much they own. This protects user privacy while keeping the transaction open and transparent for anyone on the blockchain to verify. Anonymous payments using ZKPs Anonymity of payments is a vital use-case of ZKPs in blockchain networks. ZKPs can mask transaction details, camouflaging the sender’s, recipient’s, and transaction amount’s identities. This ensures financial privacy, something highly valued in crypto-economics. Coins like Zcash use ZK-SNARKs to enable private transactions. Identity protection and authentication simplified Beyond maintaining financial privacy, ZKPs play an essential role in safeguarding digital identities on blockchain networks. By deploying ZKPs, individuals can verify their identity or authenticate themselves without revealing sensitive details. Taking it a step further, ZKPs can simplify authentication for online services, eliminating the need for users to remember complex passwords or provide personal information. The Future of ZKPs Addressing the challenges and drawbacks of ZKPs While ZKPs have a lot of promising applications, they are not without drawbacks. Some of these challenges include high hardware costs for generating proofs, verification costs that can become prohibitively high for large-scale applications, and trust assumptions in certain types of ZKPs like ZK-SNARKs, which could potentially be exploited. Moreover, the imminent threat posed by quantum computing can potentially crack current cryptographic practices, including ZKPs. Thankfully, research is being pursued vigorously in the area of quantum-resistant cryptography that could also secure ZKPs against quantum attacks. Ongoing research and development in ZKPs The cryptographic community is heavily focused on tackling these problems and furthering the application of ZKPs. Ongoing research and development are aimed at reducing hardware and validation costs, eliminating trust assumptions, and designing quantum-resistant cryptographic practices. It’s a fascinating field, with the full potential of ZKPs yet to be harnessed. With privacy being an increasingly important factor in digital communication and transactions, it is likely that we’ll see ZKPs being integrated into more and more systems. Exploring the future implications of ZKPs The increasing digitization of our world promises a future where ZKPs could be more widely used. In the field of decentralized identity, for instance, ZKPs can provide a secure and reliable way for people to prove aspects of their identity without needing to reveal any unnecessary information. From securing our digital identities to providing greater privacy in blockchain transactions, the potential applications of ZKPs are far-reaching and exciting. As research and understanding of ZKP continue to evolve, the future of ZKPs seems more promising than ever. Bringing it all together Zero-Knowledge Proofs are a revolutionary technology that has significantly impacted the way we confront the issue of privacy in the digital age. With their ability to confirm a statement’s truth without exposing any additional information, ZKPs have found essential applications spanning from Blockchain transactions to digital identity verification. However, as with any innovative technology, ZKPs come with their set of challenges. These include high hardware requirements, expensive verification costs, trust assumptions, and potential threats from quantum computing. Yet, the community is working persistently towards overcoming these issues, and ongoing research shows promising possibilities for the future of ZKPs. In our quest for more secure and private digital interactions, ZKPs offer a beacon of hope. As we continue to innovate and break new ground in this field, ZKPs will undoubtedly play a pivotal role in shaping our digital future, one where privacy is a right, not a privilege, and transparency can coexist with confidentiality. As we conclude this deep dive into ZKPs, let’s remember that while the depth of these concepts can be overwhelming, the value they provide to our increasing digital interactions is immeasurable. With ZKPs, we are one step closer to a world where our digital selves are not just blindly secure but are also to be devoid of unnecessary exposure. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Deploy a simple storage smart contract on StarkNet StarkNet and zero-knowledge rollups are gaining in popularity lately due to their efficiency, so it’s time to learn how to develop on StarkNet. This tutorial will show you how to create a simple smart contract in Cairo to save and retrieve a variable and then deploy it on the StarkNet testnet using the StarkNet Foundry framework. You can find the project with the smart contract and the compiled files in the protostar-project folder of the GitHub repository. If you want to learn some StarkNet fundamentals, I recommend reading this article about StarkNet’s architecture and environment. A Cairo smart contract Cairo is a relatively new language that powers smart contracts on StarkNet; it is worth learning more about it! The smart contract you will deploy today is very similar to a simple storage contract you are probably familiar with in Solidity. In this tutorial we’ll write a straightforward smart contract, but it will teach you how to declare a variable, write a getter function, and write a function to set the variable. The smart contract head The first thing we need is to declare it as a StarkNet contract and importing the ‘HashBuiltin’ package. %lang starknet from starkware.cairo.common.cairo_builtins import HashBuiltin As you can notice, we are importing a package, the HashBuiltin it’s a struct specifying the hash builtin memory structure. You can learn more about this package from the StarkNet and Cairo Docs. At this point, we can continue by declaring the variable. Declare a variable Like Solidity, we need to declare a variable to use it. In this example, the variable is a ‘felt’, named ‘my_value_storage’, where we can basically store a number. @storage_var func my_value_storage() -> (my_value_storage: felt) { } Storage variables are, by default, not visible from the ABI. They are similar to “private” variables in Solidity. A storage variable can be read with ‘var_name.read()‘ or written to with ‘var_name.write()'. Getter function When we use variables, it is good practice to declare a ‘getter‘ function. So we can add that too! A getter is a view function that we can call to see the stored variable. @view func get_my_stored_value{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> ( my_stored_value: felt ) { let (my_stored_value) = my_value_storage.read(); return (my_stored_value,); } For example, this function can be called from the StarkNet explorer and display the stored value. Function to set the variable Now that we have the variable declared, how do we modify it?We could automatically set it up when the contract is deployed with a ‘constructor’, but for this tutorial, I want to create a function for it. This is an ‘external‘ function, which can be called by another smart contract (or wallet), allowing us to modify that variable! @external func set_my_stored_value{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}( my_value: felt, ) { my_value_storage.write(my_value); return (); } As you notice, in the function to set a stored value, we use my_value_storage.write(my_value), where my_value is the argument passed through the function. Full smart contract Now that we have all the separate parts, we can put them together. Here you’ll find the entire smart contract, with some comments. %lang starknet from starkware.cairo.common.cairo_builtins import HashBuiltin // Store a variable // Storage vars are by default not visible through the ABI. They are similar to "private" variables in Solidity. // This variable is a felt and is called my_value_storage // From within a smart contract, it can be read with my_value_storage.read() or written to with my_value_storage.write() @storage_var func my_value_storage() -> (my_value_storage: felt) { } // Declaring getters // Public variables should be declared explicitly with a getter // Function to return the variable's value. @view func get_my_stored_value{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> ( my_stored_value: felt ) { let (my_stored_value) = my_value_storage.read(); return (my_stored_value,); } // Set the variable's value. @external func set_my_stored_value{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}( my_value: felt, ) { my_value_storage.write(my_value); return (); } A Protostar project For this example, we’ll use protostar, one of the Starknet framework. First thing, install Protostar. Note that Protostar is only supported on Linux and macOS. Initialize a Protostar project After we installed Protostar, let’s create a project by using the following command. protostar init store-variable Where store-variable is the name of the project. The result of running protostar init is a configuration file protostar.toml, example files, and the following 3 directories: src — A directory for your code. lib — A default directory for external dependencies. tests — A directory storing tests. The protostar.toml file is the configuration file where we specify the path to our contracts; in this case, you’ll already have a cairo.main example file. In this case, we will generate a contract named main from our src folder. ["protostar.contracts"] main = [ "src/main.cairo", ] Simply delete the example code and paste our smart contract’s code. Compile the Cairo smart contract We have initialized a Protostar project, and there is a Cairo smart contract is in the src folder; we are ready to compile. From the project main directory, run the following command to compile. protostar build You will receive a success message if the contract is compiled correctly. 16:23:13 [INFO] Built the project successfully 16:23:14 [INFO] Execution time: 2.96 s After the contract has been compiled, you will notice a build directory in the project, where you can find the contract’s ABI and the compiled contract as main.json. Deploy the smart contract on the StarkNet testnet After the smart contract was compiled, we can finally use Protostar to deploy it on the StarkNet testnet. Use the following command to deploy the compiled contract. protostar deploy ./build/main.json --network testnet The result will show you the transaction hash and the contract address and give you a link to the smart contract on the Voyager explorer. [INFO] Deploy transaction was sent. Contract address: 0x06a5ea9e42c921bd58e24b8da9d1fc91a488df0700b173f1c6bb0e453f68afec Transaction hash: 0x1cbba90ba0d1fbfba09b1f7a0f987134dd9a02a845ca89244b3272374d37ede https://goerli.voyager.online/contract/0x06a5ea9e42c921bd58e24b8da9d1fc91a488df0700b173f1c6bb0e453f68afec Interact with the deployed contract Now that the smart contract has been deployed on the StarkNet testnet, you can use the Voyager explorer to interact with it. You can use the smart contract we deployed if you still need to deploy yours. Use the Read Contract tab to call the view function and see the stored value. Then you can use the Write Contract tab to call the external function and modify the value. When writing to a contract, so change the state of the network; you will need to authorize the transaction, so remember to connect your wallet to the Voyager explorer and have some test ETH. You can get some Goerli ETH on the L2 from the StarkNet faucet. Conclusion Congratulations on completing this tutorial. Today you learned how to write and deploy a simple smart contract in Cairo! Check out our StarkNet odyssey series to learn more about Cairo and more developer tools available. StarkNet – Overview of developer tools and zk-rollups. A StarkNet odyssey: Escaping Cairo hell. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Deploy Hyperledger Fabric v2 web app using the Node.js SDK Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Introduction One of the main highlights of Hyperledger Fabric v2 is the concept of decentralized governance for smart contracts. It introduce peer chaincode lifecycle, which focuses on improving chaincode management between multiple organizations. Using the new lifecycle, installation and upgrading of chaincodes requires approval from multiple organizations before the chaincode can be interacted with. This article uses the Freedom Dividend chaincode as an example to show you how to build a complete Hyperledger Fabric v2 application using the new peer chaincode lifecycle together with the fabric-sdk-node and a network spun up with the Chainstack platform. The main difference from developing a Hyperledger Fabric v1.4 application is the integration of the peer lifecycle commands into the application flow as illustrated in the diagram below. Fabric v2 web app flow Prerequisites A Chainstack account. Node.js 12.13.1 or higher. NPM 6 or higher. nodemon. Tutorial overview Set up a Hyperledger Fabric network with Chainstack. Set up the environment. Set up the backend application. Set up the frontend client. Install the chaincode. Approve the chaincode. Commit the chancode. Interact with the installed chaincode through the front end. Upgrade the chaincode. Interact with the upgraded chaincode through the front end. 1. Set up a Hyperledger Fabric network with Chainstack Create a consortium project with Chainstack. See Create a project. Deploy a Hyperledger Fabric network. See Deploy a consortium network. 2. Set up the environment Clone the freedomDividend repository on your local machine: git clone https://github.com/chainstack/freedom-dividend-chaincode Install the Hyperledger Fabric v2 binaries using the downloadPeerBinary.sh script in the repository: macOS: bash downloadPeerBinary.sh Linux: bash downloadPeerBinary.sh linux The script will download a set of Hyperledger Fabric v2 binaries that you can execute to interact with the network. Set the environment variables In the webapp/server/.env file, replace the ORDERER_NAME, PEER_NAME, and MSP_ID variables with: ORDERER_NAME — the orderer name of the network you deployed your peer in. To access the orderer name in Chainstack, from Hyperledger Fabric network, select the Service nodes tab and click on Orderer to access its details page. Here you can copy the Orderer name value. PEER_NAME — the name of the peer that you deployed. To access the peer name in Chainstack, from Hyperledger Fabric network, select the Peer nodes tab, click on your peer name to access its details page. Here you can copy the Peer name value. MSP_ID — the Membership Service Provider identity (MSP ID). To access the MSP ID in Chainstack, from the Hyperledger Fabric network, click the Details link to open the network details modal. Here you can copy the MSP ID value. Export the required files from Chainstack In Chainstack, export the following files. Network connection profile Navigate to your Hyperledger Fabric network. Click Details. Click Export connection profile. Move the exported file to the webapp/certs/ directory. Orderer TLS certificate Navigate to the Hyperledger Fabric Service nodes tab from the network. Access Orderer. Click Export Unzip the downloaded folder. Move the -cert.pem file to the webapp/certs/ directory. Organization identity ZIP folder Navigate to your Hyperledger Fabric network. Click Details. Access Admin identity. Click Export. Unzip the downloaded folder. Move the msp subdirectory to the webapp/certs/ directory. 3. Set up the back end application In the cloned repository, install the required dependencies: cd webapp/server npm i Start the back end server: npm run start You should see the following output in the terminal, which indicates that the wallet and gateway have been successfully initiated using the Hyperledger Fabric v2 SDK library together with the values you set in the .env file: Setting up fabric wallet and gateway... Server running at http://localhost:4000/ ==========AS_LOCALHOST: false========== Set up complete! You should also note that a wallet with the label user01 has been created in the directory webapp/server/fabric/wallets/; this is the wallet identity that Hyperledger Fabric v2 SDK uses to authenticate the user with the network. 4. Set up the front end client In the cloned repository, install the required dependencies: cd webapp/client npm i Compile and build the front end client: npm run build Head on over to http://localhost:4000 in your browser, and you should see the following: 5. Install the chaincode In the web app at http://localhost:4000, click Install chaincode. You will now see the chaincode as installed: 6. Approve the chaincode In the web app at http://localhost:4000, click Approve. Note that we are using one organization in this example. If there are multiple parties involved and the endorsement policy requires more than one endorser, the chaincode package will have to be approved by others before it can be committed to the network. The value of the organization approval will change from false to true: 7. Commit the chaincode In the web app at http://localhost:4000, click Commit. You will see the details of the committed chaincode: 8. Interact with the installed chaincode You can now interact with the installed and committed chaincode. To read more about the chaincode and the arguments, see the chaincode tutorial at Chainstack Docs. In the web app at http://localhost:4000, click Access chaincode. You will see the following: A dynamic set of forms is automatically generated using the contract.evaluateTransaction('org.hyperledger.fabric:GetMetadata') function based on the chaincode you are accessing. In this example, we are using the Freedom Dividend chaincode which includes three transactions: OptIn OptOut QuerySSN Note that this will only work if your chaincode uses the fabric-contract-api. Execute the QuerySSN function with a random value; we will use 123-456-789 as an example. You should see an error as shown below. This error indicates that there is no record on the ledger with SSNID 123-456-789. Next, execute the OptIn function with a random value. We will use 123-456-789 with a random statement as an example. Next, execute the QuerySSN function with 123-456-789 again. You should see the following: 9. Upgrade the chaincode Now create a more descriptive metadata to override the one inferred from the source code to provide more meaningful parameters for the generated forms. The metadata is in the contract/contract-metadata/metadata.json file: freedom-dividend-chaincode |__ contract | |__ contract-metadata | |__ metadata.json In the metadata.json file, replace: ssnId with securityNumber SSN ID with securityNumberID description with statement Next, upgrade the Freedom Dividend chaincode with the following command: node webapp/server/cli/peer upgrade The command will automatically increase CHAINCODE_VERSION in the .env file by 0.1 and CHAINCODE_SEQUENCE by 1. You should see the following on the terminal to indicate that chaincode has been successfully upgraded on the network: $ node webapp/server/cli/peer upgrade executing cli - upgrade command executing cli - upgrade command 2021-04-23 16:15:45.304 +08 [cli.lifecycle.chaincode] submitInstallProposal -> INFO 001 Installed remotely: response:<status:200 payload:"\n[freedomDividendContract1.1:1e42265415ea613961053b388521ebbbc856dca1048e2ca987ccb165ed80611c\022\032freedomDividendContract1.1" > 2021-04-23 16:15:45.305 +08 [cli.lifecycle.chaincode] submitInstallProposal -> INFO 002 Chaincode code package identifier: freedomDividendContract1.1:1e42265415ea613961053b388521ebbbc856dca1048e2ca987ccb165ed80611c By using a different CHAINCODE_SEQUENCE and CHAINCODE_VERSION number, the peer lifecycle command initiates an upgrade process to override the existing Freedom Dividend chaincode with the new changes. 10. Interact with the upgraded chaincode through the front end You now need to approve and commit the upgraded chaincode. In http://localhost:4000/, approve the new chaincode definition by clicking Approve. Now commit the approved chaincode by clicking Commit. Access the upgraded chaincode by clicking Access chaincode. You should see the changes made previously are reflected in the automatically generated forms. Conclusion The concept of integrating CLI commands as a part of the application can be challenging to understand, hopefully this Freedom Dividend application helps you understand the process of building a Hyperledger Fabric v2 application. Explore Chainstack Learn more about managed Hyperledger Fabric v2 services on Chainstack. Register for a 7-day trial with Chainstack. Build a DApp with Chainstack. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Deploying a deterministic smart contract on Ethereum Introduction Deployment of a new contract on an EVM-based protocol usually produces a contract address that cannot be known in advance. Fortunately, a way of precomputing a contract address was introduced in EIP-1014. In this post we will explore:  How a contract address is usually generated.How you can know a contract address before deploying a new contract instance.What the advantages and use cases of deterministic deployment are. This article works for most EVM-based protocols—Ethereum, Polygon, BNB Smart Chain, Avalanche C-Chain, Fantom, Harmony, and others. Deploying a smart contract—the classic way Whenever a new contract is deployed to an EVM-based network classically, a couple of variables are used to generate the contract address, resulting in different addresses for the same deployer and the same contract. Even though every contract address is deployed deterministically, the main difference between the classic way and the approach we will see later is the use of different creation functions. Classically, the address of a smart contract is computed using the deployer address (sender) and the number of transactions sent by this account (nonce). The deployer and the nonce are RLP-encoded and hashed with Keccak-256.   An example function from pyethereum:  def mk_contract_address(sender, nonce): return sha3(rlp.encode([normalize_address(sender), nonce]))[12:] This way, even when having the same account and the same smart contract code, the address of this contract will change if we choose to re-deploy it. But there is a way to precompute a contract address and use this address to perform transactions—like sending ETH to it—even when this address has nothing in it yet. Deploying a smart contract—the deterministic way There are a number of approaches to generate a deterministic address for a smart contract—for example, one that seeks to lower gas costs, and older ways by using assembly code. However, newer approaches are available just by using smart contract functions and a factory contract approach.  First, let us write a simple smart contract that returns its balance and uses the deployer address as the constructor parameter. The contract can also store funds and allow the contract owner to withdraw the funds. This will be useful in the future.  // SPDX-License-Identifier: MIT pragma solidity ^0.8.13; contract SimpleWallet { address public owner; // Only owners can call transactions marked with this modifier modifier onlyOwner() { require(owner == msg.sender, "Caller is not the owner"); _; } constructor(address _owner) payable { owner = _owner; } // Allows the owner to transfer ownership of the contract function transferOwnership(address _newOwner) external onlyOwner { owner = _newOwner; } // Returns ETH balance from this contract function getBalance() public view returns (uint256) { return address(this).balance; } // Allows contract owner to withdraw all funds from the contract function withdraw() external onlyOwner { payable(msg.sender).transfer(address(this).balance); } // Destroys this contract instance function destroy(address payable recipient) public onlyOwner { selfdestruct(recipient); } } What if we deploy this contract just like this? Let’s use Remix for simplicity and deploy the contract on Goerli. First, select Injected Web3 and be sure to have a wallet extension such as MetaMask. You can also check this plugin to deploy contracts on Remix from your local environment. Once you’ve done that, add your Ethereum Goerli endpoint to MetaMask. You can get a free public node from Chainstack. Now, let’s deploy the contract, be sure that your network selected on MetaMask is correct: Also, you will need to fund your account with some ETH on Goerli from a faucet. You can now deploy the contract. Click on your account address from MetaMask to copy it to clipboard and then pass it as argument to the Remix deployment option. For example, Deploy: 0x06908fDbe4a6af2BE010fE3709893fB2715d61a6 Once the transaction gets mined, you can check the output from Remix. Also, you can check your transactions on MetaMask, select the last one. It should say Contract Deployment. You can always refer to the Chainstack article on how MetaMask transactions work. Once you click on it, it will display a few details of the transaction. Let us click on View on block explorer. This will open Etherscan, so we can see check our contract creation in depth. We can see that a new instance of our SimpleWallet contract was created on address 0x4388C588f2a28343dB614FFd3817eE5459f85760. Notice that we didn’t know in advance what address would be generated, and only when the contract was created and the transaction mined it was provided. What if we can precompute a contract address prior to its deployment and perform operations like sending funds to it, and then allow someone to get back those funds only when the contract gets deployed? We can achieve this by using the CREATE2 function. Let’s create a factory contract that also has the SimpleWallet contract and that will use the CREATE2 opcode as stated in Solidity docs: Salted contract creations / create2. // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract SimpleWallet { address public owner; // Only owners can call transactions marked with this modifier modifier onlyOwner() { require(owner == msg.sender, "Caller is not the owner"); _; } constructor(address _owner) payable { owner = _owner; } // Allows the owner to transfer ownership of the contract function transferOwnership(address _newOwner) external onlyOwner { owner = _newOwner; } // Returns ETH balance from this contract function getBalance() public view returns (uint256) { return address(this).balance; } // Allows contract owner to withdraw all funds from the contract function withdraw() external onlyOwner { payable(msg.sender).transfer(address(this).balance); } // Destroys this contract instance function destroy(address payable recipient) public onlyOwner { selfdestruct(recipient); } } contract Factory { // Returns the address of the newly deployed contract function deploy( uint _salt ) public payable returns (address) { // This syntax is a newer way to invoke create2 without assembly, you just need to pass salt // https://docs.soliditylang.org/en/latest/control-structures.html#salted-contract-creations-create2 return address(new SimpleWallet{salt: bytes32(_salt)}(msg.sender)); } // 1. Get bytecode of contract to be deployed function getBytecode() public view returns (bytes memory) { bytes memory bytecode = type(SimpleWallet).creationCode; return abi.encodePacked(bytecode, abi.encode(msg.sender)); } /** 2. Compute the address of the contract to be deployed params: _salt: random unsigned number used to precompute an address */ function getAddress(uint256 _salt) public view returns (address) { // Get a hash concatenating args passed to encodePacked bytes32 hash = keccak256( abi.encodePacked( bytes1(0xff), // 0 address(this), // address of factory contract _salt, // a random salt keccak256(getBytecode()) // the wallet contract bytecode ) ); // Cast last 20 bytes of hash to address return address(uint160(uint256(hash))); } } Let’s deploy this factory contract on Goerli using Remix again. We are deploying the contract the classic way so that we can later use it to precompute the deployment address. Again, select the deployment options in Remix and switch the contract to be deployed to Factory. Once the right contract is selected, deploy it. Once the deployment gets confirmed, select the deployed contract to expand it and check its available functions. Example of a deployed factory contract. Our motivation is now to deploy a new instance of our SimpleWallet contract, but knowing its contract address in advance. Fortunately, our Factory contract allows us to precompute this address. The getAddress function returns a precomputed address of a new SimpleWallet instance. It requires a salt parameter in order to return this address. For simplicity we will use 123 as salt, but it cant be any uint256 value. It’s important to note that, if you’re using your own deployed Factory contract the addresses wont be the same, as the getAddress function utilizes the Factory contract instance address to compute new SimpleWallet instance addresses. However, you can still use the one that has been deployed in this tutorial and (if using the same salt) get the same address as result. Let’s pass 123 as argument to the getAddress function and execute it from Remix. In this particular example the precomputed address is 0xf49521d876d1add2D041DC220F13C7D63c10E736. Now that we know in advance at which contract address our SimpleWallet will be deployed through our Factory contract, let’s send some funds to it. Don’t worry if nothing exists yet in there, we will recover our funds later. Go to MetaMask, input the contract address that was returned by the getAddress function and send some ETH. Now, let’s actually deploy our SimpleWallet instance and check if it’s correctly deployed to our precomputed address. In Remix, search for the Deploy function in our Factory contract instance and pass 123 as salt. Wait for the transaction and head to Etherscan to confirm that it deployed correctly. In the transaction details section (on Etherscan) select the Internal Txns tab. Once there, we see that the CREATE2 function was called from our Factory contract, and a new instance of our SimpleWallet contract was created. Click on the address of the created contract and check that the address is the same that was precomputed previously. Note that because Etherscan seems to be running OpenEthereum nodes on Goerli, CREATE2 is rendered as CREATE in the Etherscan interface. See OpenEthereum Issue 10922. If everything was correct, we should be able to withdraw the amount of ETH that we sent to our SimpleWallet contract. But first, we need a way to interact with it. For simplicity, you can also verify the contract on Etherscan, connect to it using MetaMask and withdraw the funds. Contract in our example. Interacting with our smart contract To be able to retrieve our funds, we need a way to interact with our SimpleWallet contract. First, let’s start a new Node.js project and install some required packages. mkdir deterministic-deployment-factory && cd deterministic-deployment-factory npm init --y npm i ethers Create a new file called SimpleWalletAbi.js and paste the following content. This file will serve as interface to our contract so we can interact with it using the ethers.js library. const abi = [ { "inputs": [ { "internalType": "address", "name": "_owner", "type": "address" } ], "stateMutability": "payable", "type": "constructor" }, { "inputs": [ { "internalType": "address payable", "name": "recipient", "type": "address" } ], "name": "destroy", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "getBalance", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "owner", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_newOwner", "type": "address" } ], "name": "transferOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "withdraw", "outputs": [], "stateMutability": "nonpayable", "type": "function" } ]; module.exports = { abi } Now, let’s create our index.js file and add the initial configuration required to interact with the contract const { ethers } = require("ethers"); const { abi } = require("./SimpleWalletAbi"); const PRIVATE_KEY = "<YOUR_PRIVATE_KEY>"; const simpleWalletAddress = "<YOUR_INSTANCE_ADDRESS>"; const main = async () => { // Inits a new ethers object with a provider const provider = ethers.getDefaultProvider( "<YOUR_GOERLI_PROVIDER>" ); // Inits a new ethers wallet to send transactions const signer = new ethers.Wallet(PRIVATE_KEY, provider); // Inits a new SimpleWallet instance const simpleWallet = new ethers.Contract(simpleWalletAddress, abi, signer); } main(); Good time to remind that you can get a free public node from Chainstack for your Goerli endpoint.Once our initial configuration is done, let’s check that everything is in order and we get no errors by running the script. node index.js Now, let’s add a simple query to fetch the contract balance. In this example we sent 0.2 GoerliETH to the contract, so it should show correctly the amount sent. const { ethers } = require("ethers"); const { abi } = require("./SimpleWalletAbi"); const PRIVATE_KEY = "<YOUR_PRIVATE_KEY>"; const simpleWalletAddress = "<YOUR_INSTANCE_ADDRESS>"; const main = async () => { // Inits a new ethers object with a provider const provider = ethers.getDefaultProvider("<YOUR_GOERLI_PROVIDER>"); // Inits a new ethers wallet to send transactions const signer = new ethers.Wallet(PRIVATE_KEY, provider); // Inits a new SimpleWallet instance const simpleWallet = new ethers.Contract(simpleWalletAddress, abi, signer); // Query the balance of the contract by calling // the getBalance function provider.getBalance(simpleWalletAddress).then((balance) => { // convert a currency unit from wei to ether const balanceInEth = ethers.utils.formatEther(balance) console.log(`Current balance in SimpleWallet: ${balanceInEth} ETH`) }) }; main(); Running the script again should now output the current balance in our SimpleWallet. Now, let’s actually recover the funds stored in the contract. Add the following code to the script and run it again. We should expect to receive the ETH stored in the contract and the contracts balance updated later. const { ethers } = require("ethers"); const { abi } = require("./SimpleWalletAbi"); const PRIVATE_KEY = "<YOUR_PRIVATE_KEY>"; const simpleWalletAddress = "<YOUR_INSTANCE_ADDRESS>"; const main = async () => { // Inits a new ethers object with a provider const provider = ethers.getDefaultProvider("<YOUR_GOERLI_PROVIDER>"); // Inits a new ethers wallet to send transactions const signer = new ethers.Wallet(PRIVATE_KEY, provider); // Inits a new SimpleWallet instance const simpleWallet = new ethers.Contract(simpleWalletAddress, abi, signer); // Withdraw funds from the contract try { console.log("Attempting to withdraw funds..."); const receipt = await simpleWallet.withdraw(); console.log("Funds withdrawn! :)"); console.log(receipt); } catch (error) { console.log("Funds can't be withdrawn"); console.error(error); } // Query the balance of the contract by calling // the getBalance function provider.getBalance(simpleWalletAddress).then((balance) => { // convert a currency unit from wei to ether const balanceInEth = ethers.utils.formatEther(balance) console.log(`Current balance in SimpleWallet: ${balanceInEth} ETH`) }) }; main(); Run the script one last time. Once the transaction succeeds, the funds will be withdrawn back to your address and the contract balance will show 0. In case you need it, the complete code can be found in the blog’s repository. Wrap up  Precomputing the address of a contract may increase the security and reliability of decentralized applications since the code in the smart contract is (generally) the same and will not change. It also allows to deploy a recreated version of a contract to the same address after it has been destroyed in case things get messed up. More important it allows to implement use cases for counterfactual interactions with code that has been created by a particular piece of init code that can be even generated off-chain. In this post we have reviewed a great topic about the ability to set a deterministic address for our smart contracts. We have included some great points on top of it:  How a contract address is usually generated.How can we know a contract address before deploying a new contract instance.What are the advantages and use cases of deterministic deployment. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Deploying an Ethereum smart contract with the eth.rb Ruby gem Introduction Eth.rb is the maintained Ethereum library for the Ruby language replacing the deprecated ethereum.rb one. This is a quick tutorial to walk you from zero to a fully deployed smart contract on the Ethereum Goerli testnet. The tutorial is two-part purely for educational purposes: Ruby console-based—to walk you through executing each of the commands with explanations.Script-based—just a couple of Ruby scripts with the eth.rb gem to quickly deploy your contract and interact with it. Prerequisites A Goerli node:Sign up with Chainstack.Deploy a Ropsten node.Get the deployed node’s HTTPS endpoint.Installed Ruby. See Installing Ruby.An Ethereum account funded with Goerli ether.Installed Solidity compiler. Prepare a smart contract For simplicity, let’s use the simple storage contract. Create a simplestorage.sol file: // SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.4.16 <0.9.0; contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() public view returns (uint retVal) { return storedData; } } Console walkthrough Clone the eth.rb repository: git clone https://github.com/q9f/eth.rb In the cloned repository, run the Ruby console: ruby bin/console In the console, import your Chainstack node HTTPS endpoint: client = Eth::Client.create 'CHAINSTACK_NODE_URL' Swap CHAINSTACK_NODE_URL with your endpoint. Import the private key of your Ethereum account: deployer_account = Eth::Key.new priv: 'PRIVATE_KEY' Swap PRIVATE_KEY with your account private key. Set the gas limit to spend on deploying the contract: client.gas_limit=200000 Set the max fee to spend on the deployment transaction in Wei: client.max_fee_per_gas=41000000000 Set the max tip to spend on the deployment transaction: client.max_priority_fee_per_gas=40000000000 Import the contract: contract = Eth::Contract.from_file(file: 'contracts/simplestorage.sol') Set the deployment address as checksummed: deployer_account.address Deploy the contract: client.deploy_and_wait(contract, sender_key: deployer_account, gas_limit: 200000) You have deployed your simple storage contract. Now you are going to send a transaction that will write a value to the contract with the set function. Set the contract ABI: simplestorage_abi = '[{"inputs":[],"name":"get","outputs":[{"internalType":"uint256","name":"retVal","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"x","type":"uint256"}],"name":"set","outputs":[],"stateMutability":"nonpayable","type":"function"}]' Set the contract address: simplestorage_address = "CONTRACT_ADDRESS" Swap CONTRACT_ADDRESS with the address of your deployed contract. Set the contract name: simplestorage_name = "SimpleStorage" Set the full contract: simplestorage_contract = Eth::Contract.from_abi(name: simplestorage_name, address: simplestorage_address, abi: simplestorage_abi) Checksum the contract address: simplestorage_contract.address Send the transaction that writes 1234 through the contract’s set function: client.transact_and_wait(simplestorage_contract, "set", 1234, sender_key: deployer_account) Now retrieve the set value: client.call(simplestorage_contract, "get") That’s it. Now let’s do the same walkthrough with a couple of Ruby scripts. Script walkthrough Install the eth.rb gem: gem install eth Create the contract deployment script deploy.rb: require 'eth' require 'forwardable' client = Eth::Client.create 'CHAINSTACK_NODE_URL' deployer_account = Eth::Key.new priv: 'PRIVATE_KEY' client.max_fee_per_gas=41000000000 client.max_priority_fee_per_gas=40000000000 contract = Eth::Contract.from_file(file: 'contracts/simplestorage.sol') deployer_account.address response = client.deploy_and_wait(contract, sender_key: deployer_account, gas_limit: 200000) puts response Swap CHAINSTACK_NODE_URL and PRIVATE_KEY with your values. Run the script with ruby deploy.rb. Your contract will be deployed. Now set 12345 to the contract with the transact.rb script: require 'eth' require 'forwardable' client = Eth::Client.create 'https://nd-112-260-163.p2pify.com/f50e5157dac5bf2394f91f0a0df21644' simplestorage_abi = '[{"inputs":[],"name":"get","outputs":[{"internalType":"uint256","name":"retVal","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"x","type":"uint256"}],"name":"set","outputs":[],"stateMutability":"nonpayable","type":"function"}]' simplestorage_address = "CONTRACT_ADDRESS" simplestorage_name = "SimpleStorage" simplestorage_contract = Eth::Contract.from_abi(name: simplestorage_name, address: simplestorage_address, abi: simplestorage_abi) simplestorage_contract.address deployer_account = Eth::Key.new priv: 'PRIVATE_KEY' client.gas_limit=200000 client.max_fee_per_gas=41000000000 client.max_priority_fee_per_gas=40000000000 deployer_account.address response = client.transact_and_wait(simplestorage_contract, "set", 12345, sender_key: deployer_account) puts response Swap CHAINSTACK_NODE_URL, CONTRACT_ADDRESS, and PRIVATE_KEY with your values. Run the script with ruby transact.rb. The contract will have the value 12345 set. Now read the value with a call to the contract with the call.rb script: require 'eth' require 'forwardable' client = Eth::Client.create 'CHAINSTACK_NODE_URL' simplestorage_abi = '[{"inputs":[],"name":"get","outputs":[{"internalType":"uint256","name":"retVal","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"x","type":"uint256"}],"name":"set","outputs":[],"stateMutability":"nonpayable","type":"function"}]' simplestorage_address = "CONTRACT_ADDRESS" simplestorage_name = "SimpleStorage" simplestorage_contract = Eth::Contract.from_abi(name: simplestorage_name, address: simplestorage_address, abi: simplestorage_abi) simplestorage_contract.address response = client.call(simplestorage_contract, "get") puts response Swap CHAINSTACK_NODE_URL and CONTRACT_ADDRESS with your values. This is it. Conclusion You’ve learned how to manage accounts, deploy a contract, transact with a contract, and read the contract value with one of the lesser represented languages in the Ethereum ecosystem—Ruby and the eth.rb gem. Congrats! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Deploying an NFT staking contract on the Gnosis chain Table of contents Introduction Prerequisites Setting up a dev environment with Truffle Taking a look at Truffle’s project structure Writing and compiling smart contracts in Truffle Setting up a dotenv file Setting up truffle-config Deploying and verifying our smart contract Logic flow for staking an NFT Conclusion Introduction Gnosis is an EVM-based blockchain that is currently secured by over 100k validators. It aims for fast transaction times and low transaction fees. Gnosis mainnet and its corresponding Chiado testnet use xDai and the Chiado xDai as native tokens for their respective blockchain networks. In this tutorial, we will deploy an NFT staking smart contract to the Gnosis Chain. Our project consists of two contracts:  Fuel.sol, will represent our NFT smart contract (ERC-721)  Rewards.sol, will be our staking contract that will receive new NFTs and issue rewards in the form of ERC-20 tokens.  Prerequisites  Any code editor of your choice on a machine that has NodeJs installed. A grasp of the basic concepts of Solidity and Javascript, since all of our code will be written in those two languages. We will be using Truffle to compile and deploy our smart contracts. It will be helpful, but not necessary to be familiar with the framework. Setting up a dev environment with Truffle Before we begin writing our smart contracts, we need to have a dev environment set up which allows us to compile and test our smart contracts before we deploy them to a live network. While there are many great smart contract frameworks available, we will be going with Truffle in this tutorial. To set up a dev environment with Truffle: Create a folder named nftGnosis (or any other name you like). Open the folder in your terminal, and run the command:npm init -yThis command will initialize an empty package.json in your directory. To install Truffle in your system, run:npm install -g truffleThis command will install the latest version of Truffle into your system. Let us check if Truffle was correctly installed in our system. To do so, run:truffle versionThis command should return the version of Truffle installed in your system. To initialize a basic Truffle project, first, make sure that your terminal is pointing correctly to the root of your project directory. Now, in the terminal, run:truffle init This command will install a barebones Truffle project into your local directory. This is what your terminal and project directory should look like right now: We are using VS Code as our editor, but any good code editor will do. Taking a look at Truffle’s project structure After you’ve initialized a boilerplate Truffle project, your directory should look something like this: ├── contracts     └── .gitkeep├── migrations    └── .gitkeep ├── test └── .gitkeep├── package.json ├── truffle-config.js Let us quickly go over this: The .gitkeep file is simply used as a placeholder in empty directories since Git does not allow us to push empty directories to remote repositories. This file does not affect our project in any way. The contracts directory contains all of our smart contracts. The migrations directory contains JavaScript files that are used to deploy our contracts to live networks. The test directory contains code that tests our smart contracts. Truffle supports smart contract testing in JavaScript, TypeScript, and Solidity. You can read more about this in their official docs. The package.json contains a reference to all the npm packages that we have installed in our project. The truffle-config file, as the name suggests, contains all the configurations for our Truffle project. This is a JavaScript file that exports an object that contains all of our configurations. We can define a wide variety of parameters within this object, including the networks, the Solidity version, and the provider RPC URLs, amongst many more. We will look into this in more detail below. Writing and compiling smart contracts in Truffle Before getting down to writing Solidity code, let us learn a bit about OpenZeppelin contracts. OpenZeppelin offers us a variety of products, but their contracts library is the one we will be using in this tutorial.Solidity as a language supports inheritance. This means we can use pre-built Solidity components to augment our own code. OpenZeppelin on its part has a huge library of Solidity contracts and interfaces that we can use to build ERC-20 and ERC-721 smart contracts in a secure way. Sure we could do the same without using OpenZeppelin, but why not use a library that has been thoroughly audited and optimized, thus saving us both time and money? To get started with OpenZepplin contracts, open your terminal and run: npm i @openzeppelin/contracts This command will install the @openzeppelin/contracts library into your local directory, and you can check your package.json to make sure it is installed correctly.We can now inherit OpenZeppelin contracts into our own solidity code. We are now ready to start writing some Solidity code. In the contracts folder, create 2 files: Fuel.sol: This will be our ERC-721 contract Rewards.sol: This contract will contain the logic for our staking system. Fuel.sol In an empty Fuel.sol, paste the following code: // SPDX-License-Identifier: MIT pragma solidity ^0.8.13; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/utils/Counters.sol"; contract Fuel is ERC721, ERC721Burnable, Ownable { using Counters for Counters.Counter; Counters.Counter private _tokenIdCounter; constructor() ERC721("Fuel", "FUEL") {} function safeMint(address to) public onlyOwner { uint256 tokenId = _tokenIdCounter.current(); _tokenIdCounter.increment(); _safeMint(to, tokenId); } } This is a small, but quite effective ERC-721 contract that does the following: The constructor initializes the contract name and symbol at the time of deployment. The counters.sol contract helps us keep track of all the NFTs that have been minted from our contract. Every time a new NFT is minted, the token ID is incremented. This means each NFT minted from our contract has a unique token ID that can be used to uniquely identify it. The safeMint() function uses the _safeMint() function from the ERC-721 contract, which allows us to conveniently mint a new NFT to a specific address. Please note that while we define the ‘safeMint()‘ function, the ‘_safeMint()‘ function is inherited from the ERC-721 contract. You can read more about the ERC-721 template from OpenZeppelin’s official docs.The onlyOwner modifier helps us in preventing unauthorized people from calling sensitive functions. ERC721Burnable.sol gives us access to the burn function, which can be used to ‘burn’ a specific NFT by basically transferring it over to the ‘zero’ address, which is basically a generic null address that has no owner. Rewards.sol Now open Rewards.sol, and paste the following code inside it: // SPDX-License-Identifier: MIT pragma solidity ^0.8.17; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/token/ERC721/utils/ERC721Holder.sol"; import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; contract Rewards is ERC20, ERC721Holder, Ownable { IERC721 public nft; mapping(uint256 => address) public tokenOwnerOf; mapping(uint256 => uint256) public tokenStakedAt; mapping(uint256 => bool) public isStaked; uint256 public rewardsPerHour = (1 * 10 ** decimals()) / 1 hours; constructor(address _nft) ERC20("Reward", "RWD") { nft = IERC721(_nft); } function stake(uint256 tokenId) external { nft.safeTransferFrom(msg.sender, address(this), tokenId); tokenOwnerOf[tokenId] = msg.sender; tokenStakedAt[tokenId] = block.timestamp; isStaked[tokenId] = true; } function calculateRewards(uint256 tokenId) public view returns (uint256) { require(isStaked[tokenId], "This Token id was never staked"); uint timeElapsed = block.timestamp - tokenStakedAt[tokenId]; return timeElapsed * rewardsPerHour; } function unstake(uint256 tokenId) external { uint timeElapsed = block.timestamp - tokenStakedAt[tokenId]; uint minimumTime = 7 days; require(tokenOwnerOf[tokenId] == msg.sender, "You can't unstake because you are not the owner"); require(timeElapsed >= minimumTime, "You need to stake for at least 7 days"); _mint(msg.sender, calculateRewards(tokenId)); nft.transferFrom(address(this), msg.sender, tokenId); delete tokenOwnerOf[tokenId]; delete tokenStakedAt[tokenId]; delete isStaked[tokenId]; } } This is our main staking smart contract. Let us go over the main concepts of this contract carefully: The contract uses four OpenZeppelin contract templates, namely: ERC20.sol: The ERC-20 contract, allows us to create a smart contract for fungible tokens. The contract constructor specifies the name, symbol, and initial minting quantity of our token. Ownable.sol: The ownable contract allows us to manage access to our contract functions in a simplified manner. Whenever a smart contract inherits the ownable contract, the deployer of the contract is set as its owner. ERC721Holder.sol: This is an interesting one. When we finally deploy our smart contracts, we will need to approve the Rewards.sol contract to be able to transfer NFTs from Fuel.sol to its own address. That is what we call ‘staking an NFT‘. But for a contract to be able to call the transfer function on an NFT from another contract, it must support the IERC721Receiver interface. The ERC721Holder.sol is simply a convenient implementation of the interface. We just need to inherit the contract into our main Rewards contract. If that was a bit confusing, we recommend you take a look at what interfaces do in Solidity. A look at OpenZeppelin’s official docs will be helpful too. IERC721.sol: This is simply the interface that ERC721 contract is based on. Since our Fuel smart contract is an ERC721 implementation, we can initiate an instance of the Fuel contract in our Rewards contract by wrapping its address inside the IERC721 interface. As you can see in the constructor, we will be providing the address of the Fuel contract to the Rewards contract while deployment. The constructor simply accepts an address argument and initializes an ERC20 token with the symbol “RWD“. The staking function is quite simple. We call the safeTransferFrom() function on the instance of the Fuel contract, which transfers an NFT of a specific token ID to the Rewards contract. Once this is done, we update three mappings in our contract. These mappings keep track of the owners of the NFTs, the specific timestamps when they were staked, and a list of valid token IDs.Please note that the function will only work if two conditions are fulfilled- The token ID being passed as the parameter should actually be a valid, minted token ID. And, the address calling the function should actually own the NFT of that specific token ID. The function calculateRewards() simply calculates the amount of tokens we need to give to the owner of a staked NFT based on the amount of time an NFT has been staked for. The function calculates the amount for only valid token IDs, which we keep track of with the help of isStaked[] mapping. The unstake function will allow an owner to unstake an NFT after a minimum of 7 days. The function mints an exact amount of RWD tokens and transfers them to the NFT owner, following which the NFT is returned to the original owner. All data corresponding to that token ID is then deleted. Please feel free to tinker around with the logic of the contract. You can calculate rewards based on other parameters. You can change the minimum staking time or perhaps remove it altogether. That was quite a lot to digest, but we now have our staking smart contract ready to go. To compile smart contracts in Truffle, we need to run the compile command in our terminal: truffle compile This command compiles all the smart contracts in the contracts directory, and generates artifacts for them in the build/contracts directory. Subsequent invocations of the command will only compile those smart contracts that have undergone any changes since the last compile command. Setting up a dotenv file We will soon be deploying and verifying the NFT staking smart contract. To do so, we need three main values: RPC_URL: Truffle needs to connect to a blockchain node to deploy our contract. We can connect to a blockchain using an HTTPS endpoint for a particular blockchain. For a fast and reliable connection to a live network, we recommend you use an endpoint from a provider like Chainstack that is run and maintained by a dedicated team behind the scenes. If you have never set up a node using Chainstack before, feel free to go through this tutorial from our blog. PRIVATE_KEY: Truffle needs access to a wallet’s private key to be able to sign transactions and send them to the blockchain. In this tutorial, we will be deploying our smart contract to the Gnosis mainnet, so make sure to use the private key of a wallet that has some xDAI tokens from the Gnosis chain. API_KEY: We will be verifying our deployed smart contract from Truffle’s command line. To do so, we need an API key from Gnosisscan. You can get started by signing up here. It is possible to plugin these values directly into the truffle-config file to get up and running, but we would highly discourage you from doing so. Putting these values directly into the config file can lead to you pushing them onto a remote directory which could potentially compromise your funds. We can instead export our sensitive data securely using the dotenv package. That is what we will do now. Once you have these three variables, open the terminal, make sure it is pointing to the root directory, and run: npm i dotenv This will install the dotenv package into your local directory. Again, in your terminal run: touch .env This will create an empty .env file inside your project. Paste the following code inside the file: PRIVATE_KEY="0x0000000000000000000" CHIADO_RPC_URL=https://123-456-789 GNOSIS_RPC_URL=https://987-654-321 API_KEY=ABCDEFGHIJKLMNOPQRSTUVWXYZ Simply replace the mock data with your actual keys and URLs. Note that we are putting two different RPC URLs into our dotenv file. This is because we will define two different networks in our truffle-config file, one for the Gnosis mainnet, and the other for the Chiado testnet. Once you are ready, save the dotenv file. Setting up truffle-config We need to install two packages to power our truffle-config file: HD wallet provider: We need to define a provider to sign transactions through truffle. A provider in Truffle is basically a combination of a private key/mnemonic with an RPC URL. These two values used together can sign transactions to a particular blockchain from a particular wallet address. truffle-plugin-verify: Truffle allows us to install a variety of officially supported plugins into our project. This plugin can be used to verify smart contracts on certain blockchains. To install these plugins, run the following commands in your terminal: npm i @truffle/hdwallet-provider npm i truffle-plugin-verify Now that you have all the required plugins, go to your truffle-config file and delete everything inside of it.Paste the following code into the file: require('dotenv').config(); const HDWalletProvider = require("@truffle/hdwallet-provider"); module.exports = { networks: { GnosisMainnet: { provider: () => { return new HDWalletProvider([process.env.PRIVATE_KEY], `${process.env.GNOSIS_RPC_URL}`); }, network_id: 100, }, ChiadoTestnet: { provider: () => new HDWalletProvider([process.env.PRIVATE_KEY], `${process.env.CHIADO_RPC_URL}`), network_id: 10200, }, }, compilers: { solc: { version: "0.8.17", settings: { optimizer: { enabled: true, runs: 50, }, }, }, }, plugins: ['truffle-plugin-verify'], api_keys: { gnosisscan: `${process.env.API_KEY}` }, }; Let us go over the major configurations we define here: Networks: We can define multiple networks inside truffle-config. Each network has to contain at least one provider along with a chain ID. A new provider can be declared as a new instance of the hdwallet-provider object that contains at least one private key and an HTTPS or WSS URL corresponding to a particular blockchain. The compiler object supports various tweaks to the Solidity compiler. Here we simply define the Solidity version and ask the compiler to optimize the contract deployment for an expected 50 calls throughout its lifetime. You can read more about the supported configurations on Truffle’s reference page. plugins: Truffle allows us to use a variety of plugins that can be installed as NPM dependencies. In this tutorial, we are using only one plugin as explained previously. Deploying and verifying our smart contract Before moving further, please note that Gnosis mainnet recently went through the merge. If you don’t know what the merge is, or what it meanse for the Gnosis chain, you can refer to this article from our blog. Gnosis Merge We have now configured everything in our truffle-config file. To actually deploy a contract in Truffle, however, we need to write a basic deployment script. Go to the migrations directory, and create a file named 1_deploy_contract.js. Inside the file, paste the following code: const Fuel = artifacts.require("Fuel"); const Rewards = artifacts.require("Rewards"); module.exports = async function (deployer) { await deployer.deploy(Fuel); await deployer.deploy(Rewards, Fuel.address); await Fuel.setApprovalForAll(Rewards.address, true); }; This is a very simple deployment script. We import the ABIs of our smart contracts from the artifacts folder. After that, we call the deploy function on all three of the contracts in an async function.Please note that the NFTstake contract requires the addresses of both Fuel.sol and Rewards.sol in its constructor. Therefore, those not only have to be deployed first, but we also need to pass their respective addresses in NFTstake’s parameters. Please note that Truffle has a very specific naming convention for its migration files. We strongly recommend you follow this naming convention or the deployment script may not work as intended. You can read more about these conventions on Truffle’s docs. To deploy our smart contracts to a live network, open the terminal and run: truffle migrate --network GnosisMainnet This will engage 1_deploy_Contract.js and deploy the contract to the Gnosis mainnet as specified in truffle-config.js. Now onto the verification part. Please note that the Gnosisscan API key that we added to our project does not support contract verification on the Chiado testnet. We can only use it to verify contracts on the Gnosis mainnet.To verify a smart contract on the Gnosis mainnet using a Gnosisscan API key in Truffle: Deploy a smart contract to Gnosis mainnet using the migrate command with the corresponding network flag as shown above. Run the following command in your terminal after your contract has been deployed successfully. truffle run verify <CONTRACT_NAME>@<CONTRACT_ADDRESS> --network GnosisMainnet This will verify your smart contract on the Gnosis network and return a success message. Your smart contract is now verified!Verify both the smart contracts on the Mainnet, and you can now interact with them right from Gnosisscan explorer. If you don’t have xDAI tokens from the mainnet, you can still follow through the tutorial by deploying the contracts to the Chiado testnet. It is just that you won’t be able to use Truffle to verify your contracts. You can still verify them by going to the Chiado explorer. If you need some testnet xDAI tokens, you can get them from the official faucet Logic flow for staking an NFT Both of our smart contracts are now deployed and verified on the Gnosis Mainnet. In this last section, we will briefly go over the logic flow for the staking mechanism: Deploy Fuel.sol. Now Copy Fuel.sol‘s contract address and pass it to the constructor of Rewards.sol. Now deploy the second smart contract. We already completed this step through the migrations script. Call the safe mint function and mint an NFT each to at least 2 unique addresses. You can check that the NFTs were minted properly by calling the currentTokenID() and ownerOf() functions. Now go to Rewards.sol and try staking an NFT to it by calling the stake function with a token ID parameter. It won’t work.Why? Because we never approved the Rewards.sol as an eligible recipient of a Fuel NFT.When you have an ERC721 NFT, you as the owner can hand over custody of your NFT by calling the setApprovalForAll() function, thus approving a particular address as an authorized handler of your NFTs. Go to Fuel.sol and approve the Rewards contract as a recipient by calling the function. Now all the NFTs of a particular wallet can be staked at Rewards.sol. Please note that only the NFTs of those addresses can be staked at the Rewards contract, those who authorized the rewards contract as an approved handler by calling the setApprovalForAll()function. If you want to stake NFTs from 10 different addresses at Rewards.sol, you will have to call the setApprovalForAll() from those 10 different addresses before staking their NFTs with the rewards contract. Conclusion In this tutorial, you learned how to compile, test and deploy smart contracts using the Truffle framework. We deployed an NFT staking smart contract on Gnosis mainnet through a migrations script in Truffle and then verified it using an API key from Gnosisscan. You can go to our blog for more tutorials like this. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Developers can’t get enough of Global Nodes We all have been minting, swapping, bridging or interacting with DApps, and get frustrated with latency issues and network congestion But what if I told you there’s a solution that has been the preferred choice for developers of late? That’s our Global Nodes for you, the unsung heroes of Chainstack infrastructure. Let’s jump straight into why they’re such a big deal and how they’ve been smashing records. What makes Global Nodes so special? They use geo-load balancing to route your requests to the closest server, slashing latency and boosting performance. And if one goes down? Another takes its place! These nodes adapt in real time, switching to the one that’s to keep your project humming along. Why you should be paying attention Web3 is an exciting space, but it’s not without its headaches. Performance and reliability can often make or break a project. That’s where Global Nodes offer a competitive advantage for Web3 developers. They offer a level of global connectivity, scalability, and reliability that’s hard to beat. Plus, they’ve got robust protection against DDoS attacks, so you can focus on what really matters: your project. The quiet achievements you might have missed Sure, let’s dive into the stats. Global Nodes have been absolutely crushing it since they launched in late June. In just two months, Chainstack Global Nodes have processed tens of billions in monthly requests! What do these numbers actually mean? So, billions of requests are cool and all, but what’s the real impact? Today, Chainstack Global Nodes represent north of 10% of our elastic nodes request usage. We expect this trend to growth, making it clear Global Nodes are the preferred choice for developers. It shows how much the Web3 community is leaning on this technology. Why this matters You might be asking, “Okay, but why should I care?” These aren’t just vanity metrics. They’re a sign of how Global Nodes are making life easier for everyone across the blockchain landscape and offer a glimpse into the stability and peace of mind that this incredible piece of decentralized technology delivers to the Web3 developer community. Whether you’re a seasoned developer or just getting your feet wet, these nodes ensure you’re getting top-notch performance. What’s on the horizon? Don’t think we’re just sitting back and admiring these numbers. We’ve got some killer updates in the works to make Global Nodes even more awesome. Coming soon, you can expect features like …archive nodes support, debug & trace requests support, and a slew of new protocols. So, stay tuned. Bringing it all together In a nutshell, our Global Nodes have been setting a new standard in Web3 performance and reliability. With their impressive track record, they’re not just changing the game; they’re changing how we play it. So, isn’t it time you experienced what all the fuss is about? Start your BUIDL for free today! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Developing DApps: The ultimate guide to building on Chainstack Welcome, aspiring Web3 developers! We at Chainstack understand that the blockchain ecosystem can often seem overwhelming with its vastness and nuances. That’s why we’ve put together this comprehensive guide designed specifically with you in mind. With Chainstack, developing decentralized applications becomes a streamlined process. We’re here to help you navigate the complexities and make the most out of our diverse range of supported blockchain networks and features. This guide covers everything from choosing the ideal blockchain network for your DApp, making sense of Layer 1 and Layer 2 networks, and leveraging the reliability-enhancing features of Chainstack, to interpreting error codes and selecting apt authentication methods. Whether you’re just starting your Web3 journey or looking to refine your development processes, this guide offers the essential insights to elevate your projects. Let’s explore together! How to choose the right chain for your project? Your choice of blockchain protocol can determine the fate of your project. Therefore, a comprehensive understanding of Layer 1 and Layer 2 networks can prove invaluable. Layer 1 networks Layer 1 networks are the foundational blockchains that foster decentralization and utmost security. Examples include Ethereum, BNB Smart Chain, and so forth. They offer a robust, trustless environment for DApps but can sometimes be hindered by scalability issues and high gas fees. Their key characteristics include: Decentralization: Highly decentralized with a distributed network of nodes. Examples include Bitcoin and Ethereum. Security: Robust consensus mechanisms like PoW or PoS ensure security. Scalability: Some L1 networks face scalability challenges, leading to congestion and high fees. Smart contracts: Support for decentralized applications with programmable logic. Native tokens: Used as gas fees or as a store of value. Leading Layer 1 networks supported by Chainstack Ethereum: A decentralized platform for DApps and smart contracts. Best for decentralized applications requiring robust smart contract functionality. BNB Smart Chain: High-performance network compatible with the Ethereum Virtual Machine. Best for DApps requiring high-speed and low-cost transactions. Avalanche: Offers scalable, customizable, and interoperable blockchain solutions with a unique consensus mechanism. Best for developers and projects seeking customizable blockchain-based applications with specific requirements. Fantom: Known for fast transaction processing, scalability, and many use cases. Best for high-performance decentralized applications and diverse use cases. Layer 2 networks Contrastingly, Layer 2 networks are the secondary networks or ‘off-chain’ solutions designed to overcome the limitations of Layer 1. They are often quicker, more scalable, and have lower transaction fees. These include Plasma, Rollups, and more. Key characteristics of L2 networks include: Scalability solutions: Designed to offload transactions from L1, increasing throughput and reducing congestion. Cost efficiency: Offer cost-effective alternatives for microtransactions. Interoperability: Can connect different L1 networks or bridge to traditional financial systems. Security: Benefit from the security of L1 but may have unique security considerations. Use cases: Ideal for high transaction throughput applications like gaming and DeFi. Top layer 2 networks supported by Chainstack Polygon: A Layer 2 scaling solution for Ethereum. Best for addressing Ethereum’s high gas fees and slow transaction times. Polygon zkEVM: The first zero-knowledge scaling solution compatible with the Ethereum Virtual Machine. Best for integrating smart contracts and developer tools with enhanced scalability. zkSync Era: Scales Ethereum with cutting-edge ZK tech and is fully compatible with the Ethereum Virtual Machine. Best for applications requiring high scalability without compromising Ethereum compatibility. Account abstraction out of the box. Optimism: A scaling solution for Ethereum using optimistic rollups. Best for achieving high throughput and low fees on the Ethereum network. Base: An Ethereum Layer 2 scaling solution built on top of Optimism. Best for secure, low-cost, and developer-friendly scaling on Ethereum. Arbitrum: Designed to enhance the performance of Ethereum-based DApps by providing a more efficient platform. Best for addressing scalability and high gas fee issues on Ethereum. Starknet: Enables Ethereum to scale securely using zk-STARKs technology. Best for enhancing data security, privacy, and scalability on Ethereum. Scroll: A reliable and scalable Layer 2 network that extends Ethereum’s capabilities. Best for scaling applications on Ethereum without compromising on performance. Making an informed choice between Layer 1 and Layer 2 requires getting to grips with the advantages and limitations of both. As each DApp has its unique requirements and audiences, there isn’t a one-size-fits-all solution. Read Solving the Blockchain Trilemma: A Look at Some Scaling Solutions to better understand Layer 2 solutions. How to make your DApp more reliable with Chainstack? As DApp developers, you’re tasked with the mission to create decentralized applications that are not only innovative but run seamlessly, ensuring a satisfactory user experience. That’s where we step in, offering robust solutions like our Global Nodes that amplify your DApp’s reliability and performance. Let’s break it down. A Global Node allows access to Ethereum nodes worldwide, which in turn ensures high-grade uptime and performance in every corner of the globe. This unique feature of Chainstack can drastically reduce latency, leading to swift and efficient transactions. Our nodes aren’t confined to specific locations. They are present in diversely located data centers worldwide, ensuring your Dapp remains operational round-the-clock, regardless of your audience’s geographical position. And the best part? This wide spectrum is automatically available to you by default—no extra step, no added configuration. The main advantages of Chainstack Global Nodes are as follows: Enhanced load balancing: Global Nodes feature a robust load balancer that can switch nodes if one fails or lags by more than 40 blocks, ensuring uninterrupted service. Reduced latency: By distributing traffic to the nearest endpoint, Global Nodes reduce latency, resulting in faster transactions and an improved user experience. Global reach: Accessible from any location, Global Nodes direct users to the nearest endpoints, maximizing service availability and responsiveness. High availability: Designed to be 99.95% available, Global Nodes ensure that your DApp continues to run with minimal interruptions. How to integrate Chainstack Global Nodes into your project? By leveraging Chainstack Global Nodes, you can take your DApp’s performance to the next level, leaving behind worries of network congestion or node collapse. Get ready to witness the power of a seamless global infrastructure in action. Web3JS example: const { Web3 } = require("web3"); const NODE_URL = "YOUR_CHAINSTACK_WSS_ENDPOINT"; // Reconnect options const reconnectOptions = { autoReconnect: true, // Automatically attempt to reconnect delay: 5000, // Reconnect after 5 seconds maxAttempts: 10, // Max number of retries }; const web3 = new Web3( new Web3.providers.WebsocketProvider(NODE_URL, undefined, reconnectOptions) ); async function subscribeToNewBlocks() { try { // Create a new subscription to the 'newBlockHeaders' event const event = "newBlockHeaders"; const subscription = await web3.eth.subscribe(event); // Changed to 'newHeads' console.log(`Connected to ${event}, Subscription ID: ${subscription.id}`); // Attach event listeners to the subscription object for 'data' and 'error' subscription.on("data", handleNewBlock); subscription.on("error", handleError); } catch (error) { console.error(`Error subscribing to new blocks: ${error}`); } } // Fallback functions to react to the different events // Event listener that logs the received block header data function handleNewBlock(blockHeader) { console.log("New block header:", blockHeader); } // Event listener that logs any errors that occur function handleError(error) { console.error("Error when subscribing to new block header:", error); } subscribeToNewBlocks(); ethersJS example: const ethers = require("ethers"); const WebSocket = require("ws"); const NODE_URL = "YOUR_CHAINSTACK_WSS_ENDPOINT"; function createWebSocket() { const ws = new WebSocket(NODE_URL); ws.on("close", () => { console.log("Disconnected. Reconnecting..."); setTimeout(() => { provider = new ethers.WebSocketProvider(createWebSocket()); startListening(); }, 3000); }); ws.on("error", (error) => { console.log("WebSocket error: ", error); }); return ws; } let provider = new ethers.WebSocketProvider(createWebSocket()); function startListening() { provider.on("block", async (blockNumber) => { console.log("New block number:", blockNumber); const block = await provider.getBlock(blockNumber); console.log("Block details:", block); }); } startListening(); How to use API endpoints on Chainstack API endpoints are essential for your DApp, as they define the routes for interacting with the database and handling client-server communication effectively. With an appropriate understanding and utilization of various API endpoints, you, as a Web3 developer, can elevate the performance of your DApp. In Chainstack, each API endpoint corresponds to a different datatype, service, or function. These endpoints allow your DApp to interact with protocol and node data, among other services, facilitating seamless data exchange. Figure 1: Deploying a Global Node in Advanced mode on Chainstack demo Always remember, that good command over API endpoints not only enhances your application’s performance but also elevates the end-user experience to a new height. It’s like mastering the art of communication in the digital world, and as a developer, you would know how vital that can be! Below are examples in JavaScript and Python to help you get familiar with the Chainstack platform API. API key authentication The Chainstack API uses API keys to authenticate requests. Include your API key in the Authorization header. The header value should be the Bearer prefix followed by the secret key generated through the platform’s user interface. Here’s an example using curl: curl -X GET '<https://api.chainstack.com/v1/organization/>' \\\\ --header 'Authorization: Bearer YOUR_API_KEY' API calls using JavaScript This example shows how to interact with the Chainstack platform API using Node.js and the Axios library. It illustrates how to communicate with the API using code. Set the environment variable: BEARER_TOKEN="YOUR_API_KEY" Ensure you install axios and dotenv before running the code: npm i axios dotenv require('dotenv').config(); const axios = require('axios'); async function getOrganization() { try { const response = await axios.get('<https://api.chainstack.com/v1/organization/>', { headers: { 'Authorization': `Bearer ${process.env.BEARER_TOKEN}` } }); console.log(response.data); } catch (error) { console.error(error); } } getOrganization(); This example uses the “Get Organization name and ID” endpoint to fetch information about the organization. It’s a straightforward way to incorporate API calls into your routine tasks. API calls using Python This example demonstrates how to interact with the Chainstack platform API using Python and the requests library. It shows how to communicate with the API using Python code. Ensure you install requests and python-dotenv before running the code: pip install requests python-dotenv import os from dotenv import load_dotenv import requests load_dotenv() def get_nodes(): try: response = requests.get( '<https://api.chainstack.com/v1/nodes/>', headers={'Authorization': f'Bearer {os.getenv("BEARER_TOKEN")}'} ) response.raise_for_status() print(response.json()) except requests.exceptions.RequestException as err: print(f"An error occurred: {err}") get_nodes() This example calls the “List all Nodes” endpoint to fetch data about the nodes deployed by your organization. This makes it easy to introduce API calls into your Python workflow. Best practices for error handling in API requests While developing DApps, handling HTTP status codes is vital to ensure a responsive and glitch-free interaction for your users. These codes, three-digit numbers, provide both users and developers with a snapshot of how the request has fared. Successes, for example, are generally coded with 2xx, but you’re more likely to encounter 4xx and 5xx when things aren’t as smooth. The 400 series is used when the client seems to be at fault, say, owing to a bad request or unauthorized access. On the other hand, the 500 series indicates that the problem pertains to server errors. Implementing proper error handling in your DApps can substantially enhance customer experience, as users will be provided detailed feedback in case something goes wrong, guiding their next actions. Though it might seem an uphill task, keep in mind that understanding and correctly working with these status codes can spell the difference between a great DApp and a mediocre one. Practical example for error handling in API requests To handle HTTP status codes, we first need to know how to retrieve them. In Python, this can be done using the status_code attribute of the response object. This attribute holds the status code returned by the server for the HTTP request. Let’s consider a scenario where we want to get the logs of the latest block. Here is an example of how to do this using Python: import json import requests node_url = 'YOUR_CHAINSTACK_ENDPOINT' headers = { "Content-Type": "application/json" } payload = { "jsonrpc": "2.0", "method": "eth_getLogs", "params": [ { "fromBlock": "latest", "toBlock": "latest", } ], "id": 1 } response = requests.post(node_url, headers=headers, json=payload) print(response.text) If the above code runs successfully, it will output the logs for the latest block. This indicates that the response code received by the client (you, who made the request) was 200. To retrieve the response code of the request shown above, you can use the following: # Considering this request: response = requests.post(node_url, headers=headers, json=payload) # Here's how we can get the response code for such request: response_code = response.status_code print('status code:', response_code) This will store the HTTP status code of the response in the status_code attribute. Now that you know how to retrieve the status code of a response, you can move on to handling these codes and analyzing error responses. Analyzing error responses In addition to dealing with response codes, it’s also important to analyze other information in the response to understand and address errors. This can be particularly useful when the server returns a 4xx or 5xx status code, indicating a client or server error. For instance, let’s consider a possible response for an eth_getLogs request that contains an error message: {"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"failed to get logs for block #192001 (0xa388fd..65beb8)"}} In this case, the server returned a JSON object with an error field, which contains additional information about the error that occurred. We can extract this information in our Python code as follows: response = requests.post(node_url, headers=headers, json=payload) response_code = response.status_code print('status code:', response_code) if response_code == 200: response_data = json.loads(response.text) if 'error' in response_data: error_content = response_data['error'] print('Error:', error_content) In this code, we first check if the response’s status code is 200, indicating a successful request. If it is not, we parse the JSON content of the response and check if it contains an error field. If it does, we store the content of this field in the error_content variable. This information can be used to implement retry logic and keep a record of whenever these errors occur. Importance of implementing retry logic Incorporating retry logic into your code can significantly enhance the reliability of your application. By leveraging the tools and techniques we have discussed, you can implement a retry mechanism that automatically handles temporary failures and retries the request when necessary. This can reduce the impact of temporary failures, increase system availability, and ensure data integrity. In the worst-case scenario, this enables you to keep track of the errors you face with precise timestamps. Implementing retry logic is particularly important when dealing with 5xx server errors. These errors indicate a problem with the server and are often temporary. By implementing retry logic, your application can automatically retry the request after a short delay, giving the server a chance to recover. This can significantly improve the user experience by reducing the number of failed requests the user has to deal with. Implementing retry logic in code Now that we understand the importance of implementing retry logic, let’s dive into how to implement it in our Python code. Our retry logic aims to automatically retry the request when a temporary failure occurs, such as a 5xx server error or a connection error. Here’s an example of how to implement retry logic in Python, using both the response code and error messages to determine when to retry a request: import json import time import requests node_url = 'YOUR_CHAINSTACK_ENDPOINT' headers = { "Content-Type": "application/json" } payload = { "jsonrpc": "2.0", "method": "eth_getLogs", "params": [ {"fromBlock": "latest", "toBlock": "latest"} ], "id": 1 } # Max retries retries = 5 delay = 1 # Seconds def get_logs(): for i in range(retries): response = requests.post(node_url, headers=headers, json=payload) if response.status_code != 200: print(f"Request failed with status code {response.status_code}. Retrying attempt {i+1}...") time.sleep(delay) continue response_data = json.loads(response.text) if 'error' in response_data: print(f"There was an error in attempt {i+1}: {response_data['error']}") time.sleep(delay) continue logs = response_data.get("result", []) if len(logs) > 0: block_number = int(logs[0]['blockNumber'], 16) print(f"Block number from eth_getLogs call: {block_number} in attempt {i+1}") print('Processing the event logs...') return print(f"Result is empty for this block in attempt {i+1}") time.sleep(delay) get_logs() The retry logic is governed by a for loop that runs up to a predefined maximum number of attempts (the retries variable). For each iteration of the loop, which represents an attempt to fetch the logs, the code performs the following steps: Send request: A POST request is sent to the Ethereum node with the defined headers and payload. Check status code: If the HTTP status code of the response is not 200 (indicating a successful request), the code prints a message indicating the request failed and the current attempt number. Then, it waits for the specified delay period (the delay variable) before proceeding to the next iteration of the loop. This delay helps in cases where the server might be temporarily overloaded or experiencing other transient issues. Handle errors: If the status code is 200, the response is parsed into JSON format and checked for an error key. If error is present, the code prints a message with the error details and the current attempt number, waits for the specified delay period, and proceeds to the next iteration of the loop. This handles cases where the request was technically successful, but the response indicates an error condition that might be resolved with a retry. Check empty results: If there’s no error key but the result is empty, the code prints a message indicating this fact and the current attempt number, waits for the specified delay period, and proceeds to the next iteration of the loop. This handles situations where the request was successful but didn’t provide any logs to process. If the function hasn’t returned by the end of the loop (meaning it hasn’t successfully processed a set of logs), it will have retried the request the maximum number of times. At this point, the function will exit, effectively giving up on fetching logs after exhausting all the allowed attempts. Using response codes and error messages in retry logic As seen in the example, both the response code and error messages are used in the retry logic. The response code indicates whether the request was successful, while error messages provide detailed information about what went wrong. By using both pieces of information, the retry logic becomes more intelligent and effective. For instance, the request can be retried immediately if the error message indicates a temporary problem, or it can wait for a longer delay if the error message indicates a more serious issue. Logging error messages also helps keep a record of the errors, which is useful for debugging and improving the application. Common problems and gotchas While handling HTTP status codes and implementing retry logic can improve the reliability of your application, there are some common problems and gotchas to be aware of. Importance of effective retry logic and robust error backlogs Without effective retry logic and robust error backlogs, your application may not recover from temporary failures, leading to a poor user experience and potential data loss. An effective retry logic should consider the nature of the error and adjust its behavior accordingly. For example, if the error is temporary (such as a 5xx server error), the retry logic should wait for a short delay before retrying the request. If the error is permanent (such as a 4xx client error), the retry logic should not retry the request, but rather log the error and notify the user. A robust error backlog helps track errors in your application, allowing for more effective debugging and issue resolution. It also provides valuable insights into the performance and reliability of your application, helping to identify areas for improvement. How to create a .env file with all your Chainstack endpoints in Python Chainstack offers a robust API that enables efficient data retrieval about your projects and endpoints. In this example, we will use the “list all nodes” API. This API allows you to seamlessly extract a comprehensive list of nodes associated with your account. Additionally, we will demonstrate how to automate the creation of a .env file with the fetched data. Follow these steps to create a Python script that retrieves endpoint data from the Chainstack API and automates the creation of a .env file with the fetched data. Step 1: Create a new Python file Create file: Create a new Python file in your project’s root directory (the same location where you created the .env file). Name this file get_endpoints.py. Purpose: This naming convention indicates the file’s purpose, which is to retrieve endpoint data. Step 2: Add code to the Python file Open file: Open get_endpoints.py in your preferred code editor. Paste script: Add the following Python script designed to interact with the Chainstack API, retrieve blockchain node information, and create a configuration file with these details. import requests import os import logging from dotenv import load_dotenv from web3 import Web3 from typing import Optional, Dict, Any # Load environment variables load_dotenv() # Constants CHAINSTACK_API_KEY = os.getenv('CHAINSTACK_API_KEY') OUTPUT_FILE_NAME = 'rpc.env' # Initialize logging logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') def fetch_chainstack_data(api_key: str) -> Optional[Dict[str, Any]]: """Fetch data from Chainstack API.""" url = "<https://api.chainstack.com/v1/nodes/>" headers = { "accept": "application/json", "authorization": f"Bearer {api_key}" } try: response = requests.get(url, headers=headers) response.raise_for_status() data = response.json() logging.info(f"Fetched {len(data.get('results', []))} items from Chainstack.") return data except requests.RequestException as e: logging.error(f"Failed to fetch data from Chainstack: {e}") return None def process_chainstack_item(item: Dict[str, Any]) -> Dict[str, str]: """Process a single item from Chainstack data.""" logging.debug(f"Processing item: {item['name']} with ID {item['id']}") return { 'id': item['id'], 'name': item['name'], 'details': item['details'], 'http_endpoint': item['details'].get('https_endpoint'), 'auth_key': item['details'].get('auth_key'), 'configuration': item['configuration'], 'client': item['configuration'].get('client') } def connect_to_web3(reconstructed_endpoint: str) -> bool: """Connect to a Web3 endpoint.""" logging.debug(f"Attempting to connect to Web3 endpoint: {reconstructed_endpoint}") try: w3 = Web3(Web3.HTTPProvider(reconstructed_endpoint)) if w3.is_connected(): chain_id = w3.eth.chain_id logging.info(f"Connected to {reconstructed_endpoint} with chain ID: {chain_id}") return True else: logging.warning(f"Failed to connect to {reconstructed_endpoint}") except Exception as e: logging.error(f"An error occurred while connecting to {reconstructed_endpoint}: {e}") return False def sanitize_name(name: str) -> str: """Sanitize the endpoint name for use as an environment variable key.""" return name.replace(" ", "_").replace("-", "_").replace("/", "_").upper() def create_env_file(endpoint_info_dict: Dict[str, Dict[str, str]], filename: str = OUTPUT_FILE_NAME) -> None: """Create a .env file from the endpoint info dictionary.""" logging.info(f"Preparing to write {len(endpoint_info_dict)} endpoints to .env file.") with open(filename, 'w') as file: for endpoint, info in endpoint_info_dict.items(): sanitized_name = sanitize_name(info['name']) file.write(f'{sanitized_name}_URL="{endpoint}"\\\\n') logging.info(f".env file created successfully at {filename}.") def main() -> None: """Main function to orchestrate the process.""" logging.info("Starting main process.") if not CHAINSTACK_API_KEY: logging.error("Chainstack API key not found.") return json_data = fetch_chainstack_data(CHAINSTACK_API_KEY) if not json_data: return endpoint_info_dict = {} for item in json_data.get('results', []): data = process_chainstack_item(item) reconstructed_endpoint = f"{data['http_endpoint']}/{data['auth_key']}" if connect_to_web3(reconstructed_endpoint): endpoint_info_dict[reconstructed_endpoint] = {'name': data['name']} if endpoint_info_dict: create_env_file(endpoint_info_dict) else: logging.info("No endpoint information to write to .env file.") logging.info("Main process completed.") if __name__ == "__main__": main() Explanation of the script Environment setup and logging Loading environment variables: The script starts by loading environment variables from a .env file, particularly the CHAINSTACK_API_KEY. Logging initialization: Logging is initialized for recording the script’s activities, errors, and informational messages, which is crucial for monitoring and debugging. Fetch data from the Chainstack API Function fetch_chainstack_data: This function makes a GET request to the Chainstack API using the provided API key. It retrieves information about the blockchain nodes on your account. Success handling: If successful, the function logs the number of items fetched and returns the data. Otherwise, it logs an error and returns None. Process Chainstack data Function process_chainstack_item: This function extracts important details like ID, name, and endpoint information from the Chainstack data. Test Web3 connection Function connect_to_web3: This function attempts to establish a connection to a Web3 endpoint. It logs a successful connection or warns if it fails, providing valuable feedback about each endpoint’s status. Note: Non-EVM endpoints or improperly formatted ones will not work and will show a warning. This is a point you can build on and improve. Sanitize data and create .env file Function sanitize_name: This function ensures that the names of the endpoints are formatted correctly to be used as environment variable keys in the .env file. Function create_env_file: This function writes the endpoint URLs into a .env file, making them easily accessible and usable in other parts of the project. This file serves as a central configuration point, enhancing the modularity and scalability of the system. Main execution flow Main function: The main function orchestrates the entire process: checking the API key, fetching and processing data, testing endpoints, and creating the .env file. It ensures each step is executed in sequence and handles the absence of data or API keys, making the script robust and user-friendly. Executing this script will efficiently process and validate your Chainstack endpoints. It identifies those endpoints that successfully return a chain ID, indicating their active and functional status. These validated endpoints are then neatly recorded into a .env file. With this setup, you gain a streamlined and organized method to access and utilize all your Chainstack endpoints. This approach simplifies endpoint management and enhances the overall efficiency of your interactions with Chainstack services. Note that non-EVM endpoints or improperly formatted ones will not work and will show a warning, which you can build on and improve. Authentication methods available on Chainstack Safeguarding data and asserting secure interactions is paramount. API authentication is essential in application programming interface (API) development, as it verifies the identities of applications or users utilizing the API. Chainstack prides itself on offering several secure API authentication methods that can fortify your DApps against unauthorized breaches, each with its advantages and considerations. Let’s briefly explore the five primary methods used for authentication first, keeping in mind only the first two are actively used on Chainstack. API keys API keys are the simplest form of API authentication. The client includes an API key, a unique identifier, in the header or as a parameter in the URL. The server matches the key to a corresponding key in its database and, if it matches, grants access. Although easy to implement, API keys can be misused if intercepted. On Chainstack, API keys are typically used with the platform API. Basic authentication Basic authentication involves sending a user ID and password with each API request. The credentials are Base-64 encoded but not encrypted, making them easily decipherable by anyone who intercepts the transmission. Basic authentication should always be used over HTTPS to add an additional layer of security. While basic authentication can be used for nodes, it won’t work with the Chainstack platform API, as API keys are used for that instead. Digest authentication Digest authentication is a step up from basic authentication, where the client sends a hashed (or digested) version of the password. It’s more secure than basic authentication because even if an attacker intercepts the hashed password, they cannot use it to make API requests. Digest authentication is not typically used on Chainstack. OAuth (Open Authorization) OAuth is a more complex but secure authentication method. It enables third-party applications to make requests on behalf of a user without needing their password. OAuth2, the latest version, uses short-lived access tokens rather than user credentials for authentication. OAuth authentication is not typically used on Chainstack. JWT (JSON Web Tokens) JWT is a token-based authentication that allows for stateless authentication. An encoded string of characters represents a payload of data, which often includes issued at time (iat), expiration time (exp), and not before (nbf) statements. JWT authentication is not typically used on our platform with the exception of some Chainstack Marketplace applications. Comparison table MethodSecurityComplexityAPI KeyLowLowBasic AuthenticationMedium (if used over HTTPS)LowDigest AuthenticationMediumMediumOAuthHighHighJWTHighMedium Choosing the right authentication method for your API depends on your specific use case, including your security needs and the resources available for implementation. Header authentication (bearer token) Header authentication with a bearer token is a common method employed in API requests. This approach involves attaching an authorization header with a bearer token in each HTTP request to the server. This token is a cryptic string, ensuring that data access is only granted to the token’s bearer, hence the name. In the context of the Chainstack platform, header authentication using a bearer token is fully supported for platform API requests. Users can authenticate their API calls on the platform by including the bearer token in their request headers. However, bearer token authentication is currently unavailable for blockchain APIs. Blockchain nodes typically do not provide traditional user-based authentication. Instead, Chainstack uses API keys or similar mechanisms to authenticate requests to hosted nodes, which are not traditional bearer tokens. Example of sending a header authenticated request to Chainstack API To learn how to generate your Chainstack API key, refer to the documentation. cURL example curl --request GET \\\\ --url <https://api.chainstack.com/v1/organization/> \\\\ --header 'accept: application/json' \\\\ --header 'authorization: Bearer YOUR_CHAINSTACK_API_KEY' This example calls the Get Organization Name and ID API, which returns the organization name and ID associated with the API key. Replace YOUR_CHAINSTACK_API_KEY with the API key from the Chainstack console. Example response { "id": "RG-123-456", "name": "Cool Organization" } Selecting the appropriate authentication method When choosing an authentication method, consider the following points: Use case and purpose: Identify the specific use case and the purpose of the API requests. Understanding the requirements will guide you in selecting the most suitable authentication method. Security and complexity: Evaluate the level of security and complexity required for your API requests. Basic authentication provides a straightforward approach, whereas API keys offer a secure way to manage different URLs and chains. Compatibility and flexibility: Determine the compatibility of the authentication method with your existing systems and the flexibility it provides for future expansion. Authenticating blockchain requests to a node Chainstack offers two sets of credentials to access a node: Access via auth token Password-protected access Access via auth token You can use the endpoint with an auth token found in your Chainstack console: HTTPS endpoint: https://ethereum-mainnet.core.chainstack.com/YOUR_AUTH_TOKEN WebSocket endpoint: wss://ethereum-mainnet.core.chainstack.com/ws/YOUR_AUTH_TOKEN Here’s how to retrieve the client version, one of the standard Ethereum JSON-RPC methods, using a POST request: curl -X POST --location '<https://ethereum-mainnet.core.chainstack.com/YOUR_AUTH_TOKEN>' \\\\ --header 'Content-Type: application/json' \\\\ --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' Password-protected access For blockchain API requests, you can also use basic authentication: HTTPS Endpoint: https://ethereum-mainnet.core.chainstack.com WSS Endpoint: wss://ethereum-mainnet.core.chainstack.com/ws Username: YOUR_USER_NAME Password: YOUR_PASSWORD You can find your username and password credentials in the Chainstack console. To include the username and password in your cURL command, use the following format: curl -X POST \\\\ -u YOUR_USER_NAME:YOUR_PASSWORD \\\\ -H "Content-Type: application/json" \\\\ --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' \\\\ <https://ethereum-mainnet.core.chainstack.com> In this command, -u YOUR_USER_NAME:YOUR_PASSWORD includes your username and password for basic authentication. Replace YOUR_USER_NAME and YOUR_PASSWORD with your actual credentials. Security reminder Keeping your API key and username/password secure is critical to prevent unauthorized access to your blockchain node. Further reading Expand your Ethereum DApp development skills with these comprehensive Chainstack resources: Ethereum DApp developer tools to help you every step of the way: Master Ethereum DApp development with this ultimate guide, covering essential tools and resources end-to-end. Web3 appchains, the future of DApps: Explore Web3 appchains, understanding how they enhance scalability, security, and user experience, shaping the next generation of DApps. Unmasking DApp endpoint security: Examine the research results from our study on DApp endpoint security, uncovering best practices and identifying common ecosystem issues. Bringing it all together Developing a DApp is an exciting journey, one that can bring challenges and rewards in equal measure. As Web3 developers, it’s crucial to have an in-depth understanding of your tools, and Chainstack is committed to helping you every step of the way. Over the course of this guide, we delved into the nuances of Layer 1 and Layer 2 network selection, the reliability of Chainstack Global Nodes, the importance of HTTP status code handling, and API authentication methods. But this is just the beginning. The ever-evolving landscape of DApp development frequently presents new strategies and challenges. Keeping your knowledge bank updated, and making the most out of robust platforms like Chainstack can ensure your DApps remain efficient, secure, and powerful. On behalf of Chainstack, we thank you for joining us on this enlightening journey into the essentials of DApp development. Together, let’s lead the charge in building a more decentralized world. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### DIA on Chainstack: Leveraging a robust oracle network for accurate and reliable data  The Decentralized Information Asset, or DIA for short, is a comprehensive open-source data and oracle multi-chain platform. DIA’s primary goal is to provide accurate and reliable feeds, needed for the effective operation of Web3 applications across protocols. What does DIA do? The DIA platform offers a comprehensive solution for sourcing, validating, and sharing transparent and verified data feeds for traditional and digital financial applications. With an extensive coverage of 6.000+ digital asset prices, 20k+ traditional assets, NFT floor data, metaverse data, and more, DIA’s institutional-grade data feeds are a valuable resource for any organization. DIA fetches a daily volume of 15bn trades directly and simultaneously from a palette of centralized and decentralized exchanges. data feeds simultaneously, This allows DIA to feed dApps with fully customizable data and oracle services, with tailor-made sources, filters and pricing methodologies. Because of this, the platform is able to foster an adequate environment for tailor-made and high-resilience feeds to thrive, ultimately setting a new paradigm for Web3 oracles. Up until now, DIA has managed to extend its solution to 25+ key blockchain networks, such as Ethereum, Fantom, Solana, Arbitrum, Polkadot, Kusama, BNB Smart Chain, Polygon, Avalanche, Celo, and others. In doing so, DIA successfully covers the entire data value chain from sourcing to delivery and thus ensures accurate and up-to-date data without reliance on third-party providers. How did DIA come across Chainstack? In order to be successful in its implementation, first and foremost DIA needed a reliable RPC provider that could facilitate the retrieval of trading data from 50+ DEX platforms across multiple blockchains. Considering the platform’s use case, however, this provider had to offer absolute stability in delivering large volumes of data with high, or no rate limits to make it all feasible for the team’s budget. After performing several trial runs with alternative infrastructure providers, DIA ultimately found none of them an adequate fit, due to various websocket endpoint and rate restrictions. This led the team to continue with the search until they discovered Chainstack as a potential solution for their RPC woes. Ultimately, the exceptional flexibility that Chainstack offered, in terms of both features and pricing, made it an easy choice for the DIA development team. Without any general rate limits imposed for using our services, the DIA platform saw in Chainstack an adequate and reliable RPC support for its demanding use case. How does Chainstack’s offer match DIA needs? Before making the ultimate choice, DIA laid out a set of three criteria for Chainstack to resolve. Above anything else, no rate limits could be imposed, because of the large volumes that came with the use case. With such limits being present, the platform could suffer unnecessary interruptions to its services, especially during peak traffic. Second, there could be no restrictions, when it came to websocket subscriptions. This was vital, considering the cross-chain support that DIA was looking to capitalize on. Having such boundaries would ultimately restrict the platform severely, as each data feed constitutes a new subscription. Last but certainly not least, websocket disconnect time needed to be unlimited just as well. Being an oracle implementation, an automatic reconnect, regardless of feed downtime was absolutely essential. Without it, the DIA development team would have to handle each manually, creating unnecessary labor and costs for the project. Outcome Chainstack ticked all the boxes when it came to the DIA’s decision-making criteria. The flexibility of our platform and pricing was certainly a welcome sight that offered solace for the development team in knowing it could fit their use case like a glove. By working together with Chainstack, DIA successfully secured the reliable infrastructure it needed to power its Web3 implementation. And keeping in mind just how critical RPC stability is for an oracle network, the DIA team found exactly what they were looking for to really make the mix complete. With performance issues no longer being present, the platform’s development team was able to free precious resources that could be put to better use. In turn, this created more opportunities to streamline the user experience and deliver the exceptional performance that makes an oracle network ultimately successful. What does DIA like about Chainstack? “We are thrilled to be working with Chainstack to scale DIA’s data and oracle infrastructure. By leveraging Chainstack’s decentralized node network, DIA will continue growing its end-to-end oracle services across multiple blockchains.” Samuel Brack, Chief Technical Officer, DIA. What does Chainstack like about DIA? “The “Oracle problem” is one of the most critical avenues for the effective long-term development of blockchain technology. That is why we see projects such as DIA as vital contributors to the entire Web3 landscape.” Eugene Aseev, Founder & CTO, Chainstack What is the most interesting engineering challenge in working together?Considering that stability was paramount for the DIA team, one of the most interesting challenges occurred during a websocket server disconnect. Should this have been left without attention, the platform would have seen a portion of its exchange scrapers disabled and thus suffer from deteriorating data feed quality. Fortunately for all, however, our support team quickly jumped in to work the issue out. Following a quick discussion, we collaborated with the DIA team in debugging the bottleneck and were ultimately able to pinpoint its root cause. By applying some minor tweaks and an update to the websocket server, our teams successfully resolved the matter in question. In doing so, we were both able to move to greener pastures and leave performance issues such as this, once again in the past, where they belong. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Distributed ledger technology for the enterprise: Paradox to promise By Laurent Dedenis What comes to mind when you hear the word ‘Enterprise’, or for that matter, ‘Organization’? Certainly not a vast collection of autonomous computers communicating and transacting among themselves. And certainly not computers that, despite the absence of a central authority, manage to get work done. Which is why Distributed Ledger Technology, or DLT for short, seems like a paradox when applied to the tightly-orchestrated and hierarchical world of business. In the enterprise world, a lack of hierarchy generally means anarchy, until now. Without going into the technical differences between DLT and Blockchain, let me just go ahead and claim that DLT and its variants (which includes blockchains) belong to a powerful way of getting things done in the real world and with many parties. Their impact extends not only to the free-for-all public version but also to the permissioned gates of the enterprise sector. Today there are hundreds of enterprises exploring DLT across a multitude of use cases. A recent McKinsey analysis went so far as to state that they have identified 90 discrete use cases at varying levels of maturity. This is a promising number for a technology that is viewed not only as disruptive but requires actively cooperating with one’s ecosystem. Why is it that Maersk and a whopping 94 other organizations have joined a blockchain trade platform? Why are drug giants Genentech and Pfizer collaborating and sharing movement of goods on a single distributed database? And why on earth would the Australian Stock Exchange decide to replace its tried-and-tested 25-year old clearing and settlements system with DLT? I could go on with similar examples of collaboration and adoption. Suffice to know, all this is happening, because the benefits of DLT to an enterprise are compelling. Let me cite a few. With DLT, enterprises and partners are discovering that they can realise operational efficiencies and collaborate better. For instance, by consolidating supply chain data on a permissioned decentralised database, manufacturers and their logistics partners can share in a single source of truth and avoid hundreds of hours of manual matching of product codes. In Insurance, data re-entry is a major cost across broker, provider, and consumer. Once again, a single source of truth does away with this bottleneck to a faster insurance claims processing. Last but not the least, through the power of smart contracts, businesses can move so much faster — imagine the automatic release of payments on receipt of shipment instead of another round of paperwork between client and vendor. The net effect is a significantly lower total cost of ownership (TCO). In Insurance, DLT is expected to save insurers close to 30%. And while TCO would vary across industries, it is expected to be significant. This is simply because a major component of costs in running enterprise systems and processes derive from supporting human capital. So DLT for the enterprise is not a paradox after all. If enterprises can take a hard look at processes across their ecosystem, cede centralization where required, and cooperate, then DLT can definitely deliver on its promise and more. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Distributed ledger technology network infrastructure remote management Chainstack stopped supporting Hyperledger Fabric and Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. As companies increasingly move their operations to the cloud, there have been significant changes in the way that the network and application architecture have been managed. With remote management capabilities, teams can access their hardware and the systems running on it from anywhere, without having to be available on-premises, or even tunnel through a VPN. Now, with the growing interest in distributed ledger technology (DLT), a new set of challenges arises. DLT is about network effects, where the value of the network increases as the number of members grows. However, the nature of these global networks means they are likely to be made up of many managed nodes running across heterogeneous infrastructure and spread over various countries, regions, or continents. Even just within a single organization. Moreover, as new projects continue appearing to address different use cases, from trade finance to supply chain, these nodes will potentially be hosting many different applications running on different protocols. This all begs the question: how can DevOps teams remotely deploy, monitor, manage, and scale this infrastructure and applications with the level of flexibility, security, and usability that they’ve come to expect when working with similar modern systems? Looking for solutions to complex problems These are the kinds of problems we’ve been working to solve at Chainstack, where we provide managed blockchain services to help reduce the friction in orchestrating complex blockchain infrastructure. We’ve been focused on the idea that teams should be able to effortlessly manage their infrastructure across any environment, completely remotely. To achieve this in a way that is scalable for us as well as our customers, the team has had to work on ensuring our suite of orchestration tools is applicable across any modern environment and accessible at any time. Tech teams should have the ability to deploy where they need, from multi-cloud networks to on-prem infrastructure, without delay and intervention. Furthermore, these teams should not have to deal with the complex questions of how to scale their architecture beyond just themselves, but to other network participants as well. All of this while monitoring their resources, scaling, healing where needed, and handling downtime. How to fix the status quo So how are people doing it today? What we’ve seen is an abundance of custom scripts and complex processes, all of which need updating for every protocol change and for different cloud providers. Teams are working with a variety of tools to manage everything—all plugged together to create custom deployment and monitoring packages that require knowledge of several different systems and processes to keep up and running. For this reason, Chainstack is now rapidly developing its platform to work with all the tools these teams already use on a daily basis. From integrating into CI/CD pipelines for application development and deployment, to securely accessing hardware security modules that manage keys, and deploying into existing cloud accounts across the globe. Monitoring is also a key component for any team tasked with managing infrastructure, particularly when that infrastructure is highly distributed. Our product team is currently working on taking our own internal monitoring tools and exposing them to every Chainstack user’s dashboard. This will ultimately provide a holistic view of the health and performance of resources regardless of which cloud environment they live in. Whether you are running a Quorum network for testing with a single node, or hundreds of nodes across multiple projects on R3 Corda and Hyperledger Fabric consortia. Bells and whistles aside, Chainstack’s customers are already discovering that they’ve been able to work with more flexibility, and with increased peace of mind in the knowledge that downtime and infrastructure complications are less of a concern. These issues are now being handled automatically without the need for intervention. Remote distributed ledger technology infrastructure management Ultimately, managed infrastructure is an evolving ecosystem. Technical teams are increasingly looking for how they can reduce the cost, time, and risk involved with operating global, highly available systems in a way that makes sense for them. For context, the value of the staff-hours required to manually manage such systems by a Cloud and DevOps team can quickly surpass $100,000/year. Now we can instead augment these teams’ capabilities with remote DLT management tools like Chainstack. These tools can reduce the time spent building, monitoring, and supporting custom solutions, all for the cost of a SaaS platform that’s 99% cheaper than doing it independently. Furthermore, as DLT networks grow out of the prototype stage, they start to onboard multiple participants, each with their own infrastructure setups and requirements. Chainstack has managed to enable these kinds of projects to scale almost effortlessly, where multiple parties can collaborate from anywhere, without ever having to trust each other or even meet in person. The process of deploying and managing DLT networks is already fraught with complexities, but with the market rapidly developing, we believe that these types of tools that simplify the process are essential to its sustained growth. It’s for this that we have been seeing the rise of managed blockchain services which, according to Gartner, will handle a significant portion of all DLT networks in the next 5-10 years. The market is now looking not only for support in running their infrastructure and application stack but for additional tools and services that supplement the core offering in providing the ability to remotely modify, monitor, and adjust their network resources. Wherever they may be in the world. Start building Get started managing a network of distributed nodes from anywhere. You can experience remote DLT management today by signing up at console.chainstack.com. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### dRPC provider overview (2026) In the Web3 world, your RPC provider is the unsung infrastructure hero that connects your frontend and smart contracts to the chain reliably. Whether you’re launching a dApp, managing a protocol, or building a node service, providers like dRPC enable you to choose how you deploy, while giving you access to global endpoints, AI-powered routing and transparent billing. dRPC offers: broad multichain support, flexible deployment, and a pricing model built around usage rather than locked-in bundles. dRPC Homepage Brief history of dRPC dRPC emerged to address common pain points: single-point-of-failure RPC providers, opaque cost models, and limited chain coverage. By building on an open routing library and a gateway layer, dRPC uses a network of independent node providers to deliver resilient and performant RPC access. Today, the platform claims support for 100+ chains and 190+ networks, serves billions of requests per day, and partners with major dApps and chains to power their public RPC infrastructure. Core dRPC products & services dRPC offers several tiers tailored to different types of teams and use cases: NodeCloud: Ideal for teams that want instant access and minimal infrastructure overhead. Developers can connect to multichain endpoints in the cloud with no node-maintenance required. NodeCore: For teams that prefer to self-host and control their own stack. Open-source stack, supports custom routing, observability, and integrates with your existing infrastructure. NodeHaus: Tailored for blockchain foundations or large-scale RPC infrastructure. Includes managed public commercial nodes, observability dashboards, branded testnet faucet, 24/7 support, global clusters, etc. dRPC infrastructure stack Together, these offerings let you choose how much infrastructure you own vs outsource, while still getting access to the global routing and provider network that dRPC has built. Performance & pricing profile Performance: The routing engine uses Dproxy at the gateway and instances of Dshackle at each provider node. When a request comes in, dRPC selects the best node based on region, node health, chain head height, method used and other characteristics. The infrastructure covers many continents via multiple geo-clusters. Pricing: dRPC uses a pay-as-you-go pricing model based on Compute Units rather than simple request counts. Different RPC methods consume different amounts of compute, so the actual cost depends on your method mix and traffic patterns. dRPC – Compute Unit Pricing This model can be flexible for small or unpredictable workloads, but it also means costs can scale quickly if your application relies heavily on logs, traces, or complex calls. To better understand how this works in practice, the example below shows how a typical workload translates into Compute Units and monthly cost compared to request-based pricing. MetricChainstackdRPCPlan used in exampleProGrowthIncluded usage80M Request UnitsPay-as-you-go (no bundled requests)Workload equivalent73.5M method calls73.5M method callsCompute usage (example workload)Fits in included usage~1.4B Compute UnitsPlan price$199$0Overage charges$0$420Total monthly cost$199$420 See the full cost comparison → Strengths vs potential weaknesses StrengthsPotential WeaknessesBroad chain and network coverage Performance and latency may vary by region or network depending on the provider node your request lands on Modular deployment options: cloud and self-hostUsage-based billing means you must monitor usage carefully to avoid surprises Transparent pay-as-you-go pricing, free tier available For ultra high-scale or specialised compliance setups, you may enter bespoke enterprise terms Smart routing & decentralized provider network for better resilience Because infrastructure is distributed across many independent nodes/providers, consistency may depend on each provider’s performance  dRPC vs Chainstack Both providers aim to deliver high-performance multichain RPC infrastructure, but there are meaningful differences worth noting: dRPC stands out for its broad chain support, flexible deployment options, and usage-based pricing. If your project spans many networks or you’re comfortable with monitoring usage and optimizing method calls, this model can provide more flexibility and potentially lower costs for certain workloads. Chainstack emphasizes cost predictability, enterprise SLA (99.99%+ uptime), and flat-fee / transparent pricing models. This makes it easier to forecast infrastructure costs and operate production workloads without worrying about method-level billing or sudden usage spikes. From an operational perspective, teams that prefer predictable monthly infrastructure costs and simpler cost modeling often lean toward request-based pricing, while teams that want maximum flexibility across many networks may prefer usage-based models. Ultimately, the right choice depends on whether your priority is flexibility across many networks and deployments, or predictable infrastructure costs and operational simplicity. Try Chainstack with predictable RPC pricing → FAQ How do I get started with dRPC? Sign up, select the appropriate product, generate an API key, and point your RPC call to the endpoint provided for your chain. What kinds of chains does dRPC support? dRPC supports a wide range: 100+ chains and 190+ networks across both EVM and non-EVM ecosystems. Is dRPC secure and reliable enough for production dApps? Yes. While uptime and latency will depend on the plan and region, the design is production-grade. How predictable is the cost with dRPC? While it uses pay-as-you­-go rather than fixed pricing, usage is transparent. You’ll still want to monitor method mix and request volume to avoid surprises. #### Easy access to Bitcoin network with Chainstack TL;DR: We are happy to welcome Bitcoin as the latest addition to Chainstack’s multi-protocol line-up. Developers can now make unlimited requests to free gateways to the Bitcoin network via shared Chainstack nodes. Applications looking for a large-scale performance can instantly deploy their own dedicated nodes through Chainstack in their cloud and region of choice, and make high-volume, high-velocity requests to the nodes. All while managing and monitoring infrastructure through an intuitive interface. Forget about infrastructure We believe that application developers need not worry about the infrastructure that their platforms are built on. If what you are building needs to read from and write to the Bitcoin network, you shouldn’t have to think about the layer that provides this access. Chainstack ensures maximum uptime of your nodes and handles all the maintenance needs so you can spend more time building. Our efforts have been spent crafting a platform that abstracts away the complications of infrastructure management. Our customers—who have been deploying blockchain infrastructure with us since launch—love the Chainstack interface. We want to continue this trend with our support for Bitcoin nodes, performing complex orchestration under the hood so you don’t need to think about it. Something for everyone We know every application developer operates on a different scale and has different needs. That’s why we choose to offer the option of both shared and dedicated nodes. Shared nodes are completely free to run on Chainstack, providing private, protected endpoints that you can access and make unlimited requests to. We aim to maintain a degree of decentralization in the network by distributing these nodes across cloud providers and regions, passing the final choice to our users. If you require the scale and performance that comes with a node running entirely for your own use, you can deploy dedicated nodes through Chainstack into your cloud and region of choice. This means you can spin up as many full Bitcoin nodes as you need, when you need them, wherever you need them.  Painless synchronization Our experience working with Ethereum introduced us to the frustrations of node synchronization. The time taken to sync the full ledger can easily take several days to a week. This encouraged us to build a snapshotting and synchronization tool to deploy >300GB dedicated Ethereum nodes for our customers in minutes. These nodes are just a few blocks out of sync when they start up and catch up with the tip of the chain very quickly. This technology, which we’ve named Bolt, has also been applied to our new Bitcoin nodes. With Bolt, we can sync a full Bitcoin node in significantly less time, removing the pain that often comes with synchronization issues and waiting times.    What’s next? This methodology that we’ve applied to solve synchronization issues in Ethereum, and now Bitcoin, permeates what we do at Chainstack. We hope to discover many more frustrations that people have with connecting to and interacting with blockchain networks so that we can continue creating solutions to alleviate that pain. And you can continue doing your thing—building applications for the trustless networks of the future. Try it out today. You can sign up for a free Developer plan at console.chainstack.com or learn more on our docs site. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Enterprise blockchains in the United States: Emerging and established projects Photo by Ferdinand Stöhr on Unsplash Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. As blockchain technology matures, protocol iterations continue to evolve in response to a growing community. Although distributed ledger technology first emerged as public infrastructure, several of its founding principles fail to meet enterprise requirements. The transparent nature of public blockchains, in particular, poses significant challenges to corporate adoption. So too does the use of native cryptocurrency, for which many companies have no use. As a result, enterprise blockchains have begun to emerge as a solution to these hurdles. These networks retain the immutable, decentralized nature of public blockchains but are permissioned and crypto-free. Further, as private networks, enterprise blockchains lack the typical consensus mechanisms used to secure trustless public solutions. As enterprise iterations continue to gain traction, no less than 14 protocols have emerged catering to diverse use cases across market sectors.   Source: The Block Crypto However, not all countries are adopting enterprise solutions at the same rate. While the US appears to match or exceed the adoption rates seen in several Asian countries, others like South Korea forge ahead. A recent surveyconducted by Deloitte also found that “only 14% of US respondents said blockchain was already in production in their organization, compared to nearly 50% in some other countries, including China and Mexico.”   Source: Deloitte 2018 Global Blockchain Survey Further to this, the same report found that “US respondents lagged well behind those in other countries in investing in new staff that possesses blockchain knowledge and expertise.”   Source: Deloitte 2018 Global Blockchain Survey While the reasoning for these findings is uncertain, specific industry trends may be contributing to slower adoption in the US. Competition concerns In the case of financial services, rivals may be resistant to using Quorum, an open-source distributed ledger, due to its close association with JPMorgan. As a result, JPMorgan plans to spinoff Quorum into its own company in hopes of garnering greater adoption. IBM and Maersk find themselves in a similar situation with their blockchain solution TradeLens. Initially created to act as a network between shippers, rivals are leery to join a team their rival owns. Regulatory environment According to The Columbia Science and Technology Law Review, “the U.S. federal government has not exercised its constitutional preemptive power to regulate blockchain to the exclusion of states.” This means that states are free to introduce their own rules and regulations pertaining to blockchain technology. Understandably, this could be contributing to the disjointed response to blockchain adoption initiatives, especially for corporations. However, as is the case in Wyoming, this state-reliant response can also be seen as a catalyst for future growth. Just recently, the state introduced 13 new laws that provide a comprehensive, welcoming legal framework for the blockchain industry. And although this is only one state, other progressive states may be inclined to follow suit now that there’s a path to follow.   Source: Blockchain and U.S. state governments: An initial assessment Considering the insights discussed, it’s not surprising that there are currently few projects delivering real-world results today. However, there are several companies piloting blockchain projects, suggesting the US may not be as far behind as perceived. Emerging enterprise projects UPS: Supply chain management Earlier this year, UPS made an investment in US-based Inxeption. While details of the deal remain limited, Inxeption aims to use blockchain technology to enhance the efficiency of business processes including manufacturing and supply chain management. The UPS Strategic Enterprise Fund is said to be working with Inxeption to develop new features on the Inxeption platform. The goal is to provide greater transparency on the supply chain while also protection customers proprietary information. Verizon: Security of digital information Last year this telecom giant announced it would deploy a blockchain platform based on Guardtime technology. Verizon Enterprise Solutions will offer a portfolio of blockchain based services that governments and enterprises can use to integrate blockchain with their existing business processes. BNSF: Freight transportation BNSF is one of North America’s leading freight transportation companies, operating in 28 US states and 3 Canadian provinces. In early 2018, BNSF joined the Blockchain in Transport Alliance (BiTA) with the shared mandate to develop industry standards for blockchain implementation. The company is one of Berkshire’s largest business units, generating $23.9 billion in 2018. Established enterprise projects While there are several companies that have begun the process of developing decentralized solutions, few have yet to produce tangible results. However, a few early adopters have begun to show us the immense value of enterprise protocols. Walmart: Tracing the supply chain In September of last year, Walmart concluded a two-year pilot project that tracked 25 food products using Hyperledger. The company has since announced that it will expand its platform to track all spinach and lettuceproducts by the end of 2019. As part of the IBM Food Trust, Walmart will require all of its supplying farmers to submit data to the network. This will allow the company to track the origin of these products, facilitating a more efficient response to contamination scares. FedEx: Critical cargo shipments For FedEx, the immutable nature of blockchain technology was the main driver of its implementation. In an increasingly global economy, there are several benefits to transparently tracing the flow of shipments. While only cargo shipments are currently tacked using blockchain, the company intends to expand its use. As a member of the BiTA, these efforts will coincide with developing industry standards alongside other progressive companies like Chainstack. Change healthcare: Claims clearinghouse Source: Change Healthcare Unveils Enterprise Blockchain to Boost Revenue Cycle Efficiency Change Healthcare is using enterprise protocol to link healthcare professionals across the US. Its blockchain solution coined “The Intelligent Healthcare Network” currently processes up to 50 million transactions per day. While the company offers several services, its claims clearinghouse is the current focus of its decentralized efforts. The company is working with AWS, Hyperledger Fabric, and TIBCO to deliver a solution that reduces the administrative complexity of the claims process. The future of enterprise blockchain in the US Although US adoption lags in comparison to other nations, several indicators point to accelerating industry innovation. The vast array of pilot projects alone points to a growing awareness amongst progressive corporations. Established projects, while in their infancy, have also begun to leverage the immense value inherent of distributed ledger technology. But more needs to be done to drive the enterprise movement forward. Despite numerous protocols catering to specific use-cases, ease of use and implementation remain significant hurdles to adoption. If those offering enterprise solutions can further simplify the implementation process, accelerated adoption is almost certain. But the question remains, what will the next generation of enterprise offerings look like? While one can hypothesize, platforms like Chainstack are already offering us a glimpse into the future. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Enterprise RPC infrastructure: nodes, SLA, and compliance TL;DR: Most enterprise blockchain projects fail at the infrastructure layer, not the smart contract layer. The gap between “it works in staging” and “it holds under production load with contractual guarantees and a compliance audit trail” is not a configuration problem — it is a vendor selection problem. This guide covers what enterprise RPC infrastructure actually means, why Ethereum remains the primary enterprise chain, and what the compliance checklist looks like before procurement. The wrong question enterprises ask about blockchain infrastructure The standard enterprise procurement question is: “What’s your uptime?” It is the wrong question — and it is how organizations end up in production on shared endpoints that technically meet the 99.9% uptime number while being completely unfit for institutional use. Shared infrastructure means your traffic competes with every other tenant on the same nodes. A burst from a high-volume dApp on the same cluster degrades your response times. You have no SLA with financial penalties, no dedicated support channel, no audit logs for your own requests, and no contractual basis to escalate when latency spikes at 2am before a settlement window. The right question is: “What happens to my organization when this endpoint fails, and what does the provider owe us when it does?” That question — not uptime percentages — is what separates enterprise blockchain RPC infrastructure from developer-tier shared endpoints. The JSON-RPC protocol is identical across vendors. The operational guarantees, isolation model, and compliance posture wrapped around it are not. Shared vs dedicated: the architectural split that matters Standard RPC providers, including the free tiers of every major vendor, operate shared infrastructure. Your application sends requests to a pool of nodes serving hundreds or thousands of other users simultaneously. This is economical and fine for development. It is unsuitable for production systems where SLA obligations exist, where sensitive data moves, or where regulators expect documented controls. Dedicated Nodes operate on physically or logically isolated compute. Your traffic goes to nodes reserved for your organization. This changes several things at once: DimensionShared RPCDedicated NodePerformance isolationNo — shared with all tenantsYes — resources reserved for youNoisy neighbor riskPresentEliminatedRate limitsPlatform-wide capsNegotiated per-deploymentCustom configurationNot availableNode client version, flags, cache settingsAudit log accessNot availableFull request/response loggingUptime SLABest-effort or softContractual, with penalty clausesCompliance artifactsNot availableAvailable on requestSupport tierTicket queueNamed technical contact For an enterprise deploying, say, a stablecoin payment system or a tokenized asset custody flow, the shared model introduces risk that cannot be mitigated by application-level retry logic alone. Retries work when failures are brief and transactional. They do not work when the underlying infrastructure is rate-limiting your tenant because another tenant spiked — and your operations team needs to explain to the compliance function why transaction confirmations were delayed. Ethereum as the primary enterprise chain Ethereum is not the fastest chain. It is not the cheapest chain. It is, however, the enterprise chain — and this is unlikely to change in the medium term. The reasons are structural rather than technical. Enterprise procurement favors auditability. Ethereum has the longest continuous mainnet history of any programmable blockchain, the deepest developer toolset, and the broadest institutional familiarity. Legal and compliance teams increasingly know what “Ethereum mainnet” means. They do not yet have equivalent frameworks for most alternatives. Beyond familiarity, Ethereum’s EVM has become the canonical smart contract execution standard. L2 networks — Arbitrum, Optimism, Base, Polygon — all expose EVM-compatible RPC interfaces. An enterprise that standardizes on Ethereum RPC infrastructure can extend that investment across most of the L2 ecosystem without retraining engineers or rewriting integration libraries. Practically, this means: Custodians, prime brokers, and institutional trading venues hold ETH and ERC-20 assets as primary inventory MiCA-regulated entities in the EU operate primarily on EVM chains for regulatory traceability Enterprise tokenization projects — real estate, bonds, trade finance — predominantly deploy on Ethereum mainnet or permissioned EVM chains SWIFT’s 2023–2024 interoperability experiments and Euroclear’s tokenized asset pilots have both targeted Ethereum or EVM-compatible environments as the settlement layer RPC infrastructure that treats Ethereum as the primary chain and extends to Solana, BNB Chain, or others as secondaries maps cleanly onto the actual portfolio of an enterprise blockchain operation. What an enterprise SLA actually contains An SLA document that just states “99.9% uptime” is close to meaningless in practice. Enterprise infrastructure contracts should specify: Uptime definition. Is downtime measured per endpoint, per region, or globally? Does partial degradation count? A provider with three regional clusters can claim 99.9% global uptime while one region is completely unavailable — unacceptable if your users are concentrated there. Penalty structure. Without financial penalties or service credits tied to specific SLA breach thresholds, the uptime number is a marketing claim. Credible enterprise SLAs include tiered credit schedules: for example, 10% monthly credit for availability between 99.5–99.9%, 25% credit below 99.5%, and contract termination rights below 99.0%. Latency guarantees. Availability alone does not cover performance degradation. p95 and p99 latency targets — not just averages — should appear in the contract. An endpoint that responds in 30ms 95% of the time but 800ms 5% of the time will fail latency-sensitive applications. Support response times. Shared-tier support means tickets processed in business hours. Enterprise SLAs should specify response time by severity: P1 (production outage) in under one hour, 24/7; P2 (degraded performance) in under four hours; P3 (non-urgent) in one business day. Incident communication. Enterprise operations teams need structured incident notifications — not just a status page — with estimated resolution times and post-incident root cause reports within 48 hours. Data residency and processing terms. For deployments subject to GDPR, data localization requirements, or sector-specific regulations (banking, healthcare, public sector), the contract must specify where request data is processed and stored, for how long, and under what deletion schedule. SOC 2 and ISO 27001: the compliance floor When an enterprise security team evaluates a blockchain infrastructure vendor, SOC 2 Type II and ISO 27001 certification are the baseline. Not differentiators — the floor below which a vendor does not make it to the shortlist. As crypto regulation tightens in 2026 under frameworks like MiCA and the GENIUS Act, this bar is rising, not softening. SOC 2 Type II and ISO 27001 covers the operational controls around security, availability, processing integrity, confidentiality, and privacy over a sustained audit period — typically six to twelve months. The “Type II” distinction matters: Type I is a point-in-time snapshot of whether controls exist. Type II demonstrates those controls were consistently applied over time. A vendor with only Type I certification has not yet proven their processes hold under real operating conditions. ISO 27001 is the international standard for information security management systems. Where SOC 2 is primarily US-focused and trusted by US enterprises, ISO 27001 is the equivalent recognized by European and Asian institutions. The two frameworks are complementary by design: ISO 27001 establishes the governance blueprint — the policies, risk management processes, and controls that define how an organization protects its information assets. SOC 2 Type II and ISO 27001 then provides the audited evidence that those controls actually work under real operating conditions, not just on paper. For multi-jurisdictional deployments, both certifications together cover the procurement requirements of most regulated industries. For blockchain node infrastructure specifically, these certifications map onto controls that go well beyond typical SaaS requirements: Validator key protection — hardware security modules (HSMs) handle cryptographic operations directly, preventing private key material from ever being exposed in software memory Change management for protocol client updates — updates to Geth, Erigon, or Reth carry real consensus risk; a faulty update can drop a node off the network entirely. Formal change processes with multi-signature approval and isolated test environments create the auditable trail SOC 2 auditors need Availability architecture — geo-distributed clusters with automated self-healing remove the single points of failure that would otherwise make continuous consensus participation impossible Double-signing prevention — real-time consensus monitoring detects duplicate key activity across forks and shuts down secondary nodes before a slashing event can occur RPC-layer attack mitigation — rate limiting, Layer-7 traffic scrubbing, and Tier 3 data center infrastructure protect endpoints against mempool-clogging and exploit attempts Data encryption — TLS in transit, AES-256 at rest across all RPC history and blockchain data For a detailed breakdown of how these controls apply specifically to node infrastructure, see the SOC 2 Type II and ISO 27001 for blockchain infrastructure guide. Chainstack holds SOC 2 Type II certification, with ISO 27001 underway as of Q2 2026 — making it one of the few RPC infrastructure providers that can hand a compliance team an audit-backed answer on the first ask. For the enterprise checklist, the compliance artifacts to request from any RPC provider include: Current SOC 2 Type II and ISO 27001 report (not older than 12 months) ISO 27001 certificate with scope statement (or in-progress roadmap with expected certification date) Penetration test summary (last 12 months) Business continuity and disaster recovery plan summary Subprocessor list Data processing agreement (DPA) template The enterprise blockchain RPC checklist Before signing with any blockchain RPC infrastructure provider, procurement and engineering teams should verify each of the following: Infrastructure Dedicated node option available (not just shared pool access) Node client version selection and configuration control Archive node access for historical state queries Multi-region deployment with documented failover behavior Private networking option (VPC peering, private endpoints) to avoid public internet transit SLA and operations Written SLA with explicit uptime definition and measurement methodology Financial penalties or service credits for SLA breach p95/p99 latency targets in addition to availability 24/7 P1 support with named escalation path Post-incident root cause analysis within 48 hours Status page with historical incident data Compliance SOC 2 Type II and ISO 27001 report available under NDA ISO 27001 certification with current certificate DPA available for GDPR or equivalent compliance Data residency options documented (EU, US, APAC) Audit log access for your own request history Commercial Custom contracts with negotiated terms (not just click-through ToS) Invoicing in a format compatible with enterprise finance systems Multi-year pricing stability clauses Defined offboarding and data export procedures Chainstack enterprise infrastructure: what the deployment looks like Chainstack’s enterprise offering combines Dedicated Nodes with the compliance posture, commercial flexibility, and support model that enterprise procurement requires. At the infrastructure layer, Dedicated Nodes provide fully managed node operation with complete resource isolation. Engineering teams choose the chain, node client, configuration parameters, and deployment region. Chainstack handles node health, software updates, and failover — without the enterprise team needing to maintain the underlying infrastructure themselves. The node product stack for enterprise deployments typically combines: Dedicated Nodes for production workloads requiring isolation and guaranteed resources Global Nodes for geo-distributed read traffic where latency optimization across regions matters Archive Data for historical state queries — common in compliance reporting, analytics, and reconciliation workflows For Ethereum specifically, archive node access is non-negotiable for most enterprise use cases. State queries against contract interactions from six months ago require full archive history. On a full (pruned) node, those calls return errors. Chainstack’s archive node coverage extends to all major EVM chains. At the commercial layer, Chainstack enterprise clients operate under custom contracts rather than standard click-through terms. This includes negotiated SLAs, DPA execution, invoicing that integrates with AP workflows, and access to the SOC 2 Type II and ISO 27001 report under NDA. Support at enterprise tier means a named technical contact, not a ticket queue. Escalation paths go directly to infrastructure engineers who know the customer deployment. This is relevant during incidents — when a trading platform’s node starts returning unexpected responses at market open, the difference between “submit a ticket and wait” and “call the engineer who deployed your node” is measurable in revenue. Conclusion The article opened with a claim: enterprise RPC infrastructure is a different product category, not a harder version of developer tooling. The procurement checklist above is what makes that claim concrete. Every item on it — dedicated resource isolation, financial penalty clauses, p99 latency targets, SOC 2 Type II and ISO 27001, DPA execution, named technical contact — exists to address a category of risk that a shared endpoint simply cannot mitigate. Retries do not fix a tenant spike. Application logic does not produce a compliance audit trail. And a status page is not a contract. Ethereum holds the primary enterprise position not because of performance benchmarks, but because the institutional framework built around it — custody support, regulatory familiarity, MiCA applicability, EVM-standard L2 extension — reduces procurement risk for deploying organizations. Infrastructure investment in Ethereum-compatible RPC compounds across the L2 ecosystem in a way that investment in chain-specific alternatives does not. If your organization is working through the vendor checklist above, start with Chainstack Enterprise — custom contracts, SOC 2 Type II and ISO 27001 report available under NDA, Dedicated Nodes with full resource isolation, and a named technical contact from day one. Get started → FAQ What is enterprise-grade blockchain RPC infrastructure? Enterprise-grade RPC infrastructure provides dedicated (not shared) node resources, contractual SLA guarantees with financial penalties, compliance certifications like SOC 2 Type II and ISO 27001, audit log access, and support escalation paths appropriate for production operations. It is distinct from developer-tier shared endpoints, which offer none of these. Why does dedicated vs shared node infrastructure matter for enterprises? Shared infrastructure means your application competes for resources with other tenants. Under load from other users on the same cluster, your latency increases and rate limits may trigger — outside your control. Dedicated infrastructure eliminates this variability. Your resources are reserved, your traffic is isolated, and your performance characteristics are predictable under your own load patterns. What SLA metrics should enterprise procurement require? At minimum: uptime measured per region with a precise definition, p95 and p99 latency targets (not just averages), financial penalty or service credit schedules tied to breach thresholds, P1 support response time of one hour or less with 24/7 coverage, and post-incident root cause reports within 48 hours. Is SOC 2 Type II sufficient for enterprise compliance, or is ISO 27001 also required? It depends on jurisdiction and sector. SOC 2 Type II and ISO 27001 is the standard expected by US enterprises and is recognized internationally. ISO 27001 is required or strongly preferred by European institutions, financial regulators in many APAC jurisdictions, and public sector organizations globally. For multi-jurisdictional deployments, both certifications together cover the procurement requirements of most regulated industries. Chainstack holds SOC 2 Type II and ISO 27001 certification. Why is Ethereum the primary enterprise blockchain? Institutional familiarity, the longest continuous mainnet history of any programmable chain, the deepest tooling ecosystem, and growing regulatory clarity — particularly in the EU under MiCA — make Ethereum the default for enterprise tokenization, custody, and settlement applications. Its EVM standard also extends to the major L2 networks, meaning infrastructure investment on Ethereum transfers to Arbitrum, Optimism, Base, and others without vendor changes. What is the difference between a full node and an archive node for enterprise use? A full node maintains current blockchain state — sufficient for reading live balances, submitting transactions, and querying recent events. An archive node retains all historical state from genesis. Enterprise use cases requiring historical queries — compliance reporting, reconciliation, audit trail reconstruction — require archive access. Calls to archived state against a full node return errors. For most enterprise deployments, archive node access is a requirement, not a premium option. Does Chainstack offer private networking for enterprise node deployments? Enterprise deployments on Dedicated Nodes can be configured with private networking options to avoid public internet transit for sensitive workloads. Contact the Chainstack enterprise team via the enterprise page to discuss deployment architecture requirements. What does enterprise support look like compared to standard tiers? Standard tier support is a ticket queue with business-hours response. Enterprise support means a named technical contact, priority escalation to the infrastructure engineers who manage your deployment, and 24/7 coverage for P1 production incidents. For organizations with SLA obligations to their own users, the support model of the infrastructure vendor directly affects what they can commit to downstream Additional resources Chainstack Enterprise Dedicated Nodes SOC 2 Type II and ISO 27001 certification SOC 2 Type II and ISO 27001 for blockchain infrastructure How regulation is reshaping crypto infrastructure in 2026 Global Nodes Enterprise Solana infrastructure: What matters in 2026 Chainstack pricing #### Enterprise Solana infrastructure: What matters in 2026 Introduction: TPS vs RPC Performance in Enterprise Solana When enterprise teams evaluate Solana, they often focus on headline metrics like theoretical throughput. But applications never interact with network TPS directly. What actually defines production performance is how reliably RPC infrastructure delivers Solana data to applications under real-world load. This distinction matters in 2026. Solana consistently produces blocks every ~400 milliseconds, yet many production systems still experience hundreds of milliseconds—or more—of RPC latency under peak conditions. For payment systems, trading platforms, and compliance-heavy deployments, these delays directly impact user experience, settlement times, and operational reliability. This article explains what enterprise-grade Solana infrastructure really means today, why network throughput alone says little about application performance, and which RPC characteristics determine whether a Solana deployment succeeds in production. Part 1: Why enterprise Solana infrastructure is not about TPS Enterprises evaluating Solana often anchor on headline metrics: 400 ms block times and thousands of transactions per second. But applications never interact with network throughput directly. What defines real production performance is how quickly and reliably RPC infrastructure delivers that data to applications. Solana can sustain 1,500–4,000 TPS and produce blocks every ~400 milliseconds, yet many production systems still experience 500 ms to 2+ seconds of RPC latency during peak load. The blockchain performs as expected — the bottleneck appears at the infrastructure layer. Network TPS measures how many transactions validators can process across the distributed network. RPC latency measures how fast your application can read and write that data through an API endpoint. These are entirely separate performance characteristics, and confusing them leads to broken production assumptions. Consider a payment processor handling 10,000–50,000 USDC transfers per day. Throughput requirements are modest, but each payment flow requires multiple RPC calls: balance checks, transaction submission, confirmation tracking, and state updates. If each call takes 500 ms instead of 50 ms, end-to-end settlement time quickly exceeds user and SLA expectations — despite Solana confirming transactions almost instantly. The same issue appears in real-time dashboards. Portfolio and trading interfaces rely on continuous RPC queries for balances and program state. When RPC latency spikes, users see stale data and make decisions on outdated information. Solana’s block time remains unchanged, but application experience degrades. In enterprise deployments, RPC latency — not network TPS — determines whether Solana feels fast or unusable in production. What to evaluate in enterprise Solana infrastructure First, demand p95 latency guarantees, not average latency. A provider claiming “average 50ms latency” might deliver 20ms most of the time but spike to 300ms for five percent of requests. That five percent represents every twentieth user experiencing degraded interface performance. Second, geographic distribution matters enormously for global applications. An RPC endpoint in US-East might serve New York with 20ms latency but deliver 200ms to Singapore. Production infrastructure requires regional endpoints in North America, Europe, and Asia-Pacific with automatic traffic routing. Third, understand the difference between public and production RPC endpoints. Solana’s public RPC endpoints implement rate limiting at 40 requests per 10 seconds, and official documentation explicitly states these endpoints are “not intended for production applications.” Applications attempting to run production workloads against public endpoints will hit rate limits immediately and experience unpredictable throttling. Part 2: Predictable performance in enterprise Solana infrastructure Enterprise systems value consistency over peak benchmarks. An RPC endpoint delivering 50 ms latency 99.99% of the time is more valuable than one that occasionally hits 20 ms but frequently degrades to 500 ms under load. Unfortunately, many RPC providers optimize for best-case benchmarks rather than worst-case production behavior. In real-world conditions, infrastructure stress rarely comes from your own application. During high-traffic events—such as major NFT mints or ecosystem launches—shared RPC infrastructure often experiences elevated latency and slot lag, even while the Solana network itself continues producing blocks every ~400 milliseconds. Applications fail not because Solana slows down, but because shared infrastructure becomes saturated. This is the classic noisy-neighbor problem. On shared RPC nodes, your requests compete with other customers’ workloads for CPU, memory, and network bandwidth. Expensive queries—such as large getProgramAccounts scans—can temporarily degrade performance for every tenant on the same node. From an application perspective, this manifests as sudden latency spikes, timeouts, or intermittent 429 errors. Unpredictability is compounded by hidden quotas. Providers frequently advertise “unlimited requests,” yet enforce undocumented throttles that surface only under real traffic. Capacity planning becomes impossible when limits are discovered reactively in production rather than defined contractually in advance. For enterprise deployments, predictable performance requires eliminating shared contention entirely. Dedicated infrastructure, explicit RPS guarantees, and SLA-backed latency targets are not optimizations—they are prerequisites for running Solana applications in production at scale. Core requirements for enterprise Solana infrastructure Dedicated nodesExclusive infrastructure with no shared tenancy to eliminate noisy-neighbor effects and guarantee predictable performance under load.Guaranteed RPS tiers with SLA backingClearly defined RPS tiers and latency targets with contractual SLAs and financial penalties for violations—not “best-effort” commitments.99.99% uptimeAvailability guarantees limiting downtime to minutes per month, documented and backed by financially meaningful SLAs.Transparent pricingComplete Solana history from genesis with low-latency queries for compliance, audits, and long-range analytics—without artificial retention limits. Part 3: Real-Time and Historical Data Together Enterprise applications require two data workloads simultaneously: low-latency access to current state and fast queries over long-term history. Most RPC architectures are optimized for one—but not both. Real-time access powers user-facing systems. Payment flows, dashboards, and trading interfaces depend on immediate balance checks and confirmation tracking. With Solana producing blocks every ~400 ms, these workloads demand consistently low RPC latency to avoid stale data and broken UX. Historical access supports compliance and analytics. Audits and reporting often require reconstructing account activity months or years in the past. With tens of billions of transactions processed annually, historical query performance has become a core infrastructure requirement—not a niche feature. The architectural tension is clear. Real-time RPC nodes prune historical data aggressively, often retaining only ~30 days. Archive nodes store full history but typically serve older data much more slowly due to storage constraints. For enterprise systems, switching infrastructure modes depending on the task is not viable. Production-grade Solana infrastructure must deliver low-latency real-time access while supporting fast, reliable queries across the full blockchain history—from genesis onward—without performance trade-offs. What enterprise Solana deployments require Archive nodes should maintain sub-200 millisecond query times even when accessing historical data from early blocks. This requires significant engineering investment in storage architecture, caching strategies, and query optimization. Block history retention from genesis forward represents table-stakes for compliance-heavy industries. Financial services regulations frequently mandate seven-year data retention. When evaluating Solana infrastructure, verify that providers can serve data from any point in the blockchain’s history—from March 2020 genesis forward—without gaps. Efficient getProgramAccounts queries on historical state are essential for reconstructing portfolio holdings at specific points in time or generating historical reports. Well-engineered archive nodes use indexing strategies and caching to make these queries practical. Consider the stablecoin issuer use case. Solana now hosts over $15 billion in stablecoin supply. Major institutions like Visa settle billions in payment volume on Solana. During normal operations, issuers need real-time balance checks to process transfers instantly. But when regulators request an audit, those same systems must reconstruct every transaction for the past six months or longer. If infrastructure can only serve real-time data efficiently, the audit process becomes manually intensive. If it only serves historical data slowly, normal operations suffer. The only acceptable solution is infrastructure that excels at both simultaneously. Part 4: Security and isolation in Solana enterprise Shared infrastructure represents unacceptable security and compliance risk for most enterprise deployments. The surface area for attack and lack of meaningful access controls in shared RPC environments create numerous vulnerabilities that become critical when handling institutional-scale value flows. Public RPC endpoints expose several critical risks. First, they provide no IP allowlisting capability. Your production payment system shares the same API endpoint anyone on the internet can access. Solana’s public RPC endpoints document rate limits of 40 requests per 10 seconds explicitly because they must protect against arbitrary internet traffic. There’s no way to ensure only your infrastructure can reach the RPC node. From a security architecture perspective, this is equivalent to running a database with no firewall rules. Second, public endpoints create enormous attack surfaces for denial of service. Because anyone can reach the endpoint, attackers can flood it with traffic. Even if the provider implements rate limiting, those limits apply uniformly across all customers. A sustained attack against shared infrastructure degrades performance for every customer simultaneously. This risk is particularly acute given the billions of dollars in institutional value now flowing through Solana. Third, shared rate limits provide no isolation between customers. When one customer launches a feature generating unexpected traffic, all customers share the pain of increased latency and potential throttling. During 2024-2025, multiple documented incidents showed shared RPC infrastructure degrading across all customers during high-traffic events, even though the underlying Solana network maintained performance. Enterprise security requirements IP allowlistingStrict source IP controls to ensure only authorized environments can access RPC infrastructure.Dedicated infrastructureExclusive RPC nodes with full resource isolation to eliminate shared-risk exposure and noisy-neighbor effects.Private endpointsRPC endpoints reachable only via private networking (VPC peering), not the public internet.SOC 2 Type II and ISO 27001 certificationSOC 2 Type II and ISO 27001–certified operations with request-level logs retained to meet regulatory audit requirements. Part 5: Real Enterprise Use Cases Three categories of enterprise deployments stress different aspects of RPC infrastructure, and 2025-2026 adoption demonstrates these requirements aren’t theoretical. Payment processor workloads (Visa, stablecoin settlement) Visa processes approximately $3.5 billion in annualized USDC settlement volume on Solana. Payment flows are latency-sensitive and multi-step: balance validation, transaction submission, confirmation tracking, and reconciliation. Even small increases in RPC latency compound across these steps and directly impact settlement SLAs. For these systems, WebSocket reliability is critical. Push-based transaction confirmations reduce polling overhead and latency, but unstable connections or missed events introduce reconciliation risk. When settling institutional payment volume, dropped confirmations translate into operational incidents, not just degraded UX. Historical access is equally important. Payment disputes and regulatory reviews often occur weeks or months after execution. Infrastructure limited to short-term data retention forces operators to maintain parallel off-chain databases, increasing complexity and audit risk. Institutional Solana use cases and regulated assets (JPMorgan, tokenized securities) 🚨JUST IN: JPMORGAN JUST TOKENIZED A BOND ON SOLANAJPMorgan arranged the creation, distribution, and settlement of a $50 MILLION short-term bond for Galaxy, fully executed on the #Solana blockchain. pic.twitter.com/GV8d17Aehv— Coin Bureau (@coinbureau) December 11, 2025 In 2025, JPMorgan issued $50 million in tokenized commercial paper on Solana, demonstrating that regulated securities are now settling on the network. These workflows impose strict compliance requirements: complete transaction traceability, long-term data retention, and verifiable auditability. Auditors may request reconstruction of account state at specific historical points, spanning fiscal quarters or entire years. Infrastructure that cannot efficiently serve historical state queries at scale turns audits into manual, time-consuming processes. For regulated institutions, full archive access from genesis forward is non-negotiable. Enterprise Solana infrastructure for stablecoins (Circle, PayPal) Major stablecoin issuers operate dual workloads. Day-to-day operations require low-latency real-time access to process transfers, manage liquidity, and monitor circulating supply. At the same time, treasury and compliance teams require fast historical queries to reconcile issuance, redemptions, and reserve backing over long time horizons. For example, PayPal’s PYUSD, issued on Solana, operates across multiple chains but has seen sustained transaction activity on Solana since mid-2025. Managing this activity at scale requires infrastructure capable of serving both real-time operational queries and historical analytics without switching systems or degrading performance. To learn more about stablecoins on Solana, see our detailed overview here: Stablecoins on Solana in 2026: Growth, adoption, and usage Part 6: Evaluating Solana RPC Providers in 2026 Enterprise teams should evaluate Solana RPC providers based on measurable production behavior—not marketing benchmarks. The following criteria determine whether an RPC provider can support institutional workloads at scale. Performance under real load Demand p95 latency metrics, not averages. Providers should demonstrate stable latency during peak network activity, including ecosystem-wide traffic spikes. Historical incidents have shown some providers maintaining low average latency while p95 and p99 degraded beyond one second under load. Throughput and throttling behavior Verify whether the provider throttles requests during congestion. Shared infrastructure frequently enforces undocumented limits that surface only under real traffic. Enterprise deployments require clearly defined RPS tiers with contractual guarantees—not best-effort rate limiting. Data availability and retention Confirm full Solana history retention from March 2020 genesis onward. Test historical queries directly and compare latency against real-time state queries. Archive access should not be orders of magnitude slower or monetized as a premium add-on. Infrastructure isolation Shared RPC nodes are insufficient for production. Require dedicated infrastructure with exclusive access to compute and networking resources. True isolation eliminates noisy-neighbor effects and enables predictable capacity planning. Reliability and uptime Request documented uptime statistics covering the past 12 months, including both planned and unplanned outages. 99.99% uptime SLAs should be backed by meaningful financial penalties, not symbolic service credits. Pricing predictability Avoid opaque pricing models based on variable compute units. Flat per-request pricing or clearly defined RPS tiers enable accurate budgeting and prevent cost surprises as workloads scale. In 2026, the difference between hobbyist and enterprise-grade Solana infrastructure is not theoretical performance. It is the ability to deliver consistent latency, predictable throughput, complete data access, and contractual reliability under real production conditions. Checklist: Enterprise Solana infrastructure requirements RequirementWhy it matters for enterpriseP95 latency SLAsAverage latency hides spikes. Enterprise systems fail on tail latency, not benchmarks.Dedicated infrastructureShared nodes introduce noisy-neighbor risk and unpredictable degradation under load.Full archive access includedCompliance and audits require genesis-to-present data without add-ons or retention limits.SOC 2 Type II and ISO 27001 coverageCertification must apply to the actual RPC infrastructure, not adjacent services.99.99% uptime guaranteesDowntime directly impacts settlement SLAs and regulatory obligations.Predictable pricingFlat pricing or clear RPS tiers enable budgeting; compute units obscure real costs. Conclusion: Infrastructure determines enterprise outcomes Solana has proven its capabilities as a high-performance blockchain. It consistently produces blocks every ~400 milliseconds, sustains thousands of transactions per second, and now settles billions of dollars in institutional value—from stablecoin payments to tokenized securities. But enterprise applications never interact with Solana directly. They interact with RPC infrastructure. In production, application performance is defined not by network throughput, but by RPC latency under load, data availability, security guarantees, and operational predictability. Many teams discover this distinction too late—after deployments encounter latency spikes, throttling, incomplete historical data, or compliance gaps. By 2026, enterprise requirements are clear. Production Solana infrastructure must deliver: predictable p95 latency, not best-case benchmarks dedicated, isolated infrastructure without shared-risk exposure full historical data access from genesis onward security controls aligned with regulated environments pricing models that remain stable as workloads scale The question enterprise teams should ask is no longer “Is Solana fast enough?”The answer is unequivocally yes. The real question is whether your infrastructure provider can consistently deliver Solana’s performance to your application, across real-world traffic, regulatory scrutiny, and long-term growth. That decision—not blockchain choice—ultimately determines whether an enterprise Solana deployment succeeds in production. Chainstack’s enterprise approach Chainstack’s Solana infrastructure is designed to meet the enterprise requirements outlined above. The platform provides dedicated RPC nodes with full resource isolation, eliminating noisy-neighbor effects common in shared environments. 99.99% uptime SLAs, backed by financial penalties, ensure availability aligned with payment and settlement workloads. Global deployments are supported through geographically distributed endpoints across the US, Europe, and Asia-Pacific, delivering consistently low p95 latency for user-facing applications. Full archive access from genesis is included by default, enabling compliance, audits, and long-term analytics without separate data pipelines or retention limits. Security controls are independently validated through SOC 2 Type II and ISO 27001 certification, while flat per-request pricing removes cost unpredictability associated with variable compute-unit models. Together, these design choices allow enterprise teams to operate Solana workloads with predictable performance, security, and cost at production scale. Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers. FAQ What’s the difference between network TPS and RPC latency? Network TPS measures how many transactions the blockchain can process. RPC latency defines how fast applications can read and write that data. Enterprise failures usually occur at the RPC layer, not the network layer. Do enterprise deployments need dedicated RPC nodes? Yes. Dedicated nodes eliminate noisy-neighbor effects, enable predictable performance, and allow SLA-backed guarantees that shared infrastructure cannot provide. What is p95 latency and why does it matter? P95 latency shows how slow the slowest 5% of requests are. Averages hide spikes that directly degrade user experience and break enterprise SLAs. Can I use public RPC endpoints for production? No. Public endpoints are rate-limited, offer no SLA, retain limited history, and are explicitly documented as not intended for production use. How does enterprise Solana infrastructure scale as demand grows? Enterprise-grade Solana infrastructure must scale predictably without performance degradation. This requires pre-defined capacity planning, dedicated resources, and the ability to increase RPS limits and node capacity without migrating endpoints or re-architecting applications. Scaling should be operationally transparent and contractually defined, not reactive or best-effort. Does Chainstack offer an enterprise infrastructure plan? Yes. Chainstack offers an Enterprise plan for Solana infrastructure designed for production and regulated workloads. The Enterprise plan includes dedicated RPC nodes with full isolation, SLA-backed uptime guarantees, predefined RPS tiers, private networking options, and full archive access from genesis. The plan is built to support predictable performance, security, and cost at enterprise scale. #### ERC-8004: On-chain infrastructure for AI Agents Introduction Over the past few weeks, AI agents have become significantly more capable of taking action with little or no human oversight. Recent viral AI agents such as OpenClaw can manage entire workflows on their own, including replying to emails and phone messages, and analyzing and handling full social media accounts. AI agents are no longer siloed and can now interact with one another, as exemplified by Moltbook, a Reddit-like social media platform where only AI agents can comment, post, and like. A screenshot of Moltbook, a Reddit-like social media platform that only AI agents can use. As AI agents become smarter, new infrastructure is needed to create, manage, and discover them, as well as enable new use cases. Connecting them to blockchains could make it easier for agents to send payments faster using cryptocurrencies such as stablecoins and to track agents on an immutable storage layer. ERC-8004, a new standard for trustless agents released on January 29, 2026, on over 18 EVM-compatible chains, serves as a starting point for realizing this vision by creating registries to list AI agents and their capabilities.  This article explains why AI agents benefit from on-chain infrastructure, how ERC-8004 works, and the trending AI agents that use ERC-8004.  🤖 Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Learn more. An advertising graphic for ERC-8004 on 8004.org, the website dedicated to the standard and its core contributors from Metamask, Ethereum Foundation, Google, and Coinbase. Why AI Agents need on-chain infrastructure on Ethereum AI agent payments and crypto wallets AI agents operate at high speeds and require new infrastructure that can better handle their operations than traditional infrastructure. For example, financial AI agents cannot handle money within traditional banking systems because they cannot open or control their own bank accounts. Financial AI agents can instead create wallets and transact using cryptocurrencies like stablecoins to settle payments, a capability unique to blockchains. The Coinbase Developer Platform enables AI agents to create crypto wallets and x402 links them to on-chain payments, enabling automatic payments for APIs, data, or digital services during execution. For these payment and coordination flows to work reliably, agents need institutional-grade RPC infrastructure that can serve as an MCP server between the agent and blockchains, such as Chainstack. The trust and identity problem for AI agents ERC-8004 aims to solve another major challenge: as the number of AI agents grows and they take on more important tasks, such as managing money, tracking, and validating them, the need to track and identify which AI agents to trust becomes increasingly important. Humans need ways to track and validate AI agents, as it becomes harder to distinguish them from humans, and to identify who is accountable when agents exhibit harmful behavior. ERC-8004 develops a foundation for AI agents to use blockchains to discover, choose, and interact with other agents across organizational boundaries. Marco Derossi, the AI Lead at MetaMask and a core contributor to ERC-8004, describes the standard as a method to create a “catalog of agents on-chain.” Users can actually truly “trust” the AI agent as its information and external feedback are stored on-chain. In this clip, @marco_derossi from @MetaMask describes ERC-8004 as an onchain catalog of agents, with commitments onchain and metadata on Filecoin Onchain Cloud. Agents can reference this data directly to identify endpoints, capabilities, and terms. pic.twitter.com/xQJb6XqGDv— Filecoin (@Filecoin) February 13, 2026 In a recent post, Ethereum further detailed the five new ways in which ERC-8004 improves the current AI agent ecosystem and experience: 0/ ERC-8004, the standard for universal AI agent identity, reputation, and verification, is now live on Ethereum Mainnet.With the ERC-8004 standard, AI agents are accountable economic actors.Here are 5 unlocks that ERC-8004 gives to builders, and how to integrate today.— Ethereum (@ethereum) February 10, 2026 Find agents across platforms  Instead of every app keeping its own private list of agents, ERC-8004 allows agents to be listed in a common registry. This makes it easier to discover agents built by different teams or companies. Choose agents based on track record  Because feedback can be recorded on-chain, users and other agents can review past ratings and comments. This helps them choose agents who have performed well in the past. Check an agent’s work  Some agents can verify or review the output of other agents. The results of those checks can be recorded so others can see whether an agent’s work was reliable. Match security to the task  Not every task needs the same level of checking. ERC-8004 allows developers to use stronger verification where it matters and lighter checks for simple tasks. Portable agent identities  An agent’s identity is tied to a token that points to its metadata. That identity is not tied to a single app, so the same agent can be recognized across different services. Together, AI agent frameworks such as ERC-8004 and x402 help Ethereum, as Vitalik Buterin, founder of Ethereum, says, “become an economic layer for AI-related interactions.” Two years ago, I wrote this post on the possible areas that I see for ethereum + AI intersections: https://t.co/ds9mLnrJWmThis is a topic that many people are excited about, but where I always worry that we think about the two from completely separate philosophical… pic.twitter.com/pQq5kazT61— vitalik.eth (@VitalikButerin) February 9, 2026 How ERC-8004 works: Identity, reputation, and validation registries The standard defines a set of on-chain registries that provide AI agents with persistent identities and standardized mechanisms for publishing metadata, receiving feedback, and recording third-party validations on Ethereum-compatible chains. The goal is to make agents easier to discover and evaluate across applications without relying on a single centralized directory. The standard introduces three main registries deployed as contracts on a chain, designed to keep on-chain data to a minimum. Identity Registry: Minting AI Agent NFTs The Identity Registry assigns each agent a unique identifier by minting an ERC-721 token, a token standard commonly used for NFTs.  To register an agent, the agent owner or core developer must mint an ERC-721 token on the ERC-8004 Identity Registry smart contract on their desired chain. They can call the mint function directly or use a no-code platform such as agentscan.info or 8004scan.io. If using the function directly, they must include a tokenURI that points to a metadata file hosted on a storage service, such as IPFS, that describes the agent’s name, capabilities, and API endpoints. We’ll use Minara AI, the AI agent registered on Ethereum with the most feedback. She’s an intelligent crypto assistant AI agent that provides real-time market analysis, DeFi guidance, swap-intent parsing, perp trading suggestions, and prediction-market analysis, as an example. An agent owner controlling wallet 0xB27AfB1741AA9BE0B924d99b26EbF5577054A138 registered the agent by calling the ERC-8004 Identity Registry contract on Ethereum in this transaction, which minted ERC-721 token ID 6888 to the creator address. The basic information of the Minara agent is provided, based on its registration. The token’s tokenURI points to an IPFS metadata file that describes the agent. This snippet shows a preview of the metadata: {"name": "Minara AI","description": "Intelligent crypto assistant powered by AI. Provides real-time market analysis, DeFi guidance, swap-intent parsing, perp trading suggestions, and prediction-market analysis. Supports x402 with multi-chain support. Website: https://minara.ai | X: @minara","image": "https://minara.ai/images/minara-logo-lg.png", } Reputation Registry: On-Chain Feedback for AI Agents The Reputation Registry defines how users or other agents can leave feedback about an agent’s performance. Feedback is recorded in a structured format on a chain, typically as simple ratings or tagged signals. More complex scoring and aggregation are expected to happen off-chain through indexers or analytics services. This keeps on-chain costs low while still making raw feedback publicly accessible. The Minara AI agent has over 135 feedback comments, with an average score of 87.49/100, which were recorded in the Reputation Registry on Ethereum. For example, a user with wallet 0x533d4d59ede3088c4F58616DDd6EeeA721D671F2 submitted feedback for the Minara agent by calling the ERC-8004 Reputation Registry on Ethereum in this transaction. The contract logged a rating of 80/100 with the following comment: The analysis speed used by Minara is incredibly fast compared to other platforms! I also use the mobile app, and I really like it because I don’t have to wait impatiently. However, I do my trading on a computer, because charts are not visible in the app. If this issue is improved as well, Minara will become a truly excellent platform—one where users can analyze the market and trade at the same time with great convenience. Validation Registry: Verifying Agent Outputs The Validation Registry lets agents request independent verification of their outputs and store references to the results. A validator could be another agent, a specialized service, or a system that re-executes tasks. The registry records requests and responses as hashes and URIs, so the detailed data can live off-chain while the existence and integrity of the validation are anchored on-chain. The Validation Registry is still planned, and its corresponding smart contracts have not yet been deployed. The three registries together provide a common format for listing agents, describing their work, collecting user feedback, and linking to verification results. Though payments are not included in the standard, ERC-8004 provides a framework for a standardized, immutable, trustless database of AI agents, using EVM-compatible blockchains as the core solution. The Agents page of 8004scan, an “agent” explorer or a web-based search engine of AI agents created by indexing the Identity and Reputation Registries on all chains that support ERC-8004.  AI Agents using ERC-8004 across EVM Chains ERC-8004 adoption metrics ERC-8004 has helped AI agents become a booming new vertical on EVM.  49,283 agents and 16,975 feedback comments are registered across all EVM-compatible chains that support ERC-8004, as of February 14, 2026. The top chains with registered agents are Ethereum (25,247), Base (17,616), and Binance Smart Chain (5,264). An X post from Etherscan, the most popular Ethereum block explorer, announces that 24,000 trustless agents have registered on Ethereum since February 13, 2026. Growth trends since launch Over 21,000 agents, or more than half of the total, were registered within the first two days of ERC-8004’s launch. The number of AI agents and feedback comments registered on the 13 chains indexed on Trust8004.xyzsince the launch of ERC-8004. Source: Trust8004.xyz Over the past two weeks, the number of registered agents has stabilized. In the past seven days, the number of agents has grown by an average of 1,000 per day. The number of feedback comments has grown more than sevenfold in the past two weeks, from 685 on February 1 to 7,694 as of February 14, 2026.  The number of AI agents and feedback comments registered on the 13 chains indexed on Trust8004.xyz in the last 7 days. Source: Trust8004.xyz Most popular ERC-8004 AI agents The top agent-type categories include: Infrastructure (2,666 agents), Trading and DeFi (793 agents), Research and Data (546 agents), Chatbot and Personal Assistant (103 agents), Creative/Art/Design (386 agents), Developer/Code (105 agents), DAO/Coordination (101 agents), Entertainment/Personality (293 agents), and Trust/Oracle/ Validation (80 agents).  The most popular AI agents since the launch of ERC-8004 are: Meerkat James, one of the most highly rated agents (avg score of 96 out of 100), is a specialized AI agent with deep expertise in robotics, automation, and intelligent systems. It is trained on a comprehensive knowledge base on mechanical engineering, control systems, computer vision, and embedded programming. The most trusted AI agent, according to Agentscan’s criteria, is Clawdia, which helps builders on Base with smart contract audits, protocol development, research & integration work. Loopuman is a trending AI agent that routes tasks to verified human workers worldwide via Telegram & WhatsApp. Users post tasks via Telegram and WhatsApp, deposit funds, and an agent assigns verified workers. Workers complete tasks, and the agent verifies quality. Workers get paid with CELO once verified.  Agents are generally well-received by the Ethereum community. 84% of feedback, recorded in the Reputation Registries, received scores of 81-100 out of a total score of 100. The score distribution of agents using the ERC-8004 standard. Source: Trust8004.xyz Infrastructure requirements for ERC-8004 AI Agents ERC-8004 agents interact continuously with on-chain identity and reputation registries. Production deployments require reliable RPC infrastructure to mint ERC-721 identities, record feedback, query metadata, and verify registry states across EVM-compatible chains. Chainstack provides enterprise-grade RPC infrastructure purpose-built for AI agent workloads, supporting all major ERC-8004 networks and 70+ additional chains. For ERC-8004 specifically: High-availability RPC endpoints: Ensure uninterrupted identity registration and feedback recording Low-latency reads: Fast metadata and registry queries for real-time agent discovery Archive node access: Historical registry lookups for auditing and validation Global endpoints: Consistent performance across regions where agents operate Predictable request-based pricing: Aligns with high-volume registry interactions As ERC-8004 expands across EVM chains, developers can rely on a single infrastructure provider without reconfiguring RPC environments. Get RPC for AI agents → Conclusion As AI agents become more embedded in workflows, the need to identify and manage them in a trustless manner grows.  ERC-8004 is a new standard that uses Ethereum as an on-chain catalog of agents, feedback, and verification of their inputs. By standardizing common registries of agent identities and on-chain public feedback, users can easily identify them and decide which to trust. With over 49,000 agents registered and more than 16,000 pieces of feedback recorded across 18+ chains, ERC-8004 is quickly becoming foundational infrastructure for agent discovery. Supporting this growth requires reliable RPC infrastructure. Providers such as Chainstack deliver the uptime, low latency, and predictable performance needed for high-volume registry interactions at scale. Start building AI agents now → FAQ What is ERC-8004? ERC-8004 is an Ethereum standard that creates on-chain registries for AI agents, providing them with persistent identities, reputation scores, and validation mechanisms. It enables users to discover, evaluate, and trust AI agents across different platforms. How does ERC-8004 work? ERC-8004 uses three registries: Identity Registry (assigns each agent a unique ERC-721 NFT), Reputation Registry (stores user feedback on-chain), and Validation Registry (records third-party verification of agent outputs). Which blockchains support ERC-8004? ERC-8004 is live on 18+ EVM-compatible chains including Ethereum, Base, Binance Smart Chain, Polygon, Arbitrum, and Optimism. The standard works on any EVM chain that supports smart contracts. How do I register my AI agent on ERC-8004? ERC-8004 agents need reliable RPC endpoints to interact with blockchain registries, verify identities, and record feedback. Enterprise-grade infrastructure like Chainstack provides the 99.99% uptime, low latency, and MCP server support required for production agent workloads. Can ERC-8004 agents make payments? ERC-8004 focuses on identity and reputation, not payments. For autonomous payments, agents can combine ERC-8004 with x402 protocol or use crypto wallets through platforms like Coinbase Developer Platform. Related AI agent infrastructure articles x402 Protocol for AI Agents Building a Web3 AI Trading Agent from Scratch Integrating Chainstack with OpenClaw Bot for Polymarket #### ERC4626: A new standard for tokenized vaults ERC token standards We’ve heard about the ERC20 and ERC721 token standards. And in case you’re not familiar with them, here is a quick refresh: ERC20: an implementation for tokens that includes methods like transfer, approve, allowance, totalSupply, and balanceOf. It’s used as a base for hundreds of tokens like USDC, WBTC, or LINK.ERC721: an implementation for Non Fungible Tokens (NFTs) used for assets and collections like Bored Ape Yatch Club (BAYC) or Moonbirds traded in OpenSea and other marketplaces. They are the building blocks that allowed hundreds of apps to appear in recent years and the main reason behind the ICO era of 2018 and the NFT boom in the last two years. These standards gave developers a starting point for their apps and allowed them to create tokens in just a few minutes. The ERC4626 is a new extension of the ERC20 and it will give a fresh perspective to the DeFi space. ERC4626 in a nutshell A tokenized vault holds a specific ERC20 token and gives shares to the users that deposit assets in it. When a user deposits funds, the vault will mint a specific number of shares for the user. When the user withdraws tokens from the vault, the correspondent amount of shares will be burnt. The ERC4626 contract inherits from the ERC20 contract to manage the shares that will be minted and burnt when the users interact with the vault. It’ll do so by calling the methods mint and burn from ERC20. This means that other methods like balanceOf and totalSupply can be used. In addition, as shares are ERC20 tokens, they can be transferred using the native transfer method (or transferFrom), unless the vault is created as non-transferrable. ERC 4626 Methods Here are some of the most important methods in the ERC4626 tokenized vault contract: constructor(ERC20 asset, string name, string symbol) The constructor that initializes an ERC4626 vault upon deployment receives three parameters: asset — is the underlying token that will be stored in the vaultname — the name of the vaultsymbol — the symbol of the shares minted for the users asset() The asset method returns the address of the ERC20 token that is deposited in the vault by the users. deposit(uint assets, address receiver) The deposit method is used to deposit the exact amount of assets in the vault and mint a corresponding number of shares for the receiver. As the token will be transferred to the vault, this requires that the user had approved for the tokens to be transferred in advance via the approve or transferFrom ERC20 methods. The methods maxDeposit returns the maximum amount of tokens that can be deposited in the vault. The previewDeposit method allows users to simulate the deposit and returns the number of shares that the user would receive. mint(uint shares, address receiver) Similar to the deposit method but in this case, it receives as a parameter the number of shares to mint. The maxMint and previewMint methods are also available. withdraw(uint assets, address receiver, address owner) The withdraw method burns the corresponding number of shares required to send the indicated amount of the original asset to the receiver. The maxWithdraw method returns the maximum number of tokens that the user is allowed to withdraw. The previewWithdraw allows users to simulate the withdrawal and returns the number of shares that would be burned in the withdrawal. redeem(uint shares, address receiver, address owner) Similar to the withdraw method although it receives as a parameter the number of shares to burn. The maxRedeed and previewRedeem methods are also available. Events The ERC4626 tokenized vault has just two events: Deposit: emitted from the deposit and mint methods.Withdraw: emitted from the withdraw and redeem methods. Contract interface Here is the full contract interface for the ERC4626, which includes all the methods and events: interface IERC4626 { function asset() external view returns (address assetTokenAddress); function totalAssets() external view returns (uint256 totalManagedAssets); function convertToShares(uint256 assets) external view returns (uint256 shares); function convertToAssets(uint256 shares) external view returns (uint256 assets); function maxDeposit(address receiver) external view returns (uint256 maxAssets); function previewDeposit(uint256 assets) external view returns (uint256 shares); function deposit(uint256 assets, address receiver) external returns (uint256 shares); function maxMint(address receiver) external view returns (uint256 maxShares); function previewMint(uint256 shares) external view returns (uint256 assets); function mint(uint256 shares, address receiver) external returns (uint256 assets); function maxWithdraw(address owner) external view returns (uint256 maxAssets); function previewWithdraw(uint256 assets) external view returns (uint256 shares); function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares); function maxRedeem(address owner) external view returns (uint256 maxShares); function previewRedeem(uint256 shares) external view returns (uint256 assets); function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets); event Deposit(address indexed caller, address indexed owner, uint256 assets, uint256 shares); event Withdraw(address indexed caller, address indexed receiver, address indexed owner, uint256 assets, uint256 shares); } Example implementation The ERC4626 specification is completed and you can find all the details here. Based on that, a pull request was created in the OpenZeppelin repository which was finally merged on June 1st, 2022. The tokenized vault is an ERC20 extension so you can import it from : openzeppelin-contracts/contracts/token/ERC20/extensions/ERC4626.sol You can find the full contract here. As the specification is already completed, there are teams already working with it. For example, Rari Capital has a GitHub repo with the ERC4626 contract and an example implementation. In that example, you can see how they’ve extended the contract to include fees, an authentication system that sets the contract deployer as the owner of the vault, more events, etc. If it looks too complex, check out the Vault’s test file to understand how to interact with the Vault contract. You can run the tests locally using Foundry (check out our intro to Foundry here). Conclusion The adoption of this standard is promising, and I’ve already found one version written in Vyper by fubuloubu and another one written in Cairo. There are also some tools under development, like this ERC4626 router by fei-protocol that can perform multicalls to different vaults. By using a standard token, interoperability between protocols will be improved, aggregators will be easier to build, and applications will be more secure. Now it’s your time to start building with it 🤙 Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Erigon vs Geth: choosing the right Ethereum client Introduction Ethereum is one of the most widely used blockchains and a leading smart-contract platform. For teams running node infrastructure in 2026, the practical question is usually not what an Ethereum client is, but which client is the better operational fit. This guide compares Geth and Erigon across the criteria that most affect production outcomes: sync model, disk footprint, trace/debug behavior, and archive-node suitability. Since Ethereum’s transition to Proof-of-Stake in September 2022, both Geth and Erigon have continued to evolve significantly. By 2026, archive node requirements have increased, making sync behavior and storage efficiency more important for production infrastructure decisions (see chainstats.org for current sizing trends). Recent upgrades such as EIP-4844 (Proto-Danksharding), implemented in March 2024, have also changed how clients handle data availability. At the same time, the client ecosystem has expanded with newer options like Reth, giving teams more flexibility in how they run Ethereum infrastructure. Against this backdrop, Geth and Erigon remain actively developed and widely used. This guide focuses on the practical choice between them: sync model, disk efficiency, tracing/debug workflows, and archive-node suitability. Erigon vs Geth at a glance DimensionErigonGethPractical decision signalSync architectureStaged sync pipeline optimized for fast catch-up and modular processingTraditional sync modes with broad default usageChoose Erigon if sync throughput and operational tuning are prioritiesDisk footprintTypically more storage-efficient data layout for historical-heavy use casesOften larger footprint for equivalent historical workloadsChoose Erigon for archive or analytics-sensitive infrastructureTrace/debug workflowsStrong fit for historical analysis and tracing-heavy backendsWidely supported, but workload cost can rise for heavy trace patternsChoose based on how trace-heavy your production workload isArchive suitabilityFrequently preferred for archive/indexer-style operationsViable, but can be more resource intensive at scaleFor sustained historical querying, Erigon is often more cost-efficientTooling/ecosystem defaultGrowing adoption, but less “default-first” than GethBroadest default compatibility across guides/toolingIf you need lowest-friction ecosystem default, Geth may be simpler For practical comparison, we benchmarked RPC behavior on both clients, focusing on trace/debug workflows and response characteristics relevant to production use. The center of these comparison tests is the debug_traceTransaction method, and the bulk of the testing focused on the differences in response speed between Erigon and Geth and the amount of data retrieved. In our tests, Erigon returned richer trace output than Geth for the same debug_traceTransaction calls. That additional output can increase response size and processing time, so latency comparisons should be interpreted together with payload depth, not speed alone. Erigon’s benefits  Erigon originated from Turbo-Geth and has diverged significantly in architecture and storage design. The team made some fundamental changes to the full sync algorithm and the storage system, allowing you to sync an Ethereum archive node much faster and using less disk space. Staged sync  Erigon improves sync speed by adopting a staged sync process. When Geth synchronizes a full node, it downloads the blocks’ data. Then, it replays the transactions while working on other operations, for instance, retrieving the senders of the transactions from the private signatures or verifying the block headers. As a result, the process is less efficient since many things are happening simultaneously.  Erigon instead breaks down the process into different stages and completes them in sequence; this means that the program will first complete a stage before moving on to the next, making the overall process faster.  16 stages compose staged sync, and the Erigon Documentation explains it extensively.   Disk efficiency  Erigon uses a more effective system to store data compared to Geth, and three main features allow Erigon to be so good at optimizing disk space: Flat KV storage Erigon stores the data in a database made of key-value pairs, allowing it to store it more straightforwardly.   You can find a detailed explanation of the database storage in the Erigon Documentation.  Pre-processing Erigon uses an ETL (Extract, transform, Load) architecture to process data. It extracts the data from its source, transforms it into the required data type, loads it into a temporary file, and places it in the correct order in the database. This way, the process is sped up by pre-processing data before saving it into the database.    You can find a detailed explanation of the ETL framework in the Erigon Documentation.  Single accounts/state trie Ethereum uses a data structure called Merkle Patricia Trie for its storage layer and to verify the integrity of the transactions. Geth uses 3 Merkle Patricia Tries Transaction Trie, Receipt Trie, and State Trie, while Erigon uses a single Merkle trie. This structure allows Erigon to be more efficient.  I recommend checking Erigon’s primary documentation for more details about all the features and functionalities Erigon offers, which are often updated.   What can you do with Erigon?  Like Geth, Erigon allows users to deploy nodes, but one substantial difference compared to Geth is that Erigon is commonly used for full/archive-style workloads; check the current Erigon docs for mode-specific behavior and flags.     Erigon is also available on Windows, Linux, and macOS, and the Erigon’s documentation explains how to install it.  Once you install Erigon, you can use this line to check available commands.    erigon --help Now that we have seen how Geth and Erigon compare on the sync speed and disk utilization side of things— let’s explore the DApp development side. Erigon offers a few RPC methods that are not available when querying a node running Go Ethereum, the most prominent being eth_getBlockReceipts and the debug (unless it’s activated) and trace API. eth_getBlockReceipts RPC Method  Calling eth_getBlockReceipts will return the receipts of all the transactions in a specified block displaying the transaction details. This method can be helpful when you want to retrieve information about all the transactions in a block in one go— instead of calling multiple different methods.  Below, you can find an example of the code you would run in cURL to call this method, but you can find a detailed explanation in the eth_getBlockReceipts guide repository, where you will find an example of what the method returns.   curl -X POST 'ERIGON_NODE_URL' \ -H 'Content-Type: application/json' \ --data '{"method":"eth_getBlockReceipts","params":["latest"], "jsonrpc":"2.0","id":1}' Remember that you need access to an endpoint from a node running Erigon to use eth_getBlockReceipts.  Debug and trace transactions  Erigon includes the debug and trace modules, which allow you to get deeper into the processing of a transaction. These functions are generally used to troubleshoot failed transactions or trace calls and transactions.You can study calls or transactions that are already validated or simulated. Trace So far, we know that tracing a transaction will give us extra information about it, but what does that mean? Generally, we can have two kinds of transactions, a direct Ether transfer between accounts and a transaction to a smart contract. For example, transferring ETH from A to B is pretty straightforward, and nothing else will happen besides updating the accounts’ balances— it is another story if the transaction goes to a smart contract. In addition to sending ETH to the smart contract, a portion of the bytecode can be executed during the transaction. A smart contract can execute complex operations. For example, it can interact with many accounts simultaneously and even call functions from other smart contracts. So, without tracing the transaction, it would not be possible to see all these intermediate operations. trace_transaction use case  At this point, we know what tracing does, but why would you want to trace a transaction in the first place?  trace_transaction is one of the methods available in Erigon, and it takes a transaction hash as input, allowing you to see the internal function calls made into a smart contract. This is important because you could send a transaction to a proxy smart contract, which will then call a function from another one, and you would never know this without tracing the transaction.  Below, you can find an example of the cURL code you would run to call this method:  In this case, this transaction calls the claim function to mint an NFT; check the detailed analysis of the transaction on the trace_transaction analysis gist, where it shows it goes through a proxy contract.   curl -X POST 'ERIGON_NODE_URL' \ -H 'Content-Type: application/json' \ --data '{"method":"trace_transaction","params":["0x8c66dab09ffdc7024a958a4a08e998b83fa146f805b301dd636909107deb9edf "],"id":1,"jsonrpc":"2.0"}' Remember that you need access to an endpoint from a node running Erigon to use trace_transaction. There are multiple RPC methods that you can call using the trace module, and some of them do not support all the trace types. Check all the JSON RPC methods available using Erigon in the docs.  Debug The debug function is handy while developing a smart contract to understand why a transaction is failing. The debug_traceTransaction method accepts a transaction hash as the parameter. It returns an array of traces that include logs of low-level opcode (operation code), allowing one to understand what might be wrong during the processing of the transaction.  Below, you can find an example of the cURL code you would run to call this method:  In this case, this transaction calls the transfer function of a smart contract, and it fails. Check the detailed debug analysis on the debug_traceTransaction analysis gist, showing that the transaction is reverted because the address is not included in the whitelist mapping.  curl -X POST 'ERIGON_NODE_URL' \ -H 'Content-Type: application/json' \ --data-raw '{"method": "debug_traceTransaction", "params": ["0x1cd5d6379c7a06619acaf07a1a87116e5a476203b1798862ebb7144ecc5ebba9", {}],"id":1,"jsonrpc":"2.0"}' Try debug and trace on Chainstack’s web app The app allows you to input the endpoints of two nodes, an Erigon node and a Geth node, and the transaction hash of the transaction on which you want to call the debug_traceTransaction method. With the debug module enabled, you can use any RPC endpoint available if the node runs Erigon and/or Geth. But if you don’t have access to such nodes, Chainstack got you covered, of course. Follow these steps to sign up on Chainstack, deploy a node, and find your endpoint credentials:  Sign up with Chainstack. Deploy a node.  View node access and credentials.  📖 You can test the app directly in JS fiddle or run it locally by cloning the GitHub repository, which includes comprehensive instructions and explanations about the source code.   Then you can choose whether to call the trace_transaction method (available only on Erigon) or the debug_traceTransaction method. Tracing or debugging the transaction will calculate the time needed to retrieve the data, the size of the data retrieved, and display the parsed result, which will look something like this: This example is part of the response from calling the trace_transaction method using the Erigon endpoint. You can also only compare the two nodes on the same transaction hash. This will call the debug_traceTransaction method at the same time and display only the analytics. If you call the debug_traceTransaction method on the same transaction hash, you will notice that Erigon will take more time to retrieve the data, but it will also retrieve more data, as Erigon will also return the memory data.   What is Go Ethereum (Geth)?  Go Ethereum, often abbreviated to Geth, is a Command Line Interface (CLI) Ethereum client written in Go (An open-source programming language developed by Google) and is the official Go implementation, fully open source, and licensed under GNU LGPL v3. Because of this, developers have free access to its code and can help improve it and add new features.   But how does Geth allow you to participate in the Ethereum network? Geth is a versatile client, and comes with a built-in JavaScript console, has a big community around it, and allows you to:    Run nodes to secure the network As you know, you can run different types of nodes, a full node is a standard, but you can also deploy a light node or a full node in archive mode.    Check out this article by Petar for details about the different types of nodes.   Provide access to the blockchain via JSON RPC endpoints exposed on HTTP, WebSocket, or IPC transports RPC endpoints are your access point to the blockchain. For instance, you can retrieve information using a DApp or use a custom endpoint for your MetaMask. Geth allows you to expose your node’s endpoint and use it for these operations.   You can enable your HTTP endpoint using this command:  geth --http The Geth docs provide instructions to configure the node’s endpoint.    Geth also supports the GraphQL API, which can help make the requests to the node more efficient, reducing the load. The GraphQL endpoint runs on top of the HTTP endpoint, and you can activate it with this command:  geth --http --graphql The Geth documentation explains how to activate the GraphQL endpoint and query it.   Create a private network and run testnet nodes  This option allows you to create your own private Ethereum network. Organizations and enterprises often use this feature to leverage blockchain technology without exposing information to the public or using real Ether to pay for transactions.  Geth supports different operating systems, including Windows, macOS, and Linux. The Go Ethereum website goes through all the other options and instructions, but Linux is the most used.  How does Geth synchronize?  Synchronization is the process that allows the node to get the latest and updated blockchain state from other nodes, and when you start the sync process, your client will look for other peers in the network to download data from. Geth has different sync modes available depending on the type of node you wish to deploy and what state information you want your node to retain. The different sync modes available with Geth at the moment are: Snap The snap mode is the default synchronization method in Geth, and you can use it to quickly set up a node to interact with the network. This mode was introduced in Geth version 1.10.0 and was designed to reduce the time and resources needed to sync to the blockchain, particularly disk space. The typical use case for the average user is to just interact with the blockchain, for instance, transfer ETH and interact with smart contracts. To achieve this, you do not need historical data, and this sync mode allows a user to get up and running faster than synchronizing a full node.    How does snap work Instead of starting the syncing process from the genesis block (the first block in the chain) and processing every transaction, the snap mode just downloads a snapshot of the current state. This mode gets you up and running quickly, but does not retain historical state — queries beyond the last 128 blocks are not available without running in archive mode. To secure the network, a node started with snap mode must first go through the state trie download phase, where it will download the accounts data (state of the network) and cross-check it with the blocks to ensure that the information is accurate.  As we mentioned, the snap mode is the default on Geth, and once you have installed it, you can initiate it with this command: geth console This command will initiate the snap sync mode on the Ethereum mainnet and the JavaScript console, where you can interact with web3 and call the JSON RPC methods. This is what the beginning of the process looks like on the console. I am using Windows in this example:  Full nodes A full node stores the entire blockchain and is responsible for verifying the transactions. This sync mode will download all the blocks from genesis, including headers, transactions, and receipts, verify all blocks, and re-execute every transaction. Full nodes are the backbone of the network and are responsible for maintaining security and ensuring only valid transactions propagate to the rest of the chain. A full node can be used to retrieve information about the state of the blockchain, but to maintain efficiency, some info is periodically pruned (removed). Because of this, a full node running on Geth can only query the state of the blockchain up to the last 128 blocks. Technically, the node can reconstruct all the intermediate states from genesis, but it would be very resource intensive and might cause the node to fall out of sync and disable. To start synchronizing a full node, run this command after you installed Geth: geth --syncmode full As mentioned above, a full node prunes data to save disk space, but if you need historical data, you could run a full node in archive mode. In this case, it would store all the intermediate states, and you could query information from any point in the past. Usually, running an archive node is the least desired option, as there is so much data that it would take months to sync an archive node. To sync an archive node, you must run this command, defining the garbage collection mode to archive:  geth --syncmode full --gcmode archive This article explains the difference between full and archive nodes in greater detail.   Geth commands  The paragraphs above show you the commands to start the sync process, but Geth has many options available to configure your node. You can find all the commands available by typing this line in the console: geth --help Or by visiting the command-line options page in the Go Ethereum docs.  What is an Ethereum client? In the computer world, a client is a software that can connect to a server to exchange data. For example, the web browser you use to read this article is a client that connects to a website’s server, receives its content, and displays it to you. In the Ethereum blockchain case, the client is a program that connects to other clients in the peer-to-peer network and implements the Ethereum protocol. The EVM is the execution environment used to run smart-contract bytecode within that protocol. Essentially, if you install and run an Ethereum client, your computer will turn into an Ethereum node. Nodes verify transactions, read data from the blocks, and execute smart contract instructions keeping the network secure and up to date. What does EVM mean? At this point, after comparing clients, it helps to briefly clarify the EVM and EVM-compatible networks for context. Of course, you already know that the Ethereum network is made of computers that run the Ethereum client. The Ethereum Virtual Machine runs in each of these Ethereum instances. Essentially, its role is to execute the code of the smart contracts (like how the CPU executes instructions on your PC) and update the blockchain state. The state of the Ethereum blockchain is made by accounts identified by an address. Each account holds four fields:   The account nonce identifies how many transactions that account made. The current ETH balance. The smart contract code. The smart contract storage. The code and storage fields are empty if the account is not a smart contract. When an account makes a transaction, the EVM, which already holds the current state, computes it and updates the states, keeping track of the account balance, nonce, etc. EVM is not only Ethereum As a result of the support for smart contracts, the Ethereum blockchain became incredibly popular, leading to congestion in the network and high transaction costs. Because of this, developers created other more efficient blockchains while maintaining EVM compatibility, so that smart contracts existing on the Ethereum network could easily be redeployed on other networks attracting users and developers. In short, an EVM-compatible network is a blockchain developed following the EVM specifications. As a result, developers do not need to learn a new programming language to deploy smart contracts to another EVM-compatible blockchain or re-write the code from scratch if they want to redeploy a contract already existing on the Ethereum network. BNB Chain, Avalanche, and Polygon are examples of popular EVM-compatible blockchains, and Chainstack supports many EVM-compatible protocols. You can check Chainstack’s website for an updated list of supported protocols. Erigon for EVM-compatible chains As we saw, Erigon has enormous potential as it allows us to maintain nodes with a fraction of the hardware compared to Geth. For this reason, it is becoming more popular among networks other than Ethereum, especially as the disk requirements to keep archive nodes keep growing. Now more of these chains are integrating their consensus mechanism into the Erigon client; the most prominent ones are the BNB Chain and the Polygon network. Disk requirements for archive nodes have grown significantly since Erigon was introduced. For Ethereum mainnet, Erigon archive nodes require approximately 3–3.5 TB compared to 18–20 TB for Geth. For Polygon, the archive node using Erigon is approximately 4.5 TB. These numbers grow continuously — check the Erigon hardware requirements docs for current figures This guide explains how to run a Polygon archive node on Erigon, while you can check the BNB chain documentation to run an archive node for the BNB chain. Over time, the disk space required to maintain archive nodes will only grow, and it is vital for software like Erigon to succeed in the long term to have a way to run archive nodes in a more user-friendly manner. Conclusion For most production teams choosing between Erigon and Geth, the decision comes down to sync model, disk profile, and tracing/debug workload needs. Erigon is often preferred for archive and analytics-heavy use cases, while Geth remains the default for broad ecosystem compatibility. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Essential Web3 calls This article first appeared in Hacker Noon. Building on top of Ethereum has never been easier. Frameworks such as the ever-popular Truffle-suite and Embark make it very easy for developers to quickly deploy contracts and interact with them. These frameworks, unfortunately, are best suited for testing and experimentation. What happens if we want to have a server connect to a blockchain and then have it interact with smart contracts? Enter Web3, a wrapper for Ethereum’s JSON-RPC API. Despite being an abstraction library, it still offers great flexibility and can handle a large deal of complexity. In this tutorial, we’ll be developing on top of the Quorum network. Quorum is similar to Ethereum, so you’ll find that this guide will work perfectly well with Ethereum as well. I chose Quorum specifically because transactions are near-instant, and I don’t need to refill my wallet with test ethers since all transactions are free. We’ll split this guide into two sections: Contract Deployment and Contract Interaction. Creating your Quorum network At Chainstack, you can create your own Quorum node easily. We have a free trial for 7 days, so hop on over to our console to get started. If you don’t want to use Quorum, you can connect to your own Ethereum node via Geth or Parity, but you can deploy your own node on Chainstack as well for free 🙂 Smart contract deployment Let’s prepare a simple smart contract called Hello.sol pragma solidity 0.5.0; contract Hello { string text; event received( address _received ); constructor(string memory _text) public { text = _text; } function getText() public view returns(string memory) { return text; } function changeText(string memory _newText) public { text = _newText; } function pay() public payable { emit received(msg.sender); } } The Hello contract accepts String argument to deploy it. You can also call getText() to get back the string that you set during deployment. To change the text, call changeText() and supply it with your new string. Finally, the contract has a payable function called pay(). A payable function is a function that can be sent Ethers to, and then the function is executed. We’ll see how all of this is done using Web3js. We’ll also assume that you know how to compile and get the bytecode and ABI of the contract. An easy way to do so is to use REMIX, and copy the bytecode and ABI that it provides. Let’s start by creating a contract instance: const Contract = web3.eth.Contract(abi) You have to supply the ABI so Web3 knows the specifications of each function in the Contract. Next, deploy the contract.  .deploy({ data: contractData.bytecode, arguments:[title], }) The deploy function accepts an object. This object contains two things, the bytecode of the contract (which you obtained via REMIX) and the arguments for the constructor. While this function is called .deploy(), it actually doesn’t deploy the contract to the blockchain. We’ll have to use .send() to finalize this process: .send({ from: address, gas: 470000000, //9000000 for Ethereum gasPrice: 0, // 3000 for Ethereum (3000 wei) }) .send() also takes in three key objects: 1. From Address2. Gas Limit (or just Gas)3. Gas Price Let’s chain .deploy() and .send() together: contract.deploy({ data: contractData.bytecode, arguments:[title], }) .send({ from: address, gas: 470000000, gasPrice: 0, }) This will return a promise, which contains the transaction receipt for the deployment of the Hello contract. In summary, to deploy a contract you need to:1. Get the bytecode and ABI of the contract2. Create a contract instance3. Include the bytecode and constructor arguments in .deploy()4. Send it to the blockchain using .send() Once deployed, the transaction receipt contains the address of the smart contract. We’ll need this in the next section. Smart contract interaction Contract interaction is slightly more complicated. The contract has three functions, getText() , changeText() and pay(). Let’s get an instance of the smart contract so your JavaScript file can interact with it. const contract = Web3.eth.Contract(ABI,contractAddress) We’ll have to supply the ABI so Web3 knows how to interact with the contract. This time, we supply the contractAddress, so Web3 knows where to send our calls to. With the contract instance, we can now access the getText() function: const text = await Contract.methods.getText().call({}) The important thing here is the .methods object. The contract object exists as a nested object in JavaScript, and the function calls are stored in the methods object. Since getText() is a view function, it does not make any changes to the blockchain. Thus, we chain the the function with .call({}). call() also returns the value in the returns() argument of the function in the smart contract and not the transaction receipt. How about the changeText() function? Take a look: Contract.methods.changeText('New Text').send({ from: accounts, gas: 470000, gasPrice:0 }) For non-view functions or functions which change the state of the blockchain, we have to chain it with .send(). Recall how we used .send() during contract deployment. This makes sense because deploying the contract is also changing the state of the blockchain. You’ll get the transaction receipt as the response. The final function pay() is a function that accepts ether. Let’s see how we can do this using Web3. Contract.methods.pay().send({ from: accounts, gas: 470000, value:1000000000000000000 // in WEI, which is equivalent to 1 ether gasPrice:0 }) We still chain it with the send() function, but this time we include the value parameter in the object to be sent. This value has to be in wei, and not Ether. So do your conversions accordingly. But wait, what about payable functions that return a value? How do we return value but also send it some Ether? The answer is to use .send() first, and then .call(). That’s it! You’re now an expert in Web3 😛 Explore Chainstack Website: chainstack.comConsole: console.chainstack.com Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Eth2 and your DApps: What you need to know Do I as a DApp developer need to change my DApps and my DApp building routine and/or architecture? No. Your DApps are safe for at least a couple of years. A longer explanation The complete Ethereum 2.0—officially referred to as Eth2—implementation and mainnet is rolled out in phases: Phase 0 — launched on December 1, 2020 with the Beacon Chain. Phase 1 — tentative for 2021 with the introduction of shard chains. Phase 1.5 — tentative for 2021 or 2022 with the docking of Eth1 to Eth2. Phase 2 — no defined plans. Each of the phases introduces changes to Eth2 and how it interacts with Eth1 where your DApps are. Let’s have a look at each of the phases and if they can potentially make you change the way you work with your DApps. Will anything change for me after Phase 0 is initiated? No. A longer explanation On December 1, 2020, the Beacon Chain launched and marked the official start of Phase 0. Whereas the Beacon Chain is the foundational component of Eth2, it’s not the full Eth2 implementation. With the launch of Phase 1, the Beacon Chain will start validating shard chains. Until then, the Beacon Chain is a network of stakers validating blocks on the chain. The Beacon Chain itself cannot handle Ethereum accounts and smart contracts. Accounts and smart contracts can only be done on shard chains, and even that won’t be immediately available in Phase 1. The Beacon Chain consists of Beacon nodes and Validator clients. To just keep an up-to-date copy of blocks on the Beacon Chain, you need a Beacon node. To be a validator on the Beacon Chain, you need both a Beacon node, a validator client, and an Eth1 node. The Beacon node connects to the Eth1 node to monitor the Eth2 staking deposit address on Eth1 for new validators on the Beacon Chain. The Eth1 mainnet itself is completely “unaware” of the existence of Eth2 in the form of Beacon Chain. Architecturally, your existing DApps or your DApp building routine won’t see changes during Phase 0. Will anything change for me after Phase 1 is initiated? No. A longer explanation At some point in 2021, Eth2 will see the introduction of shard chains—the proof-of-stake chains running in parallel and coordinated by the Beacon Chain. The Beacon Chain will be assigning validators to the shard chains and will also keep the shards up-to-date with each other. The shard chains will first be introduced as version 1. In version 1, the shards will not be capable of executing smart contracts; they will only store the data necessary to execute smart contracts—for example, time stamps, oracle data, byte information required to interact with other shards. Version 2—when or if introduced—will see the execution of smart contracts on the shards. Architecturally, your existing DApps or your DApp building routine won’t see changes during Phase 1. Will anything change for me after Phase 1.5 is initiated? No, but your DApps will start responding faster, since this is when Eth2 will presumably be locked to 12 second blocks. You won’t have to change in your smart contracts, but the centralized parts of your DApps—e.g., a web app—will be fetching a quicker response to your users. A longer explanation In 2021 or 2022, the Eth1 mainnet will switch from the current proof-of-work to the proof-of-stake consensus algorithm and will be “docked” into Eth2. The process of docking, in this case, means that the Eth1 mainnet will become one of the shards of Eth2 coordinated by the Beacon Chain. Architecturally, your existing DApps or your DApp building routine won’t see changes during Phase 1.5. Will anything change for me after Phase 2 is initiated? Yes, but what exactly will change is uncertain at this point. A longer explanation As of today, Phase 2 is not clearly defined, however this is when you might see the most changes affecting you as a DApp developer as it may have the introduction of a new Ethereum Virtual Machine. Your existing DApps and your DApp building routine will see significant changes during Phase 2. However, at this point, there is no defined strategy on how you can be prepared for the changes other than staying up-to-date with the Eth2 developments and being a Chainstack user. With Chainstack, you will be prepared for Phase 2 with as little effort from you as possible—the infrastructure migration will be as seamless as viable, you will be notified of the necessary changes on your end well in advance and be supported by our extensive documentation. Run an Eth1 node for your Eth2 client today Run a reliable dedicated Eth1 node that you can link to your Beacon node. Get early access to Eth2 nodes Contact us to get an early access to Eth2 nodes. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ethereum Beacon API guide: consensus-layer data explained TL;DR Ethereum runs as two layers. The execution layer handles transactions, smart contracts, and balances, and you read it with JSON-RPC. The consensus layer handles proof of stake: validators, block proposals, and finality. The Beacon API is the REST interface for reading that consensus-layer data, and this guide covers what it is, the endpoints you’ll actually use, and how to read them safely in production. The one thing to get right is which point in the chain you read from. Data at the tip can still change, while finalized data won’t. That single choice keeps production systems from acting on data that later gets reversed. Why the Beacon API exists Before September 15, 2022, Ethereum was one chain with one interface. You ran a node, you talked to it over JSON-RPC, done. The Merge changed that. Ethereum retired proof-of-work mining and moved consensus onto a separate proof-of-stake chain called the Beacon Chain. The old chain became the execution layer. The Beacon Chain became the consensus layer. A node now runs two clients side by side: an execution client and a consensus client. (For the full history, here’s a step-by-step explainer on the Merge.) So the interfaces split too. The execution layer kept JSON-RPC, which answers questions about accounts and transactions: a balance for an address, a receipt for a transaction hash, the result of a contract call. Consensus data has no addresses or transaction hashes at all. It’s organized by validator, slot, epoch, and checkpoint, so it has its own REST API: the Beacon API. How the Beacon API works The Beacon API is the standard HTTP interface to a consensus-layer node. It’s defined in the open ethereum/beacon-APIs specification, which every major client implements the same way. It works differently from JSON-RPC. JSON-RPC sends a POST with a method name and a params array to a single endpoint. The Beacon API gives each resource its own URL, and you fetch it with GET: GET /eth/v1/beacon/genesis GET /eth/v1/node/syncing GET /eth/v1/beacon/states/finalized/finality_checkpoints Responses are JSON, with the payload under a data key. Large endpoints (full blocks, full states) also accept Accept: application/octet-stream to return SSZ, a compact binary encoding that’s faster to transfer and parse. JSON is the default and what you’ll use most of the time. The words you need first A few consensus terms show up in almost every response. Quick definitions: Slot: a 12-second window in which one validator can propose a block. Some slots stay empty. Epoch: 32 slots, about 6.4 minutes. Validator duties and finality are organized by epoch. Validator: a participant that staked at least 32 ETH to help run consensus. There are close to 1 million of them. Attestation: a validator’s vote that a block is valid and sits at the head of the chain. Justified, then finalized: a checkpoint that enough validators vote for becomes justified, and once a later checkpoint builds on it, it becomes finalized. Finalizing takes about two epochs, roughly 13 minutes. Finalized blocks are treated as permanent, for reasons we’ll get to in Reading consensus data safely in production. Most of the endpoints below are just these concepts in JSON. How a Beacon API request is shaped Every Beacon API path follows one pattern: /eth/v{version}/{namespace}/{resource}/{identifier} Learn it once and the whole API gets predictable. The main namespaces beacon: the chain itself. Blocks, states, validators, attestations, blobs. Where you’ll spend most of your time. node: health and sync status of the node you’re talking to. config: network constants and the fork schedule. validator: duties for validator clients, like who proposes a block and when. Mostly used by staking software. events: a live stream of chain events (covered below). debug: heavy state dumps for debugging. Expensive to serve, so keep it off the public internet. rewards: per-block and per-validator reward and penalty breakdowns, served under /eth/v1/beacon/rewards/…. State and block identifiers The {identifier} is where the Beacon API gets its precision. Instead of a block number, you pass a label that names a point in chain history: head: the latest block this node knows about. Fast, but can be reorged away. finalized: the latest finalized checkpoint. Settled. justified: one step before finalized — valid for state reads, but not accepted as a block identifier. a slot number, like 7500000. a 0x-prefixed block root or state root. So …/states/head/validators/… reads from the chain tip, while …/states/finalized/validators/… reads from settled state. The only thing that changed is the identifier, and it decides how much you can trust the result. The endpoints you’ll actually use A short tour. The examples use a Chainstack consensus endpoint, which has the shape https://beacon-nd-xxx-xxx-xxx.p2pify.com/AUTH_KEY/. Is the node ready to serve? curl https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY/eth/v1/node/syncing What’s finalized right now? curl https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY/eth/v1/beacon/states/finalized/finality_checkpoints A validator’s status and balance, the core of any staking dashboard: curl https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY/eth/v1/beacon/states/head/validators/123456 The response includes a status such as active_ongoing, active_slashed, exited_unslashed, or pending_queued, plus the validator’s balance. That’s most of a staking monitor in one call. The same request in JavaScript: ``` const BASE = "https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY"; const res = await fetch(`${BASE}/eth/v1/beacon/states/head/validators/123456`); const { data } = await res.json(); console.log(data.status, data.balance); ``` Streaming live data with the events endpoint Polling for new blocks wastes requests. The events endpoint is a Server-Sent Events stream: open one connection and the node pushes events as they happen. curl -N -H "Accept: text/event-stream" \ "https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY/eth/v1/events?topics=head,finalized_checkpoint,chain_reorg" The topics that matter most: head (a new chain head), finalized_checkpoint (a checkpoint just finalized), and chain_reorg (the head changed under you). An indexer subscribes to head to ingest blocks and to chain_reorg to know when to roll back. A bridge subscribes to finalized_checkpoint to catch the exact moment new state became irreversible. A long-lived stream like this needs an endpoint that holds the connection open without dropping it, which is one reason teams point this at a managed provider instead of a home node on a flaky connection. Worked example: reading a block’s blob data Blobs are the data that L2 rollups post to Ethereum (introduced by EIP-4844 in March 2024). A block references its blobs, but the blob data itself isn’t kept on-chain permanently. The consensus layer holds blobs for about 18 days, then prunes them. So the Beacon API is where you read blob data, and only within that window. The endpoint is blobs, keyed by a block identifier: curl https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY/eth/v1/beacon/blobs/head Pulling the blobs for a specific slot in JavaScript: ``` const BASE = "https://beacon-nd-123-456-789.p2pify.com/AUTH_KEY"; const slot = 7500000; const res = await fetch(`${BASE}/eth/v1/beacon/blobs/${slot}`); const { data } = await res.json(); for (const [index, blob] of data.entries()) { console.log(`blob ${index}: ${blob.length} hex chars`); // each entry is the raw blob data itself, a 0x-prefixed hex string } ``` Reading consensus data safely in production The same query can give a safe answer or a dangerous one depending on the identifier. Three habits keep you out of trouble. Read finalized for anything irreversible. A bridge that releases funds when it sees a deposit at head can lose money if that block reorgs. Reading at finalized costs about 13 minutes of latency and removes that risk, because reversing a finalized block is expensive by design. Finalizing a checkpoint takes a two-thirds majority of validators, so two conflicting blocks can only both finalize if at least a third of them vote for both. That double-voting is provable, and the protocol punishes it by destroying the offending validators’ stake, a penalty called slashing. A third of all staked ETH is millions of ETH, worth tens of billions of dollars, so in practice a finalized block never reverts. Match the identifier to the cost of being wrong: head for speed, finalized for anything you can’t undo. Check the execution_optimistic flag. Beacon API responses include a top-level execution_optimistic boolean. When it’s true, the node has accepted the block on the consensus side but hasn’t verified its execution payload yet, so the data can still change. Treat execution_optimistic: true as “not final, don’t act on it.” A companion finalized boolean in the response tells you whether the data came from finalized state. Filter the heavy endpoints. The full validator set and the debug namespace can each return hundreds of megabytes. Always pass indices, a status filter, or a specific slot. IdentifierWhat it meansUse it forheadLatest block, can reorgUI, live feeds, indexer ingestjustifiedOne step from finalityDiagnostics, rarelyfinalizedSettled, won’t revertBridges, exchanges, accountingslot / rootAn exact point in historyBackfills, audits, blob reads Getting a consensus-layer endpoint The Beacon API only exists if you have a consensus-layer node to talk to. Running one yourself means an execution client plus a consensus client, a fast 2 TB SSD (Geth and a consensus client together; more for an archive node), and an initial sync that can take a day or more before the node is usable. The shortcut is a provider. When you deploy an Ethereum node on Chainstack, you get both endpoints: the execution-layer JSON-RPC URL and the consensus-layer Beacon API URL, already synced. The Beacon endpoint is the beacon-nd-….p2pify.com URL used in the examples above, and every path is documented with runnable examples in the Beacon Chain API reference. For a staking dashboard or a bridge that only needs to read consensus data, that’s enough to start. Conclusion The Beacon API is how you read Ethereum’s consensus layer: validators, slots, attestations, and finality, served over plain REST. The path pattern is consistent, the namespaces are few, and most real work uses a handful of endpoints you can curl. Most production bugs trace to one choice: which identifier you read from. head is fast and reversible, finalized is slower and settled, and execution_optimistic tells you when even a recent answer isn’t safe yet. Pick the one that matches what happens if you’re wrong, and the rest is just HTTP. To use the Beacon API you need a consensus-layer node running alongside an execution client. Chainstack gives you both endpoints on the same Ethereum node deployment, already synced — the same beacon-nd-….p2pify.com URL used throughout this guide. Point your code at it and start querying. Deploy an Ethereum node → FAQ What is the Ethereum Beacon API? It’s the REST/HTTP interface to Ethereum’s consensus layer, the Beacon Chain. You use it to read validators, slots, epochs, attestations, finality checkpoints, and blob data. It’s a separate interface from JSON-RPC, which reads the execution layer (transactions, contracts, balances). How is the Beacon API different from Ethereum JSON-RPC? JSON-RPC is a single endpoint you POST method calls to, like eth_getBalance, and it returns execution-layer data. The Beacon API is REST: each resource has its own URL that you GET, and it returns consensus-layer data such as validators and finality. A full Ethereum node exposes both, because it runs both an execution client and a consensus client. What is the difference between the consensus layer and the execution layer? The execution layer runs transactions and smart contracts and tracks account balances. The consensus layer (the Beacon Chain) runs proof of stake: it selects who proposes blocks, collects validator votes, and decides finality. The Merge in September 2022 split these into two clients running inside one node. How do I check if an Ethereum block is finalized? Read /eth/v1/beacon/states/finalized/finality_checkpoints, or request your data at the finalized identifier instead of head. You can also watch the finalized_checkpoint topic on the events stream. Finalization happens about 13 minutes (two epochs) after a block is produced. What does execution_optimistic mean in a Beacon API response? It’s a boolean flag at the top level of the response. true means the consensus client accepted the block but hasn’t verified its execution payload yet, so the data can still change. Wait for execution_optimistic: false before acting on the response in anything financial. How do I get a validator’s status and balance from the Beacon API? Send a GET to /eth/v1/beacon/states/head/validators/{index}, using either the validator index or its public key as the identifier. The response includes the validator’s status (for example active_ongoing or active_slashed) and balance. Avoid requesting the full validator set unfiltered, since it has close to 1 million entries. How do I read blob (EIP-4844) data from a beacon node? Send a GET to /eth/v1/beacon/blobs/{block_id} for a block’s raw blob data. The older /eth/v1/beacon/blob_sidecars/{block_id} still works and adds each blob’s kzg_commitment, but it has been deprecated since the Fusaka upgrade (its kzg_proof field now returns empty). Blobs are pruned after about 18 days, so index anything you need for the long term. A block with no blobs returns an empty array, and some clients return 404 for that case. Can I subscribe to real-time consensus events? Yes. A GET to /eth/v1/events?topics=head,finalized_checkpoint,chain_reorg opens a Server-Sent Events stream that pushes events as they happen, so you don’t have to poll for changes. Do I need to run my own beacon node to use the Beacon API? No. You can run a consensus client yourself, or use a provider. Chainstack gives you a consensus-layer endpoint alongside the execution-layer one when you deploy an Ethereum node, already synced. What are slots and epochs in Ethereum? A slot is a 12-second window in which one validator can propose a block. An epoch is 32 slots, about 6.4 minutes, and it’s the unit consensus uses to organize validator duties and finality. Additional reading Ethereum nonce management Ethereum roadmap 2026: Impact on nodes & validators Best Ethereum RPC providers for production workloads in 2026 Ethereum Fusaka: Infra upgrade for real scaling #### Ethereum Fusaka: Infra upgrade for real scaling What’s new in the Ethereum Fusaka upgrade Ethereum is securely scaling with Fusaka, which brings a powerful upgrade, giving the entire ecosystem a major boost. It unlocks more space for rollups, introduces cleaner rules for infrastructure, improves data handling, and provides better tools for developers. Most of the action happens under the hood, but the ripple effects will be felt across the network as L2s and apps upgrade while the ecosystem begins taking advantage of Fusaka’s improvements. Ethereum’s Fusaka upgrade brings a hybrid, secure, and scalable approach to L1 and L2 enhancements, improving throughput, reliability, and developer experience without compromising decentralization. Before diving into the details, here’s what you should be familiar with. Prerequisites Basic understanding of Ethereum L1 and L2 architecture. Familiarity with Ethereum upgrades and EIPs. Key Features for Rollups, Infra & Builders PeerDAS & Blob Capacity Boost PeerDAS unlocks up to 8× more data availability, giving rollups far more room for posting data while keeping nodes lightweight. Fusaka increases the capacity for blobs per block, from 6 blobs/block after Dencun to 15 blobs/block with BPO-1 (activated) and further increases coming in January. Passkey & Hardware-Secure Signatures EIP-7951 introduces secp256r1 support, enabling device-native signing and passkeys. Wallets can use hardware security modules (HSMs) and FIDO2/WebAuthn directly, allowing smoother onboarding, easier recovery, and multi-factor flows that feel like modern apps on phones and laptops, with no seed phrases required. Cleaner, More Stable Infra Unified execution rules, predictable RLP block sizes, deterministic proposer scheduling, and eth_config auto-discovery simplifies operations for RPCs, sequencers, explorers, and client teams. Nodes become lighter, more reliable, and easier to scale, setting the foundation for smoother L2 growth and better developer experience. For Regular Web3 Users The impact unfolds gradually as L2s and wallet providers adopt the new capabilities. Over time, users will notice faster transactions, lower L2 fees, and more responsive apps. Mobile wallets will start supporting passkeys, fingerprints, and Face ID for secure, seamless logins without seed phrases, making onboarding and account recovery simpler than ever. The result is a smoother, more predictable Ethereum experience that feels closer to the ease and speed of modern consumer apps. Nothing changes in how people use Ethereum, but the network around them becomes more efficient and predictable. Over time, everyday activity feels faster, cheaper, and more stable. What is EIP-7607: Hardfork Meta – Fusaka EIP-7607, the Fusaka hardfork meta, is one of the most significant upgrades, bundling 13 EIPs into a hybrid upgrade for Ethereum. Fusaka improves data availability, increases blob capacity, stabilizes fees, and upgrades L1 execution limits, making Ethereum faster, cheaper, and more predictable for both everyday users and builders. Consensus Layer (“Fulu”, the star): Enhances L2 interoperability, allowing rollups to post data efficiently. Execution Layer (“Osaka”, a city in Japan): Simplifies developer deployment and node operation with better tooling and gas management. The upgrade has been activated on testnets such as Holešky, Sepolia, Hoodi, and mainnet, ensuring widespread client support and robust testing across environments. Validators, L2 operators, developers, and users will all feel the effects, lower fees, faster finality, and more reliable network behaviour, making Fusaka one of the most consequential upgrades in Ethereum’s history. Fusaka delivers changes across data availability, user experience, and L1 performance. Each area plays a role in making Ethereum faster and more reliable. The following sections explore each of these areas and what they unlock for the ecosystem. Data Availability EIP-7594: PeerDAS – Peer Data Availability Sampling PeerDAS (Peer Data Availability Sampling) is a core EIP that enables Ethereum nodes to perform DAS by downloading only a subset of data. Before Fusaka, each node downloaded the full blob to verify availability. This limited Ethereum’s blob throughput, often causing high blob fees for rollups during periods of congestion. PeerDAS introduces a major improvement by splitting blob data into columns (hence, the zebra mascot, representing the striped column-based data availability sampling) and distributing them uniformly across the network. Each node downloads only 1/8th of the blob data at random. Since no single node ever needs to download the full blob, running a node becomes significantly lighter and more accessible. EIP-7892: Blob Parameter Only Hardforks BPO (Blob Only Parameters) hardforks allow incremental, safe scaling of Ethereum’s data availability (DA) layer. All L2s depend on the DA layer, and as these networks expand, they require more data availability. To accommodate this growing demand, Ethereum increases the number of blobs per block, providing continuous and predictable scaling for the L2 ecosystem built on top of Ethereum. BPO hardforks provide continuous scaling with a gradual increase in the number of blocks per block by modifying only blob-related parameters: target, max and baseFeeUpdateFraction through config, without requiring any client-side changes. Blobs were introduced in the Dencun upgrade with a target of 3 blobs per block. The Pectra upgrade subsequently doubled this capacity to 6 blobs per block, and with Fusaka, Ethereum now supports gradual, controlled increases in blob capacity, allowing the network to scale securely and predictably in line with L2 demand. Source: Dune With the recent activation of BPO-1, blob capacity has already increased to 15 blobs per block. BPO-2 is scheduled to be activated in January. More room for rollups.BPO-1 activated yesterday, raising blob capacity to 15 per block. This increased space on Ethereum for L2s without needing a hard fork.BPO-2, which will further increase capacity, comes online in January. pic.twitter.com/upLF8Sa1YU— Ethereum Foundation (@ethereumfndn) December 10, 2025 Source: @ethererumfndn via X EIP-7918: Blob base fee bounded by execution cost EIP-7918 pins a proportional reserve price BLOB_BASE_COST * base_fee_per_gas to blobs by introducing an if-clause in calc_excess_blob_gas() under every blob. When this reserve price exceeds GAS_PER_BLOB * base_fee_per_blob_gas, the function stops subtracting target_blob_gas and lets excess_blob_gas increase strictly according to blob_gas_used, while keeping the per-block maximum increase unchanged. The result is a more stable, predictable blob pricing mechanism that continues to function even as L2 throughput increases with PeerDAS and BPO upgrades. In summary, PeerDAS (7594): reduces node load, improves sampling efficiency BPO (7892): allows incremental blob scaling Blob Base Fee Bound (7918): ensures predictable costs Impacts: Node operators: Reduced load and faster synchronization due to PeerDAS sampling. L2 networks & rollups: Greater, predictable blob capacity enables higher throughput and reliable data posting on Ethereum. Users & dApps: More stable and lower L2 fees with faster transaction finality. Together, these upgrades allow Ethereum to scale securely, unlocking up to ~8× more DA capacity without compromising decentralization or security. UX Improvements EIP-7951: Precompile for secp256r1 Curve Support EIP-7951 adds on-chain support for the secp256r1 (NIST P-256) elliptic curve, widely used in WebAuthn, FIDO2 devices, and enterprise security systems. Until now, Ethereum only handled secp256k1 and BLS12-381, meaning developers had to rely on off-chain verification or expensive custom contracts to work with P-256 signatures. This precompile brings fast, low-gas verification directly into the EVM. This EIP introduced a functionality to efficiently perform ECDSA signature verification over the secp256r1 elliptic curve (also known as P-256 or prime256v1) at the fixed address 0x100. This precompile enables native support for signatures generated by modern secure hardware including Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices. This unlocks the usage of secure hardware devices, non custodial wallets and applications can natively verify signatures from secure hardware like smartphones, fingerprint/Face ID sensors, and hardware security modules. Users can interact with Ethereum dApps using familiar, secure authentication methods without depending on third-party relays or custodial solutions. This EIP essentially bridges modern authentication standards with Ethereum smart contracts, making non-custodial wallets more user-friendly and enterprise adoption smoother, all while preserving strong cryptographic security Impacts: App & DeFi developers: Can integrate WebAuthn/FIDO2 authentication natively in contracts. Wallets: Enable smoother onboarding and secure hardware-based authentication. Enterprise: Leverage industry-standard cryptography for blockchain solutions. Users: Secure, seamless, self-custodied access using modern authentication devices. EIP-7910: eth_config JSON-RPC Method A Meta EIP introduces a unified eth_config RPC call that lets applications query a node’s current configuration: chain ID, fork rules, EVM revision, blob parameters, and more, all from one endpoint. Instead of hardcoding chain assumptions, developers can fetch them dynamically, reducing mismatches and configuration errors across L1, L2s, and testnets. Impacts: App & DeFi developers: Expect fewer config mismatches across mainnet, L2s, and testnets. Use eth_config at app startup to automatically configure chain rules. Rollups & L2 infra teams: Can dynamically adjust sequencers, verifiers, and gas models without redeploying contracts or manually editing config files. Explorers & Tooling: Improved multi-chain support with consistent metadata pulled from the node itself. EIP-7939: Count leading zeros (CLZ) opcode EIP-7939 adds a new built-in EVM opcode called CLZ, which returns how many zeros appear at the front of a 256-bit value. This is a very common low-level operation used in cryptography, Merkle tries, hashing, and many math operations but until now, developers had to simulate it manually with loops or binary-search logic, which costs a lot of gas. By introducing CLZ as a single native opcode, the EVM can compute this result instantly and cheaply. This makes many protocol-level operations faster, more predictable, and less gas-heavy, especially for L2s and zk systems that depend on precise bit manipulation. Solidity and other EVM compilers will add direct support for CLZ in upcoming releases. Once they do, contracts that depend on leading-zero calculations can become cheaper automatically at compile time. Developers simply need to update to newer compiler versions and review release notes to understand where gas reductions apply. EIP-7917: Deterministic Proposer Lookahead EIP-7917 gives the beacon chain a fully deterministic view of next-epoch block proposers. Instead of relying on balances that may change mid-epoch, the proposer list is precomputed and stored directly in the beacon state. This eliminates unpredictable edge cases where validator balances could alter the proposer schedule. With the next epoch’s proposers known in advance, preconfirmation protocols, builders, validators, and relays gain stable coordination, predictable rotations and fewer last-minute proposer surprises. Scaling L1 EIP-7823: Set upper bounds for MODEXP & EIP-7883: ModExp Gas Cost Increase EIP-7823 introduces hard upper bounds on input sizes for MODEXP, preventing transactions from submitting extremely large parameters that could lead to long execution paths or unpredictable resource usage. This ensures that even in complex cryptographic workloads, MODEXP remains bounded, auditable, and safe for clients to process. EIP-7883 adjusts the gas schedule for MODEXP to better reflect its true computational cost. By increasing gas for expensive parameter ranges, the EVM aligns pricing with real-world execution effort, discouraging pathological input patterns and reducing DoS vectors. Together, these changes make MODEXP more predictable for node operators, safer for block builders, and more reliable for applications that rely on modular exponentiation, especially rollups, verification systems, and protocols performing heavy cryptographic operations. Contracts that depend on EIP 7883 will consume more gas for execution. If your contract relies heavily on this and becomes more expensive for users, reconsider how it’s utilized. EIP-7825: Transaction Gas Limit Cap & EIP-7935: Set default gas limit to 60M EIP-7935 proposes raising Ethereum’s default block gas limit toward ~60M, increasing total execution capacity per block and enabling higher throughput during Fusaka. Larger blocks, however, naturally increase the amount of work nodes must verify, which makes the behaviour of individual high-gas transactions more important for network stability. EIP-7825 sets a strict per-transaction cap of 16,777,216 gas, ensuring no single transaction consumes disproportionate resources as block limits rise. Together, they can create a controlled path for execution-layer scaling: more room for transactions overall, but bounded per-transaction complexity to preserve stability, fairness, and predictable validation across clients. The network gains higher throughput without exposing itself to single-transaction DoS risks or extreme state-growth spikes, making Fusaka’s higher gas-limit regime feasible and safe. EIP-7934: RLP Execution Block Size Limit EIP-7934 introduces a protocol-level cap on the RLP-encoded execution-block size, aligning the execution layer with the consensus layer’s gossip constraints. Clients define: MAX_BLOCK_SIZE = 10,485,760 bytes (10 MiB) SAFETY_MARGIN = 2,097,152 bytes (2 MiB reserved for beacon-block framing) MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN Any execution block whose RLP payload exceeds MAX_RLP_BLOCK_SIZE is rejected. This is a byte-level propagation limit, not a gas-accounting change. It constrains the maximum amount of encoded block data transmitted across the network, preventing execution blocks from exceeding the CL gossip threshold (~10 MiB) and eliminating scenarios where a block is valid for execution but too large for consensus propagation. EIP-7642: eth/69 – history expiry and simpler receipts EIP-7642 cleans up the Ethereum networking protocol by dropping handshake fields that became obsolete after the Merge. These fields were carried forward for compatibility but provided no functional value, increasing complexity in peer discovery and node communication. By removing them, clients ship with a leaner networking layer: fewer conditional checks, lower handshake overhead, and a reduced attack surface. This is especially impactful for embedded devices, light clients, and high-volume infrastructure nodes where efficiency compounds quickly. Conclusion Fusaka demonstrates Ethereum’s evolution as a secure, scalable, and developer-friendly blockchain. By combining L1 and L2 upgrades, optimized data availability, enhanced gas management, and developer-centric tooling, Ethereum now supports higher throughput without compromising decentralization. Looking ahead, Fusaka lays the foundation for: Further incremental scaling via Blob Parameter Only hardforks. Improved UX with hardware wallet integration and modern authentication. Predictable transaction costs and safer network operation. Running your own Ethereum node is essential for reliable access to the upgraded network. Chainstack makes this simple, you can deploy fully managed Ethereum nodes in minutes, ensuring access to the latest features, RPC methods, and network data. Ethereum continues to grow as a platform for secure, permissionless innovation, maintaining a balance between decentralization, usability, and high-performance L2 interoperability. Ethereum is scaling securely. Reliable Ethereum RPC infrastructure Getting started with Ethereum on Chainstack is fast and straightforward. Developers can deploy a reliable Ethereum node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Ethereum RPC access, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Ethereum low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Ethereum RPC endpoint, and experience how easy it is to build and scale on Ethereum with Chainstack – one of the best RPC providers. Deploy Ethereum Node Now #### Ethereum nonce management: preventing stuck transactions TL;DR In production, one stuck transaction doesn’t just fail — it freezes every transaction that was supposed to come after it from the same account. Ethereum nonce management is what keeps that from happening at scale. This happens because transactions from one account have to be processed in strict order, so a single blocker holds up everything queued behind it. Keeping the line moving sounds simple, but doing it safely at scale is not: you have to track order yourself, coordinate senders that would otherwise step on each other, tell the difference between stuck and merely slow, and clear the blocker without making things worse. This article walks through those pieces and the traps that show up between them. Intro In EVM: Practical explanation of how gas fee works we saw why a single transaction gets stuck: if the priority fee you offered validators is too low, the transaction sits in the mempool and eventually times out. That’s annoying when it happens once. In production, it’s a lot worse. That’s why robust ethereum nonce management starts before you ever send a transaction. Imagine a backend that signs and broadcasts transactions all day — a market maker, a bridge filler, an oracle updater, a payout service. Now imagine one of those transactions gets stuck. The next one you send from the same account won’t land either. Neither will the one after that. The symptoms pile up fast: receipts that never arrive, retry loops that keep signing new transactions on top of the blocked one, queues that grow without bound, and on-chain state that drifts from what your service thinks it has done. Your entire pipeline has frozen while still looking busy. This article walks through how ordering actually works, why the naive approach breaks at scale, how to build a local tracker that stays consistent under load, and how to detect and replace stuck transactions without making things worse. We’ll also cover two shifts worth knowing about — private mempools and L2 sequencers — that change what “stuck” even means. What is a nonce, and why does one stuck tx block all the others? Every transaction from an Ethereum account carries a nonce — a counter that starts at zero and goes up by one every time that account sends a transaction. The network enforces a strict rule: a transaction with nonce N cannot be included at an earlier position than the transaction with nonce N-1. No gaps, no reordering. This is what makes the stuck-transaction problem so bad at scale. If your service has sent nonces 42, 43, 44, 45, and 46, and nonce 42 is stuck because it was underpriced, then 43 through 46 are also stuck. They’re not “slow” — they’re literally unminable. Block builders will look at them, see the missing 42, and ignore all of them. This is called a nonce hole. The fix is not to bump nonce 46; it’s to fulfill nonce 42. If you remember only one thing from this article, make it that: always fix the oldest stuck transaction first. Why asking the node for the next nonce doesn’t scale The obvious way to get the next nonce is to ask the node: eth_getTransactionCount(address, "pending"). This returns the account’s nonce including everything already in that node’s mempool. Done, right? Two problems. First, the “pending” view is a per-node thing. Different nodes can disagree on what’s in the mempool. Some transactions haven’t propagated yet, some have expired, some came in through private routes that bypass the public mempool entirely. If you send a transaction through a private relay and then query a different RPC for the pending nonce, the private transaction won’t be counted. The next nonce you use will collide. Getting consistent reads from a reliable provider like Chainstack reduces this drift, but no single node ever sees everything. Second, and worse, is the concurrency trap. When two workers ask for the pending nonce at the same time, they both get the same number. They both sign a transaction with it. One gets accepted; the other either fails with a replacement transaction underpriced  error, or silently overwrites the first one. Here’s the anti-pattern in code, which you should not copy into production: // BAD — race-prone const nonce = await provider.getTransactionCount(wallet.address, "pending"); await wallet.sendTransaction({ ...tx, nonce }) Under single-worker load this works. The first time you send two transactions concurrently, it stops working. Local nonce management: the foundation The fix is to maintain one source of truth for each signing account — an in-process counter, serialized access, and a single path for reconciling with chain state. Here’s a minimal tracker in ethers v6: class NonceTracker {   constructor(provider, address) {     this.provider = provider;     this.address = address;     this.next = null;     this.lock = Promise.resolve();   }   async reserve() {     const prev = this.lock;     let releaseNext;     this.lock = new Promise(r => (releaseNext = r));     await prev;     if (this.next === null) {       this.next = await this.provider.getTransactionCount(this.address, "pending");     }     const n = this.next++;     releaseNext();     return n;   }   reset(n) { this.next = n; } } The chained-promise pattern serializes reserve() calls so concurrent callers line up instead of racing. The first call bootstraps from the chain; every subsequent call just increments. If a send fails, the caller must call reset(failedNonce) so the next send reuses that slot instead of leaving a gap. A few rules for making this production-safe: Persist next somewhere durable. A crash mid-send will desync the counter from the chain. On boot, take the max of the persisted value and getTransactionCount(..., "pending"). Do not share a signing key across processes without an external lock. If you must, a single dedicated signer service is simpler and safer than scattering Redis locks around. Respect the per-account mempool cap. Ethereum nodes cap how many transactions one account can have sitting in the pool — roughly 16 in the pending sub-pool and ~64 more in the queued sub-pool as typical defaults. Overflow doesn’t vanish instantly; it either waits in the queued area for a missing nonce or gets evicted under global price pressure when the whole pool is full. The practical takeaway is to avoid holding a large backlog of pending transactions per account — the more you keep in flight, the closer you get to these limits and the higher the chance of losing transactions you thought were safely queued. Confirm what you send before piling on more. Detecting and replacing a stuck transaction Sending is half the job. The other half is noticing when something didn’t land and doing something about it. The detection pattern is a polling loop with a timeout — tx.wait(1, timeoutMs) in ethers, or equivalent receipt polling. If a transaction hasn’t mined within, say, 30–60 seconds on L1 (much less on an L2), treat it as stuck and replace it. Replacement has strict rules. The new transaction must have the same nonce and both maxFeePerGas and maxPriorityFeePerGas at least 10% higher than the original. Raising only one of the two is not enough — the node will reject the replacement with replacement transaction underpriced before it even enters the mempool, and the original stays stuck. Both values have to clear the 10% bar, otherwise the attempt is simply discarded and you’re back where you started with the same blocker in place. A speed-up in ethers: const bumped = {   to: original.to, value: original.value, data: original.data, nonce: original.nonce,   maxFeePerGas:         (original.maxFeePerGas         * 12n) / 10n,   maxPriorityFeePerGas: (original.maxPriorityFeePerGas * 12n) / 10n, }; await wallet.sendTransaction(bumped); A cancel is the same pattern with the payload cleared — a zero-value self-send at bumped fees: await wallet.sendTransaction({   to: wallet.address, value: 0n, data: "0x", nonce: original.nonce,   maxFeePerGas:         (original.maxFeePerGas         * 12n) / 10n,   maxPriorityFeePerGas: (original.maxPriorityFeePerGas * 12n) / 10n, }); Escalate in steps (1.2×, 1.5×, 2×) with a hard ceiling; above that, alert rather than keep burning. The receipt of either the original or the replacement settles the nonce — whichever lands first, your tracker’s next slot is free. Skipping the public mempool: private routes As we mentioned previously, many production services don’t use the public mempool at all. That’s worth unpacking, because it changes how you manage nonces too. Private relays — Flashbots Protect, MEV-Share, direct builder endpoints — accept your signed transaction and forward it straight to block builders. Nothing shows up in the public mempool, so front-running and sandwich bots can’t see it. For any value-sensitive send (DEX trade, liquidation, arb), skipping the public mempool is the default choice today — sending through it leaks your intent to bots that will reorder or copy your trade before it lands. What actually gets that private transaction onto the chain is MEV-Boost. Post-Merge, validators don’t build their own blocks anymore — most of them run MEV-Boost as a sidecar that accepts a fully-formed block from an outside builder (via a relay) and signs whichever one pays the most. Builders are the ones reading private-relay flow, Flashbots bundles, and the public mempool, packing them into a block, and competing on tip. The relay’s job is to hand the builder’s block to the validator without either side seeing the other’s full payload until the validator has committed to it. The nonce-management consequence is the one we already flagged: a private transaction only lands if some MEV-Boost-connected builder picks it up and wins the auction for a slot. If your bundle isn’t profitable, if the relay filters it, or if the winning builder for that slot ignored your route, the transaction just sits there — no mempool entry, no revert, no signal. Your detection-and-replace loop is the only thing that will notice. There’s a subtle nonce issue worth knowing. If you submit a transaction through Flashbots Protect and then ask the Flashbots RPC for your pending nonce, it will not include that private transaction — unless you EIP-191-sign the JSON-RPC payload and include it in an X-Flashbots-Signature header. Without that signed request, the RPC returns a nonce that ignores your in-flight private transaction, so the next one you sign reuses the same slot and collides. This is exactly the kind of cross-system inconsistency a local tracker sidesteps: if your own counter is the source of truth, you never have to ask. Private routes don’t remove the need for nonce discipline. A private transaction occupies the same nonce slot as a public one, and it can still get stuck — if no builder picks it up, it just sits there, invisibly. Detection and replacement are still your problem. Chainstack’s protected transaction endpoints plug into this same flow and let you keep your existing monitoring in place. L2 nonces: sequencer-based chains Rollups like Arbitrum, Base, and Optimism run a centralized sequencer that orders transactions. Per-account nonces still apply, and the cascade rule is identical — one stuck tx blocks all subsequent ones from the same account. The differences are in the failure modes. Inclusion on a healthy L2 is sub-second, so “stuck” is rare when fees are set correctly. The sequencer is the new single point of failure: if it’s down or censoring, nothing mines for anyone. Treat sequencer uptime as a first-class health signal; Chainlink publishes L2 sequencer uptime feeds specifically for this. The escape hatch is force inclusion. Both Arbitrum and the OP stack let you submit a transaction directly to the L1 inbox; the sequencer is then required to include it. Optimism and Base honor these near-immediately; Arbitrum enforces a sequencer-delay window of around 24 hours before the force is granted. Slow, but censorship-resistant. Your nonce tracker and replacement logic carry over unchanged. Tighten the stuck-tx timeout to seconds and wire sequencer health into your alerts. Conclusion A quick checklist to take into production: One nonce source of truth per account. Never call getTransactionCount on the hot path. Serialize sends per account with an in-process lock; consolidate to one signer service across processes. Monitor receipts with a timeout, and always fix the oldest stuck transaction first. Respect the per-account mempool cap; throttle or shard signing keys before you hit it. Use private routes for MEV-exposed sends; watch L2 sequencer health. Build vs buy: ethers’ built-in NonceManager gives you local sequencing but no re-broadcast or fee escalation, so you’re still on the hook for detection and replacement. A managed relayer like OpenZeppelin Defender ships the full loop — atomic nonce assignment, gas re-estimation, automatic resubmission — and is often cheaper than rolling your own. Either way, all of it rests on the RPC underneath; consistent pending reads, stable websocket streams, and private transaction endpoints from a reliable provider like Chainstack are what stop nonce drift from compounding in the first place. Getting started on Chainstack The NonceTracker above assumes what’s underneath it is reliable — consistent pending reads, stable WebSocket streams for receipt polling, and private transaction support when you need to skip the mempool. That’s what Chainstack’s global RPC infrastructure is built for. Chainstack supports Ethereum mainnet, all major L2s (Arbitrum, Base, Optimism), and private transaction endpoints — so your nonce management strategy and your RPC layer can scale together. Start building on Chainstack → FAQ What is a nonce in Ethereum, and why does it matter?  A nonce is a per-account counter that increments by one with every transaction an address sends. Ethereum requires transactions from the same account to be included in strict nonce order with no gaps, which is why a single underpriced or dropped transaction can freeze every later transaction from that account until it is mined or replaced. How do I cancel or replace a stuck Ethereum transaction?  Resend with the same nonce and both maxFeePerGas and maxPriorityFeePerGas raised by at least 10%. To cancel, use the same nonce with a zero-value self-send and empty data at the bumped fees. Raising only one of the two fee fields gets rejected with replacement transaction underpriced, and the original stays stuck. Does sending through Flashbots Protect affect nonce tracking?  Yes. A private transaction occupies the same nonce slot as a public one and can still get stuck if no builder picks it up. The Flashbots RPC will not return your in-flight private nonce unless the request is EIP-191-signed with an X-Flashbots-Signature header — a strong argument for treating a local tracker, not the RPC, as the source of truth What happens if two workers try to send from the same account simultaneously? Both workers will read the same pending nonce and sign transactions with the same slot. One will be accepted; the other will either fail with replacement transaction underpriced or silently overwrite the first, depending on fee levels. The fix is serialized access — a single in-process lock or a dedicated signer service per account. How many pending transactions can one Ethereum account have in the mempool? As of current Geth/Reth defaults, roughly 16 transactions in the pending sub-pool and ~64 more in the queued sub-pool per account. Exceeding these limits means transactions are either held in the queued area (waiting on a nonce gap to close) or evicted entirely under global mempool pressure. Verify the exact figures against the Geth or Reth release notes for your node version before deploying. Do L2 nonce rules work the same as Ethereum mainnet? Yes — per-account nonces and the cascade-blocking rule are identical on Arbitrum, Base, and Optimism. The main differences are timeout sensitivity (stuck is “seconds” not “minutes”) and the failure mode: instead of mempool congestion, you’re watching for sequencer downtime or censorship. Use Chainlink’s L2 sequencer uptime feeds as a health signal, and know your force-inclusion escape hatch for each chain. Additional resources Ethereum core references EIP-1559: Fee market change — official specification Ethereum JSON-RPC API — eth_getTransactionCount Geth mempool transaction pool documentation Related Chainstack articles EVM: Practical explanation of how gas fee works How to get an Ethereum RPC endpoint Ethereum roadmap 2026: Impact on nodes & validators Best Ethereum RPC providers in 2026 #### Ethereum privacy in 2026: validators and confidential EVMs In July 2026, the Ethereum Foundation spun out EthSystems as a for-profit organization focused on institutional privacy. A week earlier, Vitalik Buterin published The Extremely Lean Chain, a proposal that redesigns Ethereum consensus around validator anonymity. Two moves, three weeks apart, one direction — privacy is now a first-class Ethereum problem. These two announcements target different problems for different users. Validator anonymity is a protocol-layer answer for decentralization and staker safety. EthSystems and confidential EVMs like Oasis Sapphire are application-layer answers for institutions that need to protect trading positions, payment flows, and settlement details. This article walks through both. Ethereum, the second-most popular blockchain, is adopting new privacy standards that meet these expectations at both the consensus and data layers. One major component focuses on the privacy of the identities of those securing the blockchain, specifically validators, or nodes responsible for validating transactions on the network.  Vitalik Buterin, the primary co-founder of Ethereum, recently published The Extremely Lean Chain, highlighting how Ethereum can improve decentralization through privacy. To reduce the risk of collusion or third-party influence in validating transactions, the identities of validators are untraceable and distinguishable by rotating their identifiers daily and using cryptographic schemes to prove account balances without linking them to identities. If we want to make the Lean Ethereum consensus chain aggressively more "lean", and add strong validator privacy (ZK-unlink deposit from staking activity from withdrawal, and re-anonymize stakers every day), here is a path:https://t.co/Gdee7tE53R— vitalik.eth (@VitalikButerin) July 6, 2026 An X post where Vitalik Buterin announces The Extremely Lean Chain, emphasizing technical efficiency and leaness, and strong validator privacy In addition to the privacy of validators, those that secure the chain, the Ethereum ecosystem is seeing a push in privacy tools.  In July 2026, the Ethereum Foundation Institutional Privacy Task Force founded EthSystems, a for-profit organization focused on building privacy infrastructure for institutions. Newly launched Ethereum Virtual Machine (EVM)-compatible chains are providing complete privacy to blockchain users. Unlike public blockchains, these blockchains enable end-to-end encryption of the blockchain state, appealing to institutions that want to protect user privacy and maintain a competitive advantage by keeping transaction data completely confidential. On such new chains, such as Oasis Sapphire, developers can deploy private smart contracts that keep smart contract data confidential. An ecosystem map of new blockchains that offer confidential smart contracts. Source: Kaffchad on X Privacy on the blockchain is not a paradox; it is essential to its core values and adoption. Validator privacy supports decentralization, while blockchain state privacy builds trust among institutions and their millions of users. Why privacy matters (to institutions) Institutions such as banks, governments, and funds expect blockchains to meet privacy standards, despite their public nature, to protect users’ identities and preserve the competitive advantages they are accustomed to in traditional finance. Adoption of crypto amongst institutions The adoption of cryptocurrency and blockchain amongst institutions has grown significantly since the passage of the GENIUS Act in July 2025, which provided the first comprehensive regulatory framework for stablecoins in the United States. Institutions are using crypto to hedge against inflation and to provide more investment options and faster settlement for their customers. As of January 2026, more than 2,000 U.S. advisory firms have allocations in crypto ETFs. 18% of financial institutions and corporations globally use stablecoins, including Visa and Western Union. Nearly 770 million USD has flowed into Bitcoin and Ethereum ETFs in the past three months, as of July 2026. Institutional investment in crypto is expected to grow, increasing demand for blockchain privacy. Privacy requirements for institutions Institutions are not seeking complete privacy of transaction data but are primarily concerned with preventing the disclosure of their trading data to competitors and with preventing data leaks that could compromise the blockchain’s security. Institutions are less interested in private cryptocurrencies in which user identities and transaction data are completely untraceable, because they must still comply with anti-money-laundering and know-your-customer regulations. Instead, with a public blockchain, they are most concerned with the risk of revealing their daily deposit amounts, payment flows, positions, and the customers involved in large transactions, allowing competitors to analyze this data. Several institutional privacy use cases include: Private bonds: the issuance of bonds and bond trading where volumes, prices, and positions must remain confidential to prevent other firms from front-running each other and exposing strategies. Private payments: payment transfers in which transaction details that could reveal business relationships, purchasing behavior, and financial health are kept confidential. Private commodities: trading details should remain confidential to prevent disclosure of position sizes, trading strategies, and physical delivery arrangements. Any blockchain that provides the infrastructure to support use cases must also remain completely secure against attacks that could lead to the loss of user funds. One key area is ensuring the privacy of stakeholders’ identities on the blockchain to prevent any collusion, third-party influence, or targeted hacks. Specifically, the privacy of validators, the nodes that are responsible for validating transactions and securing the blockchain, is crucial to ensuring valid transactions are approved. How to make the blockchain private Ethereum is adopting new privacy standards that address these use cases at the consensus level through validator privacy and at the infrastructure level through new tools and smart contracts. Validator privacy Vitalik Buterin’s proposal, The Extremely Lean Chain, outlines a design in which validators no longer have a permanent, trackable identity. Instead, they will have a daily rotating identity, and cryptographic schemes can be used to verify their eligibility as validators without revealing their previous identities. At present, each validator is identified by an index and a permanent public key, which can be looked up to see their Ethereum staking amount and staking income in an explorer similar to this one: An example of a validator leaderboard ranked by staking income, listing each validator’s index and public key. In Vitalik’s proposal, to remain active as a validator, the validator would need to declare and prove an effective or approximate balance daily, based on its previous balance, using a ZK-STARK, a type of zero-knowledge cryptographic proof designed to be scalable and not require an initial setup phase. In this same process, each validator would rotate or change their index and public key from a fixed seed. For outside parties, the ZK-STARK shows only the validator’s balance change since the last proof (probably the day before) and whether it has been slashed, making it unlikely that the validator’s identity can be traced from indexes and keys. Any staking withdrawals from the validator require an additional ZK-STARK that is not tied to the daily balance change proof ZK-STARK. Because the withdrawal ZK-STARK must include an exact balance to verify the withdrawal, two cryptographic proofs guarantee that a validator’s identity cannot be traced through the effective and exact balances. Such a design provides stronger guarantees that validators and their staking and withdrawal amounts remain untraceable, thereby enabling broader onboarding of institutional validators seeking to protect their competitive advantage. New privacy infrastructure for institutions on Ethereum via EthSystems Developers and institutions can also expect new privacy infrastructure for institutions with the launch of EthSystems. In July 2026, the Ethereum Foundation’s Institutional Privacy Task Force spun out into EthSystems, a for-profit organization dedicated to building privacy infrastructure for institutions. Yesterday was my final day at the Ethereum Foundation.Today, we’re launching @eth_systems .I started my career at @GoldmanSachs , working inside the financial system. Years later, I found myself at the @ethereumfndn , working with institutions exploring how that system could… https://t.co/oSQ6p2Ftx0— Mo (@motypes) July 14, 2026 An X post by Mo Jalil, co-founder and CEO of EthSystems and former Head of Institutional Privacy at the Ethereum Foundation, announcing the launch of EthSystems and its mission. Despite a recent launch, EthSystems has already developed several proofs-of-concept (PoC) addressing the following institutional privacy use cases mentioned earlier: Private bonds: The PoC tested three ways to hide information while still proving that the trade is valid: Representing each bond as a sealed note that only a holder can open using Noir Issuing bonds on Aztec, a separate privacy L2 Using an FHE-based encryption approach using Zama Private payments: The PoC hides the amount and parties involved in stablecoin transfers using: a shielded pool using Noir, where verified participants can send funds without the amount or recipient becoming public a network that keeps transaction data off-chain Private trade settlement: The PoC uses a Trusted Execution Environment (TEE), an enclave isolated from the node’s hardware, in which private information, such as counterparty identities and asset and amount, is handled. Confidential smart contracts Several new EVM chains, such as Oasis Sapphire, take confidentiality a step further by providing end-to-end encryption of transaction data natively on-chain, without requiring developers to create any new tools. Developers can directly deploy confidential smart contracts that keep that data private. EVM chains that offer confidential smart contracts separate execution from consensus. On Oasis Sapphire, the consensus layer still handles block production and finality. Each compute node responsible for executing smart contracts and processing transactions runs a Trusted Execution Environment (TEE), an enclave isolated from the node hardware, where private information is handled. The private information that a TEE handles separately from the compute node is the transaction calldata, a temporary data input when making a transaction, and contract state, the state variables a contract holds between calls, such as balances. From a developer’s perspective, deploying to Oasis Sapphire is like deploying to another EVM, except confidentiality is handled under the hood.  Write and deploy a Solidity contract onto Oasis Sapphire. When a user calls the contract, their wallet encrypts the calldata before it leaves their device. The still-encrypted transaction is submitted to the network and routed to the TEE. Inside the TEE, the runtime decrypts the calldata, executes the contract logic against the contract state, and re-encrypts the result. The encrypted output is passed to the consensus layer, which orders and finalizes it without ever decrypting it. The value of using Oasis Sapphire, as opposed to a new infrastructure add-on on Ethereum developed by EthSystems, for example, is that a developer would not need to run their own TEE hardware.  For example, unlike on Ethereum, private trade settlement on Oasis Sapphire requires only smart contract updates. While on Oasis Sapphire, transaction calldata and contract state are private; events are public by default. Events are one-off logs that a smart contract emits during a transaction for external parties to read. For a contract logging something like a trade settlement, that means the asset, amount, and price could leak. Oasis Sapphire encryption precompiles allow a smart contract to encrypt event data before it’s emitted. Here is what an example of a smart contract optimized for private settlement looks like: pragma solidity ^0.8.0; import { Sapphire } from "@oasisprotocol/sapphire-contracts/contracts/Sapphire.sol"; contract PrivateTradeSettlement {     event SettlementRecorded(address indexed counterparty, bytes32 nonce, bytes encryptedDetails);     function recordSettlement(bytes32 key, bytes calldata tradeDetails) external {         bytes32 nonce = bytes32(Sapphire.randomBytes(32, bytes("settlement-nonce")));         bytes memory encryptedDetails = Sapphire.encrypt(key, nonce, tradeDetails, bytes(""));         emit SettlementRecorded(msg.sender, nonce, encryptedDetails);     } } In the contract, the counterparty address stays a public, indexed topic, so external systems can still filter or count settlements per party.  event SettlementRecorded(address indexed counterparty, bytes32 nonce, bytes encryptedDetails); The tradeDetails payload, including the asset, amount, and price, is encrypted before it is emitted. bytes memory encryptedDetails = Sapphire.encrypt(key, nonce, tradeDetails, bytes("")); This enables institutions to publish a verifiable, timestamped record of a settlement without revealing the specific details of the settlement. What changes for RPC infrastructure Both privacy tracks have consequences for the layer developers actually touch — the RPC endpoint. Validator privacy: execution RPC is unaffected, consensus RPC and staking tooling aren’t. Standard methods like eth_call, eth_sendRawTransaction, and eth_getLogs don’t care who the validator is, so wallets and dApps see nothing different. The change lands on the Beacon Chain API. The /eth/v1/beacon/states/{state_id}/validators/{validator_id} endpoint currently returns a validator by index or public key. Under Lean Chain, those identifiers rotate daily. Staking dashboards like beaconcha.in and rated.network, MEV pipelines that bind proposer duties to a pubkey, and slasher software all need to migrate from stable keys to ZK-STARK identity commitments. For solo stakers, client teams (Lighthouse, Prysm, Teku) will need to hide the daily key derivation from the operator. For a deeper look at the mechanics behind these endpoints, see Understanding Ethereum proof of stake. Confidential EVMs: standard JSON-RPC survives, but the client and endpoint both need to know. Sapphire keeps the Ethereum JSON-RPC surface, but calldata has to be encrypted before it reaches the endpoint. That adds three things to the stack: A new RPC method: core.CallDataPublicKey returns the runtime’s ephemeral public key. The client uses it to derive a session key and encrypt calldata before submitting the transaction. See the Sapphire developer docs for the full flow. A wrapped client library. Raw ethers.js or web3.js won’t do envelope encryption. Developers use @oasisprotocol/sapphire-paratime, which wraps the provider and handles the key fetch, encryption, and decryption transparently. Authenticated reads via SIWE. Confidential contracts also require a Sign-in-with-Ethereum token on read calls — even for state queries. Unauthenticated calls return no data. See view-call authentication for the pattern. Limited introspection is the other consequence. debug_traceTransaction, eth_getStorageAt, and archive-style queries either fail or return encrypted blobs — the TEE gates them by design. Indexers reading eth_getLogs see cleartext for public events but ciphertext for anything the contract encrypted via the Sapphire precompile. For an RPC provider, the harder part is upstream: Sapphire compute nodes have to run inside a Trusted Execution Environment (Intel SGX today). That means SGX-capable hardware, remote attestation, and a runtime upgrade path that doesn’t break the enclave — none of which is a normal ops workflow. Chainstack runs both the Ethereum endpoints that will keep serving execution-layer traffic through the validator-privacy transition, and the Oasis Sapphire endpoints that run the SGX hardware — so developers ship confidential contracts without operating enclaves themselves. Conclusion Ethereum’s answer to privacy in 2026 is not one design. It’s two, aimed at different problems. At the protocol layer, validator anonymity solves a decentralization problem. Rotating identifiers and ZK-STARK identity commitments make it harder to trace, target, or coerce individual stakers — which matters for solo stakers and for institutional validators who can’t publicly show every deposit and withdrawal to competitors. At the application layer, confidential EVMs solve an adoption problem. EthSystems’ PoCs on Aztec and Noir, and confidential-by-default chains like Oasis Sapphire, let institutions run private trading, settlement, and payment flows on smart-contract infrastructure without leaking positions or counterparties. This is the layer that determines whether a bank can actually settle a bond onchain. For a broader look at how enterprises are choosing between these approaches, see private blockchains vs ZK rollups. Neither approach makes the other redundant. Validator privacy protects the network’s operators. Confidential EVMs protect the network’s users. Together they answer the question institutions have been asking since 2020: can we use public blockchain infrastructure without giving away the data that defines our business? The infrastructure that runs both — Ethereum RPC endpoints that outlast the validator-privacy transition, and Sapphire endpoints that operate the TEE hardware developers don’t want to run themselves — is what Chainstack provides. Start building with private RPC → FAQ Why do institutions specifically need privacy on a public blockchain? Institutions need to prevent competitors from accessing trading data such as positions, payment flows, and volumes, as such exposure creates front-running and strategic risks. What are some institutional use cases for privacy? Several use cases include private bonds (hiding volumes, prices, and positions from front-running), private payments (hiding transaction details that reveal business relationships and financial health), and private commodities trading (hiding position sizes, strategies, and delivery arrangements).  What is The Extremely Lean Chain? It’s a proposal by Vitalik Buterin that redesigns Ethereum to reduce technical dependencies and ensure validator privacy. What is EthSystems? EthSystems is a for-profit organization that spun out of the Ethereum Foundation’s Institutional Privacy Task Force in July 2026, focused on building privacy infrastructure for institutions. It has already published several open-source proofs of concept covering private bonds, payments, and trade settlement. How do confidential smart contracts like Oasis Sapphire keep data private? Each compute node runs a Trusted Execution Environment (TEE), a hardware enclave that decrypts transaction calldata and contract state, executes the logic, and re-encrypts the result. Resources The Extremely Lean Chain EthSystems, including institutional privacy use cases and POCs Oasis Sapphire Documentation Aztec Network, including Noir #### Ethereum roadmap 2026: Impact on nodes & validators Ethereum is now ten years old, with its initial mainnet launch in July 2015. To mark this milestone, the Ethereum Foundation recently introduced a series of comprehensive roadmaps, mandates, and visions to enhance its performance, security, and decentralization: EF Mandate is a manifesto that outlines the principles and guides on the role of the Ethereum Foundation Lean Ethereum is the overarching vision guiding the roadmap and manifesto on key areas: consensus, cryptography, governance, and overall protocol efficiency Strawmap is a detailed roadmap of research and engineering updates until 2030 The broader web3 industry has taken note of these developments. As major Bitcoin investor Nic Carter remarked on his podcast: “Frankly, I wish I were in Ethereum. I’d be thrilled right now.” @nic_carter straight-up complimenting @drakefjustin's new strawmap & Ethereum’s solid post-quantum roadmap in the pod—great contrast vs Bitcoin’s current path. Coherent PQ strategy FTW. 🔥 pic.twitter.com/WFyhU5u3u2— fara.eth (@fbwoolf) February 28, 2026 An X post by Fara Wolf, a software engineer at the Ethereum Foundation, citing Nic Carter on his podcast. For node providers, these initiatives represent major improvements, as they aim to modernize node communication, increase the number of validators to make Ethereum more decentralized, and improve overall network health. However, most are still in the research phase, and their drawbacks remain unknown or untested. This article analyzes these initiatives and their potential impact, especially on nodes and validators that run the network, including those operated by Chainstack. Ethereum’s decentralization vision for nodes What the EF Mandate means for node providers The EF Mandate defines the principles Ethereum must preserve as it scales and directly calls out the role nodes play in maintaining protocol decentralization, before any technical details are defined. In describing the EF Mandate, Vitalik Buterin, the founder of Ethereum, calls Ethereum a “decentralization-first blockchain.” The core principles defined in the mandate ensure decentralized properties to protect “self-sovereignty” and enable “cooperation without coercion.” This is the new EF Mandate.For many of you, the contents should be no surprise, and a clarification along the lines that we have been going and thinking for the past few months. But the clarification is nevertheless worth making.Ethereum is a unique object and has a unique… https://t.co/SMGCWnmUk5— vitalik.eth (@VitalikButerin) March 13, 2026 An X post by Vitalik Buterin explaining the principles highlighted in the EF Mandate Why CROPS matters for infrastructure Ethereum is partially powered by “centralized surfaces” such as wallets and RPCs, but the mandate emphasizes that current infrastructure must take a CROPS approach: Censorship resistance Open source Privacy Security Chainstack already adopts CROPS principles into its node API infrastructure. Chainstack node APIs run on bare-metal, enterprise-grade environments with encrypted endpoints, SOC 2 Type II and ISO 27001 compliance, and automated threat mitigation. Users can now also deploy, manage, and monitor them on their own hardware or in a cloud environment using Chainstack Self-Hosted. From a broader perspective, for node providers, the CROPS philosophy translates into three practical infrastructure objectives. Ethereum must remain verifiable by as many participants as possible. This principle supports efforts to reduce the hardware burden of running nodes by using lighter clients, simpler protocol components, and improved networking. The mandate emphasizes minimizing reliance on centralized intermediaries. Ethereum should not depend on a small number of infrastructure providers to function. Nodes and validators are the means by which the network maintains neutrality and resistance to censorship. The mandate emphasizes simplicity as a security feature. Excessive complexity makes it harder for independent clients to implement and increases the chance of protocol failures. Keeping the system clear and modular allows more teams to develop node software and supports client diversity. These principles guide many technical updates in development, as outlined by Lean Ethereum and Strawmap, specifically regarding node communication, block validation, and participation in consensus. Lean Ethereum, a Better Ethereum The four Lean Ethereum workstreams Lean Ethereum is the technical blueprint for simplifying and improving Ethereum’s performance. Many of its proposed changes directly affect how nodes operate. Designed as a long-term vision extending through 2030, Lean Ethereum aims to make Ethereum easier to secure, implement, and scale, as articulated by the Ethereum Foundation with this presentation slide: An X post by Thomas Coratger, a researcher at the Ethereum Foundation, cites that Vitalik Buterin shared this slide on Lean Ethereum Lean Ethereum is a complete redesign of the consensus layer, organized around four interconnected workstreams: Lean Consensus redesigns of Ethereum’s consensus layer focused on faster finality, stronger security guarantees, and improved decentralization. Lean Cryptography transitions toward simpler cryptographic building blocks, including hash-based signature schemes that are compatible with SNARK systems and resistant to quantum attacks. Lean Governance aims to strategically bundle protocol upgrades so complementary improvements ship together instead of through fragmented proposals. Lean Craft focuses on an architectural design that is characterized by minimalism, modularity, and formal verification. Several specific areas within the workstreams identify improvements for nodes, aiming to modernize communication, accelerate consensus, and increase validator participation. How peer-to-peer networking may change First, it focuses on improving peer-to-peer networking within Ethereum and how consensus nodes communicate with each other by upgrading to Gossipsub v2.0, and advanced set reconciliation. The progress milestones of the P2P networking updates on the Lean Ethereum website. Source: leanroadmap.org Gossipsub v2.0 is an upgraded peer-to-peer messaging protocol that improves reliability and spam resistance. Instead of broadcasting messages at random, nodes form structured communication meshes and prioritize peers who consistently relay messages correctly. Advanced set reconciliation allows nodes to efficiently identify which transactions or blocks they are missing from one another without rebroadcasting the entire dataset, reducing bandwidth usage and speeding up message propagation, the process by which transactions, blocks, and validator messages spread across the peer-to-peer network.  Modernized node communication would improve transaction speed, especially by decreasing slot times, the periods when a validator proposes a block, and when other validators attest to it.  However, these networking upgrades introduce tradeoffs that researchers are still evaluating. In Gossipsub, each node communicates with a limited number of peers rather than broadcasting to the entire network. This can sometimes increase message propagation latency if transactions or blocks must travel through multiple hops before reaching all validators. Nodes may also receive duplicate messages before the network converges.  More efficient networking could also support broader validator participation. Discussions around reducing the staking requirement from 32 ETH to 1 ETH could dramatically increase the number of validators participating in consensus.  A larger validator set improves decentralization but also increases the volume of network messages that nodes must process and relay. More efficient networking is essential to scaling validator participation without overwhelming node infrastructure. What’s in the Ethereum technical roadmap Fast L1, Gigagas L1, and Teragas L2 Strawmap outlines the specific technical upgrades required in a long-term roadmap. Considering the four-year roadmap, some upgrades are well-defined Ethereum Improvement Proposals (EIPs), while others lack a defined scope. The entire Strawmap roadmap. Source: strawmap.org Justin Drake, a lead researcher at the Ethereum Foundation, highlights five major areas:  The roadmap organizes Ethereum’s evolution around five major goals: Fast L1 reduces transaction finality times, allowing blocks to be confirmed in seconds rather than minutes. Gigagas L1 increases Layer 1 throughput to roughly 1 gigagas per second, enabling Ethereum to process far more transactions directly on the base layer. Teragas L2 scales rollups and other Layer 2 systems to handle millions of transactions per second, leveraging improved data availability. Post-quantum L1: transitions to quantum-resistant signature schemes to protect the network from quantum computers. Private L1 integrates privacy-preserving technologies directly into the protocol. Introducing strawmap, a strawman roadmap by EF Protocol.Believe in something. Believe in an Ethereum strawmap.Who is this for?The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers,… pic.twitter.com/gIZh5I8Not— Justin Drake (@drakefjustin) February 25, 2026 An X post by Justin Drake, lead researcher at the Ethereum Foundation Each of these goals introduces new technical requirements for the nodes that operate the network. Fast L1 focuses on reducing finality times. The roadmap includes upgrades such as 2-second slots and one-round finality, both of which shorten the time between block proposals and validator attestations.  The end result is that blocks are finalized within seconds rather than the current ~12–15 minutes (two epochs). As these slot times shrink, validator nodes must propagate blocks and validator messages across the network much more quickly.  In one-round finality, every validator votes for the block it received; in second-round finality, a certain number of validators must have seen the block, and then another set of validators confirms that they have. Though this speeds up finality, it introduces potential security flaws when malicious validators are involved. Certain measures, such as increasing the percentage of validators needed to block a transaction, would need to be implemented. A graphic showing how one-round finality would function. Source: ethereum.org Gigagas L1 and Teragas L2 aim to dramatically increase transaction throughput on Ethereum. Today, the base layer processes roughly 15–30 transactions per second, but the roadmap targets around 10,000 TPS at Layer 1 and eventually millions of transactions per second across Layer 2 networks. To support this scale, upgrades enable nodes to handle rollup data more efficiently by verifying data availability without downloading it all.  The well-defined upgrades include: Blob streaming: Nodes can send blob data to other nodes incrementally rather than waiting for the entire dataset to arrive first. By transmitting blob data pieces as they become available, nodes can share rollup data more quickly and avoid sudden spikes in bandwidth usage when blocks are distributed across the network. Block-in-Blobs (EIP-8142): This proposal stores the full transaction data for a block within a blob attached to that block. By placing the execution payload in blobs, the data remains available for nodes to retrieve and reconstruct blocks through the data availability layer. Though intended to lower gas fees for L2s by enabling them to read blobs instead of costly call data, using blobs on Ethereum remains a topic of debate. Each block has 6 blobs, and each blob can store up to 128 KB of data. Storing full transaction data in a blob increases reliance on blobs, reduces available blob space for future use cases, and still incurs gas fees. Over 17 million blobs, with an average of each storing up to 88 percent of capacity, already exist on Ethereum mainnet. More use of blobs would require additional infrastructure to ensure data availability. A graph showing the statistics of blob usage on Ethereum. Source: Blobscan As transaction volumes increase across both Layer 1 and Layer 2 systems, nodes must relay more data and verify more proofs during block validation, making efficient data availability systems a requirement. Post-quantum and private L1 requirements Post-quantum L1 and Private L1 introduce new cryptographic systems that nodes must support. Nodes need to support post-quantum signature schemes and privacy-preserving proofs, which are still under active research to reduce signature and proof sizes and improve the speed of generation and verification. Source: X post on Strawmap, by James Smith, Head of Ecosystem Dev at the Ethereum Foundation What this means for your node setup The Lean Ethereum roadmap is not abstract research — three changes have direct infrastructure implications for anyone running Ethereum nodes today. 1. Prepare for Gossipsub v2.0 client updates (2026–2027) Gossipsub v2.0 will require updated consensus client versions across Lighthouse, Prysm, Teku, and Nimbus. Node operators should track client release notes closely from late 2026 onward. Nodes running outdated clients risk degraded peer connectivity and message relay failures as the network migrates. 2. Plan for higher bandwidth with 1 ETH staking Reducing the validator minimum from 32 ETH to 1 ETH could increase the active validator set by an order of magnitude. More validators means significantly higher attestation message volume. Operators running bare-metal nodes should evaluate whether current NIC throughput and RAM headroom can absorb a 10–30x increase in p2p traffic. 3. Blob infrastructure will need scaling Post-Pectra blob targets have already increased. As Block-in-Blobs proposals progress, nodes may need additional storage and bandwidth capacity to handle full execution payloads in blob format. Monitor EIP-8142 status and plan storage provisioning accordingly. Conclusion Together, the EF Mandate, Lean Ethereum, and Strawmap outline a long-term direction for how Ethereum plans to scale and preserve its core principles. The mandate defines the values the network must protect, Lean Ethereum provides the technical vision for simplifying and strengthening the protocol, and Strawmap maps those ideas into technical upgrade requirements. For node operators, these changes improve node infrastructure overall, despite potential implementation challenges as research progresses. Faster finality requires nodes to propagate blocks and validator messages more efficiently. Higher throughput means nodes must relay more data and verify more proofs during block validation. Expanding validator participation increases the importance of efficient networking and reliable node communication. Start building on Ethereum today with Chainstack. Ethereum is working toward faster finality, higher throughput, and greater decentralization through broader validator participation. Throughout the years, Chainstack has followed the principles and technical standards that Ethereum has recently outlined. Chainstack delivers the performance and consistency required for production systems. Deploy an Ethereum RPC endpoint in seconds and scale globally with automated orchestration, uptime guarantees, and developer-friendly tooling. Building on Ethereum? Deploy your Ethereum node on Chainstack → FAQ What is Lean Ethereum? Lean Ethereum is the Ethereum Foundation’s long-term vision for making Ethereum simpler, faster, and easier to verify. It focuses on improving consensus, cryptography, governance, and protocol design. What is the difference between the EF Mandate, Lean Ethereum, and Strawmap? The EF Mandate defines Ethereum’s core principles, Lean Ethereum provides the broader technical vision, and Strawmap outlines the long-term roadmap of protocol upgrades and research directions. How could Lean Ethereum affect Ethereum nodes? Lean Ethereum could change how nodes communicate, validate blocks, process data, and support new cryptographic systems. These upgrades may improve performance, but they also introduce new operational requirements for node operators. Why does faster finality matter for Ethereum infrastructure? Faster finality reduces the time it takes for blocks to be confirmed, but it also requires validators and node providers to propagate messages more quickly and reliably across the network. What do Gigagas L1 and Teragas L2 mean for node operators? These upgrades aim to increase throughput on Layer 1 and Layer 2, which means nodes may need to handle more data, relay blobs more efficiently, and verify more proofs during block processing. Why is Lean Ethereum relevant for RPC and node providers? Because the roadmap directly affects message propagation, validator participation, data availability, and block verification. RPC and node providers will need infrastructure that can keep up with faster finality, higher throughput, and more complex protocol requirements. #### Ethereum without L2: Charting the impact of rollups on network performance Let’s take a moment to imagine a world where rollups never came to be. We’re just using the basic Ethereum layer, trying to handle our transactions and facing the resulting traffic. What would it really be like? That’s what our study aimed to explore. In normal speak, the Ethereum network gets really busy. All this traffic slows things down and makes it more expensive for everyone. Rollups, which are a way of handling these transactions, helped plenty with this problem. We aimed to demonstrate just how important they are by showing what could happen without them. We came up with a way to show this using some numbers and a linear regression-type prediction model. This allowed us to observe the differences in the volume of transactions, the cost of gas, the difference in transaction costs, and the time it takes to process a transaction. We examined these differences on the top 5 most significant dates for the years 2021, 2022, and 2023. We utilized this same model to study the effects of the absence of several rollup protocols. These protocols are different ways to handle transactions on the Ethereum network. They include Arbitrum, Optimism, Base, zkSync Era, Starknet, Linea, Polygon zkEVM, and the Boba Network. The aim of this article is to help you understand how significant these rollups are for the Ethereum network. We’ll walk you through our findings in a way that’s easy to understand, even if you’re not a technical expert. Ready to uncover the importance of rollups in managing Ethereum network traffic? Let’s explore further: Digging through Ethereum data To understand Ethereum and what rollups do for it, we needed to gather a lot of data. We pulled this information from two main sources, Dune Analytics and Etherscan. Transaction counts: First, we used Dune Analytics to determine how many transactions were happening each day. To do this we crafted a custom SQL query to extract the data on the total number of Ethereum, L2 rollup, and all transactions that happened in a day. Transaction counts vs. volume: Next, using the same Dune Analytics approach and another custom SQL, we checked the volume of transactions for each day and compared it with the average gas price. This data informed us about how busy the Ethereum network got and how that affected gas prices. ETH and gas prices: Once again, we used a custom SQL query on Dune Analytics to find out the daily ETH and gas prices. We extracted the average, lowest, and highest price for gas and how much gas was used each day. We also took note of the cost of gas in US dollars. Block count: After Dune Analytics, we went to Etherscan to find out the number of blocks created each day on Ethereum. Each of these blocks was identified with a specific date, a Unix timestamp (which told us exactly when it was made), and a value that told us more about each block. Block times: Finally, we used Etherscan again to find out how long it takes to create each block. Like the block count, this data also had a date, Unix timestamp, and a value attached to it to tell us more about it. By collecting this information, we were able to construct a picture of how the Ethereum network operated and how rollups affected this operation. Breaking down the calculations The numbers we used in our calculations to determine how much rollups helped in decreasing congestion and speeding up transactions were derived from specific formulas. Together, they are part of the linear regression model that we used to predict the impact of L2 rollups, by applying the model to calculate the estimates. There were five main formulae that we used in the prediction model—gas prices, transaction costs, congestion factor, base delay, and transaction processing times. Gas price predictions Predicting future gas prices was a key step in our analysis. This involved a close look at the average increase in gas price per transaction, which we label as avgG, alongside historical gas prices, H, and the count of transactions, T. Our method combined these factors to forecast gas prices accurately. To predict gas prices, we started with the number of transactions and multiplied this by the average increase in gas price. We then added the historical gas price to this figure. To make this number more manageable, we divided the entire sum by 1 billion (1e9) to display it in gwei. This method provided us with a reliable estimate of future gas prices. avgG = average gas price increase per transaction (single number) H = historical gas prices (array of numbers) T = transaction counts (array of numbers) Utilizing the average gas price increase per transaction (avgG), historical gas prices (H), and transaction counts (T), our prediction formula was structured as: predictedGasPrices[i] = (T[i] * avgG + H[i] / 1e9) (rounded to the nearest whole number) for i = 0 to n-1 where n is the number of elements in T. This approach helped us in anticipating the potential future state of the Ethereum network, considering the activity on L2 rollup protocols. By understanding the factors influencing gas prices, we recognized the crucial role of these developments in improving network efficiency and capacity. Transaction cost predictions Projecting transaction costs in dollars was an essential final step, tying together our prior calculations and predictions. This process hinged on the predicted gas prices, known as P, coupled with the average gas used, denoted as U. Factoring in the daily Ether price, E, brought real-world context to our numbers, grounding them in the day-to-day market. Our calculation began with the predicted gas price, which was then multiplied by the average amount of gas used. We simplified this number by dividing it by 1 billion (1e9), making the figures more tangible, as gwei units. The result was then adjusted according to the daily price of Ether. This comprehensive method yielded an anticipated average fee for gas usage, expressed in US dollars. P = predicted gas prices (array of numbers) U = average gas used (array of numbers) E = daily ETH price (array of numbers) By incorporating the predicted gas prices (P), average gas used (U), and daily ETH price (E), our formula for estimating transaction costs was: predictedAvgGasFeeInUSD[i] = ((P[i] * U[i]) / 1e9) * E[i] for i = 0 to n-1 where n is the number of elements in P. This calculation was crucial in forecasting the future state of the Ethereum network, particularly in the context of L2 rollups and their impact. Understanding potential transaction costs was key to recognizing the value of these advancements in enhancing network speed and efficiency. Congestion factor calculations The congestion factor was used to calculate the transaction processing times (base / predicted delay), according to block times. We looked at the count of transactions in each block per day, which we call B. To find the congestion factor, we divided each day’s block count by the average block count for all days. This gave us an idea of how each day’s block count compares to the overall average, as we extrapolated it for the predictions. B = block counts per day (array of numbers) avgB = average block count (single number) To estimate the potential delay in transactions without the use of rollups, we used a formula that considers the number of rollup transactions and the average wait increase per block, alongside the base delay. By multiplying the average wait increase by the number of rollup transactions and adding that to the base delay, we were able to predict the potential delay in a hypothetical scenario without rollups. Given the block counts (B) and the average block count per day (avgB), the formula was: congestionFactor[i] = B[i] / avgB for i = 0 to n-1 where n is the number of elements in B. These calculations aided us in simulating the future state of the Ethereum platform considering the impact of Layer 2 rollups. By understanding the potential delays without rollups, we could appreciate the importance of these scaling solutions in managing network congestion and improving overall network performance. Base delay estimates The base delay was a crucial metric used to determine the time required for transaction processing, factoring in the complexities of block times and the normative seven blocks needed to confirm a transaction. Our approach involved analyzing the time taken to process each block, referred to as D, and the congestion factor previously computed. Additionally, we considered the total number of transactions, denoted as T, and the quantity of Layer 1 transactions, symbolized as L. This comprehensive analysis allowed us to calculate the base delay for each day with precision. To derive the base delay, we initiated with the block time, amplified it by avgC, and then multiplied the result by the congestion factor. This value was further multiplied by the proportion of total transactions to L1 transactions. This intricate calculation offered us valuable insights into the daily fluctuations in transaction processing times. D = block times in seconds (array of numbers) C = congestion factor (array of numbers) T = transaction counts (array of numbers) L = L1 transaction counts (array of numbers) avgC = average of 7 blocks to confirm a transaction Employing the variables for block times (D), congestion factor (C), transaction counts (T), average blocks needed to confirm a transaction (avgC) ,and L1 transaction counts (L), the formula was articulated as: baseDelay[i] = D[i] * avgC * C[i] * (T[i] / L[i]) for i = 0 to n-1 where n is the number of elements in D. These calculations helped us envision what the Ethereum network might look like in the future, especially when we thought about L2 rollups that build on top of the basic network. Understanding how base delays work showed us how important these new technologies are for making the network faster and less crowded. Transaction processing time predictions Understanding the potential delays in transaction processing, especially without the use of rollups, was vital. For this, we introduced a specific formula that takes into account various factors. This included the number of rollup transactions, denoted as R, and the average wait increase per block, termed avgW, as well as the base delay, B. Our method involved enhancing the average wait by the volume of rollup transactions and integrating this with the base delay. This calculation provided us with a predictive look at possible delays, offering a glimpse into what might happen in scenarios without the benefit of rollups. R = rollup transactions (array of numbers) avgW = average wait increase per block (single number) B = base delay (array of numbers) By utilizing the rollup transactions (R), average wait increase per block (avgW), and base delay (B), our predictive formula was structured as: predictedDelays[i] = (R[i] * avgW) + B[i] for i = 0 to n-1 where n is the number of elements in R. Such predictions were essential in shaping our expectations for the future of the Ethereum network, particularly when considering the role of L2 rollups. Comprehending the potential for transaction delays underscored the significance of these innovative solutions in optimizing network throughput and reducing congestion. Together, these calculations helped us estimate what would happen to the Ethereum network without the help of rollups. These were the crucial numbers we use to simulate the future state of the Ethereum platform considering Layer 2 solutions’ impact. Evaluating the results In this section, we’ll dive into the significant impact that Layer 2 rollups could have, based on our predictions. Our data and careful analyses helped us understand potential changes in things like transaction times and gas fees on the Ethereum network. Now, it’s time to discuss the most significant findings in both absolute and percentage terms and how they differed from 2021 to 2023. The ascend of rollups in transaction counts Starting in 2021, even a cursory look at the data showed the emergence of rollup transactions. Specifically, on November 15, the network recorded a high of 2,425 rollup transactions. While this might seem modest, it made up approximately 0.188% of all transactions on that very busy day. In addition to that, November 22 and November 21 bore witness to 1,668 and 1,592 rollup transactions, comprising approximately 0.14% and 0.13% of total transactions, respectively. These figures highlight the budding but promising presence of rollups in Ethereum’s ecosystem. Figure 1: Transaction counts (L1 + L2) in 2021; Source: Interactive chart Progressing to 2022, there was a noticeable acceleration in the use of rollups. The network registered a record spike of 11,111 rollup transactions on December 7, which was a whopping five times more than the previous year’s peak. These rollups made up about 1.13% of the total transactions for the day. Furthermore, December 4, December 5, and December 8 saw remarkable rollup transactions ranging from 6,565 to 8,260, representing approximately 0.85%, 0.79%, and 0.77% of total transactions, respectively, highlighting the evolving usage and necessity of rollups in the Ethereum network. Figure 2: Transaction counts (L1 + L2) in 2022; Source: Interactive chart Once we entered 2023, the rollup transactions shot up, setting a new record. On July 30, there were an impressive 100,088 rollup transactions that accounted for approximately 9.27% of all transactions that day. Moreover, significant figures emerged throughout the year. On March 26, the network saw 93,863 rollup transactions that comprised about 8.46% of total transactions. Likewise, September 10 and September 17 recorded 83,683 with a percentage cost increase peaking at an incredible 677.82%. Figure 3: Transaction counts (L1 + L2) in 2023; Source: Interactive chart Scrutinizing these detailed accounts, it’s clear how rollup transactions have gone from representing a minor fraction of the network’s activity in 2021 to playing a vital part in Ethereum’s functioning by 2023. These growing figures illustrated their increasing acceptance and crucial function in driving overall network efficiency—a telling tale of the transition within Ethereum’s network operations. Decoding predicted gas price differences In 2021, the network registered notable spikes in predicted gas price differences. On October 28, the predicted gas difference reached 68 gwei, the highest observed for the year. Although it looks like a small figure, it played a considerable role in the total transaction process. Other standout days included October 29, November 3, November 2, and November 10, exhibiting predicted gas differences ranging from 63 to 66 gwei. Most significantly, on December 26, the predicted gas percentage difference hit nearly 91.53%—marking the highest percentage difference for the year. Figure 4: Predicted gas prices in 2021; Source: Interactive chart Fast-forward to 2022, the gas price predictions were even loftier. For instance, on December 9, the network recorded a predicted gas difference that skyrocketed to 87 gwei, a remarkable increase from the previous year. Other prominent days like July 26, August 4, February 20, and May 12 also presented significant predicted gas differences, ranging from 60 to 76 gwei. However, the true stand-out moment came on September 17, when the predicted gas percentage difference posted a staggering 666.67%, showing the volatility and unpredictability of gas price predictions. Figure 5: Predicted gas prices in 2022 By the time 2023 rolled around, the predicted gas differences had reached new heights. Specifically, on September 13, the network registered a predicted gas difference of 75 gwei, an impressive figure even by growing standards. Other significant dates emerged throughout 2023, such as March 30, June 10, March 28, and March 31, showing predicted gas differences from 55 to 56 gwei. Interestingly, September saw astounding swings in predicted gas price percentage differences, culminating on September 24 with an approximate difference of 440.00%. Figure 6: Predicted gas prices in 2023; Source: Interactive chart Looking at the data from 2021 to 2023, it’s clear that the predicted gas price differences have seen a consistent uptrend. This growth trend illustrated the increasing complexity and dynamic nature of the Ethereum network and highlighted the impactful role of rollup transactions in mitigating network congestion and improving overall network performance. Delving into transaction cost differences During 2021, the Ethereum network saw considerable variations in transaction cost differences. On November 10, an absolute cost difference of approximately $21.17 was marked, while the cost percentage increase for the day was approximately 5.17%. Other notable days, such as November 12, November 9, November 11, and November 8, recorded absolute transaction cost differences ranging from approximately $20.86 to $21.08. Additionally, the year saw significant cost percentage increases with the highest being approximately 92.88% on December 26. Figure 7: Predicted transaction costs in 2021; Source: Interactive chart In 2022, the transaction cost dynamics illustrated a notable escalation. On January 3, an absolute cost difference of approximately $17.28 was accounted for, representing a corresponding cost percentage increase of 51.17%. Other significant days throughout the year like January 2, January 4, January 5, and January 1 displayed absolute transaction cost differences ranging from approximately $17.04 to $17.13. However, September 17 outshone other days with a cost percentage increase peaking at an eye-opening 677.82%. Figure 8: Predicted transaction costs in 2022; Source: Interactive chart As we reached 2023, the transaction cost differences had expanded further. Specifically, on April 16, Ethereum marked an absolute transaction cost difference of approximately $10.69. Besides this, other days also showed important changes. These were April 17, April 15, April 14, and April 18. Transaction cost differences on these days were significant. They ranged from about $10.27 to $10.46. When it came to percentage terms, the most notable dates were September 22-24 with increases from 360.94% to 419.52%. Figure 9: Predicted transaction costs in 2023; Source: Interactive chart Examining these figures from 2021 to 2023, it became clear the transaction costs within the Ethereum network have become significantly more complex, displaying considerable differences over the years. This underlined the growing importance of rollup transactions in managing transaction costs and improving the overall network performance, visibly paving the way for a progressive Ethereum network. Analyzing transaction processing time In 2021, Ethereum saw changes in how long it took to process transactions. One notable day was November 15. On this day, there was a longer wait time of 5 extra seconds. This meant a 5.17% increase in waiting times compared to usual. Several other days stood out for similar reasons. November 21 and November 22 each had a 3-second delay. This was about a 3.40% and 3.56% increase, respectively. November 19 and November 20 also experienced more delays. On these days, the increase was 2 seconds. The percentage increase for November 19 was roughly 2.68%. For November 20, the exact increase isn’t known. Figure 10: Predicted processing times in 2021; Source: Interactive chart Moving onto 2022, the dynamics of transaction delays had considerably exacerbated. Specifically, on December 7, the absolute delay increase shot up to 21 seconds, which represented a percentage delay increase of about 23.14%. Days like December 4, December 5, December 8, and October 27 also sported considerable absolute delay increases, reaching from 12 to 16 seconds, and corresponding percentage delay increases between approximately 13.70% and 17.24%. Figure 11: Predicted processing times in 2022; Source: Interactive chart Come 2023, the transaction delays had shot up even more dramatically. For instance, on July 30, a striking absolute delay increase of 189 seconds was registered—the highest for the year, resulting in a delay percentage increase of about 191.89%. But the trend was not isolated to this day. Other significant days throughout the year like March 26, September 10, March 25, and August 26 saw remarkable absolute delay increases, ranging from 157 to 177 seconds, with corresponding delay percentage increases reaching between approximately 161.48% and 180.05%. Figure 12: Predicted processing times in 2023; Source: Interactive chart Reflecting on these numbers from 2021 to 2023, it’s evident that transaction processing times within Ethereum have gone from moderately variable to markedly dynamic. This evolution underscores the importance of technological advancements like rollup transactions in managing network congestion and improving the overall efficiency of the Ethereum network. Examining the global average results When evaluating the overall network performance based on global averages, several key insights come to light: Total transactions: Globally, the total number of transactions averaged out to 1,116,000, with an average of 13,000 being rollup transactions. The global total transactions percent increase stood at around 1.16%. It illustrated the network’s growth and a steady rise in the number of transactions being processed. Despite rollup transactions making up such a small proportion of total transactions, they played a vital role in improving transaction processing efficiency, as noted in the other results. Average gas price: An increase of 50 gwei in the average gas price was noted, corresponding to an astonishing rise of about 101.13%. The doubling of gas prices underscores the significant impact L2 rollups have on the cost of each transaction. Overall, rollups have played an integral role in managing these costs through improved network efficiency and scalability. Average transaction cost: The noticeable increase in transaction costs averaging $9.83 (86.18%) for an average predicted transaction cost of $21.21 displays the linkage between gas prices and transactional expenses. As gas prices inflated due to growing demand, transaction costs invariably increased. And as they did for the average gas price, this is where L2 rollup transactions showed to offer a significant advantage. Average processing time: The global predicted delay was roughly 114 seconds, and there has been an increase of about 24 seconds. This translated to a percent increase in predicted delay of approximately 25.58%. These figures highlighted the challenges in maintaining prompt transaction processing times in the face of increasing network demand. Figure 13: Global averages for transaction counts, gas prices, transaction costs, and processing times; Source: Interactive chart Judging from these global averages, it’s evident that the Ethereum network is continuously evolving its capabilities, with rollup transactions playing an increasingly vital role in network efficiency and cost-effectiveness. The impact of Layer 2 rollups on the Ethereum ecosystem Our in-depth analysis from 2021 to 2023 revealed the transformative influence of Layer 2 rollups on the Ethereum network, evident in several critical areas: Transaction counts Our findings show a steady climb in the number of rollup transactions, growing from a nominal presence in 2021 to a formidable force by 2023. For instance, July 30, 2023, marked a milestone with a record 100,088 rollup transactions, comprising a substantial 9.27% of the total transactions that day. This surge underscored the escalating reliance on Layer 2 rollups to bolster network efficiency and scalability. On a global scale, the total number of transactions averaged 1,116,000, with rollup transactions averaging 13,000. This consistent growth, with a 1.16% increase in total transactions, reflects the network’s expansion and the integral role of rollups in enhancing transaction throughput. Predicted gas prices While our gas price predictions indicated a rising trend, signifying a bustling Ethereum network, Layer 2 rollups emerged as a powerful counterbalance. A striking instance is December 9, 2022, when the predicted gas price difference reached 87 gwei, yet rollups contributed about 1.13% of total transactions, showcasing their efficacy in tempering gas price spikes. The global average paints a similar picture, with an average increase of 50 gwei in gas prices — a remarkable 101.13% rise. This sharp increase highlighted the crucial role of Layer 2 rollups in managing transaction costs and sustaining network stability. Predicted transaction costs Between 2021 and 2023, we observed a persistent ascent in predicted transaction costs, a consequence of the network’s heightened activity. A notable peak occurred on April 16, 2023, with a transaction cost difference of roughly $10.69. Despite these challenges, Layer 2 rollups demonstrated their capacity to mitigate cost escalations, ensuring Ethereum remains an affordable platform. The global average transaction cost experienced a significant leap to $21.21, an 86.18% increase, further emphasizing the critical buffer rollups provide against escalating operational costs. Predicted processing times Our analysis detected a considerable prolongation in transaction processing times, a testament to Ethereum’s burgeoning activity. However, Layer 2 rollups shone in their ability to manage these delays. A case in point is July 30, 2023, when the network saw an absolute delay increase of 189 seconds, but thanks to rollups, the delay percentage increase was around 191.89%. Globally, the average predicted delay stood at approximately 114 seconds, with an increase of about 24 seconds or 25.58%. These statistics signified the mounting pressures on the network’s processing capabilities and the instrumental role of rollups in sustaining manageable transaction timelines. Figure 14: Transaction counts and predicted gas prices, transaction costs, and process times; Source: Interactive chart In reflection, Layer 2 rollups were not just an incremental improvement but a paradigm shift for the Ethereum ecosystem. They enhanced transaction processing capacity, moderated gas and transaction expenses, and improved processing speeds, marking a pivotal phase in Ethereum’s journey. As we look ahead, it’s clear that Layer 2 rollups were not just a temporary fix but a foundational layer for Ethereum’s enduring resilience and performance, essential to its future as a leading decentralized platform. Curious to explore the data on your own? Play around with the interactive chart here. Bringing it all together Our data revealed a notable rise in transaction counts over the years with rollup transactions playing an increasingly prominent role. This trend underscored the impact of Layer 2 rollups in accommodating a larger volume of transactions thereby enhancing network efficiency and scalability in the face of growing demand. Ethereum’s vitality also emerged in rising gas prices over time. However, Layer 2 rollups demonstrated their potential to effectively mitigate these cost surges, reinforcing stability in the Ethereum network. As transaction cost predictions continued to rise, reflecting the increasing transactional activity, Layer 2 rollups helped to cap these increases, ensuring that Ethereum remains a cost-effective platform for users across the globe. The marked increase in transaction processing times over the period also spoke to growing activity within the Ethereum ecosystem. Yet again, Layer 2 rollups rose to the occasion, managing these times more effectively and showcasing their crucial role in reducing network congestion and improving transaction efficiency. In conclusion, our meticulous processing of historical data, diligent calculations, and careful interpretation of the results illuminated the transformative effect of Layer 2 rollups on the Ethereum ecosystem. By boosting transaction capacity, alleviating gas and transaction costs, and enhancing transaction processing times, these technological advancements promise to be invaluable to Ethereum’s evolution. Our analysis pointed to a future where Layer 2 rollups would continue to reinforce Ethereum’s robust performance, further consolidating its stance as a robust decentralized platform well-equipped to meet growing demand. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ethereum: How to monitor and react to events reliably in JavaScript? Reliably monitoring and reacting to blockchain events is crucial for maintaining data consistency and ensuring a smooth user experience, while building on Ethereum. Relying on a single node can be risky due to potential downtime or connectivity issues. A redundant event listener addresses this by subscribing to multiple Ethereum nodes, ensuring that important events are not missed. Here are its core advantages: Increased reliability: By subscribing to multiple nodes, you reduce the risk of missing events due to node failures. Enhanced fault tolerance: The system remains functional even if some nodes experience issues. Improved performance: Lower latency and higher transaction capacity. This guide will show you how to build a redundant event listener using Node.js, web3.js, and ethers.js on atop robust Chainstack infrastructure to ensure fault tolerance and reliability. How to build a redundant Ethereum event listener in JavaScript? This tutorial guides you through building a redundant Ethereum event listener using Node.js with web3.js and ethers.js libraries, leveraging global and regional Chainstack infrastructure. This setup ensures reliable and fault-tolerant monitoring of Wrapped Ether (WETH) transfer events. Prerequisites Node.js: Install Node.js (version 18 or higher recommended). Chainstack account: Sign up on Chainstack, deploy nodes, and get their access credentials. Dependencies: Install required packages: npm init -y npm install web3 ethers dotenv Environment variables: Create a .env file to store your WebSocket endpoints: ENDPOINT_1=YOUR_CHAINSTACK_GLOBAL_NODE ENDPOINT_2=YOUR_CHAINSTACK_REGIONAL_NODE ENDPOINT_3=YOUR_CHAINSTACK_REGIONAL_NODE How to set up the redundant event listener JavaScript code? The following DApp ensures redundancy by establishing multiple WebSocket connections to Ethereum RPC nodes using our global and regional infrastructure. By subscribing to multiple nodes simultaneously, the DApp increases its chances of receiving events even if some nodes experience downtime or connectivity issues. Here’s how the logic works: Connect to WebSocket endpoints: Define an array of WebSocket endpoints from various Ethereum node providers. Set up an event filter: Create a filter object specifying the WETH contract address and the “Transfer” event signature. Implement unique event tracking: Initialize a Set data structure to track unique event identifiers and prevent duplicate event processing. Define the subscription function: Define a function, subscribeToLogs, that: Takes an endpoint as input. Creates a new Web3 instance with that endpoint. Sets up a WebSocket subscription to listen for logs matching the defined filter. Handle events effectively: When a new event is received, check if the event identifier (transaction hash and log index for web3.js; transaction hash and block for ethers) has been seen before. If the event is new, log the event data to the console and add the event identifier to the Set to mark it as processed. Handle errors with ease: Log any subscription errors to the console. By implementing this redundant event listener, the application ensures that critical events, such as WETH transfers, are not missed, even if node failures or connectivity issues occur. This increased reliability and fault tolerance are essential for applications that rely heavily on real-time monitoring and reacting to Ethereum events. How to set up the redundant event listener script with Web3JS? Create a file named index.js and add the following code: const { Web3 } = require("web3"); require('dotenv').config(); const endpoints = [ process.env.ENDPOINT_1, process.env.ENDPOINT_2, process.env.ENDPOINT_3, ]; const logsFilter = { address: "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", // WETH contract address topics: [ "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", ], }; const seenEvents = new Set(); async function subscribeToLogs(endpoint) { const web3 = new Web3(endpoint); try { const subscription = await web3.eth.subscribe("logs", logsFilter); console.log(`Subscription created with ID: ${subscription.id}`); subscription.on("data", (log) => { const eventId = `${log.transactionHash}-${log.logIndex}`; if (!seenEvents.has(eventId)) { seenEvents.add(eventId); console.log(`Event received first from ${endpoint.slice(0, 33)}:`, log); } }); subscription.on("error", (error) => { console.error(`Error when subscribing to logs from ${endpoint}:`, error); }); } catch (error) { console.error(`Error setting up subscription from ${endpoint}:`, error); } } endpoints.forEach((endpoint) => { subscribeToLogs(endpoint); }); How to set up the redundant event listener script with ethersJS? Alternatively, create a new file and add the following code: const { ethers } = require("ethers"); require('dotenv').config(); const endpoints = [ process.env.ENDPOINT_1, process.env.ENDPOINT_2, process.env.ENDPOINT_3, ]; const contractAddress = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"; // WETH contract address const contractABI = [ "event Transfer(address indexed from, address indexed to, uint amount)", ]; const seenEvents = new Set(); async function subscribeToEvents(endpoint) { const provider = new ethers.WebSocketProvider(endpoint); const contract = new ethers.Contract(contractAddress, contractABI, provider); contract.on("Transfer", (from, to, amount, event) => { const eventId = `${event.log.transactionHash}-${event.log.blockNumber}`; if (!seenEvents.has(eventId)) { seenEvents.add(eventId); console.log(`Event received first from ${endpoint.slice(0, 33)}:`); console.log( `Transfer from ${from} to ${to} of ${ethers.formatEther(amount.toString())} ETH` ); } }); provider.on("error", (error) => { console.error(`WebSocket error from ${endpoint}:`, error); }); } endpoints.forEach((endpoint) => { subscribeToEvents(endpoint); }); Bringing it all together Building reliable and fault-tolerant systems is essential for Ethereum blockchain applications. Implementing a redundant event listener using Node.js with web3.js or ethers.js libraries ensures your application consistently receives important events, like token transfers, without interruptions. This strategy reduces the risks of depending on a single node by subscribing to multiple nodes simultaneously. This redundancy ensures events are captured even if some nodes fail. This tutorial offered a step-by-step guide to setting up a project, configuring environment variables, and creating a redundant event listener. With this setup, your Ethereum-based application will remain responsive, up-to-date, and provide a seamless user experience, even in the face of node failures or connectivity issues. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ethereum: How to track and handle events reliably in Python? Ensuring data consistency and a seamless user experience is critical when developing on Ethereum. Relying on a single node for event monitoring can be risky due to potential downtimes or connectivity issues. Event listeners play an essential role in blockchain technology, enabling applications to respond to specific events emitted by smart contracts. These events are vital for decentralized applications (DApps), such as tracking token transfers and monitoring contract executions. In the Ethereum ecosystem, events are logged on the blockchain and can be listened to by off-chain applications to trigger actions or update their state based on the latest blockchain activity. Implementing a redundant event listener can solve these problems by subscribing to multiple Ethereum nodes. This approach offers several key benefits: Increased reliability: Subscribing to multiple nodes minimizes the risk of missing crucial events due to node failures. Better fault tolerance: The system continues to function effectively even if some nodes experience issues. Improved performance: Multiple nodes can lower latency and handle higher transaction volumes. This guide will show you how to build a resilient event listener using Python and web3.py. By leveraging Chainstack’s robust infrastructure, you’ll ensure your application remains reliable and responsive, even in the face of network challenges. Let’s get started! How to build a redundant Ethereum event listener in Python? This tutorial aims to build a resilient Ethereum event listener using Python. By leveraging multiple Chainstack endpoints across different regions, we aim to achieve better consistency in catching events and ensure redundancy in case of endpoint failures. This approach enhances the reliability and robustness of the event listener, making it more effective in real-world scenarios where network issues or endpoint downtimes might occur. Prerequisites Ensure you have the following setup: Python: Make sure Python is installed on your machine. Virtual environment: Set up and activate a virtual environment. python -m venv venv source venv/bin/activate # On Windows, use `venv\\\\Scripts\\\\activate` Web3 library: Install the web3.py library using pip. pip install web3 Ethereum node endpoints: Deploy at least three RPC nodes (one Global Node and two Trader Nodes) on Chainstack. How to set up the redundant event listener Python script? Create a new file named main.py and paste the following code: import os import asyncio import logging from web3 import Web3 from web3.middleware import geth_poa_middleware # Configure logging logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') # List of endpoints endpoints = [ "ENDPOINT_1", "ENDPOINT_2", "ENDPOINT_3" ] # Filter for WETH transfer events logs_filter = { 'address': '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2', # WETH contract address 'topics': ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'], # Transfer event signature } # Set to track seen event identifiers to prevent duplicates seen_events = set() async def handle_event(event, endpoint): event_id = f"{event['transactionHash'].hex()}-{event['logIndex']}" if event_id not in seen_events: seen_events.add(event_id) logging.info(f"Event received first from {endpoint}: {event_id}") async def subscribe_to_logs(endpoint): while True: try: web3 = Web3(Web3.HTTPProvider(endpoint)) web3.middleware_onion.inject(geth_poa_middleware, layer=0) if not web3.is_connected(): logging.warning(f"Failed to connect to endpoint {endpoint}") await asyncio.sleep(5) continue logging.info(f"Connected to endpoint {endpoint}") event_filter = web3.eth.filter(logs_filter) while True: for event in event_filter.get_new_entries(): await handle_event(event, endpoint) await asyncio.sleep(1) except Exception as e: logging.error(f"Error when subscribing to logs from {endpoint}: {e}") await asyncio.sleep(5) # Wait before retrying async def main(): tasks = [subscribe_to_logs(endpoint) for endpoint in endpoints] await asyncio.gather(*tasks) if __name__ == "__main__": asyncio.run(main()) Import libraries: Import os, asyncio, and logging for general purposes, and Web3 and geth_poa_middleware from the web3 library to interact with the Ethereum blockchain. Configure logging: Set up logging to display informational messages. Define endpoints: List of Ethereum node endpoints. Set up event filter: Configure the event filter to listen for WETH transfer events. Track seen events: Use a set to track event identifiers that have already been processed. Handle events: Process received events and log new ones. Subscribe to logs: Continuously connect to an Ethereum node, set up a filter, and process new entries. Run the main function: Create tasks for each endpoint and run them concurrently using asyncio.gather. Add your endpoints in the endpoints list and run the following command in the terminal: python3 main.py It will start listening and logging events. Example output: 2024-05-16 17:07:09,452 - INFO - Connected to endpoint <https://nd-974-620-518.p2pify.com/> 2024-05-16 17:07:11,345 - INFO - Connected to endpoint <https://nd-777-597-727.p2pify.com/> 2024-05-16 17:07:12,776 - INFO - Connected to endpoint <https://ethereum-mainnet.core.chainstack.com/> 2024-05-16 17:07:13,805 - INFO - Event received first from <https://ethereum-mainnet.core.chainstack.com/:> 0xcab7994c8ff1495136db4966f4ed4556513540c6cf08dbd22e09fb3496acadef-1 Bringing it all together Creating a resilient Ethereum event listener is essential for ensuring reliable and consistent decentralized applications. By utilizing multiple endpoints across different regions, you can enhance event capture and introduce redundancy, making your event listener more robust against network issues and downtimes. This tutorial has walked you through the process of setting up, configuring, and running a resilient event listener using Python and web3.py. With this setup, you’ll be well-prepared to handle blockchain events efficiently and reliably, significantly boosting the performance and reliability of your DApps. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ethereum’s Glamsterdam upgrade: what changes for infrastructure Ethereum names its upgrades with a system. Consensus layer forks take star names in alphabetical order: Altair, Bellatrix, Capella, Deneb, Electra, Fulu. Execution layer forks take the names of cities that hosted Devcon or Devconnect: Berlin, London, Shanghai, Cancun, Prague, Osaka. Since the Merge, both layers upgrade together, so their names get merged into one. Shanghai plus Capella became Shapella. Prague plus Electra became Pectra. Fulu plus Osaka became Fusaka, which went live on mainnet on December 3, 2025. The next star in the sequence is Gloas. The next city is Amsterdam, which hosted Devconnect in 2022. Put them together and you get Glamsterdam: the upgrade Ethereum core developers have called the largest protocol change since the Merge, targeted for the second half of 2026. This post covers what Glamsterdam changes, why it matters, and what you should do about it if you run apps, indexers, or validators on Ethereum. Where Glamsterdam sits on the roadmap Fusaka focused on data. Its headline feature, PeerDAS, lets nodes verify blob data by sampling small pieces of it rather than downloading everything, which opened the door to raising blob capacity for Layer 2 rollups. Fusaka also raised the default block gas limit to 60 million. We covered that upgrade in detail in our Fusaka breakdown. Glamsterdam turns to the base layer itself. Its two goals: change how blocks are built, and change how blocks are executed. Every upgrade since Pectra has followed a “headliner” process where core developers pick one or two high-impact EIPs to anchor the fork, then evaluate everything else around them. Glamsterdam’s two headliners are locked in: EIP-7732: Enshrined Proposer-Builder Separation (ePBS) on the consensus layer EIP-7928: Block-Level Access Lists (BALs) on the execution layer The remaining EIPs are a mix of gas repricings and quality-of-life changes. The full candidate list lives in the EIP-7773 meta thread on Ethereum Magicians, and Forkcast tracks the live inclusion status of each proposal. Headliner 1: ePBS moves block building into the protocol To understand ePBS, you need to know how an Ethereum block gets made today. In theory, the validator selected to propose a block builds it too. In practice, most proposers outsource that work. Specialized builders compete to assemble the most profitable block possible — profit that comes largely from MEV, the extra value extracted by choosing which transactions to include and in what order. The proposer simply sells the right to publish its block to the highest bidder. But there’s a trust problem on both sides: the builder won’t reveal its block early, because the proposer could steal the profitable transaction ordering inside it, and the proposer won’t commit to a block without a guarantee of getting paid. A middleman called a relay solves this — most commonly through software called MEV-Boost. The relay holds the builder’s block, shows the proposer only the bid amount, and has the proposer sign a commitment to a block it has never seen. Only then does the relay release the block’s actual contents and pass the payment along. This system works, but it depends on off-protocol middleware and a small set of trusted relays sitting at the center of block production. If a relay fails or misbehaves, the protocol has no way to enforce the deal. EIP-7732 writes the proposer-builder split into consensus rules. The proposer selects a consensus block that commits to a builder’s bid. The builder then reveals the execution payload later in the slot, and the protocol itself guarantees the payment. A new committee of validators, the Payload Timeliness Committee (PTC), attests to whether the builder revealed the payload on time. Relays become optional rather than load-bearing. So far this sounds like a trust fix, not a scaling fix. Why does it matter for throughput? The scaling win comes from the schedule change. Splitting consensus from execution lets validators attest to each part on separate deadlines within the 12-second slot. According to ethereum.org, this expands the data propagation window from 2 seconds to roughly 9 seconds. That extra time is what allows bigger blocks and more blobs to travel across the network without validators falling behind, and it gives future ZK-proving workflows more room to operate inside a slot. For the full mechanism, including the fork-choice changes and builder payment flow, the EIP-7732 specification is the reference. Headliner 2: Block-Level Access Lists enable parallel execution Ethereum executes transactions one at a time. The reason is simple: a node can’t know which accounts and storage slots a transaction will touch until it runs it. Two transactions might conflict, so clients play it safe and process everything sequentially. That single-threaded pipeline is a core bottleneck limiting L1 throughput. EIP-7928 addresses this directly. Every block gets a Block-Level Access List: a record of every account and storage slot the block’s transactions touch, along with the resulting state values. Crucially, the BAL isn’t organized by transaction — it’s organized by address, with each account appearing exactly once, and every transaction that touched it referenced inside. That map changes what clients can do: Parallel disk reads and validation. A node knows upfront which transactions are independent, so it can execute non-overlapping ones at the same time and pre-load all required state in one pass. This cuts worst-case block validation time. Executionless sync. Because BALs include post-execution state values, a syncing node can update its records from those results without replaying every transaction. Syncing gets much faster. BALs matter beyond their direct effect. BALs are what make raising the gas limit further technically safe. Today, transactions execute sequentially, so worst-case validation time scales roughly linearly with the gas limit, and every node must finish validating a block within its 12-second slot. Push the gas limit up without changing how validation works, and slower nodes risk missing that window, forcing them out of sync or off the network entirely. BALs change the constraint: by letting nodes parallelize execution across non-overlapping transactions and skip re-execution during sync, they cut the time needed to process a given amount of gas. That headroom is what makes a higher limit sustainable. The limit sits at 60 million gas after Fusaka. Once BALs are live, 200 million becomes a realistic target, though no such increase is part of Glamsterdam itself. Gas limit changes on Ethereum happen through validator signaling, and they only happen safely when nodes can keep up. The EIP-7928 specification lays out the exact data structure, if you want to go deeper. The gas repricing bundle Beyond the headliners, Glamsterdam carries a set of repricing EIPs, organized under the meta proposal EIP-8007, that adjust gas costs to match what operations actually cost the network. Two changes stand out. Resource-based intrinsic transaction gas (EIP-2780). Every Ethereum transaction has paid a flat 21,000 gas base cost since genesis, regardless of what it does. EIP-2780 breaks that flat fee into measured components — a base transaction cost, recipient account access, the value write, and the new EIP-7708 transfer log — so each transaction pays for what it actually uses. Under the current draft, a plain ETH transfer to an existing account still totals 21,000 gas, but transactions that do less pay less: a zero-value transaction drops to 15,000 gas and a self-transfer to 12,000. Note that this EIP is still a draft and its numbers have already been revised several times (earlier versions cut a simple transfer to as little as 6,000 gas), so treat any specific figure as provisional and check the official specification at https://eips.ethereum.org/EIPS/eip-2780 for the current values. More expensive state creation Permanent storage is the resource Ethereum nodes can least afford to give away, and current pricing undercharges for it. These proposals raise the cost of creating new states so the network’s database grows at a sustainable rate. (EIP-8037 and related proposals). The direction of the whole bundle: computation gets cheaper, permanent state gets more expensive. If your contracts are storage-heavy, re-benchmark your gas assumptions on a testnet before mainnet activation. Smaller changes worth knowing about Two more proposals in the Glamsterdam scope deserve attention from anyone building on Ethereum: EIP-7708: ETH transfers emit logs. Today, native ETH movements produce no events. A plain transfer, or ETH moved inside a contract call, leaves nothing for eth_getLogs to find, which is why wallets, exchanges, and indexers reconstruct ETH flows by tracing every transaction. EIP-7708 makes value-transferring operations emit a log in the same shape as an ERC-20 Transfer event. Once it’s live, tracking ETH becomes a standard log query. EIP-7954: bigger contracts. The maximum contract code size, capped at 24 KiB (24,576 bytes) since 2016, would rise to 64 KiB (65,536 bytes), and the initcode limit would rise from 48 KiB to 128 KiB, giving developers more room before they have to split logic across multiple contracts. Two ideas you may have heard about did not make this fork. Fork-Choice Inclusion Lists (FOCIL, EIP-7805), a censorship-resistance mechanism, was considered but kept out of the headliner set to contain scope. A proposal to shorten slot times to 6 seconds (EIP-7782) was declined for Glamsterdam. Both remain candidates for future upgrades. Timeline: where things stand As of mid-2026, Glamsterdam is in the “devnet” phase: Small test networks where client teams hammer the new rules with edge cases to see what breaks. A new round of testing, devnet-6, is coming next. EtherWorld’s State of Upgrade series tracks this work in detail. From here, the process is: keep testing on devnets, then move to public testnets, then finally set a mainnet launch date. Developers are aiming for the second half of 2026, but nothing is locked in yet — the plan can still change. One thing is certain: testnets always launch before mainnet. If you’re building on Ethereum, that gap is your window to catch problems while they’re still cheap to fix. What Glamsterdam means for you If you hold ETH: nothing. Your balance, your addresses, and your keys are unaffected. There is no token migration of any kind, and anyone who tells you to “upgrade your ETH” for Glamsterdam is running a scam. If you run validators or nodes: client updates, on a deadline. Glamsterdam changes both layers, so execution clients (Geth, Nethermind, Besu, Erigon, Reth) and consensus clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine) all ship mandatory releases. Fork weeks are when self-managed infrastructure hurts most. Fusaka’s own activation is the recent example: the execution layer went smoothly, but a Prysm resource-exhaustion bug caused 248 missed blocks across 42 epochs, dropped network participation to 75%, and cost validators roughly 382 ETH in lost rewards. We looked at that incident in our comparison of Ethereum node clients. Glamsterdam touches far deeper consensus code than Fusaka did. This is the main reason to run on managed infrastructure through a fork like this one. Chainstack handles client updates, monitoring, and recovery across 70+ chains, so a fork means zero maintenance work on your side. Global Nodes route your requests across geo-balanced instances, which also means a single misbehaving client version in one region doesn’t take your app down. If you need a specific client, region, or configuration, Dedicated Nodes give you an exclusive machine with full archive and debug and trace access. If you build apps or indexers: two concrete work items. First, EIP-7708. If your product tracks ETH balances or transfers today, you’re probably calling trace methods like debug_traceTransaction to catch internal transfers. Chainstack exposes debug and trace APIs on archive nodes for exactly this workload, and that keeps working. But once transfer logs go live, you can move that pipeline to plain eth_getLogs queries, which are cheaper and simpler. Plan the migration; keep tracing for pre-Glamsterdam history. Second, gas assumptions. EIP-2780 restructures how the cost of a transaction is calculated, and the state repricing EIPs change deployment and storage costs. Hardcoded gas values in contracts, relayers, and wallets need a review. The way to do this properly is to run your test suite against a Glamsterdam testnet as soon as one is live. You can deploy Sepolia and Hoodi testnet nodes on Chainstack in a couple of minutes and fund your test accounts from the free Sepolia and Hoodi faucets. If you’re planning for scale: the combination of BALs and the wider ePBS propagation window points at a higher-throughput L1 in 2027 and beyond. More throughput means more blocks, more state, and more RPC volume for anyone indexing the chain. If your workload is heading that direction, flat-fee options like Chainstack’s Unlimited Node, with no per-request billing, make cost planning simpler than metered pricing as volume grows. Closing thoughts Glamsterdam is a builder-and-operator upgrade. Users won’t see a new feature the day it activates. What changes is the machinery underneath: block production moves into the protocol, execution gains a dependency map that permits parallelism, and gas prices shift toward the true cost of each resource. Those three changes are what allow the gas limit, blob counts, and L1 throughput to keep climbing after 2026 without pricing out node operators. The practical takeaway fits in three lines. Watch Forkcast for scope and dates. Test your gas assumptions and ETH-tracking logic on the testnets as soon as they fork. And make sure whoever runs your nodes, whether that’s you or Chainstack, has a clear plan for fork week. If you’d rather spend that week building instead of babysitting clients, spin up an Ethereum node on Chainstack and let the upgrade happen underneath you. Spin up an Ethereum node on Chainstack → FAQ What is the Ethereum Glamsterdam upgrade? Glamsterdam is Ethereum’s next major network upgrade after Fusaka, combining the Gloas consensus layer fork and the Amsterdam execution layer fork. It’s headlined by two changes: enshrined proposer-builder separation (EIP-7732), which moves block building into the protocol, and Block-Level Access Lists (EIP-7928), which enable parallel transaction execution. Core developers have called it the largest protocol change since the Merge. When is the Glamsterdam upgrade date? Glamsterdam is targeted for the second half of 2026, with no mainnet date locked yet. The upgrade is currently in the devnet phase, where client teams test the new rules on small coordinated networks. Public testnets like Sepolia and Hoodi will activate before mainnet, and Forkcast tracks the live status of scope and dates. Do I need to do anything with my ETH for the Glamsterdam upgrade? No. Your ETH balance, addresses, and private keys are completely unaffected by Glamsterdam. There is no token migration, swap, or upgrade of any kind. Anyone asking you to “upgrade your ETH” or move funds for Glamsterdam is running a scam — a warning that appears on ethereum.org’s official upgrade page. What is ePBS (EIP-7732) in Ethereum? Enshrined proposer-builder separation (ePBS) writes the split between block proposers and block builders directly into Ethereum’s consensus rules. The proposer commits to a builder’s bid, the builder reveals the execution payload later in the slot, and the protocol itself guarantees payment — making MEV-Boost relays optional instead of load-bearing. ePBS also expands the data propagation window from roughly 2 seconds to 9 seconds, creating room for bigger blocks and more blobs. What are Block-Level Access Lists (EIP-7928)? Block-Level Access Lists (BALs) give every Ethereum block a built-in map of all accounts and storage slots its transactions touch, plus the resulting state values. This lets nodes execute non-conflicting transactions in parallel and sync without replaying every transaction. Faster validation is the technical prerequisite for raising the block gas limit beyond today’s 60 million, with client teams discussing a future increase toward 200 million. What do validators and node operators need to do for Glamsterdam? All execution clients (Geth, Nethermind, Besu, Erigon, Reth) and consensus clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine) will ship mandatory releases that must be installed before activation. Validators also take on a new duty: the Payload Timeliness Committee (PTC), which attests to whether builders reveal payloads on time. Fork weeks carry real risk — Fusaka’s activation saw a client bug cost validators roughly 382 ETH — so have a clear upgrade plan, or run on managed infrastructure that handles client updates for you. Additional resources Build better with Ethereum Ethereum Fusaka: infra upgrade for real scaling How to get an Ethereum RPC endpoint (2026 guide) Best Ethereum RPC providers in 2026 How to deploy a self-hosted Ethereum node with Chainstack Ethereum RPC for forensics and compliance analytics: best providers 2026 #### EVM nodes: A dive into the full nodes vs. archive nodes Introduction  Networks based on the Ethereum Virtual Machine (EVM) typically can run two types of nodes: a full node and an archive node.  Chainstack supports many popular EVM-based networks, including Ethereum, Polygon, BNB Smart Chain, C-Chain of Avalanche, Fantom, Harmony.  The difference between a full node and an archive node is that while both store the full blockchain data that can be used to replay the network states, the archive node additionally stores the network state at each block in an archive that can be queried.  That’s the short explanation.  In this article, we are going to dive into some details, differences, and operations examples for the full node and the archive node.  Geth and Erigon  First, a quick word on the node clients.  Go Ethereum (Geth) is by far the most popular client software for EVM-based networks and probably in the entire blockchain space in general. For the Ethereum mainnet, you can check the node client distribution at the ethernodes crawler data.  Chainstack supports running Ethereum nodes using the Geth client or the Erigon client (formerly, Turbo-Geth)—the latter being another Go implementation focused on efficiency and the second most popular client.  In this article, we are focusing on the Geth and Erigon implementations for the full and the archive node modes.  Full nodes and archive nodes Let’s dive into the details.  What is a full node Stores full blockchain data. Verifies all blocks and states. All states can be regenerated from a full node, although this will require additional state re-execution past the default 128 blocks for most EVM-based clients.  A full EVM node keeps the current state of the blockchain and handles read-only calls and state-changing calls (transactions). A full node prunes the blockchain data to conserve disk space and reduce the sync time but stores enough data to recalculate the chain events in case of necessity. This makes it more efficient to run, but it also limits requests to a specific number of blocks (128 blocks, typically).  For example, on the Ethereum mainnet, with the average time to produce a new block at about 13 seconds, you can only retrieve the chain states from the last 28-29 minutes. Although, in theory, you can use a full node to recalculate all the intermediate states, it would take an exceptionally long time and would be very resource-intensive, and your node might run out of memory and stop.  Default back states and the “Missing trie node” error  Depending on the chain you access and the client you are using, you will be limited in how many blocks for the available back states you can access:  Ethereum: 128 blocks Polygon: 128 blocks BNB Smart Chain: 128 blocks Avalanche C-Chain: 32 blocksFantom: The Go Opera client does not prune information, so there is no difference between a full and an archive node. Harmony: 128 blocks You will receive a missing trie node error if you try to query a block not accessible from a full node.  In general, getting the missing trie node error means you need an archive node.  What is an archive node? Stores everything kept in the full node and builds an archive of historical states.  These are full nodes that have been configured to run in archive mode.  Archive nodes essentially contain a snapshot of the entire blockchain and hold all previous states of the network from the genesis block (first block mined). This makes archive nodes great for quickly querying historical data without the state regeneration, and this is ideal for developers who create analytical tools, DApps, and other services that need quick history access. As archive nodes keep the entire chain states, they are also much bigger in size than the full nodes. At the time of writing, the Ethereum mainnet is about 10 TB in size (etherscan.io).  To start a new archive node, the system needs to synchronize all that data before it can start running on the network. This leads to high starting and maintenance costs, given that at this point it would take months to complete the syncing process, and constant maintenance is necessary to keep up with the growing disk size requirements.  Archive mainnet state sizes for reference  Note that these keep growing. The data is valid at the time of this blog post.  Ethereum mainnet: ~12 TBPolygon mainnet: ~16 TBBNB Smart Chain: ~7 TBFantom mainnet: ~4 TBHarmony mainnet: ~20 TBAvalanche mainnet: ~3 TB    Note that BNB Smart Chain uses the Erigon client, which allows keeping the size of the network smaller compared to Geth. This shows how much data is involved in all these chains, and if you want to access your own node, you will need to download all that data and validate it before being able to run the node. This can take months for an archive node.  How to deploy a node on blockchain within minutes? You can deploy your own node in a matter of minutes thanks to Chainstack. Using our fast synchronization technology called Bolt, Chainstack allows you to deploy a full or archive node in just a few minutes, saving weeks and months of work and resources.  To get a node:  Sign up with Chainstack.Deploy a full or an archive node.  Call methods that take past states Now it is clear that to access data older than the last 128 blocks, we need to use an archive node. The following Geth JSON-RPC methods include a parameter allowing the user to specify which block to retrieve the data from:  eth_getBalance eth_getCode eth_getTransactionCount eth_getStorageAt eth_call  Let’s have a look at each of these methods and try them out.  Again, if you need a quick access to an archive node, get one with Chainstack.  eth_getBalance  Retrieve an address balance at a specific point in time (block). For details, see Ethereum Wiki: eth_getBalance. Web3.py Retrieve an address balance from the state at block number 1 using web3.py.  Running this code on a full node will return an error, as we are trying to get the balance from an address in block number 1. from web3 import Web3 node_url = "CHAINSTACK_ARCHIVE_NODE_URL" web3 = Web3(Web3.HTTPProvider(node_url)) balance = web3.eth.get_balance("0x9D00f1630b5B18a74231477B7d7244f47138ab47", 1) print(web3.fromWei(balance, "ether")) We can still run eth_getBalance on a full node but cannot go back more than 128 blocks. Web3.js Retrieve an address balance using web3.js. In this case we are the state at block number 14641000.  var Web3 = require('web3') var node_URL = 'CHAINSTACK_ARCHIVE_NODE_URL' var web3 = new Web3(node_URL) web3.eth.getBalance('0x9D00f1630b5B18a74231477B7d7244f47138ab47', 14641000, (err, balance) => { console.log(web3.utils.fromWei(balance, 'ether')) }) The fromWei method is used to convert the number we receive from the node (Wei) into a number that makes sense to us.   cURL Retrieve an address balance using cURL. In this case we are querying the state at block number 14641000. Note that the block number and the returned value are in hex. curl CHAINSTACK_ARCHIVE_NODE_URL \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_getBalance","params":["0x9D00f1630b5B18a74231477B7d7244f47138ab47", "0xDF6768"],"id":1,"jsonrpc":"2.0"}' eth_getCode  Returns the compiled bytecode of a smart contract.  For details, see Ethereum Wiki: eth_getCode. The example below will get you the bytecode of the Uniswap token at the state of the very first block when it was deployed: block 10861674. Web3.py from web3 import Web3 node_url = "CHAINSTACK_ARCHIVE_NODE_URL" web3 = Web3(Web3.HTTPProvider(node_url)) code = web3.eth.get_code("0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", 10861674) print(code) Web3.js var Web3 = require('web3') var node_URL = 'CHAINSTACK_ARCHIVE_NODE_URL' var web3 = new Web3(node_URL) web3.eth.getCode('0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984', 10861674, (err, byte) => { console.log(byte) }) cURL Note that the block number is in hex. curl CHAINSTACK_ARCHIVE_NODE_URL \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_getCode","params":["0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984", "0xA5BC6A"],"id":1,"jsonrpc":"2.0"}' The getCode RPC method can be used to verify if a contract has been deployed or destroyed correctly.   eth_getTransactionCount  Returns the number of transactions sent from an address at the state of a specific block.  For details, see Ethereum Wiki: eth_getTransactionCount. The example below will fetch the transaction count (nonce) of an address at the state of block 14674300. Web3.py from web3 import Web3 node_url = "CHAINSTACK_ARCHIVE_NODE_URL" web3 = Web3(Web3.HTTPProvider(node_url)) tx_count = web3.eth.get_transaction_count("0x9D00f1630b5B18a74231477B7d7244f47138ab47", 14674300) print(tx_count) Web3.js var Web3 = require('web3'); var node_URL = 'CHAINSTACK_ARCHIVE_NODE_URL'; var web3 = new Web3(node_URL); web3.eth.getTransactionCount('0x9D00f1630b5B18a74231477B7d7244f47138ab47', 14674300, (err, count) => { console.log(count) })  cURL Note that the block number and the returned value are in hex. curl CHAINSTACK_ARCHIVE_NODE_URL \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_getTransactionCount","params":["0x9D00f1630b5B18a74231477B7d7244f47138ab47", "0xDFE97C"],"id":1,"jsonrpc":"2.0"}' The getTransactionCount RPC method is used to retrieve the nonce of an address, the nonce is an integer value representing how many transactions that account sent. It is useful to avoid duplicate transactions.  eth_getStorageAt Returns the value from a storage position at a given address.  For details, see Ethereum Wiki: eth_getStorageAt. The examples below will return the storage value of the simple storage contract. The last value change was in block 7500943, so you can use it as a reference point to retrieve the different storage values in time. Web3.py from web3 import Web3 node_url = "CHAINSTACK_ARCHIVE_NODE_URL" web3 = Web3(Web3.HTTPProvider(node_url)) storage = web3.eth.get_storage_at("0x954De93D9f1Cd1e2e3AE5964F614CDcc821Fac64", 0, 7500943) print(storage.decode("ASCII")) Web3.js var Web3 = require('web3'); var node_URL = 'CHAINSTACK_ARCHIVE_NODE_URL'; var web3 = new Web3(node_URL); web3.eth.getStorageAt('0x954De93D9f1Cd1e2e3AE5964F614CDcc821Fac64', 0, 7500943).then(result => { console.log(web3.utils.hexToAscii(result)); }); cURL Note that the block number and the returned value are in hex. curl CHAINSTACK_ARCHIVE_NODE_URL \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_getStorageAt","params":["0x954De93D9f1Cd1e2e3AE5964F614CDcc821Fac64", "0", "0x72748F"],"id":1,"jsonrpc":"2.0"}' eth_call  Does a read-only call on the blockchain without changing any state. For details, see Ethereum Wiki: eth_call. The examples below call the balanceOf function of the Chainlink token for the Chainlink VRF coordinator address at block 14000000. Web3.py import json from web3 import Web3 node_url = "CHAINSTACK_ARCHIVE_NODE_URL" web3 = Web3(Web3.HTTPProvider(node_url)) abi=json.loads('[{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"totalSupply","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_from","type":"address"},{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transferFrom","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"decimals","outputs":[{"name":"","type":"uint8"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"},{"name":"_data","type":"bytes"}],"name":"transferAndCall","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_subtractedValue","type":"uint256"}],"name":"decreaseApproval","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"}],"name":"balanceOf","outputs":[{"name":"balance","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"symbol","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transfer","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_addedValue","type":"uint256"}],"name":"increaseApproval","outputs":[{"name":"success","type":"bool"}],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"},{"name":"_spender","type":"address"}],"name":"allowance","outputs":[{"name":"remaining","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"inputs":[],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":true,"name":"from","type":"address"},{"indexed":true,"name":"to","type":"address"},{"indexed":false,"name":"value","type":"uint256"},{"indexed":false,"name":"data","type":"bytes"}],"name":"Transfer","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"owner","type":"address"},{"indexed":true,"name":"spender","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Approval","type":"event"}]') address = "0x514910771AF9Ca656af840dff83E8264EcF986CA" contract = web3.eth.contract(address=address, abi=abi) balance = contract.functions.balanceOf('0x271682DEB8C4E0901D1a1550aD2e64D568E69909').call(block_identifier=14000000) print(web3.fromWei(balance, 'ether')) Web3.js const Web3 = require('web3'); const web3 = new Web3(new Web3.providers.HttpProvider("CHAINSTACK_ARCHIVE_NODE_URL")); web3.eth.defaultBlock = 14000000; web3.eth.call({ to: "0x514910771AF9Ca656af840dff83E8264EcF986CA", data: "0x70a08231000000000000000000000000271682deb8c4e0901d1a1550ad2e64d568e69909" }) .then(result => { console.log(web3.utils.fromWei(result)); }); cURL Note that the block number and the returned value are in hex. curl CHAINSTACK_ARCHIVE_NODE_URL \ -X POST \ -H "Content-Type: application/json" \ --data '{"method":"eth_call","params":[{"from":null,"to":"0x514910771AF9Ca656af840dff83E8264EcF986CA","data":"0x70a08231000000000000000000000000271682deb8c4e0901d1a1550ad2e64d568e69909"}, "0xD59F80"],"id":1,"jsonrpc":"2.0"}' Conclusion  As a recap, archive nodes hold the “history” of the blockchain and have a record of every previous state of the network from the genesis block. This means that historical data can be accessed can be retrieved very quickly, and using Chainstack you can set up an archive node in a breeze!  Archive nodes are a great tool for development, especially when you need to query past data, for example if you are forking the mainnet using Hardhat, Ganache, and other development frameworks used to run a local simulated blockchain for testing and development purposes, or if you’re creating a blockchain explorer, blockchain analytics tools, blockchain indexing with protocols like The Graph and so on, because you’ll have instant access to the full chain. If you are building a DApp that needs data from within the latest 128 blocks, a full node would suffice.  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### EVM speed tester: Measure how fast nodes respond to transactions  Overview Ethereum is the most popular network among all blockchain protocols—it is adopted in a wide range of digital asset applications, including NFT and decentralized finance industries. Currently, it has over one million transactions every day and there are more than 6000 nodes running all over the world. One of the most frequently asked questions from developers is how fast can a node catch a transaction in the mempool. The mempool of Ethereum, or any EVM-based network, also called transaction pool or txpool, is the dynamic in-memory area where pending transactions reside before they are included in a block and thus become static. See also Exploring the methods of looking into Ethereum’s transaction pool. The speed of a node receiving a transactions in its txpool is important in many ways: for a DeFi service provider, it means a better user experience; for NFT traders, it means being able to sell and buy tokens quicker. Would it be useful to have a tool to measure the txpool performance of a node? EVM speed tester is the tool that does exactly that. It measures how fast a node can get a transaction in its txpool sent from a different node. It is installation free and easy to use. Prerequisites An EVM address and a private key. Make sure there are some funds on the address to pay for the transaction. For testnets, use a faucet. Any EVM-based node—for example, Ethereum, Polygon, Binance Smart Chain, Avalanche C-Chain, Fantom. Some funds in the wallet, testnet Faucet is perfectly fine. At least two different nodes on the same network with a WebSocket endpoint: To get nodes: Sign up with Chainstack.Deploy a node.Get the deployed node’s WSS endpoint. About the speed tester The EVM speed tester is a serverless web app. You can simply open it on this JSFiddle. The code is explained in the second half of this article, it is recommended to any reader who wants to customize it or dive into the mechanics. Two WebSocket endpoints and one address are required to run the app. After the program start, the transaction is initiated on both endpoints one after another. It is a simple transaction. The address (identified using the private key) sends the network’s base currency (e.g., ether) to itself over and over again. So the user can see how fast both nodes received the transaction. This is a sample output when the code is successfully run: Imagine playing fetch with two dogs, this code is similar to that. The difference is now both dogs take turns throwing the ball to keep the game going. This app was tested with the Ethereum Ropsten testnet but it should be easily configured to use on any other EVM networks, mainnet, or testnet. Using the speed tester The tool needs an address and a private key to send transactions. Every transaction burns a small amount of gas fee, so please try it on testnets before running it on the mainnet. The code is explained in detail in the next section. If further assurance is needed, feel free to jump on our Discord. The live code: Enter the private key and your address.Enter the amount of the base network currency (e.g., ether) to transfer in each transaction. The default value is 0.1 ether, the minimum value is 1 wei.Enter the address of the WebSocket endpoints, it usually starts with ws:// or wss://.Click start;Wait until both connections are established, the speed test starts after that: Now the code is up and running. Your address is sending the currency to itself over and over again. It is a meaningless transaction but it helps to leverage the performance of nodes behind these endpoints. Inner workings The only external source referenced in this app is web3.js, it was hosted on cdn.jsdelivr.net and it is also used in this tutorial on Ethereum’s official website. Init() The initialization function is bare. Mainly getting user inputs and passing it to another function initNode(): function init(){ walletPrivateKey = document.getElementById("walletPrivateKey").value walletPublicKey = document.getElementById("walletPublicKey").value wsURL1 = document.getElementById("wsURL1").value wsURL2 = document.getElementById("wsURL2").value node1IsReady = false node2IsReady = false transValue = Web3.utils.toWei(document.getElementById("transValue").value,"ether") initNode ("node 1",wsURL1,"web3_1","subscribe_1","timer_1","node1IsReady") initNode ("node 2",wsURL2,"web3_2","subscribe_2","timer_2","node2IsReady") } InitNode() InitNode function initializes a node with the given parameters. function initNode(node_name, wsURL, web3_name, subscribe_name, timer_name,readyFlag_name) node_name — node 1 or node 2.wsURL — the WebSocket URL the user filled in.web3_name — reference to the web3 global instance. The web3 object is from web3.js and is declared at the beginning of code block. In functions, it is referenced as window[“web3_1”] or window[“web3_2”], therefore the parameter is a string. Same for subscirbe_name, timer_name, and readyFlag_name.subscribe_name — reference to the subscription instance. It keeps a WebScoket connection and receives feedback when events are triggered.timer_name — reference to the variables record time.readyFlag_name — reference to a boolean object for the nodes’ readiness for a new transaction. Below is the pseudocode of initNode(): Create a new web3 instance. Connect to the wallet using private key. Get the balance of the wallet to test if everything is successfully setup. If yes: Update connection success message. Start Ethereum subscription on two events: “connected”: If both node1 and node2 are ready, initiate the first transaction “data” : Waiting for pending transactions. When it comes in, calculate the difference between its initiation and receiving timestampe. This event triggers for all transactions, so unrelated transactions are filtered. pitch() Transaction is crafted and sent out in the pitch function. function pitch(){ var web3_pitcher updateInfo("***************") updateInfo(pitcher + " is the sender now") if(pitcher == "node 1") web3_pitcher = web3_1 else web3_pitcher = web3_2 node1IsReady = false node2IsReady = false pitch_time = new Date(); web3_pitcher.eth.sendTransaction({ from: walletPublicKey, to: walletPublicKey, value: transValue, gas:"21000" }).on('sent', function(payload){ }) .on('sending', function(payload){ }) .on('transactionHash', function(hash){ }) .on('receipt', function(receipt){ }) .on('error',function(error){ }); } When the transaction is finalized, the listening event on.receipt is called. The pitcher is changed and a new transaction is initiated by calling the pitch() function again. .on('receipt', function(receipt){ updateInfo("transaction finalised") endedTrxHistory.push(receipt.transactionHash) console.log(endedTrxHistory) if (!node1IsReady) updateInfo("node 1 misses") if (!node2IsReady) updateInfo("node 2 misses") if(pitcher == "node 1") pitcher = "node 2" else pitcher = "node 1" pitch() }) Conclusion Read more about the web3.js subscription and transaction methods. Feel free to tweak around with the code and try it out on other networks. Have fun playing. Happy coding! One more thing There is an upgradeable version of the app. It is called: The node-lympics! It supports an unlimited number of nodes and a user-defined number of rounds. It is in GitHub repo too, enjoy! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### EVM: Practical explanation of how gas fee works Intro You broadcast a transaction on Ethereum (or any EVM network) using tools like web3.js or ethers.js, expecting it to be included in the network, but… nothing happens. After seconds or even minutes, you finally get the error: Transaction Was Not Mined Within N Blocks. Your transaction is stuck. Why? What happens to it now? How can you get it mined? How to prevent such cases next time? This article explains what goes on behind the scenes, walking through all the concepts needed to fully understand the issue and the solutions. Gas fees matter so much that Vitalik recently suggested creating a gas futures market! By the end of this article you’ll see he probably wasn’t kidding. TL;DR Your transaction gets stuck and eventually errors with “not mined within N blocks” when the priority fee (tip) you offered validators is too low compared to competing transactions. EIP-1559 splits the fee into a dynamically adjusting baseFeePerGas (burned) and a priorityFeePerGas (goes to validator). If priorityFeePerGas is too small, validators ignore your transaction. Fix it by sending a new transaction with the same nonce and higher fees (speed-up) or 0 ETH to yourself (cancel). Why “Not Mined Within N Blocks” Happens You prepared everything, created and signed a transaction, and sent it on-chain, but you received an error like this: Transaction started at 78840812 but was not mined within 61 blocks. Please make sure your transaction was properly sent and there are no previous pending transactions for the same account. However, be aware that it might still be mined! Transaction Hash: 0xdbf108… Why wasn’t the transaction included in a block on time? Short answer: The transaction wasn’t a priority for validators, so they preferred transactions that were worth more to them. When a transaction is sent to the network, it first goes into the mempool, a pool full of transactions pending for confirmation. To put it simply, validators choose the most profitable transactions to include in the block, and the least profitable ones get stuck in the mempool, like yours did. In today’s Ethereum, most validators don’t pick transactions themselves. Instead, they use MEV-Boost to outsource block building to specialized builders who compete in auctions to build the most profitable blocks possible. Many transactions also skip the public mempool entirely by going privately to these builders (e.g., via Flashbots Protect). We’ll cover MEV-Boost and private mempools in upcoming articles. What determines a transaction’s priority for validators? Each transaction requires some work by network resources, and pays a fee for each unit of work it requires. The fee is shared between the network and the validator. The higher the fee paid to the validator per unit of work, the higher the transaction’s priority. This leads to three key questions: What determines the amount of work a transaction requires? What determines the cost per unit of work? How is the fee distributed between network and validator? What determines the amount of work a transaction requires? Every transaction consumes network resources like computation, storage, etc. Standards define exactly how much work each operation requires. This work is measured in units called Gas. To get a feel for gas costs, here are a few real examples: Adding two numbers: 5 gas Storing 1 KB of data on-chain: ~700,000 gas Base transaction cost (signature verification, account state updates, nonce increment, and network overhead): 21,000 gas  Although the amount of gas consumed by a transaction can be estimated in advance, the exact amount is only known after it has been fully executed by validators, as it depends on factors like network state that can change with every block. When broadcasting a transaction, a parameter called gasLimit must be specified. The gasLimit defines the maximum amount of gas the transaction is allowed to consume. Two major cases might happen after executing a transaction: Final used gas is less than gasLimit: the remaining gas won’t be used. Transaction only pays for the gas it consumes. Transaction tries to consume more than the gasLimit: It fails with an  out of gas error, all state changes are reverted, yet the transaction is still included and the full gasLimit is charged. The gasLimit should be set high enough to cover the worst-case consumption (typically 10–20 % above the estimate). If set too high, nothing is lost. You are never charged for unused gas. If set too low, the transaction fails without reducing the actual cost. What determines the cost per unit of work? The previous section explained how gas usage of a transaction is specified and controlled. Now the focus is on determining how much fee a transaction is willing to pay per gas. Once this value –the price of each gas unit, called feePerGas– is determined, the total fee calculation is simple: totalFee = gasUsed * feePerGas As mentioned earlier, feePerGas consists of two parts: network fee and validator fee. Network fee, called baseFeePerGas, is calculated based on how full the last block was. When more transactions are competing to be mined, baseFeePerGas rises. On the other hand, when the previous block wasn’t as full, baseFeePerGas drops. So baseFeePerGas is the same for all transactions in a block, and cannot be set individually per transaction. Now let’s get to the validator fee, called the priority fee. The name explains it: higher priority fee directly increases a transaction’s chance of being included. The logic is clear: totalFee = gasUsed * feePerGas feePerGas = BaseFeePerGas + PriorityFeePerGas → totalFee = gasUsed * (BaseFeePerGas + PriorityFeePerGas) How is the fee distributed between network and validator? The answer lies in two values that must be specified when broadcasting a transaction: maxFeePerGas and maxPriorityFeePerGas. The logic becomes clearer once you look at the variables together. baseFeePerGas is determined by the network, and maxFeePerGas is set in the transaction. The difference becomes the priorityFeePerGas, with maxPriorityFeePerGas as a ceiling. PriorityFeePerGas = min(maxPriorityFeePerGas, maxFeePerGas - BaseFeePerGas) In summary: A transaction specifies two ceilings, one for total fee and one for priority fee. By default, the maximum priority fee is charged for validators, and the base fee is burned by the network. But if the base fee rises so that base fee + max priority fee would exceed the total fee cap, the priority fee is lowered to keep the sum within the limit. All of these lead to the key point: this is how priorityFeePerGas gets calculated. When a transaction is stuck in the mempool, it’s because priorityFeePerGas is too low, which results directly from one of these two: maxPriorityFeePerGas is set too low Many new transactions arrived in the mempool, increasing baseFeePerGas and reducing maxFeePerGas – baseFeePerGas. What happens to transactions stuck in the mempool? There are three main possible outcomes: Transaction gets dropped from the mempool: If maxFeePerGas falls below baseFeePerGas, the transaction gets dropped. Additionally, different nodes have different expiration times, after which they drop the transaction from their mempool. Transaction gets mined before being dropped: When network congestion drops and the base fee falls, validators will pick up even low priority fee transactions. The sender either cancels the transaction or speeds up its mining. Since options 1 and 2 are unpredictable, developers typically prefer option3, so let’s see how it is done. How to cancel a stuck transaction or speed up its mining? Fortunately, fixing a stuck transaction is straightforward. Speed up: Send the same transaction with the same nonce but higher values for: maxFeePerGas: if the network’s baseFeePerGas has increased and/or maxPriorityFeePerGas: if it was set too low compared to competing mempool transactions. Cancel: Send a 0-ETH transaction to yourself using the same nonce and slightly higher fees. Conclusion Understanding EVM gas mechanics is essential for every Ethereum developer. Mastering these fundamentals lets you set the right fees from the start, avoid stuck transactions, instantly fix them with speed-ups or cancels when needed, and prevent unnecessary overpayment during congestion spikes while keeping transactions reliably fast and smooth. Reliable Ethereum RPC infrastructure Getting started with Ethereum on Chainstack is fast and straightforward. Developers can deploy a reliable Ethereum node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Ethereum RPC access, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Ethereum low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Ethereum RPC endpoint, and experience how easy it is to build and scale on Ethereum with Chainstack – one of the best RPC providers. #### Executing public & private transactions on JPMorgan’s Quorum with Web3 By Lee Ruian, Thomas This guide is intended for anyone interested in experimenting with Quorum. It is an introduction to deploying contracts and sending both public and private Quorum transactions using the web3.js library. This article will cover: Formatting your smart contract Setting up your network / infrastructure with Chainstack Quorum Public Transactions Quorum Private Transactions To better illustrate the mentioned features, we will introduce a simplified use case that covers a working implementation combining IoT and blockchain to monitor the participants’ storage facility temperature. Background A group of storage companies has decided to form a storage consortium to share information and automate processes on the blockchain. In this case, they have decided to use Quorum. In this tutorial, we will cover two use cases: public and private transactions. Transactions are created by different parties to interact with one another within the consortium they belong to, each transaction will either deploy a contract or execute functions within that contract to upload data to the network. These updates will then be replicated across all nodes in the consortium. Public transactions are designed to be publicly viewable by all parties within the consortium. Private transactions, on the other hand, provides an additional layer of privacy. It enables transactions and contracts to be accessible only by organisations that have been granted permission to do so. We will use the same smart contract for both use cases to better explain how public and private transactions work. Smart contract Below is a simple smart contract that I’ve created for this use case. It has a public variable temperature, which can be modified using the set method and fetched using the get method. pragma solidity ^0.4.25; contract TemperatureMonitor { int8 public temperature; function set(int8 temp) public { temperature = temp; } function get() view public returns (int8) { return temperature; }} For the contract to work with web3.js, it has to be first formatted into its respective ABI and bytecode formats. Using the function below called formatContract compiles the contract using Ethereum’s solc-js compiler. function formatContract() { const path = './contracts/temperatureMonitor.sol'; const source = fs.readFileSync(path,'UTF8'); return solc.compile(source, 1).contracts[':TemperatureMonitor'];} The formatted contract should look something like this: // interace [ { constant: true, inputs: [], name: ‘get’, outputs: [Array], payable: false, stateMutability: ‘view’, type: ‘function’ }, { constant: true, inputs: [], name: ‘temperature’, outputs: [Array], payable: false, stateMutability: ‘view’, type: ‘function’ }, { constant: false, inputs: [Array], name: ‘set’, outputs: [], payable: false, stateMutability: ‘nonpayable’, type: ‘function’ } ] // bytecode 0x608060405234801561001057600080fd5b50610104806100206000396000f30060 806040526004361060525763ffffffff7c0100000000000000000000000000000000 0000000000000000000000006000350416636d4ce63c81146057578063adccea1214 6082578063faee13b9146094575b600080fd5b348015606257600080fd5b50606960 ae565b60408051600092830b90920b8252519081900360200190f35b348015608d57 600080fd5b50606960b7565b348015609f57600080fd5b5060ac60043560000b60c0 565b005b60008054900b90565b60008054900b81565b6000805491810b60ff1660ff 199092169190911790555600a165627a7a72305820af0086d55a9a4e6d52cb6b3967 afd764ca89df91b2f42d7bf3b30098d222e5c50029 Now that the contract is formatted and ready, we will move on to set up the blockchain infrastructure to deploy the contract. Deploying the Quorum nodes Deploying blockchain nodes requires deep technical expertise, especially when it comes to synchronising of nodes within a network through the command line interface (CLI). I believe that most people have had a tough time setting up, maintaining or troubleshooting their own blockchain networks. Manual deployment is tedious for anyone who does not have the experience, interest, or the time to execute a long list of dependencies and protocol configurations. For such developers, I highly recommend using a blockchain-platform-as-a-service that time setting up, maintaining or troubleshooting their own blockchain. The company that I work at, Chainstack, does that for you. The chainstack platform takes away the pain and frustration of learning how to quickly set up your decentralised network and maintaining the blockchain nodes. The platform is cloud-agnostic and multi-protocol. It is literally a one-stop solution that helps you not only experiment with multiple cloud and protocol configurations, but also launch and maintain a production grade blockchain network. The Quorum explorer feature on Chainstack provides a better view of how blockchain and smart contracts work. Below are screenshots on how I used Chainstack to set up the Quorum Raft network with 3 nodes for this use case. For starters, let’s create our first project. You can name it what you wish. Create a project Create Quorum Raft Network A default node will be created together with the network. We then proceed to add two more nodes to the network. Create nodes Voila! Here we have our very own network with three fully functional nodes. The node details page shows the RPC, public key and other node-related information Now that the infrastructure is ready, we will go into depth explaining code, on how to deploy smart contracts and execute transactions using web3.js. Public transactions Background: Localised temperatures are a tremendous influence in cutting costs for heat-sensitive storage facilities, especially for sub-zero requirements. By enabling companies to share the ambient temperature of their geographical locations in real time and recording them on an immutable ledger, business participants are able to decide which area is optimal for heat-sensitive storage facilities without extended periods of market research. Infrastructure illustration We will execute 3 different tasks as shown on the diagram above: 1. Deploying smart contract through Node1 const contractAddress = await deployContract(raft1Node);console.log(`Contract address after deployment: ${contractAddress}`); 2. Setting the temperature on Node2. This should update the temperature to 3 degrees. const status = await setTemperature(raft2Node, contractAddress, 3);console.log(`Transaction status: ${status}`); 3. Node3 retrieves the temperature from the smart contract; it should return 3 degrees. const temp = await getTemperature(raft3Node, contractAddress);console.log(‘Retrieved contract Temperature’, temp); Below we will go into more details on how to execute public transactions on Quorum nodes with web3.js. Initiate web3 instance with RPC for the 3 nodes: const raft1Node = new Web3( new Web3.providers.HttpProvider(process.env.RPC1), null, { transactionConfirmationBlocks: 1, },); const raft2Node = new Web3( new Web3.providers.HttpProvider(process.env.RPC2), null, { transactionConfirmationBlocks: 1, },); const raft3Node = new Web3( new Web3.providers.HttpProvider(process.env.RPC3), null, { transactionConfirmationBlocks: 1, },); Next we’ll deploy the smart contract: // returns the default account from the Web3 instance initiated previously function getAddress(web3) { return web3.eth.getAccounts().then(accounts => accounts[0]);} // Deploys the contract using contract's interface and node's default address async function deployContract(web3) { const address = await getAddress(web3); // initiate contract with contract's interface const contract = new web3.eth.Contract( temperatureMonitor.interface ); return contract.deploy({ // deploy contract with contract's bytecode data: temperatureMonitor.bytecode, }) .send({ from: address, gas: '0x2CD29C0', }) .on('error', console.error) .then((newContractInstance) => { // returns deployed contract address return newContractInstance.options.address; });} web3.js provides two methods to interact with the contract: call and send. We can update the contract’s temperature by executing the set method using web3’s send method. // get contract deployed previouslyasync function getContract(web3, contractAddress) { const address = await getAddress(web3); return web3.eth.Contract( temperatureMonitor.interface, contractAddress, { defaultAccount: address, } );} // calls contract set method to update contract's temperatureasync function setTemperature(web3, contractAddress, temp) { const myContract = await getContract(web3, contractAddress); return myContract.methods.set(temp).send({}).then((receipt) => { return receipt.status; });} Lastly, we will use web3’s call method to fetch the contract’s temperature. Note that the call method runs on the local node, hence no transaction on the blockchain will be created. // calls contract get method to retrieve contract's temperatureasync function getTemperature(web3, contractAddress) { const myContract = await getContract(web3, contractAddress); return myContract.methods.get().call().then(result => result);} Now we are ready to run the full public.js, which should show the following results. // Execute public scriptnode public.js Contract address after deployment: 0xf46141Ac7D6D6E986eFb2321756b5d1e8a25008FTransaction status: trueRetrieved contract Temperature 3 Next, as shown below, we can access records via the Quorum explorer on Chainstack. All 3 nodes have interacted with the ledger, and the transactions were updated as expected: The first transaction deployed the contract The second transaction set the contract’s temperature to 3 degrees. Getting temperature reading interacts only with the local node which does not update the network, hence no block / transaction was created. Quorum Explorer Private transactions Background: A common business requirement is secured data encryption. Take an example where a supermarket rents storage solutions from a vendor for storage of perishables such as seafood: The vendor will transmit temperature readings every 30 seconds from its IoT devices for the supermarket to monitor. These readings should only be accessible between the supermarket and the vendor in the consortium network. Infrastructure illustration We will execute 4 different tasks as shown on the diagram above: I will use the same 3 nodes from the previous scenario (Public transaction) to demonstrate Quorum’s private transaction feature: Supermarket deploys a smart contract that is private between Supermarket and Storage Facility. External Party will not have the permission to access the smart contract. We call the get and set methods from both Storage Facility and External Party to demonstrate Quorum’s private transaction feature. 1. Deploying private contract for Supermarket and Storage Facility through Supermarket: const contractAddress = await deployContract( raft1Node, process.env.PK2,); console.log(`Contract address after deployment: ${contractAddress}`); 2. Set temperature from External Party (external node) and fetch temperature: The transaction will be successful despite not having access to the contract, but the setTemperature method will not mutate the temperature. // Attempts to set Contract temperature to 10, this will not mutate contract's temperature await setTemperature( raft3Node, contractAddress, process.env.PK1, 10,); // This returns nullconst temp = await getTemperature(raft3Node, contractAddress); console.log(`[Node3] temp retrieved after updating contract from external nodes: ${temp}`); 3. Set temperature from Storage Facility (internal node) and fetch temperature: The temperature from the smart contract in this scenario should return 12.Note that Storage Facility has permissioned access to the contract. // Updated Contract temperature to 12 degreesawait setTemperature( raft2Node, contractAddress, process.env.PK1, 12,); // This returns 12const temp2 = await getTemperature(raft2Node, contractAddress); console.log(`[Node2] temp retrieved after updating contract from internal nodes: ${temp2}`); 4. Fetch Temperature from External Party (external node) On step 3, the temperature was set to 12, but External Party has no access to the contract. The returned value should still be null. // This returns null const temp3 = await getTemperature(raft3Node, contractAddress); console.log(`[Node3] temp retrieved from external nodes after update ${temp}`); Below we will go into more details on how to execute private transactions on Quorum nodes with web3.js. Since most of the code are similar, I will only highlight the parts that are different from executing public transactions. Note that any contract uploaded to the ledger is immutable, hence permissioned access has to be granted to the respective nodes by including its public key on contract deployment, not after. async function deployContract(web3, publicKey) { const address = await getAddress(web3); const contract = new web3.eth.Contract( temperatureMonitor.interface, ); return contract.deploy({ data: temperatureMonitor.bytecode, }) .send({ from: address, gas: ‘0x2CD29C0’, // Grant Permission to Contract by including nodes public keys privateFor: [publicKey], }) .then((contract) => { return contract.options.address; });} Similar to contract deployment, transactions are made private by including network participants’ public key on execution. async function setTemperature(web3, contractAddress, publicKey, temp) { const address = await getAddress(web3); const myContract = await getContract(web3, contractAddress); return myContract.methods.set(temp).send({ from: address, // Grant Permission by including nodes public keys privateFor: [publicKey], }).then((receipt) => { return receipt.status; });} Now we are ready to run the full private.js, which should shows the following results. node private.jsContract address after deployment: 0x85dBF88B4dfa47e73608b33454E4e3BA2812B21D[Node3] temp retrieved after updating contract from external nodes: null[Node2] temp retrieved after updating contract from internal nodes: 12[Node3] temp retrieved from external nodes after update null Looking at the Quorum explorer below, you can see that 3 transactions were created. Deploying the Contract from Supermarket Executing the SetTemperature method from External party Executing the SetTemperature method from Storage Facility Quorum Explorer As you can see, both transactions went through, but only the transaction executed from Storage Facility managed to update the temperature on the contract. Hence, private transactions ensure the immutability of the data by internal parties and yet do not expose the data to external observers. I’ve attended quite a number of blockchain events in Singapore, but most of the talks are not very developer focused. Speaking to fellow developers at these meetups, I’ve realised that most of them are looking for something more technical, guides that can help them get started with writing their own smart contract, deploy them on the network, experiment and learn from it. Hence, I’ve written this article to share what I’ve learned at Chainstack, with the hope of helping fellow developers out there get started setting up their very own sandbox. Explore Chainstack Try Chainstack for free Access our developer resources and community Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Exploring the decentralized storage landscape Have you ever wondered how big the internet is? It seems like a rhetorical question, as the internet endlessly expands without any known limit to its capacity. And how would we quantify its actual size? We would have to consider the amount of data transferred, along with every website and its data being hosted across the internet. Think about the amount of data being created as you read this article—every Tweet and Google search query happening this instant is adding to the size of the internet. In 2021, there were 79 zettabytes of data generated. You can refer to this page here for memory size units. The size of the internet has been growing exponentially each year. And if you would like to read more about these data statistics, you can do so here. But how is this important for Web3? On-chain data and new possibilities For starters, we need to consider the cost of data on the Ethereum network. Depending on different variables such as network loads and market prices, it can easily cost well into the tens of millions to store a single gigabyte of data—this is neither scalable nor feasible. Also, with Ethereum’s EIP-4444 proposal, data older than a year will not be served by clients on the P2P layer. The case of Ethereum might be more extreme, but similar issues can also impact other L1 networks. The number of NFTs being minted with audio and video content is continuously increasing, along with the demand for storage. The option to offload on-chain data can significantly free up network resources and make it easier for validators to get started. This brings us to decentralized storage. Let’s see how it will transform the storage landscape in Web3, as well as provide more opportunities and solutions for the developers out there BUIDLing amazing DApps! Introducing decentralized storage Up until now, when we stored data in the cloud, it has traditionally been stored on centralized servers in a data center based in a singular location. This is centralized storage. Decentralized storage, on the other hand, is data stored across a distributed network of nodes in multiple locations. It works on a peer-to-peer (P2P) basis in which one user will rent out their free storage space to another user. The fees are paid in the native token of that particular storage protocol. This Web3 technology is revolutionizing the way data can be stored by offering benefits not achievable with traditional centralized storage systems. Figure 1: P2P storage, Source Sia Cost savings In centralized storage, the prices are dictated by policies intended to generate the maximum profit, and there’s not much competition in the market to challenge the status quo. Decentralized storage changes this by allowing a new paradigm of storage providers into the mix. These providers rent out their space at competitive rates to win the bid for the storage contract. Security and reliability Because Web3 data is stored on a distributed network, there is no single point of failure that can lose, destroy, or alter the data. The data redundancy policy of having it spread across the network ensures that it is always accessible and maintains integrity. On a centralized network, this is not the case, as data can be lost or corrupted. Enhanced privacy Blockchain data can be sharded and distributed to many hosts across a decentralized network. This makes the file inaccessible to everyone, except to the holder of the private key for that data chunk. Data on centralized servers is often a target for hackers because it can have immeasurable value. Easy data migration Data can easily be moved between IPFS-based storage providers if the user wants. This kind of flexibility allows a user a higher level of control with how and where their data is stored. By contrast, centralized providers can keep users locked into contracts with premium costs and penalties that don’t favor the user. A necessary progress As we move further into the Web3 space, the importance and relevance of decentralized storage cannot be emphasized enough. In fact, in order for Web3 to scale it is absolutely necessary to have a decentralized solution. A case in point, the aforementioned Ethereum EIP-4444 proposal makes it all but optional to store historical on-chain data somewhere that it can be accessed. Consider how young Web3 still is. Now consider how much data will be generated on-chain as the space continues to grow and attract more users. All the NFT’s that will be minted, all the websites that will be hosted, and other future uses of smart contract data will generate enough data to require its own storage space to keep networks running as efficiently as possible. Regardless of the protocol, decentralized storage is required for Web3 to grow and function properly. Figure 2: The exponential growth of data; Source firstsiteguide.com This is just taking into account the technical aspect based on how Web3 operates. There is also the developer aspect to decentralized storage. For developers, there is a new piece to the puzzle here. The ability to write smart contracts that interact with both on-chain and off-chain data is something that was not previously possible. Now developers have more power than ever to BUIDL world changing DApps with data. The current landscape At the moment, there are four primary L1 decentralized storage protocols serving both individual and enterprise levels of use. They are Filecoin, Storj, Arweave, and Sia, which we will break these down further to see how they compare with each other. Filecoin Filecoin is a sophisticated protocol offering data infrastructure solutions for multiple use cases. Its versatility also makes it one of the more misunderstood protocols. Enabled by its tokenomics, it allows users to store large quantities of data with smart contract support at incredibly affordable costs. Although primarily used for cold storage, with CDN retrieval, computation of data, and the Filecoin Virtual Machine (FVM), hot storage solutions are also possible with this protocol. Additionally, through Filecoin’s FVM smart contracts can be built on top of permanent storage allowing developers to create powerful DApps. The data itself may be stored off-chain, but its integrity and assurance of proper storage are kept via smart contracts on-chain. Storj Storj offers flexibility for developers of all types, from individual to enterprise. It strikes the perfect balance between Web2 and Web3 protocols with S3 compatible edge services coupled with its own native protocol and IPFS integration. Comprehensive management tools are made available seamlessly while service level agreements guarantee high standards of quality assurance. It offers a robust streaming capacity of up to 24 Gbps, making it an ideal choice for hot storage solutions. Moreover, its native token STORJ is an ERC20 standard and compatible with the Ethereum network, which ensures smooth usability while encrypting and coding data redundancy itself—ensuring maximum security without sacrificing performance. Arweave Arweave has gained significant attention in the decentralized storage space by providing innovative solutions to ensure data permanence. Notable solutions include their lazy smart contract and endowment model. This combined with strategic partnerships with major L1s have elevated Arweave as an attractive option for developers to BUIDL within its ecosystem. Despite being well-positioned in the decentralized storage market, some important issues must be considered. Without consequences for dropped data, there is no assurance that it will remain permanent. Furthermore, incentivizing miners to upload and retrieve large volumes of information timely can become much more expensive due to bandwidth charges. Finally, AR token price fluctuations heavily impact storage costs. Sia With Sia, you can benefit from both decentralization and cost-efficiency. The protocol’s miners and community hold 95% of the token, making it the most decentralized option for data storage. It also excels in hot storage use cases with an impressive TTFB (time to first byte) of around 200 milliseconds. Miners can get up and running with minimal start-up costs due to the hard drive being the only expense. The surging popularity of DApps on this platform has created a strong network within its community. However, their data model and messaging architecture are mostly proprietary and could still be used for improvement for interoperability between protocols. The obstacles to adoption While this technology shows high potential and is meant to solve many issues in the Web3 space, it is not met without challenges and limitations. We can break these down into two categories—technical and people challenges. Technical The storage service providers have distributed data centers with varying internet bandwidth capacities. However, providing a consistent Service Level Agreement (SLA) guarantee across all locations presents a challenge to overcome. Unless certain requirements are standardized, the quality of service can be affected from region to region. The interoperability between both varying L1 protocols and Web2 to Web3 providers is another set of challenges. To be able to query across multiple L1 protocols with differing messaging standards needs a solution. Additionally, data on a centralized server may need to communicate with data on a decentralized server. Centralized competition With centralized storage solutions, users often get more than storage. They are usually offered an entire suite of services for analytics, computations, and front-end applications. For enterprise users, this can be a driving factor in which providers to choose. It will be a matter of time before Web3 can offer similar tools. With data securely stored across a distributed network, centralized computing has difficulty querying it. This is an obstacle in the business-to-business adoption of decentralized storage systems. Without seamless integration with content delivery networks (CDN), this technology remains out of reach for many organizations. There has been a lack of tools to improve the developer and user experiences. A lack of proper SDKs and UIs has made the barrier to entry steeper for those looking to migrate into decentralized storage solutions. Although, this will not likely be the case for too much longer. People Humans are creatures of habit. Breaking old routines and adopting new ones is a challenge from one generation to the next. At present, centralized storage is a comfort zone for many users, and it does take time to build people’s trust and confidence in a new technology without skepticism and Luddite resistance. Additionally, when you need predictable results, you already know what you’re getting with centralized providers. On an enterprise level, costs need to be calculated to determine whether such a migration is beneficial and feasible. However, there are vast differences between the two storage mediums, and what may apply to one doesn’t apply to the other. For example, Web2 vendors tend to lock in customers with contacts that make migration costs expensive and inconvenient to business. This problem doesn’t exist in decentralized storage, but because of this, costs could be overestimated, and the migration discouraged. Knowledge matters There has not been a push for public awareness or education on decentralized storage and Web3 solutions in general. This leads to misconceptions and misinformation about the technology, like the possibility of data loss or privacy and security concerns—which both are actually strengths in Web3. But also, without the proper knowledge, the mechanics and benefits are perplexing for many users still. Lastly, some enterprises face the challenge of adhering to strict data protection regulations. If it is required to know the exact physical location of where the data is being stored, this can present legal difficulties. As you can see there are obstacles to overcome yet. But that’s the key word here—overcome. There are more opportunities than ever for Web3 developers to innovate and shape things into an ecosystem of abundance and high-level user experience. And with the Web3 community growing every day, the people’s challenges to this are decreased. A Web3 and Web2 comparison While there are many differences between decentralized and centralized storage, the main technical difference is in the data transfer protocols. In Web2, this was accomplished with a client-server model, HyperText Transfer Protocol (HTTP). In Web3, it is done using a P2P model via InterPlanetary File System (IPFS). Figure 3: HTTP vs. IPFS; source IPFS IPFS versus HTTP Rather than relying on one server to store files and deliver content as is typical in HTTP systems, IPFS uses nodes spread across an extensive network for file distribution and access. This innovative system allows for faster access to content with increased security and reliability compared to conventional HTTP connections with a central point. HTTP is location-based and utilizes URLs to locate resources with an IP address. IPFS is content-based and uses a content-addressing system called content ID (CID)—this is achieved through identifying each item based off its distinct cryptographic hash. IPFS accelerates content delivery by allowing data to be cached with multiple nodes, whereas HTTP caching is done directly on the user’s device. It offers great scalability through its caching capabilities, eliminating the need for client-side HTTP cache. This allows content to be efficiently stored, served from multiple nodes, resulting in optimal performance. HTTP is primarily designed for delivering web-centric content, like HTML and CSS. However, IPFS has the capacity to distribute a much broader range of information, from photos and videos to large files with complex data sets. How decentralized storage works The mechanics of how decentralized storage operates are much simpler than the mystery surrounding Web3 solutions. Data is stored in a network of nodes which are not controlled by any single entity. And this network is geographically distributed, which makes it more resistant to failure, censorship, and data breaches. When the data is stored on the network, it is divided into smaller chunks and encrypted before being stored on multiple nodes in the network. Because of the tamper-proof nature of the blockchain and the fact that no single node controls the entire set of data, it is incredibly difficult for hackers to access sensitive information. When retrieving data from the network, a user’s request will pull the necessary data chunks from the various network nodes and reassemble them. This entire process of data retrieval is transparent to the user, who gets to access the data like if it was stored on centralized servers. Figure 4: Saving and retrieving a file with decentralized storage Security and privacy Similar to centralized systems, security and privacy remain key priorities in decentralized storage systems. To accomplish this; encryption, consensus algorithms, and smart contracts are used in conjunction with each other to ensure that data remains secure and private within the network. Data security Data security is strengthened through encryption. Before being transferred and stored onto the network, confidential information is encrypted to prevent unauthorized access. When requested by users, data remains safely protected until decryption takes place—ensuring that sensitive information stays secure at all times. Consensus mechanism Consensus algorithms act as a cornerstone in network security and reliability. By establishing trust between nodes across the entire system, they prevent malicious actors from manipulating data or disrupting operations. In turn, this enables smooth functioning of networks with peace-of-mind assurance that concerns over tampering are addressed. Smart contracts Smart contracts provide an automated and secure layer of protection for data stored in decentralized systems. Through self-executing code, they can ensure that only those who have been granted permission can access valuable information stored on a decentralized storage system. This safeguards sensitive digital assets from malicious forces. Figure 5: Risk mitigation techniques for decentralized storage Technical components The technical details of decentralized storage can be complex and vary from system to system.  However, with encryption, chunking, P2P networks, distributed hash tables, consensus algorithms, smart contracts, and incentives, decentralized storage systems can provide a secure and powerful alternative to traditional centralized storage systems. Figure 6: Components of decentralized storage Use cases for decentralized storage There is a plethora of ways that decentralized storage can be used, and each use case of it brings improvements and innovation. Here are some ways that industries can benefit from its adoption: Increased data security for industries with sensitive or confidential data, such as healthcare, finance, and government Improved data accessibility from multiple locations and devices for industries that require remote access, such as manufacturing and logistics Cost savings by eliminating the need for expensive hardware and infrastructure for industries that rely heavily on data storage and processing, such as media and entertainment Increased transparency by allowing multiple parties to access and verify data in industries that require transparency and accountability, such as supply chain management and government Improved data backup and recovery by allowing data to be replicated across multiple nodes in industries that rely on continuous access to data, such as healthcare and emergency services Figure 7: Use case scenarios for decentralized storage The future of decentralized storage As the future of decentralized storage continues to grow, from advancements in privacy protection to innovations in security solutions, it’s clear that these technologies will only become more prominent in the years ahead. With further exploration into blockchain capabilities along with a greater emphasis on data safety and reliability requirements, decentralization processes aim to forever change how we handle digital information management. Decentralized storage is projected to increase in popularity as people and enterprises recognize its offering of a reliable and confidential way to retain information. Upholding this trajectory, the emergence of Web3 and its uses e.g., DeFi, NFTs, etc., strengthen expectations that decentralized storage uptake will continue gaining traction over time. As decentralized storage solutions become more prevalent, interoperability is emerging as a key area of focus. The development and implementation of new protocols and standards will be integral to the success of this sector. They will allow for users increased ease in transferring their data across disparate systems—unlocking further value for participants involved. The steps taken today Decentralized storage systems are quickly advancing in terms of security and privacy, as developers implement cutting-edge technologies such as advanced encryption algorithms, improved consensus mechanisms, and smart contract-based solutions to protect data. With these advancements comes an increased assurance that private information is safe from malicious actors on the network. As the need for data analytics continues to grow, so does the importance of decentralized storage systems. These secure and private solutions offer a democratized way for individuals and organizations alike to access large amounts of valuable data in order to make better informed decisions. With decentralization comes an unprecedented opportunity to innovate with trusted information at hand. The decentralized storage market is set to become more competitive and dynamic as time progresses, with ever-increasing offerings from both new entrants and existing players. This heightened competition will result in lowered prices which should make the technology easier to access for individuals and organizations alike while simultaneously providing improved quality services. In conclusion To summarize, decentralized storage is a Web3 innovation that is transforming the way data is stored. With this advancement, developers are able to BUIDL world changing DApps with numerous benefits, including cost savings and enhanced privacy. While there are challenges ahead of us, the potential of this technology gives us a lot to be excited about. We are presented with an opportunity to tap into a secure, reliable, censorship-resistant platform for data storage by leveraging Web3’s decentralization capabilities. If used correctly and efficiently, this could have an enormous positive impact on the current technological landscape. As this technology continues to mature and evolve, you can expect to see further innovation in Web3 storage solutions in the future. What are your thoughts on decentralized storage? Just remember that whatever you want to BUIDL on Web3, Chainstack is here to connect you to everything you need—sign up here to get started! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Exploring the methods of looking into Ethereum’s transaction pool (mempool) Introduction The mempool of the Ethereum mainnet—called transaction pool or txpool—is the dynamic in-memory area where pending transactions reside before they are included in a block and thus become static. The notion of a global txpool is a bit abstract as there is no single defined pool for all pending transactions. Instead, each node on the Ethereum mainnet has its own pool of transactions and, combined, they all form the global pool. The thousands of pending transactions that enter the global pool by being broadcast on the network and before being included in a block are an always changing data set that’s holding millions of dollars at any given second. There’s a lot that one can do here—and many do and make this txpool business a highly competitive market. A few examples, listed in the order of inconspicuous to contentious: Yield farming — you can watch the transactions movement between DeFi applications to be one of the first to detect the yield farming profitability changes.Liquidity providing — you detect the potential liquidity movements in and out of DeFi applications and act on the changes.Arbitrage — you can detect the movement of transactions that will affect token prices at different DEXes and make your arbitrage trades based on that.Front running — you can automatically grab the existing pending transactions, simulate them to identify the potential profit if the transaction is executed, copy the transaction and swap the existing address with your own, and submit it with a higher miner fee so that your transaction gets executed on-chain before the one you are copying.Doing a MEV — MEV stands for Miner Extractable Value, and it’s based on that miners are theoretically free to include any transactions in the blocks and/or reorder them. This is a variation of the front running where instead of submitting your transaction with a higher fee to the same pool you picked it from, you get it directly into a block through a miner and bypass the pool. To run any of the described scenarios, you need access to the Ethereum txpool, and you need the methods to retrieve the transactions from the txpool. While Chainstack has you covered with fast dedicated nodes for the former, this article focuses on all the ways you can look into the txpool. Retrieving pending transactions with Geth Since pending transactions are your targets in the txpool space, we are now going to make this a structured effort and focus on answering the following questions while accompanying the answers with practical examples: How do I retrieve pending transactions?Why do I view global or local pending transactions?Can I view global pending transactions without txpool namespace? There are a few ways to retrieve pending transactions. FiltersSubscriptionsTxpool APIGraphQL API Before we start, lets clarify a few things: Global pending transactions refer to pending transactions that are happening globally, which includes your newly created local pending transactions.Local pending transactions refer strictly to the transactions that you created on your local node. Note that you need ‘personal’ namespace enabled for Geth to send local transactions.Pending transactions refer to transactions that are pending due to various reasons, like extremely low gas, out of order nonce, etc.Chainstack is using Geth (Go Ethereum) client. Filters When we create a filter on Geth, Geth will return a unique filter_id. Do note that this filter_id will only live for 5 minutes from the last query on that specific filter. If you query this filter after 5 minutes, the filter will not exist anymore. Creating a pending transaction filter and retrieving data from it cURL Create filter Request body: '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":1}' Response body: { "id":1, "jsonrpc": "2.0", "result": "0xb337f6e2f833ecffc6e9315ba06cd03d" } Access filter Request body: '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xb337f6e2f833ecffc6e9315ba06cd03d"],"id":2}' Response body: {"jsonrpc":"2.0","id":1,"result":["0x3c72691ca7997c4ce93f07b968304ab15bfed370b2755b32bf0104bfa581da3f", ...]} Web3.js Filter for pending transactions is not supported anymore. Please use Subscriptions. Web3.py Create filter pending_transaction_filter= web3.eth.filter('pending') Access filter print(pending_transaction_filter.get_new_entries()) Common sources of confusion on filters Web3.py and the pending argument Why does web3.py have their input arguments as pending instead of a dictionary which contains the usual filter parameters like fromBlock, toBlock, address, topics. This is because Web3 does the mapping internally. If we look at the web3.py source code, when web3.py receives a string pending, it will be mapped to eth_newPendingTransactionFilter, and when web3.py receives a dictionary, it is mapped to eth_newFilter. To add to this, web3.py has get_new_entries as well as get_all_entries for filters but get_all_entries does not work in our case. This is because eth_newPendingTransactionFilter does not have get_all_entries available for it. From latest block to pending block filter Why doesn’t the following filter give me real-time pending transactions? web3.eth.filter({'fromBlock': 'latest', 'toBlock': 'pending'}) A filter only returns new_entries() when the state has changed. This specific filter state changes only when there is a new latest block or pending block. Thus, you will only receive changes when there is a new latest block or pending block, i.e. (eth.getBlock('latest') / pending). The getPendingTransactions filter Why is the following giving me a different or empty result? web3.eth.getPendingTransactions().then(console.log) This function is mapped to eth.pendingTransactions which is a function to check local pending transactions and does not give you global transactions. Based on the Geth source code, only pendingTransactions that has its from field matching with your personal account will be shown. Subscriptions Subscriptions is real-time streaming of data from server to client through WebSocket. You will need a constantly active connection to stream such events. You cannot use curl for this and have to use a WebSocket client like websocat if you want to access it via command line. Once executed, a stream of pending transaction IDs will start flowing in. For other supported subscriptions, check the Geth documentation: Supported Subscriptions. Creating a subscription Websocat Connect to node websocat wss://username:password@ws-nd-123-456-789.p2pify.com Create subscription Request body: {"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]} Response body: {"jsonrpc":"2.0","id":1,"result":"0x2d4f3eb938cdb0b6fa9052de7c4da5de"} Incoming stream {"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x2d4f3eb938cdb0b6fa9052de7c4da5de","result":"0xee426dbaef2a432d0433d5de600347e97b6a8a855daf8765c18cf1b7efc53461"}} ... Common sources of confusion on subscriptions Web3.js ‘pendingTransactions’ and Geth ‘newPendingTransactions’ Web3.js has the pendingTransactions WebSocket calls mapped directly to newPendingTransactions in Geth JSON-RPC API. To subscribe to pending transactions using web3.js, you must use pendingTransactions. To subscribe to pending transactions using Geth JSON-RPC API, you must use newPendingTransactions. For detailed instructions and code samples on how to subscribe using web3.js, see Subscribing to global new pending transactions with web3.js. Txpool API Txpool is a Geth-specific API namespace that keeps pending and queued transactions in the local memory pool. Geth’s default is 4096 pending and 1024 queued transactions. However, Etherscan reports a much bigger number of pending transactions. If we view Geth’s txpool, we will not be able to get all of the transactions. Once the pool of 4096 is full, Geth replaces older pending values with newer pending transactions. If you need a bigger pool to be stored on your node, the flag --txpool.globalslots can be adjusted to a higher value on Geth CLI options. Do note that the larger the number, the bigger the payload size. If you see your txpool_status to be empty, it can mean your node has not fully synced. The txpool namespace is only supported on Chainstack dedicated nodes. Use ‘txpool_content’ to get the pending and queued transactions cURL Create filter Request body: {"jsonrpc":"2.0","method":"txpool_content","id":1} Response body: { "jsonrpc": "2.0", "id": 1, "result": { "pending": {...}, "queued": {...} } } Web3.js txpool_content is not supported. Web3.py Geth API. GraphQL API The biggest advantage of using GraphQL is that you can filter out the specific fields of the transaction that you want. The query in GraphQL goes through the elements within the txpool. Thus, its limitations are the same as the ones of txpool as stated above. The following is an example which shows the information of a pending transaction. Query example: query { pending { transactions { hash gas value gasPrice nonce r s v inputData status gasUsed cumulativeGasUsed from { address } to { address } } } } GraphQL API is currently supported on Chainstack dedicated Ethereum nodes. I hope this blog serves you well in understanding the various ways of retrieving pending transactions. Additional resources Web3.jsEthereum JSON-RPC APIChecking pending and queued transactions in your Ethereum node’s local poolSubscribing to global new pending transaction with web3.js Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Exploring the new Chainstack ChatGPT plugin Imagine having the power to retrieve complex blockchain data without the need for advanced technical skills or extensive knowledge of blockchain protocols. Imagine being able to simply ask a question in natural language and quickly obtain the answer directly from the blockchain. This was once a dream, but our team has turned it into a reality with the launch of our outstanding Chainstack ChatGPT plugin. What is the Chainstack ChatGPT plugin? The Chainstack ChatGPT plugin is a pioneering application that simplifies access to complex blockchain data. It allows users to retrieve intricate data forms from the blockchain through natural language commands, which breaks the usual barriers of specialized language and technical knowledge traditionally required to interact with the blockchain. Incorporating GPT-4, the artificial intelligence-powered language model developed by OpenAI, our plugin leverages its capabilities to understand and interpret user queries, transforming them into blockchain-readable commands for seamless and efficient data access. Why use the Chainstack ChatGPT plugin? Blockchain data retrieval has traditionally been a difficult and complex process that demanded extensive technical expertise. With the release of the Chainstack ChatGPT plugin, we have significantly simplified this process by enabling the retrieval of complex data through simple commands. Not only does this save time and effort, but it also opens up the blockchain world to a wider group of users. The Chainstack ChatGPT plugin offers a broad range of functionalities that make interacting with the blockchain much simpler. Here’s an overview of its core functionalities: Fetching latest block number: You can retrieve the latest block number from a specified blockchain. Checking account balance: You can get the balance of a given account on a specified blockchain. Fetching base gas fee: This allows you to get the base gas fee from an EVM chain, which is useful for estimating transaction costs. Web data scraping: The plugin can scrape Chainstack documentation for information related to platform introduction, Ethereum development tools, blockchain development guides, and more. Blockchain calls: You can make specific method calls on a chosen blockchain protocol. This includes retrieving block details, transaction counts, gas prices, and more. Hexadecimal <=> decimal conversion: Convert hexadecimal values to their decimal equivalents and vice-versa. Wei to ether conversion: Convert values in wei (the smallest unit of ether) to ether. ENS Name Resolution: Resolve an ENS name, like username.eth, to its corresponding Ethereum address. Fetching token balances: Retrieve token balances for a given chain name and wallet address. Fetching NFTs: Retrieve all NFTs associated with a given chain name and wallet address. Fetching single NFT details: Retrieve details of a single NFT for a given chain name, contract address, and token ID. Transaction summary: Get a summary of transactions, including the earliest and latest transactions, for a given chain name and wallet address. Let’s delve deeper into some of them in the following sections. Fetching block numbers and account balances Imagine wanting to know the balance of a specific Ethereum account. Traditional methods would involve directly querying the blockchain and parsing through structured responses—often coded hexadecimal strings. But with the Chainstack ChatGPT plugin, this simplifies to a command as easy as “Fetch the balance of account X on Ethereum.” And the same goes for the latest block number! The way this process works is that the Chainstack ChatGPT plugin interprets the user’s natural language query, translates it into an action that the Ethereum blockchain can understand, extracts the information, and then presents it in an easily understandable format. Figure 1: Fetching ENS address balance with the Chainstack ChatGPT plugin Delving into transaction hash details On the surface, a transaction hash might appear to be a long, complicated string of numbers and letters. However, it contains essential information about the transaction it represents. Extracting this data traditionally requires understanding and navigation through complex codes. The Chainstack ChatGPT plugin simplifies this. The plugin can delve into detailed data about a specific transaction hash and return it in a digestible format, positioning it as a powerful tool for blockchain analysis. Be it the time at which a transaction was confirmed, the number of confirmations it has received, or the fee paid for the transaction, the Chainstack ChatGPT plugin retrieves all this and more—all through simple natural language commands. Figure 2: Fetching transaction hash details with the Chainstack ChatGPT plugin Baseline gas fee retrieval and web data scraping Blockchain transactions aren’t cost-free. They require gas fees, and estimating these costs is made feasible with the Chainstack ChatGPT plugin’s ability to retrieve the baseline gas fee from an EVM chain. Not just that, it can also scrape the web for data. From extracting valuable insights from Chainstack’s documentation to acquiring data on protocols, development tools, and more, its capabilities are staggering. Figure 3: Fetching documentation entries with the Chainstack ChatGPT plugin Specific blockchain protocol calls and data conversions Blockchain protocol interactions are no longer an uphill task. With the Chainstack ChatGPT plugin, users can easily fetch block details, transaction counts, gas prices, and much more with specific method calls. In addition, the Chainstack ChatGPT plugin is designed to facilitate and simplify navigations through different data formats in the blockchain space. Converting hexadecimal values to their decimal equivalents or converting values in wei to ether has never been more user-friendly. Figure 4: Fetching details of the latest Goerli block with the Chainstack ChatGPT plugin Exploring tokens and NFTs Transcending the realms of conventional data, the Chainstack ChatGPT plugin emerges as a potent tool for exploring digital assets, specifically tokens, and NFTs. Our plugin can extract information related to tokens linked to a specific address, highlighting its adaptability in examining various facets of blockchain data. More impressively, Chainstack ChatGPT simplifies the complex world of NFTs. It can retrieve comprehensive data about all NFTs associated with a given chain name and wallet address, effectively streamlining the management and exploration of NFT collections. Figure 5: Fetching number of NFTs owned by an address with the Chainstack ChatGPT plugin How to install the Chainstack ChatGPT plugin? Open ChatGPT. Go to the plugins section. Search for “Chainstack” in the available plugins list. Click on the “Install” button. Start a new GPT-4 chat with the plugin enabled. Figure 6: Installing the Chainstack ChatGPT plugin Feature highlights Simplified blockchain data retrieval: The Chainstack ChatGPT plugin allows users to easily access complex blockchain data without the need for advanced technical skills. By using natural language commands, users can retrieve intricate data forms from the blockchain, breaking down traditional barriers. Integration with GPT-4: The plugin incorporates OpenAI’s GPT-4, an advanced artificial intelligence-powered language model. This ensures accurate understanding and interpretation of user queries, transforming them into blockchain-readable commands. Broad range of functionalities: The plugin offers a plethora of functionalities, including: Fetching latest block number: Get the most recent block number from a specified blockchain. Checking account balances: Determine the balance of a specific account on a chosen blockchain. Gas fee estimation: Fetch the base gas fee from an EVM chain, aiding in transaction cost estimation. Web data scraping: Extract information from Chainstack documentation, including platform details, Ethereum development tools, and blockchain development guides. Blockchain calls: Execute specific method calls on a chosen blockchain protocol, such as retrieving block details and transaction counts. Data conversions: Easily convert between hexadecimal and decimal values, as well as convert wei values to ether. ENS name resolution: Resolve ENS names to their corresponding Ethereum addresses. Token and NFT exploration: Retrieve token balances, explore all NFTs associated with a specific chain name and wallet address, and get details of individual NFTs. Transaction summaries: Obtain a comprehensive summary of transactions for a given chain name and wallet address. Bringing it all together As we reach the end of this blog post, it is apparent that the Chainstack ChatGPT plugin serves as an exceptional way of simplifying on-chain interactions and data retrieval. The plugin demonstrates the potential of uniting artificial intelligence and decentralized technology, offering a unique solution that makes blockchain engaging, accessible, and user-friendly. Whether it’s fetching basic information such as account balances and block numbers, extracting data from Chainstack documentation, converting hexadecimal values to decimals, or performing a deep analysis of transaction histories, the Chainstack ChatGPT plugin stands as an outstanding tool in the toolbox of any Web3 developer. For those managing NFT collections or looking to delve into the world of tokens, the plugin presents a user-friendly interface, drastically simplifying the complexities typically associated with such tasks. Harnessing the tremendous power of natural language allows the plugin to bridge the gap between the intricate world of blockchain and users, inviting everyone to the open discussion table, no matter their technical expertise level. In a world where the only constant is change, the Chainstack ChatGPT plugin stands as a vivid reminder of how human-centric technology can be, and how our language can be the key to unlocking marvels in the world of data. As a result of this, we must keep embracing change, welcome new technological enhancements, and always be ready to explore new frontiers that these tools open up. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### FailSafe Security Grant: Empowering Web3 Builders with Safer Smart Contracts We’re excited to team up with FailSafe on a new grant for Web3 builders. The FailSafe Security Grant gives early-stage teams access to professional smart contract audits with up to $25,000 in support to help projects launch safer and smarter. When people talk about Web3’s biggest risks, security is always at the top. Exploits have drained billions from the ecosystem. Most teams don’t think about audits until they’re forced to — after raising, after shipping, or worse, after a breach. The FailSafe Security Grant, launched with support from Chainstack, is built to change that. Security at Chainstack We think about security on two levels: what runs under the hood, and what you build on top. On our side, that means: SOC 2 Type II and ISO 27001 certification, so our operations are independently audited and verified. Access Rules, to control exactly who can use your endpoints and how. 2FA and SSO for stronger account security. Because we take infra security seriously, it made sense to team up with FailSafe, extending the same mindset to the smart contracts you deploy on top of Chainstack nodes. About the FailSafe security grant The FailSafe security grant provides up to $25,000 per project, or up to 50% of audit costs, for selected teams. Along with funding, recipients get: A comprehensive smart contract audit by FailSafe team Actionable recommendations to address findings A follow-up verification to confirm fixes are properly implemented The grant is limited and will be awarded to teams demonstrating high potential impact and commitment to security. Who it’s for The FailSafe Security Grant is designed for: Early-stage Web3 startups preparing to launch tokens, dApps, or protocols. Builders and developers deploying smart contracts that will hold user funds or enable critical functionality. Ecosystem projects that want to reinforce security before scaling adoption. Whether you’re a small team building an innovative DeFi mechanism, an NFT marketplace, or a cross-chain protocol, this grant helps you secure your contracts before they reach production. How to apply Applying takes a few steps: Visit getfailsafe.com/apply. Fill out the application form with details about your project, team, and scope of work. Submit any supporting documentation (whitepapers, GitHub repos, or deployment plans). Applications are reviewed on a rolling basis. If selected, the FailSafe team will contact you directly to discuss next steps. Final note  Security isn’t the fun part of building, but it’s the part that decides whether your project survives first contact with users. We’re glad to team up with FailSafe on this grant and can’t wait to see what builders do with it.  Good luck to everyone applying, ship safe!  #### FailSafe: Leading Web3 security firm deploys groundbreaking security solution with Chainstack infrastructure “Chainstack’s scalable infrastructure allows us to handle high transaction volumes with minimal latency, enhancing our real-time transaction monitoring capabilities. Working closely with the Chainstack team to build custom solutions has enabled us to provide best-in-class security coverage for our enterprise customers.” FailSafe Team FailSafe, a leader in blockchain security tooling, sought to develop a solution that would protect their customers from a critical emerging threat – primarily, attacks conducted by exploiting offline signatures. Offline signatures are dangerous because they’re not immediately and directly executed by a smart contract, making standard transaction simulations ineffective in safeguarding users. This sophisticated attack method has already resulted in millions of dollars stolen from wallets. In response, FailSafe has developed a robust solution to combat this security challenge. Named the ‘X-Ray’ upgrade for its ability to ‘see’ internal transactions, FailSafe’s solution to combat offline signature exploits is enabled by real-time contract transaction simulation that leverages Chainstack’s low-latency infrastructure. This cutting-edge capability allows FailSafe to process a continuous stream of internal transactions while the parent transaction is still pending. As a result, FailSafe can promptly identify any ERC20 and ERC721 method invocations occurring internally, triggering immediate protective measures. Upon detecting a suspicious internal transaction targeting FailSafe-protected digital assets, FailSafe’s Interceptor swiftly initiates a counter-transaction that redirects targeted funds to a designated smart contract (the Recovery Vault), effectively neutralizing the attacker’s transaction. What is FailSafe? FailSafe is a leader in the sphere of Web3 security, with fundamentals built around developing robust defense-in-depth security systems to protect enterprises and their users in an ever-evolving threat landscape. FailSafe’s security tools enable organizations to integrate “fail-safe” mechanisms across all stages of a transaction: FailSafe Radar: Real-Time Threat and Fraud Detection FailSafe Guard: Risk-Adaptive Access Control for Smart Contracts FailSafe Interceptor: Automated Incident Response The collaboration with Chainstack has offered a significant enhancement to FailSafe’s security capabilities, meticulously empowering the layers of protection with low latency transaction tracing. “FailSafe’s groundbreaking security technology will accelerate the adoption of blockchain by enterprises. By integrating Chainstack’s advanced transaction tracing, FailSafe has significantly enhanced security coverage and created a safer environment for users. We’re proud to work alongside FailSafe in fortifying the Web3 ecosystem and leading the industry in innovative security measures.” Eugene Aseev, CTO & Co-Founder, Chainstack How FailSafe Started with Chainstack When we first encountered FailSafe, we were met with a team recognizant of the intricate complexities that the world of Web3 posed. They were grappling with a novel yet pernicious form of Web3 attack. Deeply concerned with the potential harm this threat posed, the FailSafe team was looking for a reliable and efficient way to manage their transaction tracing needs. They saw the need for a solution that was capable of handling a substantial volume of transaction calls, while also providing lower latency. FailSafe was acutely aware of how crucial these features were to enhancing their cybersecurity measures. As they evaluated Chainstack, FailSafe had certain expectations, the primary one being a well-organized and effective approach to transaction tracing. Our extensive protocol support and transaction tracing capabilities resonated with FailSafe’s needs. But it wasn’t just our robust service offerings that appealed to them—it was our readiness to create a custom plan specifically targeted at their unique requirements. This focus on personalized service was a critical factor that made Chainstack stand out. The deciding moment for FailSafe was when they got to experience first-hand the efficiency of our real-time transaction tracing. Not only was the latency remarkably low, but the cost-effectiveness of our shared nodes proved to be a significant advantage over setting up their own on-premise infrastructure. This combined with the potential for a custom plan to serve their specific needs, convinced them that Chainstack was the right choice. FailSafe on Chainstack in numbers Focused on enhancing their transaction call capacity, they make use of 7 active elastic nodes across various protocols currently, including Base, BNB Smart Chain, Ethereum, and Polygon. To date, all requests the company has sent our way were handled by Chainstack Elastic Archive Nodes, totaling 325.2M. When it comes to geographic distribution, the Ashburn region manages the bulk of the load, catering to 305M requests, while the Los Angeles region—19M. Analyzing by protocol, the majority of requests (210M) come from the Polygon protocol, followed by BNB Smart Chain with 66M, Ethereum with 29.5M, and Base with 19M. The partnership with Chainstack enabled FailSafe to efficiently manage their transaction tracking. Leveraging our robust infrastructure, FailSafe successfully balanced operating a high-demand service with maintaining stringent cybersecurity measures. These impressive numbers underscore the significant progress FailSafe has made in secure wallet operations and smart contract security, all facilitated by Chainstack’s reliable support. Bringing it all together When FailSafe encountered challenges in their quest to secure the world of Web3, Chainstack emerged as the optimal partner, providing the vital features and flexibility FailSafe needed to boost their services. Facing sophisticated attacks, seeking comprehensive internal transaction monitoring, and finding cost-effective alternatives to managing their own infrastructure, FailSafe found the solutions to their challenges with Chainstack. By combining Chainstack’s capabilities for real-time transaction tracing across multiple networks with FailSafe’s industry-leading solutions, we achieved a robust Web3 security infrastructure. This partnership has led to safer and more secure Web3 interactions for all of FailSafe’s users. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Faster, better, stronger: Web3 infrastructure at scale with Chainstack TraNodes Welcome to a world where your limits are defined only by your imagination. Welcome to Chainstack. At Chainstack, we believe in the limitless potential of the Web3 landscape and the innovative work that you, as a developer, are doing in this space. We are not just a platform; we are your reliable partner, your window into the exciting world of Web3 development. We understand the intricacies of working within the blockchain ecosystem, which is why we’ve created our dedicated nodes, specifically designed to support unbounded Web3 development. That’s why we conceived Chainstack Dedicated Nodes—to remove traditional barriers and give you unparalleled access to Web3 development so that you can BUIDL freely and without constraints. Let’s explore the details. Chainstack Dedicated Nodes for unbounded Web3 development At Chainstack, our journey has always been dedicated to providing Web3 developers, like yourself, the cutting-edge tools you need to harness the full potential of whatever it is you’re building. So, we channeled our groundbreaking performance, security, and accessibility to create a state-of-the-art solution—Chainstack Dedicated Nodes. Designed for limitless customization and flexibility, Chainstack Dedicated Nodes are the key you need to build and scale resource-heavy DApps. We understand that, as a Web3 developer, you need the versatility to create on a diverse set of protocols. That is why we designed Chainstack Dedicated Nodes with multi-chain support from the start. Whether it is Ethereum, Polygon, and BNB or Solana, Scroll, and zkSync Era, our ever-expanding portfolio of supported chains caters to your unique needs, ensuring you can BUIDL limitlessly and seamlessly choose the chains on which your revolutionary ideas will thrive. Figure 1: Chainstack Dedicated Nodes supported protocols; Source: Chainstack Our aim is simple: To optimize your Web3 development experience, enabling you to focus on creating breakthrough DApps while we take care of the heavy lifting. Chainstack Dedicated Nodes embody this philosophy. We let you focus on the building while we manage all the rest. Unrestricted performance with Chainstack Dedicated Nodes Innovation thrives when there are no artificial limits. Echoing this sentiment, our Dedicated Nodes are designed to sustain even the most demanding loads. Unlike traditional systems, our approach is limit-free by nature, allowing your Web3 project to grow without bounds and smoothly cater to increased demand. Your success is our success. Our goal isn’t just to provide unmatched services; it’s to empower pioneering builders and their trailblazing DApps to become the next big thing in Web3. With Chainstack Dedicated Nodes, we’re committed to helping every aspiring developer bring their visions to life. Get Started What makes Chainstack Dedicated Nodes great We believe in delivering more than just tools. Our emphasis on fostering a rich and supportive experience for Web3 developers sets us apart. From our commitment to uninterrupted service to our focus on customization for optimal efficiency, we make sure every factor makes your journey, as a builder, both smooth and successful. The reliability you deserve: Geo-load-balancing for a 99.9% uptime We understand that consistency and reliability are paramount in your journey as a Web3 developer. Every second of downtime can cost you—in the faith of your users, your DApp’s reputation, and potentially in revenue. As Web3 developers ourselves, we understand this very well, and consequently, we’ve woven tailored geo-load-balancing into the very fabric of Chainstack to ensure high availability of 99.9% for your DApps. Utilizing a sturdy, geo-load-balanced architecture, we ensure continuous, consistent performance. Our smart rerouting mechanism swiftly shifts the load to the next most performant node if any network health issues emerge—resulting in seamless operations, even during the most challenging times. Figure 2: Chainstack Global Load Balancer idea slide; Source: Chainstack The result? A DApp that is even more robust and reliable, distributing incoming traffic effectively with optimized dedicated resources and eliminating single points of failure. Get Started The award-winning architecture behind Chainstack Dedicated Nodes At the heart of Chainstack lies our award-winning architecture—globally recognized for its groundbreaking design. Crafted to be robust and reliable, our architecture serves as the bedrock of your projects. It’s not just a tool for building state-of-the-art DApps; it’s your tireless partner in bringing forth innovation in the decentralized world. Initially introduced as the “Unstoppable RPC Endpoint” at the ETH Belgrade hackathon and further developed for ETHGlobal Istanbul last year, our architectural design has earned numerous awards. It’s a key element of our Global Nodes, featuring an advanced, globally-distributed, geo-load-balanced system. This system is meticulously designed to evenly distribute workloads across various nodes, guaranteeing superior performance and dependability. Figure 3: Unstoppable RPC Endpoint architecture; Source: ETHBelgrade hackathon repo Bolt Sync: Deploy Chainstack Dedicated Nodes in moments Delays can be frustrating, especially when you are ready to hit the ground running. That is why we created Bolt Sync—to enable developers to quickly spin up fully synchronized Chainstack Dedicated Nodes, carrying the latest state. With our patented Bolt technology, you can start building instantly. Figure 4: Chainstack Bolt Sync introduction video; Source: Chainstack YouTube Warp Transactions: Power your Web3 development with speed and efficiency In the realm of Web3, speed is of the essence. Recognizing this, we took performance optimization to the next level with Warp Transactions. Offering lightning-fast transaction propagation, our solution ensures your transactions are made available instantly for validators to include in the next block, making them up to 2.5x faster than regular P2P transactions. This unbound performance is our way of supercharging your trading experience, opening up new possibilities in your Web3 journey. Get Started Chainstack Dedicated Nodes: Boundless hosting and location In the fast-paced world of Web3, being shackled by inflexible hosting options and restricted locations can be a bottleneck to progress. However, with Chainstack, you’re not confined by such limitations. Whether it’s AWS, GCP, Azure, Chainstack Cloud, Hybrid Hosting, or a Bring-your-own-cloud setup, you can choose from the widest selection of managed cloud services for deploying your nodes. You also have the freedom to deploy your nodes globally—right where your users are. We believe in empowering you with choices because we understand that your needs are as unique as your vision. A cloud and location of your choice for Chainstack Dedicated Nodes The task of Web3 development requires comprehensive control over your resources. Moreover, it’s about having the right choices at your disposal. At Chainstack, we provide the widest selection of managed cloud services, granting you maximal control over your node deployments. In our mission to empower you as a Web3 developer, it’s essential for us to break free from geographic constraints too. After all, your user base likely spans the globe, extending beyond geographical boundaries. That is why, we allow you to pin-point and deploy your nodes precisely where your users are. From Tokyo to Oregon, our global array of selections puts you in control, enabling you to cater to your users effectively and efficiently. Figure 5: Chainstack Dedicated Nodes supported clouds and locations; Source: Chainstack Chainstack Cloud: A new standard in Web3 hosting We’ve always believed in going above and beyond – and our approach to our cloud services is no different. The Chainstack Cloud offers a Web3 hosting solution that ensures zero rainy days, lighting-fast speeds, and near-zero latency. With the Chainstack Cloud, we’ve aimed to build an infrastructure that boosts your development efforts rather than hinder them. Figure 6: Chainstack Cloud supported locations; Source: Chainstack Hybrid Cloud: Tailored infrastructure meets on-premise control Chainstack ensures that ease of use does not compromise control. Our Hybrid Cloud solution enables effortless deployment and management of dedicated nodes within your own infrastructure. This perfect mix of dedicated nodes and tailored infrastructure provides the best of both worlds: the flexibility of cloud services and the command of on-premise systems. The result is a significant reduction in latency, enhanced response times, and exceptional convenience, especially for applications operating on AWS via a private network. Figure 7: Chainstack-managed hosting vs Hybrid hosting comparison; Source: Chainstack Private Networking: Enhance performance via direct node connection When it comes to access to the node, we believe in cutting down the unnecessary layers. Our private networking solutions let your app interact with the node directly, minimizing latency and boosting application response time. You get to reap the benefits of a greatly improved performance by eliminating the hurdles standing between your app and the node. Get Started Dedicated Nodes pricing that empowers you at every scale The financial aspect of Web3 development is critical, and we aim to make it as simple and transparent as possible. Our pricing policies are straightforward and created with developers in mind. No more second-guessing your budget. We allow you to focus on building and reaching out to your next billion users with the simplest pricing in all of Web3. Figure 8: Chainstack Dedicated Nodes pricing; Source: Chainstack We understand that Web3 development isn’t one-size-fits-all. That’s why we have crafted a range of affordable commitment tiers to suit individual needs, whether you’re a solo developer just starting out or an established organization seeking a future-ready array of services. Chainstack Dedicated Nodes cost-effectiveness The question may arise—how would your on-premise costs hold up against ours? We’ve got you covered in our in-depth article on self-hosted Ethereum archive node costs. We believe in making endless Web3 possibilities within your reach, without breaking the bank. That’s the Chainstack promise. But what about competitor comparisons? You can create custom usage profiles using our pricing calculator and check how well Chainstack fares against alternative providers. Transparency, simplicity, and affordability are at the forefront of our mission to make the world of Web3 accessible to all developers. Figure 9: Chainstack pricing comparison and profiles; Source: Chainstack Bringing it all together In an ocean of unprecedented possibilities, the Web3 landscape unfurls a horizon where innovation is the sail and determination the wind that paves the route to unexplored islands of opportunity. Here at Chainstack, we firmly believe in this powerful dynamism and are committed to helping developers navigate these waters with our dedicated nodes and award-winning architecture. Get Started With their incredible flexibility and high performance, Chainstack Dedicated Nodes give you more than just control. They equip you with the freedom to let your ideas soar while we tune the nitty-gritty. Combine this with our robust range of benefits and our transparent pricing approach, and you have a steadfast ally in your journey through the Web3 universe. Whether you’re breaking ground on your first project or scaling a company, Chainstack is there every step of the way. Innovation shouldn’t be shackled by constraints—technological, geographical, or financial—and Chainstack is here to ensure it never will be. We’re excited to empower your journey, supporting you as you shape the future of Web3 development. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Fault-tolerant transactions with MetaMask and Chainstack nodes This is the second article in the two-part series about MetaMask and transactions: MetaMask under the hood. Fault-tolerant transactions with MetaMask and Chainstack. <- You are here. Introduction MetaMask is by far the most common accounts manager used to interact with the Web3 world. In the previous article in this series, we saw how MetaMask works under the hood—what happens when you create a new account, when you interact with a DApp (decentralized application), and when you send transactions. Now, let us see how it connects to the blockchain and how you can make your MetaMask connection faster and more reliable using Chainstack. Fault-proof your MetaMask As we discussed in the full and archive nodes article, we need to communicate with a node to access the blockchain; and while MetaMask is not a node, it connects to one and functions as a nice and intuitive user interface. MetaMask exchanges a lot of information about the state changes that your account makes on the blockchain, such as account balance, transactions count (nonce), and more. It does so by connecting to an Ethereum node using a default provider. The default node provider is automatically set up and initially is the same across all the users; this makes it really easy to get up and running. At the same time, such a system can cause a few issues as it spreads the resources between many people. Currently, MetaMask has more than 30 million monthly users. In January @MetaMask broke 30M monthly active users accessing Web3 applications, a 42% increase in 4 months.— Consensys.eth (@Consensys) March 15, 2022 Because so many users use the same endpoints, you could experience the following obstacles in you Web3 journey. Slower transaction propagation Transactions could take longer to propagate through the network. In a distributed network like EVM blockchains, the node that picks up and validates a transaction first, will share it (propagate) with the rest of the network so that all the nodes can verify it and keep up to date. Propagation speed is very important to keep the network efficient. Higher gas fees The gas fee estimate made by MetaMask is based on the network load, and it could be out of date. You might end up paying more than necessary if you don’t realize it. Rejected transactions In case of a sudden spike in network usage, outdated gas estimates might also lead to rejected transactions since you might send a one with not enough gas. Network instability Because of the shared resources, the network might become temporarily unusable, and your transactions might get stuck. We are mentioning the Ethereum network specifically because it comes standard with MetaMask, but this applies to any other Ethereum Virtual Machine (EVM) compatible network that you connect to using MetaMask and one of the public endpoints, including Avalanche, BNB Smart Chain, Fantom, and all the others. With Chainstack, you can rely on a fast and secure node connection for all these chains. Why should you use Chainstack endpoints on MetaMask?  MetaMask is your access point to the blockchain, and it is especially important to make it fault-proof. If something happens to the public endpoints, you might find yourself unable to interact with the network, your transactions can get stuck, and you might not be able to complete important operations. Imagine trying to mint a new NFT with limited availability—the network endpoint stops working while you send the transaction and comes back online only once everything is sold out. What a disaster it would be. Luckily, Chainstack’s technology solves scalability and instability issues and provides fast and reliable node endpoints for many different networks. To get a Chainstack node:  Sign up with Chainstack.  Deploy a full node.  Protocols supported by Chainstack Chainstack supports many EVM compatible protocols, including Avalanche C-Chains, where you can create your subnet. Chainstack allows you to keep your MetaMask efficient and secure on all the supported networks from the same place. I recommend referring to the Chainstack website for an updated list of supported protocols.  How do I update my MetaMask endpoints?  Now we can finally show you how to update your MetaMask endpoints. First, sign up on Chainstack and get your node up and running. 1. Sign up on Chainstack and spin up your node:  Sign up with Chainstack. Deploy a node.   2. Open your MetaMask instance:  Click on the network selection button.  Click Add Network.  A new page will open where we are going to insert the new endpoint details. In this example, we will add a Chainstack Avalanche endpoint but the process is the same for every network. 3. Let’s find the custom endpoint information.  Network Name The Network Name field can be any name that will remind you what that specific network is for. In this case, let us call it Avalanche – Chainstack.  New RPC URL RPC stands for Remote Procedure Call, and it is a set of rules that allow a program to run instructions remotely as if they were running on the machine directly. Here is where we will define the connection to the node, go to the dashboard of your Chainstack node, copy the endpoint’s URL, and paste it into the New RPC URL input field. We are using an Avalanche C-Chain endpoint in this case.   Note that Chainstack offers WebSocket endpoints as well, but MetaMask requires the use of an HTTP/HTTPS endpoint. Chain ID The Chain ID is a number used when transactions are signed and verified (different from the private key). It distinguishes the different chains and avoids replay attacks, effectively protecting the transactions from being duplicated on another chain. It must match the Chain ID that the node returns, and it is important that you get it right. For this example, the Avalanche C-chain Chain ID is 43114. I recommend referring to the Chainstack docs to get the Chain IDs for all supported protocols. In the documentation, you can find the Chain ID and other MetaMask instructions under the Tools section of every protocol. Currency Symbol This is the symbol that MetaMask uses to identify the base currency for the network.  Block Explorer URL The block explorer is optional, but I recommend filling it up as it gives additional utility to your wallet. A block explorer allows you to look up details about smart contracts, wallets, and transactions. It is a powerful tool that will help you check details more easily. Luckily for you, Chainstack provides its users with a block explorer for every node deployed. To access the block explorer from Chainstack:  Go in your project.  Choose a network in the project.  Click Explorer. 4. Now that we have all the information that we need, we can fill the fields and save.  Note the message that I get: This Chain ID is currently used by the Avalanche Network network.  This happens because I already have an Avalanche network set up on my MetaMask using that Chain ID; this is just MetaMask reminding me that I already have a network using that Chain ID, and it is okay. It will not impact the use of the node in any way. After you save it, the new endpoint shows up in the Networks list, and all you need to do is click on it to switch.  Conclusion  At this point, you successfully added Chainstack as your custom RPC provider for the Avalanche network, and the process is the same with all the other EVM compatible protocols that Chainstack supports. Setting up custom endpoints using Chainstack is the best way to protect yourself against network instability on the Ethereum network and the public RPC endpoints for the other protocols, as well as make your transactions and interactions with DApps faster, fault-tolerant, and more enjoyable. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Flashblocks on Base: 200ms preconfirmations via Chainstack RPC Flashblocks is now live on Chainstack for Base Mainnet and Testnet Sepolia endpoints, bringing near-instant transaction signals that improve responsiveness. Built directly into Base, Flashblocks reduces effective confirmation time from 2 seconds to 200ms by streaming partial block updates before full block finality.  On Base, a standard transaction takes ~2 seconds to confirm. That’s fast by Layer 2 standards, but for real-time low-latency trading, onchain games, and time-sensitive user flows, those two seconds can still feel like a delay. Flashblocks, a transaction preconfirmation feature developed by Flashbots, introduces “partial blocks” that stream ahead of each new seal. Flashblocks is now fully supported on Chainstack Base Mainnet and Sepolia endpoints. If you’re a builder working on low-latency infrastructure, Flashblocks gives you access to ultra-fast preconfirmation signals, providing transaction feedback in as little as 200 milliseconds. In this post, we’ll cover what Flashblocks is, how it works, where it helps, and show code examples using JSON-RPC and curl to help you get started. What is Flashblocks on Base? Flashblocks is a feature on Base that introduces low-latency block previews by streaming committed transactions as they’re added to the block-in-progress. Instead of waiting for full block finality, apps can access an early view of the next block that reflects transactions already included by the builder. Each Flashblock contains transactions that have already been executed and committed by the builder as part of the in-progress block. This gives devs a low-latency signal that a transaction is already included, before the full 2-second block is finalized on-chain. The mechanism is compatible with existing Ethereum JSON-RPC methods. Calls like eth_getBlockByNumber with the pending tag will return the current Flashblock. Others, like eth_getTransactionReceipt and eth_getTransactionCount, also reflect the latest Flashblock state. Benefits of Flashblocks on Base Flashblocks makes confirmations faster, but most importantly, it gives you better ways to build. Here’s what changes when you’re using Base RPC endpoint by Chainstack. Get faster transaction signals With Flashblocks, your app doesn’t need to wait two full seconds to update the UI. You get an early signal that a transaction is already included, even before the full block is finalized. That’s a big deal for anything time-sensitive: swaps, games, bots, or even a simple onboarding flow. Low-latency RPC access, globally distributed Chainstack Global Nodes for Base are optimized for intensive traffic. We route requests through the closest available region, whether that’s the US, EU, or Asia, and serve responses from high-performance nodes. That means even when network traffic spikes, your app stays fast. # Example: Fetch the latest Flashblock (pending block) via Chainstack Base RPC curl -X POST <YOUR_CHAINSTACK_BASE_RPC_URL> \\ -H "Content-Type: application/json" \\ -d '{ "jsonrpc": "2.0", "id": 1, "method": "eth_getBlockByNumber", "params": ["pending", false] }' Works with standard Ethereum RPC methods Flashblocks works with standard RPC methods available on Base. Just use the “pending” tag with: eth_getBlockByNumber eth_getTransactionReceipt eth_getBalance eth_getTransactionCount You’ll get fresher data, streamed from the latest Flashblock, without touching your existing tools. Getting started with Flashblocks on Base via Chainstack Create a Base RPC endpoint on Chainstack Flashblocks is currently supported on Base Mainnet and Testnet Sepolia. If you already have a Chainstack Base RPC endpoint on a supported node type, it’s Flashblocks-ready by default. You can create new endpoints in just a few clicks. Connect your app, script, or tool Use your Chainstack RPC URL in your web3 app, wallet, script, or curl requests. All standard Ethereum JSON-RPC methods are supported, including the enhancements Flashblocks introduces. Use Flashblocks features with standard RPC methods There are no new SDKs or complex integrations. You can start using the “pending” tag with methods like eth_getBlockByNumber, eth_getBalance, or eth_getTransactionCount to access real-time blockchain data. Flashblocks on Chainstack unlocks near-instant confirmations, ideal for anything time-sensitive. Conclusion Flashblocks changes how fast apps can respond on Base. Instead of waiting for full block finality, you get an early signal of inclusion, fast enough to make things like trading, gaming, or live dashboards feel instant. It works with standard RPC methods and doesn’t require any new setup. If you’re using a Chainstack Base RPC Mainnet or Testnet Sepolia endpoint on a supported node type, you’re already good to go. #### Flashblocks on Optimism now available via Chainstack RPC Chainstack now supports Flashblocks on Optimism, giving developers access to near real-time transaction preconfirmations through dedicated low-latency Optimism RPC endpoints. Traditionally, applications on Optimism wait around two seconds for block confirmation. With Flashblocks, transaction updates can arrive in as little as 250 milliseconds, significantly improving responsiveness for latency-sensitive use cases such as trading platforms, prediction markets, wallets, gaming, and real-time consumer applications. Built for the OP Stack ecosystem, Flashblocks stream transaction ordering updates before the full block is finalized. This enables developers to build applications that feel more interactive while reducing perceived confirmation delays for end users. With Chainstack Flashblocks RPC, developers get: sub-second transaction feedback Ethereum-compatible RPC endpoints support for pending state reads minimal integration changes for existing applications production-grade Optimism infrastructure with global performance optimization Flashblocks are powered by Rollup-Boost, an open-source initiative developed by Flashbots in collaboration with OP Labs and ecosystem contributors to reduce latency across OP Stack chains. While Flashblocks were first introduced on Base, the Optimism implementation includes important OP Stack-specific architectural differences. Depending on the chain configuration, sequencing behavior and rollout mechanics may vary between networks. If you’re new to the technology, read our guide to Flashblocks to understand how sub-block streaming and preconfirmations work across OP Stack ecosystems. For a deeper technical comparison between Base and Optimism implementations, see the Flashblocks comparison section in the documentation. Try Flashblocks on Optimism → #### Forta for real-time monitoring and security of your smart contract Introduction Smart contracts are autonomous pieces of code that exist on a blockchain. As such, anyone on the blockchain could interact with your smart contract if the chain itself is up and running. This makes it essential to keep a steady pair of eyes on your contract, especially if you are dealing with large sums of money as is the case with DeFi smart contracts for example.Forta is an open-source project that helps you in writing bots to keep track of your smart contracts. You can configure the bot to your requirements and track your smart contract for the exact activities that you may want to look out for. Prerequisites Solidity basics to understand the basics of how events and payable functions work. You can refer solidity-by-example for a quick overview. TypeScript — we will be using TypeScript to build our bot. If you need to install TypeScript in your system, refer to the official website here. ethers.js — you need to understand the concept of providers in ethers.js. What are we building? We have a Deposit.sol smart contract deployed on the Mumbai testnet. Any account can deposit MATIC on it. Our Forta bot will: Trigger a critical alert if any blacklisted addresses deposit ether into our smart contract. Trigger an info alert if any random addresses deposit ether into our smart contract. Detect if a deposit is less than 0.01MATIC: this will trigger a suspicious activity alert. Deposit.sol has a single payable function. The contract will emit an event to signify the amount of ether deposited into the contract whenever some ether is sent to it. This is the smart contract code: pragma solidity =0.8.14; contract Deposit{ event Deposited(uint256 amount); function deposit() external payable{ emit Deposited(msg.value); } } This contract is already deployed and verified at the Mumbai network. So you can focus only on the bot building! Building the Forta Bot Building a Forta Bot requires the following steps: 1. Setting up the dev environment. 2. Configure your bot to the Mumbai network. 3. Network manager: specify the smart contract addresses for different networks we want to monitor. 4. Emit custom findings through your Forta Bot. Setting up our dev environment Create a new folder by the name of deposit-detector. Open the folder in VS code (or any code editor you like), and run the command: npm init -y This command creates an empty package.json file that contains a list of the packages we install in our directory. Now run the following command to initiate a basic TypeScript project using the forta-agent CLI tool: npx forta-agent@latest init --typescript We recommend using npm instead of yarn when setting up the project to avoid some known issues that can arise when deploying the bot. This is what your terminal should look like: Type yes through all prompts, and set a new password for your detector. npm will now download all the required packages to set up a basic Forta bot project. After installation, your directory should look something like this: That’s a ready template of a working bot. Run the npm start command in your terminal to check if everything was installed correctly. The bot should start emitting findings in all transfer events on the Tether token deployed on the Ethereum blockchain. So how does a Forta Bot really listen to transactions and blocks on a blockchain in real time? The forta-agent CLI creates an agent.ts file inside the src folder by default. The file contains a simple Forta bot that listens to transactions on the Tether token as described previously. Go to src/agent.ts . It is the main file of the bot where you can add your bot logic. You will find two exports functions: export default { handleTransaction, handleBlock }; Here is a brief overview of both of these functions: handleTransaction: This function is called each time a new transaction has been submitted to our contract. handleTransaction receives a newly generated TransactionEvent object, which contains all the events that occurred inside that particular transaction. You can check all TransactionEvent properties from the official documentation here. handleBlock: handleBlock is called each time a new block is minted on the blockchain. handleBlock receives a BlockEvent object which contains all transactions that occurred inside a block. You can take a look at all the BlockEvent properties from the documentation. We need the bot to detect deposits inside the Deposit.sol smart contract. So we really only need the handleTransaction function. Before getting down to the code, let’s think about the remaining steps to build a bot: Configuring our Forta Bot to a blockchain: Which blockchain network do we want to use? For this particular article, we will be configuring our bot to monitor a smart contract deployed on the Mumbai testnet. Network manager: we need to specify the addresses for all the smart contracts we want to monitor. Emit findings (send notification): decide which events we want to listen to. In our case, it is only a Deposited event: If the Deposited event is called. If the deposited amount is less than 0.01. If the deposited address is blacklisted. This was a brief outline of what we need to keep in mind while building a Forta Bot. Let us now move ahead to actually implementing these steps into our project. Configure your Forta bot to the Mumbai testnet The Forta bot currently is listening to the events of a single contract on the Ethereum mainnet. To configure the bot to listen to the Mumbai testnet: First, go to package.json, and inside the chainIds object, replace 1 (which is the Ethereum Mainnet’s chain ID ) with “80001”, (Mumbai network’s chain ID). "chainIds": [ 80001 ], Now go to the forta.config.json file. The file contains configuration parameters for your bot. Inside the file, replace the existing code with this: { "jsonRpcUrl": "<Your Chainstack RPC URL>" } This configuration will allow forta-agent to use your RPC URL to connect to any blockchain you want. The chain IDs and RPC URLs must be set up correctly to avoid conflicts while connecting to the blockchain.You can use a public RPC URL, or alternatively, you could use a high-speed, reliable RPC connection to the blockchain by creating a node on Chainstack. If you are not familiar with setting up a node on Chainstack, feel free to check out this guide on our blog. Now you have your bot listening for events on the Mumbai network. To test this out run npm start in the terminal. You should have an output that looks like this: If you searched for any transaction hash, you should be able to find it on Mumbai testnet explorer. So what’s happening here? Our bot is looking for events emitted from the Tether token contract. But that contract was deployed on the Ethereum mainnet. Hence, looking for events on that contract address on the Mumbai testnet does not yield anything. You can however check for the block numbers being returned in the terminal. These block numbers should correspond to the latest blocks being published on the Mumbai testnet explorer website.Stop the bot currently running in your terminal by pressing Ctrl+C (on Linux). Let us now add our own smart contract to the code. Network manager: specify the smart contract addresses for different networks we want to monitor The network manager has two main purposes. The first one is to map data to its equivalent blockchain network. So if we have a contract address 0xa… deployed on Ethereum and a contract address 0x0b… deployed on Polygon, you can monitor both addresses without changing the code. Create a file named network.ts inside the src folder. Inside the file, add this code: export interface NetworkData { address: string; // The smart contract address minimumDepositAmount: number; blacklistedAddresses: string[]; } export const networkData: Record <number, NetworkData> = { 80001: { address: "0xa87db9fe057cff6e296586bec6a6982a5a9b44b0", minimumDepositAmount: 0.01, blacklistedAddresses: [ "0x7c71a3d85a8d620eeab9339cce776ddc14a8129c", "0x17156c0cf9701b09114cb3619d9f3fd937caa3a8", ], }, }; In this file, we are exporting networkData which basically stores our contract address and an array of blacklisted addresses that will trigger an alert if they send us any ether.The second purpose of the network manager is to initialize the provider object for the network connection (if you don’t know what a network provider is, check out Ethers documentation). To do so, we need to install forta-agent-tools. Open the terminal and run: npm i forta-agent-tools Now go to src/agent.ts and delete everything inside it. Import NetworkManager from the installed package: import { NetworkManager } from "forta-agent-tools"; Now create a new networkManager object with NetworkData by importing the network.ts file: import { networkData, NetworkData } from "./network"; const networkManager = new NetworkManager(networkData); //global var To add the provider, we need to call networkManager.init() function, but we need this to be called only one time when the bot is initialized. Forta has a built-in function to initialize. First import ethers from “forta-agent”: import ethers from "forta-agent"; Now add the following code inside the agent.ts file: export const provideInitialize = ( provider: ethers.providers.JsonRpcProvider ) => { // should return a function that will be used by the Bot return async () => { await networkManager.init(provider); }; }; Finally, we will export provideInitialize(): export default { initialize: provideInitialize(utils.provider), // The utils object will be added in the next section }; Your agent.ts should now look something like this: import ethers from "forta-agent"; import { NetworkManager } from "forta-agent-tools"; import {NetworkData, networkData } from "./network"; const networkManager = new NetworkManager(networkData); export const provideInitialize = ( provider: ethers.providers.JsonRpcProvider ) => { // should return a function that will be used by the Bot return async () => { await networkManager.init(provider); }; }; export default { initialize: provideInitialize(utils.provider), // The utils object will be added on the next section }; Inside the bot, we have the network manager and all the data that we need. The only missing thing is the handleTransaction function and the utils object. Let us start with the utils object.Create a new file inside the src folder with the name utils.ts. Add the provider from forta-agent inside the utils file. We will export the provider object from the utils file: import { getEthersProvider } from "forta-agent"; const provider = getEthersProvider(); Let us now add the event ABI to our utils file. We need the event ABI to monitor our payable function whenever it’s included event is triggered: import { Interface } from "@ethersproject/abi"; const EVENT_ABI: string[] = ["event Deposited(uint256 amount)"]; const EVENTS_IFACE: Interface = new Interface(EVENT_ABI); Emit custom findings through your Forta bot A Forta bot creates findings that flag transactions and blocks that meet the required conditions. A finding mainly contains the types and severity of the flagged block/transaction. Forta gives us 4 types and 5 severities to configure our bot’s findings: Finding types: Exploit, Suspicious, Degraded, Info. Finding severity: Info, Low, Medium, High, Critical. In our bot, we will use the following types: Info, Suspicious, and Exploit, and the following severities: Low, Medium, and Critical. Let’s create the interface for our custom finding function. We need to first make some additional imports from “forta-agent”. On the top of your utils file, replace the first import with this: import { Finding, FindingSeverity, FindingType, getEthersProvider, } from "forta-agent"; Next, let us create an interface for our finding function: interface FindingParams { // deposit, minimum deposit and blacklisted address alertId: "001" | "002" | "003"; account: string; depositedAmount: string; description: string; severity: FindingSeverity; type: FindingType; } Finally, let us create a finding function named createFinding. The createFinding function is just an object initializer. const createFinding = ({ alertId, account, depositedAmount, description, severity, type, }: FindingParams): Finding => { return Finding.fromObject({ name: "Detects all deposit transactions", description, alertId: `deposit-${alertId}`, severity, type, protocol: "Depositor", metadata: { account, depositedAmount, }, }); export default { provider, EVENT_ABI, EVENTS_IFACE, createFinding, // add create finding }; }; The utils the file is ready. It should look something like this: import { Finding, FindingSeverity, FindingType, getEthersProvider, } from "forta-agent"; const provider = getEthersProvider(); import { Interface } from "@ethersproject/abi"; const EVENT_ABI: string[] = ["event Deposited(uint256 amount)"]; const EVENTS_IFACE: Interface = new Interface(EVENT_ABI); interface FindingParams { // deposit, minimum deposit and blacklisted address alertId: "001" | "002" | "003"; account: string; depositedAmount: string; description: string; severity: FindingSeverity; type: FindingType; } const createFinding = ({ alertId, account, depositedAmount, description, severity, type, }: FindingParams): Finding => { return Finding.fromObject({ name: "Detects all deposit transactions", description, alertId: `deposit-${alertId}`, severity, type, protocol: "Depositor", metadata: { account, depositedAmount, }, }); }; export default { provider, EVENT_ABI, EVENTS_IFACE, createFinding, }; The last step to complete our bot is to implement the handleTransaction function. Save your utils file and open agent.ts.Below the provideInitialize function, add the provideHandleTransaction function by pasting this code: export const provideHandleTransaction = (networkManager: NetworkManager<NetworkData>): HandleTransaction => async (txEvent: TransactionEvent) => { const findings: Finding[] = []; const depositLogs = txEvent.filterLog( utils.EVENT_ABI, networkManager.get("address") ); depositLogs.forEach((log: LogDescription) => { const amount = ethers.utils.formatEther(log.args.amount); // Emit finding for new deposit findings.push( utils.createFinding({ alertId: "001", account: txEvent.transaction.from, depositedAmount: amount, description: "New deposit!", severity: FindingSeverity.Low, type: FindingType.Info, }) ); // Emit finding if deposit less than the minimum amount if (Number(amount) < networkManager.get("minimumDepositAmount")) { findings.push( utils.createFinding({ alertId: "002", account: txEvent.transaction.from, depositedAmount: amount, description: "Someone deposited a very small amount", severity: FindingSeverity.Medium, type: FindingType.Suspicious, }) ); } // Emit finding for blacklisted addresses if ( networkManager .get("blacklistedAddresses") .includes(txEvent.transaction.from) ) { findings.push( utils.createFinding({ alertId: "003", account: txEvent.transaction.from, depositedAmount: amount, description: "Blacklisted addresses deposit!", severity: FindingSeverity.Critical, type: FindingType.Exploit, }) ); } }); return findings; }; Let us go over this function briefly. Whenever a transaction sends ether to our contract, a new event is emitted, and Forta Bot returns an array of findings to us. Based on our required conditions, we can classify the events into different types and severities.If our contract for example receives a rather small amount of ether as a deposit, we may want to flag the transaction as suspicious. We are basically emitting the findings based on the fulfillment of certain conditions. We now need to export this function as a handler to Forta Bot. Go to the bottom of agent.ts, and change the file export to this: export default { initialize: provideInitialize(utils.provider), handleTransaction: provideHandleTransaction(networkManager), }; You will probably still be seeing a bunch of errors in the agent.ts file at this point. This is because we still need to make some imports. Go to the top of the file and import additional modules from “forta-agent” with this: import {ethers, Finding, FindingSeverity, FindingType, HandleTransaction, LogDescription, TransactionEvent, } from "forta-agent"; and import the utils file into agent.ts: import utils from "./utils"; Starting up our bot The default project created by forta-agent CLI includes an agent.spec file that is used for testing our bot. We won’t be testing our bot this time, so you can just delete the file. And that’s it. Now your bot is ready to use. To start up your bot inside the terminal, run: npm start This command will start the bot. Try going to the smart contract and depositing a small amount of MATIC tokens. See what findings you get back from your bot. You can also ask your bot to listen to a specific transaction using this command: npm run tx <transaction hash> Or to listen to all transactions that happened on a block by using this command: npm run block <block number> You can get the values of the transaction hash or the block number from the readme file. And that’s it for the bot development. Now your bot is ready to use. But in most cases, bots may be more complicated than this, so I recommend you always create a unit test with positive and negative scenarios for your bot. Conclusion In this article, you learned about the Forta network, and how to use the forta-agent CLI to build your own bot that can monitor threats and suspicious activities on your smart contracts in real time. Forta-agent is a very powerful tool, and you can learn more about it from the official documentation. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Foundry: A fast Solidity smart contract development toolkit Paradigm, the company involved in many successful projects in one way or another, has recently published Foundry—a toolkit for EVM-based application development. See the announcement blog post: Introducing the Foundry Ethereum development toolbox. Let’s have a quick look at Foundry. What is Foundry? The very first thing to know about Foundry is that it’s a reimplementation of dapptools. Why is that important? If you have a look at the current top accounts by ether balance, you will see that the very top two are: Eth2 Deposit Contract — created and tested with dapptools. Wrapped Ether — created and tested with dapptools. While dapptools is written in Haskell, Foundry is in Rust. And Foundry is fast. On some occasions, when using Foundry, you’d blink and miss it compiled your code. Foundry benchmarks: ProjectFoundry compilation timedapptools compilation timeguni-lev28.6s2m36ssolmate6s46sgeb11s40svaults1.4s5.5s See also the Foundry benchmarks repository. Apart from speed, one of no less important features that Foundry shares with dapptools is being able to write and test your Solidity smart contracts in Solidity and to warp the VM state in your tests. Let’s have a simple walkthrough. Installation Install Rust. Install Foundry. Components Foundry consists of the two main components to work with your smart contracts: Forge — use forge to compile, test, and deploy your smart contracts. Cast — use cast to interact with the network and the smart contracts. Initialize your project Create your project directory and initialize it with forge: forge init Foundry Solidity smart contract tutorial For simplicity, let’s use the simple storage contract. In the initialized directory, create /root/foundry/src/simplestorage.sol: // SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.4.16 <0.9.0; contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() public view returns (uint retVal) { return storedData; } } Compile the smart contract It will take less than half a second: forge build --contracts /root/foundry/src/simplestorage.sol Create tests Write a test in Solidity to get the initial contract value, set a value and check the set value. Create /root/foundry/src/test/simplestorage.t.sol: // SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.4.16 <0.9.0; import "../../lib/ds-test/src/test.sol"; import "../simplestorage.sol"; contract SimpleStorageTest is DSTest { SimpleStorage simplestorage; function setUp() public { simplestorage = new SimpleStorage(); } function testGetInitialValue() public { assertTrue(simplestorage.get() == 0); } function testSetValue() public { uint x = 300; simplestorage.set(x); assertTrue(simplestorage.get() == 300); } } Run the test: forge test --contracts /root/foundry/src/test/simplestorage.t.sol Now that your test passes, you can spice it up with changing the VM state through a cheat code. Cheat codes are state changing methods called from the address: 0x7109709ECfa91a80626fF3989D68f67F5b1DD12D Read more at Foundry: Cheat codes. Through changing the VM state in tests, you can warp the state of the network—for example, change the timestamp of the block, instantly jump a period of time, and so on. Let’s add to the test instantly warping our blockchain state to 100 seconds in the future. Edit /root/foundry/src/test/simplestorage.t.sol to include changing the initial 0 seconds block timestamp to 100 seconds and checking it: // SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.4.16 <0.9.0; import "../../lib/ds-test/src/test.sol"; import "../simplestorage.sol"; interface Vm { function warp(uint256) external; } contract SimpleStorageTest is DSTest { SimpleStorage simplestorage; Vm vm = Vm(0x7109709ECfa91a80626fF3989D68f67F5b1DD12D); function setUp() public { simplestorage = new SimpleStorage(); } function testGetInitialValue() public { assertTrue(simplestorage.get() == 0); } function testSetValue() public { uint x = 300; simplestorage.set(x); assertTrue(simplestorage.get() == 300); } function testWarp() public { assertEq(block.timestamp, 0); vm.warp(100); assertEq(block.timestamp, 100); } } Run the test again: forge test --contracts /root/foundry/src/test/simplestorage.t.sol Deploy the smart contract Now that you have a tested contract, go ahead and deploy it. You need a node to deploy the contract to an EVM network—for example, Ropsten. To get a node: Sign up with Chainstack. Deploy a Ropsten node. Get the deployed node’s HTTPS endpoint. Make sure you have a private key to your Ethereum account funded with Ropsten ether to pay for gas. Use forge create to deploy the contract through your node: forge create SimpleStorage --contracts /root/foundry/contracts/simplestorage.sol --private-key 9c4b7f4ad48f977dbcdb2323249fd738cc9ff283a7514f3350d344e22c5b923d --rpc-url https://nd-123-456-789.p2pify.com/3c6e0b8a9c15224a8228b9a98ca1531d Interact with the smart contract Call the contract simulation at the deployed contract address through your node: cast call 0x131FBABE213A3a98cD8C71d0F1Ed94861A3665CA "get()" --rpc-url https://nd-123-456-789.p2pify.com/3c6e0b8a9c15224a8228b9a98ca1531d Conclusion Foundry is currently in active development with a very involved community. It really is blazing fast and the Foundry “pedigree” makes it a very promising project for the Web3 stack. I suggest you watch the project and see the pace at which they mature to become part of your daily stack. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### From zero to hero: Ethereum DApp developer tools to help you every step of the way Embarking on the journey of Web3 development might seem daunting at first, but with the right guide and tools, it’s a captivating voyage of discovery. In this digital realm, we primarily deal with a new kind of internet application; we call these Decentralized Applications or simply DApps. Central to the development of these DApps is a key component known as a smart contract. Smart contracts allow DApps to interact with the blockchain, marking the cornerstone of all dealings on the Web3 platform. These contracts operate on a set of coded rules embedded within them, allowing them to carry out transactions or functions when pre-set criteria are met. But worry not! As a rookie Web3 developer or hobbyist, you’re not expected to dive straight in. It’s here that the Remix Integrated Development Environment (IDE) comes in. The Remix IDE offers a user-friendly platform where you can learn, practice, create, and test smart contracts for your blockchain projects. It’s like the toolbox you never knew you needed! An IDE, or Integrated Development Environment, is an application that provides a comprehensive environment for writing, testing, debugging, and deploying code. Build simply with the Remix IDE The Remix IDE is a versatile tool for any blockchain enthusiast, acting as a multi-purpose platform that supports the entire flow of smart contract development—from writing to testing, and finally deploying on the Ethereum blockchain. The secret behind its appeal is its user-friendly interface combined with an exhaustive suite of features that cater to both beginners and seasoned developers in the blockchain space. Figure 1: The Remix IDE; Source: Remix At its core, Remix IDE thrives on simplifying the entire process of smart contract development. The platform offers all the resources for writing smart contracts in the popular Solidity programming language. Moreover, it provides a testing environment to deploy and interact with your contracts, thereby saving you from the intimidating task of setting up a test blockchain. But hold on, there’s more! Remix IDE boosts efficiency by providing direct access to documentation right inside the platform. This means all the information you need to navigate the blockchain development landscape is available at your fingertips. Figure 2: The Remix IDE project importer; Source: Remix Plus, it offers a range of project templates and plugins. These pre-built components not only reduce the development time significantly but also take away the repetitive tasks, so you can focus on building interesting parts of your blockchain project. Figure 3: The Remix IDE project templates and featured plugins; Source: Remix Learn Solidity with Remix Once you’ve got your feet wet with the basics of Web3 development and explored the Remix IDE, it’s time to take a deeper plunge. A foundational understanding of Solidity programming is central to excelling in smart contract creation. Solidity is a statically typed programming language designed for implementing smart contracts on Ethereum. Remix IDE supports Solidity programming and serves as an excellent learning ground for developers delving into blockchain projects. It brings your code to life by transforming it into instructions for the Ethereum Virtual Machine (EVM). Figure 4: The Remix IDE learning modules; Source: Remix Plug in your favorite RPC in Remix With the solid foundation you have built so far in Web3 development, you are now ready to explore even further. Remix IDE isn’t just about helping you write and deploy smart contracts; it’s about opening up a world of possibilities for you as a blockchain developer. One of the vital features of Remix IDE is its support for alternative Remote Procedure Call (RPC) providers when deploying and running transactions. What does this mean for you as a developer? Simply put, it expands the range of blockchain networks you can interact with for testing and deployment. Figure 5: The Remix IDE RPC selector; Source: Remix Remote Procedure Call (RPC) providers are a crucial part of blockchain networks, letting applications communicate with blockchain nodes. But, if you’re a rookie developer, you might ask, “What if I don’t have a node?” Simple! you can deploy a node for free on Chainstack. Chainstack is an intuitive platform for managing Web3 infrastructure like blockchain nodes. It simplifies the process, so even rookies can quickly get their nodes up and running in no time at all. To deploy your elastic node, head over to our website and create an account. Once logged in, go to your dashboard, create a new project, and select ‘Join network.’ Pick Ethereum, configure your node details, and click ‘Create.’ And within a couple of minutes, you’ll have your node up and running. Figure 6: Deploying an elastic node on Chainstack video guide; Source: Chainstack Navigate token standards with the OpenZeppelin Wizard Imagine walking into a digital marketplace where transactions, governance, and more happen seamlessly in a decentralized manner. The key driving force behind this smooth operation? Tokens. Tokens form the backbone of blockchain infrastructure, lending structure, and balance to the unfolding actions. In particular, tokens find importance in EVM-based development, constituting a set of standards known as ERC20, ERC721, and ERC1155. ERC20 tokens, similar to your everyday currency notes, are fungible—each token is identical to every other token; it’s used widely for swapping digital currencies. Conversely, ERC721 tokens are non-fungible, with each token possessing unique attributes. This uniqueness has exemplary representations in the world of cryptographically unique collectibles—remember CryptoKitties? Then there is ERC1155, a more modern, multipurpose standard, which facilitates a mix of fungible and non-fungible tokens. Creating tokens with these standards, especially for a newcomer, may appear daunting. Open-source libraries like OpenZeppelin step in right here to make your task significantly more comfortable, providing audited smart contract templates that cover a variety of use cases, including token creation. Interestingly, OpenZeppelin sports a user-friendly Smart Contract Wizard, an interactive tool that lets you create customized token contracts with just a few clicks, sparing you the complexity of code! Figure 7: OpenZeppelin Wizard ERC-20 token; Source: OpenZeppelin Smart contract example // SPDX-License-Identifier: MIT // Compatible with OpenZeppelin Contracts ^5.0.0 pragma solidity ^0.8.20; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; /// @title Chainstack ERC20 Token /// @dev Extends ERC20 Token Standard basic implementation with burnable functionality and ownership. /// The token is initially owned by the address passed to the constructor, which also receives an initial mint of tokens. contract Chainstack is ERC20, ERC20Burnable, Ownable { /// @dev Sets the details for the "Chainstack" token and assigns the initial owner. /// @param initialOwner Address to be set as the initial owner of the token. constructor(address initialOwner) ERC20("Chainstack", "CSK") // Sets the token name and symbol. Ownable(initialOwner) // Initializes the Ownable contract with the initial owner. { // Mint initial token supply to the address deploying the contract. _mint(msg.sender, 1000000 * 10 ** decimals()); } /// @notice Allows the owner to mint new tokens to a specified address. /// @dev Mints `amount` tokens and assigns them to `to`, increasing the total supply. /// @param to The address that will receive the minted tokens. /// @param amount The number of tokens to mint. function mint(address to, uint256 amount) public onlyOwner { _mint(to, amount); } } Cook Web3 with quick and easy Chainstack Recipes X has Xstorms. Developers have code snippets, and at Chainstack, we have recipes. Yes, swimming in the vast sea of blockchain development can sometimes leave you feeling lost. This is where Chainstack’s Recipes come in handy, acting as your compass and guide to navigate the array of functionalities available for smart contract development and more. Chainstack Recipes are essentially chunks of code that provide ready-to-use functionalities for your project. Think ready-made pizza dough, but for code. Whether you’re creating a basic smart contract or interacting with a decentralized oracle, they’ve got a recipe that will save you time and effort. Figure 8: Chainstack recipes; Source: Chainstack These recipes integrate seamlessly into your project, allowing you to focus on the creative aspects of your DApps, instead of the repetitive bits. They shave hours off your development time, allowing you to bring your blockchain project to life faster. So, let’s dive into them! Bringing it all together The realm of Web3 development is expansive and exciting, teeming with endless possibilities. At the heart of this universe is Remix IDE, providing a robust and user-friendly platform that equips developers with the tools they need to excel in the realm of smart contracts and DApps. From the initial steps of understanding Web3 and its components, diving into the heart of Remix IDE, widening our horizons with Solidity and OpenZeppelin Plugins, exploring alternate RPC providers, and finally getting a taste of Chainstack Recipes, this journey has been a deep dive into the world of blockchain development. Remix IDE, therefore, can be viewed as more than a tool. It is a beacon for developers, lighting the way towards mastery of Web3. The platform’s strength lies in its innovative approach that combines a comprehensive suite of tools with a simple interface that enables developers at all levels to bring their blockchain vision to life. As the age of digital democratization continues to unfold, platforms like Remix IDE and Chainstack are destined to be at the forefront, spearheading the movement toward a decentralized future. And with each passing day, the future of Web3 comes more into focus. No matter where you are in your blockchain journey, remember that your creativity, combined with the right tools, can create remarkable innovations in this dynamic Web3 space. The blockchain revolution is ongoing, and with the help of guides like these, you can navigate it confidently. After all, in the vast cosmos of Web3, the possibilities are endless, and the exploration is just beginning! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### GET on Chainstack: Leading blockchain and NFT adoption across the ticketing industry GET Protocol is an NFT Ticketing infrastructure provider, including an event dashboard, ticket shops, and a mobile ticketing application. GET also offers a distinctive product that allows ticketing companies to issue NFT Tickets in their local market. Together their digital twin product and white-label solution allow them to serve the entire spectrum of the ticketing industry. What does GET protocol do? GET Protocol delivers a unique combination of infrastructure that allows it to service the global events industry and extends the benefits of NFT Ticketing throughout the entire event chain to the organizer, artist, and their fans. Every single ticket issued through the protocol is minted as an NFT as soon as it is sold and importantly, a ticket buyer requires zero knowledge of blockchain or cryptocurrency to purchase a ticket and attend an event. This is made possible using blockchain technology and the protocol’s smart contracts, which automate the entire process and ensure that tickets cannot be counterfeited or duplicated. Additionally, GET provides event organizers with the means to control the secondary resale market by capturing previously lost revenue and data. Doing so creates an opportunity for events to be easily rescheduled or have information changed without causing problems to the ticket sale itself. GET Protocol has seen significant growth ever since its inception, reaching 1M on-chain tickets issued in October 2021 and adding another 50% on top by March 2022. Looking a year back, the protocol has managed to issue as many as 900,000 NFT tickets through more than 9 white-label partners, and one digital twin integrator. Worldwide the infrastructure has seen use in over 121 countries, powering 9,700 events, while offering support to more than 400 artists and event organizers. How did GET protocol come across Chainstack? To make sure the protocol can be easily accessible to even non-tech-savvy customers, the extra layer of complexity of the blockchain and NFT infrastructure is intentionally hidden from the UX. At the same time, however, this also means that network operations need to be performed seamlessly to ensure no delays or interruptions to the service can occur. In order to accomplish this, GET protocol needed a reliable RPC node provider that could adhere to the strict performance requirements laid out beforehand. Without it, the development team risks incurring heavy losses in terms of revenue, as well as customer satisfaction that could lead to severe damage to the protocol’s reputation and its future adoption. That is why after experiencing prolonged periods of network instability on the Polygon network, the team set out on a search for a robust infrastructure provider to resolve these issues. They conducted a survey of node providers to discover the one that could offer the best performance in terms of stability, which eventually led them to Chainstack. How does Chainstack’s offer match GET protocol needs? Chainstack stood out from all the options in the survey by offering optimal performance with the lowest number of dropped transactions overall. Seeing the reliability of Chainstack’s robust infrastructure prompted the GET team to select our services to power the protocol’s network operations. The Chainstack team was always quick to respond to any issues the development team of GET encountered throughout the process. We worked together in further increasing the reliability of the RPC infrastructure provided and chimed in swiftly, whenever the nodes needed additional maintenance and critical updates. This eventually prompted the GET team to upgrade their plan and opt-in for a dedicated node instead of a shared one. The move would prove vital for the improvement of network stability and was of immense help when it came to monitoring transaction confirmations in real-time. Outcome Considering that transaction confirmation is essential for the effective delivery of GET services, having a reliable infrastructure provider to support their efforts was paramount. Nobody wants to be put in the tricky situation of having to explain to customers that their NFT ticket is unavailable due to poor network conditions. Thanks to Chainstack’s reliable RPC node service the GET team was able to leave these woes in the past and move forward with delivering exceptional service to their customers. This meant no more disappearing transactions and a final goodbye to fallback code implementations for non-propagated transactions. But that wasn’t the only benefit of using Chainstack’s robust infrastructure for GET protocol. By opting in for the Enterprise plan, the development team was able to receive priceless real-time data from the effective delivery of their services. This allowed them to be notified of completed transactions within milliseconds, giving them ample time to prepare for the rare occurrence of dropped requests. What does GET protocol like about Chainstack? Chainstack provided reliable blockchain infrastructure and complemented our team with its highly responsive and solution-oriented team. This allowed us to focus on improving performance and developing better innovative solutions. Jack Turnbull, Protocol Engineering Lead, GET Protocol What is the most interesting engineering challenge in working together? The demanding use-case of GET protocol was an interesting engineering challenge in itself. Having to service large venues and open-air concerts meant tens of thousands of sales events being rapidly generated on a regular basis. And translating this into NFTs while recording them successfully on the network was truly an exceptional feat of blockchain engineering. That is why one of the first challenges we needed to tackle together with the GET team was handling the significant volume of transactions being pushed towards the node. With Chainstack’s assistance, the development team was swiftly able to streamline the node parameters in optimizing the infrastructure for effective propagation. While the journey towards success was not a straight line, like most interesting engineering challenges are, Chainstack worked together with the GET team to pivot whenever needed. Ultimately our team helped guide GET towards the necessary Bor service tweaks to best fit their needs and assisted the protocol developers during conversations with Polygon. In doing so, together we successfully navigated through the precarious situations we encountered, while keeping their finger on the pulse of mempool transactions at any given moment. Maintaining a healthy dialogue between GET, Polygon and Chainstack became a crucial moment in finding the shortest route to mint the ticket NFTs on the Polygon network and effectively tweak the peer-nodes setup to accomplish this. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Give me trust Part 2 of trust trilogy Photo by marcos mayer on Unsplash By Laurent Dedenis In part 1 of the Trust Trilogy, I took a sweeping view of the evolution of trust and what it means today for all of us. I tried to establish the unique and powerful nature of blockchain as a ‘controllable trust interface’ and touched lightly upon what it means for businesses. In part 2, I plan to go further down the road where businesses and blockchain meet. First, they ignore you. Then they laugh at you. Then they attack you. Then you win. I have seen the above quoted on multiple occasions. Its popularity attests to the fact that it represents an interesting and, often, predictable pattern among people and businesses when faced with something unfamiliar. Once upon a time, the cloud was viewed as a highly-risky thing. Businesses were wary of offloading their data to ‘up-there’ or ‘out-there’. It didn’t help either that this new technology, itself an evolution from mainframe to virtualization to grid computing, was called ‘cloud’. Today, the public cloud is a staggering $170 bn plus industry and counting. What’s holding us back? Much has changed since the Bitcoin white paper was introduced to the world. It has gone from a fringe movement to being considered a store of value to now being an institutional asset class. As for blockchain, this is where things get really interesting. Once ignored in favor of its superstar app Bitcoin to being lightly acknowledged as a possible solution to data security and privacy, it is now being seriously explored as a world-changing technology. Companies are coming together in consortia to explore how blockchain can streamline processes, remove intermediaries, and make systems more secure and transparent. Governments are exploring it to provide its citizens with the kind of trust they should have provided by default. But notwithstanding the multitude of experiments, there’s been scant real-world adoption. In a recent PWC survey of 600 executives, 84 percent indicated their organizations have at least some involvement with blockchain technology. What’s even more promising is Gartner’s forecast that blockchain will generate an annual business value of more than US$3 trillion by 2030. It goes on to say that there’s every possibility that by 2030, 10 to 20 percent of global economic infrastructure will be running on blockchain-based systems. So why is that we are still at a trivial 1% adoption rate? If there’s one thing that’s holding enterprises back, it’s a view of the way things should be based on how they have always been. Paradoxically, for a technology that engenders trust, its adoption is hindered by a lack of trust. The PWC study puts it eloquently: It is perhaps ironic that a technology meant to bring consensus hits a stumbling block on the early need to design rules and standards. I am not surprised. Trust, as I have shown in part 1, has been part of our social capital since time immemorial. Forcing a radically different technology that ‘engineers’ trust to fit into the conventional way we view trust simply won’t work. Adopting blockchain and reaping its full benefits requires a higher order thinking. It calls for a mind-shift that views collaboration as a norm. In this new way of thinking, the world of business no longer becomes a zero-sum game, it becomes a playground of possibilities. An idea whose time has come Imagine a typical automotive supply chain. It’s massive, complex, and comprises a maze of participants, namely, OEMs, warehouses, assembly plants, dealers, customers, and, connecting those dots, logistics providers. Traditionally, silos of data and heterogeneity of IT systems have resulted in a lot of inefficiencies such as manual records-matching and delayed coordination in matching supply with demand resulting in waste. When combined with the twin power of IoT and blockchain, real-time updates to all participants become possible because they all can access a single view of the state of the supply chain. With data transparency, the result is a more nimble and less wasteful supply chain. Add machine learning to the mix, and the supply chain becomes intelligent, predictive, and rich with insights. But nothing of this would be possible without the first step: a blockchain-enabled single source of truth. If you think this scenario is far out, you only have to look at MOBI, a consortium that aims to transform the entire mobility services value chain using blockchain and other distributed ledger technologies. MOBI is setting standards and APIs for data sharing that will positively impact everything from vehicle identity and data tracking to ride sharing as well as the mobility ecosystem commerce. What’s admirable is that the consortium has already brought into its fold members that account for 70 percent of global car production along with 30 other partners. Competition and beyond Not so long ago ‘coopetition’ was a buzzword in corporate circles. With roots in game theory, the neologism introduced the basic premise that traditional competitors could cooperate ‘to reach a higher value creation compared to the value created without interaction and struggle to achieve competitive advantage’. Then there are examples of coopetition such as those among Citroën, Peugeot, and Toyota to develop a city car; Apple, IBM, and Motorola to develop microprocessors; and Samsung and Sony to establish joint manufacturing and technological capabilities. In each of these cases, sharing of technology and resources resulted in reduced costs and superior products even while the companies were competing fiercely in other markets. As expected, there are not too many examples of this seemingly paradoxical way of doing business. I believe it will become a lot more common, and it goes back to the issue of mindset. Given that there is some strategic agreement between two organizations on the value of coopetition, what those organizations will need is a strong set of tools. There’s simply no partnership without sharing and transparency. But with the fundamentally trust-inducing nature of a blockchain, companies might just find the idea of coopetition a lot more achievable and less risky. From the examples that I have seen, coopetition has largely been confined to a few players. But thanks to the automated manner in which trust can be achieved via blockchain, I see the pool of participants growing much larger. Larger ecosystems, larger markets, richer insights, these and more are possible with a simple mind shift. And that’s the topic of the final part of the Trust Trilogy. Stay tuned. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Gnosis Merge: Transitioning to a POS future The merge on Gnosis On 8th December 2022, Gnosis Chain will undergo the Merge. The current execution layer will Merge with the parallelly running Beacon Chain, and the entire network will henceforth transition to a permissionless Proof-of-Stake (PoS) consensus mechanism from the current Proof-of-Authority (PoA) consensus. This blog will tell you all you need to know about the Gnosis Merge and what you need to do to prepare for it. When will the merge happen? Technically speaking, the Merge on Gnosis Chain has no fixed date or time. However, we can reasonably assume that the merge will happen sometime on 8th December 2022. This ambiguity arises due to how the Merge is set to be executed. The ‘difficulty‘ of a particular block on a blockchain is a quantitative measure of how much computation power is required to generate that particular block. ‘Terminal total difficulty‘ (TTD), as the term suggests, is a measure of the total difficulty reached until that block. The Gnosis Chain core developers have set the terminal total difficulty to this value: 8626000000000000000000058750000000000000000000 This value was proposed as a way to schedule the Merge during the week of 5th Dec 2022. As of now, the Gnosis Chain is predicted to reach this TTD sometime around 8th Dec. How will users be affected? The average user on the Gnosis Chain won’t be affected by the Merge in any way. No new coins will be minted, and no coins will be burned. The Gnosis token (GNO) will continue to be used for staking, and the xDai token will continue to serve as the native gas token. For DApp developers on Gnosis Chain: block.difficulty will be deprecated along the lines of the Ethereum merge. If your DApp uses the value as part of its algorithm, we recommend you make changes. You can read more on Gnosis Docs. Gnosis Chain previously had a mechanism to generate on-chain randomness with the help of the RandomAuRaCode smart contract. That mechanism will now be deprecated, and developers should find alternatives. What does it mean for node operators? Post-Merge, your Gnosis Chain node will need an execution layer client with a consensus layer client. Those two layers communicating with each other will form a full node. As of the time of writing, only Nethermind has a Gnosis execution layer implementation ready for the Merge. As for the consensus clients, there are various options to choose from. You can read more about these in the Gnosis’ docs. To run a node on your own, you would have to: Configure a server on your machine that remains online all the time to enable you to run a node seamlessly. Run an execution client, and configure it with a JSON Web Token (JWT) secret to allow it to communicate with the consensus client. On top of it, if you want to run an archive node, you would need at least 2TB of space on your disks, plus 2-6 weeks waiting for it to completely sync on your machine. You would then need to run a consensus client like Teku or Lighthouse, embedded with your execution client’s JWT key, to finally be able to run a full Gnosis Chain node. Credits: Diagrammatic representation of a full validator node With Chainstack however, you don’t have to worry about any of this. We have already: Set up fast and reliable servers ✅ Configured Nethermind for an execution layer ✅ Combined that with Lighthouse as a consensus layer to form a full node ✅ Follow these steps to sign up on Chainstack to deploy a node and find your credentials: Sign up with Chainstack Deploy a node View node access and credentials Go through this tutorial on our blog for all the details: Parity’s AuRa(Authority Round) POA consensus model Unlike Ethereum, Gnosis Chain doesn’t use the PoW consensus mechanism pre-Merge. It instead subscribes to an AuRA (Authority Round) Proof-of-Authority consensus model to add new blocks to the Gnosis Chain. This is how it works: To start, Gnosis Chain currently divides its consensus operations into small time-frames of staking epochs. The default length of an epoch is 1 week, though it can be configured as required. A new set of validators is selected to add new blocks to the chain every time an epoch expires. Do note that a new set of validators can also include validators from the previous set, sometimes even leading to the formation of identical validator sets. It is important to understand what a delegator is and the difference between a validator and a delegator. An address can become a validator or a delegator by staking the respective minimum amounts of GNO tokens into the protocol. It is, however, only the validators that actually produce new blocks. Delegators typically stake fewer tokens than validators, but they can ‘vote’ on a candidate by pooling in their stake with a particular candidate. Candidates with a good reputation will naturally attract more delegators. This combined candidate+validator stake is referred to as a candidate’s pool. The larger this pool, the higher the chances for a candidate to be included in the next validator set. Gnosis Chain implements a random number generator that selects a new validator set from an existing set of candidates, with a proportional preference to the size of a candidate pool. This new validator set produces new blocks for the entire epoch, while a new set of validators for the next is determined from the remaining candidates. The figure below will make the POSDAO validator selection process clearer. Credits: POSDAO Whitepaper Post-merge Gnosis consensus model Gnosis Chain aims to closely mirror the Ethereum mainnet Merge that happened on 15th September 2022. Post-Merge, Gnosis Chain will switch to a permissionless PoS consensus mechanism. This means a few changes to choosing validators for block production: No ‘delegators’ will be able to vote on validators to increase the total pool and, thereby, the chances of getting selected to produce the next blocks. Validators will now be chosen randomly, and a committee of 128 fellow validators will vote on the proposed block’s validity. The preference given to validators with big pools will be removed. Now each validator will have to stake a fixed amount of 1 GNO (32 mGNO) to participate in the validation process. You can, however, run multiple validators from a single node. Gnosis Chain aims to mirror its’ Merge to that of Ethereum. There are, however, a few differences in the parameters between the two. You can have a look at the Gnosis Chain’s initial post-Merge parameters below. VariableValueStaking amount32 mGNO (equivalent to 1 GNO)Block time5 secondsValidator slots per epoch16 (with further reduction possible, N > 1 honest proposer/epoch as per V. Buterin)Validators per slot128 (see more on minimum committee size)Epoch time80 secondsSlashingReductions to 16 mGNO, then removalClientsPrysm, LighthouseCustom Deposit ContractmGNO deposit (ERC20 enabled)UpgradeableClaiming on accidental locksCustom network keys generation (deposit-cli)ExplorerModified beaconchain explorer🔍 beacon.gnosischain.comRPChttps://rpc-gbc.gnosischain.comLaunch MVP4096 validators131,072 mGNO83% APYSecurity Goal Prior to Merge50K+ validators1.6M+ mGNO23% APYCredits: Gnosis Docs Explore all our services Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### GraphQL on Ethereum: Availability on Chainstack and a quick rundown Starting today you can use GraphQL on Chainstack Ethereum nodes. In brief GraphQL is available on dedicated Ethereum nodes on Chainstack starting from the Growth plan. Where previously JSON-RPC was your only option to query the data on an Ethereum node, you can now do so with GraphQL. Full nodes do not have historical data but can be queried for the latest data. Archive nodes have all the data—latest and historical—and can be queried live. The Graph has prebuilt and pre-indexed sets of data—called subgraphs—and querying them is the fastest, albeit limited to a data set. Chainstack supports all options. Our Ethereum archive nodes are already feeding the Graph nodes used by the community. We are also looking into supporting the Graph nodes natively. Geth and GraphQL Back in the middle of 2019, Go Ethereum (Geth) introduced native GraphQL support with the release of version v1.9.0. Geth was not just the only client to do so but did the implementation fairly quickly and with enthusiasm. Read the original EIP-1767 for GraphQL support. At the same time, there’s The Graph project with subgraphs, also using GraphQL. So what are all of these, and what’s the difference? What is GraphQL? GraphQL is a query language and a runtime that allows the client to define a schema of all the entities it has and the relationships between the entities. With GraphQL, all you need as a user is one endpoint that you send your query to and define what fields and relationships you want to get in the response. This is in contrast to the traditional REST API and JSON-RPC, where one has to set up in the client many endpoints that the API users might need. With the REST API, you, as a user, need to send your requests over many routes and then process the many responses. With GraphQL, you just have one route and a query that you define. Why replace JSON-RPC with GraphQL? The primary purpose of JSON-RPC is to interact with the Ethereum node, not just retrieve some read-only data off the node. As such, the JSON-RPC method tends to be resource-wasteful. For example, for simple data retrieval requests like eth_getBlock, it will return all of the extra data that the user requesting may not be interested in. GraphQL, on the other hand—specifically designed to query the data the user needs— is resource-efficient. From the moment GraphQL support was introduced and implemented in Geth, you can run the GraphQL queries both in Geth full nodes and Geth archive nodes. Full nodes For a simple example, let’s take the Uniswap V2: Factory Contract and run a GraphQL query against a full node to see how many transactions it has from the start to the latest block. Chainstack conveniently provides GraphiQL—a GraphQL IDE—that lets you type in and execute your queries. To open your instance of GraphiQL, navigate to your deployed Ethereum full node in the Chainstack UI and click Open next to GraphQL IDE URL. In your GraphiQL instance, paste in the following query to get all the Uniswap V2: Factory Contract transactions: { block { account(address:"0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f"){ transactionCount } } } Running this query will give you the number contract creating transactions done from the start until the latest block. Archive nodes If you want to check the number of transactions from the start until a certain block in the past, you won’t be able to do this with the full node as this requires querying the historical state. Only an archive node can provide historical state. So let’s now run the very same query for a block in the past against an archive node deployed with Chainstack. Again, navigate to your deployed Ethereum archive node in the Chainstack UI and click Open next to GraphQL IDE URL. In your GraphiQL instance, paste in the query for block 10010000 to get all the Uniswap V2: Factory Contract transactions: { block (number:10010000) { account(address:"0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f"){ transactionCount } } } Running this query will give you the number contract creating transactions done from the start until block 10010000. This is something that can only be done on an archive node. And on The Graph. The Graph Where does The Graph fit in the Geth and GraphQL scenario? The Graph works a little bit differently by introducing the so-called subgraphs. Subgraphs are prebuilt and pre-indexed data sets deployed to the Graph nodes that are automatically maintained and updated. To create a subgraph, you use The Graph code and define in a YAML file what smart contract to index and what smart contract events to listen to. Then create a GraphQL schema for your subgraph that users will later be able to query. Having defined your subgraph, you can start your own Graph node with your subgraph deployed that will index the data, or you can deploy it to a node run by The Graph organization. The defined data will be indexed and stored in its database, ready to be immediately queried. To do a similar query with the Uniswap V2: Factory Contract, you can head over to The Graph playground to interact with the Uniswap subgraph. Paste in the following query: { uniswapFactory(id: "0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f", block: {number: 10010000}){ txCount } } It will take the subgraph less than a second to process it, because it’s querying a pre-indexed data set, and respond with the total number of transactions for the Uniswap V2: Factory Contract until block 10010000. You can’t get the transaction list as it’s not defined in the subgraph, but it’s fast for what it does. You will be able to build your own subgraph by using The Graph and Ethereum nodes deployed by Chainstack. Check out our The Graph service at Chainstack marketplace and reach out to us if you want to launch a Graph node on Chainstack. Conclusion GraphQL is a great and efficient way to query live Ethereum data on full and archive nodes. Go Ethereum did a great job implementing GraphQL. If you have a set of specific queries that you need to run often and with fast response times, your best bet is to build your own pre-indexed data set—called subgraph—by using The Graph and Chainstack Ethereum nodes. The data set will be updating itself live by pulling the data off Ethereum nodes and putting it in your Graph database that you can query any time. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Helius RPC provider overview (2026) Solana teams care about two things: how quickly you can read state and how reliably you can land transactions when the network is busy. Helius leans into both with Solana‑specific plumbing, staked connections for sends, gRPC‑class streaming, and pre‑parsed data so you write less glue code. Helius.dev Homepage Helius is a Solana-focused RPC provider and data platform that bundles staked RPC sends, Sender’s parallel submit path to Jito, Yellowstone-compatible LaserStream with replay and regional failover, faster Enhanced WebSockets, and DAS APIs for assets and transactions, all wrapped in a credit-based model with clear RPS caps and optional fixed-rate streaming tiers. Where Helius fits (and where it doesn’t) Best fit Solana‑only projects that need fast inclusion and low‑latency streams. Sender + staked defaults help when slots are tight. Teams that don’t want to maintain Yellowstone clusters; LaserStream is turnkey and adds replay/failover. Apps that hate writing parsers. DAS and Enhanced Transactions cover common asset and tx workflows. Not ideal Multi‑chain roadmaps (you’ll need a second provider elsewhere). Workloads that can’t tolerate plan gating (e.g., LaserStream mainnet is Professional+; Enhanced WS sits on Business+). Product surface RPC nodes (HTTP/WSS). Paid plans use staked connections by default via the regular mainnet endpoint; “secure” masked URLs exist for frontends. Streaming choices. LaserStream (gRPC) — drop‑in for Yellowstone; adds historical replay, auto‑reconnect, and multi‑region endpoints. Enhanced WebSockets — 1.5–2× faster on average than standard WS; now powered by the LaserStream backend. Webhooks — server‑to‑server pushes when you prefer HTTP over sockets. Data APIs. DAS (Digital Asset Standard): ownership/metadata for tokens, NFTs, and compressed NFTs. Enhanced Transactions: human‑readable tx data + address history. getTransactionsForAddress: Helius‑exclusive, paginated, filterable history in a single method. Send path. Sender: submits in parallel to Jito and Helius across 7 regions; no credits billed, min 0.001 SOL tip; tuned parameters recommended for speed. Specialized option. Shred Delivery (beta): UDP feed of raw shreds for desks chasing single‑digit‑ms advantage. Pricing at a glance Helius uses a credit-based pricing model with additional pricing components for streaming and dedicated infrastructure. Pricing is structured around three main components: Plans include monthly credits with request-per-second (RPS) caps. Data add-ons for LaserStream and Enhanced WebSockets are priced as fixed tiers ranging from 5 TB to 100 TB per month. Dedicated Solana nodes are listed as starting at around $2,900 per month. Because RPC methods, streaming volume, and data services all consume credits or data bandwidth differently, total cost depends not only on request volume but also on streaming usage and the specific APIs used. Helius Pricing/Credits MetricChainstackHeliusPlan used in exampleProBusinessIncluded usage80M Request Units100M API CreditsExample workload73.5M calls73.5M callsPlan price$199$499Overage$0$0Total monthly cost$199$499 In this example, both workloads fit within included usage, but the pricing models differ significantly — request-based pricing ties cost directly to request volume, while credit-based pricing depends on method mix and streaming usage. See the full cost comparison → Tip: If streaming volume is your biggest cost variable, use right‑size filters and consider fixed‑rate tiers if you’re always on. Strengths and trade‑offs StrengthsTrade‑offs / watch‑outsStaked sends by default on paid plans; less work to get good landing rates.Single‑chain scope. Great for Solana, not for multi‑chain stacks.LaserStream gives Yellowstone features without the ops burden (replay, failover, regional).Some features are plan‑gated (e.g., LaserStream mainnet = Professional+; Enhanced WS = Business+). Enhanced WebSockets (now on LaserStream infra) and Webhooks simplify real‑time work.Streaming volume can dominate cost; use the data add‑on or tighten filters.DAS + Enhanced Tx + getTransactionsForAddress reduce custom indexing and parsing.Parsers don’t cover everything; some protocols still need bespoke logic.Sender routes to Jito + Helius in parallel (0 credits; tip required).Needs fee/tip tuning; recommended params (e.g., skipPreflight) won’t suit every workflow. Helius vs. Chainstack Scope Helius: Solana‑only, optimized around low‑latency streaming and fast inclusion. Chainstack: Multi‑chain with managed Yellowstone gRPC and an Unlimited Node option for flat‑fee, RPS‑tiered scaling when you want predictable cost. Pricing posture Helius: Credit plans + data add‑on for streaming; good when you want granularity and can size your data budget. Chainstack: Transparent request‑based plans and flat‑fee Unlimited Node to cap spend under steady or bursty workloads. Try Chainstack with predictable RPC pricing → FAQ How do I start on Helius? Create a key, point to the mainnet/devnet endpoints. On paid plans, staked connections are automatic—no endpoint swap needed. What’s the big deal with LaserStream? It’s a managed, Yellowstone‑compatible gRPC with replay and multi‑region failover. Use it when you need reliable, low‑latency streams without running your own nodes. Does Sender cost credits? No credits; you tip in SOL and it routes to Jito + Helius in parallel. Tune fees for your risk profile. Any gotchas on pricing with Helius.dev? Streaming volume with Helius is the variable. Consider the data add‑on or tighten filters #### Hello blockchain world, we are Chainstack Announcing our launch #buidl it, and they will come Launching any Platform as a Service (PaaS) is tough. Launching a blockchain PaaS, even tougher. Industry insiders would agree — from identifying the right set of problems that deserve to be solved to continual prioritization can seem like a never-ending story of dilemmas and decisions. Add to that, in our case, the constantly evolving protagonist, the blockchain, and things only get more exciting. Enterprise blockchain is arguably the most contentious, misunderstood, and under-leveraged technology, and we are here to play a part in helping the world understand and benefit from its massive potential. Which is why this is a momentous time for every one of us at Chainstack and every other person who has believed in our vision — of building the easiest to use, yet world’s most sophisticated PaaS that will contribute to blockchain’s adoption in the real world.   Founders Laurent Dedenis and Eugene Aseev at Chainstack’s first presentation to a packed audience. SGInnovate, Singapore. June 2018. Only a few days ago, our first email to early adopters went out inviting them to sign up and try Chainstack. This singular moment has been around nine months in the making. During this period, we have been patiently building the plumbing that enables companies to deploy blockchains in minutes, a process that would normally take hours or even days. Some might even call this process an ordeal. But from today onwards, developers and enterprises have a significantly better choice. Was this the face that launch’d a thousand ships,And burnt the topless towers of Ilium… Marlowe’s Dr. Faustus on Helen of Troy Remember the rise and dominance of Ruby on Rails, or, for that matter, Docker? Theirs was the face that launched a thousand ships in the worlds of web development and containerization respectively. The process of launching technology-based products has not been the same since then, with more power, more ease, and incredibly richer applications at a fraction of the cost now being the norm. At Chainstack, we want to be the face that will help launch a thousand (and more) decentralized applications on the blockchain. Someday, and very soon we believe, launching decentralized applications with ease will be the norm. As that unfolds, you will find Chainstack right there in the thick of the action, reliably shouldering all the infrastructure complexity that goes with deploying blockchains. Many blockchain developers liken the maturity of the blockchain tools and frameworks to those of the web during the early days of the Internet. […] There is extremely low-hanging fruit in making the field more accessible, and a lot of technical infrastructure needs to be built up to bring blockchain from 1994, in internet terms, to 2017. Building for the Blockchain How do you eat an elephant? One bite at a time Breaking down a problem into small manageable parts and building solutions incrementally is the de facto way of problem-solving. It works exceedingly well in the case of independent isolated pieces of software, large or small. But in the case of blockchains, we have discovered that a reductionist approach combined with a systems approach works best. The blockchain is where cryptography, distributed computing, and governance converge. At Chainstack, we are eating the elephant one bite at a time with eyes on the forest. Some of the finest minds world over have contributed to powerful enterprise protocols such as MultiChain, Quorum, and others. We believe there is simply no ‘one ring to rule them all’. In fact, the complexity of modern business and myriad use cases calls for an approach that goes beyond ‘one size fits all’. This is precisely the rationale for our universal approach. We want to offer a wide choice to the enterprise and developers not just in terms of blockchain protocols, but also in terms of hosting environments. In our first release, we have chosen to offer MultiChain, Quorum, Ethereum with hosting on Google Cloud and AWS, and more are on their way. Support for leading protocols with a choice of Mircosoft Azure, Digital Ocean, Alibaba Cloud as well as hybrid and on-prem environments are on the roadmap. Stay tuned for updates on that front. Chainstack is quite innovative in its vision about how the enterprise will use blockchain going forward. Being multi-cloud and multi-protocol will give the Fortune 500 and their partners the single panel they need to manage frequent and large blockchain deployments in heterogeneous environments. Akihiko Katayama, Director, PwC Our current tech stack employs the following key technologies and more.   Our tech stack Beyond the dizzying array of microservices, APIs, and clusters, there’s something that’s unseen and that holds the workings of successful decentralized platforms: governance. Any effective blockchain platform should enable organizations that decide to come together to define and execute clearly as per governance policies. In that regard, we are not there yet, admittedly, but well on our way. While our code gurus have been grappling with and resolving hard technical choices, our hands-on leadership and solutions architect have been drafting sophisticated governance mechanisms that should help consortia and mega-consortia transact smoothly. Even in its current form, Chainstack’s projects-based and intuitive collaboration workflow provides great value to enterprises keen on collaborating on blockchain projects. Try taking Chainstack for a spin, and you will know what we mean. The function of good software is to make the complex appear to be simple. Grady Booch Let’s get back to the tech for a while. Several developers have found the entire stack required to launch decentralized projects on a public chain to be notoriously confusing and time-consuming. Synchronizing nodes with the mainnet itself, among several other tasks, is a challenging one, and this quote from the latest DApp survey is telling. Developers pointed out that sometimes using multiple technologies to connect to the blockchain was required to keep the DApp state and user interface up to date. Among the reasons to use multiple technologies was the fact that connectivity issues and node stability might present a problem and affect overall DApp quality — having a negative impact on the end user experience. DApp survey results At Chainstack, we are radically simplifying the entire process of blockchain deployment. Launching nodes effortlessly, whether it’s permissioned or public, in as short a time as possible should be a given. This is so that developers and enterprises can direct a major chunk of their limited resources to build DApps that address various use cases. Furthermore, with efficiencies on multiple fronts, enterprises can direct their efforts towards building blockchain-based consortiums that unlock value. Our rapid deployment and sync take only a few minutes, and we are pushing the boundaries on that front. If you are curious to see how it all works, you can register for one of our upcoming webinars, or try it for yourself. Humans! The secret sauce Over a blistering pace spread across nine months, we have grown 400%. Today our team comprises 7 nationalities and speaks a multitude of languages combined. On a lighter note, for a company that prides itself on being multi-cloud and multi-protocol, being multi-lingual is a natural extension. Tackling hard problems at work is just one part of the story that we are living in. Dragon boat racing, team running, wine and cheese now and then, that’s the smorgasbord that makes building a global PaaS company, especially in blockchains, exhilarating. On that note, we are hiring across a variety of roles; and if you fancy yourself being part of a team that is boldly taking on the complexity of the blockchain world, drop us your CV via our AngelList page. In a fast-paced process, you will encounter an interview, a take-home challenge, and a chat with the CEO as the final step. And it doesn’t matter where you are, as long as you are open to relocating to this bustling, dynamic corner of the world called Singapore. I think by then we will have stopped talking about blockchain technology, and it will be part of a tech stack that delivers a distributed, secure transaction record. I also think we will have sorted out smart contracts and they will be fairly ubiquitous, enabling efficiencies across many sectors. My hope is that we will have re-imagined economic and business models in a way that emphasizes stakeholder engagement rather than shareholder extraction, creating a more sustainable and balanced economic system for all. Sheila Warren, Head of Blockchain and Distributed Ledger Technology, World Economic Forum (WEF) We couldn’t have said it better. At Chainstack, we pride ourselves on working at the boring end of exciting technology. Call it plumbing, nuts-and-bolts, infrastructure, it all boils down to building a reliable, fault-tolerant layer, which enterprises and developers of the world can leverage to rapidly build decentralized applications. It is our thesis that these applications will not only enlarge markets, but also create new ones. This is because coming together on the blockchain is a whole new paradigm — it’s a collaboration rather than competition, it’s win-win rather than a zero-sum game. For more on our views on this topic, read All We Need Is Trust. To that end, we will be pushing out support for more protocols, whether permissioned or public. We will push out support for more hosting environments. And we will push out sophisticated governance so that complex and mega-consortiums can confidently realize their decentralization goals. Explore Chainstack Try Chainstack for free Access our developer resources and community Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How AI agents talk to blockchains with MCP and RPC Key takeaways A single agent reasoning step typically generates three to seven RPC calls. Multi-step workflows compound that load — which is why the node API layer, not the LLM, is usually the bottleneck in production agentic Web3 systems. The node API layer splits across two interfaces that coexist: raw JSON-RPC for the hot path of reads, writes, and event subscriptions, and MCP (Model Context Protocol) for tool discovery, documentation lookup, and node lifecycle operations the agent invokes autonomously. A practical walkthrough of a stablecoin treasury agent follows below, showing one full reasoning cycle from LLM prompt to on-chain transaction — including realistic RU consumption for production-scale deployment. What an agentic Web3 workflow actually is An agentic Web3 workflow is a sequence in which an LLM-driven agent uses blockchain node APIs to read on-chain state, reason about it, and write transactions back to the chain — repeating the cycle until a goal is met. That sentence is dense, so unpack it: there is an LLM, there is a goal, there is a node API layer between the LLM and the chain, and there is a loop. The loop is what makes the workflow agentic rather than scripted. A scripted bot follows a fixed sequence. An agentic workflow lets the LLM decide what to do next based on what it just learned from the chain. Three properties distinguish an agentic Web3 workflow from a traditional dApp interaction: The agent — not a human — decides which RPC method to call, and when. There is no fixed call sequence. The agent operates autonomously across multiple reasoning steps, often for minutes or hours, without a UI in the loop. The agent reads and writes on-chain state through a node API, which can be raw JSON-RPC, MCP tool calls, or both. The third property is where most teams underestimate complexity. The LLM is the visible part. The node API layer — how the agent actually talks to the blockchain — is where reliability, latency, and cost live. The two interfaces between an agent and a blockchain When a Web3 AI agent needs to interact with a chain, the request flows through one of two interfaces. Sometimes both, in the same reasoning step. Raw JSON-RPC. The agent (or its tooling) constructs a JSON-RPC payload and sends it directly to a node endpoint. This is how web3.py, ethers.js, and every other Web3 library talk to nodes. It is fast, flexible, and gives the agent full access to every method the node exposes. It is also brittle from an LLM’s perspective: the agent has to know the method name, the parameter order, the encoding rules, and how to interpret the response. Get any of that wrong and the call fails silently or returns junk. MCP (Model Context Protocol). MCP is an open standard from Anthropic that defines a structured tool interface an LLM can discover and call autonomously. Instead of an agent constructing a raw eth_getBalance payload, it calls an MCP tool like get_balance with named parameters, gets back a typed response, and knows what it received without parsing hex strings. MCP wraps RPC — under the hood, the MCP server still talks to nodes — but it exposes that capability as a tool the LLM can reason about. The Chainstack MCP server is a hosted implementation that gives agents access to node lifecycle operations, documentation search, platform status, and live pricing through a single HTTP endpoint — connection guides are available for Claude and Codex. The simplest way to think about it: raw JSON-RPC is what the chain speaks. MCP is what the LLM speaks. The agent runtime translates between them. InterfaceBest forLimitationsRaw JSON-RPCHigh-frequency reads, transaction submission, WebSocket subscriptions, methods not exposed by the MCP serverAgent has to know method signatures; failure modes are opaque to the LLMMCPTool discovery, documentation lookup, node deployment, structured queries the LLM can reason aboutOne layer of indirection; not appropriate for sub-millisecond hot paths The rest of this article walks through exactly how these two interfaces interleave during one full reasoning cycle. Before that, the anatomy. Anatomy of a single reasoning step A single reasoning step inside an agentic Web3 workflow has six stages. They look like this: 1. PROMPT — the agent receives a goal or sub-goal 2. TOOL SELECTION — the LLM decides which tool(s) it needs 3. TOOL CALL — the runtime executes the tool: MCP, raw RPC, or both 4. CHAIN ACCESS — the node provider returns blockchain state or transaction result 5. INTERPRETATION — the LLM parses the response and updates its working state 6. DECISION — the LLM decides whether the step is complete or another tool call is needed Stages 3 and 4 are where the blockchain node API layer sits. Everything else is LLM mechanics. But stages 3 and 4 determine whether the workflow completes in seconds or stalls at a 429. Two things compound across reasoning steps. First, a single step rarely uses one RPC call — it uses three to seven, because the LLM tends to verify state before acting (read balance, read allowance, check gas, simulate, then send). Second, a workflow rarely has one step. A stablecoin treasury agent rebalancing positions across three chains can run twenty to fifty reasoning steps in a single execution, each triggering its own bundle of RPC calls. The aggregate load is what breaks shared infrastructure — covered in detail in the Chainstack guide to blockchain RPC for AI agents. Walkthrough: a stablecoin treasury agent rebalances positions Concrete example. The scenario is realistic for any fintech or institutional team running stablecoin operations: a treasury holds USDC across Ethereum, Base, and Solana for operational liquidity. When the balance on any chain drops below a threshold — say, $50,000 — the agent moves USDC from the chain with the highest excess to top it up. The agent’s job: detect the deficit, choose a source chain, simulate the transfer, execute it, and confirm settlement. One full execution cycle, end to end. Step 1 — The agent gets its goal The treasury system sends the agent a prompt: Check USDC balances on Ethereum, Base, and Solana for treasury address 0x7a23…f2c1. If any chain is below $50,000, top it up from the chain with the largest excess. Do not exceed $200,000 in a single transfer. The LLM parses the goal. It identifies three sub-tasks: read balances, evaluate the deficit, execute the transfer. It needs blockchain access for the first and third. Step 2 — The agent reads balances across three chains The LLM decides to use a tool. If the agent is configured with the Chainstack MCP server, it could ask the MCP layer to search docs for the right method, but in this case it already knows: USDC is an ERC-20 on Ethereum and Base, an SPL token on Solana. It needs eth_call to the USDC contract’s balanceOf method on the EVM chains, and getTokenAccountBalance on Solana. For Ethereum, the agent (via web3.py in its runtime) constructs a JSON-RPC batch: [ {"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","data":"0x70a082310000000000000000000000007a23...f2c1"},"latest"],"id":1}, {"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","data":"0x70a082310000000000000000000000007a23...f2c1"},"latest"],"id":2} ] That’s two eth_calls — one to USDC on Ethereum, one to USDC on Base — submitted as a JSON-RPC batch over a single HTTP request. Batching cuts three potential round trips down to one and consumes one RPS slot instead of three. (Why batching matters under burst load: see the RPC-for-agents guide.) On Solana, the agent uses getTokenAccountBalance against the treasury’s USDC token account. Three reads, two HTTP requests, one to each chain provider. The Python that issues these reads looks like this — note that this is the actual code path, not a framework abstraction: from web3 import Web3 from solana.rpc.api import Client eth = Web3(Web3.HTTPProvider(CHAINSTACK_ETH_URL)) base = Web3(Web3.HTTPProvider(CHAINSTACK_BASE_URL)) sol = Client(CHAINSTACK_SOL_URL) USDC_ETH = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" USDC_BASE = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" TREASURY = "0x7a23...f2c1" TREASURY_SOL_USDC_ACCOUNT = "..." eth_balance = eth.eth.contract(address=USDC_ETH, abi=ERC20_ABI).functions.balanceOf(TREASURY).call() base_balance = base.eth.contract(address=USDC_BASE, abi=ERC20_ABI).functions.balanceOf(TREASURY).call() sol_balance = sol.get_token_account_balance(TREASURY_SOL_USDC_ACCOUNT).value.ui_amount The runtime returns balances to the LLM as structured data: {"ethereum": 42100, "base": 187500, "solana": 95200}. Step 3 — The agent evaluates and decides The LLM now has state. It reasons: Ethereum is at $42,100 — below the $50,000 threshold by $7,900. Base has $187,500, the largest excess. Source = Base, destination = Ethereum, amount = $10,000 (round up from $7,900 to give buffer, well under the $200,000 cap). This stage is pure LLM reasoning. No chain access. But it produces the parameters for the next on-chain action. Step 4 — The agent simulates the transfer before execution Before sending real funds, the agent simulates. This is the step most non-agentic scripts skip and most production agents include — because the cost of a failed transfer is non-trivial and the cost of a simulation is negligible. Chainstack nodes expose eth_simulateV1 and full Foundry-forking support for this. The agent constructs a transfer call against the USDC contract on Base, with from = treasury, to = bridge_contract, amount = 10000 * 10**6, and simulates against the current state. If the simulation succeeds and reports the expected balance changes, the agent proceeds. If it fails — wrong allowance, insufficient gas, paused contract — the agent surfaces the error and either retries with adjusted parameters or escalates. sim_result = base.eth.call({ "from": TREASURY, "to": USDC_BASE, "data": transfer_calldata, }) # sim_result == b'\x00...\x01' means success in ERC-20 transfer simulation Step 5 — The agent uses MCP to verify it has up-to-date method signatures This is where MCP earns its keep. Before constructing a cross-chain transfer (USDC on Base going to Ethereum requires bridging through CCTP — Circle’s Cross-Chain Transfer Protocol — not a direct ERC-20 transfer), the agent calls the MCP search_docs tool: mcp_call: search_docs("USDC cross-chain transfer Base to Ethereum CCTP") The MCP server returns the relevant documentation pages. The LLM reads them, identifies the correct method signatures and contract addresses for CCTP’s depositForBurn on Base and receiveMessage on Ethereum, and constructs the transaction with verified parameters. This eliminates the most common LLM failure mode: hallucinated method names or stale contract addresses. Without MCP, the agent has two bad options: rely on the LLM’s training data (which may be outdated), or hardcode the method signature in the agent’s tool definitions (which breaks the moment Circle deploys a new version). MCP lets the agent fetch the canonical truth at runtime. Step 6 — The agent submits the transaction Back to raw RPC for the actual write. The agent signs the transaction (using a key held in its own secure environment — never exposed to the LLM context), constructs the eth_sendRawTransaction payload, and submits: { "jsonrpc": "2.0", "method": "eth_sendRawTransaction", "params": ["0xf86c0a85046c7cfe008252089...signed_tx_hex..."], "id": 1 } The node returns a transaction hash. The agent stores it. Step 7 — The agent confirms settlement The transfer is async — CCTP burns USDC on Base, emits an attestation, and Circle’s attestation service signs it. The agent then submits receiveMessage on Ethereum to mint the equivalent USDC. End-to-end, this can take a few minutes. The agent could poll eth_getTransactionReceipt every few seconds, but that wastes RPS. Better: subscribe to the receipt via WebSocket and let the chain push the confirmation when it lands. async with websockets.connect(CHAINSTACK_ETH_WS) as ws: await ws.send(json.dumps({ "jsonrpc": "2.0", "method": "eth_subscribe", "params": ["newHeads"], "id": 1 })) # then watch for the destination transaction confirmation When the destination tx lands and emits the MessageReceived event, the agent has confirmation. Its working state updates: Ethereum balance is now ~$52,100, deficit closed. The workflow ends. The agent logs the cycle and waits for the next polling interval. What just happened, by the numbers One execution cycle of this agent generated: 3 read calls (balance checks across three chains) 2 simulation calls (Base transfer, Ethereum receive) 2 documentation lookups via MCP 2 write transactions (Base burn, Ethereum mint) 1 WebSocket subscription That’s ~10 distinct interactions with the blockchain layer for a single rebalancing cycle. If this agent runs every five minutes across a 24-hour window, that’s roughly 2,880 chain interactions per day — for one treasury, on stable operating conditions. During market events or fee spikes the load can multiply 3-5x as the agent retries, re-simulates, or escalates. In Chainstack Request Units, a steady-state day for this treasury runs around 3,000 RUs — most calls are standard full-node reads at 1 RU each, with archive lookups for reconciliation adding 2 RUs each when they occur. A burst day at 5x load comes in under 15,000 RUs. That is the unit economics of one agent. The number to remember when you start adding more. This is why the choice of node API provider is not incidental for agentic Web3 workflows. It is the substrate. When to use MCP, when to use raw RPC The walkthrough above used both interfaces. The choice in each step was deliberate. Here is the underlying logic. The agent is doing…Use MCPUse raw RPCLooking up which method or contract to use✅ search_docs—Deploying or destroying nodes mid-workflow✅ node lifecycle tools—Reading account balances at high frequency—✅ eth_call, batchedSubmitting a signed transaction—✅ eth_sendRawTransactionSubscribing to live events—✅ WebSocket eth_subscribeChecking platform or node health programmatically✅ get_platform_status—Decoding an unfamiliar event log✅ get_doc_page for ABI reference—Pricing or quota questions for the agent’s own operations✅ get_chainstack_pricing—Simulating a transaction before send—✅ eth_call / eth_simulateV1Multi-call aggregation across many contracts—✅ Multicall3 The pattern: MCP for discovery, governance, and meta-operations. Raw RPC for the hot path of reading and writing chain state. Agents that try to do everything through MCP add latency to operations that should be sub-100ms. Agents that try to do everything through raw RPC reinvent documentation lookup, error parsing, and node management — usually badly. The right mix uses each for what it is good at. Multi-step workflow patterns The treasury walkthrough was a single linear cycle. Real agentic Web3 workflows are rarely linear. Four patterns recur across production agents. Sequential One step, then the next. The treasury walkthrough is sequential — balance reads, decision, simulation, send, confirm. Each step waits for the previous one. Easy to reason about, easy to debug, but slow when steps are independent. Parallel Multiple sub-agents or sub-tasks execute concurrently against the same node infrastructure. A multi-chain monitor might subscribe to events on six chains in parallel, each running its own reasoning loop. Parallelism multiplies aggregate RPS load — the load profile analysis covers this in detail. The fix is either a Dedicated Node per high-load chain or a single dedicated node with capacity headroom for the parallel fan-out. Conditional The agent’s next action depends on what it reads from the chain. The treasury agent only triggers a transfer if a balance threshold is breached. Conditional workflows look light in the average case but produce burst load in the trigger case, when many sequential calls fire in quick succession. Retry with state preservation The agent encounters an error mid-workflow — a 429, a failed simulation, a timed-out confirmation. It needs to retry without losing context. This requires the agent runtime to externalize state (typically to a database or message queue) so retries can resume from the last verified state rather than restarting the cycle. Combined with exponential backoff and jitter, this is what separates production agents from demos. What this means for building production agents Three things hold across every agentic Web3 workflow worth building. MCP and raw RPC are not alternatives — they are complementary layers. The agent uses MCP for the operations where the LLM benefits from structure: discovering which method to call, looking up a contract address, checking platform status, deploying or destroying nodes. It uses raw RPC for the operations where structure costs latency: high-frequency reads, signed transaction submission, WebSocket event subscriptions. Trying to force everything through one interface produces either slow agents or fragile ones. A single reasoning cycle generates enough chain interactions to break shared infrastructure. The treasury walkthrough hit ten in one cycle. A monitoring agent watching six chains in parallel can hit forty across a single decision window. The node API layer has to absorb that without rate-limiting the agent into incoherent retry loops. The full load profile analysis covers exactly how this breaks shared endpoints and what to do about it. This is not optional — it is the practical constraint that determines whether an agentic system reaches production. The difference between a demo agent and a production agent is state preservation under error. A demo handles the happy path: read, decide, simulate, send, confirm. A production agent handles the day when simulation fails, the confirmation never arrives, the rate limit triggers mid-workflow, or the chain reorgs. Building the agent so it can resume from the last verified state — rather than restart from the original goal — is the work that separates the two. If the agent is correctly designed and the infrastructure underneath is correctly chosen, the LLM is rarely the limiting factor. The chain interactions are. That is where the engineering attention should go. The Chainstack pieces Mapping the walkthrough back to the infrastructure it ran on: Global Nodes and Dedicated Nodes — the raw RPC endpoints the agent talks to for reads, writes, and WebSocket subscriptions. Dedicated Nodes eliminate rate-limit contention for production agentic workloads. Global Nodes reduce P99 latency through geo-routing. For agents that need maximum transaction landing rate — high-frequency trading, MEV, time-sensitive arbitrage — Trader Nodes are the right default on Solana. MCP server at mcp.chainstack.com/mcp — the structured tool layer for documentation, platform status, pricing, and (with an API key) full node lifecycle. Five tools work without authentication: search_docs, get_doc_page, get_platform_status, get_chainstack_pricing, contact_chainstack. Node deployment tools require a Chainstack API key. Archive Data and Debug & Trace APIs — for agents that need historical state reconstruction, transaction-level execution traces, or audit reconciliation. Costs 2 RUs per call versus 1 RU for standard full-node calls. Simulation support — eth_simulateV1, eth_call, Foundry forking, Solana simulateTransaction. The agent in the walkthrough used these to verify transfers before execution. WebSocket subscriptions and gRPC streaming — eth_subscribe and chain-specific equivalents on EVMs; Yellowstone gRPC for Solana for structured real-time data streaming. Push-based event delivery instead of polling. Reduces RPS consumption and latency for event-driven agents. 70+ supported chains (as of 2026) — Ethereum, Solana, Base, Polygon, Arbitrum, BNB Smart Chain, Hyperliquid, Monad, MegaETH, Tempo, Tron, and others. A multi-chain agent gets a single provider rather than five. To connect an agent to Chainstack: register an MCP endpoint and deploy your first node in under a minute. No credit card required for the Developer plan. Start building with AI agents → FAQ What is an agentic Web3 workflow? An agentic Web3 workflow is a multi-step loop where an LLM-driven agent reads on-chain state, reasons about it, and writes transactions back to the chain — selecting which tool to call at each step rather than following a fixed script. Do AI agents talk to blockchains through MCP or through RPC? Both. MCP is the tool interface the LLM uses for discovery, documentation, and structured operations. Raw JSON-RPC is what the underlying agent runtime uses for high-frequency reads, transaction submission, and event subscriptions. Production agents use them together. How many RPC calls does one agent reasoning step generate? Typically three to seven. A reasoning step often involves checking current state, verifying a precondition (allowance, gas, account status), simulating an action, and only then executing — each of which is one or more RPC calls. Can an agent sign transactions through MCP? The Chainstack MCP server does not hold private keys or sign transactions. Signing happens inside the agent’s own runtime, against a key the agent (or its operator) controls. MCP is used for read operations, node management, and documentation — not for handling cryptographic material. What chains does Chainstack support for agentic workloads? As of 2026, 70+ chains across EVMs and non-EVMs, including Ethereum, Solana, Base, Polygon, Arbitrum, BNB Smart Chain, Hyperliquid, Tempo, Tron, Monad, MegaETH, Avalanche, and Aptos. See the current list at chainstack.com/protocols. Does the Chainstack MCP server require local installation? No. The Chainstack MCP server runs as a remote Streamable HTTP server at https://mcp.chainstack.com/mcp. Any AI assistant or agent runtime that supports HTTP MCP transport connects directly — no binary, no Docker image, no package install. How do agentic workflows differ from scripted bots on the same infrastructure? A scripted bot follows a predetermined call sequence. An agentic workflow lets the LLM decide which RPC method to call next based on what it just learned from the chain. The infrastructure requirement is similar — both need AI-ready infrastructure with low latency and headroom for bursts — but agentic workloads add unpredictable burst patterns from LLM reasoning cycles that scripted bots do not produce. For a full hands-on build of an autonomous trading bot on Chainstack infrastructure, see Building a Web3 AI trading agent from scratch. Related reading Blockchain RPC for AI agents: infrastructure guide (2026) AI-ready infrastructure on Chainstack Chainstack MCP server How to connect Chainstack MCP server to Claude How to connect Chainstack MCP server to Codex Building a Web3 AI trading agent from scratch Chainstack MCP server documentation Mastering Web3 LLMs and AI use #### How Cartesi enhances real-time data querying with Dedicated Subgraphs Supercharging real-time data querying for robust decentralized applications The practicality of Decentralized Applications (DApps) in today’s super-connected digital world is undeniable. As such, platforms that provide a conducive environment for the creation and functioning of these DApps are of utmost value. One such platform, rich with innovation and intent on breaking barriers, is Cartesi. ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. What is Cartesi? Cartesi is a rapidly evolving platform designed to revolutionize the way decentralized applications, or DApps, are built and function. Its core pursuit is to provide a seamless, powerful, and familiar environment for developers to create scalable, secure, and decentralized applications while overcoming the computational limitations the industry often faces. At its heart, Cartesi provides application-specific rollups alongside a Linux runtime. This unique approach significantly enhances computational scalability while preserving the fundamental virtues of a decentralized system: security, censorship resistance, and the absence of a controlling entity. Cartesi’s innovative approach means each DApp gets a dedicated CPU and rollup, preventing competition for processing power that’s often an issue within Ethereum and comparable Layer 2 scaling resolutions. Under the hood of Cartesi Cartesi is not merely a platform for creating DApps; it is an innovative solution that enhances the way decentralized applications run, aiming for greater scalability, security, and flexibility. With Cartesi, developers can leverage the familiarity of a Linux runtime ecosystem while typing into the potential of application-specific rollups. Figure 1: Cartesi DApp architecture; Source: Cartesi The Cartesi Virtual Machine is one of the innovations making Cartesi a game-changer in the DApp space. Unlike on traditional platforms, developers aren’t confined to the restrictions of the Ethereum Virtual Machine (EVM). They have the freedom to run an array of mature operating systems and harness the capabilities of the RISC-V architecture. When it comes to scalability, Cartesi takes a formidable stand. Cartesi Machines operate off-chain, free from the burdens of blockchain consensus mechanisms. This approach allows them to process data at an exponential pace compared to on-chain smart contracts, setting a new precedent for speed and efficiency in the DApp world. Another aspect that sets Cartesi apart is its focus on productivity. By employing RISC-V, a wide range of software infrastructure is supported, thereby drastically increasing productivity. Developers can run key parts of their DApp logic inside Cartesi Machines atop the Linux Operating System, leveraging familiar tools and enhancing the process of DApp creation. Figure 2: Cartesi DApp communication sequence; Source: Cartesi Furthermore, with Cartesi Rollups and Rolling Cartesi Machines, developers can ensure a well-defined advancement of application state, with the ability to deliver consistent responses regardless of the operator. The power of Cartesi lies in its potential to break traditional barriers, optimizing the creation and function of DApps and laying foundations for mainstream scalability and developer productivity. Users can look forward to a more vibrant, responsive, and robust DApp ecosystem with Cartesi driving the helm. Resolving real-time data querying challenges Fetching smart contract data in real-time represents a central challenge in the DApp space, made even more complex by the computational needs and additional layers characteristic of a platform like Cartesi. Faced with complexities from querying data across multiple rollups and Cartesi Virtual Machines to handling differing characteristics and data formats, the platform needed a solution that could stand up to these demanding tasks while delivering crucial real-time data to DApp users. In the pursuit of scalable, accurate, and robust data querying, Cartesi made the savvy decision to transition to Dedicated Subgraphs. A move that demonstrated both foresight and commitment to continuous improvement, the result was a notable transformation in its data querying landscape. With our solution, Cartesi was able to navigate the challenging terrain of transitioning to a robust and versatile data querying solution without compromising its broad network support, complex data from multiple sources, or demanding processing requirements. Making this leap has delivered numerous benefits to Cartesi: greater support for popular blockchain protocols, simpler and predictable pricing structures, and an invaluable 24/7 support service, among other things. Chainstack’s dedication to maintaining seamless, flowing operations is a testament to its commitment to providing robust, reliable services to its partners like Cartesi. Thanks to Chainstack, Cartesi can efficiently query real-time data from diverse rollups and Cartesi Virtual Machines. Chainstack’s powerful suite of tools and support enables Cartesi to exceed user expectations on real-time data queries, boosting trust, and ensuring the platform remains a powerful player in the ever-evolving DApp landscape. By ensuring efficient and comprehensive data access, our solution has empowered Cartesi to provide a more robust and responsive service, contributing to the project’s continued success in the DApp ecosystem. It’s a welcome reminder of how innovative solutions, collaboration, and a commitment to solving tough challenges can drive meaningful progress in the world of decentralized applications. Resolution summary Efficiency in querying: By deploying multiple Dedicated Subgraphs, Cartesi was able to efficiently query real-time data across various rollups. Support for various protocols: The broad protocol support offered by our services allowed Cartesi to collect data from multiple sources effortlessly, thereby expanding its service across these networks. Latency minimized: At Chainstack we prioritize efficient data querying by reducing latency, ensuring faster response times. It’s particularly crucial in the DApp landscape, where real-time access to accurate data is fundamental. Customization and support: We offered personalized customizations catering to the specific needs of Cartesi. Coupled with round-the-clock support, our team ensures minimal disruptions to Cartesi’s operations. Improved data freshness: Access to real-time data contributes significantly to user satisfaction, trust, and informed decision-making. By fulfilling this key function, we play a vital role in Cartesi’s continued success. In the end, Cartesi excelled in leveraging real-time data from multiple sources and cemented its place as a pioneer in the ever-evolving DApp landscape thanks to Chainstack’s comprehensive and innovative solutions. Bringing it all together Cartesi has emerged as a groundbreaking platform in the DApps landscape, offering a unique approach to building and running DApps. By providing application-specific rollups and a Linux runtime, Cartesi has successfully addressed the computational limitations that often hinder the development of DApps. The platform’s innovative features, such as the Cartesi Virtual Machine and off-chain Cartesi Machines, empower developers to create scalable, secure, and flexible DApps with unprecedented speed and efficiency. The transition to Dedicated Subgraphs has further enhanced Cartesi’s capabilities, enabling efficient real-time data querying across multiple rollups and Cartesi Virtual Machines. This move has not only improved the platform’s support for popular blockchain protocols but also simplified pricing structures and provided invaluable 24/7 support. As a result, Cartesi can now offer a more robust and responsive service, contributing to its continued success in the DApp ecosystem. Cartesi’s commitment to innovation, collaboration, and problem-solving has positioned it as a pioneer in the DApp space. By breaking traditional barriers and optimizing the creation and function of DApps, Cartesi is laying the foundations for mainstream scalability and developer productivity. Users can look forward to a more vibrant, responsive, and robust DApp ecosystem with Cartesi at the helm. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How Chainstack makes multi-protocol, multi-cloud, and on-prem possible in minutes Photo by _M_V_ on Unsplash Companies around the globe are eager to explore blockchain technology. And for a good reason — distributed ledger systems have the potential to fundamentally change the business world. According to Deloitte’s 2018 Global Blockchain Survey, 32% of executive respondents believe blockchain technology will deliver greater speed over existing systems. Another 28% believe that this technology will result in new business models and revenue sources.   Source: Deloitte 2018 Global Blockchain Survey However, implementing a blockchain solution has typically been a daunting task for many organizations. Presented with an array of protocol and deployment options, developing a proof of concept can take months in itself. What’s worse, the end product may not deliver the return on investment (ROI) forecasted when the project began. Chainstack is an innovative enterprise blockchain solution To leverage the power of blockchain technology while minimizing these risks, more flexible solutions are crucial. Only then will more businesses be enticed to explore the world of blockchain — fueling much-needed adoption in the ecosystem. Aiming to fill this void in the market, we’ve developed a simple, innovative platform for enterprise users. Our Platform As a Service (PaaS) operates on a user-friendly interface that provides a unique sandbox environment for developers. But what makes Chainstack so different from other solutions? Perhaps most notably, the Chainstack platform facilitates the use, deployment, and administration of several enterprise protocols — all in one place. Companies can choose to employ Hyperledger Fabric, MultiChain, Quorum, and Ethereum protocols while selecting from several deployment options including: Google Cloud Platform (GCP) Amazon Web Services (AWS) Microsoft Azure On-Premises or Hybrid We’re also planning to roll out additional protocol and deployment options in the coming months for even greater functionality. At Chainstack ‘one size does not fit all’ It’s clear that we don’t believe in one size fits all. At Chainstack, we recognize that every company will have different requirements when it comes to protocols and their associated features. That’s why we help you cut through the noise. We provide recommendations based on your needs using several key indicators including: Privacy Each blockchain protocol offers a different level of privacy. But what exactly are you keeping private? While almost all enterprise blockchains are permissioned, transaction information can still be wholly or partly hidden on the network. This option is an essential consideration for those implementing a system that will handle sensitive information. Consensus There is a vast array of consensus protocols in the world of distributed ledger technology. These mechanisms ensure that networks are kept secure and transactions remain valid. As with public distributed ledgers, each enterprise solution employs a specific consensus mechanism — some supporting more than one. Determining the appropriate consensus protocol for your use case is essential to ensure optimal functionality. Malicious intent Malicious intent refers to a participant’s ability to disrupt regular network functions. Depending on the protocol used, one party may be able to “hijack” the network. This situation allows them to alter otherwise immutable records. Every company needs to determine their tolerance for these events and respond accordingly. Crash fault tolerance Crash fault tolerance relates to a systems ability to continue operating in the event of a component failure. These events will trigger specific outcomes depending on the blockchain protocol in use. As companies explore enterprise iterations, the probability of these occurrences should be considered against use cases. Performance Transaction speeds vary between blockchain protocols depending on many of the variables above. Companies need to determine the required speed of their enterprise solution based on their intended use case. Chainstack simplifies consortium projects In an increasingly global economy, businesses must share data with a growing list of vendors, suppliers and end users. But often, communication in these networks is disjointed. In these instances, consortium networks can provide immense value to participants. In sharing a distributed ledger between two or more companies, data can be deployed more efficiently. Results of the 2018 PwC Global Blockchain Survey further highlight the importance of consortium solutions. In the survey, 40% of respondents identified scalability as the top feature required for blockchain success. Another 28% pointed to interoperability as a necessary feature. For several use cases, including supply chain management, consortium networks are far more appropriate for delivering on these requirements. Only through broad collaboration can truly effective distributed ledger networks gain traction.   Source: 2018 PwC Global Blockchain Survey Fortunately, the Chainstack platform was built to accommodate the growing need for consortium blockchain solutions. Using our service, companies can set up a consortium network within minutes, not hours or weeks. Further, consortium members can choose to run multiple networks, each operating on a different protocol within the same project. This functionality means that each component of a project can be managed with the most appropriate solution.   View of multi-protocol networks on Chainstack Chainstack is charting a new course Although there are several enterprise solutions to choose from, the Chainstack platform offers a unique approach to blockchain deployment. Our intuitive dashboard facilitates ultimate flexibility through an offering of multi-protocol, multi-cloud, and on-prem functionality. Built specifically to accommodate the growing need for consortium networks, Chainstack makes collaboration simple. Beyond great functionality — we’re here to help you through the entire implementation process. We understand that deploying a blockchain can be intimidating, so we provide a wealth of knowledge and support that helps you make the right decisions. By providing exceptional flexibility within an intuitive interface, we aim to make your foray into blockchain technology seamless. So go ahead, roll out projects, deploy networks, and make as many changes as you’d like in minutes. The Chainstack sandbox was designed to put your company’s needs first. Let us show you the future of enterprise blockchain deployment. Explore Chainstack Try Chainstack for free Access our developer resources and community Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How Chainstack supports high-performance trading on Solana In an era where speed equates to success, ensuring the swift and seamless processing of transactions is a priority for Web3 developers. At Chainstack, we understand the importance of this demand, and we are dedicated to delivering solutions that empower developers, optimize efficiency, and elevate projects. Our Solana trader nodes embody this commitment. These nodes enhance Solana transactions by ensuring 100% landing rates, rapid block inclusion, and highly efficient transaction routing. Not just that, our unique integration with the bloXroute Trader API brings a new edge to your traditional trading setup. Without any need for custom setups or alterations, developers can experience the combined power of Chainstack and bloXroute, boosting transaction speeds significantly. Let’s explore the core features of Chainstack Solana trader nodes and their impact on transaction speed and efficiency. How Chainstack Trader nodes transform your Solana project From an outset, setting up your trading project to utilize our Chainstack Solana Trader nodes is a straight-forward process, and the benefits are immediate. All it needs is a simple endpoint swap to the Trader node one and your project gets transformed into a high-speed powerhouse. This seamless transition comes with a host of benefits. For starters, it guarantees 100% landing for all transactions—a feat achieved by going through some of the biggest and most reputable SwQoS Solana validators. Moreover, all your project requests pour through Chainstack Solana Trader nodes apart from the sendTransaction requests, which are smartly routed through the bloXroute infrastructure. Consequently, you relish the best of both worlds. Consider this: 75% of transactions are included in less than five blocks. Within this, 37% land within two blocks, 79% within four, and 95% within six. By the time we reach the tenth block, we’re looking at 99% of transactions landing. Full landing is achieved within 14 blocks. And remember, you get all this without any substantial change to your existing setup. No need for crafting custom, non-standard transactions or unnecessary upheavals to your current operations—it’s all there from the start. A brief overview of Solana Trader nodes on Chainstack How Solana Trader nodes approach transaction prioritization When it comes to elevating transaction speed and ensuring swift processing, priority fees play an indispensable role. However, one aspect that we’ve consciously decided not to include in our Solana Trader nodes is the front-running protection. Why? Simply because incorporating such a safeguard would shrink the number of validators who can receive the transaction, thereby delaying the transaction—a trade-off that could compromise the speed we guarantee. However, this does not imply that your transactions are left vulnerable. On the contrary, by leveraging bloXroute for your transactions, you’re placed at the very top of users, which significantly narrows down any front-running opportunities for potential adversaries. Having said that, if you want to take it a step up and further increase your chances of being included in the first two blocks, Priority Fees can be a game-changer. These fees serve as your ticket to get an earlier placement within a block and even in the earliest blocks. With Chainstack Solana Trader nodes, you can experience the power of Priority Fees and, consequently, expedite your transaction processing. Let’s explore how! How to implement Solana Priority Fees As a blockchain network famed for its high throughput and low latency, Solana offers priority fees to help users expedite their transactions. This feature becomes a critical tool for times when you need to override others, especially during high network congestion. Priority fees on the Solana network allow users to attach a higher fee to their transactions, encouraging validators to prioritize and process them quicker. Opting to set a higher compute unit price gives your transaction precedence over those with lower fees, ensuring faster confirmation times. This specific feature highly benefits time-sensitive operations like DEX trading or running high-demand events like NFT minting. To give you a clear picture, let’s walk through a practical example. In our scenario, we will demonstrate how to include priority fees in your Solana programs using the web3.js library and TypeScript. As such, you will get a comprehensive insight into priority fees, how to integrate them, and their contribution towards enhancing the performance of your Chainstack Trader node projects. // main.ts import { ComputeBudgetProgram, Connection, Keypair, LAMPORTS_PER_SOL, SystemProgram, TransactionInstruction, TransactionMessage, VersionedTransaction } from "@solana/web3.js"; import bs58 from "bs58"; import 'dotenv/config'; const CHAINSTACK_RPC = process.env.SOLANA_RPC || ""; const SOLANA_CONNECTION = new Connection(CHAINSTACK_RPC, {wsEndpoint:process.env.SOLANA_WSS, commitment: "confirmed"}); console.log(`Connected to Solana RPC at ${CHAINSTACK_RPC.slice(0, -36)}`); // Decodes the provided environment variable private key and generates a Keypair. const privateKey = new Uint8Array(bs58.decode(process.env.PRIVATE_KEY!)); const FROM_KEYPAIR = Keypair.fromSecretKey(privateKey); console.log(`Initial Setup: Public Key - ${FROM_KEYPAIR.publicKey.toString()}`); // Config priority fee and amount to transfer const PRIORITY_RATE = 25000; // MICRO_LAMPORTS const AMOUNT_TO_TRANSFER = 0.001 * LAMPORTS_PER_SOL; // Instruction to set the compute unit price for priority fee const PRIORITY_FEE_INSTRUCTIONS = ComputeBudgetProgram.setComputeUnitPrice({microLamports: PRIORITY_RATE}); async function sendTransactionWithPriorityFee() { // Create instructions for the transaction const instructions: TransactionInstruction[] = [ SystemProgram.transfer({ fromPubkey: FROM_KEYPAIR.publicKey, toPubkey: FROM_KEYPAIR.publicKey, lamports: AMOUNT_TO_TRANSFER }), PRIORITY_FEE_INSTRUCTIONS ]; // Get the latest blockhash let latestBlockhash = await SOLANA_CONNECTION.getLatestBlockhash('confirmed'); console.log(" ✅ - Fetched latest blockhash. Last Valid Height:", latestBlockhash.lastValidBlockHeight); // Generate the transaction message const messageV0 = new TransactionMessage({ payerKey: FROM_KEYPAIR.publicKey, recentBlockhash: latestBlockhash.blockhash, instructions: instructions }).compileToV0Message(); console.log(" ✅ - Compiled Transaction Message"); // Create a VersionedTransaction and sign it const transaction = new VersionedTransaction(messageV0); transaction.sign([FROM_KEYPAIR]); console.log(" ✅ - Transaction Signed"); console.log(`Sending ${AMOUNT_TO_TRANSFER / LAMPORTS_PER_SOL} SOL from ${FROM_KEYPAIR.publicKey} to ${FROM_KEYPAIR.publicKey} with priority fee rate ${PRIORITY_RATE} microLamports`); try { // Send the transaction to the network const txid = await SOLANA_CONNECTION.sendTransaction(transaction, { maxRetries: 15 }); console.log(" ✅ - Transaction sent to network"); // Confirm the transaction const confirmation = await SOLANA_CONNECTION.confirmTransaction({ signature: txid, blockhash: latestBlockhash.blockhash, lastValidBlockHeight: latestBlockhash.lastValidBlockHeight, }); if (confirmation.value.err) { throw new Error("🚨 Transaction not confirmed."); } // Get the transaction result const txResult = await SOLANA_CONNECTION.getTransaction(txid, {maxSupportedTransactionVersion: 0}) console.log('🚀 Transaction Successfully Confirmed!', '\\n', `https://solscan.io/tx/${txid}`); console.log(`Transaction Fee: ${txResult?.meta?.fee} Lamports`); } catch (error) { console.log(error); } } // Call the function to send the transaction with a priority fee sendTransactionWithPriorityFee(); For greater detail on how to set up your Solana Priority Fees project please refer to our dedicated guide here. How to estimate Priority Fees with getRecentPrioritizationFees Efficiency is a cornerstone of transaction processing, and a pivotal element to this lies within Solana’s feature, getRecentPrioritizationFees. This method equips users with the latest insights on these fees, allowing them to gain a clear understanding of the current fees attached to successful transactions. With this information, users can dynamically adjust the Priority Fees attached to their transactions. When you integrate this feature into your programs, you can tap into real-time trends and patterns on the network’s current Priority Fees. This information is not just abstract data; it serves as a strategic input, helping you decide your transaction’s fee to ensure quicker processing. To give you a better understanding, let’s look at this in action. Firstly, let’s deploy a Solana node on Chainstack, providing you direct blockchain access—crucial for effectively exploring unique features like the getRecentPrioritizationFees method. Once you deploy the node, and familiarize yourself with the getRecentPrioritizationFees method, you will develop an understanding of how you can strategically pay a prioritization fee that considerably enhances your transaction’s chance of getting included in the forthcoming block. // main.ts import { Connection, PublicKey } from '@solana/web3.js'; import 'dotenv/config'; // Strongly type the environment variable getter function getEnvVariable(key: string): string { const value = process.env[key]; if (!value) { throw new Error(`Environment variable ${key} is not set.`); } return value; } // Define interfaces for more explicit typing interface PrioritizationFeeObject { slot: number; prioritizationFee: number; } interface Config { lockedWritableAccounts: PublicKey[]; } const getPrioritizationFees = async () => { try { const SOLANA_RPC = getEnvVariable('SOLANA_RPC'); const connection = new Connection(SOLANA_RPC); const publicKey = new PublicKey('JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4'); const config: Config = { lockedWritableAccounts: [publicKey] }; const prioritizationFeeObjects = await connection.getRecentPrioritizationFees(config) as PrioritizationFeeObject[]; if (prioritizationFeeObjects.length === 0) { console.log('No prioritization fee data available.'); return; } // Extract slots and sort them const slots = prioritizationFeeObjects.map(feeObject => feeObject.slot).sort((a, b) => a - b); // Extract slots range const slotsRangeStart = slots[0]; const slotsRangeEnd = slots[slots.length - 1]; // Calculate the average including zero fees const averageFeeIncludingZeros = prioritizationFeeObjects.length > 0 ? Math.floor(prioritizationFeeObjects.reduce((acc, feeObject) => acc + feeObject.prioritizationFee, 0) / prioritizationFeeObjects.length) : 0; // Filter out prioritization fees that are equal to 0 for other calculations const nonZeroFees = prioritizationFeeObjects .map(feeObject => feeObject.prioritizationFee) .filter(fee => fee !== 0); // Calculate the average of the non-zero fees const averageFeeExcludingZeros = nonZeroFees.length > 0 ? Math.floor(nonZeroFees.reduce((acc, fee) => acc + fee, 0) / nonZeroFees.length ) : 0; // Calculate the median of the non-zero fees const sortedFees = nonZeroFees.sort((a, b) => a - b); let medianFee = 0; if (sortedFees.length > 0) { const midIndex = Math.floor(sortedFees.length / 2); medianFee = sortedFees.length % 2 !== 0 ? sortedFees[midIndex] : Math.floor((sortedFees[midIndex - 1] + sortedFees[midIndex]) / 2); } console.log(`Slots examined for priority fees: ${prioritizationFeeObjects.length}`) console.log(`Slots range examined from ${slotsRangeStart} to ${slotsRangeEnd}`); console.log('====================================================================================') // You can use averageFeeIncludingZeros, averageFeeExcludingZeros, and medianFee in your transactions script console.log(` 💰 Average Prioritization Fee (including slots with zero fees): ${averageFeeIncludingZeros} micro-lamports.`); console.log(` 💰 Average Prioritization Fee (excluding slots with zero fees): ${averageFeeExcludingZeros} micro-lamports.`); console.log(` 💰 Median Prioritization Fee (excluding slots with zero fees): ${medianFee} micro-lamports.`); } catch (error) { console.error('Error fetching prioritization fees:', error); } }; getPrioritizationFees(); For greater detail on how to set up your Solana Priority Fees estimator project please refer to our dedicated guide here. How to set Priority Fees on a Jupiter swap Jupiter stands as one of the top DEX aggregators on Solana, boasting a cumulative volume in USD billions. As a Web3 developer, you might find yourself needing to add Priority Fees to a token pair swap through a Jupiter aggregator. In our case, let’s examine how to do this using Python. Although at the time of writing this, Jupiter does not have a Python SDK, it’s equally effective when implemented in Python. For JavaScript, you can refer to their Jupiter SDK. # jupiter_swap.py import asyncio import base58 import base64 import aiohttp import statistics import time from solana.rpc.async_api import AsyncClient from solders.keypair import Keypair from solders.transaction import VersionedTransaction from solders.compute_budget import set_compute_unit_price # Configuration PRIVATE_KEY = "PRIVATE_KEY" # trader node RPC_ENDPOINT = "CHAINSTACK_NODE" # regular node # RPC_ENDPOINT = "CHAINSTACK_NODE" INPUT_MINT = "So11111111111111111111111111111111111111112" # SOL OUTPUT_MINT = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" # USDC AMOUNT = 1000000 # 0.001 SOL in lamports AUTO_MULTIPLIER = 1.1 # a 10% bump to the median of getRecentPrioritizationFees over last 150 blocks SLIPPAGE_BPS = 1000 # 10% slippage tolerance async def get_recent_blockhash(client: AsyncClient): response = await client.get_latest_blockhash() return response.value.blockhash, response.value.last_valid_block_height # Get the data on the priority fees over the last 150 blocks. # Note that it calculates the priority fees median from the returned data. # And if the majority of fees over the past 150 blocks are 0, you'll get a 0 here as well. # I found the median approach more reliable and peace of mind over something like getting some # fluke astronomical fee and using it. This can be easily drain your account. async def get_recent_prioritization_fees(client: AsyncClient, input_mint: str): body = { "jsonrpc": "2.0", "id": 1, "method": "getRecentPrioritizationFees", "params": [[input_mint]] } await client.is_connected() async with aiohttp.ClientSession() as session: async with session.post(client._provider.endpoint_uri, json=body) as response: json_response = await response.json() print(f"Prioritization fee response: {json_response}") if json_response and "result" in json_response: fees = [fee["prioritizationFee"] for fee in json_response["result"]] return statistics.median(fees) return 0 async def jupiter_swap(input_mint, output_mint, amount, auto_multiplier): print("Initializing Jupiter swap...") private_key = Keypair.from_bytes(base58.b58decode(PRIVATE_KEY)) WALLET_ADDRESS = private_key.pubkey() print(f"Wallet address: {WALLET_ADDRESS}") async with AsyncClient(RPC_ENDPOINT) as client: print("Getting recent blockhash...") recent_blockhash, last_valid_block_height = await get_recent_blockhash(client) print(f"Recent blockhash: {recent_blockhash}") print(f"Last valid block height: {last_valid_block_height}") print("Getting recent prioritization fees...") prioritization_fee = await get_recent_prioritization_fees(client, input_mint) prioritization_fee *= auto_multiplier print(f"Prioritization fee: {prioritization_fee}") total_amount = int(amount + prioritization_fee) print(f"Total amount (including prioritization fee): {total_amount}") print("Getting quote from Jupiter...") quote_url = f"<https://quote-api.jup.ag/v6/quote?inputMint={input_mint}&outputMint={output_mint}&amount={total_amount}&slippageBps={SLIPPAGE_BPS}>" try: async with aiohttp.ClientSession() as session: async with session.get(quote_url, timeout=10) as response: response.raise_for_status() quote_response = await response.json() print(f"Quote response: {quote_response}") except aiohttp.ClientError as e: print(f"Error getting quote from Jupiter: {e}") return None print("Getting swap data from Jupiter...") swap_url = "<https://quote-api.jup.ag/v6/swap>" swap_data = { "quoteResponse": quote_response, "userPublicKey": str(WALLET_ADDRESS), "wrapUnwrapSOL": True } try: async with aiohttp.ClientSession() as session: async with session.post(swap_url, json=swap_data, timeout=10) as response: response.raise_for_status() swap_response = await response.json() print(f"Swap response: {swap_response}") except aiohttp.ClientError as e: print(f"Error getting swap data from Jupiter: {e}") return None print("Creating and signing transaction...") async with AsyncClient(RPC_ENDPOINT) as client: try: swap_transaction = swap_response['swapTransaction'] print(f"Swap transaction length: {len(swap_transaction)}") print(f"Swap transaction type: {type(swap_transaction)}") transaction_bytes = base64.b64decode(swap_transaction) print(f"Decoded transaction length: {len(transaction_bytes)}") unsigned_tx = VersionedTransaction.from_bytes(transaction_bytes) print(f"Deserialized transaction: {unsigned_tx}") # Add ComputeBudget instruction to do the prioritization fee as implemented in solders compute_budget_ix = set_compute_unit_price(int(prioritization_fee)) unsigned_tx.message.instructions.insert(0, compute_budget_ix) signed_tx = VersionedTransaction(unsigned_tx.message, [private_key]) print(f"Final transaction to be sent: {signed_tx}") print("Sending transaction...") result = await client.send_transaction(signed_tx) print("Transaction sent.") tx_signature = result.value tx_details = await client.get_transaction(tx_signature) print(f"Confirmed transaction details: {tx_details}") return result except Exception as e: print(f"Error creating or sending transaction: {str(e)}") return None async def wait_for_confirmation(client, signature, max_timeout=60): start_time = time.time() while time.time() - start_time < max_timeout: try: status = await client.get_signature_statuses([signature]) if status.value[0] is not None: return status.value[0].confirmation_status except Exception as e: print(f"Error checking transaction status: {e}") await asyncio.sleep(1) return None async def main(): try: print("Starting Jupiter swap...") print(f"Input mint: {INPUT_MINT}") print(f"Output mint: {OUTPUT_MINT}") print(f"Amount: {AMOUNT} lamports") print(f"Auto multiplier: {AUTO_MULTIPLIER}") result = await jupiter_swap(INPUT_MINT, OUTPUT_MINT, AMOUNT, AUTO_MULTIPLIER) if result: tx_signature = result.value solscan_url = f"<https://solscan.io/tx/{tx_signature}>" print(f"Transaction signature: {tx_signature}") print(f"Solscan link: {solscan_url}") print("Waiting for transaction confirmation...") async with AsyncClient(RPC_ENDPOINT) as client: confirmation_status = await wait_for_confirmation(client, tx_signature) print(f"Transaction confirmation status: {confirmation_status}") except Exception as e: print(f"An error occurred: {str(e)}") if __name__ == "__main__": asyncio.run(main()) You can find the full project details in our dedicated guide here. To underscore the simplicity, here’s a brief walk-through: Use the Jupiter API to get a token pair price quote. Then, use the getRecentPrioritizationFees call from your node to gather Priority Fees data from the last 150 blocks. Calculate the Priority Fees to include in your transaction based on the data collected. With priority fee in hand, use the Jupiter API quote to prepare your swap transaction. Finally, submit the transaction through your Chainstack Solana Trader node. This approach not only guarantees faster transactions but also ensures you are managing costs effectove;y. It puts you ahead of the competition by providing you with a unique Chainstack Solana Trader node endpoint that is reliable and efficient. Further reading How to prepare for the Solana Agave 2.0 upgrade: Stay ahead with the Solana Agave 2.0 upgrade. Seamlessly build, deploy, and scale with updated APIs and resilient nodes. Solana reloaded and next gen RPCs: Explore our massive Solana infrastructure update to optimize latency, coverage, and speed for Global Nodes. How to use Program Derived Addresses: Learn how to use Program Derived Addresses for state management in Solana, their benefits, creation process, and practical applications. How to calculate transaction fees programmatically: Get to know Solana’s deterministic fee model and learn how to calculate transaction fees programmatically to optimize your project. How to retrieve historical data effectively: Learn how to retrieve historical data on Solana effectively, using transaction replay, Geyser plugins, 3rd-party services, and others. Master guide to troubleshooting common development errors: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. How to overcome the 1000 transaction limit: Learn to handle Solana’s 1000 transaction limit with getSignaturesForAddress. Use pagination and recursion to fetch large transaction lists. What is the right transaction commitment level: Get to know what transaction commitment levels are on Solana and how to make the right choice when it comes to your program use case. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Bringing it all together The Web3 development landscape is consistently evolving, and staying ahead of the curve involves leveraging innovative solutions and tools. By ensuring 100% transaction landing rates, routing through reliable SwQoS Solana validators, and allowing the use of Priority Fees for faster block placement, Chainstack Solana Trader nodes are driving an entirely new level of speed and efficiency. By offering a deep understanding of speed metrics and ensuring seamless integration with tools like the Solana web3.js library, TypeScript, and the bloXroute infrastructure, we support Web3 developers in achieving frictionless flow across their transaction processes. Additionally, with features like getRecentPrioritizationFees, which offer insights into network-wide priority fee trends, Chainstack helps developers make data-backed, strategic decisions to optimize transaction speeds. All these elements come together to make Chainstack Solana Trader nodes an essential choice for Web3 developers looking for reliable high-performance solutions. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How Curra revolutionizes crypto infrastructure for enterprises with Chainstack Non-custodial infrastructure to operate with incoming crypto payments. Switching to Chainstack was a game-changer for us. Their 99.9% uptime means we can focus on innovating, not troubleshooting. The Curra Team Entering the world of cryptocurrency is like riding the wildest roller coaster in the world. It’s filled with highs and lows, sharp turns, and breathtaking vistas. This dynamic arena is being transformed daily with technologies breaking boundaries and revolutionizing payment norms. One such force of innovation is Curra, a non-custodial infrastructure created for centralized crypto exchanges, crypto processing services, payment service providers, infrastructure providers, P2P services, iGaming operators, and eSports platforms. With a mission to take crypto to the next billion users, Curra merges cost-effectiveness, top-tier security, and a host of tailor-made features to streamline crypto payments for businesses by providing a whole new infrastructure approach. Packed with an array of powerful features, Curra aims to optimize how centralized crypto services create proxy (aka. deposit) wallets for their users and save up to 84% on Gas for businesses, savings can reach $63,300 in equivalent of ETH for each 10,000 incoming payments. Whether it’s the industry-leading security, cost-efficient payment infrastructure service or comprehensive customization options, Curra embodies the shift towards a decentralized financial future. Join us as we unravel the journey of Curra and the transformative impact of our partnership has had on their service delivery and efficiencies within the rapidly evolving crypto payments sector. What is Curra? To accept crypto payments, crypto exchanges and other crypto-friendly services usually allocate a unique proxy wallet (aka deposit address) for each end-user. Due to the architecture of EVM blockchains, all assets deposited by end-users into proxy wallets must be forwarded to the Omnibus wallet for further management. Although exchanges do not charge end-users any fees for incoming payments, exchanges and any other custodial service incur a base cost to transfer assets to the Omnibus (Hot Wallet), accepting crypto payments.The well-established implementations of crypto processing typically cost between 63,000 to 120,000 Gas for each incoming token payment. Gas usage is just one of the issues with this commonly used approach. Curra offers non-custodial toolset for high-volume crypto businesses to reduce processing costs and delegate infrastructure maintenance, working with crypto payments, they pioneered new architecture to operate with incoming crypto payments for enterprises, so they can save up to 84% on Gas across EVM-compatible blockchains.  Figure 1: Curra gas usage comparison; Source: Curra Non-custodial nature of crypto Curra’s vision is to mainstream adoption of crypto payments for businesses. To achieve this, Curra offers an infrastructure-based pricing model, without any volume-based fees. We believe that blockchain is a technology that businesses should interact without intermediaries. Enjoying exceptional reliability with Chainstack Navigating through the intricacies of the crypto payments sector, Curra experienced turbulence with node reliability and rate limits. Despite exploring various service providers, and even trying with their own on-premise nodes, their team often faced subpar performance. These mishaps demanded constant restarting and re-indexing of missed blocks, a process exerting heavy network loads, leading to technical hiccups. In addition, they were often met with rate limits while trying to re-index the blocks, further complicating operations. This is where Chainstack made a world of difference for Curra. We stood out with our superior reliability, boasting an impressive 99.9% uptime. Programmed rate limits, which were a constant bother with other services, were a non-issue with us, making Curra’s re-indexing tasks indomitably smoother. Furthermore, we’ve specifically designed our API to cater to high-audit applications. This reduces the need for additional logic layers, simplifying complex procedures, and enhancing operational flow. Even the most stable software at times requires updates or misses blocks, but our team ensured these concerns were effectively addressed. Curra noted a significant dropdown in such issues when compared to other node providers or self-hosted on-premise nodes. And last but certainly not least, we strive for maximum cost-effectiveness in our services, which is why the Curra team found our pricing structure especially reasonable, adding another positive aspect to their experience with us. In conclusion, we offered Curra a service that was significantly more stable, reliable, and cost-effective than other players in the industry. This effective solution led to reduced complexities and proved to be a valuable asset for Curra in its quest to transform the crypto payments sector. Resolution summary Curra experienced several infrastructure challenges, particularly with node reliability and rate limits. Their team explored various providers and even deployed their own on-premise nodes with little positive impact. Chainstack emerged as a viable solution, boasting a 99.9% uptime that could provide Curra with the stability their team needed. Our robust infrastructure made re-indexing tasks much simpler with the absence of programmed rate limits, a feature that caused operational complexity with other services. Chainstack’s API, specifically designed for high-audit applications, significantly reduced the need for additional logic layers. Curra found fewer problems related to updates and missing blocks in comparison to their experience with other node providers and self-hosted nodes. We offered competitive and affordable pricing for our services, adding to the long list of benefits for Curra. Ultimately, Chainstack provided a reliable and efficient solution that surpassed the other competitors, meeting Curra’s specific use case needs. Partnering with Chainstack enabled Curra to refocus on what they do best—creating exceptional crypto payment experiences for their clients, and they in turn, for their users. Bringing it all together In the tumultuous ocean of cryptocurrency, Curra offers non-custodial solution for CEXs, PSPs and other high-volume crypto services to save up to 84% on Gas, working with incoming crypto payment.Drawing from its Chainstack integration, Curra rose to the challenges they faced head-on, armed with newfound reliability, no rate limits, and a user-friendly API for high-audit applications. With our support, Curra went from dealing with frequent service interruptions and complex operational tasks to enjoying an almost always-on uptime. They found a solution that was not only significantly more stable and reliable than the rest but also cost-effective. Thus, Curra continues its journey, tapping into a new level of efficiency and stability with a significantly improved infrastructure stack from Chainstack. By overcoming its past challenges and by leveraging a powerful Chainstack integration, Curra is now closer than ever to its goal of empowering the next billion crypto users. And as the crypto world continues to evolve, we look forward to witnessing Curra playing its part in shaping the future, making cryptocurrency easier, safer, and more accessible. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How do Ethereum and Solana generate public and private keys? This is an article about the secret behind accounts, seed phrases, and key pairs. In the Web3 world, the private and public key is, and always will be a user’s sole identity on-chain. But not many people know how it works. Do you think you are a Blockchain expert? Here are some questions to test your understanding: Can Ethereum private keys be imported on Solana? Can hackers brute force crack a private key base on public information? How likely are two users are assigned to the same public address? Are different blockchains using the same cryptography system? What is a seed phrase and how does it work? This blog explains how public keys and private keys are generated on Ethereum and Solana. You can find the answer to the above questions along the way: The public key, and private key, what are they? Ethereum vs Solana How does Ethereum generate a public address from a private key? How does Solana generate a public address from a private key? How secure is this system? Technical terminologies BIP-32 and BIP-39 ED25519 and ECDSA SHA512 and Keccak-256 Conclusion What are the public key and the private key? Let’s start with the private key. Ethereum and Solana’s private keys both are 32 bytes/256 bits. So technically you can use the same key for both chains. But you should never do that, we will get into this later. In the cryptography world, private key and public key are mainly used in two areas– encryption and authentication. In both cases, the public key is known by everyone (just as the name suggested), and the private key is known only to the owner self. Let’s say Derp wants to send a message to Derpina asking her out for dinner. In the case of Encryption, Derp can encrypt his message with Derpina’s public key. When the message is sent, no one can interpret it. When Derpina receives her message, she can decrypt it with her private key. Hence message is transferred securely. Encryption in a nutshell However, encryption is NOT relevant to our topic today. For blockchain protocols, authenticity is the primary use case of cryptography. When a message, or transaction from a blockchain’s perspective, is sent, the main question is whether the message is indeed from its said sender. When a message/transaction was created, it was attached with a signature from the sender. The signature is generated from the sender’s private key and anyone can verify its authenticity with the sender’s public key. Theoretically, no one can forge a signature without knowing the private key behind it. Authenticity in a nutshell Here comes the first takeaway– the public key is generated from the private key and authenticity is the main use case for blockchain. The second takeaway for you is: a private key is not a password. Open MetaMask or any other Ethereum wallet; go to “Import account” and paste the following private key into the text box: “1111111111111111111111111111111111111111111111111111111111111111”. There are sixty-four 1s in this key string. As mentioned, Ethereum’s private key is 32 bytes/256 bits. In most cases, it is represented as hexadecimal characters. Two hexadecimal are equivalent to 1 byte of data; therefore, the private key entered is a 64-character string. MetaMask will import the following account. The account for private key “1111111111111111111111111111111111111111111111111111111111111111” Hacker in the house! 🥷 Anyone can easily access any account, as long as the private key is valid. The user does not need to provide the public key or go through any other authentication steps. This applies to both Ethereum and Solana, or any other blockchain. Ethereum vs Solana private key generation So, can a user replicate the same steps to import a random private key into a Solana wallet? The simple answer is no, at least not directly. Use two popular Solana wallets – Phantom and Solflare – as an example. This is the “Private key” from Phantom: This is the “Private key” from Solflare: Notice how these two “private keys” are in a different format? Yes, unlike Ethereum, which represents data in hexadecimal; Solana represents data in two systems(mostly): Base58 and Uint8. Both of them are valid formats and under the hood, they represent the same set of binary data. Dig a little deeper, you will realize that the “private key” data is not 32 bytes, it is 64 bytes. This is because both wallets misuse the term “private key”. According to Solana’s official documentation, this shall be called a “secret key”. The secret key is created by combining the public key and private key of the account. The first 32 bytes are the private key, the last 32 bytes are the public key. There are many terms misused/misunderstood widely in the blockchain space. It is probably best to clarify them before going further. Even though many people call the Ethereum account address a public key, it is NOT. The public key of an Ethereum account is never revealed explicitly. Solana’s account address IS its public key in Base58 format. A 64 bytes “private key” on Solana is actually its “secret key”. Base58 or Base64 is not an encoding system, they are number systems, just like decimal and hexadecimal. Generating account address from private key for Ethereum The public address of Ethereum can be derived in 3 steps. How an account address is generated from a private key on Ethereum Step 0: generating a private key on Ethereum Ethereum private key is a 32 bytes/256 bits data often represented as a 64 hexadecimal character string. Theoretically, any string can be used as a private key. Most wallets and blockchains support generating private keys from seed/mnemonic phrases, which are first defined in BIP-32, BIP-39, and BIP-44. Step 1. Using ECDSA to generate a public key Once a private key is obtained, Ethereum uses ECDSA (Elliptic Curve Digital Signature Algorithm) to produce a public key. ECDSA leveraging on Epileptic curve for validation. From this step, a public key of 128 hexadecimal characters/64 bytes/512 bits is obtained. Step 2: Hash the public key with Keccak256 Ethereum uses Keccak-256 for hashing. A hashing function basically converts a data input in any size to a fixed size output. From this step, 32 bytes/256-bit hashed data was produced. Step 3: Obtain the on-chain address The last step is to get rid of the first 12 bytes/96 bits from the hashed data. The remaining 40 hexadecimal characters/20 bytes/160 bits of data were used as addresses. Usually, the address is prefixed with “0x-”. Generating account address from private key for Solana How an account address is generated from a private key on Solana Step 0: Generating a private key on Solana Same as Ethereum, Solana’s private key is 32 bytes, but it is usually represented as an array of 32 8-bit unsigned integers(Uint8). Solana supports seed/mnemonic phrases too. Step 1: Hashing the private key with SHA512 Solana’s private key is first hashed with the SHA-512 function, converting the private key into 64 bytes of hashed data. Step 2: Pruning From the result, the second half of the hash output is discarded. Only the first 32 bytes is used to generate its public key. Step 3: Calculating the public key Solana uses Ed25519 for cryptography. Same as ECDSA, Ed25519 is an Elliptical signature algorithm. From this step, 32 bytes of data are generated. It is both the public key and the account address. Solana’s account address is usually converted to base58. Below is a table that summarizes the key differences between Ethereum and Solana cryptography: EthereumSolanaOn-Chain addressLast 20 bytes of the hashed public keyStart with 0x20 bytesPublic key itself32 bytesData formatHexadecimalBase-58 or Uint8Private key32 bytes random number32 bytes random numberWallet import/exportThe private keySolana’s “secret key pair”Cryptography systemECDSAEd25519Hashing systemKeccak-256SHA512Supports BIP32 and BIP39YesYesCryptography, Ethereum VS Solana How secure is the system? As you may know, both Ethereum and Solana are proven to be very secure, but why? Let us start with a question: “I have 100 Ethers in my account, and my private key is randomly generated. What is the chance that someone ‘accidentally’ accesses my account by entering the correct private key?” A random yellow rectangle This is a yellow rectangle. In the middle of this rectangle, there is a black dot. The yellow area represents all possible combinations of private keys and the black dot is all the addresses that have been claimed on Ethereum. Hacking Ethereum can be simplified as randomly dropping points onto this rectangle. When you hit the black dot, it means a collision occurs, an account is hacked – not a specific account though, just any random active Ethereum account. What is the probability of this happening? What about the same dot, but the yellow rectangle is the size of the whole EARTH? The actual probability of private key collision on Ethereum is roughly equal to hitting a small black dot on the earth, 3 consecutive times. Technically it is possible, but extremely unlikely. If a hacker wants to hack into a specific account, with current computation capability, it is going to take more than the age of the universe to do it. So yes blockchain is secured. But, all of this does NOT hold true if the private key is NOT randomly generated. So always generate your private key randomly. Technical terminologies There are a few important technical terms that came up in this article. It is impossible to explain them all but if you are interested to learn further, here is a high-level explanation of what they are. BIP-32 and BIP-39 Both of them are related to “seed phrase”, AKA “mnemonic phrase”. As mentioned previously, randomness is a very important aspect of private key generation. To enforce this, most wallets and blockchain supports using seed phrase to generate a private key. BIP(Bitcoin improvement proposal)-32 is a proposal submitted in 2013, it is about generating random private keys from a set of Binary data known as “seed“. BIP-39 is about using a fixed set of words to represent the “seed” data, which is called “seed phrase”. It is mainly for ease of reference and human readability. The list of words can be found here. One thing to take note of is neither the “seed phrase” nor the data derived from the seed phrase are private keys. In fact, a seed phrase can even generate multiple private keys with a Password-Based Key Derivation Function(PBKDF). ECDSA and ED25519 Both ED25519 and ECDSA are elliptic curve-based cryptography systems. They are the fundamentals of Ethereum and Solana. Both ECDSA(Elliptic Curve Digital Signature Algorithm) and EdDSA(Edwards-curve Digital Signature Algorithm ) are variants of DSA(the Digital Signature Algorithm ). Ed25519 is the EdDSA signature scheme using  a special curve named curve 25519. SHA512 vs Keccak-256 Both SHA and Keccak are hash functions. A hash function basically converts its input data(of any length) to a fix-size output. There are many variants of hashing algorithms, among them SHA(secure hash algorithm) is the most widely used. One of its important characteristics is it is non-reversible; once data is processed, it is nearly impossible to recover the source data. Both SHA512 and Keccak-256 belong to the SHA family. Their number represents the length of the output. SHA-512 returns a 512-bit/64 bytes string as result, Keccak-256’s output is 256 bits/32 bytes. Conclusion That is the end of this article. I hope you find it useful. If you have any questions to clarify, or would like to suggest a blog post that you want to see, feel free to ping me on Twitter/Telegram/Discord. Thanks for reading. Happy coding. Cheers. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How regulation is reshaping crypto infrastructure in 2026 TL;DR  Major crypto regulations (MiCA, GENIUS Act, California DFAL) become fully enforceable in 2026, ending the era of regulation by enforcement. Compliance is shifting from legal strategy to core infrastructure requirement, forcing changes at the protocol level. Platforms must now architect real-time transaction monitoring, MPC custody, and proof-of-reserves systems directly into their infrastructure.  The firms clearing regulatory approvals fastest built compliance into their systems from day one rather than retrofitting it later.  Introduction: The institutional shift in crypto regulation The difference between a compliant crypto exchange and a non-compliant one in 2026 isn’t about legal strategy anymore. It’s about whether you can keep operating. For years, crypto companies dealt with regulation mostly through enforcement. The SEC would bring an action, firms would fight it in court, and the industry learned the rules by watching who got sued. That approach is ending. 2026 is when major jurisdictions switch from debating what the rules should be to enforcing the rules they’ve written, and those rules were built specifically for crypto rather than borrowed from securities law or banking regulation. This transition is driven by institutional capital. Pension funds to banks entering crypto markets demand regulatory certainty, not risk appetite. Compliance is becoming core infrastructure. The regulatory frameworks shaping this infrastructure are global in scope but enforced locally, with different timelines and technical requirements across jurisdictions. Europe is moving first. MiCA: Europe sets the global standard July 1, 2026 is a hard deadline. That’s when the Markets in Crypto-Assets Regulation (MiCA) becomes fully enforceable across all EU member states, and crypto asset service providers without proper authorization will be ordered to cease operations. There’s no grace period left to negotiate. The requirements are specific: Anti-money laundering controls that can be audited Customer identification systems that meet EU standards Complete asset segregation Travel Rule compliance for any transfer above €1,000 The transitional arrangements that let pre-MiCA firms keep operating while their applications were processed are ending. The European Securities and Markets Authority (ESMA) provides a technical list of specific deadlines for each Member State. If you’re still waiting for authorization without provisional approval, you either find a licensed partner or stop serving EU customers. Then there’s DAC8. The Eighth Directive on Administrative Cooperation went live at the start of the year, requiring crypto platforms to report customer transaction data directly to tax authorities. The first information exchange happens in September 2027, covering all of 2026. This isn’t a voluntary transparency initiative. It’s mandatory tax reporting with penalties for failure, and it requires transaction tracking at a level of detail that many platforms never built for. MiCA gives you the license to operate. DAC8 tells you exactly what data you need to collect while you do. US regulatory reset: GENIUS Act & beyond While Europe enforces a unified framework, the US is building its regulatory structure in pieces. The approach is more fragmented, but the direction is clear. Federal stablecoin framework The GENIUS Act, signed into law in July 2025, establishes the first federal framework for stablecoin issuers in the United States. The core requirement is straightforward: every dollar of stablecoin must be backed by a dollar of high-quality liquid assets, verified monthly through independent attestations.   What counts as a high-quality liquid asset? What are the capital requirements for issuers? Which entities can hold reserves, and under what custody arrangements? Federal and state regulators are still defining the licensing structure, creating a two-track system where issuers may need both federal approval and state money transmitter licenses depending on their operational footprint. The framework exists, but the compliance infrastructure is still being built. The framework is already operational. This month, Tether launched USA₮ through Anchorage Digital Bank as the first federally regulated stablecoin under the GENIUS Act. Major issuers are now running separate products for different markets: U.S. compliant tokens for domestic users alongside global offerings for international markets. This dual approach reflects how platforms are adapting to fragmented international regulation. Market structure clarity The CLARITY Act, which passed the House in July 2025, is undergoing Senate review with committee markup scheduled for early 2026. If passed, it would end the multi-year jurisdictional fight between the SEC and CFTC by giving the CFTC authority over tokens that function as commodities.  Clear rules mean exchanges can build their custody and reporting systems with confidence, without worrying about contradictory guidance from different regulators. Token projects can launch without structuring their entire business around avoiding lawsuits. The shift from “regulation by enforcement” to defined frameworks changes more than legal costs. It changes what infrastructure you need to build. State-level action California’s Digital Financial Assets Law becomes operative on July 1, 2026, requiring licensing for any crypto business serving California residents, which given the state’s market size effectively functions as a national requirement for US-focused platforms. New York continues issuing BitLicenses with evolving standards that go beyond minimum AML requirements to include documented disaster recovery procedures, system redundancy, and predefined escalation protocols for security events. These regulatory frameworks create more than just legal compliance requirements. They are forcing fundamental infrastructure changes that go all the way down to the protocol level. FeatureEU (MiCA)United StatesLegal BasisOne single, unified EU lawMultiple laws (GENIUS Act, CLARITY Act) + Agency rulesMarket AccessLicense in one country, legal in all 27Multi-agency (SEC/CFTC) + 50 State licensesStablecoinsRegulated as E-Money Tokens (1:1 bank-grade backing)Regulated as Payment Stablecoins (GENIUS Act 2025)Asset TestingFixed categories (ART, EMT, Utility)Flexible/Judicial (Howey Test / CLARITY Act tests)SupervisionESMA / EBA (centralizedSEC / CFTC / Treasury (divided) Crypto infrastructure under pressure: Rising compliance standards The regulatory frameworks in Europe and the US set the rules. What’s less visible is how those rules are forcing infrastructure changes at the protocol level. Compliance is no longer something you add on top of your tech stack. It’s something you architect from the ground up. Custody standards evolving Multi-party computation (MPC) is replacing traditional multi-signature setups as the standard for institutional custody. In multi-sig arrangements, a complete private key exists and is split among parties      Source: What is Multi-Party Computation (MPC)? In MPC systems, the private key never exists as a complete artifact. Signatures are generated through collaborative computation across distributed nodes, where each party holds only a share that’s mathematically useless on its own. This reduces key exfiltration risk, but more importantly, it matches what regulators want to see in custody models where no single party can unilaterally access assets. Proof-of-reserves used to be a marketing tool. Now it’s a compliance requirement. Regulators aren’t asking platforms to voluntarily prove solvency. They’re mandating regular attestations from independent auditors, with specific standards for what qualifies as reserves and how verification must happen on an ongoing basis. Real-time surveillance requirements Transaction monitoring used to mean flagging large transfers and reviewing them later. That’s no longer sufficient. Platforms now analyze wallets in real-time, assessing risk based on on-chain behavior before transactions even clear. The wallet address itself becomes part of the compliance check, separate from traditional customer identification.  Compliance-by-design architecture The platforms clearing regulatory approvals fastest aren’t the ones with the best lawyers. They’re the ones that built compliance into their infrastructure from day one.  Client funds and operational funds are separated at the code level, making it technically impossible to mix them. Transaction monitoring happens during settlement, not as an afterthought. Audit trails are written automatically as transactions execute, not compiled later for regulators.  This architecture matters because regulators can verify compliance by examining the system itself, rather than reviewing policies and procedures. When compliance is embedded in how the platform operates, approval processes move faster. This matters for access.  Banks are more willing to provide fiat rails to platforms with SOC 2 Type II and ISO 27001 certifications. Institutional clients onboard faster when they can review independently audited security controls rather than trust policy documents. Regulatory approvals move quicker when examiners can verify that compliance isn’t enforced by procedure but by the infrastructure itself. SOC 2 Type II and ISO 27001 has become the baseline for infrastructure providers serving institutional clients. It demonstrates independently audited security controls that banks and funds now expect to see before working with any crypto platform. This requirement now extends beyond exchanges and custodians.  Beyond compliance certification, institutional clients now demand operational guarantees. Uptime SLAs and infrastructure reliability are non-negotiable, especially for stablecoin payment processing where downtime can freeze millions in transactions. Node infrastructure providers must deliver the same reliability standards as traditional financial rails. Chainstack’s recent SOC 2 Type II and ISO 27001 achievement combined with enterprise-grade uptime (99.99%) guarantees reflect how even foundational infrastructure layers must meet the same institutional standards to secure partnerships with enterprise clients. The Travel Rule & cross-border challenges Even as regulatory frameworks converge on similar principles, implementation is fragmenting the operational reality. The Travel Rule requires virtual asset service providers to share originator and beneficiary information for transactions above certain thresholds, but those thresholds vary: EU enforces under MiCA at €1,000 US Financial Crimes Enforcement Network sets it at $3,000 Singapore uses different standards under its Payment Services Act The bigger problem is unhosted wallets. Some jurisdictions treat transfers to self-custody as high-risk transactions requiring enhanced due diligence. Others allow them with minimal friction. This forces platforms to implement jurisdiction-specific controls for the same transaction type, where users face different requirements depending on where they’re located and where their counterparty operates. Cross-border tax reporting adds another layer. The OECD’s Crypto-Asset Reporting Framework establishes standards for how countries share tax information about crypto transactions, with the first data exchanges expected in 2027. As major markets agree on tax reporting standards, platforms can no longer avoid oversight by choosing low-regulation jurisdictions. However, countries still differ on the specifics such as what transactions must be reported and what data must be collected. Global landscape: Race for crypto hub status That inconsistency is creating competition. Jurisdictions that establish clear frameworks quickly are attracting crypto firms that would rather deal with defined rules than regulatory uncertainty, and that’s reshaping where infrastructure gets built. Hong Kong expects to issue its first Stablecoin Ordinance licenses in early 2026 as part of its push to reclaim status as a major crypto hub. Singapore has fully operationalized its Stablecoin Regulatory Framework, which was finalized in August 2023 and expanded through 2024 amendments to the Payment Services Act that brought custodial services and cross-border money transfers under strict oversight Canada is building a stablecoin framework that looks a lot like the US GENIUS Act, with similar reserve requirements and attestation standards. South Korea is working on legislation for won-backed stablecoins with strict rules around who can issue them and how reserves must be held. The frameworks vary in specifics but converge on the basics: reserve backing, regular audits, consumer protection. The Basel Committee on Banking Supervision is requiring banks to start disclosing their crypto exposure from the start of this year, with capital requirements tied to risk levels. This changes how traditional banks evaluate crypto partnerships. Banks now assess whether working with a crypto platform increases their own capital requirements, not just whether the platform is trustworthy. The partnership has to clear both reputational and regulatory hurdles. Conclusion  By 2026, crypto regulation is no longer theoretical. What matters is execution. Infrastructure is now expected to meet the same standards as traditional financial systems, with compliance enforced through how platforms are built and operated. Firms that clear regulatory approvals faster are not the ones relying on legal strategy, but those that embedded compliance directly into their infrastructure from day one. This shift raises the bar for infrastructure RPC providers. Reliability, security controls, and auditability are now baseline requirements, not differentiators. Certifications like SOC 2 Type II and ISO 27001, independently audited controls, and clear uptime guarantees have become essential for accessing banks and institutional clients. Infrastructure providers like Chainstack are built for this execution-first environment, combining compliance-by-design architecture with enterprise-grade reliability required to operate at scale. Start for free, connect your app to a reliable blockchain RPC endpoint, and build enterprise and stablecoin applications on infrastructure designed for scale, uptime, and compliance with Chainstack. #### How Stobix survived crypto’s biggest liquidation cascade 100M+ monthly RPC requests across across multiple chains 99.99% successful RPC response rate in production ~30% reduction in RPC infrastructure costs vs. previous setup On October 10, 2025, crypto markets broke. A market-wide liquidation cascade — one of the largest in the industry’s history — sent platforms scrambling. Deposit flows surged. Oracle reads spiked. Positions were opened and closed in seconds across every major chain. For most trading infrastructure, this is the moment things start going wrong. For Stobix, it was the moment their infrastructure held. Meet Stobix Stobix is an AI-powered decentralized perpetual futures protocol offering up to 200x leverage across multiple blockchain networks. The platform combines self-custody trading with real-time AI-driven market insights — an AI assistant that monitors technical indicators, tracks market sentiment, and delivers relevant insights as users navigate the market. What makes Stobix’s infrastructure problem unusually hard is the combination of product type and network breadth. Perpetual futures with high leverage are not a read-heavy, eventually-consistent workload. Liquidation accuracy, position updates, and oracle data freshness all depend on RPC quality in real time. A slow response isn’t a UX inconvenience — it’s a safety-critical failure that can affect user funds. That problem is compounded across multiple chains: Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Solana, Tron, and Bitcoin. Each has its own finality model, data layout, and RPC quirks. Keeping that stack consistent, predictable, and cost-efficient at 100M+ requests per month is not a solved problem. Michael Semin is the founder and CTO of Stobix — he architected the protocol from the ground up and continues to lead infrastructure, product development, and engineering. When he talks about RPC quality, he means it the way a pilot means it when talking about avionics: not “better would be nice” but “this is load-bearing.” The challenge: infrastructure that looks fine until it doesn’t Before settling on Chainstack, the Stobix team ran the standard evaluation cycle: public RPC endpoints, self-managed nodes, and several paid providers. The failure modes were consistent across all three. Public endpoints are unreliable under load — usable for development, not for production trading where a dropped oracle read can cascade into a liquidation error. Self-managed infrastructure scales operational overhead linearly with chain count: one node per chain per region, multiplied by multiple networks, quickly becomes a full-time engineering workload in its own right. Paid providers performed well on benchmark dashboards and degraded in production — specifically under high-traffic conditions, which is exactly when a perp DEX needs them most. Cost predictability was the second compounding issue. RPC billing at scale, with unpredictable traffic spikes during market volatility, made capacity planning genuinely difficult. Monthly spend was not a fixed line item — it was a variable with a tail that depended on how volatile the market was. For a trading business, that’s an uncomfortable coupling between infrastructure costs and market conditions. The forcing function wasn’t a single incident. It was the recognition, as Stobix scaled across more chains and added more product features, that they needed RPC infrastructure that stayed predictable under real production trading workloads — not just on synthetic tests. Why Chainstack The team evaluated Ankr, Alchemy, and Quicknode alongside Chainstack, plus several smaller providers. The evaluation criteria were specific: multiple chains including non-EVM networks, consistent latency under load, and predictable pricing at their request volume — all three simultaneously. Consistent latency where it matters: p99, not average In trading infrastructure, average latency is a misleading metric. What matters is tail latency — the p99 during the worst hour of the worst day. A trading platform can survive occasional slow responses on a calm Tuesday afternoon. It cannot survive slow responses during a market-wide event, when every user is active simultaneously, oracle reads are maxing out, and liquidation logic needs to execute precisely. Chainstack’s Global Nodes provided geo-balanced infrastructure that maintained consistent p99 performance under production trading workloads — not just synthetic benchmarks. That distinction drove the decision. Multi-chain coverage without multi-chain operational overhead Operating multiple chains with Chainstack Global Nodes compressed what had previously been a per-chain infrastructure project into a configuration change. New chain support — which previously involved evaluating providers, setting up fallbacks, tuning rate limits, and monitoring quirks per chain — became significantly simpler to add and maintain. “Adding a new chain used to involve evaluating providers, setting up fallbacks, tuning rate limits, and monitoring quirks per chain. With Chainstack, it became closer to a configuration change than an infrastructure project.” — Michael Semin, Founder & CTO, Stobix For a team operating across multiple networks, this is a meaningful operational shift. The engineering hours that were going into RPC maintenance became available for product work. Building with Chainstack Stobix runs Chainstack Global Nodes as primary RPC infrastructure across its supported chains. The workload is read-heavy but latency-sensitive: eth_getLogs queries for position monitoring, oracle freshness checks, deposit and balance reads, and transaction execution — all of which surge simultaneously during market volatility. That’s the pattern that breaks most infrastructure, and it’s the pattern Chainstack’s isolated node infrastructure is built to handle. For a leveraged trading platform, market volatility doesn’t just mean more traffic — it means financial urgency. When prices move fast, users rush to deposit collateral, close positions, and execute withdrawals simultaneously. Each of those actions touches the RPC layer: balance reads, transaction submissions, confirmation checks. A slow or dropped response at that moment isn’t a UX inconvenience — it’s a direct financial impact on the user. That’s the exact surge pattern Chainstack handles for Stobix. Chainstack is also not just a Stobix dependency. Michael’s team uses it across other internal products as well — a signal that operational consistency held up well beyond the initial deployment. The results 99.99% successful RPC response rate across all supported chains p99 latency under 250ms on heavy queries on primary EVM chains ~30% reduction in RPC infrastructure costs vs. the previous setup, with elimination of unexpected cost spikes during high-traffic events Engineering time on RPC-related issues dropped substantially, freeing the team to focus on product development But the most meaningful result happened on October 10, 2025. That day produced one of the largest liquidation cascades in crypto market history — more than $19 billion liquidated in roughly 24 hours. For Stobix, it meant a major simultaneous surge in open positions, liquidations, oracle reads, and user actions — all at once, across multiple chains. “Our infrastructure, including the Chainstack RPC layer, handled the load without degradation. Latency stayed within normal bounds, RPC error rate did not spike, and no manual intervention was required. For a trading product, that’s the moment infrastructure has to work. Anyone can look good on a calm Tuesday; the question is what happens during a market-wide liquidation cascade.” — Michael Semin, Founder & CTO, Stobix What’s next Stobix has shipped its mobile app and continues expanding chain coverage and product features. The AI agent layer — real-time market sentiment monitoring, technical analysis, and market intelligence — is an active development area. As the platform scales, the RPC infrastructure stays constant: Chainstack Global Nodes across all supported networks. “October 10 was one of the hardest days crypto has seen in years. Seeing Stobix handle that load without a single incident is exactly what we build Chainstack for.” — Eugene, Founder of Chainstack Build like Stobix Trading platforms, DeFi protocols, and real-time on-chain products need RPC infrastructure that holds up when markets don’t. Chainstack Global Nodes give you consistent performance, multi-chain coverage, and predictable costs at any scale. Build on infrastructure that holds under pressure → Bottom line For teams building trading and DeFi infrastructure, RPC quality is not a background concern — it’s directly tied to user safety and platform reliability. Stobix’s experience shows what the right infrastructure looks like under real conditions: consistent latency during liquidation cascades, predictable costs at scale, and multi-chain coverage that doesn’t require a dedicated ops team to maintain. If you need RPC infrastructure that holds up when markets don’t — and you need it across more than one chain — that’s what Chainstack is for. More ways teams use Chainstack How Whale Alert delivers blockchain alerts to 3M users with zero incidents CertiK slashed Ethereum archive costs by 70%+ while strengthening Web3 security. Nexo lowered Debug & Trace costs by 5X+ using Elastic Business data profiles. #### How to buidl your own Web3 dashboard This article will guide you through building a cool Web3-based dashboard on your own using a bit of Python and a Google spreadsheet. The idea is to help you get started on this journey of data exploration by showing you how to collect, process and present data in the simplest way possible. We will be fetching the data from Ethereum, a public blockchain platform, and we will see if we could make a dashboard out of it.  Dashing through data  The secret sauce of any thriving establishment is data. From deciding what to do next to gauging the impact of those decisions, all these steps require access to data. In this age of information, large amounts of data are not that hard to find. But having access to enormous data does not guarantee its usability. For the data to be useful, you need to make sense of it and that can be a bit of a challenge. Even in the case of Web3, which tends to democratize the flow and storage of data, making sense of all the information which is scattered throughout the various chains and nodes can be a bit daunting, but that does not stop people from doing it. I mean, you must surely be familiar with the block explorers (like Etherscan). And if you are using a node provider like Chainstack, you must have come across the node request metrics dashboard. The purpose of all these platforms is to present data in a way that is easy to grasp. With the help of diagrams, charts, graphs, etc, we can craft and narrate powerful stories out of the huge amount of data and that is a neat trick to learn. To build such a platform on your own, you would need to write a ton of code, learn a lot of analytics and, create charts… you know the works, or you can use a bit of code, and some familiar tools and get the job done. So, here is one of the easiest ways to buidl your own Web3 dashboard.  Planning the exploration  As mentioned previously, our endeavour consists of three stages: Collecting data Processing data Presenting data  Let us see how we are planning to go through each of these steps. Collecting data  All right, the first order of business in building a dashboard would be to collect the data. As we have already established, we will be fetching data from the Ethereum blockchain. We will use Python along with the web3.py library to collect the details of all the newly generated blocks in Ethereum. Once we have the blocks, we will retrieve certain details from them and store the data in our Google sheets for further processing.  Processing data  Once we store the data in our Google sheets, we can make use of all the in-built Google spreadsheet functionalities to process the data and build interactive charts and graphs out of that data.  Presenting data  After we prepare the charts, the next step would be to “embed” those charts onto a website or any other platform of your choice. We will also see how we make the charts update automatically upon receiving new data  Now that we have a plan, let us go ahead and set up a few prerequisites.  Prerequisites  Before we start building the dashboard, we need a few things.   To start things off, make sure that you have the following installed on your system  Python (version ^3.6, preferably) The corresponding version of the python package manager (pip v21.3.1) A good code editor (I recommend VSCode)  Now that we have Python, we need to install a couple of Python packages.  Let’s start with web3.py. We will use this library to access the Ethereum blockchain via an Ethereum node. To install web3.py, open a terminal and type,  $ pip install web3  Now, the web3 library cannot access the Ethereum data unless we connect to an Ethereum node, so here’s how you can set up an Ethereum node.  Heading over to Chainstack and setting up an account.Once you have your account, deploy a node in Chainstack. Note: Here, we will be fetching data from the main Ethereum chain, so go ahead and set up an Ethereum mainnet node.  Now that you have the node,   get the RPC endpoints (WSS) of the node  By using the WSS endpoint, we will be able to connect to our Ethereum node.  Apart from the web3 library, we also need to install a python package called gspread. This is a Python Application Program Interface (API) for Google sheets. To install gspread, use the following command,  $ pip install gspread  Before we can access the spreadsheet using gspread, we need to enable the google sheets API service and create the necessary credentials to authorize and authenticate our application.   Here is how you can do it  Head over to the Google Developers Console > sign in using your Google account > create a new project Click on ‘enable APIs and services Search and select google drive API > enable the API Do the same for Google Sheets API We have enabled the necessary API services, now let’s generate the credentials  In the project, go to credentials > click on Create Credentials > Select service account Note: Service accounts help applications to access data via the Google APIs  Fill in all the required details > click Done go to credentials once again > go to the service accounts section > select Edit service accounts Select keys > click Add key > click Create a new key Select JSON and click Create  This will automatically generate and download a JSON file carrying all the necessary credentials. The JSON file includes fields like account type, private_key, project_id,client_email, etc. Take care not to expose these details or share this file.  { "type": "service_account", "project_id": "PROJECT_ID", "private_key_id": "KEY_ID", "private_key": "-----BEGIN PRIVATE KEY-----\\nPRIVATE_KEY\\n-----END PRIVATE KEY-----\\n", "client_email": "SERVICE_ACCOUNT_EMAIL", "client_id": "CLIENT_ID", "auth_uri": "<https://accounts.google.com/o/oauth2/auth>", "token_uri": "<https://accounts.google.com/o/oauth2/token>", "auth_provider_x509_cert_url": "<https://www.googleapis.com/oauth2/v1/certs>", "client_x509_cert_url": "<https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL>" } To enable access to a particular google sheet,  Sign into your Google account Create a new Google spreadsheet > give it a name  Click on Share In the add people or group column, copy-paste the client_email from the JSON file Click Share  Once we share a Google spreadsheet with the client_email, we can use the gspread package and the JSON file to access it.  Great, now that we have set up a place to store the data, let us work on fetching the data.  A script to fetch data  Alright, we are about to write a Python script that will  Connect to our Ethereum node Fetch the latest blocks Retrieve the required data Add the data to our Google sheets  So, open your code editor and create a new python file, script.py  To keep the script clean and readable, I am going to break the code into a set of functions, each with a specific task. These functions will: Handle the requests Fetch the latest block information Retrieve details from the blocks Add the details to the google sheets  So, let us start by importing some necessary libraries: #for handling some asynchronous code import asyncio #for establishing connection with our node import websockets # for handling json data import json #for interacting with Ethereum node from web3 import Web3 # for interacting with google sheets import gspread We also need to set a few values  #Setting the wss endpoint CHAINSTACK_WSS_ENDPOINT = "wss://<chainstack_node_wss_enpoint" #Location of credential.json file GOOGLE_CREDENTIAL_LOCATION = "<credentials_json_location>" #Name of the spreadsheet GOOGLE_SPREADSHEET_NAME = "<google_sheet_name>" #Access drive using our credential DRIVE = gspread.service_account(filename=GOOGLE_CREDENTIAL_LOCATION) #Access the first sheet in from the google spread sheet SHEET = DRIVE.open(GOOGLE_SPREADSHEET_NAME).sheet1 Here, we used the WSS endpoint because we will try and “subscribe” to all the latest blocks created in the Ethereum blockchain. This means that we will be dealing with data streams and hence the WSS endpoint  Now that the values are set, let us write some functions.  The first set of functions would help us to manage something called filters. In Ethereum, filters notify us regarding certain events that take place in the Ethereum network. In our script, we will be dealing with the block filter, which will get us the details of all the new blocks that get generated in the network. #Function to # -> establish connection # -> send the required rpc object # -> receive and process the corresponding response # Returns result async def send_receive_data(_request_data): async with websockets.connect(CHAINSTACK_WSS_ENDPOINT) as websocket: await websocket.send(json.dumps(_request_data)) resp = await websocket.recv() return json.loads(resp)["result"] #Function to fetch the filter id async def get_filter_id(): #Prepping the request request_data = { "jsonrpc": "2.0", "method": "eth_newBlockFilter", "params": [], "id": 1 } # send request to fetch the id filter_id = await send_receive_data(request_data) return filter_id These functions will help us create a new filter using the “newBlockFilter” RPC method and fetch its id. Once we get the filter id, we can use the eth_getFilterChanges RPC method to poll for any changes in the filter (in our case, generation of new blocks) and fetch the details of those changes (the new block hash). #function to # -> establish connection with a node # -> use the filter to fetch the hash details of new blocks # -> get the details of the block using the block hash async def get_block_details(): #get the filter id filter_id = await get_filter_id() #prepare request using filter id request_data = { "jsonrpc": "2.0", "method": "eth_getFilterChanges", "params": [filter_id], "id": 0 } #connect to a chainstack node w3 = Web3(Web3.WebsocketProvider(CHAINSTACK_WSS_ENDPOINT)) #keep polling for changes while True: new_block_hash = await send_receive_data(request_data) print(new_block_hash) #pass the hash value list to get_transaction_detail if(len(new_block_hash) != 0): #fetch the block details new_block = w3.eth.get_block(new_block_hash[0]) add_data_to_sheet(new_block) Once we have the block details, we can create a function to retrieve certain details from the block. #function to extract the details from the block def extract_block_details(_new_block): #block size size = _new_block['size'] #block number blockNumber = _new_block['number'] #total gas used gasUsed = _new_block['gasUsed'] #number of transactions in the block transactionNumber = len(_new_block['transactions']) #base fee / gas baseFeePerGas = _new_block['baseFeePerGas'] #timestamp unixTimestamp = int(_new_block['timestamp']) #converting the unix timestamp to utc timestamp = datetime.utcfromtimestamp(unixTimestamp).strftime('%Y-%m-%d %H:%M') #returning the details in the form of a list return [size,blockNumber,gasUsed,transactionNumber,baseFeePerGas,timestamp] Now let’s build a function to add the details to Google sheets. def add_data_to_sheet(_new_block): blockInfo = extract_block_details(_new_block) try: SHEET.append_row(blockInfo) except Exception as e: #if we encounter "write quota exceeded" error if e.args[0]['code'] == 429: #pause the execution for a minute sleep(60) #retry with same data add_data_to_sheet(_new_block) Since we are adding multiple fields to our Google sheets, it would be wise to add a set of headers to identify the fields. To set headers in our sheet, add the following lines of code right after the code for setting the required values.  #clear all data in the field SHEET.clear() #headers for the sheet HEADERS = [ "Block size", "Block Number", "Total gas used", "Number of transactions", "Base fee / gas", "timestamp" ] #add the headers to the first line SHEET.insert_row(HEADERS,index=1) To link all these functions together, go to the get_block_details() function, remove the print statement at the end and add the following code: add_data_to_sheet(new_block)  Also, as an entry point for execution, we should add the following lines at the end of our script: if __name__ == '__main__':      loop = asyncio.get_event_loop()      loop.run_until_complete(get_block_details())      loop.close()    Alright, our completed script should look like this: import asyncio #for handling some asynchronous code import websockets #for establishing connection with our node import json # for handling json data from web3 import Web3 #for interacting with Ethereum node import gspread # for interacting with google sheets #setting the wss endpoint CHAINSTACK_WSS_ENDPOINT = "wss://<chainstack_node_wss_enpoint" #location of credential.json file GOOGLE_CREDENTIAL_LOCATION = "<credentials_json_location>" #name of the spreadsheet GOOGLE_SPREADSHEET_NAME = "<google_sheet_name>" #access drive using our credential DRIVE = gspread.service_account(filename=GOOGLE_CREDENTIAL_LOCATION) #access the first sheet in from the google spread sheet SHEET = DRIVE.open(GOOGLE_SPREADSHEET_NAME).sheet1 #clear all data in the field SHEET.clear() #headers for the sheet HEADERS = [ "Block size", "Block Number", "Total gas used", "Number of transactions", "Base fee / gas", "timestamp" ] #add the headers to the first line SHEET.insert_row(HEADERS,index=1) #function to # -> establish connection # -> send the required rpc object # -> receive and process the corresponding the response # returns result async def send_receive_data(_request_data): async with websockets.connect(CHAINSTACK_WSS_ENDPOINT) as websocket: await websocket.send(json.dumps(_request_data)) resp = await websocket.recv() return json.loads(resp)["result"] #function to fetch the filter id async def get_filter_id(): #prepping the request request_data = { "jsonrpc": "2.0", "method": "eth_newBlockFilter", "params": [], "id": 1 } # send request to fetch the id filter_id = await send_receive_data(request_data) return filter_id #function to # -> establish connection with a node # -> use the filter to fetch the hash details of new blocks # -> get the details of the block using the block hash async def get_block_details(): #get the filter id filter_id = await get_filter_id() #prepare request using filter id request_data = { "jsonrpc": "2.0", "method": "eth_getFilterChanges", "params": [filter_id], "id": 0 } #connect to a chainstack node w3 = Web3(Web3.WebsocketProvider(CHAINSTACK_WSS_ENDPOINT)) #keep polling for changes while True: new_block_hash = await send_receive_data(request_data) print(new_block_hash) #pass the hash value list to get_transaction_detail if(len(new_block_hash) != 0): #fetch the block details new_block = w3.eth.get_block(new_block_hash[0]) add_data_to_sheet(new_block) #function to extract the details from the block def extract_block_details(_new_block): #block size size = _new_block['size'] #block number blockNumber = _new_block['number'] #total gas used gasUsed = _new_block['gasUsed'] #number of transactions in the block transactionNumber = len(_new_block['transactions']) #base fee / gas baseFeePerGas = _new_block['baseFeePerGas'] #timestamp unixTimestamp = int(_new_block['timestamp']) #converting the unix timestamp to utc timestamp = datetime.utcfromtimestamp(unixTimestamp).strftime('%Y-%m-%d %H:%M') #returning the details in the form of a list return [size,blockNumber,gasUsed,transactionNumber,baseFeePerGas,timestamp] def add_data_to_sheet(_new_block): blockInfo = extract_block_details(_new_block) try: SHEET.append_row(blockInfo) except Exception as e: #if we encounter "write quota exceeded" error if e.args[0]['code'] == 429: #pause the execution for a minute sleep(60) #retry with same data add_data_to_sheet(_new_block) if __name__ == '__main__': loop = asyncio.get_event_loop() loop.run_until_complete(get_block_details()) loop.close() Note: Here’s the code repository for reference : EVM-Dashboard. The code in the repository has been modularised for ease of navigation. Now, all you need to do is to run the script, for that, open a terminal in the location of the script and type  $ python script.py  This will fetch the block, retrieve the block details, and add the details to our google sheets. If you open your google sheets, you can see the data getting added to it.  A bit of Google sheet magic  Now that we have the data in our spreadsheet, let’s try and create some charts and diagrams out of it.  Google sheets have some prebuilt features that we can leverage to build powerful charts. Since we have multiple columns of data, we can use each of these columns as a basis for our charts and hence create multiple charts out of our data.  To create a chart out of a column, all you need do is select the column, click on the insert option from the top menu and click on charts. This will generate a line chart out of our data by default.  The line chart shows the variation in block size. Once you have such a chart you can modify every aspect of it, including the size of the chart, its style, name and even its theme.  We can even add data to the horizontal axis of the chart and start trying to create inferences out of our data. In our case, we can add the timestamp as the value of our horizontal axis, and this will give us an idea regarding the block size during different time periods. To do that, all you have to do is to add the column details to the x-axis field. Since the timestamp data starts from column F (in our case), we can give it as the value for the x-axis field.  Once we add the data to the horizontal axis, we can identify points in the chart that give us information regarding the block size during a particular timestamp. Now, I know that the x-axis can seem a bit crowded, however, we can create a cleaner chart by aggregating the data. Aggregation is the process by which we can create high-level summaries of our data, by combining individual data points. Here, we can aggregate the data and see if we could generate the average block size during a particular period. Here is how you do it:  Now, the point in the chart shows the average block size during a particular time. You can further customize the chart and make it look even cooler.  Here, I have changed the color of the line, displayed the data labels, and added the x-axis title. You can do all these things by tinkering around with the edit chart option. Now that we know how to handle charts, we can use the same steps to create the charts out of all our data columns: Embedding the charts  Alright, now that we have our charts, let’s look into ways to present them on a platform (websites and such) of our liking. To present the charts to other websites, first, we need to publish them: Now, while publishing, make sure you have the “Automatically republish when changes are made” option enabled. As the name suggests, this option will update the charts automatically upon receiving new data and thus we will always be presenting the latest version of the charts. Now, once you publish, you can either use the link or the embed option to add the charts to a platform of your choice  Conclusion  The idea of this article was to show you how we can easily collect, process, and get insights out of web3-based data (or any other kind of data for that matter). The Google spreadsheet also allows the users to use more complex statistical formulas that can help derive more in-depth insights. We can connect our spreadsheet to tools like Google Data Studio, and generate more comprehensive reports of our data without the need for much code, but since we are trying to keep things simple, we will not be looking into those methods “for now.”  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to build a HIP-4 trading bot on Hyperliquid Hyperliquid’s HIP-4 brings outcome markets natively on-chain. Learn how HIP-4 works, walk through the API, set up your environment, and run a passive market-making bot on binary outcome markets. TL;DR HIP-4 is Hyperliquid’s native outcome market protocol, live on mainnet Hyperliquid’s native outcome market protocol, live on mainnet Settles in USDH, no leverage, no liquidations Binary and multi-price markets, automatically deployed and settled by the protocol The API runs on the same engine as spot and perps Same REST and WebSocket engine as spot and perps Read state via /info with outcomeMeta, write via /exchange Outcome asset IDs follow 20000 + outcome_index The bot quotes YES and NO tokens passively across multiple outcomes A passive market-making bot that quotes YES and NO tokens simultaneously Bot manages fair value, spread, inventory caps, and graceful shutdown Runs on Chainstack’s Hyperliquid node with a single endpoint for HyperCore and HyperEVM Hyperliquid HIP-4 is live 🤔 Prefer diving straight into the code? Get the HIP-4 bot by Chainstack HIP-4 is live on mainnet. We just detected the first HIP-4 transaction on Hyperliquid mainnet at 07:46 UTC.It begins. pic.twitter.com/AkRNkAeSbK— Hypedexer (@hypedexer) May 2, 2026 Hyperliquid integrated outcome markets directly into HyperCore that processes billions in daily spots and perpetuals volume. On day one, the initial BTC binary market generated 6.05 million contracts in the first 24 hours HYPERLIQUID HIP 4 CONTRACT SEES 6M DAY ONE VOLUMEHyperliquid’s HIP 4 event contract recorded 6.05 million contracts on its first day of trading.The launch captured about 0.7% of total prediction market share.The platform is directly competing with Polymarket and Kalshi and… pic.twitter.com/ijH0oohjbB— BSCN (@BSCNews) May 4, 2026 and a cumulative volume of 25.1M in a week since May 2. Source: https://www.artemis.ai/company/HYPE?tab=hip4 What is Hyperliquid HIP-4? HIP-4 (Hyperliquid Improvement Proposal 4) introduces outcome markets: non-linear, expiry-based contracts designed as an alternative derivative primitive without leverage or liquidations. For a deeper breakdown of all HIPs, read Hyperliquid HIPs Explained. Outcomes are single tradable contract that settle into predefined results at expiry instead of behaving like continuously margined perpetual positions. For eg: “BTC closes above $80,922 at 06:00 UTC May 14”. Each outcome is identified by a positive integer index. On mainnet, the first BTC daily binary outcome has index 5915. Recurring outcomes are markets automatically deployed and settled by the protocol on a fixed cadence, with the active market configuration stored in the description field of outcomeMeta. Binary outcome markets settle into one of two states: YES or NO. class:priceBinary|underlying:BTC|expiry:20260503-0600|targetPrice:78213|period:1d class:priceBinary : specifies a binary price outcome market underlying:BTC : uses BTC as the reference asset expiry:20260503-0600: settlement timestamp of the market targetPrice:78213 : strike price used for settlement period:1d : a new binary market is created every 1 day Settlement uses linear interpolation between the mark price updates immediately before and after expiry. The market settles to YES if the interpolated price is greater than or equal to the target price. Multi-price markets divide settlement into multiple price buckets. class:priceBucket|underlying:BTC|expiry:20260507-0745|priceThresholds:81538,81783|period:15m class:priceBucket → specifies a bucket-based outcome market underlying:BTC → BTC is the reference asset expiry:20260507-0745 → settlement timestamp priceThresholds:81538,81783 → defines three settlement buckets: <81538, [81538,81783), and ≥81783 period:15m → a new market instance launches every 15 minutes There are three price buckets depending on the target price at the time of settlement: < P1 [P1, P2) ≥ P2 Exactly one of the 3 outcomes settles to 1, and the others settle to 0. One such example is already live on testnet and on mainnet. Hyperliquid has stated additional features will be rolled out gradually in later stages. Outcome tokens are the tradable units representing each possible market result, and their prices are bounded between [0,1], where 0 represents an impossible outcome and 1 represents a guaranteed winning outcome at settlement. USDH is the quote and settlement denomination used for outcome markets, allowing outcome token prices ( probabilities ) to trade as decimal probabilities such as 0.001, 0.25, or 0.9999 depending on the outcome. For eg: The price tick on the BTC binary is 0.0001 Settlement is automatic. There is no claim, redeem, or settle call. At expiry, USDH credits land in the account in proportion to the side balances held, and the outcome is removed from the next outcomeMeta response. Hyperliquid HIP-4 API Before understanding how the bot works, it is important to understand how Hyperliquid exposes their APIs. 📖 All across Hyperliquid, whether spot, perps or outcomes, they run on the same engine accessible through the same HyperCore. It is recommended to read “Hyperliquid API for Developer” to understand the HIP-4 API smoothly. Info All on-chain state read from the chain flows through /info endpoint. The only thing that changes is the type field in the request. Pass outcomeMeta in type import requests url = "<https://api.hyperliquid.xyz/info>" payload = { "type": "outcomeMeta" } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) Returns all outcome markets with their asset IDs, question text, expiry timestamp, oracle type, and settlement status. To see it in action: list outcomes 📖 Find the full availability matrix for all hyperliquid methods and in detail explanation of each in API reference Exchange POST /exchange is the write layer. Every state-changing operation, placing orders, canceling, splitting, merging, flows here. All requests on /exchange endpoint requires an EIP-712 structured data signature from the wallet key for authentication and security purposes. The four outcome-specific exchange actions: ActionEffectsplitOutcomeBurns 1 USDH, mints 1 YES + 1 NO for a questionmergeOutcomeBurns 1 YES + 1 NO, returns 1 USDHnegateOutcomeConverts YES to NO (or NO to YES) for the same questionmergeQuestionSettles a categorical question at expiry The Hyperliquid Python SDK handles signing and payload encoding. The hl4/ library in the repo wraps the SDK specifically for outcome asset IDs and action types. WebSocket Hyperliquid’s WebSocket endpoint streams l2Book and trades updates for any asset including outcomes at: mainnet : wss://api.hyperliquid.xyz/ws testnet : wss://api.hyperliquid-testnet.xyz/ws See an easy implementation of subscribing to l2Book + trades for one side of an outcome over WebSocket Updates arrive as JSON frames with bid/ask depth changes. The bot uses this feed to track mid-price in real time without polling the REST endpoint on every tick. Use this reference to check all subscription types: WebSocket subscriptions docs Build the bot We will use: A Chainstack account: Create your account for free Python 3.11 or higher hyperliquid-python-sdk: Hyperliquid trading interface eth-account: Ethereum account signing python-dotenv: Load environment variables httpx: Async HTTP client websockets: WebSocket communication library rich: Rich terminal formatting and UIIt is a Python project built with uv and organized into three layers: hyperliquid-hip-4/ ├── hl4/ ← core client library (API calls, signing, types) ├── examples/ ← 13 standalone scripts, one per primitive operation ├── bot/ ← passive market-maker ├── .env.example ← environment variable template All scripts target testnet by default. Mainnet requires changing the base URL in the config. Create Chainstack Account Head to Console and create a free account This is where you can manage all your nodes across 70+ protocols Click on “Add node” Choose Hyperliquid and then select “Hyperliquid Testnet” in the network section below Click “Next” In the next step, select the type of node. For this project, choose “Global Node”. Give your node a name, review all the settings in the summary, and click “Deploy Node” Once the node is deployed, click “View Node Details”. Scroll down to the “Access and credentials” section. Here you will find the endpoint URL, copy it and keep it safe. It will be needed in the next step. Do not expose your URL. Store it securely in a .env file and add it to your .gitignore before pushing the code to GitHub. Consider using password-protected endpoints to enhance security. Environment Setup git clone <https://github.com/chainstacklabs/hyperliquid-hip-4> cd hyperliquid-hip-4 uv sync cp .env.example .env Fill in .env: HYPERLIQUID_TESTNET_PRIVATE_KEY=0x... TESTNET_WALLET_ADDRESS=0x... For your RPC endpoint, use Chainstack, deploy a Hyperliquid node and drop the HTTPS URL into your config. Chainstack’s Hyperliquid nodes expose both HyperEVM /evm and a subset of HyperCore /info queries on a single endpoint, which simplifies auth and latency tuning when running bots. Explore examples (optional) # list all outcome IDs with metadata uv run python examples/01_list_outcomes.py # list categorical questions (multi-leg markets) uv run python examples/02_list_questions.py For learning purposes, explore and run scripts like 01_list_outcomes.py to call outcomeMeta on /info endpoint. It returns each outcome’s ID, question text, expiry timestamp, and settlement oracle type. On testnet, you will see the BTC daily binary, a HYPE 15-minute binary, and several validator-deployed test markets. Move to next step to setup and run the bot. Get USDH (critical) HIP-4 settles in USDH. To get USDH, run script 00_get_usdh.pyThe standard testnet faucet pays USDC; handles the USDC → USDH swap. uv run python examples/00_get_usdh.py --amount 50 Then, check your USDC, USDH, and outcome token balances uv run python examples/03_account_state.py Run the bot The bot/ directory contains market_maker.py, a passive market-making loop designed for binary outcome markets. Here is what it does and how each parameter controls behavior. To run the bot: # market-make BTC daily and HYPE 15-min binaries simultaneously uv run python -m bot.market_maker --outcomes 5915,5969 \\ --quote-notional 12 --half-spread 0.04 --max-inventory 30 --tick 5 ParameterDescription--outcomesComma-separated outcome IDs to make markets on simultaneously--quote-notionalUSDH size of each resting order (bid and ask)--half-spreadOne-sided spread from mid-price, in USDH. A half-spread of 0.04 places bids at mid - 0.04 and asks at mid + 0.04--max-inventoryMaximum net position in USDH before the bot stops quoting the direction that would increase exposure--tickLoop interval in seconds How does the bot work? The bot/market_maker.py script runs a passive market-making strategy for HIP-4 binary outcome markets. Its job is to continuously place buy and sell quotes around the current market price while managing inventory risk automatically. import argparse import asyncio import signal import time from dataclasses import dataclass, field import httpx from hyperliquid.exchange import Exchange from hyperliquid.info import Info from rich.console import Console from hl4 import load_config from hl4.client import make_clients from hl4.outcomes import encode_balance_coin, encode_coin console = Console() import async runtime, HTTP client, exchange SDK, and CLI tools PRICE_MIN=0.001 PRICE_MAX=0.999 PRICE_TICK=0.001 define price bounds, defaults at 0.001 for safety smallest allowed price movement (tick size) def round_tick(px: float) -> float: return max(PRICE_MIN, min(PRICE_MAX, round(px, 3))) def fetch_book(base_url: str, coin: str) -> tuple[float | None, float | None]: r = httpx.post(f"{base_url}/info", json={"type": "l2Book", "coin": coin}, timeout=5.0) levels = r.json().get("levels", [[], []]) bid = float(levels[0][0]["px"]) if levels[0] else None ask = float(levels[1][0]["px"]) if levels[1] else None return bid, ask def fair_from_book(bid: float | None, ask: float | None) -> float | None: if bid is not None and ask is not None: return (bid + ask) / 2 if bid is not None: return min(PRICE_MAX, bid + PRICE_TICK) if ask is not None: return max(PRICE_MIN, ask - PRICE_TICK) return 0.5 def position_for(base_url: str, address: str, balance_coin: str) -> float: """Look up an outcome side balance. Note: outcome balances appear under the `+<encoding>` coin form, not the `#<encoding>` form used for trading.""" r = httpx.post( f"{base_url}/info", json={"type": "spotClearinghouseState", "user": address}, timeout=5.0, ) for b in r.json().get("balances", []): if b["coin"] == balance_coin: return float(b["total"]) return 0.0 round prices to valid ticks fetch order book data, calculate fair market prices or defaults to 0.5 and retrieve current YES/NO inventory balances The bot maintains 4 quote channels per outcome: YES bid / YES ask NO bid / NO ask @dataclass classSideState: coin:str is_buy:bool open_oid:int|None=None open_px:float|None=None open_sz:float|None=None SideState tracks the currently resting order classOutcomeMM: def__post_init__(self): forsidein (0,1): coin=encode_coin(self.outcome_id,side) self.sides[(side,True)]=SideState(coin,True) self.sides[(side,False)]=SideState(coin,False) This prebuilds the full two-sided quoting structure for each prediction-market outcome. def__post_init__(self): forsidein (0,1): coin=encode_coin(self.outcome_id,side) self.sides[(side,True)]=SideState(coin=coin,is_buy=True) self.sides[(side,False)]=SideState(coin=coin,is_buy=False) This builds full quoting structure: side = 0 → YES contract side = 1 → NO contract each side has: BUY order state SELL order state This gives the bot continuous two-sided liquidity on both contracts simultaneously. Once initialized, the bot enters a continuous quoting cycle: bid_px=round_tick(mid-half_spread) ask_px=round_tick(mid+half_spread) This creates a passive spread designed to earn edge from market flow while staying inventory-neutral over time. Troubleshooting Common errors and their fixes when running the HIP-4 bot for the first time. “Order must have minimum value of 10 USDH” The server enforces a $10 USDH minimum notional per order. At a price of 0.42, a size of 23 gives a notional of 9.66 USDH just under the floor. Use --quote-notional 12 or higher when starting the bot. Validate notional client-side before signing so the round-trip to the server is not wasted: “Order has invalid size” Outcome side coins use integer size precision. Fractional sizes like 10.5 are rejected at the server even when the price and notional are valid. Always round sizes up to the nearest integer before placing an order. The bot does this internally. If you are placing orders manually: Orders fill but the position does not appear in account state There are two coin string forms for the same side asset, and they are not interchangeable: FormUsed in#<encoding>/info l2Book, order placement, WebSocket+<encoding>spotClearinghouseState balances Querying balances with #59150 returns nothing. Querying l2Book with +59150 also returns nothing. Both fail silently with no error. Use encode_coin(outcome_id, side) for order placement and encode_balance_coin(outcome_id, side) for balance lookups. Both helpers are exported from hl4.outcomes. outcomeMeta returns empty or fails against the Chainstack endpoint outcomeMeta is only served by the official Hyperliquid public API. It is not part of the open-source node software, so it is not available on Chainstack-hosted endpoints. Point HIP-4 metadata and trading calls at the public API: “mainnet:https://api.hyperliquid.xyz testnet: https://api.hyperliquid-testnet.xyz Continue using your Chainstack endpoint for HyperEVM operations and the supported subset of /info static metadata methods. The full availability matrix is at Hyperliquid methods. USDH balance is zero HIP-4 settles and collateralizes in USDH, not USDC. The standard testnet faucet pays USDC. They are separate assets and the exchange layer does not substitute one for the other. Swap USDC to USDH using the @1338 spot pair (~1:1) before placing any outcome orders: uv run python examples/00_get_usdh.py --amount 50 Then confirm the balance before proceeding: uv run python examples/03_account_state.py The bot stops quoting one side Once the net position in USDH exceeds --max-inventory, the bot stops placing orders in the direction that would increase exposure. It continues quoting the opposite side. This is intentional — it is the inventory cap working as designed. To widen the cap, increase --max-inventory. To reset a position manually, use examples/09_close_position.py to flatten before restarting the bot. WebSocket feed goes silent mid-session HIP-4 markets can have low liquidity, especially on testnet. Periods of no activity produce no WebSocket events, the connection stays open but nothing is pushed. A network-level disconnection can look identical since the library does not always surface it immediately. The example scripts are minimal and do not include reconnect logic. In the bot, the REST fallback in fetch_book() covers this: if the WebSocket stalls, the --tick loop interval triggers a fresh REST snapshot instead. For production use, add a heartbeat or reconnect loop around the WebSocket connection. Settlement lands but the position lingers: waiting for a claim call HIP-4 settlement is automatic. There is no claim, redeem, or settle call. At expiry, USDH credits land in the account proportional to the side balances held, and the outcome is removed from the next outcomeMeta response. Waiting for a transaction to trigger settlement means waiting for something that will never come. To confirm settlement happened, check that your USDH balance increased and that the outcome ID is no longer listed in outcomeMeta. Use examples/12_wait_for_settlement.py to poll through expiry: uv run python examples/12_wait_for_settlement.py Price rejected near 0 or 1 Outcome prices are bounded to [0.001, 0.999]. Orders at 0.0, 1.0, or prices with too many decimal places are rejected. The price tick on the BTC binary is 0.0001. Always pass prices through round_tick() before submitting. The bot enforces PRICE_MIN = 0.001 and PRICE_MAX = 0.999, and fair_from_book() clamps the result automatically when one side of the book is empty. Hyperliquid builder tools The builder codes enable many perks and benefits for developers who choose to build on top of Hyperliquid. Outcome, a builder on HIP-4, generated 1M in trade volume: Next target : $50,000,000 https://t.co/gXVwK3DQkz pic.twitter.com/MLJET2DWFy— Outcome (@Outcomexyz) May 11, 2026 The HIP-4 ecosystem is moving fast. Outcome markets went live on May 2, 2026, and builders are already shipping on top of it. Here is everything you need to go further, from code and frontends to docs and data. Code chainstacklabs/hyperliquid-hip-4: The reference implementation from this guide, with 13 standalone example scripts and the full market-making bot. Hyperliquid Python SDK: Core SDK for order placement, signing, and account management across spot, perps, and outcomes. Frontends and Builders Outcomexyz: The first official HIP-4 builder, live with BTC daily binary markets. trade.xyz: The leading HIP-3 builder for tokenized stocks and commodities, a reference point for what builders can ship on Hyperliquid primitives. Analytics and Data Artemis HIP-4: Protocol-level analytics for HIP-4 volume, traders, and market activity. Allium HIP-4 Deep Dive: On-chain data terminal with a dedicated HIP-4 breakdown. Core Documentation HIP-4 Outcome Markets: Full protocol specification. Contract Specifications: Recurring outcome structure, binary and multi-price mechanics. Fee Schedule: Outcome token fee structure and settlement details. Asset IDs: Schema for deriving outcome asset IDs. Exchange Endpoint: Reference for splitOutcome, mergeOutcome, negateOutcome, and mergeQuestion. WebSocket Subscriptions: Real-time l2Book and trades feeds for outcome assets. Chainstack Hyperliquid RPC: Deploy a Hyperliquid node with a single endpoint for HyperCore and HyperEVM. HIP-4 Trading Guide: Step-by-step guide for trading outcome markets via Chainstack. Hyperliquid API Reference: Full method availability matrix and in-depth endpoint documentation. Community Hyperliquid Discord #api-traders: The go-to channel for builder questions, API discussions, and ecosystem updates. Conclusion HIP-4 brings a new class of derivative to Hyperliquid, one that settles automatically, runs on the same engine as spot and perps, and requires no leverage or liquidations. For builders, that means a clean surface to build on. Outcome markets expose the same REST and WebSocket APIs, use the same signing flow, and sit inside the same liquidity environment that already processes billions in daily volume. The bot in this guide is a starting point. It covers the core loop: fetching fair value from the order book, placing resting quotes on both YES and NO sides, managing inventory caps, and cleaning up on shutdown. From here, you can extend it with dynamic spread skewing based on inventory, multi-outcome correlation logic, or signal layers that adjust quotes around known settlement windows. To get started, deploy a Hyperliquid node on Chainstack, clone the repo, and run the bot on testnet first. Chainstack’s Hyperliquid nodes give you a reliable, low-latency endpoint with access to both HyperCore and HyperEVM on a single URL, which keeps the setup straightforward as you move from exploration to production. With Chainstack Hyperliquid nodes, you get a single low-latency endpoint for both HyperCore and HyperEVM, making it easier to manage market data, order execution, and on-chain interactions without stitching together multiple providers. Whether you’re experimenting with passive market making on testnet or deploying production trading systems, Chainstack gives you reliable RPC performance, predictable connectivity, and fast global access for latency-sensitive bots. Deploy a Hyperliquid node via Chainstack Console → FAQ What is HIP-4 on Hyperliquid? HIP-4 (Hyperliquid Improvement Proposal 4) introduces outcome markets — expiry-based contracts that settle into predefined results like YES or NO. Unlike perpetuals, they have no leverage, no liquidations, and settle automatically in USDH at expiry. How does settlement work in HIP-4? Settlement is fully automatic. At expiry, USDH credits land in your account proportional to the side balances you hold. There is no claim, redeem, or settle transaction to submit. The settled outcome disappears from the next outcomeMeta response. What is USDH and why does HIP-4 use it instead of USDC? USDH is Hyperliquid’s native stablecoin used as the quote and settlement currency for outcome markets. The testnet faucet pays USDC — they are separate assets. Swap USDC to USDH via the @1338 spot pair before placing any outcome orders. Does outcomeMeta work on a Chainstack Hyperliquid endpoint? No. outcomeMeta is served only by the official Hyperliquid public API and is not part of the open-source node software. Point HIP-4 metadata and trading calls at https://api.hyperliquid.xyz (mainnet) or https://api.hyperliquid-testnet.xyz (testnet). Use your Chainstack endpoint for HyperEVM operations and supported /info methods. What is the difference between splitOutcome, mergeOutcome, and negateOutcome? splitOutcome burns 1 USDH and mints 1 YES + 1 NO token for a question. mergeOutcome does the reverse — burns 1 YES + 1 NO and returns 1 USDH. negateOutcome converts a YES token to NO (or NO to YES) for the same question without touching USDH. How are outcome asset IDs derived? Outcome asset IDs follow the schema 20000 + outcome_index. The first BTC daily binary on mainnet has index 5915, giving asset ID 25915. Use encode_coin(outcome_id, side) for order placement and encode_balance_coin(outcome_id, side) for balance lookups — the two forms are not interchangeable. Can I run the bot on mainnet straight away? The bot and all example scripts target testnet by default. To switch to mainnet, change the base URL in your config to https://api.hyperliquid.xyz and fund your wallet with real USDH. Run on testnet first — use examples/00_get_usdh.py to get testnet USDH from the faucet and verify your setup before moving to mainnet. What are the minimum order requirements for HIP-4? Each order must have a minimum notional of 10 USDH. Order sizes must be integers — fractional sizes are rejected. Prices are bounded to [0.001, 0.999] with a tick size of 0.0001 on the BTC binary. Always pass prices through round_tick() before submitting. Related reading Hyperliquid + HIPs Hyperliquid HIPs Explained Hyperliquid API Guide: Endpoints, SDK, WebSocket HIP-4 Outcome Markets Trading Guide Hyperliquid Methods Infrastructure + RPC Hyperliquid RPC on Chainstack Deploy a Hyperliquid Node Blockchain API Reference #### How to build a Hyperliquid on-chain activity tracker This guide shows how to build a Hyperliquid on-chain activity tracker using Chainstack to monitor large trading activity and send real-time Telegram alerts. The process covers fetching trading data through Chainstack Hyperliquid RPC, monitoring large movements across any address to detect high-leverage activity, and building a Telegram bot that automatically sends a ping the moment any significant event is detected. Prefer diving straight into the code? Get the Hyper Tracker bot on author’s GitHub start getting automated pings instantly. Prerequisite To track trading data and run a bot, you must have the following before you begin: Node.js 17+, If not installed → Node.js Download A Telegram account Basic understanding of JavaScript Familiarity with common DeFi terminologies ✅ Verify Node.js version by running node -v in your terminal. If it’s below 17, update it and confirm the new version. What is Hyperliquid? Hyperliquid is a Layer 1 blockchain designed for derivatives trading that allows users to trade perpetual contracts (perps) with leverage. It runs on HyperBFT, a custom consensus algorithm that delivers full decentralization and on-chain transparency while providing execution speeds similar to a centralized exchange. Users can hold multiple positions across assets like BTC, ETH, and SOL using cross or isolated margin with a transparent on-chain order book. Since all trading activity is publicly visible, anyone can inspect positions, leverage, balances, and overall market behavior. Hyperliquid is straightforward to build on using Chainstack. Its RPC layer exposes clean, well-structured endpoints for fetching user states, position data, and order book details, making it easy to build monitoring tools, analytics dashboards, or automated systems on top of the protocol. → Learn more about Hyperliquid in our deep dive Why track high on-chain activity on Hyperliquid? Monitoring large movements in real time gives a strategic advantage by providing insights into market behavior and potential price action. Analyzing the activities of large holders, also known as whales, can reveal shifts in trends and highlight opportunities for profitable trades. If you’re a trader, builder, quant, or enjoy following whale wallets, real-time raw on-chain activity becomes actionable signals. For this project, “high activity” refers to meaningful position changes on Hyperliquid like: A new position opens Leverage increase/decrease in a position A position becomes profitable or close to liquidation Build the Hyperliquid on-chain activity tracker We will use: A Chainstack account → Create your account for free Node.js Yarn or npm Axios Dotenv Telegram account Botfather VS Code or your choice of code editor Set up Hyperliquid RPC on Chainstack Head to Console and create a free account This is where you can manage all your nodes across 70+ protocols Click on “Add node” Choose Hyperliquid and then select “Hyperliquid Mainnet” in the network section below Click “Next” In the next step, select the type of node. For this project, choose “Global Node” Give your node a name, review all the settings in the summary, and click “Deploy Node” Once the node is deployed, click “View Node Details”. Scroll down to the “Access and credentials” section. Here you will find the endpoint URL, copy it and keep it safe. It will be needed in the next step. ⚠️ Do not expose your URL. Store it securely in a .env file and add it to your .gitignore before pushing the code to GitHub. Consider using password-protected endpoints to enhance security. Set up your Telegram bot and broadcast channel Before sending automated alerts, you’ll need two things in place: a dedicated Telegram bot and a channel where those alerts will be published. Create your bot via BotFather Open Telegram and search for BotFather, the official tool for creating and managing bots Start a conversation and run the command /newbot BotFather will guide you through choosing your bot’s display name and unique username After the setup, you will receive a Bot Token. Store this token securely, it will later go into your .env file as the TELEGRAM_BOT_TOKEN Set up a Telegram channel Create a new channel in Telegram, either public or private If you choose a public channel, assign it a clear and memorable handle (for example: @hypertracker) This handle or channel ID will serve as your TELEGRAM_CHANNEL_ID Connect the Hyperliquid on-chain activity bot to your channel Open the channel’s settings or admin panel Add your bot as a member Promote it to an administrator so it can post messages automatically After completing these steps, you will have both the TELEGRAM_BOT_TOKEN and the TELEGRAM_CHANNEL_ID needed to send alerts programmatically. Set up the environment Create a new project folder mkdir hypertracker cd hypertracker npm init -y Install dependencies npm install axios dotenv Create an .env file with the following keys CHAINSTACK_URL=<Your-Chainstack-Endpoint-URL> BOT_TOKEN=<Your-Telegram-Bot-Token> CHAT_ID=<Your-Telegram-Channel-or-Supergroup-ID> USERS=<Whale-Wallet-1,Whale-Wallet-2> COIN=<Crypto-Holding-Symbol> POLL_INTERVAL_MS=<Polling-Interval-in-Milliseconds> CHAINSTACK_URL: The RPC endpoint URL obtained from Chainstack when the Hyperliquid node was deployed BOT_TOKEN: The token generated by BotFather for your Telegram bot CHAT_ID: The unique identifier for the Telegram channel or supergroup where the bot will send alerts. Supergroup IDs usually start with -100…. USERS: A comma-separated list of whale wallet addresses to track. COIN: The symbol of the cryptocurrency to track (e.g., BTC, ETH, SOL) POLL_INTERVAL_MS: The interval in milliseconds at which the bot fetches new data from Chainstack. For example, 5000 will make the bot check for updates every 5 seconds. Monitor on-chain positions and activity Create a file named activity.js. This script monitors a user’s open positions on Hyperliquid Perps using a Chainstack RPC endpoint. If a user opens, updates, or closes a position, it returns a structured update that can be forwarded to a Telegram bot. Import Required Libraries import axios from "axios";import { CONFIG } from "./config.js"; Track Last Known State const lastState = {}; Each tracked user gets an entry like lastState[user] = { size: <number>, entry: <number>} This allows the script to detect: new positions size changes position closed Create Hyperliquid RPC Caller async function hyperInfo(payload) { const url = `${CONFIG.CHAINSTACK_URL}/info`; try { const { data } = await axios.post(url, payload, { headers: { "Content-Type": "application/json" }, }); return data; } catch (err) { console.error(err.message); throw err; } } hyperInfo is a helper function that: Builds a URL ending in /info, Sends a POST request with a JSON payload Returns parsed JSON directly (data) Throws an error if the RPC fails Fetch All Account State export async function getAccountState(userAddress) { const user = userAddress.toLowerCase(); const coin = CONFIG.COIN.toUpperCase(); const active = await hyperInfo({ type: "activeAssetData", user, coin, }); const clearing = await hyperInfo({ type: "clearinghouseState", user, }); return { active, clearing }; } For this project, we’re looking at whale traders who dominate the spotlight with massive positions and attention-grabbing liquidations, including: James Wynn: 0x5078c2fbea2b2ad61bc840bc023e35fce56bedb6 Andrew Tate: 0xB78D97390a96A17Fd2B58FeDBEB3DD876c8F660A Machi Big Brother: 0x020ca66c30bec2c4fe3861a94e4db4a498a35872 The getAccountState functions fetches information related to these whales by: Converting wallet address → lowercase Converts coin symbol → uppercase Fetches both: active positions clearinghouse state Returns both together in one object: { active: <activeAssetData>, clearing: <clearinghouseState> } This becomes the raw input for activity detection. Detect Position Activity export function detectActivity(user, clearing) { const assetPositions = clearing.assetPositions || []; const pos = assetPositions.length > 0 ? assetPositions[0].position : null; if (!pos) { if (lastState[user]?.size && lastState[user].size > 0) { lastState[user] = { size: 0, entry: 0 }; return { type: "POSITION_CLOSED", msg: `User ${user} closed all positions.`, }; } lastState[user] = { size: 0, entry: 0 }; return null; } const size = Number(pos.szi || 0); const entry = Number(pos.entryPx || 0); const leverage = Number(pos.leverage?.value || 0); const unrealizedPnl = Number(pos.unrealizedPnl || 0); const liquidationPx = pos.liquidationPx ? Number(pos.liquidationPx).toFixed(2) : "0.00"; if (!lastState[user] || lastState[user].size === 0) { lastState[user] = { size, entry }; return { type: "ORDER_ACTIVITY", sizeBefore: 0, sizeAfter: size, entry, msg: `User ${user} has an opened a position. nSize: ${size}${size} nEntry: $${entry} nLeverage: ${leverage}x nPnL: $${unrealizedPnl} nLiquidation Price: $${liquidationPx} `, }; } const prev = lastState[user]; if (size !== prev.size) { lastState[user] = { size, entry }; return { type: "ORDER_ACTIVITY", sizeBefore: prev.size, sizeAfter: size, entry, msg: `Order activity:nUser: ${user}nOld Size: ${prev.size}nNew Size: ${size}`, }; } console.log("No change detected."); return null; } detectActivity triggers when: user closed their position user opens a new position and then extract: position size entry price of position leverage value Unrealized Profit/loss in USD Liquidation Price detects a change in size of position no activity logs Telegram Hyperliquid on-chain activity tracker utility Create a file named bot.js. This script handles all communication between your trading monitor and your Telegram bot. It uses your bot token to send pings in real-time such as position opened, position updated, or position closed. import axios from "axios"; import { CONFIG } from "./config.js"; const TELEGRAM_API_URL = `https://api.telegram.org/bot${CONFIG.BOT_TOKEN}/`; const CHAT_ID = CONFIG.CHAT_ID; export async function sendMessage(chatId, text) { try { const { data } = await axios.post(`${TELEGRAM_API_URL}sendMessage`, { chat_id: chatId, text, parse_mode: "Markdown", }); return data; } catch (err) { console.error(err.message); return null; } } export async function sendAlert(text) { const res = await sendMessage(CHAT_ID, text); if (!res?.ok) { console.error(res); } } sendMessage endpoint sends the message to the chatId sendAlert for sending bot alerts. This is the function you call from your monitoring script whenever: a whale opens a position a trader updates their size leverage changes a position is closed Get real-time Hyperliquid tracker alerts Run the monitoring script: node index.js Watch Alerts in Telegram: Open Telegram and check your bot or channel. You’re live Your bot is now online, tracking whales automatically and sending real-time notifications straight to your phone. Considerations Security Keep your credentials private at all times. Your Chainstack endpoint, Telegram bot token, and chat ID should only live in a .env file. Make sure this file is ignored by Git so it never ends up in a public repository. Poll Settings and RPC Use Polling too frequently can cause unnecessary strain or hit RPC limits. Choose a polling interval that balances speed and stability. If you plan to track many wallets at once, consider spacing out requests or adding caching. Scaling the Bot If you expand the bot to monitor multiple traders, coins, or different types of activity, you might want to reorganize your code so everything stays efficient. Using queues, timers, or lightweight backend frameworks can help when scaling. RPC Issues Network issues and RPC hiccups are normal when dealing with blockchain data. Good error logs make it much easier to understand what went wrong and to keep the bot stable over long periods of time use reliable services (e.g., Chainstack) to ensure faster and more consistent updates. Future Upgrades You can always add more features later such as tracking funding rates, liquidation warnings, order book snapshots, or grouping alerts into cleaner messages. You could even connect dashboards or build your own analytics layer on top of this foundation. Summary This guide walks through how to build a simple but powerful real time Hyperliquid on-chain activity tracker using Node.js, Chainstack, and a Telegram bot. You learned how Hyperliquid exposes transparent on chain trading data and how to read that data through a Chainstack Hyperliquid RPC endpoint so you can follow whale movements as they happen. The tutorial covered setting up your development environment, deploying a Hyperliquid node, creating a Telegram bot with BotFather, and storing your credentials safely. From there you built the core script that keeps track of a wallet’s open positions, watches for changes, and sends alerts whenever something meaningful happens. That includes new positions, updates in size or leverage, or full position closures. Once the bot is running, you have a lightweight tool that delivers useful trading signals straight to your Telegram channel. It is especially helpful for traders who want to stay close to market shifts or for builders experimenting with on-chain data. With the setup in place, you can expand the bot to support more wallets, more coins, or additional functionalities like a trading bot using /exchange endpoint and eventually shape it into a full monitoring system for your own research or trading workflow. #### How to build a Hyperliquid trading bot If you’re building a bot, you need two things: reliable infra and a trading loop. We’ll cover both: from choosing the right Hyperliquid node to wiring a trading bot repo and testing strategies safely on the Hyperliquid blockchain. Bots drive a big share of flow on Hyperliquid. With native order books, sub-second confirms, and an API surface that works well with JSON-RPC and WebSockets, it’s a natural choice for automation. But speed on paper doesn’t guarantee your bot keeps up in practice. Your loop depends on three choices: the RPC node you connect to, how you consume WebSocket feeds, and how you budget requests under rate limits. Those constraints come from Hyperliquid’s architecture itself, a unified chain with two execution layers (HyperCore for trading and HyperEVM for smart contracts), each exposing different RPC and API capabilities. This guide walks those decisions and links to a minimal repo you can clone, configure, and use as a baseline Hyperliquid trading bot. Why build a Hyperliquid trading bot? Hyperliquid puts its order book on-chain. You can query state, stream updates, and submit orders through public endpoints. For builders, that means you can observe the same feed your logic depends on and validate each step in the loop. Perpetuals trade at scale here, so you will feel real contention for block space and see whether your loop keeps up under pressure. If your goal is to react to live order flow, a Hyperliquid bot is a direct way to test and operate those strategies with feedback on a decentralized exchange. What you need for a Hyperliquid trading bot Before you wire anything, have these ready: A Hyperliquid RPC endpoint. You’ll need HTTPS and WSS URLs to read the book and send orders. (Create a Hyperliquid node if you don’t have one yet) Hyperliquid testnet account with testnet funds (claim through the Chainstack Hyperliquid faucet and Hyperliquid DEX faucet for USDC https://app.hyperliquid-testnet.xyz/drip) uv package manager Your testnet API key Choosing the right Hyperliquid RPC node You can self-host a Hyperliquid RPC node. That gives you full control, but it also means owning the ops work: provisioning servers, monitoring uptime, scaling with demand, and keeping up with updates. For many builders — especially if you’re running trading bots that can’t afford downtime — those resources are better spent on the strategy. That’s why most teams turn to providers. With Chainstack, you get two options: Global Nodes — shared, elastic capacity. Good for getting started, testing on testnet, or running lighter strategies that don’t push request-per-second limits. You can also set Access rules (IP or Origin allowlists) for extra control. Dedicated Nodes — single-tenant capacity with predictable latency under load and higher request ceilings. Suited for high-performance like production bots, continuous operation, or bursty strategies. Archive is available if you need deeper historical reads. Once you’ve picked what fits your loop, creating a Hyperliquid node in the console is simple: In the Chainstack console, open your project and click Add node. Choose Global Nodes or Dedicated Nodes, then pick mainnet or testnet. Deploy the node. Copy the HTTPS and WSS RPC URLs into your bot config. Create Hyperliquid node Set up your environment Instead of setting up everything yourself, we’ve open-sourced a Hyperliquid trading bot you can use as a reference. Inside you’ll find: A working grid trading bot wired for Hyperliquid testnet. Configs (like a conservative BTC grid) you can adjust to your own parameters. Environment examples to drop in your testnet key and toggle testnet mode. Learning scripts for market data, orders, and realtime WebSockets. Clone the repo, install with uv, and explore it. From there, you can validate, run the default config, or start cutting your own. Take five minutes to watch the setup video below to see how the pieces fit together. How a Hyperliquid trading bot works Please note that the bot is in active development and its state may be slightly different. A trading bot is a loop. It keeps local state, reacts to feeds, and reconciles with chain state on every tick. Ingest live data — Open a price stream over WebSockets. Keep a small cache: best bid/ask, mid, recent trades. Pull account state when needed for balance, positions, and open orders. Plan the next tick — Read your YAML config. For a grid, derive the band and levels from current price. Build the target set of orders. Act — Submit signed limit orders via the Hyperliquid exchange API. Include a client identifier if supported so you can track, amend, or cancel. Log intent with timestamps. Observe — Watch acks and order updates from the stream. Track partial fills and status changes. Note gaps or drops in the feed. Reconcile — Compare intended orders to the current open orders from the API. If price exits the band, cancel and rebuild the grid. If an ack is missing, query status and resolve before proceeding. Recover — Handle disconnects with backoff. On reconnect, replay state by querying open orders and positions, then resume from the reconciled view. Persist and measure — Write compact logs for decisions, acks, rejects, and reconnects. These logs drive tuning and the evidence you will show later. Wrapping up You now have a baseline loop to test against Hyperliquid. The repo covers the bot, configs, and learning scripts, extend it to other DEXes and strategies as you go. Hyperliquid trading bot on GitHub Create a Hyperliquid node on Chainstack Claim test tokens through Chainstack Hyperliquid faucet Check out the Hyperliquid API method availability table, which lists 100+ methods with live support status per endpoint. Archive nodes and WebSockets are now live on Hyperliquid HyperEVM mainnet — use them for historical queries and realtime streams. Check out the Hyperliquid API reference. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is a Hyperliquid RPC node? An endpoint that exposes Hyperliquid’s HyperEVM over JSON-RPC and HyperCore. You use it to query state, stream data, and send signed orders. Please note that some API methods are supported by public nodes only. Where do I get Hyperliquid testnet funds? Use the Chainstack Hyperliquid faucet to fund your testnet account before running a trading bot and Hyperliquid DEX faucet for USDC (https://app.hyperliquid-testnet.xyz/drip). How do I get HTTPS and WebSockets RPC endpoints for the Hyperliquid blockchain? Spin up a Hyperliquid node in the Chainstack console. Once the node status is “running,” open Access & credentials to copy an info endpoint. How do I connect a trading bot to Hyperliquid RPC? Run a Hyperliquid Global or Dedicated Node on Chainstack. Grab the info endpoint and drop them into your environment variables, that’s how it pulls order book data and pushes transactions. Please note that some API methods are supported by public nodes only. Can I integrate smart contracts with Hyperliquid RPC? Yes, you can. Since Hyperliquid keeps the order book on-chain, a smart contract can watch state through RPC and trigger trading logic when conditions hit. #### How to build a Kuru copy trading bot Copy trading drives a significant share of trading volume on decentralized exchanges. On Kuru DEX, built on Monad’s high-throughput blockchain, bots can automatically mirror successful traders’ orders in real-time through transparent on-chain order books. This guide shows you how to build a copy trading bot that monitors source wallets and replicates their limit orders on Kuru DEX using Chainstack infrastructure. The video below covers the same steps outlined in this article, presented as a practical walkthrough. Why Build a Kuru Copy Trading Bot? Kuru operates as a decentralized token exchange on Monad, combining speed with full on-chain transparency. Copy trading bots on Kuru benefit from: On-chain order books: Every order is visible and verifiable on the blockchain Event-driven architecture: WebSocket subscriptions detect orders as they’re placed Limit order precision: Mirror sophisticated strategies with exact price and size control Automated copy trading eliminates manual intervention while giving you full control over position sizing and risk parameters. What You Need for a Kuru Copy Trading Bot Before you start, gather these essentials: RPC Endpoints: HTTPS and WSS URLs to monitor events and submit orders to the Monad blockchain Monad Wallet: A funded wallet with testnet MON tokens for gas fees (Monad faucet) Python Environment: Python 3.10+ and the uv package manager Kuru Account: Funded Kuru trading account for executing orders Source Wallets: Addresses of traders you want to copy The most critical component is your RPC node connection. Public Monad endpoints work for initial testing, but copy trading demands consistent WebSocket stability and low-latency order submission. Choosing the Right Monad RPC Node Chainstack offers two deployment models for Monad nodes: Global Nodes Shared infrastructure suits teams starting out or running lighter workloads. Global nodes provide: Usage-based pricing with no upfront costs WebSocket support for event subscriptions Access controls like API key authentication Suitable for development and testing Global nodes share resources across users, which can introduce variable latency during network congestion. Dedicated Nodes Single-tenant infrastructure delivers predictable performance for continuous trading operations. Dedicated nodes offer: No rate limits on requests or WebSocket subscriptions Consistent low latency even during market volatility Higher request ceilings for burst activity Fixed monthly pricing for cost predictability Dedicated infrastructure provides consistent performance without the resource contention of shared endpoints. Deploy a Monad node on Chainstack in minutes and retrieve your HTTPS and WSS endpoints from the access credentials panel. Set Up Your Environment Clone the open-source Kuru copy trading bot repository: git clone https://github.com/chainstacklabs/kuru-copy-trading-bot.git cd kuru-copy-trading-bot Install dependencies with uv: pip install uv uv sync Configure your .env file with Chainstack endpoints and trading parameters: MONAD_RPC_URL=https://your-chainstack-node.com MONAD_WS_URL=wss://your-chainstack-node.com BOT_PRIVATE_KEY=0xYourPrivateKeyHere SOURCE_WALLETS=0xTraderAddress1,0xTraderAddress2 MARKETS=0xMarketContract1,0xMarketContract2 COPY_RATIO=1.0 MIN_ORDER_SIZE_USD=10 MAX_POSITION_SIZE_USD=1000 DRY_RUN=false Fund your Kuru trading account: uv run python scripts/deposit_margin.py --amount 1000 Launch the bot: uv run python main.py The bot connects to your Chainstack node’s WebSocket endpoint and begins monitoring configured markets for source wallet activity. How a Kuru Copy Trading Bot Works The bot monitors blockchain events through your Chainstack node’s WebSocket connection and replicates orders from configured source wallets. Event Monitoring: The bot subscribes to Kuru market contract events including order creation, trade execution, and order cancellations. When a monitored wallet places an order, the bot detects it through the WebSocket stream. Risk Management: Built-in validation checks each detected order against configurable parameters like minimum balance thresholds, order size limits, and total exposure caps. Orders that fail validation are rejected and logged. Position Sizing: The copy ratio setting controls order size relative to the source trader. You can copy at 50%, 100%, 200%, or any percentage of their order size. The bot enforces minimum and maximum size constraints and adjusts for available account balance. Order Execution: Validated orders are submitted to Kuru DEX as limit orders matching the source trader’s price and direction. The bot maintains internal tracking to map source orders to your mirrored orders. Cancellation Synchronization: When source wallets cancel orders, the bot automatically cancels the corresponding mirrored orders to keep your positions aligned. Wrapping Up This open-source bot demonstrates copy trading implementation on Kuru DEX using Monad blockchain infrastructure. The repository includes event monitoring, risk validation, and order execution capabilities. Reliable RPC infrastructure is essential for WebSocket stability and transaction submission. Chainstack provides Monad nodes with both shared and dedicated deployment options. Resources Kuru Copy Trading Bot Repository Chainstack Documentation Deploy a Monad Node Monad Documentation Monad Testnet Faucet FAQ 1. What does a Monad RPC node provide for copy trading? Your Chainstack Monad node exposes reliable JSON-RPC methods for blockchain interaction and WebSocket endpoints for real-time event subscriptions. The bot uses WebSockets to monitor Kuru market events and HTTPS for submitting order transactions. 2. How do I get testnet funds for testing? Get testnet MON from the Monad faucet for gas fees. For Kuru trading account deposits, you’ll need testnet tokens compatible with Kuru markets. 3. What’s the difference between Global and Dedicated nodes for this bot? Chainstack low-latency Global nodes share resources across users. Dedicated nodes provide consistent high performance with no rate limits on WebSocket subscriptions or RPC requests. 4. Can I copy multiple traders simultaneously? Yes. Add multiple addresses to SOURCE_WALLETS separated by commas. The bot monitors all configured wallets and applies your risk limits to aggregate exposure across all copied trades. 5. How do I avoid copying bad trades? Use the risk management parameters: set MIN_ORDER_SIZE_USD to filter noise, cap MAX_POSITION_SIZE_USD to limit downside, and configure MAX_TOTAL_EXPOSURE_USD for portfolio-level risk control. Market whitelisting lets you restrict trading to tokens you understand. Explore the open-source repository to see the implementation. Chainstack Monad nodes provide the RPC infrastructure for blockchain connectivity. #### How to build a Polymarket bot using Polygon RPC TL;DR Prediction markets are rapidly growing as a new frontier for information aggregation, and Polymarket leads this space on Polygon. This guide shows how to build a Polymarket bot using Polymarket SDKs and raw RPC calls, combining Polygon RPC infrastructure with LLM-powered reasoning to detect correlated markets and construct hedge portfolios. You’ll learn how the bot works, how to deploy it locally, and why reliable RPC infrastructure is essential for production-grade prediction market automation. Why build a Polymarket Bot? Polymarket operates as a decentralized prediction market, combining speed with full on-chain transparency. Unlike traditional prediction markets, Polymarket tokenizes outcomes as binary ERC-1155 assets through Gnosis’s Conditional Token Framework (CTF), creating opportunities for sophisticated trading strategies. AI-powered prediction market bots benefit from: Correlated market detection: LLMs identify logical relationships between seemingly unrelated markets, uncovering hedge opportunities invisible to manual analysis On-chain transparency: Every position and outcome is verifiable on the blockchain through positionIds and collectionIds Event-driven architecture: Real-time market monitoring and automated portfolio construction Reasoning-powered hedging: LLMs close the reasoning layer—determining “what follows from A relative to B”—while the engine converts these insights into hedge candidates with probabilistic coverage This approach goes beyond simple copy trading, enabling discovery of alpha through logical market relationships that would be impractical to identify manually. What is Alphapoly? Alphapoly (chainstacklabs/polymarket-alpha-bot) is an open-source platform for finding “alpha” in correlated prediction markets. It detects dependencies between markets, classifies them to find hedge pairs, monitors prices, and provides a UI for quickly entering discovered opportunities while tracking open positions. The system operates through a four-stage pipeline: Groups: Collecting multi-outcome market groups (e.g., “Presidential Election Winner”) Implications: LLM extracts logical relationships between market groups Portfolios: Selecting position pairs that mutually hedge risk with high probability coverage Positions: Tracking and monitoring purchased pairs The UI is designed for “bot operators”—the dashboard displays strategies like a trading terminal, with Target bet and Backup bet in one row, along with LLM confidence, cost, and expected return. Live prices and pipeline toggles provide real-time control. ⚠️ Important: The project is provided “as is” for educational and research purposes and does not constitute financial advice. Trading prediction markets carries risk of loss. Why RPC and LLM are essential The Blockchain layer: Why you need Polygon RPC Polymarket isn’t just a “feed of odds”—at the protocol level, outcomes are tokenized on Polygon. YES/NO shares are implemented as ERC-1155 tokens and issued through Gnosis’s Conditional Token Framework. In documentation terminology, these are positionIds/collectionIds. This means any stable bot functions—checking positions, reading logs/events, monitoring balances, and especially sending transactions—require access to Polygon JSON-RPC. A few practical details critical for bots: Polymarket settles in USDC.e (bridged USDC) Polygon for Polymarket means chain ID 137—all libraries and web3 clients must point to the correct RPC A “public RPC on luck” works for one-off checks but breaks down with 24/7 polling, log scanning, and automation. Public endpoints face rate limits, 429 errors, and unstable latency under shared load. What RPC provides in practice: Your Polygon RPC URL is the entry point for JSON-RPC methods—eth_call, eth_getLogs, eth_sendRawTransaction. This isn’t a “web3 detail”—it’s the transport layer. Without it, your bot is either blind or unable to execute. The Intelligence layer: Why you need an LLM LLM in this architecture isn’t decorative. Alphapoly uses it to extract logical connections between market groups and construct covering pairs (hedge pairs), not just sort by price. The LLM closes the reasoning part: “what follows from A relative to B.” The engine then converts this into hedge candidates with probabilistic coverage. This separation is reflected in the dual model strategy: IMPLICATIONS_MODEL: Extracts relationships between market groups VALIDATION_MODEL: Validates the extracted implications This division is pragmatic for production: use an “expensive and powerful” model where errors cost more, and a lighter model for draft passes. It helps manage both systematic errors and cost/quality tradeoffs. What you need to run a Polymarket bot Before you start, gather these essentials: RPC Endpoints: HTTPS URL to monitor events and submit orders to the Polygon blockchain LLM Access: OpenRouter API key for accessing language models Polymarket CLOB Access: Polymarket uses Cloudflare protection that blocks requests from certain IPs, ensuring that the bot runs under allowed IPs  Python Environment: Python 3.12+ and the uv package manager Node.js: Node.js 18+ for the frontend Polymarket Account: Optional for on-chain execution (the bot works as a detector/tracker without this) Choosing the right Polygon RPC node Chainstack offers two deployment models for Polygon nodes, each suited to different operational needs: Global Nodes (Elastic) Global Node is Chainstack’s implementation of the elastic approach as a globally load-balanced service. Requests route to the nearest available location, reducing latency, and the balancer can switch backends if a node degrades (e.g., falls behind in block height). Key characteristics: Usage-based pricing with no upfront costs WebSocket support for event subscriptions Deploys in seconds (Chainstack documentation states “ready in seconds”) Ideal for local development, demos, and MVPs where you want stable RPC without manual failover Trade-off: Shared infrastructure can introduce variable latency during network congestion. Dedicated Nodes Dedicated Node is an exclusive node deployed for a single client. Computational resources aren’t shared, and configuration can be adapted to specific scenarios. Key characteristics: No rate limits on requests or WebSocket subscriptions Consistent low latency even during market volatility Debug/trace APIs enabled (where protocol supports), useful for debugging transaction failures Fixed monthly pricing for cost predictability Resource isolation ensures predictable performance Recommended for: 24/7 services with active market scanning and especially on-chain transaction execution. Chainstack’s Polygon documentation positions dedicated nodes as “go-to” for request-intensive loads, including traders. Quick Comparison Node TypeLatencyCost ModelBest ForGlobal/ElasticUsually lower (geo-routing)Pay-per-requestDev, prototypes, testingDedicatedPredictable, no shared loadFixed monthly (compute/storage)Production bots 24/7 Recommendation: Global Node is the best way to start and debug the pipeline. Dedicated node becomes essential when Alphapoly transitions to production—especially with regular scanning, monitoring, and on-chain execution. Bot load is often “step-wise” (peaks during recalculations), and performance depends on RPC response stability. Deploy Polygon node → Local Installation and setup a Polymarket bot Clone and Install Clone the Alphapoly repository: git clone https://github.com/chainstacklabs/polymarket-alpha-bot.gitcd polymarket-alpha-bot Install dependencies (install uv and npm first): uv sync npm install Quick Start Copy .env.example to .env: cp .env.example .env With make (auto-detects fnm/nvm/volta): make install && make dev Without make: # Backend cd backend && uv sync cd backend && uv run python -m uvicorn server.main:app --reload --port 8000 & # Frontend cd frontend && npm install cd frontend && npm run dev Access the application: Dashboard: http://localhost:3000 API Documentation: http://localhost:8000/docs Configure environment Copy the example configuration: cp .env.example .env Configure your .env file with the following: # OpenRouter LLM Configuration OPENROUTER_API_KEY=sk-or-v1-... IMPLICATIONS_MODEL=<your-chosen-model> VALIDATION_MODEL=<your-chosen-model> # Chainstack Polygon RPC CHAINSTACK_NODE=https://polygon-mainnet.core.chainstack.com/<YOUR_KEY> # Optional: Market filters and polling POLYMARKET_TAG=politics MARKET_POLLING_ENABLED=true POLL_INTERVAL_SECONDS=300 Getting your Chainstack endpoint: Log in to the Chainstack console (or sign up if needed). Create a new project. Select Polygon as the blockchain. Choose the network: Polygon Mainnet Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS RPC endpoints. Configuration tips: Development: Start with MARKET_POLLING_ENABLED=false and enable it once the pipeline is stable Production: Enable polling to incrementally fetch new markets Market focus: Use POLYMARKET_TAG to limit to specific topics (e.g., politics, sports, crypto) How Alphapoly works Alphapoly operates through a sophisticated four-stage pipeline that combines AI reasoning with market analysis: Groups: Market Collection The system fetches multi-outcome market groups from Polymarket. For example, a “Presidential Election Winner” market group contains multiple possible outcomes (different candidates), each represented as a separate tradable position. Implications: LLM Reasoning The LLM (via IMPLICATIONS_MODEL) extracts logical relationships between different market groups. This is where AI adds value—identifying non-obvious connections like: “If Candidate A wins the primary, Candidate B’s general election odds decrease.” “Policy X passage implies higher probability of Economic Outcome Y” These implications are then validated by the VALIDATION_MODEL to reduce systematic errors. Portfolios: Hedge Pair Construction Using the validated implications, Alphapoly constructs position pairs that mutually hedge risk. The system calculates: Probability coverage: How likely the hedge protects against loss Cost analysis: Entry cost for the pair Expected return: Potential profit if the correlation holds LLM confidence: How certain the AI is about the logical relationship The dashboard displays these as actionable strategies with Target bet and Backup bet clearly labeled. Positions: Tracking and Execution Once you enter a position (either manually through the UI or automatically if configured), the system: Monitors on-chain state: Tracks your positions via Polygon RPC Updates in real-time: Shows current P&L and position status Logs activity: Maintains a complete audit trail The key insight: This isn’t simple copy trading or manual analysis. The LLM handles the reasoning layer (“what implies what”), while the engine handles the execution layer (“how to construct and monitor hedges”). This separation allows for sophisticated strategy discovery at scale. Conclusion Alphapoly represents a sophisticated approach to prediction market trading—using LLMs for reasoning, not just execution. The system doesn’t merely copy trades or react to price movements. Instead, it discovers logical relationships between markets and constructs hedging portfolios that would be impractical to identify manually. The architecture demonstrates how to combine modern AI with blockchain infrastructure: LLMs handle the reasoning layer: “What follows from A relative to B” The engine handles execution: Portfolio construction, risk analysis, position tracking RPC provides the transport: Reliable on-chain access via Polygon For infrastructure, the choice is clear: Development: Start with Chainstack Global Nodes for fast deployment and low initial cost Production: Migrate to Dedicated Nodes for consistent performance, no rate limits, and operational predictability The open-source nature of Alphapoly makes it an excellent starting point for building your own prediction market strategies. Whether you’re researching market correlations, testing AI-driven trading hypotheses, or building production automation, the combination of LLM reasoning and robust blockchain infrastructure opens new possibilities in decentralized prediction markets. Explore the Alphapoly repository and deploy your Chainstack Polygon node to get started. Deploy a Polygon node and start building → FAQ Can I run Polymarket bot without RPC? Yes, for detector/tracker mode only. The .env.example notes that RPC is required for on-chain actions. You can start with just the LLM component and UI to discover strategies, then add RPC later when you want to execute trades or monitor on-chain positions. Why use two separate LLM models? The pipeline separates extraction (finding relationships) from validation (checking quality). This allows you to:– Use a faster, cheaper model for initial extraction– Use a more powerful model for validation where errors are costly– Optimize for both quality and cost efficiency What’s the difference between Global and Dedicated nodes for this use case? Global Node: Best for development and testing. Shared resources mean lower cost but variable performance. Perfect for prototyping Alphapoly and validating the pipeline.Dedicated Node: Essential for production 24/7 operation. No rate limits, consistent latency, and resource isolation. Bot workloads are often “step-wise” (spikes during recalculations), making predictable infrastructure critical. How does this differ from copy trading bots? Copy trading: Mirrors another trader’s positions mechanicallyAlphapoly: Uses AI to discover logical relationships between markets and constructs hedge portfolios. It finds alpha through reasoning, not imitation.The LLM can identify correlations like “If X happens, Y becomes more likely” that would be impractical to spot manually across hundreds of markets. What Polygon network does Polymarket use? Polymarket operates on Polygon mainnet (chain ID 137). Make sure your RPC endpoint and any wallet configurations point to mainnet, not testnet. Resources Alphapoly Repository – Full source code, README, and dashboard screenshot Chainstack Polygon Documentation – Getting started guide and endpoint setup Chainstack Global Nodes – Elastic infrastructure documentation Chainstack Dedicated Nodes – Single-tenant deployment guide Polymarket CTF Documentation – Conditional Token Framework overview OpenRouter – LLM API access and model selection Why Public RPCs Aren’t Enough – Understanding RPC limitations under load #### How to build a Solana trading bot On Solana, markets move in milliseconds. New tokens launch, liquidity floods in, and by the time most traders click confirm, the price has already run. This guide shows how to build a basic Solana trading bot in Python using the essentials: a Trader Node for the lowest latency, Geyser gRPC for streaming data, and Warp transactions for faster execution. Trading on Solana doesn’t reward patience. It rewards whoever gets there first. Blocks move fast, and memecoins can double before the tweet lands. The only players who consistently stay ahead are bots. Bots operate by directly accessing on-chain data using the Solana JSON RPC API, sending transactions as soon as a condition is met. With Python and the right infrastructure, you can do the same: connect to a low-latency Solana RPC node (or even run your own full RPC node if you prefer managing infrastructure), stream program events with the Geyser plugin, and send Warp transactions that propagate faster than standard flows. In this guide, we’ll show you exactly how to put those pieces together. Just remember: the result isn’t a plug-and-play money printer. It’s the skeleton every Solana bot needs before you start layering in your strategies, risk controls, and edge. Why build a Solana trading bot? On Solana, things don’t wait. Blocks are produced in ~400ms slots, new liquidity pools pop up, tokens launch out of nowhere. No human can manually track that pace. A trading bot fills the gap. It runs your logic as an always-on process and reacts the instant an event hits the chain. And what you do with it is wide open. Some builders point their bots at fresh liquidity pools so they can move on new tokens as soon as they appear. Others set up simple spread-capture strategies, quoting both sides on a DEX. The more ambitious ones scan across venues, looking for tiny arbitrage windows. The strategies differ, but the principle is the same, automation gives you reaction speed you’ll never match by hand. And while strategies can get complex, the infrastructure doesn’t have to. At its core, every Solana trading bot needs three things. A fast RPC connection, a live data stream, and a reliable way to send transactions. What you need for a Solana trading bot Before wiring up your Solana trading bot, make sure you have: Python 3.10+ installed. A Solana wallet with some testnet SOL to sign transactions. A low-latency RPC like Chainstack Trader Node to reduce queuing and improve time to inclusion. Set up your environment To keep things simple, you don’t need to start from scratch. We’ve already open-sourced a Solana trading bot you can use as a reference: Pump.fun / Bonk.fun bot. This repo includes: A working Solana trading bot scaffold. Code for connecting to RPCs, listening to events, and sending transactions. Examples you can adapt for your own strategies. Clone the repo and explore the structure to see how a production-ready bot is organized. You can then swap in your own RPC endpoint and trading logic. Choosing the right Solana RPC node for your trading bot If your RPC lags: You fetch a stale blockhash, and your transaction fails outright. You stream delayed slot data, and end up reacting to events that have already settled. You hit public Solana RPC rate limits, and your bot goes dark when you need it live. You may also miss or drop critical RPC requests, causing your bot to fall behind the market. That’s why your infrastructure matters as much as your strategy. On a busy Solana cluster, milliseconds decide who wins the trade. You can also run a Solana node yourself. But keep in mind a proper Solana node requires powerful hardware, large amounts of storage to keep up with ledger growth, and ongoing maintenance. To run a validator, you also need a vote account and a large amount of SOL staked, which makes it out of reach for most builders. Some node operators also configure settings to limit ledger size. Running your own setup can be useful if you’re experimenting or want to learn, but most traders skip this overhead in favor of dedicated nodes or managed services. Using Chainstack Solana Trader Nodes This is why most builders use Trader Node. Chainstack Trader endpoints deliver sub-second responses and handle higher RPC methods and requests. They act like top Solana RPC endpoints, tuned for high performance so your bot can keep up with Solana’s 400ms slots without dealing with the overhead that most nodes require. To get one: Log in to the Chainstack console. Spin up a Solana Trader Node (you should have a Growth plan or higher). Copy the HTTPS endpoint and drop it into your .env as SOLANA_RPC_URL. 👉 Read the docs on Trader nodes for setup details. How to stream real-time Solana data with the Geyser plugin A trading bot is only as good as the data it reacts to. If you poll RPCs for account state, you’ll always be a few slots behind and you’ll waste requests. To keep up with Solana’s ~400 ms blocks, you need a streaming feed. That’s what the Geyser plugin gives you: a direct gRPC stream of program logs, account updates, and transaction events as soon as Solana validator nodes see them. Why stream instead of poll Polling = make a request, wait for a response, hope you didn’t miss anything. Streaming = open a socket and listen; the validator pushes every event in real time. For a trading bot, the difference is simple: pollers react to history, streamers react to the present. Subscribing with Geyser On Chainstack, you can enable the Geyser plugin on your Solana Trader Node and subscribe to the data you care about. For example, if you track a DEX program for liquidity events, you subscribe once. You then get a push every time an InitializePool or Swap instruction hits the chain. To get the Yellowstone Geyser plugin: Log in to the Chainstack console. Go to the Marketplace section Select the Geyser plugin and click Install (you should have a Growth plan or higher). Choose the suitable pricing option and specify the Trader Node where to activate the add-on. How to execute fast trades with Warp transactions Catching the signal is useless if your transaction lands late. On Solana, memecoins can double in a single slot. If your bot waits on a slow propagation path, you’re already out of the trade. To activate Warp transactions: Log in to the Chainstack console. Go to the Billing section Top-up your balance with a card or crypto Enable Pay-as-you-go. Building a basic buy/sell function A bot’s core loop usually boils down to: listen → decide → send transaction. Once you’ve got streaming data, you need a simple function to wrap buys and sells. Check out our Pump.fun / Bonk.fun bot for a full example. Using Warp transactions for speed Even with a low-latency RPC, transactions sent over the standard pipeline can get stuck behind network congestion. Warp transactions cut that path short and send your tx straight to the cluster’s block leaders that are validators vote-producing and participating in consensus. For trading bots, that means: Faster inclusion — your transaction is seen earlier in the slot. Lower failure rate — less chance of expired blockhashes. Better edge — more trades land before the price moves. Validators focus on securing the network and earning rewards for block production. Traders, on the other hand, care about execution speed — landing transactions fast enough to capture opportunities. Warp doesn’t change your strategy, it changes the physics of how fast your strategy hits the chain. That’s why most serious Solana trading bots run with Trader RPC + Warp enabled. The Solana trading bot workflow At this point you’ve got the parts of a Solana trading bot laid out: a fast RPC connection, a live data stream, and a transaction path that can push trades fast enough to matter. For a full working example, check out our Pump.fun / Bonk.fun bot. Wrapping up You’ve now seen the basic workflow every Solana trading bot relies on: listen to on-chain data in real time, decide when to act, and push transactions through a low-latency RPC so they land ahead of the pack. If you’re ready to take it further, spin up a Solana Trader Node on Chainstack, you’ll get the speed and reliability your bot needs to compete in sub-second markets. Spin up Solana Trader Node Further reading Get a Solana RPC endpoint on Chainstack and configure a production-ready Solana RPC URL for Devnet or Mainnet. Explore how to use the new Solana faucet on Chainstack to grab testnet SOL and experiment with free Solana RPC connections. Dive into the Solana developer guide covering accounts, programs, Web3.js, and the Solana JSON RPC API. See how we built real-time Solana analytics for Raydium and Bonk.fun using the Yellowstone gRPC Geyser plugin. FAQ Do Solana trading bots work? Yes, but they’re only as good as the infrastructure and strategy behind them. A bot can react faster than humans to on-chain events, but poor RPC latency or badly designed logic means it won’t give you an edge. How much is a Solana trading bot? The code itself can be free (open source). Your real costs come from running infrastructure (like low-latency RPCs, servers, and monitoring) and funding the wallet you trade with. Are trading bots illegal? Trading bots are legal on Solana and most blockchain networks. But if you deploy one on centralized exchanges, always check their ToS, some explicitly ban automation. Can trading bots really profit? Yes, but only with an actual edge. The skeleton you build here handles speed and automation; profitability depends on your strategy and risk controls. Do professional traders use bots? Many do. A large share of high performance trading in both TradFi and crypto is automated. On the Solana blockchain, bots are common in areas like memecoin launches, arbitrage, and market-making — though they don’t guarantee profitability. #### How to build and deploy a subgraph in 5 Minutes ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available.Subgraphs migrated to Ormi. See migration details This guide will show you how to build & deploy your own subgraph in as little as 5 minutes. This is the written version of a “Byte-Size BUIDLing” video that we recently published. Taking after the video, we will build a subgraph that indexes transfers of Bored Ape Yacht Club NFTs. Let’s start by installing the graph client We can do that with npm install. npm install -g @graphprotocol Now let’s make a directory for our subgraph mkdir Chainstack cd Chainstack Verify that we have The Graph client installed To do this and ensure the installation was successful, you can run the following command. graph Start a subgraph project Run the following command that will start the initialization process. This process will take us through a number of general configurations which will be used to generate a project template. graph init You can start by choosing the protocol you’d like to deploy to You will have multiple options, but for the sake of this tutorial, we’ll be choosing Ethereum. Now you can choose between hosted service or Subgraph Studio Because we are deploying our subgraph on Ethereum, we can go with the Subgraph Studio option, and of course, we will be deploying this through Chainstack, which we’ll touch on later in this tutorial. Choose a slug In our case, it’ll be BAYC. Choose the directory to create the subgraph in We can name it ChainstackSubgraph. This will create a sub-directory in the main directory that we created earlier. Choose the network where you are deploying to Here we will pick Ethereum mainnet; named mainnet within the configuration menu. Paste the smart contract address The contract address of the Bored Ape Yacht Club contract is 0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D This will ask for a start block, but we’ll be defining that later on when we paste in our manifest files. Let’s set this at zero for now. For the contract name, you can name this BAYC, and then select Yes. Great, now we should have our basic directory filled out, so we can open that up with our file explorer We need to fill in three main files in order to make this work properly We are referring to the schema file (schema.graphql), the manifest file (subgraph.yaml), and the mappings files (TypeScript file(s) located in ./src). subgraph.yaml Replace the code with a copy of the code below specVersion: 0.0.5 description: A subgraph to index data on the Bored Apes contract features: - ipfsOnEthereumContracts schema: file: ./schema.graphql dataSources: - kind: ethereum name: BAYC network: mainnet source: address: "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D" abi: BAYC startBlock: 12287507 mapping: kind: ethereum/events apiVersion: 0.0.7 language: wasm/assemblyscript entities: - Transfer - BoredApe - Property abis: - name: BAYC file: ./abis/BAYC.json eventHandlers: - event: Transfer(indexed address,indexed address,indexed uint256) handler: handleTransfer file: ./src/bayc.ts Here you can see things like the name of the contract, the contract address, the start block, the entities that are defined in the schema, and the event handlers that are defined in the TypeScript file. Save it and now open your schema file. schema.graphql Replace the code with the sample provided below type Transfer @entity(immutable: true) { id: Bytes! from: Bytes! to: Bytes! tokenId: BigInt! blockNumber: BigInt! transactionHash: Bytes! } type BoredApe @entity { id: ID! creator: Bytes! newOwner: Bytes! tokenURI: String! blockNumber: BigInt! } type Property @entity { id: ID! image: String background: String clothes: String earring: String eyes: String fur: String hat: String mouth: String } Here we have the transfer entity, which is the event that we are listening for, we have the Bored Ape, which is the NFT itself, and we have the property which is the metadata or the attributes of the NFT. Now that we have our manifest defined and our schema defined, we have to define the event handler itself, which is the transfer event. Mappings files (src folder) Go to the TypeScript file and rename contract.ts with bayc.ts and then replace the code with the sample provided below. import { Transfer as TransferEvent, BAYC, } from "../generated/BAYC/BAYC" import { BoredApe, Transfer, Property } from "../generated/schema" import { ipfs, json, JSONValue, log } from '@graphprotocol/graph-ts' export function handleTransfer(event: TransferEvent): void { //Here we write the handler code for the Transfer entity let transfer = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32())) transfer.from = event.params.from transfer.to = event.params.to transfer.tokenId = event.params.tokenId transfer.blockNumber = event.block.number transfer.transactionHash = event.transaction.hash transfer.save() //The transfer entity handler code ends here //Here we write the handler code for the BoredApe entity let contractAddress = BAYC.bind(event.address); let boredApe = BoredApe.load(event.params.tokenId.toString()); if (boredApe == null) { boredApe = new BoredApe(event.params.tokenId.toString()); boredApe.creator = event.params.to; boredApe.tokenURI = contractAddress.tokenURI(event.params.tokenId); } boredApe.newOwner = event.params.to; boredApe.blockNumber = event.block.number; boredApe.save(); //The BoredApe entity handler code ends here //Here we write the handler code for the metadata const ipfshash = "QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq" let tokenURI = "/" + event.params.tokenId.toString(); let property = Property.load(event.params.tokenId.toString()); if (property == null) { property = new Property(event.params.tokenId.toString()); let fullURI = ipfshash + tokenURI; log.debug('The fullURI is: {} ', [fullURI]); let ipfsData = ipfs.cat(fullURI); if (ipfsData) { let ipfsValues = json.fromBytes(ipfsData).toObject(); if (ipfsValues) { let image = ipfsValues.get('image'); let attributes = ipfsValues.get('attributes'); let attributeArray: JSONValue[]; if (image) { property.image = image.toString(); } if (attributes) { attributeArray = attributes.toArray(); for (let i = 0; i < attributeArray.length; i++) { let attributeObject = attributeArray[i].toObject(); let trait_type = attributeObject.get('trait_type'); let value_type = attributeObject.get('value'); let trait: string; let value: string; if (trait_type && value_type) { trait = trait_type.toString(); value = value_type.toString(); if (trait && value) { if (trait == "Background") { property.background = value; } if (trait == "Clothes") { property.clothes = value; } if (trait == "Earring") { property.earring = value; } if (trait == "Eyes") { property.eyes = value; } if (trait == "Fur") { property.fur = value; } if (trait == "Hat") { property.hat = value; } if (trait == "Mouth") { property.mouth = value; } } } } } } } } property.save(); //The Metadata entity handler code ends here } This code defines the Transfer event handler, handleTransfer. If you look at the code, you can see that we have handleTransfer right there, as well as the Bored Ape entity, transfer to token id, transfer from token id, block number, transaction hash, NFT attributes, etc. We will have a complete look over the transfers and the data that we are indexing here once our subgraph is deployed. Now you should have all your files defined, your manifest file (subgraph.yaml), your schema file (schema.graphql) and your TypeScript file. Build the subgraph Open the terminal again. Make sure that you are inside the sub-directory that we created cd ChainstackSubgraph and start by running the following command graph codegen This will automatically generate some files based on the information that we entered in the subgraph. Now go ahead and run graph build Recap on what we did until this point 1. We’ve created our subgraph 2. We’ve initialized it through the graph init function 3. We’ve defined our schema, manifest, and mappings files 4. We’ve run graph codegen to save all our changes 5. We’ve compiled the subgraph through graph build This subgraph is now ready to go ahead and be deployed to the Chainstack hosted service Deploy the subgraph Log in to the Chainstack console https://console.chainstack.com/sign-in and go to the “Subgraphs” tab. If you do not have an account yet, you can sign up for free here. Click on “Create Subgraph” Chose the blockchain that you are deploying to For this tutorial, we will choose Ethereum Mainnet. Type in a name and click “Add subgraph” Go to the deployment command section and copy the code See the sample command below. You’ll need to copy the equivalent snippet with your subgraph URL from the Chainstack console. graph deploy --node https://api.graph-eu.p2pify.com/5b1413adbc6d4533af27469f79dfc4d8/deploy --ipfs https://api.graph-eu.p2pify.com/5b1413adbc6d4533af27469f79dfc4d8/ipfs ggf Paste the command into the directory of your subgraph. Type in the version label In our case, it was v0.0.1 This will compile the subgraph and then it’ll deploy to IPFS, and then it will be finally deployed to Chainstack’s hosted service. If successful, you should see your HTTP endpoint. If you go back to Chainstack’s console, you should see that your Subgraph is now deployed and syncing with the blockchain. That’s a wrap. Congratulations if you’ve made it to the end. If you are looking for more tutorials like this, check out our developer portal and blog. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to build on the Sonic testnet with Chainstack Built for low-latency execution and near-instant blocks, Sonic is becoming a go-to chain for high-frequency apps. Accessing it through Chainstack gives you stable RPC endpoints to test, benchmark, and move projects toward production. Sonic, once known as Fantom, has come back with a new name and a faster core. It rebuilt its consensus around an aBFT engine tuned for real-time execution and paired it with an EVM designed to keep pace. This shift delivers sub-second finality and ultra-low fees, drawing in builders working on high-frequency dApps, trading bots, and data-intensive systems. And while we’ve supported Sonic mainnet for a while, we’re now rolling out Sonic testnet support to give you more room to experiment, stress-test code, and move toward production without rebuilding your setup. What is Sonic? We’ve mentioned that Sonic evolved from Fantom with a faster core, but what that change really means comes down to how the network now handles speed, execution, and incentives. Each piece of the stack was rethought to make it faster in a few key ways: Consensus got faster: Sonic replaced its old validator design with an asynchronous BFT engine that finalizes blocks in under a second. That single change cuts latency, reduces the odds of reorgs, and makes live data feeds far more reliable. Execution stayed familiar but lighter: The network kept the standard EVM stack, yet optimized how transactions move through it. You still write in Solidity and deploy with the same tools, only now your code runs faster and costs less. Apps earn their keep: Every transaction feeds back into builders through a fee-sharing model that rewards activity on-chain. It’s a small but meaningful shift in how network value circulates. Bridging got native: A built-in Ethereum bridge now handles asset transfers and liquidity flow, which means less dependency on third-party connectors and fewer points of failure. Data stayed readable: Events, logs, and traces follow the same EVM formats, so your dashboards, indexers, and subgraphs just work out of the box. Together, these upgrades make Sonic suitable for high-performance EVM workloads. These upgrades open up new ground for what developers can realistically build on an EVM chain. With faster consensus, lower costs, and cleaner data flows, Sonic fits naturally into projects that depend on speed and precision, like: What you can build with Sonic These upgrades fundamentally change what developers can build on an EVM chain. Faster consensus, cheaper execution, and cleaner data flows make Sonic a strong fit for projects such as: High-frequency DeFi protocols: Perpetuals, AMMs, and on-chain order books that rely on near-instant confirmation. Automation and agent systems: Keepers, liquidators, and on-chain executors that depend on predictable block times. Real-time analytics and data pipelines: Dashboards, explorers, and subgraphs that stream and index events without lag. Trading and market bots: Low-latency strategies that need consistent reads and writes across contracts. Payments and consumer apps: Wallets, loyalty systems, and micropayments where low fees and fast UX matter. Cross-chain infrastructure: Bridges and liquidity layers that use Sonic’s native Ethereum gateway for smoother asset movement. How to get Sonic RPC with Chainstack Getting access to Sonic RPC on Chainstack takes minutes and follows the same workflow you’d use for any EVM network. You can deploy endpoints for mainnet or testnet, choose between Global and Dedicated infrastructure, and manage everything from a single console. Here’s how to set it up: Log in to your Chainstack account (or create one if you don’t have it yet). Create a new project or select an existing one. Pick Sonic as the network and choose Sonic mainnet or Sonic testnet. Pick your node type. Chainstack Global Nodes give you instant access through a globally distributed, load-balanced pool optimized for reliability and latency. Chainstack Dedicated Nodes provide single-tenant infrastructure with isolated resources and deeper control. Once deployed, you’ll see both HTTPS and WebSocket endpoints. These serve as your Sonic RPC URLs for apps, SDKs, or scripts. Add the RPC URL to your configuration in Hardhat, Foundry, or any standard EVM client. Wallets like MetaMask can connect using the same URL. Each deployment comes with built-in metrics, request analytics, and Access rules for managing rate limits and API keys. This lets you test safely, monitor performance, and scale without downtime. For low-latency workloads like trading bots or automated strategies, Chainstack Trader Nodes deliver higher concurrency and optimized routing. If you’re indexing data, Chainstack Subgraphs let you query Sonic events without maintaining your own indexer. Both Sonic mainnet and testnet run on the same surface in Chainstack’s infrastructure, so you can build, test, and deploy without switching platforms. Deploy a Sonic node Sonic tooling Sonic development feels familiar if you’ve built on other EVM chains. The network supports standard frameworks and SDKs out of the box, so you can connect to your Chainstack Global Node or Chainstack Dedicated Node using the same setup you already use for Ethereum or Polygon. Below are the main tools that work with Sonic today: MetaMask: Add your Chainstack endpoint directly in node access details to interact through MetaMask. Ideal for deploying or testing contracts in the browser. web3.py and ethers.js: Build or test DApps using your Chainstack RPC URL over HTTP or WebSocket. Both libraries connect instantly to Sonic mainnet or testnet once you provide your endpoint and network ID. Hardhat: Configure Sonic as a network in your hardhat.config.js and deploy with npx hardhat run. The full environment supports compiling, forking, and testing against Sonic. Remix IDE: Use the Injected Provider – MetaMask environment to deploy directly through a Chainstack node. Works well for quick contract checks or demos. Foundry: Run commands with –rpc-url to develop, test, and deploy smart contracts through your Chainstack endpoint. Use forge for deployment or cast for network interactions. For the complete setup examples, command syntax, and network IDs, see the full Sonic tooling guide. Wrapping up Sonic’s rework makes it one of the fastest EVM chains live today, pairing sub-second finality with an architecture built for real-time execution. With testnet live on Chainstack, you can now try that stack yourself. Spin up a node, deploy, and see how it behaves under load. If you want to go deeper, the Sonic swap farming tutorial walks through automating trades in Python on Sonic testnet, good for testing performance or building internal tooling. Deploy a Sonic node Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is Sonic? Sonic is an EVM-compatible Layer-1 that evolved from Fantom with a new asynchronous BFT consensus. It delivers sub-second finality, low fees, and native incentives for apps, making it ideal for performance-sensitive workloads like DeFi, bots, and data pipelines. How do I get access to Sonic testnet? You can deploy a Sonic testnet endpoint directly through Chainstack. Log in, select Sonic testnet, and choose between Chainstack Global Nodes or Chainstack Dedicated Nodes. Once deployed, you’ll get your RPC URL and WebSocket endpoint to use in any EVM client. Is Sonic EVM-Compatible? Yes. Sonic runs a full EVM execution layer, so you can deploy Solidity contracts, use existing SDKs, and interact with tools like Hardhat, Foundry, or The Graph without changes. #### How to build on Unichain testnet with Chainstack Unichain mainnet has solid traction already. Testnet gives builders room to experiment before mainnet, and Chainstack now runs RPC for both. Read on to see how to set up and start building. Every L2 promises lower fees and faster blocks, yet few are tuned for DeFi from day one. Unichain, the OP Stack chain built by Uniswap Labs, is one of them. It runs with one-second blocks and is rolling out ~200 ms sub-blocks, while gas fees come in about 95 percent lower than Ethereum L1. On top of that, block building happens inside a trusted execution environment with verifiable ordering and revert protection. That means failed trades don’t burn gas, and predatory MEV is harder to pull off, creating room for strategies like arbitrage bots and multi-step trades that would be too costly or too slow elsewhere. With both testnet and mainnet online, Unichain RPC is available on Chainstack so you can start on testnet and move to mainnet without changing your setup. Here, we will cover the details on how to connect and get to building. What is Unichain? As said, Unichain is an OP Stack L2 built by Uniswap Labs, with an architecture tuned for decentralized finance. This DeFi-first design delivers low latency, fast confirmation, and the throughput needed for high-frequency trading and complex on-chain strategies. Being built on the OP Stack also makes Unichain fully EVM-equivalent. You get Ethereum compatibility out of the box and direct access to the wider Optimism Superchain. This lets you keep using the same tools you already know — Hardhat, Foundry, and Remix — to port contracts and dApps. Both the Unichain testnet and mainnet share the same environment, which makes building on Unichain feel like a direct extension of your Ethereum workflow. This consistency matters because Unichain isn’t a general-purpose rollup like Arbitrum or Base. It’s built to concentrate DeFi liquidity and experimentation around the Uniswap ecosystem. That focus makes it suited for: High-frequency trading systems and arbitrage strategies Perpetual and margin trading protocols Vaults and advanced multi-step swap routing MEV-resistant liquidation and backrunning Cross-chain DeFi applications tapping into the Optimism Superchain Unichain Mainnet vs. Testnet: Which one to choose? The choice is simple: always start with the Unichain testnet. It’s a risk-free environment designed for development, testing, and debugging without financial risk. Once tested, you switch to the Unichain mainnet, where you can run against live liquidity. FeatureUnichain testnetUnichain mainnetPurposeDevelopment, testing, debuggingProduction apps Token/gasTestnet tokens, obtained for free from a Unichain faucetUNI, ETHLiquiditySimulated, no real exposureReal liquidity and active DeFi protocolsRPC endpointGlobal Nodes, Dedicated NodesGlobal Nodes, Dedicated Nodes Both environments mirror each other, so moving from testnet to mainnet doesn’t require changing your setup on Chainstack. Building on Unichain with Chainstack Infra you can trust is non-negotiable when you’re building on chain, and it matters even more for a DeFi-heavy L2 like Unichain. With Chainstack, you get Unichain RPC on both mainnet and testnet. That means archive access, debug & trace, and global coverage without the stress of running your own nodes. On the Unichain mainnet, you can run Global Nodes or Dedicated Nodes, and choose between Full and Archive. On Unichain testnet, you can run Global Nodes or Dedicated Nodes. Both environments expose HTTP and WebSocket connections. You can also add Access rules to control methods, keys, and IPs. From here, create a Unichain RPC endpoint on Chainstack and plug it into your tooling. How to connect to Unichain testnet RPC In the Chainstack console, open your project and click Add node. Choose between Global Node or Dedicated Node and then pick testnet. Deploy the node. Copy the HTTP or WebSocket RPC endpoint from the node details page. Paste the endpoint into your config (Hardhat, Foundry, Remix, or whichever framework you use). Fund your wallet with testnet tokens from a faucet. Deploy and interact with your contracts against Unichain testnet. Create Unichain node Wrapping up Unichain is built for DeFi, and now both its testnet and mainnet are supported on Chainstack. With Unichain RPC you can deploy contracts, run tests, and debug without worrying about infra, then scale the same setup when it’s time to ship. The flow is simple: start on the Unichain testnet to experiment safely, then move to mainnet when you’re ready for real liquidity. Chainstack gives you the same workflow across both, so the only thing that changes is the network you point to. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is Unichain, and how is it different from other L2s? Unichain is a DeFi-first L2 built by Uniswap Labs on the OP Stack. Unlike general-purpose rollups such as Arbitrum or Base, it’s designed with DeFi in mind: low latency, MEV protection, and throughput that can handle high-frequency trading. The goal is to concentrate liquidity and experimentation around the Uniswap ecosystem. Is Unichain EVM-compatible? Yes. Unichain is fully EVM-equivalent. This means that if you’re a developer coming from Ethereum, you can use the same tools and workflows you already know, such as Hardhat, Foundry, and Remix, without any major changes. Your existing smart contracts will port over seamlessly. Does Unichain have a testnet? Yes. The Unichain testnet is live and supported on Chainstack. It mirrors the mainnet environment but uses faucet tokens and may reset more often. #### How to build your own blockchain with Polygon Supernets: A beginner’s guide Scalability and throughput have always been the most significant pain points for Web3 developers working with public networks. This is where Polygon Supernets truly shines, offering a crucial feature that solves this dilemma: interoperability. Polygon Supernets can communicate with other blockchains, enabling seamless transactions across multiple platforms. By combining Ethereum’s security with the versatility of a self-governing blockchain, they have developed a system that can support a vast spectrum of use cases. A Supernet allows you to build your own blockchain network that caters to the needs of your application, enabling you to establish default transaction fees and implement your own gas token. In this article, we will explore the world of Polygon Supernets and provide a step-by-step guide to creating and deploying your blockchain platform for the first time. First, let’s start by explaining what Supernets are, what they can do, and why they are a game-changer in Web3. What are Polygon Supernets? In a nutshell, Polygon Supernets is a network of connected clusters offering various benefits for data management and collaboration. They function as an ecosystem of seamlessly integrated modules that enhance their capabilities as they accumulate. By understanding complex data structures and uncovering previously unseen relationships between data points, these Supernets provide a potent tool for users. Beyond their inherent utility, Polygon Supernets also enable communication and data sharing among different groups of users. They can exchange messages and value with other Supernets and the Ethereum network, with validators ensuring the network’s security level by participating in the MATIC mainnet. With tons of potential use cases, many projects have already utilized Polygon Supernets to enhance their capabilities. One recent example is Nubank, a significant fintech company based in the LATAM region. It announced that it is partnering with Polygon and leveraging Polygon Supernets to power its loyalty program with “NuCoin,” its customized blockchain token. As an increasingly vital tool for businesses and individuals looking to manage and understand complex data structures, Polygon Supernets have tremendous potential for mainstream adoption. Why should I use Polygon Supernets? If you are tired of dealing with slow, unreliable blockchain networks that fail to meet your specific needs, Polygon Supernets is the answer to your woes. Blockchains weren’t meant to be one-size-fits-all, and a Supernet lets you create a personalized blockchain that you can fine-tune and infinitely customize. Polygon Supernets are custom-designed to provide a superior installation experience and offer improved speed, constant and reliable throughput, and broad customization options. Plus, Web3 applications can be seamlessly integrated directly into dedicated networks, optimizing them for modern blockchain formats. But Polygon isn’t just stopping there. With their goal of bringing mass Web3 adoption, Supernets constitute a significant step in the right direction. As a scalability solution comprising numerous Publicnets and a standalone blockchain-based solely on the principle of Supernets, Polygon is working to achieve maximum transparency between validator nodes. What’s more, Polygon Supernets can be tailored to meet the needs of your specific project, whether it’s an L1 Supernet validated by professional validators or an even more scalable L2 Supernet that utilizes a web of blockchains for web applications. What are the benefits of using a Supernet? 1) Versatility Supernets are specialized and intended for a singular project or application. Although initially developed for specific purposes, they are now utilized for diverse functions. These dedicated Web 3 hosting systems have the advantage of being tailor-made networks that can be employed for particular objectives. One such application is linking universities for seamless student transfers. Supernets are a valuable resource for both storing and retrieving data. 2) Supernets can employ any scaling architecture When selecting the various architectural options for the Polygon Edge blockchain legos, remember that only the Simple, Trusted, and Protected options will be accessible through Supernets. The Supernets’ ease of use and many advantages make it simpler for developers to deploy and run their apps. As Supernets grow, they can modify different aspects of their architecture to meet current demands. For instance, the Supernet Polygon Edge could begin as a self-governing Proof of Authority network, transition into a Proof of Stake network, and eventually evolve into a full-fledged Layer 2. The owner can transfer the underlying software’s ownership at any point. 3) The Supernet platform provides full-fledged support for EVM (Ethereum Virtual Machine) and smart contracts By integrating EVM into the Supernet framework, developers compile smart contracts created on the platform into EVM bytecodes using high-level languages like Solidity. Additionally, developers can easily port Solidity contracts to Supernets without any modifications. Thanks to this support for EVM, developers with experience in Ethereum can easily use Supernet utilities like Truffle suite, Hardhat, MetaMask, Remix, and block explorers to create new applications. This enables developers to leverage their existing skills and knowledge to build innovative applications on the Supernet platform. 4) Support from Polygon Edge-certified partners Creating, managing, and sustaining blockchain networks can be challenging, and app developers may not have the knowledge and expertise to execute them effectively. These efforts can be demanding, consuming significant time and resources. To address this issue, Polygon offers Edge Certified Partners, which comprises certified development teams that can either take over or assist with these aspects. 5) Supernets enable the hassle-free creation of custom, high-speed, and exceptional-performance blockchain networks Their modular design allows for the swift deployment of new features without compromising overall performance. Supernets also provide an open architecture that simplifies integration with existing blockchain networks. How to build your own blockchain platform? Now that we’ve covered the basics of Polygon Supernets and you better understand what they are, it’s time to start building your very own blockchain network. Step 1: Choose the right development environment To build your blockchain platform, you must choose the right development environment. There are several options, including Truffle, Remix, and Hardhat. Each has advantages and disadvantages, depending on your project’s complexity and requirements. Step 2: Design the blockchain structure The next step is to design the structure of your blockchain. You need to determine the number of nodes, the consensus mechanism, the block size, and other parameters. You can use tools like Ganache to simulate your network and test different configurations. Step 3: Configure nodes and set up the network Once you have designed the structure, you must configure the nodes and set up the network. Polygon Supernets use the PoS consensus mechanism, which means you must set up nodes and validators to secure the network. You can use our Polygon Supernets nodes to set up your nodes and validators quickly. Step 4: Create smart contracts Smart contracts are self-executing contracts that run on the blockchain. They automate transactions and eliminate the need for intermediaries. You can create smart contracts using Solidity, a programming language specifically designed for Ethereum and Polygon Supernets. Step 5: Test and deploy them The final step is to test and deploy your blockchain platform. You can use tools such as Truffle and Remix to test your smart contracts and ensure they function correctly. Once you have completed testing, you can deploy your blockchain to the network and transact. Step 6: Boost your blockchain with Polygon Supernets After deploying your blockchain platform, you can enhance it further using Polygon Supernets. You can leverage Polygon’s interoperability to extend your network’s capabilities, connect with other blockchains, and benefit from cross-chain transactions. Integrating your blockchain with the Polygon Network can also help you scale your network and improve transaction speed and security. You can use Polygon’s PoS bridge to connect your network to the Polygon Network and take advantage of its features. Final thoughts Now that you know how to build your own proof of stake blockchain platform, you can customize it to your needs and integrate it with other platforms using Polygon Supernets’ interoperability. As blockchain technology and Web3 continue to evolve, the possibilities for your decentralized applications are endless. Polygon seeks to remove the complexity of blockchain development by providing exceptional support to help you build your own blockchain without the hassle of maintaining blockchain infrastructure. So what are you waiting for? Start running your blockchain with Polygon Supernets on Chainstack today. We are currently helping thousands of projects run on Polygon. Our direct communication with the Polygon development team ensures that we deliver optimal solutions to you. Leave the heavy lifting to us while you focus on what’s truly important: Innovating and BUIDLING! FAQ How is a Polygon supernet different from an Avalanche subnet? Subnets and Supernets are both scalability solutions for building L1 blockchains quickly. Avalanche uses the Snowman Proof-of-Stake consensus protocol for probabilistic consensus and infinite decentralization, while Polygon’s IBFT consensus protocol guarantees consensus but limits permissionless participation and decentralization. Avalanche processes up to 4500 TPS, while Polygon processes up to 1500 TPS. Subnets have around 1,300 validators, require a minimum staking amount of 2000 AVAX to become a validator and require all validators to validate the entire primary network. Supernets have 100 validators, need a minimum staking amount of 20,000 MATIC to become a validator, and do not have a similar validation requirement. Supernets and subnets also differ in their approach to Slashing, with Avalanche aiming to prevent centralization of staking while Ethereum favors higher stake validators. Why is Polygon faster than Ethereum? Polygon processes transactions on side chains instead of the main chain for faster transaction speeds and lower fees due to lower congestion. Developers can create multiple side chains with customized rules and governance structures to meet specific Web3 needs. Polygon boasts a transaction speed of almost 65,000 transactions per second. Its consensus mechanism completes the transaction confirmation process in a single block, allowing for an average block processing time of 2.1 seconds, making it much faster than Ethereum. Polygon is a Layer-2 scaling solution for Ethereum that provides a cheaper and faster experience and allows developers to create customized blockchain environments. What is the difference between Ethereum and the Polygon blockchain? Ethereum and Polygon have entirely different architectures and use cases for Web3 developers. Ethereum is a standalone blockchain that focuses on supporting decentralized applications and smart contracts. On the other hand, Polygon is a Layer 2 scaling solution that enhances Ethereum’s scalability, speed, and interoperability. Polygon is a Layer-2 scaling solution that mitigates Ethereum’s gas fees, providing users with a more affordable experience. Who is behind Polygon Matic? Jaynti Kanani, Sandeep Nailwal, and Anurag Arjun, experienced entrepreneurs and developers in the blockchain space, co-founded Polygon Matic. With a background in developing and scaling decentralized applications, the team behind Polygon Matic dedicates itself to providing a reliable and user-friendly blockchain platform. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to check ERC20 token balance – The ultimate guide Checking different ERC20 token balances is a common task and something pretty simple to do. You just need to open your wallet, and it’ll automatically check the balances of all the tokens you’ve imported. But what happens if you own some tokens that you have not imported into your wallet? What if you want to check the balance of someone else’s wallet? And what if you want to check your balances on a specific date? In this article, we’re going to show you everything you need to know about how to check token balances for any wallet, in multiple blockchain protocols, at any point in time. In addition, we’ll provide a command-line tool that you can run locally to make things even easier. Let’s jump into it. How to check ERC20 token balance? All ERC20 tokens have a balanceOf method that returns the balance of a given wallet address. This method is public so anyone can use it, you just need: the ERC20 token contract address. the wallet you want to query the balance from. access to a blockchain node to run the query. So first of all, to get access to multiple blockchains nodes with Chainstack: Sign up with Chainstack. Deploy a node. Get the node RPC endpoints. How to get an ERC20 token address? We can find the address of the ERC20 token we want to check from the project documentation. For common tokens like USDC, you can go to any explorer like Etherscan, enter the name, and it’ll pop up. If we want to get the balance from multiple tokens, the first thing we need is a list of all of them. One option is to manually create a file with the contract address of all the ERC20 tokens we want to check. This option is ok if we want to check just a few tokens, but if we want to check the balances across tens of different tokens, manually creating a file would be a tedious task. So, how can we get a list of all ERC20 tokens? How to get a list of ERC20 tokens? TokenLists.org is a good option for Ethereum, but if we want to query different blockchain protocols, we need more lists. Luckily for us, this is something a lot of people are working on and I found this repository with lists of ERC20 tokens for a lot of different blockchains like Avalanche, BNB, Polygon, etc. We can manually download the JSON files directly from the repository or download them with JavaScript. In the example below, I created a function that receives the name of the blockchain we want to get the token list for, and it downloads it from the corresponding URL: // using axios for the request const axios = require('axios') const TOKEN_LISTS = { Ethereum: 'https://raw.githubusercontent.com/viaprotocol/tokenlists/main/tokenlists/ethereum.json', Avalanche: 'https://raw.githubusercontent.com/viaprotocol/tokenlists/main/tokenlists/avax.json', Binance: 'https://raw.githubusercontent.com/viaprotocol/tokenlists/main/tokenlists/bsc.json', Polygon: 'https://raw.githubusercontent.com/viaprotocol/tokenlists/main/tokenlists/polygon.json', } /** * @param chain string with the protocol name. eg Avalanche */ const getTokens = async (chain) => { // get token list file URL by chain const tokenSource = TOKEN_LISTS[chain] // retrieve token list from URL const res = await axios.get(tokenSource) // return list of tokens return res.data } How to check the current balance and past balance? To obtain the current balance we’d need to call the balanceOf method of the ERC20 contract instance and pass the wallet address we want to query from: const { ethers } = require('ethers') const provider = new ethers.providers.JsonRpcProvider('https://my-chainstack-node/123456') /** * Gets current balance * @param {*} token object with address, name and symbol * @param {*} wallet address to query * @returns */ const getSingleTokenBalance = async (token, wallet) => { const contract = new ethers.Contract(token.address, ERC20_ABI, provider) const res = await contract.balanceOf(wallet) return res } However, if we want to obtain the balance from a previous date, we’d need to include the blockTag flag, which receives the block number from which we want to query. const { ethers } = require('ethers') const provider = new ethers.providers.JsonRpcProvider('https://my-chainstack-node/123456') /** * Gets balance at a given block * @param {*} token object with address, name and symbol * @param {*} wallet address to query * @param {*} block block number * @returns */ const getSingleTokenBalanceByBlock = async (token, wallet, block) => { const contract = new ethers.Contract(token.address, ERC20_ABI, provider) // adds the blockTag flag to query past balances const res = await contract.balanceOf(wallet, { blockTag: +block, }) return res } It’s important to note that you can obtain the current balance from a blockchain full node, but in order to get balances from past dates (or 128 blocks before the current one in most cases), you’d need access to an archive node. You can get access to both types of nodes in Chainstack, just make sure you are using the correct one to avoid getting errors. And if you want to read more about the differences between full and archive nodes, check out this article. The problem here is, how do we find the block number of a specific date? Let’s dig into that. How to get the block number for a past date? Obtaining the block number at any given date is the tricky part. For Ethereum, there is the ethereum-block-by-date NPM package, but for other chains, I haven’t found anything similar. However, most chains have an explorer based on Etherscan. For example, there is Snowtrace for Avalanche and BscScan for BNB Chain. All these explorers have a public API with a method named getblocknobytime that returns the block number at a given timestamp. You can find the documentation here. So to get the block number from a specific date, we just need to send a request to the API method passing a Unix timestamp and our API key. const axios = require('axios') // API base URL const ETHERSCAN_API = 'https://api.etherscan.io/api' // API key loaded from environment variable const ETHERSCAN_API_KEY = process.env.API_KEY /** * @param {*} dateFrom JS Date to query from * @returns the block number * */ const getBlockByTimestamp = async (dateFrom) => { // generate Unix timestamp from JS date const timestamp = Math.floor(new Date(dateFrom).getTime() / 1000) // API endpoint from docs const queryParams = `?module=block&action=getblocknobytime&timestamp=${timestamp}&closest=before&apikey=${ETHERSCAN_API_KEY}` const endpoint = `${baseURL}${queryParams}` // send requests using axios const res = await axios.get(endpoint) // reponse received in data.result return res.data.result } How to get multiple token balances simultaneously? Once we have a list of tokens, we can loop through it and call the balanceOf method for each token to get a list of all token balances. However, waiting for each request to finish before sending the next one can take a lot of time. For example, the Ethereum token list has more than 1200 different tokens so it’ll take a while to send all the requests one after the other. Using Promise.allSettle() we can loop through the list of tokens and create all the requests, but instead of waiting for each one, we can send them all simultaneously: /** * Loops through a token list to retrieve balances for a given wallet * @param {*} tokenList array of tokens with address, symbol, decimals and name * @param {*} wallet address to query balance from * @param {*} block block number to query past balances * @returns Array of balances */ const getAllTokenBalances = async (tokenList, wallet, block) => { // array to store all balance requests let proms = [] // array to store balances let results = [] for (const tkn of tokenList) { // create ERC20 token contract instance const erc20 = new ethers.Contract(tkn.address, ERC20_ABI, provider) // save request in array of Promises proms.push( erc20.balanceOf(wallet, { blockTag: +block, }) ) } // actually requests all balances simultaneously const promiseResults = await Promise.allSettled(proms) // loop through all responses to format response for (let index = 0; index < promiseResults.length; index++) { // transforms balance to decimal const bal = convertToNumber( promiseResults[index].value, tokenList[index].decimals ) // save balance with token name and symbol results.push({ name: tokenList[index].name, symbol: tokenList[index].symbol, balance: bal, }) } return results } Note that we’re storing all the request responses in promiseResults and then looping through it to format the balance as a decimal and save it with the token name and symbol. How to obtain token details: name, symbol, and decimals All the token properties like name and the number of decimals can be retrieved from the contract itself using the name or decimals methods. Here is a function that retrieves the name, symbol, and number of decimals for a given token: const { ethers } = require('ethers') const provider = new ethers.providers.JsonRpcProvider( `https://chainstack-node-endpoint/123456` ) /** * @param {*} address address of the ERC20 token contract * @returns object with name, decimals and symbol of the token */ const getTokenDetails = async (address) => { const contract = new ethers.Contract(address, ERC20_ABI, provider) console.log(`Retrieving ERC20 token details...`) const decimals = await contract.decimals() const name = await contract.name() const symbol = await contract.symbol() return { name, decimals, symbol } } How to format token balance to decimal The balanceOf method of the ERC20 token contract returns the balance as a BigNumber in hexadecimal format and converting it to string will not separate the decimals for us. For example, if we have 15 USDC, the response will be this: // wallet with 15 USDC const balanceBN = await contract.balanceOf(wallet) // balanceBN will be BigNumber { _hex: '0xe4e1c0' } const balanceStr = balanceBN.toString() // balanceStr will be "15000000" In order to format this into a number with decimals, we can use ether.utils.formatUnits, which receives the original value and the number of decimals. Most ERC20 tokens use 18 decimals by default but not all of them, like USDC which uses 6 decimals. /** * * @param {*} hex the original value in hex format * @param {*} decimals the number of decimals used by the token, default 18 * @returns */ const convertToNumber = (hex, decimals = 18) => { if (!hex) return 0 console.log(`Converting to number ${hex} with ${decimals} decimals`) return ethers.utils.formatUnits(hex, decimals) } ERC20 token balances CLI tool In the following repository, you can find a CLI tool that simplifies the whole process of checking token balances. To run it locally, you’d need to get access to blockchain nodes, get your API keys from Etherscan, Snowtrace, BscScan, and PolygonScan and configure them in the .env file. You can query the balances from the different blockchains and choose between a single token or all available tokens (which will be retrieved from the GitHub repo mentioned above). In addition, you’ll be able to select the date you want to query from. You can find all the instructions to configure and run the application in the repository. Conclusion In this article, we’ve reviewed all the little intricacies that could arise when dealing with token balances. From finding a token contract to getting a list of all the tokens in a protocol, and formatting the response with decimals. Getting balances from past dates can be very tricky because we need to find the block number for a specific date, but we can make things easier by leveraging APIs from the different blockchain explorers. Make sure to clone the repo with our token balance CLI tool and give it a try! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to connect Chainstack MCP server to Codex What if Codex could check a wallet balance, deploy an Ethereum node, or pull Chainstack docs — all without leaving your terminal? With the Chainstack MCP server, it can. MCP (Model Context Protocol) is an open standard that lets AI agents talk directly to external tools and APIs. Connect it to Chainstack and Codex gets live access to 70+ blockchain networks, your node infrastructure, and the full Chainstack documentation — right inside your coding workflow. This guide walks you through setup for Codex CLI and the Codex IDE extension. What is the Chainstack MCP server MCP (Model Context Protocol) is an open standard that gives AI agents secure, structured access to external tools and APIs. It was created by Anthropic and has since been adopted across the AI ecosystem — including OpenAI Codex. Chainstack is a blockchain infrastructure provider offering RPC nodes for 70+ networks: Ethereum, Solana, Base, Polygon, Arbitrum, and more. The Chainstack MCP server lets Codex: Search Chainstack documentation Deploy and manage Global Nodes via natural language Make direct JSON-RPC calls to Ethereum, Solana, and all other supported chains ServerURLTransportStatusChainstack MCP (unified)https://mcp.chainstack.com/mcpStreamable HTTP✅ Current Available tools No API key required: ToolWhat it doessearch_docsSearch Chainstack documentation — RPC methods, deployment guides, code examplesget_doc_pageFetch the full content of any documentation pageget_platform_statusCheck platform status, active incidents, and network healthget_chainstack_pricingGet current pricing informationcontact_chainstackReach the Chainstack team API key required (get one at console.chainstack.com/user/settings/api-keys): ToolWhat it doesget_organizationGet your organization name and IDget_deployment_optionsList available blockchain, cloud, and region combinationslist_projectsList all your projectscreate_projectCreate a new projectlist_nodesList all nodes with status and endpointsget_nodeGet a node’s full details including RPC endpointscreate_nodeDeploy a new blockchain nodedelete_nodeDelete a noderequest_testnet_fundsRequest testnet tokens Prerequisites Codex account — sign up or log in at codex.com. Codex CLI — install via npm: bash npm install -g @openai/codex Check your install with: codex --version 3. Node.js ≥ 18 — required for npm. Check with: node -v. 4. Chainstack account — sign up at console.chainstack.com/sign-up. Create an API key under Settings → API Keys (shown only once — save it somewhere safe). Where Codex stores MCP configuration Codex stores all MCP configuration in a single TOML file. The CLI and the IDE extension share this configuration, so you only need to set things up once. OSPathmacOS / Linux~/.codex/config.tomlWindows%USERPROFILE%\.codex\config.tomlProject-scoped.codex/config.toml (in trusted projects only) To open the config from the IDE extension: select the gear icon → Codex Settings → Open config.toml. Connecting Chainstack MCP to Codex Chainstack runs a cloud-hosted unified server at mcp.chainstack.com/mcp — no local installation needed. Option 1: Register via CLI (recommended) The quickest way. Run one command and Codex handles the rest: bash codex mcp add chainstack --url https://mcp.chainstack.com/mcp To also pass your Chainstack Platform API key as a bearer token (required for node deployment and project management): bash codex mcp add chainstack \ --url https://mcp.chainstack.com/mcp \ --bearer-token-env-var CHAINSTACK_API_KEY Then export your key in your shell profile: bash export CHAINSTACK_API_KEY=your_api_key_here Verify the server is registered: bash codex mcp list Option 2: Edit config.toml directly For more control, add the following block to ~/.codex/config.toml: Without API key (documentation search and platform status only): toml [mcp_servers.chainstack] url = "https://mcp.chainstack.com/mcp" With API key (full access including node management): toml [mcp_servers.chainstack] url = "https://mcp.chainstack.com/mcp" bearer_token_env_var = "CHAINSTACK_API_KEY" Then set the environment variable: bash export CHAINSTACK_API_KEY=your_api_key_here To make the key persistent across sessions, add the export line to your ~/.bashrc, ~/.zshrc, or equivalent. Verify the connection Open the Codex TUI and run: /mcp You should see chainstack listed with a connected status. You’re ready. Example prompts Once connected, Codex can query blockchain data, manage your infrastructure, and search Chainstack’s documentation inline. EVM queries: “Get the ETH balance of 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on Ethereum mainnet.” “Trace transaction 0xabc…def and explain what happened step by step.” “What’s the latest block number on Ethereum?” Solana queries: “What’s the SOL balance of Gh9ZwEmdLJ8DscKNTkTqPbNwLNNBjuSzaG9Vp2KGtKJr?” “Get recent prioritization fees and recommend a priority fee for a swap.” Documentation: “How do I enable the Yellowstone gRPC Geyser plugin on my Chainstack Solana node?” “What chains on Chainstack support archive data?” “Show me the Chainstack pricing tiers.” Platform operations (requires API key): “Deploy a new Chainstack Global Node on Ethereum mainnet in the us-east region.” “List all my active nodes and their endpoints.” “Scan my repo for hardcoded RPC URLs and suggest Chainstack replacements.” Project-scoped configuration If you want Chainstack MCP enabled only for a specific repository, use a project-level config instead of the global one. Create .codex/config.toml in your project root: toml [mcp_servers.chainstack] url = "https://mcp.chainstack.com/mcp" bearer_token_env_var = "CHAINSTACK_API_KEY" Note: Codex only loads project-scoped config from trusted projects. To mark a project as trusted, run codex from that directory and confirm the trust prompt. Troubleshooting ProblemSolutionchainstack not showing in /mcpRun codex mcp list to verify registration. If missing, re-run codex mcp add.TOML parse errorValidate ~/.codex/config.toml with a TOML linter — a stray quote or missing bracket breaks everything silently.401 Unauthorized on platform toolsEnsure CHAINSTACK_API_KEY is exported in your current shell session and that the key is active in your Chainstack console.Bearer token not picked upThe bearer_token_env_var value should be the variable name (e.g., "CHAINSTACK_API_KEY"), not the key value itself.RPC calls failingChainstack endpoints already embed credentials in the URL — no additional Authorization header is needed for RPC.Project config not loadingCodex only loads .codex/config.toml from trusted projects. Run codex from the project root and accept the trust prompt. Conclusion Once connected, Chainstack MCP turns Codex into a live blockchain development assistant — you can query on-chain data, deploy and manage nodes, and search Chainstack’s documentation without leaving your terminal or IDE. The unified server at mcp.chainstack.com/mcp requires no local setup and works across both the Codex CLI and the Codex IDE extension. The CLI and IDE extension share the same ~/.codex/config.toml, so you configure once and it works everywhere. For node management and platform operations, grab your API key at console.chainstack.com/user/settings/api-keys — public tools like documentation search and platform status work without one. Get started for free → FAQ Do I need a paid Codex plan to use Chainstack MCP? Any Codex plan works. MCP server support is part of the standard Codex CLI and IDE extension. Do I need a Chainstack API key? Not for documentation search, platform status, or pricing lookups. You do need one for node deployment and project management. Get it at console.chainstack.com/user/settings/api-keys. Does my CLI config also work in the IDE extension? Yes. Codex stores MCP configuration in a single ~/.codex/config.toml shared by both clients. Configure once and it works in both. What chains does Chainstack MCP support? All chains available on the Chainstack platform — including Ethereum, Solana, Base, Polygon, Arbitrum, and more. See the full list at chainstack.com/protocols. Can I scope Chainstack MCP to a single project? Yes. Create .codex/config.toml in your project root with the [mcp_servers.chainstack] block. Codex loads it only for that project (requires trusting the project on first run). Related reading Chainstack MCP server documentation How to connect Chainstack MCP server to Claude Blockchain RPC nodes for AI agents Migrate blockchain RPC endpoints to Chainstack #### How to connect to Plasma RPC endpoint for zero-fee stablecoin transfers Plasma is a new EVM-compatible L1 built for stablecoin payments. It combines zero-fee USDT transfers with deterministic finality in seconds, making it practical for enterprise rails. With Chainstack, now you can deploy Elastic or Dedicated Plasma RPC nodes, test performance on mainnet or testnet, and move stablecoin infrastructure into production. Stablecoins hold over $250 billion in circulation, with more than $2 trillion moving on-chain each month in 2025 across exchanges, merchant settlements, and treasury flows. That kind of volume makes it clear what builders care about most: predictable units, low friction, and settlement that clears the moment a transaction is sent. Yet most networks still trade one of those for another. Lower fees often slow settlement, while faster confirmations raise costs. That’s why builders are starting to look at Plasma, a new L1 designed for stablecoin transfers from the start. It offers zero-fee USDT transfers through protocol-level sponsorship and deterministic finality in seconds, powered by PlasmaBFT. And now, you can build with Plasma directly on Chainstack, available on testnet and mainnet through Global Nodes and Dedicated Nodes (available on request). What is Plasma chain? As said, Plasma is one of the few L1s built specifically for stablecoins, but what makes it different under the hood comes down to two choices: how it handles gas and how it reaches finality. First, the network sponsors gas for USDT transfers at the protocol level, meaning verified transfers don’t require a native token. Then there’s PlasmaBFT, a deterministic consensus layer that locks transactions within seconds instead of relying on probabilistic confirmations. Together, these two design calls make stablecoin transfers faster, cheaper, and far more predictable than what most EVM chains can offer. In practice, that gives builders: Zero-fee USDT transfers where the protocol covers gas for verified sends, so users don’t need to hold a native token. Deterministic finality through PlasmaBFT, which closes transactions within seconds and keeps settlement loops tight. Full EVM compatibility powered by Reth, so your Solidity contracts, SDKs, and indexers run without change. Infrastructure already live on Chainstack, letting you connect to Plasma RPC on testnet or mainnet without running validators. Plasma and stablecoin payments The way to see the impact of plasma is to look at what that design does once it hits the payment layer. As the network sponsors gas for USDT and locks transactions deterministically through PlasmaBFT, transfers start behaving less like crypto operations and more like instant balance updates. It’s a subtle change at the protocol level that shifts how stablecoin infrastructure works day to day. The clearest way to see it is through product and ops outcomes: Onboarding drops the gas token step, so a first send can happen immediately. Payouts reconcile on the same tick they’re sent, tightening approval and release loops. Merchant and treasury flows can price transfers precisely, since verified USDT sends carry no network fees. Dev teams keep their existing solidity stack and data pipelines, sizing infra for latency targets instead of fee volatility. It puts Plasma in a different lane, closer to a stablecoin-native settlement network than a traditional Layer 1: Plasma vs other payment chains CriteriaPlasmaTronEthereum RollupsFee model for USDTZero-fee for verified transfers via protocol sponsorshipUser pays network fee in trx or USDT depending on wallet flowUser pays L2 fee posted to L1FinalityDeterministic in secondsProbabilistic with committee-based confirmationsFast L2 confirmation, L1 finality followsEVM SupportFull EVM via rethTVM, solidity-likeFull EVMLatency and withdrawalsSeconds to usable fundsSeconds to minutes depending on pathSeconds on L2, L1 settlement adds delayBest fit for Stablecoin payments, payouts, merchant railsLarge USDT flows, consumer remittanceGeneral compute with on-chain data availability When to build on Plasma If your priority is predictable timing, no-gas transfers, and EVM compatibility, Plasma is usually the cleaner choice over general L1s or rollups, with common use cases including: Stablecoin payouts and treasury automation – recurring payroll, vendor disbursements, or treasury sweeps without gas overhead. Merchant rails and fintech apps – instant settlements and refunds with lower checkout friction and full EVM parity. Cross-border settlements – predictable timing and zero-fee transfers for counterparties across regions. Exchange and wallet USDT flows – cheaper deposits, withdrawals, and rebalancing with bounded confirmation windows. BTC bridge via pBTC – move liquidity from Bitcoin, then operate daily in USDT on Plasma. All of these begin with one setup step: connecting to Plasma RPC. How to get Plasma RPC If you’re testing Plasma’s zero-fee model, the best way to do it is through managed RPC. Having both testnet and mainnet access in one place makes it easier to benchmark performance, track stability, and move from testing to production, and Chainstack now runs both environments in a single console. With Chainstack, you can either deploy Global Nodes or globally routed access with failover, or Dedicated Nodes (available on request) for single-tenant performance in a specific region. Both are available on testnet and mainnet, expose JSON-RPC and WebSocket. As your traffic grows, enable the Unlimited Node add-on to switch to flat-fee billing by RPS tier with unlimited requests inside the tier. Additionally, you can set Access rules to manage keys, rate limits, and permissions per environment. Because Plasma runs on Reth, your Solidity contracts and SDKs work as they are, with no rewrites or special configuration. With this setup, you can benchmark zero-fee USDT transfers on testnet, record latency and success rates, then switch the same configuration to mainnet when your flow is production ready. It keeps the work in one place and lets you focus on building rather than running infrastructure. Start building on Chainstack Wrapping up Zero-fee USDT, sub-second finality, full EVM support. Plasma bundles all three into one L1, which is why it works for merchant payouts, treasury automation, and cross-border settlements. If you want to test it out, get Plasma RPC through Chainstack. Both environments, testnet and mainnet, are live, with an option to deploy either Global Nodes or Dedicated Nodes (available on request). Start building on Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is Plasma? Plasma is a new EVM-compatible Layer 1 built for stablecoin payments. It uses PlasmaBFT consensus for deterministic finality and covers USDT gas fees at the protocol level, enabling zero-fee transfers with predictable settlement. How is Plasma different from other Layer 1s? Most networks optimize for compute or DeFi throughput. Plasma focuses on stablecoin movement. It combines zero-fee transfers, sub-second finality, and EVM compatibility to make payments behave like instant balance updates rather than blockchain transactions. What is PlasmaBFT? PlasmaBFT is the network’s consensus engine. It achieves deterministic finality within seconds, removing the need for probabilistic confirmations and making settlement timing consistent across transfers. Does Plasma support USDT only? USDT is the first stablecoin supported with protocol-level gas sponsorship. Other tokens can still operate as standard ERC-20 assets, with gas paid in the network’s native token. What is the Reth execution layer? Reth is a high-performance execution client built in Rust and fully compatible with the EVM. It ensures your Solidity contracts, SDKs, and dev tools work on Plasma without modification. How do I get Plasma RPC? You can access Plasma RPC on Chainstack, available across testnet and mainnet through Global Nodes for shared access or Dedicated Nodes (available on request) for isolated performance. Both support HTTPS JSON-RPC and WebSocket connections. Can I use Plasma with MetaMask or web3 SDKs? Yes. Plasma runs on Reth, so it supports standard EVM tooling. You can add Plasma to MetaMask or connect via common libraries like web3.js, ethers.js, or Foundry. Is Plasma production-ready? Yes, both testnet and mainnet are live. Builders can benchmark performance on testnet, then move the same setup to mainnet once their flow is validated. What kind of use cases is Plasma best for? Plasma works best for merchant payouts, treasury automation, exchange transfers, and cross-border settlements, anywhere stablecoins are the primary asset being moved. #### How to connect to Zircuit RPC for smart contracts Built with proof aggregation and a hybrid design, Zircuit is a zk rollup for Ethereum developers. Running smart contracts and processing transactions in real time requires stable RPC, and here’s how Dedicated Nodes on Chainstack make that possible. Zircuit is a zk rollup built for Ethereum developers, combining proof aggregation with a hybrid architecture to keep gas fees low and smart contracts fully EVM compatible. It extends the Ethereum network while giving builders a secure environment to deploy production workloads. Over time, Zircuit has become a strong choice for teams building DeFi protocols and liquid restaking tokens, with hundreds of millions already staked. The appeal is obvious: an EVM-compatible rollup designed to run production contracts safely and at scale, with RPC access as the entry point to start building. But to understand why, let’s look closer at what it is and how it works. What is Zircuit? As mentioned, Zircuit uses a hybrid architecture with proof aggregation. A key differentiator is Sequencer Level Security (SLS), an AI-powered layer at the sequencer that inspects transactions in real time and can quarantine suspicious activity before block inclusion. When building, this comes in handy because this closes the gap where many exploits occur, improves ordering predictability, and keeps costs in check while staying fully EVM compatible. Add modular proof aggregation that rolls subproofs into a single validity proof, plus faster settlement once proofs verify, and you get a rollup that can handle production workloads without forcing you to change your Ethereum toolchain. The result is a rollup tuned for jobs where security and timing decide outcomes. That covers DeFi protocols chasing reliable order flow, restaking projects moving large sums, and systems that trigger on live data or automated execution. Choosing Your Connection: Public vs. Private Zircuit RPC Endpoints The choice between public and private access completely depends on what you’re building. Public endpoints are fine for testing and lighter workloads, though they can run into rate limits or inconsistent latency. For production-grade dApps or financial protocols, a private RPC provides the stable throughput and uptime needed to handle traffic at scale. To help you decide, here’s a quick comparison: FeaturePublic Zircuit RPCPrivate Zircuit RPCCostFree, community/sharedPaid, reserved capacityPerformanceOften limited, risk of throttling and outageHigh performance, scalable depends on requirementsLatencyVariable, can spike under loadConsistent, low-latency response timesThroughputShared bandwidthUltra-high throughput, isolated performanceAccess controlNone or minimalIP whitelisting, key gating, access rulesDebug/trace APIsSometimes unavailableTypically enabledBest forTesting, dashboards, light appsProduction dApps, trading bots, DeFi protocols, high-traffic services While public RPC is fine to start with, it won’t hold up once you’re shipping to real users or moving size. At that point, you can either spin up your own node or go with a provider like Chainstack if you want less overhead, more features, and flat-fee pricing that stays predictable. So in the next section, let’s take a look at the costs. How much does it cost to run a Zircuit RPC? If you host it yourself, running an OP Stack–based node for Zircuit means covering hardware, bandwidth, storage, and ongoing maintenance. Also, there’s no full node guide in the docs yet. Costs swing depending on your setup and the level of redundancy you need, which is why most teams choose a provider instead of rolling their own. With providers, you’ll usually see usage-based or tiered pricing. On Chainstack, that means a Dedicated Node paired with a Pro plan at a flat monthly rate. It’s simpler to budget, and you don’t have to worry about surprise overages. To get an estimate, explore the pricing options here and see what fits your project. How to get a private Zircuit RPC URL So you’ve decided to move to a private RPC. That’s a good call — once you’re dealing with real users or moving capital, stability matters more than anything. If you go with Chainstack, you get a Zircuit node that runs in its own secure environment, backed by 99.9% uptime, and it speaks standard JSON-RPC so it drops right into Hardhat, Foundry, ethers.js, or web3.py. Get Zircuit Dedicated Node How to set up a Zircuit RPC in a wallet or app To connect directly, add Zircuit as a custom network in your wallet or dev tooling: Mainnet Chain ID: 48900 RPC URL: https://mainnet.zircuit.com Currency symbol: ETH Explorer: https://explorer.zircuit.com Garfield Testnet Chain ID: 48898 RPC URL: https://garfield-testnet.zircuit.com You can also add Zircuit through Chainlist for a one-click setup. And if you’re using a Chainstack Dedicated Node, replace the public RPC URL with your private endpoint once it’s provisioned (it will work with the same settings). Wrapping up We’ve walked through what Zircuit brings to the table, how its RPC endpoints fit in, and the choices you have for connecting. If you’re building DeFi, liquid restaking, or anything that depends on predictable sequencing and steady infra, the RPC setup is where it all starts. Request Zircuit Dedicated Node Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is Zircuit? Zircuit is an EVM-compatible zk rollup built on an OP Stack–based foundation. It combines proof aggregation, hybrid architecture, and Sequencer Level Security (SLS) to lower gas costs, speed up finality, and make blockchain technology safer to use in production. What is the Zircuit RPC API? Zircuit RPC follows the standard Ethereum JSON-RPC spec. Because the rollup is fully EVM compatible, you can use the same libraries and frameworks you already know—ethers.js, web3.py, Hardhat, Foundry—by pointing them to a Zircuit RPC URL. Is Zircuit compatible with existing Ethereum smart contracts? Yes. Zircuit supports Solidity contracts and is fully compatible with the Ethereum development stack, so you can keep using your usual frameworks and tools. Can I use public Zircuit RPC endpoints for production? Public endpoints are best for testing, dashboards, and lighter workloads. For production deployments or high-traffic apps, private RPC access gives you consistent performance and avoids shared rate limits. How do I connect to Zircuit in MetaMask or another wallet? Add Zircuit as a custom network using the official chain ID, RPC URL, and explorer, or add it directly through Chainlist. If you’re on Chainstack, replace the public URL with your private endpoint once it’s ready. #### How to create an EVM compatible blockchain bridge Blockchains are siloed systems. If you have some tokens or NFTs in your Ethereum wallet, they are not available for you to use or spend on Tempo, Solana, Arbitrum, or any other blockchain. Interoperability between blockchains is one of the most significant problems that the industry is trying to solve, and one of the solutions we currently have is cross-chain bridges. Bridges allow users to “send” these tokens from one blockchain to another. This seems like an easy task, but it actually involves multiple pieces of code and smart contracts. In addition, production-ready bridges have to control any errors that could arise when sending tokens across to avoid losing them into the ether 😉 When bridging stablecoins, the choice of destination chain matters. Purpose-built payment chains like Tempo offer predictable gas costs and sub-second finality, making them attractive targets for enterprise stablecoin settlement compared to general-purpose networks. In this article, we’re going to build a basic bridge between two EVM-compatible blockchains. And which better than the most popular, Ethereum, and the latest one supported by Chainstack, Harmony 😊 This project will help us get an overview of how bridges work behind the scenes. Requirements You’ll need access to blockchain RPC nodes on both sides of the bridge. To get started, check out the following links: Sign up with Chainstack. Deploy a node. Get the node RPC endpoints. In addition, you’ll need some tokens for your target networks to pay for the smart contract deployments and the bridge transactions. This bridge was tested with the Ethereum Ropsten and Harmony testnets. You can get Ropsten ETH here and Harmony testnet ONE here. Blockchain bridge overview Our bridge will be very simple: When the bridge wallet receives tokens from the Ethereum side of the bridge, it should mint new tokens in the Harmony side and send them to the same user. When the bridge wallet receives tokens from the Harmony side of the bridge, it should burn those tokens and transfer back the same amount of tokens from the bridge wallet to the user. The project is divided into three parts: Smart contracts: we need two ERC20 token contracts, one in each blockchain that we’re going to bridge. To create and deploy the smart contracts, I’m going to use Hardhat. Web app: the frontend that users will interact with to actually send their tokens accross. I’ll create it with Vue.js and use ethers.js to interact with the smart contracts. Backend job: we also need a process listening to tokens received in the bridge wallet. This job will be written in JavaScript to keep it simple. It’ll use web3.js to interact with our blockchain RPC nodes and smart contracts. You can find all the code of this project in the following repository in GitHub. Steps overview Create an ERC20 token contract for the Ethereum chain. Create an ERC20Burnable token contract for the destination chain. Override the mint and burnFrom methods with onlyBridge modifier. Deploy contracts to the Ropsten and Harmony testnets. Create frontend to transfer tokens from user’s wallet to the bridge. Create a backend job that listens for Transfer events in both token contracts. Store the bridge wallet private key in the server. Methods to send mint, burnFrom and transfer transactions from the server. Create the ERC20 tokens As mentioned, I’ll use Hardhat to create the contracts. I created a solidity folder to hold the Hardhat project. Run npx hardhat and select the Create sample project option to scaffold the project. It’ll generate a test contract and script for you. We’ll use standard ERC20 tokens on both sides of the bridge, so we have to install OpenZeppelin contracts with npm install @openzeppelin/contracts. With all the dependencies installed, we can create the contract files inside the solidity/contracts folder. I created two files: OriginToken.sol and DestinationToken.sol. OriginToken.sol: is a standard ERC20 token for the Ethereum side of the bridge. It mints all tokens once it’s deployed. In the constructor, we have to send a token name, symbol and an initial supply. I named this contract ChainstackDollars with the symbol CHSD. // SPDX-License-Identifier: MIT pragma solidity ^0.8.4; import "hardhat/console.sol"; // Import ERC20 import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract ChainstackDollars is ERC20 { // create the token passing the name and symbol constructor( string memory _name, string memory _symbol, uint256 _initialSupply ) ERC20(_name, _symbol) { // mint all tokens and send them to the deployer's wallet _mint(msg.sender, _initialSupply * (10**uint256(18))); console.log("Tokens minted %s", _initialSupply); console.log("Deployed! Tokens sent to %s", msg.sender); } } Note: we’re minting the initial supply received multiplied by 10**18, as the ERC20 token has 18 decimals by default. DestinationToken.sol: is an ERC20 and ERC20Burnable token for the Harmony side of the bridge. This means we can use the mint and burnFrom methods to create and destroy tokens. Instead of using the default mint() and burnFrom() methods, we’ll override them to add the onlyBridge modifier which will prevent any other sender, except the bridge, to call these methods. I named this token DChainstackDollars with symbol D-CHSD. // SPDX-License-Identifier: MIT pragma solidity ^0.8.4; import "hardhat/console.sol"; // Import ERC20 import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; contract DChainstackDollars is ERC20, ERC20Burnable { address bridge; constructor(address _bridge) ERC20("DChainstackDollars", "D-CHSD") { bridge = _bridge; } modifier onlyBridge() { require( bridge == msg.sender, "DChainstackDollars: only the bridge can trigger this method!" ); _; } // @dev called from the bridge when tokens are locked on ETH side function mint(address _recipient, uint256 _amount) public virtual onlyBridge { _mint(_recipient, _amount); console.log("Tokens minted for %s", _recipient); } // @dev called from the bridge when tokens are received // on Harmony side function burnFrom(address _account, uint256 _amount) public virtual override(ERC20Burnable) onlyBridge { super.burnFrom(_account, _amount); console.log("Tokens burned from %s", _account); } } Note: this contract has no initial supply as it will only be minted when users bridge some ChainstackDollar tokens from the ETH side of the bridge. Deploying the ERC20 token contracts To deploy the contracts we first need to get Ropsten ETH from here and Harmony testnet ONE from here. Once we have the “money”, we need to configure our target networks and account in the hardhat.config.js file. In my case, I created an .env file and loaded the values from it like this (you’ll have to install dotenv (npm i dotenv) for that): require('@nomiclabs/hardhat-waffle') //load env file require('dotenv').config() //.... module.exports = { solidity: '0.8.4', paths: { sources: './contracts', artifacts: '../web/src/artifacts', tests: './test', }, networks: { hardhat: { chainId: 1337, }, ganache: { chainId: 5777, url: 'http://127.0.0.1:7545', }, // Eth side of the bridge origin: { url: process.env.DEPLOY_ENDPOINT_ORIGIN, accounts: [process.env.DEPLOY_ACC_KEY], }, // Harmony side of the bridge destination: { url: process.env.DEPLOY_ENDPOINT_DESTINATION, accounts: [process.env.DEPLOY_ACC_KEY], }, }, } The URLs (DEPLOY_ENDPOINT_ORIGIN and DEPLOY_ENDPOINT_DESTINATION) are the HTTPS endpoint from your nodes, which you can get from the Chainstack console. The account is the private key of your wallet. Make sure you do not upload that private key to a repository or share it! To deploy the contracts, I created two script files: solidity/scripts/deployOrigin.js and solidity/scripts/deployDestination.js: They’re both pretty similar; the only difference is that in deployOrigin.js we have to pass a few parameters to the constructor: the token name, the symbol, and the supply while the deployDestination.js does not need those. // File: solidity/scripts/deployOrigin.js const main = async () => { const [deployer] = await hre.ethers.getSigners() const accountBalance = await deployer.getBalance() console.log('Deploying contracts with account: ', deployer.address) console.log('Account balance: ', accountBalance.toString()) let contractFactory = await hre.ethers.getContractFactory('ChainstackDollars') let contract = await contractFactory.deploy( 'ChainstackDollars', 'CHSD', 1000000 ) await contract.deployed() console.log( 'contract ChainstackDollars deployed to address: ', contract.address ) } const runMain = async () => { try { await main() process.exit(0) } catch (error) { console.error(error) process.exit(1) } } runMain() To execute the scripts and deploy the contracts, we need to run npx hardhat run ./scripts/deployOrigin.js --network origin and npx hardhat run ./scripts/deployDestination.js --network destination. If everything goes well, you’ll see something like this in the console: > contract ChainstackDollars deployed to address: 0xASDF1234ASDF1234ASDF1234 Remember to run both scripts and save the contract addresses, as we’ll need them for both the frontend and backend jobs. Building the frontend I’ll not explain step-by-step how I created the web app, but I’ll go through the main concepts. I created a Vue.js application with two pages: Origin.vue and Destination.vue. Each page has a form in which users can enter the number of tokens they want to bridge: When the user clicks the Bridge to… button, MetaMask asks the user to authorize the transaction and the tokens are transferred to our bridge wallet. Here is the code from the Origin.vue file that triggers the transfer: import ChainstackDollars from '@/artifacts/contracts/OriginToken.sol/ChainstackDollars.json' const bridgeWallet = import.meta.env.VITE_BRIDGE_WALLET const originTokenAddress = import.meta.env.VITE_ORIGIN_TOKEN_ADDRESS const provider = new ethers.providers.Web3Provider(window.ethereum) // get the account that will pay for the trasaction const signer = provider.getSigner() let contract = new ethers.Contract( originTokenAddress, ChainstackDollars.abi, signer ) const sendTokens = async function () { const amountFormatted = ethers.utils.parseUnits(amount.value, 18) if (typeof window.ethereum !== 'undefined') { trxInProgress.value = true try { const transaction = await contract.transfer( bridgeWallet, amountFormatted.toString() ) console.log('transaction :>> ', transaction) // wait for the transaction to actually settle // in the blockchain await transaction.wait() bridgedOk.value = true amount.value = '' trxInProgress.value = false } catch (error) { console.error(error) trxInProgress.value = false } } } As you can see, there are a lot of variables that we need to pre-load, like the contract address (VITE_ORIGIN_TOKEN_ADDRESS), the bridge wallet address (VITE_BRIDGE_WALLET), and the contract ABI. Again, I decided to load them from an .env file and provided an example in the repository. The transfer method will transfer the indicated amount of CHSD tokens from the user’s wallet to the bridge wallet. The Destination.vue file is similar although it transfers the D-CHSD tokens instead. Create the backend process Now that we’re able to transfer tokens from the user’s wallets to the bridge wallet, we need a job that listens to those transfers and reacts accordingly. Remember: When the bridge wallet receives CHSD tokens from the ETH side of the bridge, it should mint new tokens in the Harmony side and send them to the same user. When the bridge wallet receives D-CHSD tokens from the Harmony side of the bridge, it should burn those tokens and transfer back CHSD tokens from the bridge wallet to the user. The code for the backend job is stored in the backend folder and, as the rest of the pieces, requires some variables to be configured in an .env file like: WebSocket endpoints: we can get these from our Chainstack dashboard. Token contract addresses: we need the token addresses to listen to the events emitted by them and to transfer, mint, and burn tokens. Bridge wallet: all transactions will be signed and sent from our bridge wallet, so we need to have the private key stored in the backend. You can find an example env file for the backend in the repository. ERC20 tokens emit a Transfer event that we can monitor to identify bridge transactions. Here is the part of the event-watcher.js file that starts a Transfer event listener: const CHSD_ABIJSON = require('./ChainstackDollars.json') const BRIDGE_WALLET = process.env.BRIDGE_WALLET const BRIDGE_WALLET_KEY = process.env.BRIDGE_PRIV_KEY const ORIGIN_TOKEN_CONTRACT_ADDRESS = process.env.ORIGIN_TOKEN_CONTRACT_ADDRESS const originWebSockerProvider = new Web3(process.env.ORIGIN_WSS_ENDPOINT) // adds account to sign transactions originWebSockerProvider.eth.accounts.wallet.add(BRIDGE_WALLET_KEY) const oriNetworkId = await originWebSockerProvider.eth.net.getId() const originTokenContract = new originWebSockerProvider.eth.Contract( CHSD_ABIJSON.abi, ORIGIN_TOKEN_CONTRACT_ADDRESS ) let options = {} originTokenContract.events .Transfer(options) .on('data', async (event) => { await handleEthEvent( event, destinationWebSockerProvider, destinationTokenContract ) }) .on('error', (err) => { console.error('Error: ', err) }) console.log(`Waiting for Transfer events on ${ORIGIN_TOKEN_CONTRACT_ADDRESS}`) We need to listen to the Transfer events of both token contracts and check if the destination address of the transfer is our bridge wallet address. If that’s the case, we can proceed with the bridge operations of minting, burning, or transferring tokens. When the bridge wallet receives CHSD on the ETH side of the bridge, we need to mint the same amount of D-CHSD tokens in the Harmony side of the bridge and send them to the same user. To do so, I created the mintTokens method: const BRIDGE_WALLET = process.env.BRIDGE_WALLET const ORIGIN_TOKEN_CONTRACT_ADDRESS = process.env.ORIGIN_TOKEN_CONTRACT_ADDRESS const DESTINATION_TOKEN_CONTRACT_ADDRESS = process.env.DESTINATION_TOKEN_CONTRACT_ADDRESS const mintTokens = async (provider, contract, amount, address) => { try { const trx = contract.methods.mint(address, amount) const gas = await trx.estimateGas({ from: BRIDGE_WALLET }) console.log('gas :>> ', gas) const gasPrice = await provider.eth.getGasPrice() console.log('gasPrice :>> ', gasPrice) const data = trx.encodeABI() console.log('data :>> ', data) const nonce = await provider.eth.getTransactionCount(BRIDGE_WALLET) console.log('nonce :>> ', nonce) const trxData = { // trx is sent from the bridge wallet from: BRIDGE_WALLET, // destination of the transaction is the ERC20 token address to: DESTINATION_TOKEN_CONTRACT_ADDRESS, data, gas, gasPrice, nonce, } console.log('Transaction ready to be sent') const receipt = await provider.eth.sendTransaction(trxData) console.log(`Transaction sent, hash is ${receipt.transactionHash}`) console.log( `mintTokens > You can see this transaction in ${process.env.DESTINATION_EXPLORER}${receipt.transactionHash}` ) } catch (error) { console.error('Error in mintTokens >', error) return false } } As you can see, creating a valid transaction manually requires a lot of data. We need to get the gas price and amount, obtain the wallet’s transaction count (or nonce) and finally, send it and wait for it to be added to a block. When the bridge receives D-CHSD tokens in the Harmony side of the bridge, the operation is more complex as we need to: Call approveBurn() to authorise burning the tokens in the Harmony side. Call burnFrom() to actually burn the tokens in the Harmony side. Call transfer() to transfer tokens in the ETH side of the bridge. For this, I created three different methods that you can review in this file of the repository. Wrapping up To test the bridge, you just need to start the backed process with npm start and the web app with npm run dev. The web should be available on localhost:3000, where you can send some tokens between chains. In addition, you should be able to see some logs in the backend terminal. This bridge is a simplified version and it does not handle all possible errors when minting or burning tokens, but I hope it helps you understand how they work behind the scenes. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to create generative NFTs? Making abstract art with code You may be expecting a dry and convoluted tutorial but we’re just going to have some fun this time instead. That is why you will be building a real Rube Goldberg NFT printing machine beyond the minds of even the maddest of scientists. Jokes aside, you really are about to start building an NFT doomsday machine. But doing so will also be a great opportunity to practice some of the most foundational concepts behind programmatic or procedural generation as it’s commonly referred to. And since the goal of this tutorial is to show you how you can be an artist without ever touching the brush, you also get a chance to experience the diversity of code that the open-source community has to offer you as aid. Will it be lean? Hardly! But how often will you get to have a real Dr. Frankenstein moment while doing a tutorial on Web3? So, put on your lab coat and start practicing your evil laughter, for you are about to go Lex Luthor on your code editor and programmatically mint yourself a brand-new horde of loyal minions as NFTs. How to generate NFTs – Overview Planting the seed of procedural generation Build on existing foundations Out with the old and in with the new Installing essential libraries Initializing core variables Structuring the script Seed parameter generation Generating a unique ID Generating text colors Creating a number string Setting shape generation parameters Creating a loop for the remaining shape parameters Calculating the digital root of the number string Checking if the digital root result is odd or even Procedural generation layer 1: Text Procedural generation layer 2: Icon Procedural generation layer 3: Shape Merging the three image layers Uploading the merged image to IPFS Creating the metadata JSON Submitting the minting transaction Outcome Planting the seed of procedural generation While procedural generation does sound quite scary and arcane, in reality, it is a relatively simple concept. What makes it complex, however, are the countless clockwork gears you can put together to assemble such mechanical golems to your liking. So, let’s forget about that for a moment and start off at ground zero. At the core of everything procedurally generated lies the seed. The seed is a set of symbols in various arrangements like words, numbers, and any other nonsensical string of characters you can imagine. Planting such a seed in an algorithm like an NFT nuclear football generator tends to sprout into an endless chain of roots and branches, resulting in more possible combinations than the time it takes to mint them all. How that is possible you may be asking, and the answer you will find by planting the seed in several generator layers. And the best thing about it? You only need a single seed to feed as many as you need. Split it, do some math, and transform it. Every digit is a value, and every byte is a part of the equation. A perfect opportunity to make up for all those boring arithmetic lessons. Sounds fun? It is! Let’s dive in: Build on existing foundations As the wise men say, there is no need to reinvent the wheel and as you will see soon, you will be rather taking a public transport ride instead. What this metaphor serves to point out is that you will be using plenty of ready-made tools and libraries to reach the finish line. In turn, this would allow you to focus more on having fun than writing the next few tomes of “Code and Release.” Your first coding Uber ride for this tutorial will take you through our previous article on the subject of NFTs, where we explored every step from planning to coding and release with all their pesky details. And as the saying goes “if it ain’t broke don’t fix it,” so go ahead and rip the full tutorial files without shame. Up for a challenge instead? Then just feel free to start from the beginning with it: In the end, what you really need to get things started with this tutorial is a working minting contract and a node endpoint at your disposal – all the metadata you get to generate inside your code. And if you have the former, not the latter, it’s time to take another shortcut that will take away the stress of running one on-premises. All you need to do is reach this stop to grab an endpoint with zero cost: Out with the old and in with the new To make the entire process easier to follow and understand, you won’t be taking an organic approach to set things up, as was the case when making this tutorial. Instead, you get to organize your toolset right off the bat in a clean and efficient manner. That being said, let’s move forward with the first half of the prerequisites for your procedural minter. Assuming you have either successfully followed through on the first tutorial, or shamelessly ripped its end code, you will have a “mint.js” file with the following dependencies at your disposal: require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; const privKey = process.env.PRIVATE_KEY; const contractAdrs = process.env.CONTRACT_KEY; var fs = require('fs'); var contractNFT = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); var metadata = 'https://ipfs.io/ipfs/QmZZXrLMFFXYAcSQmjmtGNqc6ZhYe2ECCoANFAXVBS3T7y?filename=sampli.json'; As mentioned earlier, you won’t be reinventing the wheel in this tutorial, so go ahead and copy all of these to a new JS file, which you can call “generate.js” to best fit its end goal. You can skip the last variable “metadata,” however, as you won’t be working with pre-generated metadata. Instead, you will be taking care of it yourself. And the best thing about it? You won’t need to touch a single pixel. Installing essential libraries And speaking of which, now that you have the first half of the dependencies you need, it is time to take care of the second. To do that will need a diverse palette of libraries all of which are available with a seamless NPM installation. So, hop on to your CLI and start fetching those NPM packages: npm i random-words text-to-image jdenticon canvas image-data-uri merge-images axios form-data In doing so, you will install the eight packages you need to reach the end of the tutorial. The first one – “random-words” is a generator package that will output a set of random words, given the number of words you want to have upon completion. “Text-to-image,” on the other hand will render those words into an image file you can use as one of the generator layers. When it comes to “jdenticon,” it works in a similar manner to a gravatar but instead of looking cool on your website or wallet, for example, it will be exported to another image layer. The third image layer will be drawn “by hand” if you can call it that, using “canvas”. But rather than using your mouse or a paint brush, you will just input as code the points you want drawn and connected. Even so, the “canvas” package will create a “dataURI” output, which you may have seen across the web as something similar to “data:image/gif;base64,R0lGODlhyAAiALM…DfD0QAADs=” and that is not something you can work with directly. That is why you will use the “image-data-uri” to process it into a “.png” file, like the rest of the image layers generated with other packages. Once you have everything you need, in terms of layers, you will also need a library that will merge them all together to create the final form of your NFT image. For that you will use the “merge-images” package. And with everything pressed into a single image file, you won’t be able to make any further progress without an HTTP request module, such as “axios” to push relevant data to IPFS. Since you will be working with Pinata, you will also need “form-data” to help set the file metadata. Once you have successfully installed all the libraries, don’t forget to reference them in your code too! Oh, and while we are still on the subject of forgetting and referencing, this would be a good starting point to integrate a coding best practice into your workflow – leaving a descriptive comment trail. This one will particularly come in handy, as the complexity of how everything is intertwined will increase exponentially, as you dig deeper into the tutorial. And with this practical insight noted, you can move forward with the next steps. To make it easier for you, here’s what your “generate.js” file would look like with everything taken care of correctly: //Process dependencies require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; const privKey = process.env.PRIVATE_KEY; const contractAdrs = process.env.CONTRACT_KEY; var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); var fs = require('fs'); var randomWords = require('random-words'); var textToImage = require('text-to-image'); var jdenticon = require('jdenticon'); const { Canvas, Image } = require('canvas'); const ImageDataURI = require('image-data-uri'); var mergeImages = require('merge-images'); var axios = require('axios'); var FormData = require('form-data'); var data = new FormData(); var contractNFT = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); Initializing core variables Despite having your dependencies adequately referenced, you may encounter issues when running your code, should your environmental variables be set incorrectly. After all, the entire backbone of the script relies on them to connect to the Goerli network and execute smart contract interactions. Fortunately for you, there is yet another shortcut you can take to make sure you got things right. That is why, you will find an example environment setup here that clearly outlines the format of each variable, so you can just copy and paste it into a “.env” file and fill it with your own. You can use the same tool from the example setup to manage your Dapp secrets, which will especially come in handy once your project starts getting real or should you prefer to avoid dealing with “.env” files manually. With environmental variables taken care of, you can move forward with initializing the ones you need for the procedural generation stages: // Initialize variables // Starting seed parameters var randomHex; // The starting seed for procedural generation var idHex = ''; // The unique ID generated from the initial seed var wordNrs; // The output from converting the initial hex seed to decimal // Text layer parameters var digiRoot; // The digital root result of the decimal number string above var randomStr; // The output of the random word generator var wordsOut = ''; // The output from cleaning up the random word string var colorHex = '#'; // The hex color output generated for the text layer var bgColorHex = '#'; // The hex color output generated for the text background // Shape layer parameters var shapeSides = ''; // The number of sides generated for the polygon shape var shapeSize = ''; // The size generated for the polygon shape var shapeCtrX = ''; // The central X-axis position generated for the polygon shape var shapeCtrY = ''; // The central Y-axis position generated for the polygon shape var shapeStroke = '#'; // The generated polygon shape border color var shapeFill = '#'; // The generated polygon shape fill color // IPFS interaction parameters var ipfsPath; // The IPFS CID generated for a particular upload and pin var jsonPath; // The file system path generated for the JSON metadata file Structuring the script To create the script for the procedural generation of the NFTs, let’s first start by mapping out the structure that we will be following to make it easier to understand. Overall, the structure will contain 11 core fragments: An overlapping generator function Seed parameter generation Text layer generation Icon layer generation Shape layer generation Shape layer export Layer merge Merged image IPFS upload Metadata generation Metadata JSON IPFS upload Transaction commit That being said, the first thing you need to do is create the overlapping generator function. To create this, start with an async function and be sure to leave its curly brackets open, as we will only be closing it, once everything is complete: const generator = async () => { // Random generator layer 0: Seed preparations console.log('\nSeed generation started...\n'); Seed parameter generation As mentioned previously, everything procedurally generated starts with the seed. Such is the case here too, which is why your first task is to generate a random hex string of 20 bytes with Web3.js. Generating a hex string of 20 bytes will deliver you one with the same length as an Ethereum address. To do that you can use the built-in functionality of the library and to add further randomization you will be tying the result with a slice of the address. Make sure you exclude the “0x” before the address to make the resulting string uniform with the following code segment: // Generate random hex with 20 bytes for symbols (same as wallet addresses) randomHex = web3.utils.randomHex(20).concat(address.slice(2)); console.log('Random hex generated: ' + randomHex + '\n'); Generating a unique ID Next, let’s create a unique ID to be included within the text layer to add another opportunity for randomization. To generate this ID, you will be using the first three symbols from the randomHex string and combine them with the last three, which will be coming from the address: // Generate ids for filenames to organize easier idHex = randomHex.slice(2, 5).concat(randomHex.slice(79, 82)) console.log('Used hex to generate ID: ' + idHex + '\n'); Generating text colors To generate some colors for the text layer, such as font and background colors, you will be using the same randomHex string you generated earlier. To promote a higher degree of randomization, create a “for loop” that will repeat a total of six times for each of the needed characters. You will need six characters, since a hex color code is composed of six characters, as is the case for the color “white,” for example, with #ffffff being its code. You will do this twice for each color – one for the font and one for the background. Keep in mind that adding a “#” will not be needed since it is already there from the variable initialization stage and you will be adding the characters after it: // Generate random hex color value by picking random characters from the generated hex string for (var i = 0; i < 6; i++) { colorHex = colorHex.concat(randomHex.slice(2).charAt(Math.floor(Math.random() * randomHex.slice(2).length))); bgColorHex = bgColorHex.concat(randomHex.slice(2).charAt(Math.floor(Math.random() * randomHex.slice(2).length))); } console.log('Used hex to generate text color: ' + colorHex + ' & background color: ' + bgColorHex + '\n'); Creating a number string Next, it’s time to lay some more groundwork for the text layer beyond the simple hex colors you set up in the previous step. To do that, you will first need to transform the randomHex string into the decimal counting system with the built-in Web3.js functionality: // Generate new string by combining the random hex output with wallet address and converting it to number string wordNrs = web3.utils.hexToNumberString(randomHex); console.log('Transformed hex into number string: ' + wordNrs + '\n'); Setting shape generation parameters Okay, this is the part, where things get a little more complicated. To generate the shape, you will need a set of several parameters, similar to those of the text layer we introduced before. These will be: shapeSides shapeStroke shapeFill shapeSize shapeCtrX shapeCtrY Let’s start with the number of sides for the polygon shape that will be stored in the “shapeSides” variable. To determine the number of sides, grab the numbers string you converted in the previous step and grab some of its characters at random: // Begin calculations for random shape layer generation parameters // Randomize shape parameters but ensure they are never zero // Find out the number of sides the shape has by picking a random number from the number string above shapeSides = parseInt(1 + wordNrs.charAt(Math.floor(Math.random() * wordNrs.length))); console.log('Used number string to determine polygon shape sides count: ' + shapeSides + '\n'); Once done it’s time to pick colors for the shape too. To do that, you can use the hex colors for the text layer generated earlier, while grabbing the first three and last three digits of each color for the “shapeStroke” variable and vice versa for the “shapeFill” one: // Combine the first three digits of one of the two hex color values picked above with the last three of the other for greater variation shapeStroke = shapeStroke.concat(colorHex.slice(4, 7).concat(bgColorHex.slice(1, 4))); shapeFill = shapeFill.concat(bgColorHex.slice(4, 7).concat(colorHex.slice(1, 4))); console.log('Used text & background colors to generate new border: ' + shapeStroke + ' & fill: ' + shapeFill + '\n'); Creating a loop for the remaining shape parameters Next, it’s time to create a “for loop” that will generate the “shapeSize”, as well as the starting point on the X and Y axes for the drawing of the shape. This can normally be done without a loop but considering the desired values you are looking for are of at least two digits, it is necessary. After all, given a maximum shape size of 350×350, which are the absolute dimensions of the image, two-digit values will land your shape somewhere in the middle with enough size to make it clearly visible: // Loop following calculations twice to generate double or higher digit values to have the shape for (var i = 0; i < 2; i++) { // Avoid negative results by converting result to absolute value // Pick a random digit from the number string above, add the current shapeSize value, serve as float, multiply by Pi and add 10 for sizes between ~50 and ~150 for greater balance shapeSize = Math.abs(10 + Math.PI * parseFloat(shapeSize + parseInt(wordNrs.charAt(Math.floor(Math.random() * wordNrs.length))))); // Same as above except you substract 100 instead of adding 10. This will make the shape roll around the middle shapeCtrX = Math.abs(Math.PI * parseFloat(shapeCtrX + parseInt(wordNrs.charAt(Math.floor(Math.random() * wordNrs.length)))) - 100); shapeCtrY = Math.abs(Math.PI * parseFloat(shapeCtrY + parseInt(wordNrs.charAt(Math.floor(Math.random() * wordNrs.length)))) - 100); } console.log('Used number string to determine polygon shape size: ' + shapeSize + ' X-axis center value: ' + shapeCtrX + ' & Y-axis center value: ' + shapeCtrY + '\n'); Calculating the digital root of the number string After you have successfully set the shape parameters, grab the number string once again and perform a digital root calculation. With this calculation, you will be able to reduce the number string to a single digit, which you will use to determine the number of randomly generated words and in doing so add another layer of randomization: //Reduce number string to single digit with the digital root formula function digitalRoot(input) { var nrStr = input.toString(), i, result = 0; if (nrStr.length === 1) { return +nrStr; } for (i = 0; i < nrStr.length; i++) { result += +nrStr[i]; } return digitalRoot(result); } //Print digital root result digiRoot = digitalRoot(wordNrs); console.log('Calculated digital root of number string: ' + digiRoot + '\n'); Checking if the digital root result is odd or even The digital root result will not be enough as is, however, as you want to output a specific number of words depending on whether the result is odd or even. Once you have determined this, you will use an odd result to generate a set of three words and an even one for a set of two words. This is also the last step of determining parameters, before moving on to the actual image layer generation: //Check if result is odd or even function NrChk(nr) { return nr % 2; } console.log('Checking if digital root is odd or even: ' + NrChk(digiRoot) + '\n'); if (NrChk(digiRoot) > 0) { console.log('Generating 3 random words - digital root is odd\n'); } else { console.log('Generating 2 random words - digital root is even\n'); } Procedural generation layer 1: Text To generate the text layer, you will be using some of the parameters you set up during the previous steps, and run them through the “random-words” library you installed earlier. The first parameter you will be using is the odd/even digital root result you calculated in the last step: // Random generator layer 1: Text //Generate set of random words - 2 for even 3 for odd. Since result will always be 0 or 1 easiest and fastest way is to just add 2. Replace "," with space for natural appeal randomStr = (randomWords(NrChk(digiRoot) + 2).toString()).split(','); console.log('Random words generated are: ' + randomStr + '\n'); This will output a set of unformatted words, which will require a few extra touch-ups to make them truly useful. So, once the unformatted word string is generated, clean it up a bit like so: //Capitalize word set and join them as single string for (var i = 0; i < randomStr.length; i++) { randomStr[i] = (randomStr[i].charAt(0)).toUpperCase() + randomStr[i].slice(1); } wordsOut = randomStr.join(' '); console.log('Capitalizing random words string: ' + wordsOut + '\n'); And with that out of the way, it’s time to run it through the “text-to-image” library, so you can export the results into an image file that will be used as one of the layers. Make sure you have “debug” mode turned on, as otherwise, the image will remain as “dataURI”, instead of the image layer that you need. Feel free to experiment with other parameters within the settings: // Generate image from the random words, while using the library's debug mode to render to file // Exporting images to folders that do not exist yet may cause errors because of FS/OS permissions. Try creating them manually if you encounter such issue. var textPath = './texts/' + idHex + ' ' + wordsOut + ' ' + colorHex + ' [Text Layer].png'; console.log('Exporting random words string as image to: ' + textPath + '\n'); const dataUri = await textToImage.generate(idHex + ' ' + wordsOut, { debug: true, debugFilename: textPath, maxWidth: 330, customHeight: 33, fontSize: 18, fontFamily: 'Arial', lineHeight: 22, margin: 5, bgColor: bgColorHex, textColor: colorHex, textAlign: 'center', verticalAlign: 'top', }); Procedural generation layer 2: Icon The icon layer is quite straightforward when comparing it with the others. To generate it you mainly need two parameters – the icon size and the icon seed, which is a string input. The icon size you will use is 350px, so go ahead and set that in the settings, while selecting the formatted random words string as seed: // Random generator layer 2: Icon // Set icon parameters var iconSize = 350; var iconSeed = wordsOut; Once that is done, all you have to do is export the generated icon to an image and in doing so create the second layer of procedural generation: // Export icon to png const iconExport = jdenticon.toPng(iconSeed, iconSize); var iconPath = './icons/' + idHex + ' ' + wordsOut + ' ' + colorHex + ' [Icon Layer].png'; console.log('Using random words string as seed to generate icon at: ' + iconPath + '\n'); fs.writeFileSync(iconPath, iconExport); Procedural generation layer 3: Shape The last of the procedural generation layers is the shape and to create it successfully you will be using the “canvas” module. As mentioned previously, your dimensions parameters are 350×350, so make sure you have set these correctly for your canvas object. Additionally, since the generated image will be a 2D visual, go ahead and set that, as well: // Random generator Layer 3: Shape // Create new canvas object and set the context to 2d const shapeCanvas = new Canvas (350, 350); const shapeContext = shapeCanvas.getContext('2d'); Once that is done, it is time to start drawing the shape. To do that, start drawing with the “beginPath()” function, followed by four points outlined in the following formula for maximum randomization. The formula uses a combination of every shape parameter you have laid out previously, and running it through various calculations: // Start drawing path on canvas console.log('Using polygon settings to draw path points & paint shape...\n'); shapeContext.beginPath(); // Pick four incomprehensively generated points for the drawing path. Feel free to play around with the formula until you get desireable results shapeContext.moveTo (shapeCtrX + shapeSize * (Math.floor(Math.random() * 100 * Math.cos(shapeSides))), shapeCtrY + shapeSize * (Math.floor(Math.random() * 10 * Math.sin(shapeSides * shapeSize))), shapeCtrX + shapeSize * (Math.floor(Math.random() * 1000 * Math.tan(shapeCtrY * shapeSides))), shapeCtrY + shapeSize * (Math.floor(Math.random() * (1 / Math.tan(shapeCtrX * shapeSides))))); We will not be getting into the details of the formula itself, as that is beyond the scope of the tutorial, but you can feel free to experiment with its values should you want to expand on its randomization factors. Even so, it is still relevant to know what the formula does in its essence, which is to set four points on the canvas, which will be connected with the following “for loop”: // Connect the path points according to randomly picked number of sides for the polygon for (var i = 1; i <= shapeSides;i++) { shapeContext.lineTo (shapeCtrX + shapeSize * Math.cos(i * 2 * Math.PI / shapeSides), shapeCtrY + shapeSize * Math.sin(i * 2 * Math.PI / shapeSides)); } With the four points of the shape connected, you can go ahead and finalize the polygon by closing the path and selecting the parameters for its styling, which you already generated earlier: // Close drawing path to complete the drawn object then proceed with applying border width and color, as well as fill color shapeContext.closePath(); shapeContext.strokeStyle = shapeStroke; shapeContext.fillStyle = shapeFill; shapeContext.fill(); shapeContext.lineWidth = shapeSides; shapeContext.stroke(); As the last step for this stage, all that’s left to do is to export the generated polygon shape to an image, using the following code segment: // Record shape data URI to image buffer then render to preferred path const shapeBuffer = shapeCanvas.toBuffer("image/png"); var shapePath = './shapes/' + shapeSides + ' ' + shapeStroke + '.png'; console.log('Exporting polygon shape as image to: ' + shapePath + '\n'); fs.writeFileSync(shapePath, shapeBuffer); Merging the three image layers Once you have all three image layers successfully generated to their corresponding folders, it is time to merge them into one. To accomplish this, you will be using the “merge-images” module that you installed in the previous step in addition to the path variables that were set at each generation stage: // Merge existing layers by combining them in image buffer as data URI then output to file var mergePath = './merged/' + idHex + ' ' + wordsOut + ' ' + colorHex + ' [Merged].png'; console.log('Merging all layers & exporting image to: ' + mergePath + '\n'); mergeImages([shapePath, iconPath , textPath], { Canvas: Canvas, Image: Image }).then(function (response) { ImageDataURI.outputFile(response, mergePath) }); Uploading the merged image to IPFS To make it easier to upload to IPFS and allow for faster fetching of newly uploaded data, you will be using Pinata’s pinning service. If you don’t have an account on the platform already, then this is a good time to make up for it and create one. Once you have created it, click on your avatar in the top right corner and select “API keys.” Create a new API key with the “Admin” option ticked and copy the “JWT (secret access token)” field to a safe location for now. In your case that would be the “.env” file or the Vault WebUI, accordingly, resulting in a key-value pair like this: PINATA_JWT="Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IlpXVCJ9.eyJ1c2VySW5mb3JtYXRpb24iOnsiaWQiOiI5NWZlN2E1Ni1lYjBhLTQzYTItYmFmZCo1ZjEyZDkyZDBlMmYiLCJlbWFpbCI6InBldGFyLmkuc3RveWtvdkBnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwicGluX3BvbGljeSI6eyJyZWdpb25zIjpbeyJpZCI6IkZSQTEiLCJkZXNpcmVkUmVwbGljYXRpb25Db3VudCI6MX0seyJpZCI6Ik5ZQzEiLCJkZXNpcmVkUmVwbGljYXRpb25Db3VudCI6MX1dLCJ2ZXJzaW9uIjoxfSwibWZhX2VuYWJsZWQiOmZhbHNlLCJzdGF0dXMiOiJBQ1RJVkUifSwiYXV0aGVudGljYXRpb25UeXBlIjoic2NvcGVkS2V5Iiwic2NvcGVkS2V5S2V5IjoiYTFjMTNhMDdkMmFiNDIxOGE0ODkiLCJzY29wZWRLZXlTZWNyZXQiOiJjYmYzYjFkMGM3YzdiYmY5MmQzZTZhOTNhNjU2OTEzODQwMWFjMmE3ZTY2OTNjNTI2YjU4MTRiODM3YmFjZWFmIiwiaWF0IjoxNjYwNjIyOTc4fQ.dNXeLnIlekbnXx7gU36-FGVBn9UeiS_ARKQjI6m2CU0" Do note that you will need to add “Bearer,” followed by an interval before you paste your JWT token. Also keep in mind that the above JWT will not work, as some characters have been changed to protect the actual token and is just there as a formatting tip. Once you have set up the JWT in the “.env” file, don’t forget to reference it in your “generate.js” file like so: const pinataJWT = process.env.PINATA_JWT With this taken care of, it’s time to begin uploading with the following code segment. You will be using the FormData module, to set some basic file metadata for your upload to be made available on IPFS: const addFile = async (source) => { console.log('Attempting to upload ' + source + ' via Pinata to IPFS...\n'); const url = "https://api.pinata.cloud/pinning/pinFileToIPFS"; const src = source; var status = 0; var data = new FormData(); data.append('file', fs.createReadStream(src)); The above will set the settings for your IPFS upload but there is still more to take care of, before it is complete. That is why as a next step, you will be setting your access credentials for the Axios module by using the “JWT” token you copied earlier: //Set Pinata API access credentials and use it for the Axios configuration var config = { method: 'POST', url: url, headers: { "Content-Type": 'multipart/form-data; boundary=${data._boundary}', "Authorization": pinataJWT, ...data.getHeaders() }, data: data }; Axios is essentially an HTTP request parser. Without it, you won’t be able to upload the data you need to IPFS. And once you have set the data you want uploaded in the previous code segment, as the final last step submit the Axios request. Don’t forget to ask for a receipt and close the “addFile()” function, while giving ample time for the merging to complete: // Submit Axios request and wait for it to finish const response = await axios(config); console.log(response.data); // Get receipt for the image IPFS link from the Axios response ipfsPath = 'https://gateway.pinata.cloud/ipfs/' + response.data.IpfsHash; console.log(source.slice(9) + ' successfully uploaded to: ' + ipfsPath + '\n'); console.log('Allowing time for file propagation...\n'); return ipfsPath; }; setTimeout(() => { addFile(mergePath) }, 5000) Since the entire operation is composed of several layers within one function, you can refer to the complete code segment here: const addFile = async (source) => { console.log('Attempting to upload ' + source + ' via Pinata to IPFS...\n'); const url = "https://api.pinata.cloud/pinning/pinFileToIPFS"; const src = source; var status = 0; var data = new FormData(); data.append('file', fs.createReadStream(src)); //Set Pinata API access credentials and use it for the Axios configuration var config = { method: 'POST', url: url, headers: { "Content-Type": 'multipart/form-data; boundary=${data._boundary}', "Authorization": pinataJWT, ...data.getHeaders() }, data: data }; // Submit Axios request and wait for it to finish const response = await axios(config); console.log(response.data); // Get receipt for the image IPFS link from the Axios response ipfsPath = 'https://gateway.pinata.cloud/ipfs/' + response.data.IpfsHash; console.log(source.slice(9) + ' successfully uploaded to: ' + ipfsPath + '\n'); console.log('Allowing time for file propagation...\n'); return ipfsPath; }; setTimeout(() => { addFile(mergePath) }, 5000) Creating the metadata JSON Now that the image is uploaded to IPFS, it is time to use its CID in the metadata JSON too. But you don’t have a JSON file already, so what needs to be done first is to create a data object called “dataObj.” Since uploading to IPFS and seeing the changes go live may take some time, make sure you give it some leeway by creating a waiting function for it too: // Create the metadata JSON after making sure the image is already uploaded setTimeout(() => { var dataObj = { name: '#' + idHex + ': ' + wordsOut, image: ipfsPath, description: 'A programmatically generated NFT with metadata seeds. Words: ' + wordsOut + ', Color: ' + colorHex + ', Digital Root: ' + digiRoot }; Once you have created the data object, it is time to write it to file using the “fs” file system module. To do that you will need to convert the JSON object to a string using the “JSON.stringify” function. Keep in mind that this is part of the overarching code segment, which has not been closed as of yet: // Convert the metadata JSON array into string so you can write it to file console.log('Attempting to create JSON metadata file...\n'); var jsonObj = JSON.stringify(dataObj); fs.writeFile('./' + idHex + ' ' + wordsOut + ' ' + colorHex + '.json', jsonObj, 'utf8', function(err) { if (err) throw err; jsonPath = './json/' + idHex + ' ' + wordsOut + ' ' + colorHex + '.json'; console.log('JSON metadata file created at: ' + jsonPath.slice(2) + '\n'); With that successfully out of the way, you can go ahead and close the code segment by calling the “addFile(),” and then the “startMint()” functions, while giving ample waiting time for their prerequisites to complete: // Upload the metadata JSON to IPFS after waiting for the file to be created setTimeout(() => { addFile(jsonPath); }, 10000) // Give ample time for the IPFS uploads to propagate or risk minting empty NFTs setTimeout(() => { startMint(); }, 20000) }); }, 10000) And once again, to make sure the entire code segment is written correctly, you can refer to its complete state here: setTimeout(() => { var dataObj = { name: '#' + idHex + ': ' + wordsOut, image: ipfsPath, description: 'A programmatically generated NFT with metadata seeds. Words: ' + wordsOut + ', Color: ' + colorHex + ', Digital Root: ' + digiRoot }; // Convert the metadata JSON array into string so you can write it to file console.log('Attempting to create JSON metadata file...\n'); var jsonObj = JSON.stringify(dataObj); fs.writeFile('./json/' + idHex + ' ' + wordsOut + ' ' + colorHex + '.json', jsonObj, 'utf8', function(err) { if (err) throw err; jsonPath = './json/' + idHex + ' ' + wordsOut + ' ' + colorHex + '.json'; console.log('JSON metadata file created at: ' + jsonPath.slice(2) + '\n'); // Upload the metadata JSON to IPFS after waiting for the file to be created setTimeout(() => { addFile(jsonPath); }, 10000) // Give ample time for the IPFS uploads to propagate or risk minting empty NFTs setTimeout(() => { startMint(); }, 20000) }); }, 10000) Submitting the minting transaction This is the final part of the procedural NFT generation and if you have followed the previous tutorial on the subject, it should be far from foreign for you. First, you need to set the transaction parameters as follows: // Set the parameters of the minting transaction then sign it for processing const contractObj = new web3.eth.Contract(contractNFT, contractAdrs) const startMint = async (tokenId) => { console.log('Attempting to mint to address: ' + address + '\n'); const mintTX = await web3.eth.accounts.signTransaction( { from: address, to: contractAdrs, data: contractObj.methods.safeMint(address, ipfsPath).encodeABI(), gas: '2968862', }, privKey ); Once you have set the parameters, go ahead and submit the transaction with the following code segment, while making sure you ask for a receipt in doing so: // Ask for a receipt of your transaction const createReceipt = await web3.eth.sendSignedTransaction( mintTX.rawTransaction ); console.log('NFT successfully minted. Here is your receipt: ', createReceipt); setTimeout(() => { console.log("\nThank you for using Petar's Procedural Minter!"); }, 3000) }; }; And to close the curtains on everything successfully, don’t forget to call the overarching “generator” function: // Don't forget to run the entire process! generator(); Here’s how the entire minting function should look like in your code: // Set the parameters of the minting transaction then sign it for processing const contractObj = new web3.eth.Contract(contractNFT, contractAdrs) const startMint = async (tokenId) => { console.log('Attempting to mint to address: ' + address + '\n'); const mintTX = await web3.eth.accounts.signTransaction( { from: address, to: contractAdrs, data: contractObj.methods.safeMint(address, ipfsPath).encodeABI(), gas: '2968862', }, privKey ); // Ask for a receipt of your transaction const createReceipt = await web3.eth.sendSignedTransaction( mintTX.rawTransaction ); console.log('NFT successfully minted. Here is your receipt: ', createReceipt); setTimeout(() => { console.log("\nThank you for using Petar's Procedural Minter!"); }, 3000) }; }; Outcome With all the steps complete successfully you should now be the proud owner of a newly minted NFT that was brought forward entirely by procedural generation using code. And the best thing about it? All you need to do to mint some more is run the “generate.js” script. Here are some of the best results accomplished using the same tutorial code base, whose repo you can find here: Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to deploy a blockchain node in minutes – Get started with Chainstack Despite all the ups and downs that are a given in the space, Web3 is here to stay. And not only has it become a permanent fixture in the minds of developers and users alike, but it is also well on its way to disrupting the entire internet as we know it. This makes it a perfect time for you to join in the fun with fellow BUIDLers. Fortunately for everyone involved, Web3 is far from being in that raw form that it once was. Quite the contrary—it is more accessible than it ever was, creating a ton of exciting opportunities for you to leverage. So, what’s stopping people? In reality, one of the toughest barriers to entry for plenty—infrastructure, still remains. And considering just how difficult it is to run and manage your own nodes, that comes as no surprise. The good news about this, however, is that things are changing and for the better, as we are about to see. But first—let’s take a closer look at just what makes running a node such a hassle. Why is running a node difficult?  Much like running your very own server, running a node does come with a lot of responsibility. One of the first major differences between the two, however, can be found in just how long it can take to get a node up and running.   While deploying is a relatively straightforward process, node synchronization can take days, or even weeks, depending on the writing speed of your hard drive and other technical factors involved in the process. This is an absolute nightmare and a total buzzkill for any eager developer that wants to get started. But even if you have the patience of a Buddhist monk and don’t mind that much of a wait, there is more trouble for you in store. Having a healthy node requires you to perform regular updates, which can even ask you to rebuild everything from scratch, every once in a while. Talk about pain. The same applies to the plethora of reasons behind your node(s) falling behind and desynchronizing. And should you allow such issues to plague your setup, get ready for an overwhelming wave of downtime and interruptions to the user experience, due to the dread of unsynchronized nodes.  Scaling node operations makes it worse These issues are further exacerbated, once you start scaling up your project and have to do the same with infrastructure as well. Running a single node for your educational project is fine in comparison, but things really get complicated, once you have to maintain the health of multiple nodes and perform more complex interactions.  That is especially true, when running nodes on-premises, as you effectively place the overwhelming burden of administering everything successfully on your shoulders. This means more waiting, more painstaking debugging, and basically very little time for you to focus on what truly creates value—developing your Web3 application.   Knowing this, it’s time to draw the bottom line and evaluate the pitfalls you will be facing when running your own on-premises node:  Synchronizing nodes can take an unreasonable amount of time. Successfully running a node means more time spent on updates and maintenance. A single node timeout can throw a wrench in your entire endeavor. Nodes can desynchronize, causing a cascade of issues, even if you don’t make any mistakes. Maintaining a stable setup of multiple nodes can be incredibly difficult to do. Heavy network traffic can destabilize even the most robust setup. Introducing Chainstack – the painkiller for all your Web3 woes  While these challenges can easily seem like the end of the world for many new developers, your Web3 experience doesn’t have to be that traumatic. Quite the contrary—as mentioned previously, the space is far from its raw form and there are plenty of useful tools you can use at your disposal to make things much more pleasant.  And that is where Chainstack comes into play. As a developer, who just wants to focus on building a cool DApp, Chainstack can truly be a lifesaver. The platform serves, as a Node-as-a-Service provider, with the primary goal of making your BUIDLer experience as pleasant as possible. It serves as a “control panel for blockchains” that operates across a multitude of cloud service providers and supports a wide range of some of the most significant protocols to date. Having a trustworthy infrastructure provider like Chainstack allows you to focus on building freely, taking the entire burden of running your own node setup. This means you can ship to market faster than ever, run and administrate decentralized networks without the DevOps pain that comes with it, whether you are barely making your first steps as a developer, or are part of a powerful enterprise. Why Chainstack? Multi-chain: 14+ blockchain networks    Ethereum, Binance Smart Chain, Avalanche, Polygon, Fantom, Solana, Harmony, StarkNet, Tezos, Bitcoin, Quorum, MultiChain. Multi-cloud: 4 clouds with 7 locations around the world    AWS, GCP, Azure, Virtuozzo clouds, located in US East, US West, Singapore, Tokyo, London, Frankfurt, Amsterdam. Hybrid: Chainstack-hosted, self-hosted, or mix    Freedom of choice for you to run nodes either in Chainstack’s managed clouds, your own managed clouds, or a combination of the two.   Reliable: self-healing infrastructure with >99.9% uptime    3rd-party independent health status checker of the Chainstack’s platform shows more than 99.9% uptime across all services.   Scalable: run any number of nodes and networks, anywhere    Elastic nodes fit growing businesses starting from a few requests to hundreds of million requests. Dedicated nodes fit businesses’ need for unlimited requests. Nodes can serve up to 4000 requests per second, from 1 to unlimited nodes. Affordable: pay only for what you use    Availability of free of charge plan for developers with up to 3M requests a month. Dedicated nodes for an unlimited number of requests for predictable payments. Instant: Get started in minutes and experiment    A node can be run in less than a minute and start serving your business. Support: enterprise-class SLAs and premium customer support   Heard enough? Time for you to start leveraging robust enterprise infrastructure for your Web3 project. So, without further ado, let’s walk you through the steps. Getting Started with Chainstack in 7 easy steps Deploying a node with Chainstack is incredibly swift and straightforward. The entire process from creating an account, all the way to your first interaction with a node takes no more than the time it takes to brew a fresh cup of coffee. That’s especially heart-warming, considering doing everything on your own can take days, if not even more.   And should you find yourself lost somewhere along the way, you can always make use of Chainstack’s documentation directory to find your way back, or to obtain relevant information for your queries here.  Step 1: One small step for man  The first thing you need to do to get started is to create an account. To do that hop on to https://chainstack.com/ and click the “Start for Free” button in the top right corner. Alternatively, you can visit the account creation page from here directly.  Step 2: Entering your details  To create your account, you will need to provide some basic details first. Nothing too fancy—just an email, a password, and your organization. If you are not part of any organization, you can simply type “Developer,” or “Not Available,” for example. Once you have done that, it is time to pick a plan.   This shouldn’t cause any stress for you, however, if you just want to try things out—just select the free Developer plan and enjoy all essential functionalities you will need, without paying a dime. If you are interested in leveraging more powerful features, you can select the paid plan that suits your use case best. For more information about the plans, please refer to our pricing page here.  Step 3: Verification  Once you are happy with your selection, you will be prompted to complete a quick and simple verification procedure. Just input your name and card details and you are ready to go! If you have picked the free Developer plan, don’t worry about incurring charges during this step—your card details will only be used for verification purposes. But should you have chosen one of the paid plans, however, you will be prompted to complete the subscription payment at the end of this step.  Step 4: Creating your first project  With all those pesky account creation details out of the way, you can now make your first step towards deployment – creating your project. Follow the instructions from the dashboard and click the “Get started” button to create a project. In the following pop-up input some identifying information for your project. This information will only be visible to you, so if you are not a perfectionist, you don’t have to worry too much about it.  Step 5: Joining a network  Now that you’ve created your first project, it is time to join a network. Once again click the Get started button and follow the steps in the wizard to select a network and cloud provider. Note that some of the options are only available under certain plans.   Confirm all the details and once you feel ready click the “Join network” button to begin deployment. Keep in mind that it will take some time to completely deploy your node. Fortunately, you won’t have to wait for too long, as the entire process should take no more than a few minutes of your time.  Step 6: Examining your node  Now that your node has been deployed, click on its name to examine it in further detail. Once in the node details screen, you will see three main sections—Details, where you will find some basic information about your node and its settings; Metrics, where you can evaluate relevant performance statistics and KPIs, once your node is running; and last will be Access and credentials, listing all possible node endpoints and how you can access them.  Step 7: Interacting with your node  With the completion of the previous step, you are ready for the fun stuff—making your first interaction with the node you just deployed. In this tutorial, we selected an Ethereum mainnet node to be deployed, so we will be providing the means to interact with one of the same type. No need for any Web3 libraries at this point, just a basic cURL will suffice for interacting with the RPC endpoint (HTTP).    To do that, hop on to the Command Line Interface (CLI) of your choice, like Terminal, for example, and create a directory at a preferred location. Type the following command to begin installing cURL:  npm install curl  Once the installation process is successfully completed, it is time to commit your first interaction. This can be done by inputting the following command:  curl -X POST -H "Content-Type: application/JSON" --data \ '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ https://chainstack-node-endpoint  In doing so, you will invoke the eth_blockNumber method that will fetch you the latest block number, hex-encoded, as a return value:  { "jsonrpc": "2.0", "id": 0, "result": "0xe3acf4"}   Congratulations, you have now made your first interaction with a node!   But your journey doesn’t stop there – quite the contrary, it has only just begun and the time to build is now officially upon you!  Continue learning with our knowledge base And to top it all off, we have a parting gift for you – a collection of tutorials to help you get started, crafted by no other than Chainstack’s very own dedicated knowledge management team. Have a Web3 question that keeps eluding you? Join us on Telegram and Discord to get an answer straight from the experts behind the guides. Here’s what we have arranged for you today:  Web3 guides for newbies Blockchain node providers: What, how, and why – get acquainted with the infrastructure powering Web3. Introduce yourself to the nodes that help secure the network (or don’t), the typical woes that come in interacting with them, and how node providers can alleviate them:  Metamask under the hood series – discover the inner workings of one of the most commonly used Web3 wallet providers out there. Dig into the details behind Metamask’s functionality and learn more about the cryptography, methods, transaction processing, endpoints, and more factors involved in the process with Davide Zambiasi’s tutorial series:  A developer’s guide to the transactions in mempool series – dive deeper into transaction processing on Metamask. See the reasons behind transaction delays after examining the mempool, fees, and nonce values in closer detail with Sethu Raman:  Advanced blockchain tutorials  Tips to handle RPC request errors – make your first steps in debugging on Web3. Secure the knowledge to resolve common errors occurring during interaction with your nodes. Handle promises, duplicate requests, and retrying with ease, with the help of Antonio Ufano’s practical code examples:  Node performance insider – compare how well your node will fare.  Get a better understanding of your node’s performance with a lightweight, hassle-free, plug-and-play-ready EVM analysis tool, developed by Wuzhong Zhu. Explore popular node metrics, like chain ID, network latency, total gas value in the transaction pool, and more:  Blockchain developer walkthroughs  Avalanche subnet series – start your journey into one of today’s leading protocols. Learn the ropes of running your own blockchain network with subnets and understand how to leverage their flexibility in creating the dApp, or chain you always wanted in a seven-part series from Wuzhong Zhu:  How to create an EVM compatible blockchain bridge – escape the siloed digital asset systems. Take your first steps in cross-chain Web3 development by creating your very own means of transferring tokens, and NFTs from one protocol to another with this smart contract tutorial from Antonio Ufano:  Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to deploy a Chainlink node with Chainstack infrastructure for free This article first appeared in Coinmonks. Chainlink nodes are oracles that allow Smart Contracts that reside on the Ethereum Blockchain to interact with external APIs. Prior to the creation of Chainlink nodes, it was impossible for Smart Contract to access these APIs, thus limiting their functionality. The importance of Chainlink nodes cannot be underestimated — smart contracts can now be much more fluid & flexible, allowing it to truly be smart by accessing data sets from outside the blockchain. In this tutorial, we will deploy our own Chainlink node and then seamlessly get it to connect to an Ethereum node created via Chainstack (I work there). This will be done on the Ropsten network. Nodes created by Chainstack only need minutes to fully sync, meaning that your Chainlink node can be quickly deployed as well. Requirements Install Docker-CE A Chainstack node (sign up for free) A PostgreSQL database Node Endpoint Let’s start by getting the websocket endpoint of your Ethereum node. This can easily be obtained from your Chainstack console. If you’re not sure on how to create an Ethereum node on Chainstack, visit my previous tutorial. Take note of the WSS (websocket) endpoint: Endpoints page in the Chainstack console Running your Chainlink node First, let’s create the directory where your Chainlink node will reside. mkdir ~/.chainlink-ropsten Next, create the .env file for the Docker image echo "ROOT=/chainlinkLOG_LEVEL=debugETH_CHAIN_ID=3MIN_OUTGOING_CONFIRMATIONS=2LINK_CONTRACT_ADDRESS=0x20fe562d797a42dcb3399062ae9546cd06f63280CHAINLINK_TLS_PORT=0SECURE_COOKIES=falseALLOW_ORIGINS=*" > ~/.chainlink-ropsten/.env The “LINK_CONTRACT_ADDRESS” variable is set to “0x20fe562d797a42dcb3399062ae9546cd06f63280” , which is the contract address for test Chainlink tokens on the Ropsten testnet. Thus, change this accordingly when using other testnets or mainnet. Since we’re running the Ethereum client on Chainstack and not on a local machine, copy & edit the code below with your WSS endpoint. echo "ETH_URL=WSS_ENDPOINT" >> ~/.chainlink-ropsten/.env where WSS_ENDPOINT is the value obtained from the Chainstack console. Creating a PostgreSQL database For information on how to run a managed PostgreSQL database with popular cloud providers, see Chainlink Docs: Connecting to a Remote Database. If you would like to set up your own PostgreSQL database, follow an example for Ubuntu in Setting up a Chainlink node with an Ethereum node provided by Chainstack. Add your PostgreSQL database connection details to the .env file for the Docker image: echo "DATABASE_URL=postgresql://SUPERUSER:PASSWORD@IP_ADDRESS:PORT/DATABASE_NAME" >> ~/.chainlink-ropsten/.env where SUPERUSER — the PostgreSQL database superuser. PASSWORD — the password for the superuser. IP_ADDRESS — the IP address of the machine where you run your PostgreSQL database. PORT — use the default PostgreSQL port 5432. DATABASE_NAME — the database name you created for the superuser. Starting the node Run the code below in your terminal: cd ~/.chainlink-ropsten && docker run -p 6688:6688 -v ~/.chainlink-ropsten:/chainlink -it --env-file=.env smartcontract/chainlink local n Congratulations, your node should be running! Your terminal window should look something like this: Creation of a Chainlink node Chainlink nodes will manage and use their own Ethereum keys, and will not use the Ethereum keys managed by the Ethereum client. You will be prompted for a password, and this password represents the Ethereum Keystore file used by your Chainlink node. Once you’ve set the node password, you can create the first API user for your Chainlink node. As an API user, you will be able to create new jobs for smart contracts to make API calls to. Once the API user is created, the Chainlink node should receive block headers from the Chainstack Ethereum node: Chainlink listening to Chainstack That’s it! You can also log in to your Chainlink console http://localhost:6688 to add in jobs. Conclusion Feel free to play around and deploy your own jobs and interact with the node. See also a full walkthrough for Ubuntu: Setting up a Chainlink node with an Ethereum node provided by Chainstack. You can head over to the Chainlink documentation on how to fulfill requests. Explore Chainstack Try Chainstack for free Access our developer resources and community Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to deploy a self-hosted Ethereum node with Chainstack Running your own Ethereum node gives you full control over infrastructure, data locality, and performance. With Chainstack Self-Hosted, you can deploy and manage Ethereum nodes on your own environment using the same control plane experience as Chainstack’s managed offering—without handing over your infrastructure. This guide walks you through deploying a self-hosted Ethereum Hoodi node using Chainstack Self-Hosted, from prerequisites to a running node. Node deployment options There are several common ways to run a self-hosted Ethereum node: Running a node via DIY toolingRunning nodes with Chainstack Self-HostedManaged using self-managed tools and scriptsManaged through a centralized web-based control panelRequires manual configuration, monitoring, and ongoing maintenanceSupports running and operating multiple nodes from a single interfaceTypically used for individual nodes or custom, small-scale setupsProvides centralized visibility and easier operational control The DIY approach works well for custom or small-scale setups, while Chainstack Self-Hosted is better suited for teams that need centralized control, scalability, and consistent node operations. What is Chainstack Self-Hosted? Chainstack Self-Hosted is a control plane for deploying and managing blockchain infrastructure on your own hardware or cloud environment. It lets you run blockchain nodes on premises or in private infrastructure while keeping operational workflows simple and consistent. Key capabilities include: Full infrastructure control over where and how nodes run. Simplified deployment through a web-based control panel. Enterprise-grade architecture built on Kubernetes. Ethereum Mainnet and Testnet support using the Reth execution and Prysm consensus client. At the moment, Chainstack Self-Hosted supports the following Ethereum configurations: Protocol: Ethereum Network: Mainnet, Sepolia, Hoodi Client: Reth + Prysm Node type: Full node Additional protocols and networks are planned for future releases. Ethereum Hoodi node requirements Before starting the deployment, make sure your infrastructure meets the minimum requirements for an Ethereum Hoodi full node. For detailed system requirements, see the full list in the documentation here. ResourceMinimumRecommendedCPU4 cores6+ coresRAM16 GB32 GBStorage250 GB NVMe SSD500 GB NVMe SSD Insufficient resources will significantly increase sync time and may lead to instability during operation. How to run an Ethereum Hoodi node — step-by-step First, install Chainstack Self-Hosted following our installation guide. Step 1: Access the deployment wizard Log in to the Chainstack Self-Hosted Control Panel. Navigate to the Nodes section. Click Add node to start the deployment wizard. This wizard guides you through protocol selection, configuration, and deployment review. Step 2: Select protocol and network Choose Ethereum as the protocol. Select Hoodi as the network. ⚠️ Chainstack Self-Hosted currently supports Ethereum Mainnet,Sepolia and Hoodi Testnets. Step 3: Configure node settings Select the available deployment configuration preset: Ethereum Hoodi Reth + Prysm This preset defines both the execution and consensus clients and applies recommended defaults optimized for performance and stability. Step 4: Review and deploy Review your node configuration and resource allocation. Click Create node to start the deployment. Once confirmed, Chainstack Self-Hosted provisions resources and begins configuring the node automatically. Deployment phases After deployment starts, the node progresses through several phases: PhaseDescriptionDurationBootstrappingResources are allocated, client software is configured2-5 minutesPendingNode synchronizes with the network2-5 daysRunningNode is fully operationalContinuous Initial sync times Initial synchronization time depends on hardware specifications: Hardware tierApproximate sync timeMinimum spec (4 CPU, 16GB RAM, 2TB SSD)3-5 daysRecommended spec (6+ CPU, 32GB RAM, 4TB SSD)2-3 days Snapshot-based deployment to reduce initial sync time is planned for H1 2026. Building on Ethereum? Deploy your Ethereum node on Chainstack → After deployment Once the node reaches Running status: Open the node details page in the Control Panel. Retrieve connection information. Start using the node in your applications for reads, writes, indexing, or internal tooling. ⚠️ Endpoint access Node endpoints are available only from within the Kubernetes cluster. To achieve consistently low latency (around 1 ms), endpoints are exposed internally and are not accessible over the public internet. To use the node, deploy your applications in the same cluster or connect through a private network. At this stage, the node behaves like a production Ethereum full node and runs entirely within your own infrastructure. Production readiness and beta status Chainstack Self-Hosted is currently in beta. It is recommended for: Development and testing environments. Proof-of-concept deployments. Infrastructure evaluation and internal trials. ⚠️ Production readiness is planned for later in 2026. Choosing the right Ethereum RPC approach Deploying a self-hosted Ethereum node no longer requires weeks of manual setup and operational overhead. With Chainstack Self-Hosted, you get a streamlined deployment workflow while retaining full control over infrastructure, data, and network access. If you need Ethereum nodes that meet internal compliance, security, or data residency requirements, Chainstack Self-Hosted provides a practical path to self-managed blockchain infrastructure—without sacrificing usability. In other cases, teams may prefer a managed approach. Getting started with Ethereum on Chainstack is fast and straightforward — deploy a reliable node in seconds through an intuitive console, no hardware or complex setup required. With 99.99% uptime, 24/7 SLA-backed operations and low-latency global endpoints, Chainstack ensures seamless RPC access for building and scaling DeFi, analytics, and trading applications. Deploy Chainstack Self-Hosted → FAQ What is Chainstack Self-Hosted? Chainstack Self-Hosted brings the power of Chainstack’s blockchain infrastructure platform to your own infrastructure. Deploy, manage, and monitor blockchain nodes on your own hardware or cloud environment while maintaining complete control over your data and infrastructure. What are the minimum hardware requirements for a Mainnet node? Ethereum Mainnet node:– 4 CPU cores, 16 GB RAM, 2 TB NVMe SSDControl Panel + Ethereum Mainnet node:– 6 CPU cores, 18 GB RAM, 2+ TB NVMe SSD How do I join the beta program? The beta is open to individual developers and teams running, or planning to run, self-hosted nodes in staging or production environments. We review applications and onboard users in batches to ensure deployment support and collect actionable feedback.Fill out the beta signup form: Join the Chainstack Self-Hosted Beta How long does the initial Ethereum node sync take? Minimum (4 CPU, 16GB, 2TB SSD) – Approximate time 3-5 daysRecommended (6+ CPU, 32GB, 4TB SSD) – Approximate time 2-3 days Related Reading Challenges: Self-hosted blockchain node DIY vs Chainstack Self-Hosted How to run a self-hosted blockchain node on HOSTKEY Chainstack Self-Hosted Docs Ethereum nodes and clients #### How to enable gzip encoding for ethers.js, web3.js and curl About Gzip GNU Gzip is a popular file compression format, for users who often retrieve a huge amount of data from a server, compressing the response with Gzip reduces load time and bandwidth consumption effectively. Gzip has an outstanding 95% compression rate for JSON objects, which makes it a perfect companion for EVM nodes; because basically, all EVM responses are in JSON format and some can be as big as a few MBs. How Gzip works with EVM nodes in a nutshell First of all, you need to check if Gzip is available on your EVM-compatible nodes. Gzip is enabled by default for most Linux machines. In this tutorial, the sample code is developed and tested with a Chainstack endpoint—it is highly recommended for the following reasons: Gzip enabled by default Free 3 million requests. Seamless node deployment. Simply follow these steps to deploy a node: Sign up with Chainstack. Deploy an Ethereum node. Get the deployed node’s endpoint. This is how Gzip works in a nutshell: Figure 1: Gzip interaction process When a sender sends an RPC request to the node/server, a header is attached. In the header, the sender specifies an attribute “Accept-Encoding: gzip”. When the server receives the request, this header attribute lets it know that the client wants the response to be Gzip encoded. The server compresses the data and sends it back to the client. The response is attached with “content-encoding: gzip” in its header. This is to let the receiver knows that the data is encoded with Gzip. It needs to be decoded to retrieve the original data. This is basically how Gzip works. Both client and server need to support this format and they notify each other in the request/response header. Using Gzip in a browser If you are developing a web application with ethers.js or web3.js and you are wondering how to enable Gzip at the frontend, there’s nothing to configure actually.Popular browsers like Chrome and Firefox support Gzip by default. All requests sent are attached with the “Accept-Encoding” header. Both <script src="https://cdn.ethers.io/lib/ethers-5.2.umd.min.js" type="application/javascript"></script> <script> const provider = new ethers.providers.JsonRpcProvider(“your RPC endpoint") provider.send('eth_getBlockByNumber',['0xE6F190',false]) .then(function(block) {console.log(block); } ); </script> And <script src="https://cdn.jsdelivr.net/npm/web3@latest/dist/web3.min.js"></script> <script> const HTTP_ENDPOINT = 'your RPC endpoint' const provider = new Web3.providers.HttpProvider(HTTP_ENDPOINT) const web3 = new Web3(provider) web3.eth.getBlock('0xE6F190').then(function(block) { console.log(block); }); </script> Both work fine. You can check the header in the browser developer’s tool.Request header: Response header: And the response was auto-decoded by the browser. Using Gzip at the backend Enabling Gzip at the backend is more complicated because the header must be specified explicitly. At the time of writing, only ethers.js and curl support Gzip, not web3.js. With Curl: curl https://your-RPC-endpoint/12345 -X POST --data '{"id":1234,"jsonrpc":"2.0","method":"eth_getBlockByNumber", "params":["0xE6F190",false]}' -H "Content-type: application/json;" -H "Accept: application/json;" -H "Accept-Encoding: gzip" -–compressed With ethers.js const options = { allowGzip: "true", url: "your RPC endpoint", }; const provider = new ethers.providers.JsonRpcProvider(options) With web3.js, you can set the header by: const options = { headers: [ { name: 'Content-Type', value: 'application/json', }, { name: 'Accept-Encoding', value: 'gzip', }, ], } const HTTP_ENDPOINT = 'your RPC endpoint' const provider = new Web3.providers.HttpProvider(HTTP_ENDPOINT, options) const web3 = new Web3(provider) web3.eth.getBlock('0xE6F190').then(function(block) { console.log(block); }); However, you will probably receive an error message: Refuse to set unsafe header “Accept-Encoding” This error message is returned by a node module: /node_modules copy/xhr2-cookies/dist/xml-http-request. You can delete this line to force it to attach the header. However, when the response is received, you will receive an invalid response like this. That is a Gzip encoded data. But the receiving end(web3.js) does not know how to decode this response. Therefore it throws an error.To summarise: Figure 2: Libraries support Gzip Performance To show how Gzip can help optimize bandwidth consumption, 3 different EVM RPC methods were compared in their response size. Response size without GzipResponse size with GzipBenchmarkingeth_blockNumber69 Byte45 Byte-34%eth_call297 Byte97 Byte-64%eth_getBlockByHash204 KB26 KB-87% The compression rate increases with the size of the return data. But even for the simplest request, Gzip reduces the data size by more than 30 percent. Conclusion This is the end of this tutorial. Thanks for reading.If you have any questions, feel free to ping me on Twitter/Telegram/Discord.Happy coding. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to get a BNB Smart Chain RPC endpoint (2026 guide) TL;DR BNB Smart Chain RPC endpoints must handle burst traffic, event-heavy workloads, and reliable eth_getLogs access—this guide explains how they work and how to deploy one for production. BNB Chain scalability metrics showing current TPS and block time (source: Chainspect). BNB Smart Chain is one of the highest-throughput EVM networks, producing blocks roughly every 3 seconds and capable of processing up to ~2,000 transactions per second. That performance places unique demands on RPC infrastructure. What is a BNB Smart Chain RPC endpoint A BNB Smart Chain RPC endpoint is your app’s gateway to BNB Chain. It uses the same JSON-RPC interface as Ethereum (eth_call, eth_getBalance, eth_sendRawTransaction) but connects to BNB Chain’s validator network and reflects BNB Chain’s network conditions. Every user-facing blockchain action in your product depends on it: Reading wallet balances Fetching contract state Estimating gas costs Broadcasting signed transactions Monitoring contract events via eth_getLogs That is why endpoint quality directly affects user experience. If your endpoint is slow, your app feels slow. If your endpoint is unstable, transaction flows fail at the worst possible time. How BNB Smart Chain RPC differs from Ethereum RPC WhatBNB Smart ChainEthereumBlock time~3 seconds~12 secondsThroughputUp to ~2,000 TPS~15-30 TPS (L1)Gas tokenBNBETHConsensusProof of Staked Authority (PoSA)Proof of StakeValidator set45 active validatorsThousands of validatorsLog queriesOften restricted on public RPC endpointsGenerally availableTraffic patternsHigh burst activity during market volatilityMore distributed This is exactly why provider selection for BNB Chain should include log access guarantees and burst traffic handling, not just raw RPS limits. BNB Smart Chain RPC endpoint options Choosing the right endpoint is primarily a reliability decision. You’re balancing convenience, cost, and operational risk. Public vs Private BNB Chain RPC endpoints Official public BNB Chain endpoints: Mainnet: https://bsc-dataseed.bnbchain.org Testnet: https://bsc-testnet.bnbchain.org Rate limits: 10,000 requests per 5 minutes (per BNB Chain docs)Critical limitation: eth_getLogs is disabled on public Mainnet endpoints ⚠️ Full public endpoint list is available in the official BNB Chain documentation here. FeaturePublic RPCPrivate RPC (Chainstack)AccessFree and openRestricted accessResourcesShared infrastructureDedicated resourcesPerformanceVariable, rate-limitedStable, high throughputLog queriesDisabled on public MainnetFull eth_getLogs supportWebSocket stabilityLimited guaranteesReliable long-lived connectionsBest use caseDevelopment & testingProduction workloads Public RPC endpoints are useful for testing and experimentation, but treat them as shared community resources. For production workloads—especially DeFi apps, bots, or analytics systems—use an infrastructure RPC provider with eth_getLogs support and clearer performance guarantees. Full node vs Archive BNB Smart Chain node Your data requirements should drive this decision. Full node accessArchive node accessCurrent state queriesHistorical analyticsStandard wallet/dApp interactionsExplorer-like productsTransaction submissionDeep event backfills (via eth_getLogs with wide block ranges)Real-time event monitoringCompliance and reportingLong-range debugging If your product depends on historical state queries or event backfills beyond recent blocks, validate archive availability before launch. HTTPS vs WebSockets Transport choice impacts system behavior, especially at scale. FeatureHTTPSWebSocketModelRequest/responsePersistent connectionComplexitySimple operationallyRequires reconnect/heartbeat logicBest forStandard reads/writesEvent streams, real-time subscriptionsLatencyStandardLower for frequent updatesConnection overheadPer requestOne-time handshake In practice, many teams use HTTPS broadly and add WebSocket subscriptions only where real-time behavior is required (event monitors, bots, live dashboards). If your system depends on live data, test WebSocket stability under load early—don’t assume HTTPS reliability translates to WebSocket reliability. 📖 For a detailed comparison of BNB Smart Chain RPC providers, including performance benchmarks and feature analysis, see Best BNB Chain RPC providers for production use in 2026. How to get a private BNB Smart Chain RPC endpoint with Chainstack Log in to the Chainstack console (or create an account) Create a new project Select BNB Smart Chain as your blockchain protocol Choose network: BNB Smart Chain Mainnet or BNB Smart Chain Testnet Deploy the node Open Access/Credentials and copy your HTTPS and WebSocket endpoints Run a quick connectivity check before wiring it into production code Connect from your application (ethers.js) const { ethers } = require("ethers"); var urlInfo = { url: 'YOUR_CHAINSTACK_ENDPOINT' }; var provider = new ethers.providers.JsonRpcProvider(urlInfo, NETWORK_ID); provider.getBlockNumber().then(console.log); NETWORK_ID — BNB Smart Chain network ID: Mainnet: 56 Testnet: 97 This confirms your app can connect and read live chain data before you integrate more complex logic. 📖 For a full list of BNB Chain-compatible tools including MetaMask, Hardhat, ethers.js, viem, and Foundry, see the Chainstack BNB Smart Chain tooling documentation. Using Chainlist Chainlist can help add BNB Smart Chain to wallets like MetaMask or Rabby, but it is not an infrastructure provider. For BNB Smart Chain, use your provider dashboard and official SDK tooling instead. If you used Chainlist during development, replace any public/community RPC URL with your managed endpoint before launch. Chainstack pricing for BNB Smart Chain RPC Chainstack pricing is request-unit-based and easier to forecast than compute-unit models. PlanCostRequests/MonthRPSOverage (per 1M extra)Developer$03M (~25 RPS)~25$20Growth$4920M~250$15Pro$19980M~400$12.5Business$499200M~600$10EnterpriseFrom $990400M+CustomFrom $5 Advanced options: Unlimited Node add-on: Flat monthly pricing for unmetered usage within RPS tier Dedicated Nodes: From $0.50/hour (+ storage) for isolated high-performance workloads How to estimate monthly cost Forecast average and peak requests/day Convert to monthly request units Add 20–30% buffer for spikes Check if RPS limits match your peak traffic profile Compare shared tier vs dedicated economics at projected scale For BNB Chain specifically: If your app is event-heavy (bots, analytics, DeFi monitors), throughput limits and overage policy matter more than base plan price. Production readiness checklist Before launch, validate these basics: Primary + fallback RPC provider configured Request timeout policy set Retry logic with exponential backoff implemented Chain ID validated at startup (eth_chainId) Credentials stored in env/secret manager (never hardcoded) Monitoring for latency, error rate, and throttling Alerts for sustained degradation eth_getLogs access confirmed (if needed) These controls prevent most avoidable RPC incidents in production. Troubleshooting common BNB Chain RPC issues IssueLikely CauseHow to Fix429 Too Many RequestsShared endpoint saturation or aggressive pollingMove to managed endpoint, reduce polling frequency, batch requestsWrong chain ID returnedApp pointed to Mainnet instead of Testnet (or vice versa)Validate eth_chainId at startup and fail fast on mismatcheth_getLogs failsPublic Mainnet endpoints restrict log accessUse managed endpoint with confirmed log support or switch to WebSocket event streamsWebSocket disconnectsUnstable long-lived connection or provider limitsAdd reconnect logic, heartbeat handling, and missed-event backfillHigh latency spikesRegion mismatch or overloaded shared infrastructureRoute to closer region and enable fallback endpoint Conclusion BNB Smart Chain’s high throughput and EVM compatibility make RPC selection critical. Your provider needs to support burst traffic, reliable eth_getLogs access, and stable WebSocket connections—not just provide basic JSON-RPC uptime. Use public endpoints for prototyping, then move to managed infrastructure with proven BNB Chain support, confirmed log access, and SLA-backed reliability before production launch. Start with Chainstack’s free tier (3M requests/month), validate your query patterns in staging, then scale to dedicated infrastructure as traffic grows. Building on BNB Smart Chain? Deploy your BNB Smart Chain node on Chainstack → FAQ Can I use Ethereum tooling with BNB Smart Chain? Yes. BNB Chain is EVM-compatible, so ethers.js, Web3.js, Hardhat, and MetaMask work with BNB Chain. Just point them to a BNB Chain RPC endpoint instead of Ethereum. How does BNB Smart Chain RPC differ from Ethereum RPC? The JSON-RPC interface is the same, but BNB Chain has faster block times (~3s vs ~12s), different gas pricing, and public endpoints often restrict eth_getLogs access. What SDKs work with BNB Smart Chain RPC endpoints? Most teams use ethers.js or web3.js. Any SDK supporting Ethereum JSON-RPC works with BNB Chain. Can I use MetaMask with BNB Chain? Yes. MetaMask supports BNB Chain as a custom network. Chainlist can help add it quickly. Is a public BNB Smart Chain endpoint enough for production? Usually no. Public endpoints have rate limits, no log access on Mainnet, and no uptime guarantees. Production apps need managed infrastructure. What should I monitor on my BNB Smart Chain RPC layer? Track p95/p99 latency, failure rate, 429 responses, WebSocket reconnect frequency, and block lag. For event-heavy apps, monitor log delivery and backfill success. Additional resources BNB Chain Official JSON-RPC endpoints documentation BNB Chain Chainstack tooling BNB Smart Chain: BEP-1155 contract with Truffle & OpenZeppelin Best BNB Chain RPC providers in 2026 Compare Dashboard now tracks Arbitrum and BNB Smart Chain #### How to get a Gnosis Chain RPC endpoint (2026 tutorial) TL;DR The Gnosis Chain team openly warns developers that their official public RPC at https://rpc.gnosischain.com comes with no SLA or availability guarantees — yet most guides send you there first. For a chain designed to run always-on payments, DAO tooling, and prediction markets that can’t afford downtime, that’s a mismatch worth addressing before you write a single line of production code. This guide covers every endpoint option for Gnosis Chain mainnet and Chiado testnet, explains why xDAI as the gas token changes your infrastructure assumptions, and shows you how to deploy a private endpoint in minutes. What is a Gnosis Chain RPC endpoint Gnosis Chain runs a standard Ethereum JSON-RPC API — the same eth_* methods, the same ABI encoding, the same familiar tooling. An RPC endpoint is the HTTPS or WebSocket URL your application sends those JSON-RPC calls to, whether it’s asking for the current block number, reading a multisig Safe’s pending transactions, or broadcasting a new CoW Protocol batch order. What depends on the endpoint on Gnosis Chain specifically: Reading xDAI balances and ERC-20 token balances across 145,000+ validator addresses Querying conditional token contract states for prediction market outcomes Calling Safe multisig contract methods to read pending confirmations and transaction queues Emitting and listening to eth_getLogs events from DeFi protocols (CoW Protocol, Curve, Balancer, Gnosis Pay) Broadcasting transactions to the mempool for inclusion in the next ~5-second block Fetching historical event logs for governance participation tracking and treasury analytics Running eth_call simulations for smart contract interactions before on-chain execution The quality difference between a public and a private endpoint on Gnosis Chain is more consequential than it looks on paper. Because Gnosis is designed as a home for always-on coordination infrastructure — Safe wallets, DAO voting, payment streams — an endpoint that stumbles at 50 concurrent requests can silently degrade the user experience of products that were built assuming reliable, low-latency responses. 📖 You can review the full list of supported JSON-RPC methods in the Ethereum JSON-RPC API reference — Gnosis Chain implements the same standard API. How Gnosis Chain RPC differs from Ethereum RPC Gnosis Chain is EVM-compatible and implements the standard Ethereum JSON-RPC spec — but its chain parameters create meaningful differences that affect how you select and configure your RPC provider. PropertyEthereum MainnetGnosis ChainBlock time~12 seconds~5 secondsGas tokenETH (volatile)xDAI (USD-pegged stablecoin)Chain ID1100ConsensusPoS (Beacon Chain)PoS (Gnosis Beacon Chain)Finality~12.8 min (2 epochs)~2.5 min (faster epoch)Validator minimum32 ETH1 GNOTypical feeVariable ($1–$100+)Sub-cent (< $0.001) The two differences that matter most for RPC provider selection are the faster block time and the stablecoin gas model. At 5-second blocks, polling-based architectures generate roughly 2.4× more RPC requests against your plan quota than the same code running against Ethereum. And because fees are denominated in xDAI rather than ETH, any app doing fee estimation or gas display needs to understand it’s working in a stablecoin context — not a volatile asset — which changes how you surface cost data to users. Gnosis Chain RPC endpoint options Public vs private Gnosis Chain RPC endpoints Gnosis is designed for the kind of applications that keep running — Safe wallets processing treasury transactions, prediction markets tracking outcomes, payment systems settling micro-transactions. A shared public endpoint, by definition, cannot guarantee that your application’s requests won’t be queued behind someone else’s. Official public endpoints: Mainnet: https://rpc.gnosischain.com Mainnet (Gateway): https://rpc.gnosis.gateway.fm Chiado Testnet: https://rpc.chiadochain.net Chiado Testnet (Gateway): https://rpc.chiado.gnosis.gateway.fm ⚠️ The Gnosis Core Team explicitly states that the official public RPC carries no SLA or availability guarantees. For production deployments — including Safe wallets, DAO tooling, or any payment-critical application — the Gnosis docs themselves recommend using professional RPC providers. Additionally, because Gnosis Chain is on Chainlist, any endpoint you find there should be treated as a discovery tool, not a production configuration. Replace Chainlist URLs with a managed endpoint before going live. FeaturePublic endpointPrivate endpointAccessFree and openRestricted accessResourcesShared infrastructureDedicated resourcesBest use caseDevelopment & testingProduction workloadsAvailability guaranteeNone (no SLA)Contractual uptime SLAWebSocket supportLimited/unstableAvailableArchive data accessNot availableAvailable For chains designed to host always-on coordination infrastructure, a shared endpoint with no SLA is the one configuration that contradicts Gnosis Chain’s entire reliability premise. Full node vs archive Gnosis Chain node Gnosis Chain’s most important use cases — DAO governance participation tracking, prediction market resolution, Safe wallet historical audit trails — all require looking back at historical state. Knowing which node type you need is the difference between a query that returns in milliseconds and one that silently fails. Full node accessArchive node accessCurrent xDAI and ERC-20 balancesHistorical balance at any past blockReal-time Safe multisig transaction monitoringComplete transaction history for governance audit trailsActive prediction market contract statePast conditional token resolution events via eth_getLogsLive CoW Protocol batch order broadcastingHistorical DEX trade data for analytics and complianceCurrent validator set and staking stateFull event log history for on-chain DAO voting recordsLatest block data and mempool accesseth_getStorageAt calls against historical block numbers Chainstack supports archive nodes for Gnosis Chain. If you’re building governance analytics, compliance tools, or any application that needs to reconstruct the full history of Safe wallet approvals or prediction market outcomes, archive access is not optional. HTTPS vs WebSockets On a 5-second block chain, persistent WebSocket connections earn their overhead cost faster than on Ethereum. If your application subscribes to eth_subscribe for new blocks or pending transactions, you’ll see a WebSocket connection re-established every 24 blocks or fewer on Gnosis — connection overhead matters. FeatureHTTPSWebSocketModelRequest/responsePersistent connectionComplexitySimple operationallyRequires reconnect/heartbeat logicBest forSafe transaction reads, contract calls, one-off queriesReal-time block subscriptions, eth_subscribe for log events, CoW Protocol order status monitoringLatencyStandardLower for frequent updatesConnection overheadPer requestOne-time handshake WebSocket support is limited or unreliable on public Gnosis endpoints. For any production application subscribing to on-chain events, a managed provider with stable WebSocket infrastructure is the only viable path. How to get a private Gnosis Chain RPC endpoint with Chainstack Chainstack provides Gnosis Chain nodes for both Mainnet and Chiado Testnet, with WebSocket endpoints and archive data access available on paid plans. Log in to the Chainstack console (or create a free account) Create a new project Select Gnosis Chain as your blockchain protocol Choose network: Gnosis Mainnet or Chiado Testnet Deploy the node Open Access & Credentials and copy your HTTPS and WebSocket endpoints Run a quick connectivity check with eth_blockNumber before wiring it into production code Here’s a quick connection check using ethers.js: const { ethers } = require("ethers"); // Connect to your Chainstack Gnosis Chain endpoint const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT", { chainId: 100, // Gnosis Chain mainnet chain ID name: "gnosis" }); async function checkConnection() { const blockNumber = await provider.getBlockNumber(); console.log("Latest Gnosis Chain block:", blockNumber); // Check xDAI balance of an address const balance = await provider.getBalance("0x0000000000000000000000000000000000000001"); console.log("Balance (xDAI):", ethers.formatEther(balance)); } checkConnection(); // Requires ethers v6. For v5, use ethers.providers.JsonRpcProvider instead. 📖 For the full integration guide, see the Chainstack Gnosis Chain tooling documentation. Chainstack pricing for Gnosis Chain RPC Chainstack’s pricing model bills per request regardless of method type — no compute-unit multipliers, no per-method surcharges. See the full Chainstack pricing page for plan details and overage rates. PlanCostRequests/MonthRPSOverage (per 1M extra)Developer$03M (~25 RPS)~25$20Growth$4920M~250$15Pro$19980M~400$12.5Business$499200M~600$10EnterpriseFrom $990400M+CustomFrom $5 Advanced options: Archive Node add-on — for historical state access, governance analytics, and compliance workloads Unlimited Node add-on — for request-intensive production workloads Dedicated Nodes: From $0.50/hour (+ storage) How to estimate monthly cost Estimate your daily active users or bots interacting with the chain Count RPC calls per session: Safe reads, log queries, contract calls, transaction broadcasts Multiply by 30 for monthly volume Compare against plan request allocations Gnosis-specific note: At 5-second blocks, automated systems polling for new blocks will consume ~17,280 requests per day per poller — factor this in separately from user-driven traffic. A governance bot polling every block can exhaust a Developer plan’s daily allocation in under three hours. Production readiness checklist Primary + fallback RPC provider configured Request timeout policy set (recommended: 10s for standard calls) Retry logic with exponential backoff implemented Credentials stored in env/secret manager (never hardcoded) Monitoring for latency, error rate, and throttling Alerts for sustained degradation WebSocket reconnect logic with missed-event backfill for eth_subscribe consumers Chain ID validation (100 for mainnet, 10200 for Chiado) — prevents accidental cross-chain transaction submission eth_getLogs query window tested against your provider before launch — some endpoints cap the block range per query Use Chainstack Compare to benchmark endpoint latency before choosing a provider Troubleshooting common Gnosis Chain RPC issues IssueLikely CauseHow to Fix429 Too Many RequestsHitting rate limits on public or shared endpointMove to a managed endpoint with higher RPS limitsWebSocket disconnects mid-sessionPublic WS endpoints are unstable; no heartbeatImplement reconnect logic with exponential backoff; use a private endpoint with stable WSeth_getLogs returns empty results despite events existingBlock range too wide; some providers cap at 1,000–10,000 blocks per queryPaginate your log queries; verify provider’s block range limitsTransaction broadcast succeeds but doesn’t confirmInsufficient xDAI for gas, or gas price below current basefeeCheck xDAI balance; use eth_gasPrice to set appropriate gas; don’t hardcode gas valuesinvalid chain ID error when signingWallet or signer configured for Ethereum (chain ID 1) instead of Gnosis (chain ID 100)Explicitly set chainId: 100 in your provider configurationStale state returned from eth_callFull node hasn’t synced to latest; using outdated block tagUse "latest" as block parameter; verify node sync status with eth_syncing Conclusion A public Gnosis Chain endpoint that goes down during a governance vote isn’t just an inconvenience — it’s a failed quorum, a Safe transaction that can’t be confirmed, a prediction market settlement that hangs. The Gnosis Chain team documents this risk explicitly: their own public RPC carries no availability guarantee. For a chain built around coordination infrastructure that must keep running, that’s the configuration that breaks the most silently and costs the most to diagnose. The pattern that works: start with a managed endpoint from day one, even on the Developer free tier. Configure a fallback provider. Implement WebSocket reconnect logic before you need it — not after your first production incident. Archive access isn’t optional if your application reads historical Safe transactions or past governance outcomes. Start building with Chainstack → FAQ What SDKs work with a Gnosis Chain RPC endpoint? Any Ethereum-compatible library works unchanged on Gnosis Chain. ethers.js, web3.js, viem, web3.py, and Foundry all connect by pointing at a Gnosis Chain endpoint with chainId: 100. The only adjustment required is ensuring you’re using xDAI for gas estimation rather than ETH — the API surface is identical. Is the official public RPC sufficient for a production dApp? No. The Gnosis Chain documentation explicitly states the official public RPC comes with no SLA or availability guarantees. For any application where downtime has real consequences — Safe multisig wallets, active DAO voting periods, payment streams — you need a managed endpoint backed by an uptime commitment. The public endpoint is appropriate for local development and initial testing only. Why does my polling bot exhaust RPC quota so quickly on Gnosis Chain? Gnosis Chain produces a block every ~5 seconds, roughly 2.4× faster than Ethereum’s 12-second blocks. An automated system that calls eth_blockNumber or eth_getBlockByNumber on every new block generates 17,280 requests per day — before any actual application logic runs. Structure your bot to batch calls where possible, use WebSocket subscriptions instead of polling where available, and account for this baseline consumption when sizing your plan. Do I need archive access for Safe wallet integrations? It depends on your use case. If you only need to display current pending transactions and check current multisig state, a full node is sufficient. If you need to reconstruct a complete transaction history, audit past approvals, or backfill historical Safe events for compliance or analytics purposes, you need archive access. Most serious Safe integrations eventually require archive — plan for it early. Can I use Chainlist to configure Gnosis Chain in MetaMask for production? Chainlist is a useful discovery tool for adding Gnosis Chain to wallets, but any RPC URL sourced from Chainlist should be replaced with a managed private endpoint before going to production. Public endpoints listed on Chainlist are community-submitted and carry no reliability guarantees. What’s the difference between Gnosis mainnet and Chiado testnet? Chiado (Chain ID: 10200) mirrors Gnosis mainnet parameters — same 5-second block time, same xDAI gas token, same EVM compatibility — making it a high-fidelity staging environment. Chiado runs a semi-permissioned validator set managed by Nethermind, Gateway, and the Gnosis team for stability. Use Chiado for smart contract deployments, bridge testing, and pre-production validation before mainnet release. Testnet xDAI is available from https://faucet.chiadochain.net/. Additional resources Simple soulbound token with Remix and OpenZeppelin on Gnosis Chain Chainstack Gnosis Chain tooling documentation Gnosis Chain official documentation More Gnosis Chain tutorials and articles on the Chainstack Blog Gnosis Chain developer tutorials #### How to get a Hyperliquid RPC endpoint Learn how to get a Hyperliquid RPC endpoint for both mainnet and testnet, choose between public and private options, and set up a reliable RPC provider. TL;DR Hyperliquid is an L1 with a native order book and an EVM-compatible execution layer (HyperEVM). As usage grows, public HyperEVM RPC access is increasingly constrained for high-frequency workloads. Starting August 9 2025, public HyperEVM RPC is rate-limited to 100 requests/minute per IP. That is usually fine for testing and light reads, but it is a bottleneck for bots, indexers, and latency-sensitive systems. This guide explains: Public vs private Hyperliquid RPC access. Full vs archive node trade-offs. How to get a private endpoint for production workloads. How to use official public endpoints for testing. Hyperliquid API endpoint cheat sheet Use this as a quick integration reference for HyperEVM RPC access. Endpoint format Mainnet public RPC (read-only): https://rpc.hyperliquid.xyz/evm Testnet public RPC (read-only): https://rpc.hyperliquid-testnet.xyz/evm Private RPC pattern: https://<your-rpc-host>/evm Optional private info endpoint: https://<your-rpc-host>/info Auth header pattern Public endpoints: no auth header. Private endpoints (provider-specific):Authorization: Bearer <API_TOKEN>orx-api-key: <API_KEY> Minimal cURL ```bash curl -sS https://rpc.hyperliquid.xyz/evm \ -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' What is a Hyperliquid RPC endpoint? A Hyperliquid RPC endpoint lets you read data from the HyperEVM (the chain’s EVM-compatible execution layer) over HTTP.  If you’ve worked with Ethereum, this will feel familiar: the HyperEVM implements a subset of the standard JSON-RPC API used across EVM chains. Hyperliquid runs two execution environments under one consensus: HyperCore, the trading engine that handles the order book and exchange logic, and HyperEVM, the smart contract layer. RPC endpoints only expose the EVM layer. Trading actions are routed through a separate API path with different capabilities. When you send a request to a Hyperliquid RPC endpoint, you’re querying data or simulating state transitions from the HyperEVM. The RPC is used to read contract state, check balances, fetch logs, and simulate calls, but not to send transactions. Execution happens off-path, through a separate submission layer that functions more like a sequencer than a traditional mempool. Hyperliquid RPC layer is designed to support bots, dashboards, indexers, and other offchain infra that rely on fast, consistent access to chain data. This makes the choice of RPC provider (or the decision to self-host) especially important if you’re building production infrastructure. Public vs private Hyperliquid RPC endpoints There are two ways to access the HyperEVM RPC: through the public endpoint maintained by the core team, or via a private RPC, either self-hosted or through a provider like Chainstack. Public RPCPrivate RPCFree and open to everyonePaid service (self-hosted or managed)Rate-limited to 100 requests/minute (as of August 9)No rate limits or much higher limitsShared infrastructureDedicated infrastructureBest for: prototyping, occasional queries, building demosBest for: production apps, trading bots, indexers, real-time applicationsNo SLA or uptime guaranteesProvider SLAs available (e.g., Chainstack)No observability or metricsRequest-level observability and monitoringSingle-region accessGlobal routing available (with managed providers)Higher latency under loadLower latency, consistent performance In short: If your workload is occasional and non-critical, public RPC is acceptable.If you need stable throughput, lower latency variance, observability, or operational guarantees, private RPC is the safer default. Full node vs archive Hyperliquid node Hyperliquid nodes can be configured to store varying amounts of historical data. Full nodes typically store recent blockchain state, while archive nodes retain complete historical data from genesis. Full nodeArchive nodeStores recent blockchain state (recent blocks and transactions)Stores complete historical blockchain data from genesisSuitable for: sending transactions, querying current state, real-time monitoringSuitable for: analytics, explorers, historical queries, compliance tools How to get a private Hyperliquid RPC endpoint on Chainstack Chainstack now supports private Hyperliquid RPC endpoints via GEN, available on all paid plans. These endpoints offer higher request throughput than the public RPC, removing the 100 requests/minute limit per IP. To get started: Log in to your Chainstack account. Create an account if you don’t have one. Create a new project or select an existing project. Choose Hyperliquid as your network and select mainnet or testnet. Deploy a node configured for Hyperliquid RPC access. Once deployed, your private RPC URLs, including the /evm and /info endpoints, will be available in your node dashboard. You can then use these endpoints in your trading bots, indexers, or real-time apps without worrying about public rate limits. Chainstack also gives you visibility into how it’s performing: logs, metrics, and request data. You can also lock it down with Access rules to avoid leaking keys or getting spammed. Here’s what it looks like to spin up your own HyperEVM RPC endpoint in less than two minutes with Chainstack: Create HyperEVM RPC endpoint 💡 Quick tips for stable Hyperliquid RPC performance Use HTTP for simple reads, WebSocket for real-time data – WebSockets are great for subscriptions (eth_subscribe, pending txs, logs). For everything else, HTTP is faster and easier to retry. Add a fallback RPC – If your primary endpoint fails, route to a backup (public or secondary private). Log failovers so you can catch issues early. Cache aggressively – Don’t hit the RPC for static data like token metadata or contract ABIs. Cache locally and refresh only when needed. Monitor your usage – Chainstack gives you metrics on latency, errors, and request volume. Use them to spot issues before they break your app. How to get a public Hyperliquid RPC endpoint Hyperliquid provides a free, publicly accessible HyperEVM RPC endpoint—ideal for testing, prototyping, or light scripting. It’s maintained by the core team and can be used without signup, but as of August 2025, it’s rate-limited to 100 requests per minute per IP. Official Hyperliquid public RPC URLs MainnetTestnethttps://rpc.hyperliquid.xyz/evmhttps://rpc.hyperliquid-testnet.xyz/evm What’s supported These endpoints support standard read-only JSON-RPC methods like: eth_call – Execute a message call without creating a transaction eth_getLogs – Get logs matching a filter eth_blockNumber – Get the current block number Important limitations: ❌ No transaction submission ❌ No gas estimation ❌ No WebSocket support ⚠️ 100 requests/minute rate limit per IP For production applications or anything requiring higher throughput, use a private RPC endpoint instead. Supported methods / limits / errors This table summarizes practical method availability and common failure patterns for integration planning. Method / capabilityCommon use caseTypical limits or constraintsCommon errorsPractical fixeth_blockNumberHealth checks, latest block pollingPublic RPC is shared; private endpoint capacity depends on plan429 (rate-limited), timeout (temporary congestion)Backoff + retry, reduce poll frequency, move sustained traffic to private RPCeth_callRead contract state for bots/dashboardsRead-only path; heavy burst traffic may be throttled-32602 (bad params), 429 (throttle)Validate calldata/params, batch reads where possible, retry idempotentlyeth_getLogsEvent indexing and backfillsWide-range queries can be expensive; throughput depends on endpoint typetimeout / query failure (range too broad), 429Split block ranges, paginate scans, checkpoint progresseth_sendRawTransactionTransaction submissionNot supported on public HyperEVM read RPC-32601 / method unsupportedUse Hyperliquid execution/submission path for writeseth_estimateGasPre-trade simulationNot supported on public HyperEVM read RPC-32601 / method unsupportedUse execution workflow/tooling that supports simulationWebSocket subscriptionsReal-time stream subscriptionsPublic endpoints list no WebSocket supportconnection failure / unsupported transportUse HTTP polling or a provider endpoint with WS supportAuthenticated private RPCHigher-throughput production workloadsLimits and auth model depend on plan401/403 (auth issue)Verify header format, token/key scope, and endpoint URL How to add Hyperliquid to your wallet MetaMask doesn’t come preloaded with Hyperliquid, and neither do most EVM-compatible wallets like Rabby, or Rainbow. Whether you’re using a private RPC URL from Chainstack or the public endpoint, you’ll need to add the network manually. The steps below use MetaMask, but they work for any EVM wallet that supports custom networks. Option 1: Add your private Hyperliquid RPC To use a private Hyperliquid Mainnet RPC: Open wallet Click the network dropdown → Add network manually Fill in the fields: FieldValueNetwork nameHyperliquid MainnetRPC URLyour Chainstack mainnet URLChain ID999Currency symbolHYPEBlock explorerhttps://app.hyperliquid.xyz/explorer To use a private Hyperliquid Testnet: FieldValueNetwork nameHyperliquid TestnetRPC URLyour Chainstack testnet URLChain ID998Currency symbolHYPEBlock explorerhttps://app.hyperliquid-testnet.xyz/explorer Option 2: Use a public Hyperliquid RPC URL If you don’t have a private endpoint, you can use a public RPC URL instead. These are shared across all users and may be rate-limited or less reliable. Hyperliquid Mainnet (RPC URL public)Hyperliquid Testnet (RPC URL public)https://rpc.hyperliquid.xyz/evmhttps://rpc.hyperliquid-testnet.xyz/evm These endpoints support standard read-only JSON-RPC methods like eth_call, eth_getLogs, and eth_blockNumber. They do not support transaction submission or gas estimation. Use the same MetaMask steps as above, just paste in the public URL instead of your private one. Conclusion Hyperliquid public RPC is useful for testing and light read workloads, but production systems typically require private infrastructure for predictable throughput and reliability. If your application depends on continuous reads, low latency variance, or operational controls, use private Hyperliquid RPC and treat public endpoints as fallback or development-only access. Create HyperEVM RPC endpoint FAQ How do I choose the right Hyperliquid RPC provider? Prioritize workload fit: low-latency reads for trading bots, stable log/query throughput for indexers, and predictable limits/support for production operations. Compare providers on method support, endpoint stability, and private endpoint options. Is a public Hyperliquid RPC endpoint enough for production? Usually only for light or bursty read traffic. For sustained bot/indexer workloads, private endpoints are typically the safer option for consistency and operational control. What is the Hyperliquid RPC endpoint format (mainnet/testnet)? HyperEVM public JSON-RPC endpoints use the /evm path for mainnet and testnet. See the Hyperliquid RPC public endpoint format section above for current endpoint patterns. Does Hyperliquid RPC require authentication? Public read endpoints typically do not require authentication. Private endpoints usually require provider-specific credentials such as an API key or bearer token. Can I execute trades with eth_sendRawTransaction on the public Hyperliquid RPC? Treat the public HyperEVM RPC path as read-oriented. Trading and order execution should use the protocol’s execution/submission path, not the public read RPC interface. What should I do when I hit RPC limits or intermittent errors? Use retries with backoff, reduce burst concurrency, and split heavy read workloads (especially logs/backfills). If this is a recurring issue, move critical traffic to private endpoints. Recommended reading If you want to go deeper into the Hyperliquid ecosystem and start building production-ready trading systems, we also recommend checking out the following guides: What is Hyperliquid? — an overview of Hyperliquid’s architecture. How to build a Hyperliquid trading bot — a step-by-step guide to set up and wire a trading bot. Hyperliquid On-Chain Activity Tracker — build automated alerts with Hyperliquid RPC. Mastering Hyperliquid — guides to Hyperliquid APIs, authentication, and trading. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Optimism, Avalanche, TON, Ronin, zkSync Era, Starknet, Scroll, Aptos, Fantom, Cronos, Gnosis Chain, Klaytn, Moonbeam, Celo, Aurora, Oasis Sapphire, Polygon zkEVM, Bitcoin and Harmony mainnet or testnets through an interface designed to help you get the job done. To learn more about Chainstack, visit our  Developer Portal or join our Discord server and Telegram group. Are you in need of testnet tokens? Request some from our faucets. Multi-chain faucet, Sepolia faucet, Holesky faucet, BNB faucet, zkSync faucet, Scroll faucet. #### How to get a MegaETH RPC endpoint TL;DR MegaETH RPC endpoints power real-time applications on MegaETH’s high-throughput L2. With ~10 ms mini-blocks and the Realtime API, infrastructure must handle low-latency queries, rapid event streams, and reliable transaction delivery. Source: Uptime on MegaETH A MegaETH RPC endpoint connects your application to MegaETH’s real-time sequencer. While it uses the standard Ethereum JSON-RPC interface, MegaETH’s ~10 ms blocks and Realtime API require infrastructure optimized for high-frequency queries and streaming workloads. What is a MegaETH RPC endpoint A MegaETH RPC endpoint is your application’s gateway to the MegaETH network. It uses the same JSON-RPC interface as Ethereum (eth_call, eth_getBalance, eth_sendRawTransaction) but connects to MegaETH’s real-time sequencer — an Ethereum Layer 2 capable of processing up to 100,000 transactions per second with 10ms mini-block intervals. That speed advantage places unique demands on RPC infrastructure that standard Ethereum tooling was never built to handle. Every user-facing blockchain action in your product depends on it: Reading wallet balances and contract state Estimating gas with MegaETH’s custom gas model Broadcasting signed transactions via the Realtime API Monitoring contract events in real time using eth_getLogs and filter subscriptions That is why endpoint quality directly determines user experience. At 10ms block intervals, a single slow RPC query costs you hundreds of missed mini-blocks. If your endpoint is unstable, real-time applications fail in ways that are invisible on slower chains but immediately apparent on MegaETH. How MegaETH RPC differs from Ethereum RPC MegaETH runs on top of Ethereum as an L2 rollup, which means the JSON-RPC interface is familiar — but the operating environment is fundamentally different. The table below maps the key distinctions that affect provider selection. WhatMegaETHEthereumBlock modelMini blocks every 10ms + EVM blocks every 1s~12 second blocksThroughputUp to 100,000 TPS~15–30 TPS (L1)Gas tokenETH (native, bridged from L1)ETHArchitectureEthereum L2 rollup (OP Stack based)Ethereum L1FinalityL2 soft finality in ~1s; L1 settlement via Ethereum~12 minutes (probabilistic)debug/traceUnavailable on public endpointsGenerally availableRealtime APIYes — realtime_sendRawTransaction + streamingNoGas estimationUse on-chain estimation; local sim may failLocal simulation reliable This is exactly why provider selection for MegaETH must account for Realtime API support, low-latency streaming, and correct gas estimation behavior — not just raw RPS limits. MegaETH RPC endpoint options Choosing the right endpoint is a reliability and latency decision. You are balancing convenience, cost, and operational risk at a speed that magnifies every infrastructure gap. Public vs Private MegaETH RPC endpoints Official public MegaETH endpoints: Mainnet: https://mainnet.megaeth.com/rpc Testnet: https://carrot.megaeth.com/rpc Rate limits: Dynamic CU + bandwidth limits per user (see MegaETH RPC docs) Critical limitation: debug/trace methods are unavailable on all public endpoints 📖 The full RPC method availability list — including restrictions on gas limits and block ranges — is documented in the official MegaETH RPC docs at docs.megaeth.com/rpc. FeaturePublic RPCPrivate RPC (managed provider)AccessFree and openAuthenticated, restricted accessResourcesShared infrastructureDedicated or isolated resourcesPerformanceVariable, rate-limitedStable, high throughputdebug/traceUnavailableProvider-dependent — verify before committingRealtime APIAvailable at public endpointProvider-dependentWebSocket stabilityLimited guaranteesReliable long-lived connectionsBest use caseDevelopment and testingProduction workloads Public RPC endpoints are suitable for testing and prototyping. For production workloads — especially high-frequency trading, DeFi bots, or real-time analytics — use a managed infrastructure provider with predictable rate limits. Full node vs Archive MegaETH node Your data requirements should drive this decision. MegaETH’s 10ms block cadence produces significantly more state than slower chains, which affects archive storage costs and query latency. Full node accessArchive node accessCurrent state queriesHistorical analytics and backfillsStandard wallet and dApp interactionsExplorer-grade productsTransaction submission and broadcastingDeep event backfills via eth_getLogs with wide block rangesReal-time event monitoringCompliance, reporting, and auditLong-range debugging (where trace methods are available) If your product depends on historical state queries or event backfills spanning more than recent blocks, validate archive availability explicitly before launch. MegaETH’s block density means archive nodes carry more data than equivalent Ethereum archives. HTTPS vs WebSockets Transport choice has a larger impact on MegaETH than on slower chains because block frequency amplifies the cost of every round trip. FeatureHTTPSWebSocketModelRequest/responsePersistent connectionComplexitySimple to operateRequires reconnect and heartbeat logicBest forStandard reads and writesReal-time streams and subscriptionsLatency profilePer-request overheadLower for high-frequency updatesMissed event riskPoll-based, predictableRequires backfill logic on reconnect In practice, most teams use HTTPS for standard contract reads and transaction submission, then layer in WebSocket subscriptions for real-time event delivery. On MegaETH specifically, test WebSocket stability under burst traffic early — mini-block rates generate subscription pressure that is orders of magnitude higher than Ethereum mainnet. How to get a private MegaETH RPC endpoint with Chainstack Log in to the Chainstack console (or create an account) Create a new project Select MegaETH as your blockchain protocol Choose network: MegaETH Mainnet (MegaETH Testnet only for Dedicated Nodes) Deploy the node Open Access/Credentials and copy your HTTPS and WebSocket endpoints Run a quick connectivity check before wiring it into production code Connect from your application (ethers.js) const { ethers } = require("ethers"); var urlInfo = { url: "YOUR_CHAINSTACK_ENDPOINT", }; var provider = new ethers.providers.JsonRpcProvider(urlInfo, NETWORK_ID); provider.getBlockNumber().then(console.log); NETWORK_ID — MegaETH network ID: Mainnet: 4326 Testnet: 6342 This confirms your application can connect and read live chain data before integrating more complex logic. Note that MegaETH’s custom gas model means you should always use on-chain gas estimation via the RPC rather than relying on local EVM simulation — some toolchains may throw “intrinsic gas too low” errors without this adjustment. 📖 For a full list of MegaETH-compatible tools including MetaMask, Hardhat, ethers.js, viem, and Foundry, see the Chainstack MegaETH tooling documentation. Using the Realtime API MegaETH exposes a custom realtime_sendRawTransaction method on top of standard JSON-RPC. This enables sub-second transaction confirmation paths that are not possible on standard Ethereum endpoints. Check provider availability for this method before building latency-critical flows — it may not be present on all third-party endpoints. 📖 For more information on the MegaETH Realtime API, see the official documentation. Using Chainlist Chainlist can quickly add MegaETH to wallets like MetaMask or Rabby by auto-filling the correct RPC URL and chain parameters. This is useful for wallet configuration and end-user onboarding. Chainlist is not an infrastructure provider. For production applications, always replace any public or community RPC URL from Chainlist with your managed endpoint before launch. Public endpoints obtained through Chainlist carry no uptime guarantees and may not support archive queries or the Realtime API. Chainstack pricing for MegaETH RPC Chainstack uses request-unit-based pricing, which is easier to forecast than compute-unit models — especially important on MegaETH, where high TPS can amplify compute-weighted billing unpredictably. PlanCostRequests/MonthRPSOverage (per 1M extra)Developer$03M (~25 RPS)~25$20Growth$4920M~250$15Pro$19980M~400$12.5Business$499200M~600$10EnterpriseFrom $990400M+CustomFrom $5 Advanced options: Unlimited Node add-on: Flat monthly pricing for unmetered usage within RPS tier Dedicated Nodes: From $0.50/hour (+ storage) for isolated high-performance workloads See our pricing plans → How to estimate monthly cost Forecast average and peak requests per day Convert to monthly request units Add 20–30% buffer for burst spikes — MegaETH’s high TPS means traffic patterns are more volatile than Ethereum Verify that your RPS tier matches peak traffic — 10ms blocks can generate 100x more requests than equivalent Ethereum workloads Compare shared tier vs dedicated economics at projected scale For MegaETH specifically: if your application is latency-critical (trading bots, real-time DeFi, or on-chain gaming), throughput tiers and overage policy matter more than base plan price. Production readiness checklist Before launch, validate these controls: Primary and fallback RPC provider configured Request timeout policy set (MegaETH’s fast blocks mean stale responses age out quickly) Retry logic with exponential backoff implemented Chain ID validated at startup via eth_chainId (0x10e6 for mainnet) Gas estimation routed through RPC, not local simulation Credentials stored in environment variables or a secrets manager — never hardcoded Monitoring for latency, error rate, and throttling (429 responses) Alerts for sustained degradation eth_getLogs access confirmed and block range limits understood debug/trace method availability verified with provider if needed These controls prevent the most common RPC incidents in production on MegaETH. The gas model difference is the most frequently missed item for teams migrating from Ethereum. Troubleshooting common MegaETH RPC issues IssueLikely CauseHow to Fix429 Too Many RequestsCU or bandwidth limit exceeded on shared endpointMove to managed endpoint, reduce polling frequency, batch requests where possibleWrong chain ID returnedEndpoint pointed to wrong networkValidate eth_chainId at startup; fail fast on mismatch“intrinsic gas too low” errorLocal gas estimation bypassing MegaEVMForce on-chain estimation via the RPC; avoid local simulation for gasdebug/trace methods return errorsMethods unavailable on public endpointsSwitch to a managed provider with confirmed debug support, or redesign without traceWebSocket disconnects frequentlyMini-block rate overwhelms connection keepalive settingsAdd reconnect logic, heartbeat handling, and missed-event backfill on reconnectHigh latency on real-time flowsUsing HTTPS polling instead of WebSocket subscriptionsSwitch time-critical paths to WebSocket; use Realtime API for tx submissionRealtime API method not foundProvider does not expose realtime_sendRawTransactionVerify provider supports Realtime API; fall back to eth_sendRawTransaction Conclusion MegaETH’s real-time architecture makes RPC provider selection far more critical than on standard Ethereum L1 or L2 chains. At 10ms block intervals and up to 100,000 TPS, infrastructure gaps that are invisible on slower networks become immediate application failures. Your provider must support burst traffic, reliable event delivery via eth_getLogs, stable WebSocket connections, correct gas estimation, and ideally the Realtime API for latency-sensitive transaction flows — not just basic JSON-RPC uptime. Use public endpoints for prototyping, then migrate to managed infrastructure with confirmed MegaETH support and SLA-backed reliability before production launch. Start with Chainstack, validate your query and gas estimation patterns in staging, then scale to dedicated infrastructure as traffic grows. Start bulding on MegaETH → FAQ Can I use Ethereum tooling with MegaETH? Yes. MegaETH is EVM-compatible, so ethers.js, web3.js, Hardhat, and MetaMask all work. Point them at a MegaETH RPC endpoint instead of Ethereum. The one significant exception is gas estimation — always use on-chain estimation through the RPC, as local simulation tools may not correctly model MegaEVM’s gas behavior. How does MegaETH RPC differ from Ethereum RPC? The JSON-RPC interface is the same, but MegaETH has 10ms mini-blocks (vs ~12s Ethereum), a unique gas model, unavailable debug and trace methods on public endpoints, and an additional realtime_sendRawTransaction method for ultra-low-latency transaction submission. What SDKs work with MegaETH RPC endpoints? Most teams use ethers.js or web3.js. Any SDK supporting the Ethereum JSON-RPC standard works with MegaETH. Configure the provider URL to point to your MegaETH endpoint and set gas estimation to use RPC rather than local simulation. Can I use MetaMask with MegaETH? Yes. MetaMask supports MegaETH as a custom network (Chain ID 4326, native token ETH). Chainlist can add it automatically. For production dApps, wire your frontend to a managed RPC endpoint rather than the public endpoint. Is a public MegaETH endpoint enough for production? Usually no. Public endpoints have dynamic rate limits, no debug/trace access, no uptime guarantees, and no Realtime API guarantees. Production applications — especially those that need real-time performance — require managed infrastructure. What should I monitor on my MegaETH RPC layer? Track p95/p99 latency, failure rate, 429 responses, WebSocket reconnect frequency, and block lag. For real-time or event-heavy applications, monitor eth_getLogs delivery latency, missed mini-block windows, and gas estimation error rates. Additional resources MegaETH methods MegaETH Chainstack tooling #### How to get a Polygon RPC endpoint in 2026 TL;DR Polygon operates on a robust Layer 2 architecture, providing high throughput and low transaction fees while ensuring compatibility with Ethereum’s ecosystem. This infrastructure is designed for production use, emphasizing scalability and reliability to support decentralized applications and services. This guide explains how to get a Polygon RPC endpoint in 2026 — from public RPCs for testing to private endpoints for production workloads. Polygon RPC options: public vs private When choosing a Polygon RPC endpoint, developers typically decide between shared public RPC infrastructure and managed RPC providers based on workload characteristics, performance requirements, and reliability expectations. The next sections provide a comparison of the benefits and limitations involved. Public RPC endpoints Access is free and straightforward, allowing for easy integration during initial development. They may experience limited request rates and variable performance due to shared resources. No guaranteed uptime or service level agreements (SLAs), making them less suitable for critical applications. Mainly used for testing, development, or applications with light usage. Private RPC endpoints Offers dedicated resources, ensuring stable performance and request handling. Typically comes with SLAs, enhancing reliability for production workloads. Provides customizable infrastructure to meet specific application needs. Better suited for high-demand applications that require consistent uptime. Private RPC endpoints are preferred for applications requiring stronger reliability and performance guarantees. Transitioning to access a private RPC endpoint can enhance your application’s performance and reliability. How to get private Polygon RPC using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Polygon as the blockchain. Choose the network: Polygon PoS Mainnet Testnet (Polygon Amoy Testnet) Deploy a Polygon RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. In addition to managed RPC nodes, Polygon provides community-operated endpoints with notable limitations. Free public Polygon RPC URLs (with limitations) Mainnet RPC: https://polygon-rpc.com (Polygon Foundation) Testnet RPC: Amoy testnet: https://rpc-amoy.polygon.technology/ WebSocket / Notes: – Mainnet: wss://rpc-mainnet.matic.network; – Mumbai testnet deprecated by “Amoy” Public endpoints are shared resources that often have limitations such as rate limits, stability variability, and no SLA, and they are mainly suitable for testing, development, or light usage rather than production workloads. Using Chainlist Chainlist can be used to add Polygon to wallets (for example, MetaMask), but it does not provide RPC infrastructure. It typically relies on public or community RPC endpoints, so for production usage any RPC URL obtained via Chainlist should be replaced with a managed RPC endpoint such as Chainstack. Polygon RPC considerations for 2026 Throughput and request limits impacting application performance. Latency and regional availability affecting user experience across different geographies. Reliability and uptime behavior of the RPC endpoints during peak usage demands. Cost predictability and scaling behavior as applications grow. Dependency on Ethereum L1 for finality may introduce additional latency during cross-chain transactions. Network congestion patterns that could affect the responsiveness of RPC services. Reliable Polygon RPC provider for production Looking for a reliable Polygon RPC provider for production use in 2026?Chainstack provides low-latency, globally distributed Polygon RPC infrastructure built for DeFi and stablecoin infrastructure, from development to high-throughput production. With dedicated nodes, high availability, and enterprise-grade security, Chainstack helps teams build, scale, and operate Polygon applications without managing infrastructure. Chainstack as a Polygon RPC provider Low-latency Polygon RPC endpoints powered by global infrastructure Dedicated and global nodes for mainnet and testnets High 99.99% uptime and consistent performance under real-world load Secure access with API keys and role-based permissions Fast setup — deploy a Polygon node in minutes Start building on Polygon today Start for free, connect your application to a reliable Polygon RPC endpoint, and scale with dedicated nodes built for production performance. Deploy Polygon node now FAQ How do Polygon RPC endpoints differ from Ethereum RPC endpoints? Polygon RPC endpoints are optimized for scalability, enabling faster transactions and lower fees compared to Ethereum. They are designed to handle specific workloads and offer distinct performance characteristics. When should developers use Polygon RPC instead of Ethereum RPC? Developers should consider using Polygon RPC when building applications that require faster transaction speeds and reduced costs, especially for high-frequency transactions or scaling solutions. What SDKs or tooling are commonly used with Polygon RPC endpoints? Developers typically leverage tools such as ethers.js and Web3.js to interact with Polygon RPC endpoints, ensuring compatibility with existing Ethereum development practices. How does Polygon’s ecosystem support new developers? Polygon provides comprehensive documentation and tooling support for developers, along with testnet environments to facilitate the development and testing of applications before deploying to the mainnet #### How to get a Solana RPC endpoint in 2026 TL;DR Solana — high-performance L1 blockchain with ~400ms blocks and sub-cent fees, built for order-book trading, stablecoin infrastructure, and high-throughput dApps. With sub-second block times and massive transaction volume, every interaction with the network — from balance checks to transaction submission — starts with an RPC endpoint. As Solana adoption continues to grow in 2025–2026, choosing the right RPC infrastructure has become a critical production decision. Public endpoints are often insufficient under load, while private RPC providers offer the performance, reliability, and scalability required for real-world applications. In this guide, we explain how Solana RPC endpoints work, compare public and private options, and show how to get a reliable Solana RPC endpoint suitable for production workloads. Solana RPC options Public vs Private When choosing a Solana RPC endpoint, developers typically decide between shared public RPC infrastructure and managed RPC providers based on workload characteristics, performance requirements, and reliability expectations. Public endpoints (with limitations) Mainnet RPC: https://api.mainnet-beta.solana.com Testnet RPC: https://api.testnet.solana.com Devnet: https://api.devnet.solana.com WebSocket supported (use wss:// for same URLs) Public endpoints are shared resources that often have limitations such as rate limits, stability variability, and no SLA, and they are mainly suitable for testing, development, or light usage rather than production workloads. The sections below outline the key advantages and limitations of each approach. FeaturePublic RPCPrivate RPC (Chainstack)AccessFree and openRestricted accessResourcesShared infrastructureDedicated resourcesPerformanceVariable, rate-limitedStable, high throughputBest use caseDevelopment & testingProduction workloads Private RPC is preferred for consistent performance and reliability in production environments. Full node vs archive Solana node Node modeWhat it storesWhen it shinesFull nodeCurrent state plus ~2–3 days of recent slotsreal-time wallets, games, trading botsArchive nodeEvery slot since genesis and historical state queriesblock explorers, analytics, compliance, ML models Archive nodes consume more storage and bandwidth, so providers usually charge extra. If you never need to query slot 100, you can safely start with a full Solana RPC node and upgrade later. The next section describes the process for setting up a private RPC endpoint with Chainstack. HTTPS vs Websockets Solana’s RPC service speaks both HTTPS (request/response) and WebSocket (bi-directional stream). Choosing the right protocol affects latency, bandwidth, and even feature availability. FeatureHTTPSWebSocketTransport stylestateless request/responsestateful, bi-directionalReal-time subscriptions (accountSubscribe, logsSubscribe)polling every N msnative push, < 50 ms latencyFirewall-friendly✅ (port 443)sometimes blocked on corp networksEasy to cache & retry✅harder, connection-orientedMobile data usagehigher (headers per call)lower (single handshake)Supported by Trader node Warp tx✅❌ (HTTP only)CLI default (solana config set)HTTPS plus inferred WSS URL‍*WSS must be set manually via --ws Tip: The Solana CLI auto-derives a WebSocket URL from the HTTPS endpoint, but the computed value may be wrong on custom hosts. Always override with --ws if you need live streams. For more details on WebSocket endpoints, JSON-RPC methods, and client SDKs such as Solana web3.js and solana.py, refer to Solana tooling. How to get private Solana RPC using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Solana as the blockchain. Choose the network: Solana Mainnet Devnet Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. In addition to managed RPC nodes, Solana provides community-operated endpoints with notable limitations. Solana RPC considerations for 2026 Throughput and request limits: Solana workloads often require very high RPS. RPC providers must handle sustained traffic spikes without hard throttling or degraded performance. Latency and regional availability: Low latency is essential for trading and real-time applications. Multi-region routing and proximity to validators directly impact response times. Reliability and uptime: RPC instability can halt applications instantly. Providers should demonstrate consistent uptime, fast failover, and resilience during network congestion. Validator performance: RPC responsiveness depends heavily on validator setup, hardware, and indexing efficiency, especially for state-heavy queries. Ecosystem tooling: Beyond JSON-RPC, mature Solana stacks include WebSockets, gRPC streams, metrics, and production-ready developer tooling. State growth and historical access: Rapid state growth increases demand for scalable storage and fast access to historical data and archives. How to choose the best Solana RPC provider in 2026 The Solana ecosystem now handles billions of JSON-RPC calls each day, and the difference between a good endpoint and a great one is measured in lost trades, stalled user experiences, and unexpected invoices. In other words, your RPC provider has become part of your application’s core logic. Before you copy-paste the first URL you find in a tutorial, step back and weigh the qualities that will keep your wallet, bot, or dApp competitive: multi-region footprint – latency matters when you race solana-validators. burst handling – can the pool absorb 10× traffic for a minute? add-ons – debug & trace APIs, Unlimited Node flat-fee tiers, or Warp transactions for MEV-sensitive bots. observability – per-method stats, logs, and alerts. a real SLA – credits for downtime. Chainstack checks all boxes and adds global elastic nodes, archive mode on demand, and an Unlimited Node add-on that swaps pay-per-request for a fixed monthly bill. For production Solana apps, Chainstack = safest bet. Still unsure? Check our Best Solana RPC providers 2026 ranking — full 6-provider comparison. FAQ How does Solana RPC differ from EVM-based networks? Solana RPC operates within a unique architecture that is not compatible with EVM standards, leading to differences in data models and response formats compared to Ethereum-based networks. What SDKs or tooling are commonly used with Solana RPC endpoints Developers working with Solana typically use the official Solana JS SDK and the Anchor framework for TypeScript to build their applications and interact with the blockchain. What common use cases exist for Solana RPC endpoints? Solana RPC endpoints are used for a variety of applications, including decentralized finance (DeFi), stablecoins, and other Web3 solutions that require high throughput and low latency. Are public Solana RPC endpoints suitable for production applications? Public Solana RPC endpoints are useful for testing and early development but are not recommended for production. They are shared, rate-limited, and offer no uptime guarantees, which can lead to dropped requests, broken subscriptions, and degraded performance during network congestion. What should I look for in a Solana RPC provider for production? When choosing a Solana RPC provider for production, focus on sustained throughput (RPS), low and predictable latency, global regional routing, WebSocket and gRPC support, and proven uptime with SLA guarantees. These factors directly impact application stability under real-world load. Learn more about Solana architecture from our articles Architecture & Parallel Transactions Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution Transactions, Messages & Address Lookup Tables Reliable Solana RPC provider for production In summary, public RPC endpoints are suitable for testing and development, while managed RPC providers are the recommended production option. Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and stablecoin infrastructure. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – a trusted Solana RPC provider. Building on Solana? Deploy your Solana node on Chainstack → #### How to get a Sui RPC endpoint in 2026 TL;DR Sui’s Move-based object model and parallel execution architecture require RPC infrastructure optimized for object queries and checkpoint reads—not just account/log patterns from EVM chains. A Sui RPC endpoint is the core infrastructure layer your app uses to read object state, track checkpoints, and submit transactions on Sui. This guide explains how to choose the right Sui RPC endpoint in 2026, compare public and private options, and move to production-ready infrastructure with reliable performance, archive access, and API roadmap compatibility. What is a Sui RPC endpoint? A Sui RPC endpoint is your app’s gateway to Sui’s Move-based blockchain. Unlike EVM chains where you query accounts and logs, Sui is object-centric: you query owned/shared objects, track checkpoint sequences, and submit transactions that reference object versions. This fundamental difference means: API evolution differs (Sui is actively moving beyond JSON-RPC) Query patterns differ (object IDs, not account addresses) Historical data needs differ (checkpoint history, not just block logs) How Sui RPC differs from EVM RPC WhatSuiTypical EVMData ModelObject-centric (Move)Account-basedConsensusNarwhal-Tusk DAG (parallel)Sequential (Proof of Stake/Work)Primary QueriesObjects + checkpointsAccounts + logs/eventsHistorical NeedsCheckpoint/object historyBlock/log historyAPI Status (2026)Migrating from JSON-RPCJSON-RPC stableIndexingSui-specific strategy neededMany off-the-shelf options This is exactly why provider selection for Sui should include API roadmap and indexing fit, not just raw RPS. Sui RPC endpoint options Choosing the right endpoint is mostly a reliability decision. You’re balancing convenience, cost, and operational risk. Public vs Private Sui RPC endpoints Common public endpoints: Mainnet: https://fullnode.mainnet.sui.io:443 Testnet: https://fullnode.testnet.sui.io:443 Devnet: https://fullnode.devnet.sui.io:443 FeaturePublic RPCPrivate RPC (Chainstack)AccessFree and openRestricted accessResourcesShared infrastructureDedicated resourcesPerformanceVariable, rate-limitedStable, high throughputObject queriesMay timeout under loadConsistent response timesCheckpoint accessLimited historical depthFull archive availableBest use caseDevelopment & testingProduction workloads Public RPC endpoints are useful for testing and experimentation, but treat them as shared community resources. For production workloads, use an infrastructure RPC provider with clearer performance and availability guarantees. Full node vs Archive access on Sui Your data requirements should drive this decision. Full node accessArchive-capable data accessCurrent state readsDeep historical analysisStandard wallet/dapp interactionsExplorer-like productsTypical transaction workflowsCompliance/reporting use casesLarge historical backfills If your product depends on long-range historical queries, validate archive availability before launch. HTTPS vs WebSocket Transport choice impacts system behavior, especially at scale. HTTPSWebSocketRequest/response modelBetter for event-heavy or real-time workflowsSimple operationallyCan reduce overhead for high-frequency interactionsGood for most standard backend reads/writesRequires stronger reconnect/error handling patterns In practice, many teams use HTTPS broadly and add persistent channels only where real-time behavior is required. How to get a private Sui RPC endpoint with Chainstack Log in to the Chainstack console (or create an account). Create a new project. Select Sui as your blockchain protocol. Choose Sui Mainnet Network Deploy the node. Open Access/Credentials and copy your endpoint and auth details. Run a quick connectivity check in your SDK/client before wiring it into production code. This flow keeps setup simple while giving you production-grade infrastructure earlier in the lifecycle. Is Chainlist applicable for Sui? Not really.Chainlist is mainly used for EVM wallet-network configuration and is not the standard infrastructure path for Sui. For Sui, use your provider dashboard and official SDK tooling instead. How to choose the best Sui RPC provider in 2026 Most teams pick an RPC provider too early based on “it works in dev.” For Sui, that can backfire in production because your workload profile changes quickly once users, bots, or indexers hit your app. Use this evaluation framework before you commit: Evaluation CriteriaWhat to CheckWhy It matters for SuiReliability under load• SLA terms and incident history• Traffic burst handling• Regional failover behaviorSui’s parallel execution can spike RPC load unpredictably. Shared infrastructure may throttle during network congestion.Performance• p95/p99 latency from your backend regions• Consistency during peak windowsObject queries and checkpoint reads are latency-sensitive. Users notice slow wallet updates immediately.API roadmap compatibility• Support for Sui’s API transition path• SDK stack compatibilitySui is moving away from legacy JSON-RPC. Ensure your provider supports your integration path.Data access depth• Archive/checkpoint retention• Historical backfill capabilitiesSui’s checkpoint-based history model requires archive nodes for analytics and compliance queries.Operational controls• Key management and access rules• Usage analytics and alerting• Support escalation processProduction incidents need fast response. Monitoring prevents surprises at scale.Pricing predictability• Request-based vs compute-unit pricing• Model costs at 3x expected traffic• Overage rules and dedicated optionsObject-heavy queries cost more. Understand pricing before you scale. A practical rollout model: Start on public/dev endpoints for prototyping Move to managed shared endpoints for staging Use managed production tier with fallback provider before launch Chainstack pricing for Sui RPC Chainstack pricing is request-unit-based and easier to forecast than method-weighted credit systems. Plan tiersCostOverage (per extra 1M requests)Developer$0/mo, 3M requests included, ~25 RPS$20Growth$49/mo, 20M requests, ~250 RPS$15Pro$199/mo, 80M requests, ~400 RPS$12.5Business$499/mo, 200M requests, ~600 RPS$10Enterprisefrom $990/mo, 400M requests, custom throughputfrom $5 How to estimate your likely monthly cost quickly: Forecast average and peak requests/day Convert to monthly request units Add a 20–30% buffer for spikes Check if RPS limits match your peak traffic profile Compare shared tier vs dedicated economics at projected scale If your traffic is bursty (bots, analytics, event-heavy apps), throughput limits and overage policy matter more than base plan price. Production readiness checklist Before launch, validate these basics: Primary + fallback RPC provider configured Request timeout policy set Retry logic with exponential backoff implemented Endpoint and network validated at startup Credentials stored in env/secret manager (never hardcoded) Monitoring for latency, error rate, and throttling Alerts for sustained degradation These controls prevent most avoidable RPC incidents in production. Troubleshooting common Sui RPC issues IssueLikely causeHow to fixFrequent rate limitsShared endpoint saturationMove to managed endpoint, reduce polling, batch requestsHigh latency spikesRegion mismatch or overloaded shared infraRoute to closer region and enable fallback endpointIntermittent request failuresNo retry/timeout strategyAdd bounded timeouts + exponential backoffMissing historical dataEndpoint not archive-capableUse archive-capable tier/providerAuthentication errorsMissing/invalid token configVerify auth headers/tokens and rotate credentials Conclusion Sui’s object-centric architecture makes RPC selection more critical than on EVM chains. Your provider needs to support Sui’s unique data model, API migration path, and checkpoint-based historical queries—not just provide raw RPS. Use public endpoints for prototyping, then move to managed infrastructure with proven Sui support, clear object indexing strategy, and SLA-backed uptime before production launch. Start with Chainstack’s free tier (3M requests/month), validate your query patterns in staging, then scale to dedicated infrastructure as traffic grows. Building on Sui? Deploy your Sui node on Chainstack → FAQ How is Sui RPC different from EVM RPC? Sui uses a Move-based, object-centric data model instead of the account-and-log model used by EVM chains. Developers query object states, versions, and checkpoints rather than accounts and events, which changes integration and indexing patterns compared to typical EVM RPC setups. What SDK should I use for Sui? For TypeScript, @mysten/sui is the primary SDK path. Confirm compatibility with your chosen API mode. Should I still use JSON-RPC in 2026? JSON-RPC is still supported, but it should no longer be the default for new Sui integrations. Use it only where required for legacy compatibility or existing tooling, and plan a structured migration to gRPC or GraphQL for better performance, stronger typing, and long-term ecosystem support. Is Sui Testnet enough for staging? Yes for most integration and pre-production testing. Sui Testnet is suitable for validating contract logic, object lifecycle flows, SDK integrations, and API compatibility. However, you should also simulate realistic traffic patterns, concurrency, and data growth to uncover rate limits, latency spikes, and indexing edge cases before launching on Mainnet. What should I monitor on Sui RPC? Track p95/p99 latency, failure rate, throttle events, and endpoint availability. Alert early, before user-facing transactions degrade. Monitor trends over time to detect gradual performance regression, not just sudden outages. Additional resources Sui tooling On-chain validator analytics with pysui #### How to get a Tempo RPC endpoint Introduction Tempo is a Layer-1 blockchain designed specifically for payment use cases. It supports an Ethereum-compatible JSON-RPC API and enables payment flows using TIP-20 stablecoins, including features such as payment memos for reconciliation. Developers can use Tempo RPC endpoint to build, test, and validate payment applications before moving to production. As an official Tempo ecosystem partner, Chainstack is listed on the Tempo docs as a recommended infrastructure provider for teams building payment applications. Tempo RPC endpoint options Public RPC vs Private RPC Developers typically choose between public RPC endpoints for quick testing and private RPC endpoints for higher reliability, performance, and production use cases. The next sections provide a comparison of the benefits and limitations involved. Public RPC endpointsPrivate RPC endpointsFree and community-operatedDedicated infrastructureRate-limited and shared infrastructureHigher throughput and reliabilityNo guarantees on monitoring or request visibilityUsage metrics, monitoring, and request visibilitySuitable for testing and developmentSLA-backed uptimeUnreliable for production workloadsSuitable for production applications Private RPC is preferred for production use.A private RPC endpoint provides better reliability and consistency for applications with sustained traffic or availability requirements. Public RPC endpoints (with limitations) Mainnet: https://rpc.tempo.xyz Testnet: https://rpc.moderato.tempo.xyz WebSocket: wss://rpc.moderato.tempo.xyz, wss://rpc.tempo.xyz These public endpoints are foundation-provided and run on shared infrastructure. As a result, they commonly enforce rate limiting and request throttling, and they do not provide uptime or performance guarantees. Public RPC endpoints are suitable for testing and development, but production applications typically require a managed or private RPC endpoint. Note for payment applications: Tempo’s public endpoints support payment memo queries via standard eth_getLogs calls, but production payment processors typically require dedicated RPC infrastructure to ensure memo data availability and reconciliation reliability. Full node vs archive Tempo node Tempo nodes can be configured to store different amounts of historical blockchain data. Full nodes typically store recent blockchain state, while archive nodes retain complete historical data from genesis. Full nodeArchive nodeStores recent blockchain state (recent blocks and transactions)Stores complete historical blockchain data from genesisSuitable for: sending transactions, querying current state, real-time monitoringSuitable for: analytics, explorers, historical queries, compliance HTTPS vs WebSockets Transport protocol choice affects connection behavior, latency characteristics, and suitability for different application patterns. HTTPS uses a request–response model with per-request connections, while WebSockets provide a persistent connection better suited for frequent or real-time interactions. HTTPSWebSocketsRequest-response modelPersistent connectionEach query requires a new connectionLower latency for frequent queriesSuitable for: intermittent queries, simple integrationsSupports real-time subscriptions (if available)Suitable for: real-time monitoring, event-driven applications How to get private Tempo RPC endpoint using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Tempo as the blockchain. Choose the network: Mainnet or Testnet: Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. Using Chainlist Chainlist can be used to add Tempo to wallets (for example, MetaMask or Rabby Wallet), but it does not provide RPC infrastructure. It typically relies on public or community RPC endpoints, so for production usage any RPC URL obtained via Chainlist should be replaced with a managed RPC endpoint such as Chainstack. Tempo vs Standard EVM chains: RPC differences FeatureStandard EVM L1TempoGas tokenNative token (ETH, MATIC, etc.)TIP-20 stablecoinToken standardERC-20 (contract-based)TIP-20 (protocol-enshrined)Payment memosNot supportedISO 20022-compliant, queryable via RPCBalance queriesContract call (balanceOf)Native operation (optimized)Use case focusGeneral-purposePayment-specific These architectural differences affect RPC integration patterns. Payment applications benefit from Tempo’s optimized native operations for TIP-20 queries and memo-based reconciliation, while general-purpose dApps may require adjustments to account for stablecoin gas mechanics and enshrined token infrastructure. Tempo RPC considerations for 2026 Payment-oriented traffic patterns — Payment apps generate frequent, latency-sensitive RPC calls for balances, receipts, and confirmations. Stablecoin-based gas model — Transactions use TIP-20 stablecoins for gas, affecting fee estimation and balance checks via RPC. Payment memos and reconciliation — Reliable access to logs and transaction data is required for memo-based reconciliation workflows. WebSocket stability — Persistent connections are important for monitoring incoming payments in near real time. Archive data availability — Historical data is needed for audits, analytics, and payment history queries. Tooling compatibility — Standard EVM tooling support simplifies integration with existing payment stacks. ISO 20022 memo compatibility — RPC access to payment memos follows banking standards, enabling seamless integration with traditional payment reconciliation systems. Enshrined stablecoin infrastructure — TIP-20 tokens are protocol-native, not external contracts, affecting how balance queries and gas estimations work via RPC. Consensus + execution layer separation — Built on Commonware consensus and Reth execution, which may affect finality timing and RPC query patterns compared to monolithic L1s. Conclusion Public RPC endpoints are suitable for testing and early development, while managed RPC endpoints are the recommended option for production payment applications. As RPC traffic grows, reliability, throughput, and observability become critical. Chainstack makes it easy to deploy Tempo RPC infrastructure without managing hardware or node configuration. Developers can spin up production-ready RPC endpoints in minutes and scale as application traffic increases. With globally distributed infrastructure, Chainstack provides low-latency access to Tempo RPC endpoints, ensuring consistent performance for building, testing, and operating payment-centric applications. Start for free, connect your application to a production-grade Tempo RPC endpoint, and scale with infrastructure built for real-world payment workloads. Start building on Tempo → FAQ What is a Tempo RPC endpoint? A Tempo RPC endpoint provides access to the Tempo network via an Ethereum-compatible JSON-RPC API. It allows applications to send transactions, query blockchain state, and monitor payment activity on Tempo testnet or mainnet. Does Tempo support standard Ethereum tooling and SDKs? Yes. Tempo is EVM-compatible and works with common Ethereum tools such as ethers.js, web3.js, Hardhat, Foundry, and web3.py. Existing Solidity contracts and deployment workflows can be reused without modification. How do TIP-20 stablecoins differ from ERC-20 tokens when querying via RPC? TIP-20 tokens are enshrined at the protocol level rather than deployed as smart contracts. This means balance queries and transfers use optimized native operations instead of contract calls. Standard Ethereum tooling works, but developers should be aware that TIP-20 operations have different gas characteristics and faster execution than external ERC-20 contracts. Are there public Tempo RPC endpoints available? Yes. Tempo provides public RPC endpoints for testnet use. These endpoints run on shared infrastructure and are suitable for testing and development, but they typically enforce rate limits and do not provide uptime or performance guarantees. When should I use a private Tempo RPC endpoint? Private RPC endpoints are recommended for production applications or any workload that requires consistent performance, higher throughput, monitoring, and reliability. Payment applications in particular benefit from dedicated RPC infrastructure. More additional resources Connect to Tempo testnet via the JSON-RPC API Build a payment app using TIP-20 stablecoins Explore the complete Tempo tooling guide Tempo methods Build a basic DEX swap with Foundry #### How to get a Tron RPC node: public vs private explained Need to decide between public and private TRON RPC? In this guide, we will explain the trade-offs. We will show how tenancy (Global vs Dedicated) affects performance. We will also help you quickly set up a private TRON RPC node. If you’re shipping on TRON, your first fork in the road is simple. You grab a public RPC URL and start reading data. Or, you spin up a private endpoint for steadier writes and predictable latency. If your traffic is light and occasional rate limits don’t bother you, a public node is enough. But if you need consistent throughput, authenticated access, and fewer surprises under load, private is the obvious choice. So, the decision comes down to how much control you need over performance and access. To understand why that choice matters, we will map the trade-offs and point you to both options so you can make the right call. What is a TRON RPC node? Full Node vs Solidity Node A TRON RPC node is just the server that links your app to the TRON network. It keeps a local copy of the chain, verifies new blocks, and relays transactions. On top of that, it exposes RPC methods so your scripts, wallets, or services can pull blockchain data or push signed transactions. Most of the time, you won’t think about the node itself — you’ll just point your app at a TRON RPC URL and start talking to it over HTTP. Historically, the stack distinguished between: Full Node — tracks every block and transaction, serving the core HTTP APIs. Solidity Node — served data from finalized blocks. Today, you’ll still see the namespaces reflected in APIs: /wallet (latest state) and /walletsolidity (confirmed state). At the protocol layer, TRON runs delegated proof of stake with 27 super representatives (SRs) elected by TRX holders to produce blocks and secure the chain. Running as an SR requires a configuration file, suitable hardware, and a super representative account. Meeting the network’s hardware requirements is essential if you plan on actually starting the node yourself. Most builders don’t go that far; they either connect to a hosted TRON RPC endpoint or run their own non-producing node for development, indexing, or analytics. When you connect through a TRON RPC node, the jobs usually fall into three buckets: Read — pull balances, scan transaction history, or scrape recent blocks and contract events when you’re building analytics. Write — deploy a contract or send a transaction that you’ve signed locally with a private key, then broadcast it through the node. Observe — watch latency spikes, error codes, or connection drops so your app doesn’t stall in production. TRON RPC interfaces (HTTP, JSON-RPC, gRPC) On the surface, it’s just an endpoint. Underneath, the node exposes the APIs you’ll hit every day. Here are some API surfaces you’ll encounter: HTTP — /wallet and /walletsolidity endpoints for native TRON operations. EVM-compatible JSON-RPC — exposed at /jsonrpc for EVM-style workflows (coverage differs from Ethereum). gRPC — high-performance, strongly typed access, including transaction broadcast. So your RPC choice doesn’t change consensus, but it does affect how consistently you see fresh state and how predictably your writes settle under load. Public vs private TRON RPC URL Public TRON RPC endpoints Public TRON RPC endpoints are community- or foundation-hosted URLs available to use for those who do not want to set up their own node. These endpoints come in handy when doing quick experiments, reading balancers, or testing contract calls. The big trade-off here is that you have to share the same pool with everyone else, which means getting rate limits, variable latency, and the occasional timeout. However, if your workload is light and you don’t mind occasional retries, public RPC will do the job. Private TRON RPC endpoints A private TRON RPC endpoint gives you isolation and control. You authenticate requests, keep environments separate, and get a steadier latency envelope under load because you’re not competing with a public pool. This matters once you start submitting transactions regularly, streaming events for indexing, or running flows where flakiness impacts users or strategies. So, when predictable performance, access controls, and clearer observability become requirements, private is the right move. Global vs Dedicated nodes If you’ve reached the point where private RPC is the right choice, you then decide how much tenancy you need. On Chainstack, that means choosing between Global and Dedicated Nodes. Global Nodes are multi-tenant but still give you your own protected endpoint, balanced across regions. They’re quick to start, affordable (from $0/month), and work well if you need elastic capacity without the overhead of running hardware yourself. Dedicated Nodes are single-tenant. You’re not sharing performance with anyone else, so they’re better suited for workloads that need guaranteed throughput, reliability, or compliance-grade isolation. Both options let you skip the work of compiling the TRON source code, setting up a configuration file, or trying to run your own super representative setup. You just create the node in the console, grab the RPC URL, and you’re ready to integrate. Choosing between public and private TRON RPC A quick rule of thumb to see which option fits your workload: FeaturePublic RPCPrivate RPCSetupZero setup neededOne-time setup to fill in the private endpoint detailsWorkloadLight queries, exploration, demosContract deployments, bots, steady reads/writesPerformanceShared capacity, variable latencyReserved capacity, predictable response timesReliabilityOccasional retries are fineConsistent latencySecurityOpen, no controlsAuthenticated, access rules, account security TRON RPC endpoint URLs Below are the public TRON RPC endpoint URLs for Mainnet and testnets. These are free TRON RPC endpoints suitable for development and light testing — no signup required. For production workloads, use a private endpoint from Chainstack or another provider. Mainnet RPC endpoints InterfaceURLNotesHTTP (Full Node)https://api.trongrid.ioTronGrid official. 15 QPS with API key, throttled without.HTTP (Solidity)https://api.trongrid.io/walletsolidityConfirmed-only state.JSON-RPChttps://api.trongrid.io/jsonrpcLimited EVM compatibility. Read-only — no eth_sendRawTransaction.gRPCgrpc.trongrid.io:50051 (Full Node), grpc.trongrid.io:50061 (Solidity)Native protobuf. Highest performance for high-throughput workloads. Third-party public endpoints: ProviderURLRate limitAnkrhttps://rpc.ankr.com/tronFree tier: ~30 RPSdRPChttps://tron.drpc.orgFree tier availablePublicNodehttps://tron-rpc.publicnode.comNo signup required Shasta Testnet InterfaceURLHTTPhttps://api.shasta.trongrid.ioJSON-RPChttps://api.shasta.trongrid.io/jsonrpcFaucetshasta.tronex.io Shasta mirrors Mainnet parameters. No API key required. Use for testing contracts and transactions before deploying to Mainnet. Nile Testnet InterfaceURLHTTPhttps://nile.trongrid.ioJSON-RPChttps://nile.trongrid.io/jsonrpcFaucetnileex.io Nile runs ahead of Mainnet — new TRON features land here first. Use for testing against upcoming protocol changes. Private TRON RPC endpoint (Chainstack) For production workloads that need higher throughput, gRPC access, and no rate limits, deploy a private TRON endpoint on Chainstack: Create a free Chainstack account Create a project → Add node → Select TRON Mainnet or Nile Testnet Copy your endpoint URL from the Access & Credentials panel Your private endpoint supports all four TRON interfaces (/wallet, /walletsolidity, /jsonrpc, gRPC) behind a single authenticated URL. See the TRON API reference for supported methods. For a deeper comparison of TRON RPC providers — including pricing, gRPC support, and enterprise compliance — see our Best TRON RPC Providers in 2026 guide. Create TRON RPC node → Working with TRON tooling Once you have a TRON RPC node, the next step is plugging it into the tools you use to build, test, and deploy. Tooling bridges your endpoint with familiar developer workflows, so you don’t have to work directly with raw RPC calls. API surfaces Chainstack TRON nodes support all three RPC namespaces: /jsonrpc — Ethereum-compatible JSON-RPC methods. /wallet — latest state queries. /walletsolidity — confirmed/finalized state queries. 📖 Note: TRON nodes are full only (non-archive), so some deep-history methods are not available. WebSocket event subscriptions are also not supported at this time. SDKs and frameworks You can connect your TRON RPC endpoint to common Web3 libraries: TronWeb.js — native JavaScript SDK for sending transactions, reading balances, and contract interaction. web3.py — Python interface for DApps; connect via HTTP provider using your endpoint. Hardhat, Foundry, Remix — EVM-compatible frameworks can be configured to use a TRON RPC URL for deploying and testing smart contracts. Wallets and IDEs For contract testing and deployment, you can also route through: TronLink or Trust Wallet — TRON-native wallets with pre-configured RPC endpoints. Remix IDE — interact via MetaMask (bridged tokens only) or TronLink for native TRC-20s. Quick start examples cURL curl -X POST YOUR_CHAINSTACK_ENDPOINT/wallet/getnowblock \ -H "Content-Type: application/json" TronWeb.js const { TronWeb } = require('tronweb'); const tronWeb = new TronWeb({ fullHost: 'YOUR_CHAINSTACK_ENDPOINT' }); async function getBalance() { const balance = await tronWeb.trx.getBalance('TWiEv2wfqQ8FkbAJ6bXt1uA2Uav9ZWvXip'); console.log('Balance in TRX:', tronWeb.fromSun(balance)); } getBalance(); Python from web3 import Web3 web3 = Web3(Web3.HTTPProvider('YOUR_CHAINSTACK_ENDPOINT/jsonrpc')) print('Latest block:', web3.eth.block_number) Why tooling matters Without tooling, you’d be crafting raw HTTP requests against your RPC URL. Toolchains like TronWeb or web3.py abstract that into readable functions and scripts, making it easier to manage accounts, compile contracts, broadcast transactions, or even fork the network for local testing. ℹ️ For more info, check out our documentation. Wrapping up The choice between public and private TRON RPC depends on what you’re building. Public is fine for light reads or early tests. For contract work, indexing, or anything that needs stable performance, go with private. Once you’ve got your endpoint, everything else — TronWeb, web3.py, Hardhat, Foundry — plugs in on top. That’s where you write, test, and ship. If you’re evaluating which provider to use for production, our Best TRON RPC Providers in 2026 comparison covers pricing, gRPC support, archive access, and enterprise compliance across Chainstack, TronGrid, Quicknode, Ankr, and dRPC. Create Tron RPC node → FAQ What is a TRON node? A TRON RPC is server software that keeps a synchronized copy of the blockchain and exposes RPC endpoints so apps can query data or broadcast transactions. Super representatives run block-producing nodes, while most builders connect through RPC endpoints for reads and writes. Does TRX stand for Tron? TRX is the ticker TRON of the native token of the Tron network. The blockchain itself is called TRON, while TRX is the asset used for gas fees, staking, and on-chain transactions. Can I add TRON to MetaMask? MetaMask doesn’t natively support TRON RPC because of the VM and address differences. The only way to see TRX in MetaMask is as a bridged token (BEP-20 on BNB Chain or ERC-20 WTRX on Ethereum). For anything native like TRX balances, TRC-20 contracts, validator interactions, you’ll need TronLink, Trust Wallet, or another Tron-specific wallet. What’s the difference between Full Node and Solidity Node? Historically, Full Node validated and stored every block, while Solidity Node served finalized block data. Today, their functionality is merged, but you’ll still see API namespaces like /wallet(latest) and /walletsolidity (confirmed). Do I need to run my own node to build on TRON? No. Developers often prefer to just use public RPC URLs or spin up a private RPC with a provider like Chainstack. You’d only run your own node if you want total control over the setup, can handle the hardware requirements, or plan to operate as a super representative. Are TRON and TRX the same? Not exactly. TRON is the blockchain protocol and network; TRX is its native token. You’ll often see them used interchangeably, but technically TRX refers to the currency and TRON refers to the chain. #### How to get an Arbitrum RPC endpoint in 2026 TL;DR Developers need Arbitrum RPC access to read chain state, monitor activity, and submit transactions against Arbitrum networks such as Arbitrum One and Arbitrum Sepolia. Choosing the right RPC infrastructure affects reliability, operational overhead, and integration with developer tooling. Public endpoints are convenient for experimentation, while private managed endpoints provide stronger reliability and operational guarantees for production. Consider your workload, SLAs, and integration needs before selecting an endpoint. Arbitrum RPC options Choosing an RPC endpoint requires balancing cost, reliability, and operational control. The next sections provide a comparison of the benefits and limitations involved. Public RPC endpointsPrivate RPC endpointsFree and community-operatedDedicated infrastructureRate-limited and shared infrastructureHigher throughput and reliabilitySuitable for testing and developmentSLA-backed uptimeUnreliable for production workloadsSuitable for production applications Private RPC is preferred for production use. Transitioning to access a private RPC endpoint can enhance your application’s performance and reliability. Public endpoints (with limitations) Mainnet: https://arb1.arbitrum.io/rpc (Offchain Labs) Testnet: https://sepolia-rollup.arbitrum.io/rpc (Arbitrum Sepolia testnet) WebSocket availability: wss://arb1.arbitrum.io/ws (mainnet); Nitro Devnet uses Goerli ETH The listed public endpoints are community or foundation-provided resources and are shared infrastructure. Public endpoints commonly implement rate limiting and request throttling to protect service availability. Uptime and performance characteristics are not guaranteed for production workloads. For production applications, a managed or private RPC endpoint is generally recommended. Full node vs archive Arbitrum node Arbitrum nodes can be configured as full or archive nodes, depending on how much historical data they retain. Full nodes serve recent state and real-time queries, while archive nodes store complete history from genesis for deep analytics and long-range historical queries. Full nodeArchive nodeStores recent blockchain state (recent blocks and transactions)Stores complete historical blockchain data from genesisSuitable for: sending transactions, querying current state, real-time monitoringSuitable for: analytics, explorers, historical queries, compliance HTTPS vs WebSockets Transport protocol choice influences connection behavior and integration patterns. HTTPS and WebSockets each have trade-offs for connection lifecycle, latency, and suitability for different application models. HTTPSWebSocketsRequest-response modelPersistent connectionEach query requires a new connectionLower latency for frequent queriesSuitable for: intermittent queries, simple integrationsSupports real-time subscriptions (if available)Suitable for: real-time monitoring, event-driven applications For details on using Arbitrum RPC with wallets, development frameworks, client libraries, and HTTP or WebSocket connections, refer to the Arbitrum documentation tooling. How to get private Arbitrum RPC using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Arbitrum as the blockchain. Choose the network: Arbitrum One Mainnet for production Arbitrum Sepolia for testing Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. In addition to managed RPC nodes, Arbitrum provides community-operated endpoints with notable limitations. Using Chainlist Chainlist can be used to add Arbitrum to wallets (for example, MetaMask), but it does not provide RPC infrastructure. It typically relies on public or community RPC endpoints, so for production usage any RPC URL obtained via Chainlist should be replaced with a managed RPC endpoint such as Chainstack. Arbitrum RPC considerations for 2026 Throughput and request limits — Ability to sustain high request volumes without aggressive throttling or degraded performance. Latency and regional availability — Impact of geographic routing and infrastructure distribution on response times. Reliability and uptime behavior — Consistency under load, failover mechanisms, and resilience during network instability. Archive data availability — Access to complete historical state for long-range queries and analytics. Dependency on L1 for finality — RPC behavior can be influenced by settlement and confirmation patterns on the underlying L1, affecting how applications observe final state. Cross-chain RPC traffic — Increased load from monitoring inter-network activity and cross-chain coordination can affect endpoint capacity. Nitro execution efficiency — Optimized execution environment affecting RPC performance characteristics. Conclusion In summary, public RPC endpoints are suitable for testing and development, while managed RPC providers are the recommended production option. Chainstack is the fastest and most reliable way to get started with Arbitrum RPC infrastructure in 2026. Getting started with Arbitrum on Chainstack is fast and straightforward. Developers can deploy a reliable RPC node for mainnet access in seconds—no complex setup or hardware provisioning required. Chainstack provides low-latency Arbitrum RPC endpoints powered by globally distributed infrastructure. This ensures consistent performance for building, testing, and scaling real-world applications, including DeFi, trading, and stablecoin infrastructure. Key features: Fast deployment through an intuitive console Low-latency access via global infrastructure High throughput and stable performance under load Support for dedicated and shared RPC nodes Secure access with API keys and role-based permissions Start for free, connect your application to a production-grade Arbitrum RPC endpoint, and scale with dedicated infrastructure built for performance. FAQ What’s the difference between L1 and Arbitrum RPC endpoints? L1 and Arbitrum endpoints represent access to different networks with separate state and operational characteristics. Applications choose between them based on where activity needs to be performed and which network’s state must be read. How do SDKs interact with Arbitrum RPC endpoints? Common SDKs used with Arbitrum include @arbitrum/sdk (TypeScript SDK) and ethers.js. These SDKs typically configure an HTTP or WebSocket endpoint and handle request serialization, connection management, and higher-level developer primitives. When should I use Arbitrum RPC instead of Ethereum L1 RPC? Use Arbitrum RPC when you need to interact with or observe activity on Arbitrum-specific networks such as Arbitrum One or Arbitrum Sepolia. For workflows that require data or operations on L1, use the corresponding L1 RPC endpoints. Does Arbitrum support the same RPC methods as Ethereum? Tooling support varies across blockchain ecosystems, and network-specific considerations apply. Consult Arbitrum documentation for protocol details and to verify compatibility with specific client tooling. How does Arbitrum Nitro affect RPC behavior? Arbitrum Nitro improves execution efficiency on L2, but RPC latency still depends on sequencer behavior, node configuration, and infrastructure load rather than execution alone. Learn more about how Arbitrum Nitro works here. #### How to get an Avalanche RPC endpoint (2026 guide) TL;DR Send a request to the wrong Avalanche chain endpoint and you get silent errors that look like network problems — not a clear message telling you that C-Chain, X-Chain, and P-Chain each require a different URL. Avalanche’s three-chain architecture means a single base node URL exposes three separate APIs, and routing the wrong operation to the wrong one is the most common source of integration failures. This guide covers all three chains, when each matters for RPC selection, and how to deploy infrastructure that handles the full Avalanche API surface without the guesswork. What is an Avalanche RPC endpoint An Avalanche RPC endpoint is a chain-specific URL — not a single address that handles everything. Each of Avalanche’s three primary chains has its own endpoint path appended to a base node URL, and each speaks a different API dialect: C-Chain (/ext/bc/C/rpc) — EVM-compatible JSON-RPC, same interface as Ethereum. This is where smart contracts live, DeFi protocols run, and all eth_* calls go. X-Chain (/ext/bc/X) — Avalanche-native API for asset creation and transfers using the DAG-based Avalanche consensus. Not EVM-compatible. P-Chain (/ext/P) — Platform chain API for staking, validator management, and subnet creation. Also not EVM-compatible. Every production action routes through one of these: Deploying and calling smart contracts via C-Chain JSON-RPC (eth_call, eth_sendRawTransaction) Reading DeFi protocol state, token balances, and event logs via C-Chain Transferring AVAX between chains or interacting with native assets via X-Chain Querying validator sets, delegator balances, or subnet configurations via P-Chain Monitoring real-time C-Chain transactions via WebSocket subscriptions The operational consequence: if you build a wallet or exchange that handles native AVAX transfers across all three chains, you are not talking to one endpoint — you are managing three separate API surfaces with different authentication, different method namespaces, and different data models. Beyond the three primary chains, Avalanche supports subnets — customizable, application-specific blockchains that run on Avalanche infrastructure with their own validator sets, virtual machines, and tokenomics. Each subnet exposes its own RPC endpoint, independent from the C/X/P-Chain endpoints. If you are building on or integrating with an Avalanche subnet, you will need a separate managed endpoint for that subnet in addition to your primary chain endpoints. For a deeper look at subnet architecture and development, see the Avalanche subnet series on the Chainstack Blog. How Avalanche RPC differs from Ethereum RPC For C-Chain development, Avalanche is intentionally Ethereum-equivalent — the same tooling, the same methods, the same mental model. The differences that matter for RPC selection are below the application layer. WhatAvalanche C-ChainEthereumBlock time~2 seconds~12 secondsFinality~1–2 seconds (Snowman consensus)~12 seconds (single slot)ThroughputHundreds of TPS, peaks above 1,000~15–30 TPS (L1)Gas tokenAVAXETHConsensus (C-Chain)Snowman (linear, probabilistic BFT)Proof of StakeChain ID43114 (mainnet) / 43113 (Fuji)1 (mainnet)Multi-chain APIC-Chain + X-Chain + P-Chain (separate endpoints)Single chain, single endpointWebSocket on public APIC-Chain onlyFull support The finality difference is significant for RPC infrastructure design. Snowman consensus finalizes transactions probabilistically in under two seconds — there is no waiting for multiple block confirmations the way Ethereum applications often do. Applications that implement Ethereum-style confirmation polling on Avalanche are adding unnecessary latency and request volume. The right pattern is to treat a single confirmed block as final on C-Chain. Avalanche RPC endpoint options Public vs private Avalanche RPC endpoints The three-chain architecture means provider evaluation is not just about C-Chain performance — it is about whether the provider covers all three chains and whether WebSocket is available beyond C-Chain. The public API handles light workloads well, but drops WebSocket streams under heavy load and does not offer WebSocket for X-Chain. Official public Avalanche endpoints (Mainnet): C-Chain: https://api.avax.network/ext/bc/C/rpc X-Chain: https://api.avax.network/ext/bc/X P-Chain: https://api.avax.network/ext/P Fuji Testnet: C-Chain: https://api.avax-test.network/ext/bc/C/rpc ⚠️ WebSocket limitation: The public API supports WebSocket only on the C-Chain. X-Chain and P-Chain WebSocket connections are not available on the public API node. For applications that subscribe to X-Chain events, managed infrastructure is required. FeaturePublic API (api.avax.network)Private RPC (Chainstack)AccessFree, no auth requiredAuthenticated, isolatedResourcesShared, load-balancedDedicated resourcesC-Chain coverageFull JSON-RPCFull JSON-RPCX-Chain coverageAvailable, throttledAvailable, stableP-Chain coverageAvailable, throttledAvailable, stableWebSocketC-Chain onlyC-Chain + X-ChainArchive accessNot availableC-Chain archive availableBest use caseTesting, light readsAll production workloads For DeFi protocols and smart contract applications that only touch the C-Chain, the public API is a reasonable starting point. The moment your application needs reliable X-Chain or P-Chain access — or sustained WebSocket subscriptions — managed infrastructure becomes necessary. 📖 For a detailed provider comparison including performance benchmarks and feature analysis, see Best Avalanche RPC providers in 2026. Full node vs archive Avalanche node Archive support on Chainstack is available for the C-Chain only. X-Chain and P-Chain archive access is not currently offered. Plan your data architecture around this boundary. Full node accessArchive node access (C-Chain only)Current C-Chain contract stateHistorical C-Chain state at any block heightRecent DeFi protocol queriesLong-range eth_getLogs backfills for analyticsX-Chain and P-Chain API callsDeFi protocol TVL history and liquidation auditsReal-time event monitoringBlock explorer-grade data for C-ChainTransaction broadcastingCompliance and regulatory reporting Archive access starts at $49/month on Chainstack — confirm whether your use case requires historical C-Chain state queries before choosing a plan. For subnet development and most DeFi applications, full node access is sufficient. 📖 Learn more about Chainstack archive data and what it enables for C-Chain historical queries. HTTPS vs WebSockets Avalanche’s sub-two-second finality changes the calculus on WebSocket usage compared to slower chains. Real-time monitoring matters more when blocks come fast — a two-second polling interval on C-Chain already feels sluggish for latency-sensitive applications. FeatureHTTPSWebSocketModelRequest/responsePersistent connectionComplexitySimple operationallyRequires reconnect/heartbeat logicBest forC-Chain contract calls, P-Chain/X-Chain queries, batch readsC-Chain real-time tx monitoring, DeFi event streams, MEV botsLatencyStandardLower for high-frequency C-Chain updatesConnection overheadPer requestOne-time handshake A critical constraint: WebSocket subscriptions are available on C-Chain only — both on the public API and on Chainstack. If your application needs event streaming from X-Chain transactions, you must poll over HTTPS. Design for this upfront rather than discovering it when you try to subscribe to X-Chain events in production. How to get a private Avalanche RPC endpoint with Chainstack Log in to the Chainstack console (or create an account) Create a new project Select Avalanche as your blockchain protocol Choose network: Avalanche Mainnet or Fuji Testnet Deploy the node Open Access/Credentials and copy your C-Chain, X-Chain, and P-Chain endpoint URLs Run a connectivity check on each chain you plan to use before wiring into production Connect to the C-Chain with ethers.js using your Chainstack endpoint: const { ethers } = require("ethers"); const provider = new ethers.providers.JsonRpcProvider( "YOUR_CHAINSTACK_ENDPOINT/ext/bc/C/rpc", 43114 // C-Chain Mainnet chain ID — use 43113 for Fuji Testnet ); // Confirm connectivity: fetch the latest block number provider.getBlockNumber().then((blockNumber) => { console.log("Latest C-Chain block:", blockNumber); }); 📖 For the full integration guide including X-Chain with AvalancheJS, WebSocket setup, Hardhat, Foundry, and Brownie configuration, see the Chainstack Avalanche tooling documentation. Using Chainlist Chainlist lists the Avalanche C-Chain (chain ID 43114) and Fuji Testnet (chain ID 43113), and can be used to add them to MetaMask or Rabby in one click. It does not list the X-Chain or P-Chain, as those are not EVM networks. Chainlist is not an infrastructure provider — any public RPC URL added through Chainlist should be replaced with your managed endpoint before going to production. Chainstack pricing for Avalanche RPC Chainstack counts requests uniformly across all three Avalanche chains — a C-Chain eth_call, an X-Chain avm.getBalance, and a P-Chain platform.getCurrentValidators all draw from the same monthly request pool at a flat rate per request unit. PlanCostRequests/MonthRPSOverage (per 1M extra)Developer$03M (~25 RPS)~25$20Growth$4920M~250$15Pro$19980M~400$12.5Business$499200M~600$10EnterpriseFrom $990400M+CustomFrom $5 Advanced options: C-Chain Archive Node: Complete C-Chain historical data starting at $49/month Unlimited Node add-on: Flat monthly pricing for unmetered usage within your RPS tier Dedicated Nodes: From $0.50/hour (+ storage) — recommended for high-frequency DeFi bots and MEV applications that need consistent sub-second response times How to estimate monthly cost Separate your C-Chain, X-Chain, and P-Chain request volumes — they add up to a single pool but sizing them individually prevents surprises Factor in WebSocket subscription keepalives — persistent connections generate periodic heartbeat requests Account for Avalanche’s block speed: at ~2-second blocks, a bot polling every block hits ~1.3M requests/month per polling loop Add 25–35% buffer for DeFi protocol activity spikes — Avalanche traffic correlates with AVAX price movements and cross-chain bridge volume If you use archive for historical eth_getLogs backfills, estimate query volume separately — wide-range log queries can be expensive per call For Avalanche specifically: Applications that also interact with subnets add a separate endpoint and request stream per subnet. If you are building multi-subnet infrastructure, account for each subnet’s traffic independently from the primary chain endpoints. Production readiness checklist Before launch, validate these basics: Primary + fallback RPC provider configured — use Chainstack Compare to benchmark endpoint latency across providers before committing Request timeout set — P-Chain queries for validator sets can be slower than C-Chain reads Retry logic with exponential backoff implemented Credentials stored in env/secret manager, never hardcoded Monitoring and alerting in place for latency, error rate, and throttling Avalanche-specific items: Separate endpoint URLs configured for C-Chain, X-Chain, and P-Chain — do not send all requests to the C-Chain URL Chain ID validated at startup (eth_chainId returns 43114 on mainnet, 43113 on Fuji) — fail fast on mismatch WebSocket reconnect logic and heartbeat handling in place for C-Chain subscriptions Snowman finality model applied — treat one confirmed block as final on C-Chain instead of waiting for multiple confirmations X-Chain WebSocket limitation documented in your runbooks — polling fallback implemented if you need X-Chain event monitoring Troubleshooting common Avalanche RPC issues IssueLikely CauseHow to FixX-Chain or P-Chain calls return 404Request sent to C-Chain /ext/bc/C/rpc endpointUse chain-specific paths: /ext/bc/X for X-Chain, /ext/P for P-ChainWebSocket fails on X-ChainX-Chain WebSocket not available on public APISwitch to HTTPS polling for X-Chain events; use managed provider for WSSeth_getLogs returns empty on old blocksFull node queried beyond its retained historySwitch to C-Chain archive node for historical log queriesWrong chain ID in MetaMaskConnected to Fuji (43113) instead of Mainnet (43114)Validate eth_chainId at startup; enforce correct chain ID in wallet connection logicHigh latency on validator queriesP-Chain getCurrentValidators is a heavy callCache validator set responses locally; reduce polling frequency to minutes, not seconds429 Too Many RequestsPublic API rate limit hit during burstMove to managed endpoint; public API drops WebSocket streams and throttles under load Conclusion Most Avalanche integration failures are not network issues — they are routing issues. A request to /ext/bc/C/rpc that should have gone to /ext/bc/X returns an error that tells you nothing useful. A WebSocket subscription that works on C-Chain silently fails on X-Chain because the public API never supported it there. These are not edge cases; they are the standard failure modes for teams who treat Avalanche as a single-endpoint EVM chain without reading the architecture first. The pattern that works: start on C-Chain with the public API, lock down your endpoint routing per chain before writing application logic, and move to managed infrastructure the moment your workload involves X-Chain, sustained WebSocket connections, or historical data queries against the C-Chain archive. That last step is not optional for production — it is the point where the public API’s limitations become your users’ problem. Start with Chainstack’s free tier (3M requests/month across all three chains), validate your chain-specific endpoint routing and WebSocket behavior in staging, then scale to dedicated infrastructure as DeFi or subnet traffic grows. Start building with Chainstack → FAQ I only need C-Chain — can I ignore X-Chain and P-Chain entirely? For pure smart contract development — deploying contracts, reading DeFi state, monitoring events — yes. The C-Chain is fully EVM-compatible and your existing Ethereum tooling works without modification. You only need X-Chain if your application handles native AVAX asset transfers between chains, and P-Chain only if you interact with staking, validators, or subnet management. Does Avalanche’s fast finality change how I write my confirmation logic? Yes, meaningfully. Snowman consensus finalizes C-Chain transactions in approximately one to two seconds, so the standard Ethereum pattern of waiting for multiple block confirmations adds unnecessary latency and doubles or triples your polling request volume. For most applications, treating one confirmed Avalanche block as final is the correct and safe approach. What SDKs work with Avalanche RPC endpoints? For C-Chain development, any Ethereum-compatible SDK works without modification — ethers.js, web3.js, viem, Hardhat, and Foundry all connect to the C-Chain endpoint using standard Ethereum JSON-RPC. For X-Chain and P-Chain operations, AvalancheJS is the primary SDK, providing typed methods for asset transfers, staking queries, and subnet interactions that are not available in EVM tooling. Can I use MetaMask with Avalanche? Yes — MetaMask connects to the C-Chain using the standard EVM network configuration (chain ID 43114, RPC URL pointing to your C-Chain endpoint). MetaMask does not support the X-Chain or P-Chain, as those are not EVM-compatible. For native AVAX cross-chain transfers, Core Wallet is the recommended alternative as it natively supports all three chains. Is a public Avalanche endpoint sufficient for production? For low-volume C-Chain applications, the public API is a reasonable starting point. The hard limits arrive when you need reliable WebSocket connections (public streams drop under load), X-Chain WebSocket subscriptions (not available publicly), archive data for historical queries, or consistent throughput for DeFi bots and MEV strategies. Any of these requirements means moving to managed infrastructure. What should I monitor on my Avalanche RPC layer? Track latency separately per chain — C-Chain reads, X-Chain queries, and P-Chain validator calls have very different response time profiles. Monitor WebSocket reconnect frequency on C-Chain subscriptions, 429 response rates, and archive query response times if you use historical data. For DeFi applications, also track eth_getLogs query latency — wide block ranges against the archive are the most common source of unexpected slowdowns. Additional resources Avalanche: Aave V3 flash loan with Hardhat — Chainstack Docs Chainstack Avalanche tooling documentation Best Avalanche RPC providers in 2026 — Chainstack Blog More Avalanche tutorials and articles on the Chainstack Blog Avalanche official RPC providers documentation AvalancheJS SDK documentation #### How to get an Ethereum RPC endpoint in 2026 TL;DR Public Ethereum RPC endpoint options are ideal for prototyping, but most production applications quickly outgrow them. Shared infrastructure means rate limits during peak traffic, dropped WebSocket sessions, and 429 errors precisely when reliability matters most. In this guide, you’ll learn when a public Ethereum RPC endpoint is sufficient, and when to upgrade to managed infrastructure. What is an Ethereum RPC endpoint? An RPC (Remote Procedure Call) endpoint is the URL your application uses to communicate with an Ethereum node. Every interaction with Ethereum—reading balances, calling smart contracts, sending transactions—goes through JSON-RPC methods like eth_call, eth_getBalance, and eth_sendRawTransaction. Without an RPC endpoint, your app cannot read chain state or send transactions. Because RPC sits between your app and Ethereum, endpoint reliability directly affects user experience and transaction success. Ethereum RPC endpoint options Think of RPC choices as a maturity curve: public for early testing, managed for production, self-hosted for maximum control. Public Ethereum RPC endpoint Best for: Development, learning, prototyping, low-traffic testing Public RPC endpoints are shared infrastructure run by the community. They’re free, require no authentication, and work immediately. For Sepolia testnet, https://rpc.sepolia.org provides community-maintained access. The reality: Rate limits: Shared endpoints throttle aggressive usage. When you hit limits, requests fail with 429 errors. Unpredictable performance: Response times vary based on total load from all users. During network congestion, latency spikes. No SLA: Community endpoints can disappear, change URLs, or go offline without notice. Limited features: Archive data, debug traces, and advanced RPC methods often unavailable. ⚠️ Important: There is no official Ethereum Foundation public RPC for mainnet. Any “free mainnet RPC” you find online is community-run with unknown reliability guarantees. Private-managed Ethereum RPC endpoint Best for: Production applications, high-traffic dapps, businesses requiring uptime guarantees Managed RPC providers (like Chainstack) operate dedicated or isolated infrastructure with authentication, monitoring, and support. You get your own endpoint with defined capacity. What you gain: Predictable performance: Dedicated or better-isolated capacity means your traffic doesn’t compete with others. Higher rate limits: API keys with defined request budgets. No surprise 429 errors during traffic spikes. SLA-backed uptime: Provider guarantees (typically 99.9% or higher). When downtime happens, you know who to contact. Archive & debug access: Full historical state queries and transaction traces without maintaining your own archive node. WebSocket stability: Persistent connections for real-time event monitoring without constant reconnection. The trade-off: Cost. You pay for reliability, but you eliminate the hidden costs of downtime, debugging rate limit issues, and lost users. Chainstack Self-Hosted Best for: Data sovereignty, compliance requirements, enterprise security policies Chainstack Self-Hosted deploys Ethereum nodes directly in your cloud infrastructure (AWS, GCP, Azure, etc.), while Chainstack handles all the operational complexity. This gives you data sovereignty without the operational burden of running nodes yourself. How it works: Your infrastructure: Nodes run in your account. Data never leaves your network. Chainstack manages: Deployment, monitoring, upgrades, scaling, and troubleshooting. You get enterprise-grade node operations without hiring a DevOps team. Full control: Your nodes, your data, your compliance requirements met. Perfect for regulated industries or enterprises with strict data governance policies. The key difference: This isn’t “run Geth yourself.” It’s “Chainstack runs it for you, in your infrastructure.” You get the benefits of data sovereignty and managed operations—no choosing between them. Typical use cases: Financial institutions with data residency requirements Enterprises that cannot send data to third-party infrastructure Teams that need SOC 2 / ISO compliance with node access in their own VPC Organizations requiring audit trails showing data never left their network Learn more: Deploy Chainstack Self-Hosted Ethereum nodes Quick comparison: which option fits your needs? TypeReliabilityCostBest ForPublic RPCShared, variableFreeDevelopment, prototypingPrivate ManagedSLA-backed, predictablePay-per-use or subscriptionProduction applicationsChainstack Self-HostedData sovereignty + managed opsYour infrastructure costs + Chainstack feeCompliance, data residency, enterprise HTTPS vs WebSockets Transport protocol choice affects connection patterns and suitability for different application types. HTTPS and WebSockets provide different trade-offs in connection model and responsiveness. HTTPSWebSocketsRequest-response modelPersistent connectionEach query requires a new connectionLower latency for frequent queriesSuitable for: intermittent queries, simple integrationsSuitable for: real-time monitoring, event-driven applications Which Ethereum network should you use in 2026? Ethereum Mainnet: Production applications with real economic value. Every transaction costs real ETH in gas fees. Use mainnet only when your smart contracts are audited and thoroughly tested. Sepolia Testnet: The recommended testnet for dapp and smart contract development. Sepolia is long-term supported and has a stable validator set. Use Sepolia for integration testing and staging environments. Chain ID: 0xaa36a7 (11155111) Hoodi Testnet: Designed for validator and staking-provider testing. If you build validator tooling or staking infrastructure, use Hoodi. For most dapps, use Sepolia. 💡 Need testnet ETH? Chainstack provides both Sepolia and Hoodi faucets, so you can fund test wallets quickly during development and QA. How to get a private Ethereum RPC endpoint using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Ethereum as the blockchain. Choose the network: Ethereum Mainnet for production Ethereum Sepolia or Hoodi Testnet for testing Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. Test your endpoint in 10 seconds curl -X POST "$ETH_RPC_URL" -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' Expected: Mainnet returns chain ID 0x1 Sepolia returns chain ID 0xaa36a7 (11155111) Connect from your application Using ethers.js: import { JsonRpcProvider } from "ethers"; const provider = new JsonRpcProvider(process.env.ETH_RPC_URL); const blockNumber = await provider.getBlockNumber(); console.log(`Current block: ${blockNumber}`); Using web3.js: import { Web3 } from "web3"; const web3 = new Web3(process.env.ETH_RPC_URL); const blockNumber = await web3.eth.getBlockNumber(); console.log(`Current block: ${blockNumber}`); Using Chainlist Chainlist can be used to add Ethereum to wallets (for example, Rabby, Rainbow, or MetaMask), but it does not provide RPC infrastructure. It typically relies on public or community RPC endpoints, so for production usage any RPC URL obtained via Chainlist should be replaced with a managed RPC endpoint such as Chainstack. Production readiness checklist Before launching your application, verify these infrastructure requirements: Fallback provider configured: Have a backup RPC endpoint. If your primary fails, your app should automatically retry with a secondary provider. Request timeouts set: Configure reasonable timeouts (5-10s for standard calls, 30s+ for archive queries). Don’t let requests hang indefinitely. Retry logic implemented: Transient failures happen. Implement exponential backoff for failed requests. Chain ID validated: Always verify you’re connected to the expected network. Accidentally using testnet in production causes obvious problems. Monitoring enabled: Track RPC response times, error rates, and request volumes. Set up alerts for degraded performance. API keys secured: Never commit RPC URLs to Git. Use environment variables or secret management tools. Troubleshooting common issues IssueLikely CauseHow to Fix429 Too Many RequestsYou are exceeding your RPC plan limits or polling too aggressively.Add caching, reduce polling frequency, batch requests where possible, and add a fallback RPC provider.Wrong chain ID (eth_chainId)Your app is pointed to the wrong network endpoint (Mainnet vs Sepolia).Verify eth_chainId on startup and fail fast if it doesn’t match expected (0x1 Mainnet, 0xaa36a7 Sepolia).Request timeouts (ETIMEDOUT)Endpoint latency spikes, poor region routing, or temporary provider load.Add retries with exponential backoff, set realistic timeouts, and use a region closer to your backend.WebSocket disconnectsIdle timeouts or unstable long-lived connections.Implement auto-reconnect with jitter, heartbeat/ping logic, and backfill missed events using eth_getLogs.Transactions stuck in pendingGas fee too low or nonce management issues under load.Use dynamic fee estimation, monitor pending nonce, and support replacement/cancel transaction strategy.Historical queries failYou’re using a full node endpoint for archive-level queries.Switch to an archive-capable RPC endpoint for deep historical state or wide-range analytics queries. Conclusion Getting an Ethereum RPC endpoint in 2026 is straightforward: choose Sepolia for testing, Mainnet for production, and prefer managed private RPC over shared public endpoints when reliability matters. Use HTTPS for standard calls and WSS for real-time subscriptions. Before launch, validate chain ID, set retries/timeouts, and add fallback providers. That gives you a stable RPC layer you can scale with as traffic grows. The expensive mistake is not paying for RPC. It’s discovering too late that your current endpoint cannot support your traffic profile. Deploy your Ethereum RPC node on Chainstack and get enterprise-grade infrastructure in under 60 seconds. Building on Ethereum? Deploy your Ethereum node on Chainstack → FAQ Can I use ethers.js or web3.js with Ethereum RPC endpoints? Yes. Both work with standard JSON-RPC providers. Do I need my own node to build on Ethereum? No. Most teams start with managed RPC providers and only move to self-hosting when they need maximum decentralization or have specialized requirements. Running nodes is operationally complex and expensive. Is a free public endpoint enough for production? Almost never. Public endpoints can work for development and experimentation, but production applications require predictable uptime backed by SLAs, higher rate limits to handle real traffic, responsive support when issues arise, and archive access for historical queries. The hidden cost of “free” infrastructure typically appears during peak traffic, when downtime and rate limits directly impact users and revenue. Should I use Sepolia or Hoodi? Use Sepolia for dapp and smart contract development. Use Hoodi only if you’re building validator tooling or testing staking infrastructure. For 95% of developers, Sepolia is the right choice. What’s the difference between managed and public RPC providers? Managed providers typically offer stronger uptime guarantees, higher throughput tiers, and support channels. Public endpoints are still valuable for development, but they are best-effort by design. How do I migrate from public to private RPC without downtime? Migrate without downtime by using a fallback provider pattern. Set your Chainstack endpoint as the primary RPC, keep your existing public endpoint as a secondary fallback, and run both in parallel for 24–48 hours while monitoring latency and error rates. Once performance is stable and consistent, remove the public fallback. Most modern Web3 libraries support this setup natively through FallbackProvider or equivalent multi-endpoint configurations. What should I monitor on my Ethereum RPC layer? Track latency (p95/p99), error rate, rate-limit responses (429), WebSocket reconnect frequency, and chain sync/block lag. Alert on threshold breaches before users are affected. Related Reading Best Ethereum RPC providers in 2026 Ethereum clients — Geth and Erigon: Deep dive Ethereum debug_trace APIs: Deep dive Ethereum’s transaction pool (mempool) Ethereum: Asset tokenization with Embark #### How to get an Optimism RPC endpoint in 2026 TL;DR Developers need Optimism RPC access to interact programmatically with OP Mainnet and OP Sepolia Testnet for development, testing, and production workloads. Reliable RPC infrastructure affects integration stability, operational cost, and the ability to serve real-time applications. Public endpoints are convenient for quick testing but are shared and may be rate-limited; private or managed endpoints provide dedicated capacity and service-level assurances. Choose the endpoint type that matches your reliability, throughput, and operational requirements. Before choosing an Optimism RPC endpoint, it’s important to understand what Optimism is and how it differs from Ethereum L1. Optimism RPC endpoint options Choosing the right RPC endpoint involves evaluating trade-offs between cost, reliability, and operational control. The next sections provide a comparison of the benefits and limitations involved. Public RPC endpointsPrivate RPC endpointsFree and community-operatedDedicated infrastructureRate-limited and shared infrastructureHigher throughput and reliabilitySuitable for testing and developmentSLA-backed uptimeUnreliable for production workloadsSuitable for production applications Private RPC is preferred for production use. Transitioning to access a private RPC endpoint can enhance your application’s performance and reliability. Public Optimism RPC endpoints (with limitations) Mainnet: https://mainnet.optimism.io (Optimism Docs) Testnet: https://sepolia.optimism.io (Optimism Docs) The listed public endpoints are community or foundation-provided resources and are shared infrastructure. Public endpoints commonly implement rate limiting and request throttling to protect service availability. Uptime and performance characteristics are not guaranteed for production workloads. For production applications, a managed or private RPC endpoint is generally recommended. Warning about Chainlist and public endpoints Chainlist can be used to add Optimism to wallets (for example, MetaMask or Rabby Wallet), but it does not provide RPC infrastructure. It typically relies on public or community RPC endpoints, so for production usage any RPC URL obtained via Chainlist should be replaced with a managed RPC endpoint such as Chainstack. Full node vs archive Optimism node Optimism nodes can be configured to store varying amounts of historical data. Full nodes typically store recent blockchain state, while archive nodes retain complete historical data from genesis. Full nodeArchive nodeStores recent blockchain state (recent blocks and transactions)Stores complete historical blockchain data from genesisSuitable for: sending transactions, querying current state, real-time monitoringSuitable for: analytics, explorers, historical queries, compliance HTTPS vs WebSockets Transport protocol choice affects connection behavior, latency characteristics, and suitability for different application patterns. HTTPS is a request-response protocol using per-request connections, while WebSockets provide a persistent connection suitable for frequent or realtime interactions. HTTPSWebSocketsRequest-response modelPersistent connectionEach query requires a new connectionLower latency for frequent queriesSuitable for: intermittent queries, simple integrationsSupports real-time subscriptions (if available)Suitable for: real-time monitoring, event-driven applications For details on using Optimism RPC with wallets, development frameworks, client libraries, and HTTP or WebSocket connections, refer to the Optimism documentation tooling. How to get private Optimism RPC endpoint using Chainstack Log in to the Chainstack console (or sign up if needed). Create a new project. Select Optimism as the blockchain. Choose the network: OP Mainnet for production OP Sepolia Testnet for testing Deploy a managed RPC node. Open the project dashboard and copy the generated HTTPS and WebSocket RPC endpoints. In addition to managed RPC nodes, Optimism provides community-operated endpoints with notable limitations. After deploying your Optimism RPC endpoint, you can use it for real-world integrations such as cross-layer transfers. Bridge ether from Ethereum L1 to Optimism L2 for a step-by-step example of bridging ETH using a private RPC endpoint. Chainstack Pricing Chainstack offers transparent, request-based pricing for Optimism RPC: Free tier: 3M requests/month (~25 RPS) – ideal for development and testing Growth plan: $49/month for 20M requests (~250 RPS) Pro plan: $199/month for 80M requests (~400 RPS) Business plan: $499/month for 200M requests (~600 RPS) Enterprise plans: Custom RPS configurations with Unlimited Node add-on for flat-rate, unmetered access Unlike compute-unit-based pricing models, Chainstack’s request-based approach makes costs predictable regardless of which RPC methods you call. This is significantly more cost-effective than running your own Optimism node, which requires dedicated hardware, maintenance, and bandwidth costs. View detailed pricing → Optimism RPC considerations for 2026 Throughput and request limits — Ability to sustain high request volumes without aggressive throttling or degraded performance; choose providers that align with expected traffic patterns. Reliability and uptime behavior — Consistency under load and resilience during network instability are critical for production applications and user-facing services. WebSocket stability — Stability of persistent connections matters for real-time monitoring and event-driven integrations that rely on lower-latency updates. Archive data availability — Access to complete historical state is required for analytics, explorers, and compliance workflows that query historical data. Tooling and ecosystem maturity — Tooling support varies; evaluate SDKs, libraries, and integrations that simplify development and operations. Cost predictability — Understand how RPC usage costs scale with traffic and whether pricing remains predictable as usage grows. Dependency on L1 for finality — As an L2, RPC behavior can be influenced by L1 settlement timing; network-specific considerations apply. Cross-chain RPC traffic — Increased load from cross-chain monitoring and coordination can affect RPC capacity planning. Superchain interoperability — For deployments on the OP Stack, RPC usage may be influenced by shared infrastructure and cross-domain coordination. Provider selection — Multiple providers offer Optimism RPC (Alchemy, QuickNode, Chainstack, Ankr). Evaluate based on pricing model (request-based vs compute-units), uptime SLAs, and integration complexity. Chainstack offers request-based pricing and 99.99%+ uptime. Conclusion In summary, public RPC endpoints are suitable for testing and development, while managed RPC providers are the recommended production option. While several providers support Optimism (Alchemy, QuickNode, Ankr), Chainstack stands out for transparent request-based pricing, 99.99%+ uptime guarantees, and simple deployment. Getting started with Optimism on Chainstack is quick and easy. Developers can deploy a reliable RPC node for mainnet access in seconds—no complex setup or hardware provisioning required. Chainstack provides low-latency Optimism RPC endpoints powered by globally distributed infrastructure. This ensures consistent performance for building, testing, and scaling real-world applications, including DeFi, trading, and stablecoin infrastructure. Key features: Fast deployment through an intuitive console Low-latency access via global infrastructure 99.99%+ uptime with multi-cloud failover Free tier (3M requests/month) and scalable paid plans from $49/month Support for dedicated and shared RPC nodes Secure access with API keys and role-based permissions Start for free, connect your application to a production-grade Optimism RPC endpoint, and scale with dedicated infrastructure built for performance. Building on Optimism? Deploy your Optimism node on Chainstack → FAQ What’s the difference between L1 and Optimism RPC endpoints? Optimism RPC endpoints target the OP Mainnet and OP Sepolia Testnet networks and are intended for interacting with those layers specifically. Network-specific considerations apply when choosing endpoints for L1 versus L2 access. How much does a private Optimism RPC endpoint cost? Chainstack offers a free tier with 3M requests/month (~25 RPS), which is suitable for development and testing. Paid plans start at $49/month for 20M requests (~250 RPS). Pricing is transparent and request-based, so you always know what you’ll pay. For high-volume applications, Enterprise plans offer custom RPS configurations and flat-rate unlimited options. Does Optimism support the same SDKs and tooling as other L2 networks? Tooling support varies across ecosystems, but common JavaScript SDKs and the Optimism SDK (JavaScript utilities) are available for developers working with Optimism. Consult Optimism documentation and provider guidance for integration details. When should I use Optimism RPC instead of Ethereum L1 RPC? Use Optimism RPC endpoints when your application needs direct access to OP Mainnet or OP Sepolia Testnet network state and transactions. For workloads tied to those networks, Optimism RPC provides the appropriate connectivity and data scope. How do SDKs interact with Optimism RPC endpoints? Developers typically use ethers.js, Web3.js; Optimism SDK (JavaScript utilities) when integrating with Optimism RPC endpoints. Tooling support varies across ecosystems, so validate compatibility with your chosen SDKs. Do I need archive node access for my application? No, most applications don’t. Standard full nodes are sufficient for sending transactions, querying current state, and real-time monitoring.Archive nodes are only necessary for specific use cases like block explorers, historical analytics, compliance audits, or querying old contract states. Since archive nodes cost more, only use them if you specifically need complete historical blockchain data. #### How to get Base RPC endpoint in 2026 Introduction Base is one of the most important Ethereum L2s for production apps in 2026, but getting a Base RPC endpoint is no longer just about copying a public URL from a docs page. Base offers standard public RPC endpoints, Flashblocks-aware endpoints for low-latency reads, and the usual choice between public and managed infrastructure. Rollup Chains By TVL. Source: DeFiLlama That means the real question is not only where to find a Base RPC URL, but which type of Base endpoint your application actually needs. A wallet, payment app, indexer, or trading system can all connect to Base through JSON-RPC, but they will not all succeed on the same infrastructure. This guide covers how to get a Base RPC endpoint, how Base RPC differs from standard Ethereum RPC in practice, and when to move from public access to production-grade infrastructure. What is a Base RPC endpoint? Base is an Ethereum layer 2 rollup developed by Coinbase, running on the OP Stack. It works just like any EVM-compatible chain: your app talks to it through an RPC endpoint. A Base RPC endpoint is simply a URL that lets your app send JSON-RPC requests to a node synced with the Base chain. There are two types of RPC endpoints you’ll find: Public RPC endpoints – Free, open-access URLs shared by the community or providers. These don’t require authentication and are great for testing and prototyping. Private RPC endpoints – Access-controlled URLs from platforms like Chainstack, which come with actual guarantees: lower latency, higher uptime, usage analytics, and better performance overall. Most devs start with a public RPC when in early-stage development or prototyping. Yet, as your dApp scales, the free endpoint will start failing you; that’s why switching to a private Base RPC endpoint becomes essential for performance, reliability, and speed at scale. How Base RPC differs from Ethereum RPC Base uses the Ethereum JSON-RPC standard, but the infrastructure behavior is not identical to Ethereum mainnet. DimensionEthereum mainnet RPCBase RPCWhy it mattersNetwork modelL1 execution + PoS settlementOP Stack L2 with sequencer-based executionBase supports Ethereum tooling, but confirmation and execution flow differ from L1Public RPC postureDepends on providerOfficial public endpoints are rate-limited and not suitable for productionPublic Base RPC is fine for testing, but not for production reliabilityFlashblocks supportNot applicableBase also offers Flashblocks-aware endpoints with earlier preconfirmed stateLow-latency apps can read state earlier than with standard RPC alonepending behaviorStandard pending-state semanticsFlashblocks-aware endpoints can expose preconfirmed pending stateImportant for real-time apps, games, and trading systemsBest fitL1-native apps and settlement-critical workflowsConsumer apps, wallets, backends, and low-latency Base workloadsEndpoint choice should match workload, not just chain support Base RPC endpoint options There are several ways to connect to Base, and they are not interchangeable. The right choice depends on whether your app needs simple development access, production stability, historical data, or low-latency preconfirmed reads. OptionExample / formatRequires authBest forMain trade-offPublic standard Base RPChttps://mainnet.base.org / https://sepolia.base.orgNoTesting, prototyping, low-volume developmentRate-limited and not suitable for productionPublic Flashblocks-aware Base RPChttps://mainnet-preconf.base.org / https://sepolia-preconf.base.orgNoTesting Flashblocks behavior and preconfirmed readsAlso rate-limited and not suitable for productionManaged standard private Base RPCProvider-issued authenticated endpointYesProduction apps, wallets, payment systems, general backendsPaid infrastructure, but with reliability and observabilityManaged Flashblocks-enabled Base RPCFlashblocks-ready provider endpoint on supported node typesYesLow-latency apps, games, bots, trading-style workloadsRequires provider support and correct handling of preconfirmed stateArchive Base RPC endpointManaged archive node or archive-enabled endpointUsually yesAnalytics, indexers, historical queries, large backfillsHigher cost than standard full-node accessSelf-hosted Base nodeSelf-managed OP Stack node deploymentNo external authTeams needing full control and custom infrastructureHighest ops overhead: sync, storage, upgrades, monitoring For most teams, the decision is not just public vs private, but whether standard Base RPC is enough or whether Flashblocks-aware and archive-capable infrastructure is required. How to get a public Base RPC URL Base ecosystem offers a few free public RPC endpoints, which are perfect for experimenting, learning, or spinning up small-scale apps. Here are a few places to find public Base RPC URLs: Base official documentation: Base provides public RPC endpoints maintained by ecosystem contributors. This is a rate-limited global endpoint that offers basic access to the Base mainnet. But note the alert on the Base documentation page: RPC endpoint is Rate-limited and not for production systems. One example is: https://mainnet.base.org. Link Third-party infrastructure aggregators: Platforms like Chainlist list public endpoints for networks like Base. These endpoints are sometimes wrapped with caching or rate limits, depending on the provider. Community GitHub repositories: Some projects aggregate and share public RPC lists via GitHub. Repositories like ethereum-lists/chains are good places to look for up-to-date RPC URLs with metadata. Is public Base RPC enough for production? Usually not. A public Base RPC endpoint is a good starting point for developers who want to test contracts, connect a wallet, or run low-volume scripts. But once your application starts serving real users, public infrastructure becomes the weak point. The biggest limitations are shared capacity, rate limits, no performance guarantees, and limited observability. If your frontend depends on fast state reads, if your backend listens to events continuously, or if your bot reacts to new state in real time, public Base RPC will eventually create avoidable failures. Pros of public RPCs: No setup required, just copy and paste the URL. Free to use: no account or API key needed. Ideal for prototyping and testing environments. Cons of public RPCs: Rate limits – Because public RPC endpoints have a cap on the call volume, your dApp could stall or fail during high traffic. Performance bottlenecks – Since you’re sharing infrastructure, delays and timeouts are pretty common, especially during peak usage. No data – Tracking usages is impossible, along with latency and error rates. Security risks – A public endpoint can mean that traffic gets intercepted or messed up if not encrypted; or your requests get rate-limited or blocked arbitrarily. That is why public RPC is best treated as development infrastructure. For production systems, a managed Base RPC provider is the safer default. 📖 Tip: Public Base RPC endpoints and faucets are great for development and testing, but production applications should always run on managed or dedicated Base RPC infrastructure. How to get a private Base endpoint When you outgrow public endpoints, it’s time to look at private infrastructure. Here is where Chainstack, one of the top Base RPC node providers, comes in. Chainstack offers key benefits, which include high-performance and production-grade Base RPC endpoints. Why choose Chainstack for Base Global coverage – There is reduced latency for worldwide users as Chainstack’s Global Nodes are automatically geo-balanced. Dedicated nodes – Enjoy full control over your dedicated Base node and run it from a location of your choice. Unlimited Node add-on Traffic caps will no longer be a worry, as flat-fee RPS-tiered node endpoints with no traffic limitations are available. Archive access – Access full historical blockchain states for advanced analytics, data indexing, or debugging via Base archive nodes. Security – Utilizing IP allowlists, Origin restrictions, JWT authentication, and key rotation within a SOC2-certified infrastructure are all methods Chainstack employs to ensure security. Monitoring – Real-time metrics and error rates on a method-level can be viewed directly within the Chainstack console. Uptime – Enterprise-grade SLAs and real-time 24/7 monitoring ensure superior uptime. Getting started with Chainstack Sign up for a Chainstack account. Navigate to Projects and create a new project. Use the Node wizard to deploy a Base node. (Mainnet or Sepolia Testnet) Decide whether you want Global Node, Trader Node (region-specific), or Unlimited Node. Copy the endpoint URL and start using it in your app. Here’s an example of a Chainstack Base endpoint: https://base-mainnet.core.chainstack.com/<your-access-token>/ Authenticated access allows you to push traffic at scale and monitor every user interaction while ensuring a fast and stable user experience at all times. When testing on Base Sepolia, you can deploy a Base RPC endpoint on Chainstack and request test ETH from the Chainstack Base faucet in the same platform, which simplifies development setup. Chainstack pricing for Base RPC Chainstack gives you several ways to run Base RPC depending on how much traffic and control your application needs. Developer plan: free entry point for testing and low-volume development Growth / Pro / Business: shared managed infrastructure for production workloads Unlimited Node: flat-fee RPS-tiered access when you want predictable cost under sustained traffic Dedicated nodes: isolated Base infrastructure for workloads that need more control, better consistency, or custom deployment This matters because Base usage can scale quickly from simple wallet reads to payment rails, bots, analytics, and low-latency application logic. A pricing model that looks cheap on paper can become unpredictable if it depends on complex per-method weighting. Chainstack’s structure is easier to model operationally because it provides a clear upgrade path from free testing to dedicated production infrastructure. Explore the pricing tiers → Configure Base RPC in wallets Open the EVM wallet (Metamask, Rabby) and click the chain icon in the top left corner. Navigate to Base Mainnet and click the three-dot icon, then Edit. Select dropdown “Default RPC URL”. Click “+ Add RPC URL” In the “Add RPC URL” form specify your Public or Chainstack Base Mainnet RPC URL. Troubleshooting common Base RPC issues IssueWhat it usually meansPractical fix429 Too Many RequestsPublic endpoint or low-tier plan is rate-limiting your trafficReduce burst traffic, add retry/backoff, or move to managed RPCWrong chain IDYour app is pointed to the wrong Base networkVerify 8453 for mainnet and 84532 for Base SepoliaWebSocket disconnectsShared endpoint instability or too many active subscriptionsReduce subscription load or use a production-grade providerSlow reads during traffic spikesShared infrastructure is saturatedMove critical workloads to private or dedicated RPCMissing historical dataYou are querying a full node instead of an archive nodeUse archive access for deep historical queriesUnexpected pending-state behaviorYou are using Flashblocks-aware endpoints without handling preconfirmed dataTreat pending/preconfirmed state separately from finalized state Production readiness checklist Before you rely on a Base RPC endpoint in production, confirm the following: eth_chainId returns the expected network (8453 for Base mainnet, 84532 for Base Sepolia) Your app supports retry and backoff on transient failures You have a fallback RPC endpoint configured for failover WebSocket subscriptions remain stable under your expected load Archive access is available if your workload depends on historical state or backfills Monitoring is in place for latency, error rate, and request volume If you use Flashblocks-aware endpoints, your app treats preconfirmed state correctly Conclusion Public Base RPC endpoints are useful for interacting with the Base blockchain. They are most useful for early-stage projects, during testing, and in environments with low traffic. As your Web3 application grows, however, availability alone will not be sufficient; you will also require consistency, performance, and observability. This is where private, reliable Base infrastructure, such as Chainstack, becomes useful. Whether you’re building a DeFi protocol, data indexer, or Web3 game, Chainstack provides you with scalable Base RPC access, real-time insights, secure authentication, and a growth-aligned pricing model. Begin with a public endpoint, but have a transition plan ready to shift it to a private one. Start building with Chainstack → FAQ What is a Base RPC endpoint? A Base RPC endpoint is a URL that lets your application send JSON-RPC requests to a node synced with the Base network. What is the official Base public RPC URL? For Base mainnet, the standard public RPC is https://mainnet.base.org. For Base Sepolia, it is https://sepolia.base.org. Is the Base public RPC good enough for production? No. Base documentation explicitly notes that the public RPC is rate-limited and not intended for production systems. What is the difference between standard Base RPC and Flashblocks-aware RPC? Standard Base RPC exposes normal block state. Flashblocks-aware RPC exposes preconfirmed pending-state data earlier for low-latency applications. When do I need an archive Base node? You need archive access for deep historical state queries, large-scale event backfills, tracing, and analytics-heavy workloads. Does Base RPC work with MetaMask and standard Ethereum tooling? Yes. Base is EVM-compatible, so standard Ethereum tools such as MetaMask, ethers.js, viem, web3.py, and Foundry work with Base RPC endpoints. When should I switch from public Base RPC to private infrastructure? Switch when your app starts depending on stable latency, subscriptions, production uptime, or historical-query reliability. What is the chain ID for Base mainnet and Base Sepolia? Base Mainnet: 8453; Base Sepolia: 84532 Related Reading Flashblocks on Base: 200ms preconfirmations for lightning-fast UX Best Base RPC providers for on-chain applications in 2026 Best Ethereum RPC providers in 2026 Base: Deploy an ERC-721 contract with Hardhat #### How to get Hyperliquid testnet tokens with the Chainstack faucet Hyperliquid is pushing for sub-second on-chain trading. To build on it, you’ll need faucet HYPE, a working RPC URL, and a reliable setup. We cover how to do it on Chainstack. Hyperliquid is popping up in more and more builder chats. Traders are wiring bots, devs are stress-testing contracts, and everyone wants to see what an order-book chain with sub-second finality feels like. Test HYPE is still scarce though, and that slows the loop. So we decided to ship one. On Chainstack, you can now request Hyperliquid testnet HYPE directly from our Hyperliquid faucet. On top of that, we’ve made the stack end-to-end: mainnet and testnet coverage, HyperEVM (full + archive), HyperCore, plus docs and node management through the console. In this guide, we’ll show you how to grab free HYPE test tokens, set up your Hyperliquid testnet RPC endpoint, and start building. How the Hyperliquid testnet faucet works Before you push anything to mainnet, you dry-run the flow — deploy a contract, fire transactions against a Hyperliquid testnet RPC, or check that your scripts handle responses the way they should. For any of that, you need HYPE. We’re one of the first to ship a Hyperliquid faucet built for that. It’s tied to your wallet address and lets you claim 1 HYPE every 24 hours, with no Twitter authentication in the mix. Just sign in, point it at your wallet, and you’re ready to test. From there, you can use your balance to cover gas on testnet, validate deployments on HyperEVM, or run automated checks in your dev loop. And when you’re ready to go beyond test tokens, you can deploy a Hyperliquid node in the console and plug into mainnet or testnet RPCs all in one place. How to use the Hyperliquid testnet faucet on Chainstack Getting test HYPE from our Hyperliquid faucet is simple. Sign in — Log into your Chainstack console. Get your API key — In the console, go to Settings → API keys and copy an active key. You’ll need it to authenticate with the faucet. Open the faucet — Navigate to the Hyperliquid faucet page and paste your API key when prompted. Enter your wallet address — Paste the address you want to fund. Request tokens — Submit the claim. You’ll receive 1 HYPE every 24 hours. Confirm balance — Check your wallet or query your Hyperliquid RPC endpoint. Once your wallet has balance, you can use it to pay gas on testnet, deploy contracts, or run integration scripts against HyperEVM. If you need stable, high performance infrastructure, alongside tokens, you can spin up a Global Node for quick tests or a Dedicated Node for latency-sensitive workloads. Both expose HTTPS and WebSocket RPC URLs that slot straight into wallets, frameworks, or custom tooling. Get test HYPE What you can do with Hyperliquid testnet HYPE On Hyperliquid, nothing moves without HYPE, even on testnet. Gas covers smart contracts on HyperEVM, transaction calls, and anything you push through a Hyperliquid testnet RPC. That makes a faucet a baseline tool if you want to: Deploy and test contracts in a safe loop Run bots or scripts against real RPC responses Validate dApp or infra integrations before mainnet Backtest or stress test without burning real funds Onboard teammates or teach flows without risk Once you’ve got tokens in your wallet, the natural move is to wire them into a node you control. In the Chainstack Console you can spin up a Hyperliquid node, copy the HTTPS or WebSocket RPC URL, and start routing calls through your own endpoint. Deploy a Hyperliquid node Hyperliquid tooling Beyond the faucet and nodes, Hyperliquid comes with SDKs and APIs you can wire into your stack. There’s an official Python SDK and Rust SDK for trading applications, plus the JSON-RPC API to query chain state on HyperEVM. Dedicated Nodes also unlock system transactions between HyperCore and HyperEVM. For the full set of SDKs and integration guides, check the Hyperliquid tooling docs. Wrap up: more for Hyperliquid builders Faucet HYPE gets you moving, but most builds need more than gas. On Chainstack you can run HyperEVM archive nodes to query past blocks, use Debug & Trace for transaction-level insights, or stream state changes in real time over WebSockets. We also maintain the Hyperliquid method availability table — 100+ RPC methods mapped with live status, so you always know what’s callable. For trading flows, the Hyperliquid API reference covers REST and WebSocket endpoints for order submission, market data, and account queries. Understanding how these endpoints map to HyperCore and HyperEVM is essential, since not all functionality is available through RPC nodes. And if you’d rather start from code than docs, our GitHub repo includes a starter trading bot wired for Hyperliquid RPC. Between the faucet, HyperCore + HyperEVM nodes (Global or Dedicated), and the docs, you’ve got an end-to-end setup: test on faucet HYPE, debug against stable infra, then move to mainnet without rewriting your stack. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ How do I get Hyperliquid testnet tokens? You can claim them from the Chainstack Hyperliquid faucet. Enter your wallet address and you’ll receive 1 HYPE every 24 hours. No Twitter authentication is required. Is Hyperliquid EVM-compatible? Yes. Hyperliquid runs Hyperliquid EVM, an EVM-compatible execution layer that brings smart contracts into an order-book environment. What are hype tokens used for? HYPE tokens pay gas fees on both mainnet and testnet. On testnet you can claim 1 HYPE per 24 hours from the faucet; on mainnet, HYPE covers contract deployments, transfers, and trading flows. Can I trade perpetual futures on testnet? Yes. Hyperliquid supports perpetual futures markets on both mainnet and testnet. Faucet HYPE lets you simulate order placement, run bots against the order book, and test how your integration behaves — all without touching real funds. Are there rate limits? Yes. Public RPC endpoints are shared and subject to rate limits. For heavier loads, you can deploy a Chainstack node to get predictable performance. #### How to get Monad RPC endpoint Monad Mainnet and Testnet are now available on Chainstack! You can spin up Monad RPC endpoints in seconds and start building on one of the fastest EVM-compatible chains out there. Monad processes 10,000 transactions per second through parallel execution while staying fully compatible with Ethereum tooling. That means you get the performance boost without rewriting your contracts or switching frameworks. Your Solidity code, your deployment scripts, your ethers.js setup, everything just works. In this guide, we’ll show you exactly how to get a Monad RPC endpoint on Chainstack, connect it to your project, and start making calls. No fluff, just the practical steps you need. What you get with Monad RPC on Chainstack Before we jump into setup, here’s what you’re getting: High throughput without the wait. Monad handles 10,000 TPS through parallel transaction execution. If your app needs to process heavy transaction volumes—DeFi protocols, gaming applications, NFT platforms—Monad gives you room to scale without hitting congestion. Global infrastructure that actually performs. Chainstack routes your requests through the nearest data center. Whether your users are in New York, London, or Singapore, they get low-latency responses from nodes optimized for high traffic. Standard Ethereum RPC. Every eth_ method you’re used to works here. eth_sendRawTransaction, eth_call, eth_getBalance, eth_getLogs—they all work exactly as expected. Use Hardhat, Foundry, Remix, or any Ethereum dev tool without modifications. Create your Monad RPC endpoint Log into your Chainstack account. If you don’t have one yet, sign up—it takes about 30 seconds. Once you’re in: Click Create project or select an existing project Click Join network Select Monad from the protocol list Choose Mainnet or Testnet depending on where you’re building Click Deploy node Your endpoint will be ready in seconds!Copy that URL. You’ll need it for everything else. Create Monad RPC endpoint Connect to Monad in your code Now let’s actually use that Monad endpoint. Here are the most common ways to connect: Using curl (quick test) bash curl -X POST https://monad-mainnet.core.chainstack.com/auth-key \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "eth_blockNumber", "params": [] }' Using ethers.js javascript import { ethers } from 'ethers'; const provider = new ethers.JsonRpcProvider( 'https://monad-mainnet.core.chainstack.com/auth-key' ); // Get latest block number const blockNumber = await provider.getBlockNumber(); console.log('Latest block:', blockNumber); // Get account balance const balance = await provider.getBalance('0xYourAddress'); console.log('Balance:', ethers.formatEther(balance)); Using web3.js javascript import Web3 from 'web3'; const web3 = new Web3('https://monad-testnet.core.chainstack.com/auth-key'); const block = await web3.eth.getBlock('latest'); console.log('Latest block:', block.number); Using Hardhat Update your hardhat.config.js: javascript module.exports = { networks: { monad: { url: 'https://monad-mainnet.core.chainstack.com/auth-key', accounts: [process.env.PRIVATE_KEY] }, monadTestnet: { url: 'https://monad-testnet.core.chainstack.com/auth-key', accounts: [process.env.PRIVATE_KEY] } } }; Deploy with: bash npx hardhat run scripts/deploy.js --network monad Using Foundry Update your foundry.toml: toml [rpc_endpoints] monad = "https://monad-mainnet.core.chainstack.com/auth-key" monad_testnet = "https://monad-testnet.core.chainstack.com/auth-key" Deploy with: bash forge create src/MyContract.sol:MyContract \ --rpc-url monad \ --auth-key $AUTH_KEY What makes Monad different (and why it matters) Monad executes transactions in parallel instead of one at a time. On a standard EVM chain, if you send 100 transactions, they process sequentially. On Monad, transactions that don’t conflict with each other run simultaneously across multiple threads. This matters when you’re building apps that need high throughput: DEXs processing thousands of swaps, games with intensive onchain activity, NFT platforms handling heavy minting, or any application where transaction volume creates bottlenecks. You also get single-slot finality and sub-second block times. That means faster confirmations and better UX for your users. The best part? You don’t need to change anything about how you build. Monad is fully EVM bytecode compatible. Your existing Solidity contracts deploy without modification. Your testing suites work. Your monitoring tools work. Everything you’ve built on Ethereum or other EVM chains ports over directly. Troubleshooting common issues Rate limits: If you’re hitting rate limits, upgrade your Chainstack plan or add more endpoints to distribute load. Connection timeouts: Check that you’re using the correct RPC URL and that your API key is included. Also verify your network configuration if you’re behind a firewall. Transaction failures: Make sure you have enough native tokens for gas. Check that your nonce is correct and that you’re not sending transactions too quickly. Contract deployment issues: Verify your compiler version matches what the network expects. Double-check that your constructor parameters are correct. Next steps You’re now connected to Monad through Chainstack. Your geo-balanced RPC endpoint is live and you can start building. If you need higher throughput or dedicated resources, check out Chainstack’s enterprise plan. For support or questions about your infrastructure setup, reach out to the Chainstack team through the console. #### How to get Monad testnet tokens with Chainstack faucet Monad is emerging as one of the fastest-growing networks, driven by its focus on sub-second finality and high-throughput execution. As more teams start experimenting and building early-stage applications, access to reliable infrastructure and test resources becomes critical for productive development. Developers are experimenting with smart contracts and stress-testing performance. But test MON is still scarce, which slows down experimentation. So we decided to ship one. On Chainstack, you can now request Monad testnet MON directly from our Monad faucet. Beyond the faucet, Chainstack provides production-grade infrastructure for Monad, including reliable RPC endpoints, archive access, documentation, and node management through the Chainstack console. In this guide, we’ll show you how to get free MON test tokens and start interacting with the Monad testnet. How the Monad testnet faucet works Before you push anything to mainnet, you dry-run the flow — deploy a contract, fire transactions against a Monad testnet RPC, or check that your scripts handle responses the way they should. For any of that, you need MON. We’re one of the first to ship a Monad faucet built for that. It’s tied to your wallet address and lets you claim 0.5 MON every 24 hours, with no Twitter authentication in the mix. Just sign in, point it at your wallet, and you’re ready to test. From there, you can use your balance to cover gas on testnet, validate smart contract deployments on Monad, or run automated checks in your dev loop. And when you’re ready to go beyond test tokens, you can deploy a Monad node in the console and plug into mainnet or testnet RPCs all in one place. ⚠️ Faucet requirements: To safeguard against misuse, the Chainstack faucet implements two key checksbefore disbursing funds: The requesting address must have a minimum balance of 0.08 ETH on theEthereum mainnet. The address should have a history of holding ETH on the mainnet; it shouldnot have been recently empty. These precautions help maintain the integrity of the faucet, ensuring fair andequitable access for all users. How to use the Monad testnet faucet on Chainstack Getting test MON from our Monad faucet is simple. Sign in — Log into your Chainstack console. Get your API key — In the console, go to Settings → API keys and copy an active key. You’ll need it to authenticate with the faucet. Open the faucet — Navigate to the Monad faucet page and paste your API key when prompted. Enter your wallet address — Paste the address you want to fund. Claim tokens — Submit the claim. You’ll receive 0.5 MON every 24 hours. Confirm balance — Check your wallet or query your Monad RPC endpoint. Once your wallet has balance, you can use it to pay gas on testnet, deploy contracts, or run integration scripts against the Monad testnet. If you need stable, high-performance infrastructure, alongside tokens, you can spin up a Global Node for quick tests or a Dedicated Node for latency-sensitive workloads. Both expose HTTPS and WebSocket RPC URLs that slot straight into wallets, frameworks, or custom tooling. Get test MON What you can do with Monad testnet MON On Monad, nothing moves without MON, even on testnet. MON is used to pay gas for smart contract deployments, transaction calls, and anything you send through a Monad testnet RPC. That makes a faucet a baseline tool if you want to: Deploy and test contracts in a safe loop Run bots or scripts against real RPC responses Validate dApp or infrastructure integrations before mainnet Backtest or stress-test without burning real funds Onboard teammates or teach flows without risk Once you’ve got tokens in your wallet, the natural next step is to wire them into infrastructure you control. In the Chainstack console, you can spin up a Monad node, copy the HTTPS or WebSocket RPC URL, and start routing calls through your own endpoint. Deploy a Monad node Monad tooling Beyond the faucet and nodes, Monad provides developer tooling you can integrate into your stack. You can interact with the network using standard EVM-compatible tooling over JSON-RPC, making it easy to work with smart contracts, query chain state, and run automated workflows. Monad works with familiar Ethereum developer tools and libraries, allowing you to reuse existing Solidity code, frameworks, and scripts without custom integrations. For the full set of SDKs, APIs, and integration guides, check the Monad tooling docs. Wrap up: more for Monad builders Faucet MON gets you moving, but most production-grade workflows need more than just gas. On Chainstack, you can run reliable Monad RPC infrastructure to query historical data, debug transactions, and stream state changes over WebSocket connections. If you prefer starting from code, Chainstack provides examples and reference implementations that show how to interact with Monad RPC endpoints using standard EVM-compatible tooling. The Monad API refers to the standard Ethereum-compatible JSON-RPC interface exposed by Monad RPC nodes. For application-level use cases built on top of Monad, you can also explore example projects such as a starter copy trading bot built for Kuru DEX and wired to Monad RPC. Between the faucet, stable RPC infrastructure (Global or Dedicated Nodes), and up-to-date documentation, you get an end-to-end setup: test with faucet tokens, validate against production-like infrastructure, and move to mainnet without reworking your stack. Additional resources Deep dive into Monad: speed, performance, and architecture — a detailed overview of how Monad works under the hood. Monad for builders 2026: a practical implementation guide — a hands-on guide to working with Monad testnet infrastructure, RPCs, and smart contracts. Monad & Berachain: blockchain usage weeks after mainnet — an analysis of early network activity and how builders are using these chains post-launch. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ How do I get Monad testnet tokens? You can claim them from the Chainstack Monad faucet. Enter your wallet address and you’ll receive 0.5 MON every 24 hours. No Twitter authentication is required. Is Monad EVM-compatible? Yes. Monad is EVM-compatible, which means you can deploy Solidity smart contracts and use standard Ethereum tooling and libraries. What are MON tokens used for? MON is used to pay gas fees on the Monad network. On testnet, MON covers smart contract deployments, transaction calls, and interactions sent through a Monad testnet RPC endpoint. Can I deploy and test smart contracts on testnet? Yes. Monad testnet is designed for safely deploying and testing smart contracts, running scripts, and validating integrations before moving to mainnet. Are there rate limits? Yes. Public RPC endpoints are shared and subject to rate limits. For predictable performance and higher throughput, you can deploy a Chainstack node and use dedicated RPC endpoints. #### How to get started as a DevRel in Web3: Career tips with our DevRel Lead, Ethan Francis The world of Web3, powered by blockchain, has opened up new avenues for developers to explore and innovate. Web3 is an innovative field where new things get built every single day so there is a growing need for developer relations professionals who can bridge the gap between developers and projects in this space. To gain insights into the world of DevRel in Web3, Crypto Jobs List had a conversation with our Developer Relations Lead, Ethan Francis. We’ll cover everything Ethan talked about and all the nuggets he shared in his talk for Developer Relations Professionals. And should you prefer to listen as you read you can tune in to the full CryptoJobsList interview: Figure 1: CryptoJobsList interview with Ethan Francis, DevRel Lead, Chainstack; Source: YouTube From enthusiast to DevRel Lead Our Developer Relations Lead, Ethan Francis started his journey in Web3 in 2020 when he was just 15 years old. He like many others got motivated from the post-pandemic altcoin run but then developed a keen interest in the tech behind blockchain. Already aspiring to pursue software engineering in college in a few years, Ethan focused on building his blockchain developer skills in 2021. He revisited Python, JavaScript, Web3.js, and other frameworks and libraries associated with Web3. During his learning journey, Ethan spent a significant amount of time in different communities and engaging with numerous people and even built a project that integrated with Discord and enabled a direct interface with EVM networks. A year later he decided to apply for jobs in the Web3 space and interviewed with us at Chainstack and came on board as a Developer Relations Manager. He spent six months working on DevRel at Chainstack and eventually transitioned into leading the DevRel team in 2023. Ethan emphasizes that DevRel requires a combination of technical skills, communication abilities, and content creation expertise. It serves as a unique way to leverage one’s skills and create meaningful connections with developers across web3. Understanding DevRel and its importance DevRel, short for developer relations, is a role that combines aspects of software development, marketing, communications, and business development. However, its specific focus and responsibilities may vary from project to project. The primary goal of DevRel is to engage with developers and build high-quality relationships with them.  Traditional marketing and ads often struggle to connect with developers due to the limited technical knowledge of most marketing professionals. DevRel serves as a middle ground, connecting marketing messaging with developers through content creation and technical expertise. This allows projects in Web3 to engage and interact with developers in a language that they understand and resonate with. Figure 2: Web3 DevRel areas of expertise DevRel is especially beneficial for companies like ours, which offer infrastructure products that allow developers to build robust Web3 products and bring them to the market faster through tools to build applications without fuss. Becoming a successful DevRel professional To excel in DevRel the key is to continuously optimize and improve your skill set. This includes honing your communication skills, content creation abilities, and engagement with developers. Additionally, since it’s crucial to have a deep understanding of application development and new technologies relevant to Web3 you should also spend as much time as you can building things and understanding how the web3 back end really works. In his conversation with Crypto Jobs List, Ethan also suggested focusing on a specific vertical within Web3 where you excel and then scaling your efforts on top of that. By understanding what developers want and tailoring your content to their needs, you can build a strong foundation for success as a DevRel. As long as you can provide value and demonstrate your competence, you can find opportunities in DevRel, so your age or location does not matter much when it comes to DevRel. “Developer Relations is an incredibly versatile role, meeting at the intersection of communication, content production, and technical aptitude. Succeeding in such a role requires a commitment to growing comfortable with the aforementioned skills and, in practice, finding ways to provide value to the community,” shared Ethan Francis, DevRel Lead Key performance indicators (KPIs) for Developer Relations One of the challenges in DevRel is measuring success. We spent a considerable time figuring out how to measure success effectively for DevRel ourselves at Chainstack. One way is using deliverable-based KPIs that focus on efforts, such as the number of Twitter Spaces sessions, videos created, and outreach meetings with developers. While these metrics showcase the level of effort, it’s important to consider the value created for the project. Some projects might choose the deliverable based method, others might go for purely value creation KPIs such as how many new developers were onboarded in the past month and others might figure out a health mix for their project. Another important thing to note is that measuring the direct impact of DevRel on developer signups or SDK usage can be a bit challenging due to external factors like market movements. So, it’s always a good idea to factor in the potential delta beforehand. The path from zero experience to full-time DevRel hero Now let’s talk about going from zero experience to a full-time DevRel hero. Starting from scratch and eventually securing a full-time position in DevRel takes time and hands-on experience. The opportunities in Web3 are ever present and as you can see companies have been hiring through the bear market. These numbers of course are going to be way higher during a bull phase when more money is flowing into the markets. Figure 3: Number of Web3 companies hiring; Source: Crypto Jobs List Trends Bear markets however are a great time to build skills, and relationships and even work on your own projects so you have a foundation ready when the bull phase hits. However, it’s essential not to expect immediate full-time positions, especially when you’re young and just starting. Ethan advises aspiring DevRel professionals to gain a strong understanding of JavaScript/Python, and Web3 development. This is the core of DevRel, this is what makes you different from marketing managers or business development managers in the space. You must spend time and effort to build your development skills so you can communicate better with the developers, understand their pain points, and understand the infrastructure and requirements of the space. The next step is to build confidence in your skills to the point where you can deliver business value. Sometimes all you need is to understand how to convert the knowledge and skills that you have into something that creates value for other businesses in the marketplace. Creating your own projects is an excellent way to get started with that. Start with thinking about solving problems that you are passionate about and problems that frustrate you. This will also help you gain hands-on experience and solve problems that resonate with you. Networking and interactive engagement with the community can also lead to valuable opportunities once you’ve figured out your own value prop to the projects in the Web3 space. It might be a great idea to start looking for internships and other such career opportunities in the Web3 space after this to dip your toes into the DevRel world. Content types in Web3 DevRel According to Ethan, video content holds several advantages over other mediums, particularly in the Web3 space. Video is more engaging, especially in the anonymous world of Web3, as it allows developers to attach a face or voice to the information. Sharing engaging educational content through videos, including examples of building applications within specific timeframes, helps establish a strong connection with developers. However, you must not stop at that. Developers in Web3 spend a lot of time reading articles, Twitter spaces & Discord servers. And the best way to meet developers is to go where they are at. So, Twitter spaces, Discord servers, Community calls, and writing valuable pieces of content for developers are great ways to engage and build meaningful relationships. Transitioning from Web2 to Web3 DevRel Some of you might already be a DevRel professional in Web2 but want to transition into Web3. There are notable differences between DevRel in Web2 and Web3. In Web3, developers have a unique culture that emphasizes community interaction, including a lot of participation in Twitter Spaces and other community-driven activities. Web3 DevRel is often more personal and community-focused, whereas Web2 DevRel can be more corporate in nature. To transition from Web2 to Web3 DevRel, Ethan recommends spending time with the Web3 community, interacting with Web3 developers, and understanding their behavior, culture, and expectations. Additionally, dedicating time to understanding blockchain tech, Web3 development, and its technical aspects is crucial due to the significant differences between Web2 and Web3 technologies. We have a tutorials section on our blog that covers a lot about Web3 development that could help you in this department, as well as a dedicated section in our docs–Web3 [De]Coded, where you will find more detailed and comprehensive ones: In fact, we also share a lot of helpful content regularly on our Twitter such as this video tutorial on Solana-Web3js that Ethan recently posted. In conclusion, starting a career in DevRel in Web3 requires a combination of technical skills, communication abilities, and a deep understanding of Web3 development. Building personal projects, networking, and continuous skill development are key to success in this space. By leveraging the insights in this article, you can embark on a fulfilling journey as a DevRel professional in the exciting world of Web3. Some quick Web3 Developer Relations FAQs These FAQs cover most of the information we shared with you in this article however if you have any specific questions feel free to Tweet at us and Ethan anytime! What is Developer Relations (DevRel) in Web3? DevRel in Web3 refers to the role of bridging the gap between developers and projects in the Web3 ecosystem. DevRel professionals engage with developers, provide technical support, create educational content, and build relationships within the developer community. What skills are required to excel in Web3 DevRel? Successful Web3 DevRel professionals possess a combination of technical skills, including programming languages like JavaScript and Python, Web3 development frameworks, and an understanding of blockchain architecture. Strong communication, content creation, and community engagement skills are also crucial. How do I get started with Web3 development? To get started with Web3 development, you can begin by learning blockchain basics and familiarizing yourself with the concepts of smart contracts, decentralized applications, and relevant programming languages such as Solidity (for EVM) or Rust (for Polkadot). Explore developer documentation, tutorials, and online courses to deepen your understanding and start building small projects. How do you measure success in Web3 DevRel? Measuring success in Web3 DevRel can be challenging due to the decentralized and ever-evolving nature of the industry. Common metrics include the number of developer sign-ups, engagement in developer-focused events (such as Twitter Spaces or workshops), the impact of educational content, and the growth of developer communities. How can I transition from Web2 to Web3 DevRel? Transitioning from Web2 to Web3 DevRel requires gaining a deep understanding of Web3 technologies, such as smart contracts, decentralized applications (DApps), and blockchain platforms. It also involves immersing yourself in the Web3 community, engaging with developers, and understanding the unique culture and expectations of the devs in Web3. What are the key differences between Web2 and Web3 DevRel? Web2 DevRel often has a more corporate focus, whereas Web3 DevRel is more community-driven. Web3 DevRel requires more personal interactions, such as participating in Twitter Spaces or Discord communities, to foster developer engagement. The technical aspects of Web3, including blockchain architecture and decentralized protocols, also differentiate it drastically from Web2 DevRel. How can I build a career in Web3 DevRel during a bear market? Bear markets can be an opportune time to invest in learning and building your skills. Use the downtime to develop applications and solutions that solve real-world problems. Building a strong work portfolio during a bear market positions you for success when the market enters a bullish phase and adoption increases. Is age a big factor in becoming a DevRel professional in Web3? No, there are no age restrictions for becoming a DevRel professional in Web3. The field is open and permissionless, welcoming individuals of all ages as long as they can provide value and demonstrate competence in technical skills, communication, and community engagement. How can I find opportunities and companies aligned with my values in Web3 DevRel? Networking, attending industry events, participating in Web3 communities, and engaging with projects and individuals on platforms like Discord are effective ways to find opportunities in Web3 DevRel. Look for companies and projects that align with your values by researching their missions, values, and culture. Make sure to spend some time in their Discord, and listen to the Twitter spaces and interviews their team does to understand their culture better. What are the key challenges in Web3 DevRel? Challenges in Web3 DevRel include keeping up with rapidly evolving technologies, understanding complex blockchain architectures, navigating the decentralized nature of the industry, and measuring the impact of DevRel efforts. Building strong relationships with developers and creating content that resonates with the target audience are ongoing challenges as well. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to improve Solana RPC latency with ShredStream Solana runs on speed, and those who build on it chase every millisecond. ShredStream by Jito Labs brings block data closer to real time by streaming it through Jito’s Block Engine network from Solana validators instead of waiting for standard network propagation. This guide shows what it means for your stack and how to enable it on Chainstack. Solana pushes data through the network faster than most systems can follow, yet anyone building latency-sensitive tools, even a few ms of delay still matters. Standard Solana RPC nodes receive block updates only after validators finish propagating them, which creates small but costly timing gaps. ShredStream, built by Jito Labs, closes that gap by streaming shreds directly from the validators producing blocks. The result is steadier feeds, lower tail latency, and fewer missed slots. If you’ve been trying to get closer to real-time data or test the limits of your infrastructure, here’s how it works and how to enable it on Chainstack. What is ShredStream? To put it simply, ShredStream is a data feed that connects directly to Solana’s validators to deliver block data the moment it’s produced. Instead of waiting for information to travel through the network, it streams the individual shreds (the pieces that form each block) straight from the source. In practice, it’s a faster pipeline between the validator generating the block and your RPC endpoint. Each shred arrives slightly earlier and with less timing variance, so your data feed reflects the chain’s state sooner and more consistently. How you use it depends on your setup. If you run your own node, you can connect through the public ShredStream network, though configuring and maintaining it adds operational overhead. The simpler path is using an infrastructure provider that has already integrated it into their stack, like Chainstack. Either setup gives you earlier block updates, more consistent timing, and fewer dropped slots when streaming Solana data. How Solana shreds and block propagation work To understand why ShredStream changes how your node performs, it helps to see how data usually travels through Solana. Every block on Solana is split into small pieces called shreds. The validator produces the block and sends those shreds to other validators using a protocol called Turbine. Turbine works like a fanout tree: each validator forwards the shreds it receives to the next group in line until the entire network has a full copy of the block. That process keeps the network decentralized and resilient, but it also introduces variability. Some validators are closer to the leader than others, so they receive shreds sooner. Network hops can create jitter, which means your RPC might see blocks a few hundred milliseconds after they’re produced. If a few shreds arrive late or out of order, your node can briefly lag behind or miss a slot entirely. These delays don’t affect consensus, but they matter for builders who rely on real-time data. ShredStream bypasses that propagation tree by streaming the same shreds directly from the validators generating them. To put it simply, it just lets your RPC see the data as soon as it exists. ShredStream-enabled Solana node vs non-ShredStream-enabled Solana node Once you start using a ShredStream-enabled node, you notice the difference in how your data behaves: Typenon-ShredStream-enabled Solana nodeShredStream-enabled Solana nodeData pathReceives blocks after full network propagationStreams shreds directly from validators as they’re producedLatencyAverage latency stable, tail latency highLower and more predictable tail latencyConsistencyOccasional jitter or missed slotsContinuous feed with even timing Pairing it up with the Yellowstone gRPC Geyser plugin To make the most of your ShredStream-enabled Solana node, you’d want to pair ShredStream with the Yellowstone gRPC Geyser plugin. The reason for that is simple: The plugin exposes Solana data, like transactions, accounts, and program updates, directly from the validator over gRPC. When your validator or RPC provider runs Yellowstone gRPC Geyser plugin on top of a ShredStream-backed feed, every update arrives sooner and with fewer gaps because the underlying shreds reach it first. If you want to see how it works in practice, the plugin is available as an add-on on Chainstack. You can spin up a Solana node and start streaming data for as little as $49 a month, currently the most affordable managed setup on the market. When to use ShredStream-enabled Solana Node To put it in practice, we ran a short test on the same Solana GEN node—ten minutes with ShredStream, ten minutes without it. When we put it to the test, the quality of the data stream shifted noticeably, with the results showing 37% more slots in the optimal timing window and 3× fewer missed slots. You see the biggest gains in setups where speed and consistency decide outcomes: High-frequency trading systems see steadier fills and fewer slow blocks. Liquidation and keeper bots trigger on time instead of a slot late. DeFi indexers and analytics pipelines run smoother with fewer backfills. Wallets, dashboards, and alerting tools show live updates without skipped blocks. So with numbers like that, the takeaway is pretty clear: if you’re building anything that depends on live Solana data, you’ll want to run it through a ShredStream-enabled RPC. How to access ShredStream-enabled node If you want to start using ShredStream without setting up validators, you can do it directly using Chainstack. We’ve already wired ShredStream into our Yellowstone gRPC Geyser plugin, so you get the same real-time Solana feed Jito designed, streamed straight from validators, without any of the heavy lifting. Here’s how to get it running: Log in to your Chainstack account (or create one if you don’t have one yet). Create a new project, or pick an existing one. Deploy a Solana Global Node. Open the node once it’s live. Go to Add-ons → Yellowstone gRPC Geyser Plugin → Install. ShredStream is enabled by default inside the plugin, so as soon as the installation finishes, your streams are already pulling validator data in real time. Start streaming Solana data in real time Wrapping up ShredStream turns Solana data into a source you can trust slot after slot. With Chainstack, that capability is now part of your infrastructure, giving you validator-speed access to Solana data without touching validator code. Whether you’re running bots, analytics, or full-scale trading systems, it’s a direct path to reliable, low-latency infrastructure that scales with your workload. Start streaming Solana data in real time Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is ShredStream? ShredStream is a data feed built by Jito Labs that connects directly to Solana’s validators. It streams block data the moment it’s produced instead of waiting for it to travel through the wider network. The result is lower latency and more consistent Solana data for builders who rely on real-time updates. Does ShredStream change how Solana reaches consensus? No. ShredStream doesn’t alter Solana’s consensus or block production. It only changes how quickly your node receives the data once a block is produced. Do I need to run my own validator to use ShredStream? Not at all. On Chainstack, ShredStream is already integrated into the nodes. Who benefits most from using ShredStream? Projects that depend on real-time data: trading bots, liquidation systems, analytics dashboards, and DeFi indexers. Anything where timing or data freshness affects the outcome. #### How to make concurrent Web3 RPC calls with Python A little bit of context first for the origin of this article. We had a member of the developer community ask us: how to loop through a large range of blocks, and for each block that we loop through, and iterate through, we have to use that block number as a parameter in a smart contract method call, using Python. The issue that this developer had was that it was taking too long, it was too slow. After some back-and-forth talking, we realized what the issue was. The issue was Python itself. The issue If you didn’t know Python as well as web3.py are largely synchronous, this means that operations are essentially processed sequentially one after the other until the script ends. For example, if you are making thousands of RPC requests, in this case looping through different block numbers to be used as parameters in smart contract calls, each of those calls you’re making will go one… wait till it completes, two… wait till it completes, and so on. What this means is that for use cases like this, or any use case where you need to make a large amount of specific Web3 RPC calls, Python can get extremely slow, very quickly. The question that we aim to answer in this tutorial is: How do we loop through or make a large amount of Web3 requests without it taking a lot of time? Of course, there are a few ways of doing this, but for the sake of this tutorial, we will use a combination of asynchronous functions, and multi-threaded processing to achieve concurrent RPC calls, and significantly cut down the amount of time that it takes to make these large amounts of typically sequential RPC calls. Let’s utilize asynchronous and multi-threaded Python programming to send concurrent Web3 RPC requests. The goal of this tutorial Loop through 500 blocks, and for each block, get the balance of an address at that specific point in time. Import the libraries Before we get started we need to import a few base libraries. We will import asyncio, concurrent.Futures, Web3, and time. import asyncio from concurrent.Futures import ThreadPoolExecutor from web3 import Web3 import time Define the base Web3 object web3 = Web3(Web3.HTTPProvider{"input RPC URL here"}) Remember our goal. We need to find the balance of an address, at different points in time in the past. This is what we call historical states. In order to do this, we’ll need an archive node. Spin up a Chainstack node You can deploy an archive node through Chainstack if you subscribe to our Growth plan. Follow the steps in the video below to do that. After you deploy the node, get your endpoint. Please note that another important aspect that impacts the speed at which this process will go is node latency. Define other variables address = "input wallet address here" //this will be the address of the account that we'll be pulling the balance for start_block = web.eth.block_number //this will be the most recent block end_block = start_block - 500 Define the main function Let’s go ahead and define the main function for actually getting the balance of the address itself. def get_balance_at_block(block_num): balance = web3.eth.get_balance(address, block_identifier = block_num); print(f"Balance at block {block_num}: {web3.from_wei(balance, 'ether')} ETH") Now that we have this function, we’ll go ahead and define our main asynchronous function that will call ThreadPoolExecutor which will call the function for every block in the range that we’ve defined. Define async function async def main(): with ThreadPoolExecutor(max_workers = 10) as executor: tasks = [ loop.run_in_executor( executor, get_balance_at_block, block_num ) for block_num in range(start_block, end_block, -1) ] await asyncio.gather(*tasks) Let’s look at what the code does. We defined a function called main that will run with ThreadPoolExecutor, which has 10 workers assigned. We defined a list called tasks, in which we called a variable called loop, which will be defined a bit later, and we called the run_in_executor method on the loop variable, through which we passed 3 parameters (executor, get_balance_at_block, and block_num) Then we loop through the blocks in the range start_block <-> end_block in descending order. Define the loop variable loop = asyncio.get_event_loop() Under the loop definition, we will also start a clock. You do not have to do this if you do not want to, but we will do it for demonstration purposes in order to see how much time it takes for this entire process to happen. start = time.time() loop.run_until_complete(main()) print(f"Time to completion: {time.time() - start}") Perfect, now you should have the complete script. You can go ahead and run it, and see what it does. When you compare the method above with the standard way of processing requests like this in Python, you will actually get some surprising results in terms of speed. In our case, with the method shown above it took a bit over 5 seconds to get the job done, while a standard Python setup, that uses no asynchronous or multi-threaded processing took 13.5 seconds for the same task. Standard Python takes a lot more time because it does not implement concurrent processing. JavaScript version We will use standard asynchronous functions in JavaScript. Specifically, we will process this through just a Promise.all method. const { Web3 } = require('web3'); const web3 = new Web3('your Chainstack endpoint here') const address = 'input wallet address here'; async function getBalanceAtBlock(blockNum) { const balanceWei = await web3.eth.getBalance(address, blockNum); console.log(`Balance at block ${blockNum}: ${web3.utils.fromWei(balanceWei, 'ether')} ETH`); } async function main() { let startBlock = await web3.eth.getBlockNumber(); startBlock = Number(startBlock); const endBlock = startBlock - 500; const blockRange = Array.from({length: parseInt(startBlock - endBlock + 1)}, (_, i) => startBlock - i); const start = Date.now(); await Promise.all(blockRange.map(blockNum => getBalanceAtBlock(blockNum))); const end = Date.now(); console.log(`Time taken: ${(end - start) / 1000} seconds`) } main(); When compared to the Python scripts, this one took 3.1 seconds. Recap of what we did Imported the variables. Defined the RPC node itself. Defined some base variables. Defined the get_balance_at_block function that gets the balance of the address at the block number in the range that we are looping through. Defined the main function, that uses the ThreadPoolExecutor to run get_balance_at_block concurrently through the range of blocks that we defined. Created a clock to measure how much time it takes to finish the whole process. Congratulations if you’ve made it to the end. If you are looking for more tutorials feel free to check out our docs and Web3 tutorials. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to measure RPC latency: P50, P95, P99 explained A methodology guide for benchmarking RPC providers across regions — with real Arbitrum data, common measurement mistakes, and how to read latency dashboards for production decisions. TL;DR Most public RPC benchmarks cite average latency. That’s the wrong metric for production workloads. Average hides tail latency — the 1-in-100 requests that determine whether your trading bot fires, your wallet feels snappy, or your indexer keeps up with block production. This guide covers the metrics that actually matter (P50, P95, P99, success rate), how to measure them yourself, and how to read a live latency dashboard properly. We’ll use current Arbitrum benchmarks as the case study — where Chainstack currently ranks #1 with 266ms P95 at 100% availability across three regions. By the end, you’ll know what “good” latency looks like for your chain, what a P99 spike really tells you about a provider’s infrastructure, and why success rate matters more than everyone gives it credit for. Why RPC latency matters Every RPC call sits on your app’s critical path. When latency degrades, the impact isn’t linear: Trading bots miss inclusion windows. On Arbitrum’s 250ms block time, a 500ms round-trip delay pushes you into the next block — sometimes past the arbitrage opportunity entirely. Wallet UX feels broken. Users perceive delays above 400ms as sluggish; above 1 second as unresponsive. MEV searchers lose bundle placement. Sub-100ms consistency is table stakes for competitive bundle submission. Real-time dashboards stall. WebSocket subscription lag creates data staleness that compounds across UIs. Indexers fall behind. If your indexer can’t process blocks faster than they’re produced, you accumulate a backlog that never recovers without infrastructure changes. The question isn’t whether latency matters — it’s which latency metric matters for your workload. That’s where most benchmarks fail. Latency metrics that actually matter P50 (median) — the typical experience P50 tells you what half your users see. If P50 is 200ms, half of all requests finish faster than that, half take longer. It’s the closest single number to “how does it feel on average” — but it’s still incomplete, because half your users have worse experiences than P50 suggests. Use P50 for baseline expectations. Never use it alone. P95 — the reliability threshold P95 tells you what your worst 5% of users see. If P95 is 400ms, 95% of requests finish faster than 400ms, but 5% take longer. For most production apps, P95 is the most important number: it captures the consistency of the infrastructure, not just its best-case performance. A provider with 100ms P50 and 200ms P95 is dramatically more reliable than one with 100ms P50 and 800ms P95 — even though their “average” might look identical. P99 — the tail latency threshold P99 tells you what your worst 1% of requests look like. For most apps, P99 is diagnostic — a signal about how well the provider handles edge cases (cold caches, node restarts, network hiccups, regional failovers). For trading and MEV workloads, P99 is critical. If you fire 100 trades a day, 1 of them will hit the P99 latency. A 3-second P99 means one trade a day arrives 3 seconds late. Why P99 matters in practice: Consider a provider showing P95 of 300ms and P99 of 700ms. The P95 looks competitive. But that P99 tells you 1 in 100 requests takes over 700ms. For a trading bot firing 10,000 requests a day, that’s 100 requests hitting the slow path — potentially the difference between landing an arbitrage and missing it. Ratios of P99 to P95 above 2x usually indicate infrastructure inconsistency worth investigating: cold caches, regional failovers, or capacity pressure showing up in the tail. Why average is misleading The single biggest measurement mistake in RPC benchmarking is citing averages instead of percentiles. Averages get pulled around by outliers in ways percentiles don’t. A provider with two very fast regions and one very slow region can post a great “average” that no user in the slow region will ever experience. Averages also fail to capture the shape of the distribution — one 5-second request in a batch of 1,000 barely moves the average but dominates P99. Rule of thumb: if a benchmark only gives you an average, it’s marketing, not measurement. Success rate: the metric everyone underweights Here’s an underrated fact: 99.99% availability delivers roughly 7x fewer failures than 99.93%. That gap looks small in percentage terms — 0.06 percentage points. In practice, it’s the difference between one failed request in ten thousand versus seven failed requests in ten thousand. For a trading bot firing 100k requests a day, that’s the difference between 10 failures and 70. The Chainstack Compare methodology uses this specific scoring formula: Score = 1 ÷ ((1/ResponseTime) × (SuccessRate³)) Success rate is cubed. That’s not arbitrary — it’s a deliberate choice to penalize even small reliability drops heavily. Cubing means a provider with 99% success gets 3x the penalty compared to 99.7%, not a linear 0.7% penalty. The reasoning: production apps care about consistent reliability more than average reliability. A provider that’s fast on good days but drops requests on bad days is worse than a slightly slower provider that never drops. How to measure RPC latency yourself If you’re evaluating a provider, don’t rely on their marketing benchmarks. Run your own. Here’s what a rigorous test setup looks like. Test setup Geographic distribution: Test from at least three regions. RPC latency is dominated by physical network distance for most workloads — a US-East endpoint tested only from US-East hides how your Asian users will actually experience the service. Minimum recommended regions: North America, Europe, Asia-Pacific. If you have specific geographic user concentrations, add matching test regions. Sample size: Aim for at least 10,000 requests per region over 24+ hours. Anything less gives you noise; anything less than a full day misses time-of-day variation. Providers behave differently at 3am UTC versus 8pm UTC. Method selection: Different RPC methods have very different latency profiles. A good benchmark tests a mix: Light methods: eth_blockNumber, eth_chainId — pure state reads, minimal computation Medium methods: eth_call, eth_getBalance — some computation, cache-friendly Heavy methods: eth_getLogs, debug_traceTransaction — expensive, cache-unfriendly Testing only eth_blockNumber will make every provider look fast. Testing only eth_getLogs on wide block ranges will show real infrastructure differences. Warmup period The first N requests to any endpoint are typically slower than subsequent ones — DNS resolution, TLS handshakes, connection pooling, and provider-side caching all warm up over time. Discard the first ~100 requests from your dataset, or run a warmup phase before the measured phase. Timeout handling Set a realistic timeout. Chainstack Compare uses 55 seconds as its ceiling. Anything faster than 30 seconds risks classifying legitimate slow requests as failures; anything slower than 60 seconds gives no useful signal for production apps. Failure counting Count these as failures: Timeouts HTTP non-200 responses JSON-RPC error responses (per the spec) Excessive block delays (for methods returning block data) Do not exclude failures from your latency dataset — they’re the most important signal. A provider with fast successful responses but frequent failures is worse than one with slightly slower but reliable responses. Benchmark script Here’s a minimal Python benchmark that captures the key metrics: import time import requests from statistics import quantiles RPC_URL = "https://your-rpc-endpoint.com" SAMPLE_SIZE = 10000 WARMUP = 100 TIMEOUT = 55 payload = { "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 } # Warmup for _ in range(WARMUP): try: requests.post(RPC_URL, json=payload, timeout=TIMEOUT) except Exception: pass # Measure latencies = [] failures = 0 for _ in range(SAMPLE_SIZE): start = time.time() try: r = requests.post(RPC_URL, json=payload, timeout=TIMEOUT) if r.status_code == 200 and "error" not in r.json(): latencies.append((time.time() - start) * 1000) else: failures += 1 except Exception: failures += 1 # Report success_rate = len(latencies) / SAMPLE_SIZE * 100 p50, p95, p99 = quantiles(latencies, n=100)[49], quantiles(latencies, n=100)[94], quantiles(latencies, n=100)[98] print(f"Success rate: {success_rate:.2f}%") print(f"P50: {p50:.0f}ms | P95: {p95:.0f}ms | P99: {p99:.0f}ms") Run this from three regions, combine the results, and you have a real benchmark. Run it against multiple providers with the same script — and you can make an informed decision. Common measurement mistakes Every team that benchmarks providers themselves makes at least one of these mistakes. Avoid them. MistakeWhy it hurtsFixTesting only from one regionLatency dominated by network distance — single-region tests miss geographic realityTest from US, EU, APAC minimumOff-peak testing onlyInfrastructure behaves differently at 3am UTC vs market openInclude peak and off-peak windowsNot distinguishing hot vs coldFirst request slower due to connection setup, cache warmupDiscard first 100 requestsMethod complexity ignoredeth_blockNumber returns in ms, debug_traceTransaction can take secondsTest light + medium + heavy method mixSkipping warmup phaseConnection setup skews P95/P99Discard first ~100 requestsFailures counted as non-eventsProvider with 100ms P95 + 2% failure rate worse than 200ms P95 + 100% successInclude failures in latency dataset Chain-specific latency considerations Not all chains have the same latency profile. What counts as “good” latency depends on the chain and your workload. Ethereum Methods are relatively homogeneous. Most read operations complete in similar time ranges — eth_blockNumber, eth_getBalance, eth_call all cluster within a narrow band. The main variance comes from archive queries and debug_* / trace_* methods, which can be 10-50x slower than standard reads. Ethereum’s 12-second block time also means block propagation lag is less critical than on faster chains — a 500ms RPC response is still comfortably within block time. Good P95 for L1: under 500ms is competitive; under 300ms is excellent. Solana sendTransaction and getSlot have radically different profiles. sendTransaction involves cluster propagation and validator gossip — it can take 400ms+ under normal conditions and 2s+ during congestion. getSlot returns in tens of milliseconds. Benchmarking one and reporting it as the provider’s “latency” is meaningless. More importantly, for Solana trading workloads the real metric is transaction landing rate — the percentage of submitted transactions that actually make it into a block. A provider with fast sendTransaction responses but 60% landing rate is useless. Chainstack Compare tracks landing rate separately for exactly this reason, using standardized memo transactions with fixed priority fees. Good P95 for Solana reads: under 200ms. Landing rate: above 90% for production trading. L2s (Arbitrum, Base, Optimism) L2 latency stacks in three layers: RPC round-trip + sequencer soft finality (~2s) + Ethereum hard finality (~7 days for withdrawals). For most application logic, RPC latency dominates the user experience because sequencer confirmation happens automatically in the background. Arbitrum specifically has one wrinkle: pre-Nitro blocks (before block #22,207,815) require arbtrace_* methods instead of standard debug_*. If your analytics or forensic tool benchmarks the wrong namespace, you’ll see either failures or artificial slowness. Base and Optimism share the OP Stack namespace behavior, so provider coverage transfers between them. Good P95 for L2s: under 350ms is competitive; under 300ms is excellent. Hyperliquid Perp trading requires sub-100ms consistency. Order book updates and HyperCore precompile reads have distinct latency budgets that standard RPC benchmarking doesn’t fully capture. WebSocket subscription lag matters more than HTTP request/response — a bot polling order book state via HTTP will always lose to one subscribing via WebSocket, regardless of provider P95. For Hyperliquid trading infrastructure, benchmark WebSocket subscription latency (time from block/order production to WS delivery) separately from HTTP RPC. Good P95 for Hyperliquid HTTP RPC: under 150ms. WebSocket delivery lag: under 100ms for trading workloads. Chainstack Compare: transparent open-source benchmarks The problem with most RPC provider benchmarks is that they’re published by the providers themselves. “We’re the fastest” without measurable, verifiable data is marketing, not evidence. Chainstack Compare takes a different approach: real-time latency and success rate measurements across providers, published continuously in two forms. Landing page (compare.chainstack.com) — quick per-chain rankings with P50/P95/P99 and per-region breakdowns. Refreshes every 3 minutes. Public Grafana dashboards — per-method deep-dive with 14 days of history. Filter by method, provider, region, time window. No login required. Example: Ethereum performance dashboard. How it actually works The methodology matters. Here’s what the dashboard actually does: Data collection: Vercel serverless functions in three regions (US, Germany, Singapore) fire real RPC requests every 1-3 minutes Method coverage: commonly used methods per chain — balance checks, transaction simulation, block queries Failure classification: timeouts >55s, non-200 responses, JSON-RPC errors all count as failures Ranking formula: Score = 1 ÷ ((1/ResponseTime) × (SuccessRate³)) — cubed success rate penalizes reliability drops disproportionately Open source: the entire data collection service is published on GitHub. Fork it, verify the methodology, run your own copy For the launch details and full architecture breakdown, see the Chainstack Compare Dashboard launch post and the Arbitrum + BNB expansion update. Case study: reading Arbitrum latency benchmarks Let’s apply everything above to a real snapshot. Here’s the current Arbitrum ranking on compare.chainstack.com, as of July 2026, 24-hour window: Chainstack ranks #1 with 100% availability and 266ms P95. Four things worth unpacking here. Speed advantage against tied availability Three of the four providers post 100% availability. Only dRPC drops the top tier at 99.97% — a small gap that translates to roughly three failed requests per ten thousand versus zero. Not catastrophic for most workloads, but meaningful for high-frequency trading and MEV where every request counts. With availability tied at the top, P95 is the differentiator. Chainstack’s 266ms beats Quicknode’s 310ms by 14% and Alchemy’s 321ms by 17%. On Arbitrum’s 250ms block time, that difference determines whether your submitted transaction lands in the current block or slips to the next. The takeaway: when top providers converge on high availability, speed becomes the ranking factor. Chainstack Compare’s scoring formula picks up this shift automatically — reliability is cubed, but with reliability effectively equal across the top three, the response time factor dominates. Regional performance: where each provider actually wins Aggregate P95 hides regional variance. The regional columns reveal specific strengths: US (US-East test region): Chainstack 242ms — the fastest single-region number across all providers. If your users concentrate on the US East coast, this is a decisive advantage. Japan (APAC test region): Chainstack 246ms — again the fastest, dominating APAC latency for the group. Trading platforms serving Asian markets pay lower round-trip costs. Germany (EU test region): Quicknode 294ms takes this region, edging Chainstack’s 311ms by 17ms. Chainstack does not win everywhere — Quicknode’s European infrastructure is competitive here. Every provider has a regional profile. Chainstack wins US and JP by comfortable margins; Quicknode wins DE narrowly. Alchemy’s regional numbers cluster around 284-368ms — no strong region, no weak region. dRPC lags in every region. For a production app with global users, this means multi-region provider evaluation isn’t optional. Aggregate rankings tell you the headline; regional data tells you whether the provider fits your geography. The P99 story worth watching There’s honest tension in the data. Chainstack has the fastest P50 (131ms) and P95 (266ms) in the group — but the highest P99 (687ms) among the top three. The P95-to-P99 ratios: Chainstack: 266ms → 687ms (2.58x) Quicknode: 310ms → 375ms (1.21x) Alchemy: 321ms → 433ms (1.35x) dRPC: 338ms → 412ms (1.22x) Chainstack has the largest tail spread in the top three. Interpretation: the infrastructure is optimized for typical-case speed, and 95% of requests are fast — but the worst 1% see wider variance than the more consistent (and slower on average) alternatives. For most production workloads this is a favorable trade-off: your median user gets substantially faster responses, and the tail impact is bounded. For latency-sensitive trading at the P99 level specifically, it’s worth monitoring — the Grafana per-method breakdowns show whether the P99 spikes concentrate in specific methods or time windows. This is exactly the kind of nuance that headline “we’re the fastest” marketing hides — and exactly why publishing real numbers matters more than publishing claims. Deeper dive via Grafana For per-method breakdowns on Arbitrum, open the Arbitrum Grafana dashboard. It shows: eth_call vs eth_getBalance vs eth_getLogs — different latency profiles per method 7-day and 14-day historical charts — how rankings shift over time Success rate breakdown by method + region — where failures actually happen Aggregate rankings tell you the headline. Per-method data tells you whether the provider fits your workload. When RPC latency doesn’t matter Not every workload cares about latency. If you’re building any of these, optimize for cost over speed: Batch indexers — retry-tolerant, throughput matters more than per-request latency Historical analytics — running trace queries over past blocks doesn’t need real-time response Backfill jobs — bulk data ingestion that runs asynchronously Tax reporting — long-range historical queries where seconds don’t matter Research pipelines — one-off queries for ad-hoc analysis For these, a provider with 500ms P95 and predictable request-based pricing beats one with 100ms P95 and credit-multiplier billing. When RPC latency is critical For these workloads, latency variance directly impacts your business: Trading bots — inclusion probability depends on submission timing MEV searchers — bundle placement is millisecond-competitive Wallet UX — user perception of “fast” starts breaking above 400ms Real-time dashboards — data staleness compounds across the UI Live liquidation engines — the difference between profit and loss is often single-digit milliseconds Cross-chain bridges — settlement timing sensitive to source-chain finality signals For these, invest in dedicated infrastructure, test benchmarks yourself, and prioritize P99 consistency over P50 headline numbers. Conclusion Measuring RPC latency well isn’t complicated, but it does require discipline. Test from multiple regions. Test with a mix of methods. Look at P95 and P99, not averages. Weight success rate seriously. Discard warmup. Count failures. Most importantly: verify claims independently. If a provider can’t show you live, per-method, per-region latency data with an auditable methodology, treat their performance claims as marketing. The Chainstack Compare dashboard exists to change that dynamic — real-time measurements, open-source methodology, public Grafana dashboards, 14 days of history. It’s the same infrastructure Chainstack itself is measured against every three minutes, published live for anyone to audit. Deploy a production Arbitrum RPC endpoint on Chainstack → FAQ What’s a “good” P95 for Ethereum vs Solana vs L2s? Rough production targets in 2026:– Ethereum L1: P95 under 500ms is competitive; under 300ms is excellent– Solana: measure transaction landing rate over standard P95 — targets vary by workload– L2s (Arbitrum, Base, Optimism): P95 under 350ms is competitive; under 300ms is excellent– Hyperliquid: P95 under 100ms for perp trading workloads How often should I re-benchmark my provider? Continuously if you’re latency-sensitive. Monthly at minimum for production apps. Providers can degrade or improve over time — infrastructure changes, regional migrations, and capacity shifts all affect performance. Should I test HTTP or WebSocket? Both, separately. HTTP request/response latency and WebSocket subscription lag have different profiles and different failure modes. If your app depends on eth_subscribe for pending transactions, HTTP benchmarks tell you nothing about that dimension. Can I trust provider self-reported benchmarks? Rarely. Provider-published benchmarks tend to select methodology that favors their infrastructure — cherry-picking regions, methods, or time windows. Cross-reference with independent measurements, run your own tests, or use a publicly-auditable dashboard like Chainstack Compare. Where can I see per-method breakdowns? The Chainstack Compare Grafana dashboards are public and show per-method latency, per-region breakdowns, and 14-day historical charts for every tracked chain. Does Chainstack Compare test the same provider tier that I’d get as a customer? Yes — the dashboard documentation notes that all providers are tested on their paid tiers (except TonCenter, which uses the free tier as they don’t have a paid one). The results reflect production infrastructure, not free-tier performance. How do I benchmark WebSocket subscription latency? WebSocket lag is a different measurement than HTTP round-trip. Subscribe to newHeads (or the chain equivalent) on the provider’s WebSocket endpoint, then measure the delta between block production timestamp (from the block header) and the moment your subscription receives it. Run this for hours across multiple regions to build a distribution. Providers with stable WebSocket infrastructure typically deliver blocks within 100-300ms of production on Ethereum; slower deliveries usually indicate regional routing issues or subscription server load. For pending transaction subscriptions (newPendingTransactions), measure delivery latency the same way but expect wider distributions — mempool broadcasting is noisier than block propagation. Why are my cold-start requests so much slower than subsequent ones? The first request to any endpoint carries connection setup overhead: DNS resolution, TCP handshake, TLS negotiation, and often provider-side cache warmup. This can add 100-500ms to the first request. Subsequent requests on the same connection reuse the setup, so they’re measurably faster. If your app uses short-lived connections (each request is a new HTTPS session), you’re paying this cost every time — consider connection pooling or persistent HTTP/2 clients. Benchmarks should either warm up with 50-100 discarded requests, or explicitly separate cold-start latency from steady-state latency in reporting. How many requests do I need to trust my P99 number? For P99 to be statistically meaningful, you need at least 1,000 samples — that gives you 10 requests in the 99th percentile bucket. For P99.9 (which some trading workloads care about), you need at least 10,000 samples. Below these thresholds, your P99 is dominated by whichever unlucky outlier landed in the small sample. This is why serious benchmarks run for 24+ hours across multiple regions: you need enough samples per region to make regional P99 meaningful, not just aggregate. Does the provider’s routing behavior affect which region “wins”? Yes, and it matters. Some providers use anycast routing that automatically directs your requests to the geographically nearest data center. Others use fixed regional endpoints where you pick a URL like us-east.example.com. Anycast providers can appear faster in benchmarks because your test client’s IP determines routing — a test from Frankfurt hits EU infrastructure, a test from Singapore hits APAC. Fixed-endpoint providers force you to choose, and if you pick wrong, your users pay the latency cost. When benchmarking, check whether the endpoint auto-routes or requires manual region selection — it changes what the numbers actually mean for your production traffic. Should I run benchmark requests concurrently or sequentially? Both, and separately. Sequential benchmarks (one request at a time) measure baseline latency — the theoretical best case. Concurrent benchmarks (many requests in parallel) measure how the provider’s infrastructure handles load — which is closer to production behavior. A provider that looks fast in sequential tests can degrade significantly under concurrent load if their rate limiting, connection pooling, or backend scaling isn’t well-tuned. Test both patterns: 1,000 sequential requests for baseline, then 100 requests at 10 concurrent connections for load behavior. Additional resources Chainstack Compare Chainstack Compare landing page Chainstack Compare documentation Arbitrum performance dashboard (Grafana) Open-source data collection repo (GitHub) Compare Dashboard launch announcement Arbitrum and BNB Chain expansion RPC provider comparisons Best Arbitrum RPC providers in 2026 Best Ethereum RPC providers in 2026 Best Optimism RPC providers in 2026 Arbitrum vs Optimism RPC infrastructure #### How to migrate from Google Cloud Platform (GCP) Blockchain Node Engine to Chainstack Google Cloud is shutting down Blockchain Node Engine (BNE) and Blockchain RPC on December 15, 2026, and has named Quicknode as the recommended migration target. Before you click “start migrating” on the partner page, do the math on what Google’s migration guide does not show you: how a credit-based pricing model — 20 credits per EVM request, 40 on Solana — rewrites your monthly bill compared to Chainstack’s 1 Request Unit per full call (2 per archive). For most BNE workloads — particularly anything archive-heavy or trace-heavy — the gap is 3–5x on the live calculator. This guide walks through the migration mechanics, the architectural choices, and the pricing math, with code examples for Ethereum, Polygon, and Solana. 🤔 Already convinced? Try Chainstack before you commit to the default migration path The shutdown timeline The shutdown comes in two phases, both documented in the BNE release notes: June 15, 2026 — limited support begins. New BNE nodes cannot be created. New Blockchain RPC endpoints cannot be provisioned. Existing resources keep running and receive critical updates. December 15, 2026 — full shutdown. Google deletes every existing node and endpoint. Any application still pointing at BNE URLs will start failing. There is no grace period. The first deadline is the one most teams underestimate. After June 15, you cannot spin up a fresh BNE node — not for testing, not for a parallel cutover, not for staging. Whatever you have on June 14 is what you have to work with until you fully migrate off. If you operate a production dApp, plan to be fully migrated by mid-November to leave margin for issues. What you are actually migrating Google is retiring two distinct products, and they have different migration paths: Blockchain Node Engine — dedicated full and archive nodes, per-project provisioning, supports Ethereum (Mainnet, Sepolia, Holesky, Goerli), Polygon (Mainnet, Amoy), and Solana. Blockchain RPC — a shared endpoint service, supports only Ethereum Mainnet and Holesky. Knowing which one you are on changes the migration. Blockchain RPC was a key-in-URL shared endpoint — the model Chainstack uses by default — so for those workloads migration is a pure host swap. BNE was per-project with a separate API key, so migration involves both a URL swap and removing the key from your request headers or query parameters. Details further down. Network mapping Every BNE network has a direct Chainstack equivalent. Two testnets need a different target because they are being retired across the broader Ethereum ecosystem, not just by Google: BNE networkChainstack equivalentNotesEthereum MainnetEthereum MainnetDirect swapEthereum SepoliaEthereum SepoliaDirect swapEthereum HoleskyEthereum Hoodi or SepoliaHolesky is being retired ecosystem-wide. Hoodi is the long-lived replacement.Ethereum GoerliEthereum Sepolia or HoodiGoerli is long deprecated.Polygon MainnetPolygon MainnetDirect swapPolygon AmoyPolygon AmoyDirect swapSolanaSolanaDirect swap. Chainstack adds Yellowstone gRPC, Trader Nodes, and Warp transactions. Beyond the BNE chains, Chainstack supports 70+ protocols, so this is also an opportunity to consolidate other infrastructure on a single provider. If you already know which network you are moving and want a side-by-side comparison with Quicknode before touching code, start with the Chainstack BNE migration overview. Choosing your Chainstack node type For most BNE migrations, a Global Node is the right default. It is a load-balanced endpoint that routes requests to the nearest healthy region and fails over in under one second, with archive and debug/trace support on paid plans. This is the closest match for Blockchain RPC users and covers most BNE full-node workloads. You need a different node type when the workload has specific characteristics: Predictable high steady traffic → Global Node with the Unlimited Node add-on. Converts to a flat monthly fee at a fixed RPS tier. This is the most direct apples-to-apples replacement for BNE’s flat per-node billing, and the reason it exists is precisely the workload shape BNE attracted. Isolation, compliance, or VPC Service Controls → Dedicated Node. Exclusive infrastructure, archive mode, full debug/trace, available on Pro plans and above. If you relied on BNE’s per-project isolation or VPC Service Controls, this is the analog. Trading and other latency-critical workloads → Trader Node. Regional, low-latency endpoints with the Warp transactions add-on for fast transaction landing on Solana, Ethereum, and BNB Smart Chain. Available on paid plans. Start with a Global Node unless you have a clear reason not to. The other options are not better — they are different, for specific workload shapes. (For workloads that must run inside your own cloud account — VPC Service Controls or strict data residency — see the FAQ.) Start with a Global Node unless you have a clear reason not to. The other options are not better — they are different, for specific workload shapes. The fastest migration path: AI agent Before walking through manual steps: if you use Claude Code, Codex CLI, Cursor, Windsurf, Gemini CLI, Antigravity, or any other agentic coding tool, the fastest migration is to let the agent do it. Chainstack publishes a runbook for this. Paste the following into your agent and approve the plan it generates: get docs.chainstack.com/docs/migrate-to-chainstack-with-ai.md The agent scans your codebase for BNE endpoints, checks coverage against Chainstack, plans the swap, and executes after you approve. It uses the Chainstack MCP server for live deployment options and pricing. Full details in the migrate to Chainstack with AI guide. The manual steps below are for teams that prefer to migrate by hand or want to understand what the agent is doing. Manual migration: endpoint and authentication What changes depends on which Google product you are leaving. From Blockchain RPC: The API key is already embedded in your endpoint URL — same model Chainstack uses — so this is a pure host swap. # Before — Blockchain RPC (key already in URL, copy from Google Cloud console) ETHEREUM_RPC_URL=YOUR_BLOCKCHAIN_RPC_ENDPOINT # After — Chainstack (key in URL path) ETHEREUM_RPC_URL=https://ethereum-mainnet.core.chainstack.com/YOUR_AUTH_KEY From Blockchain Node Engine: BNE authenticated with a separate Google Cloud API key, passed either as the X-goog-api-key header or as a ?key= query parameter. Chainstack puts the auth key in the URL path, so you need to both swap the URL and remove the header or query param. # Before — BNE JSON-RPC (key as query parameter) # https://json-rpc.NODE_ID.blockchainnodeengine.com?key=YOUR_BNE_KEY # Before — BNE JSON-RPC (key as X-goog-api-key header) # https://json-rpc.NODE_ID.blockchainnodeengine.com # Before — BNE WebSocket # wss://ws.NODE_ID.blockchainnodeengine.com?key=YOUR_BNE_KEY # Before — BNE Beacon Chain API # https://beacon.NODE_ID.blockchainnodeengine.com # After — Chainstack (key in URL path, no separate header or query param) ETHEREUM_RPC_URL=https://ethereum-mainnet.core.chainstack.com/YOUR_AUTH_KEY ETHEREUM_WS_URL=wss://ethereum-mainnet.core.chainstack.com/YOUR_AUTH_KEY If you authenticated to BNE with the X-goog-api-key header, remove the custom header entirely after migrating — Chainstack credentials live in the URL. If you used BNE’s beacon.NODE_ID.blockchainnodeengine.com endpoint for consensus-layer data (validator workloads, deep staking inspection), Chainstack exposes the standard Beacon Chain API on Ethereum nodes — point your client at the Chainstack Beacon endpoint and keep your existing calls. Connection examples The application code does not change. Only the URL. Python with web3.py: from web3 import Web3 # Before — BNE # w3 = Web3(Web3.HTTPProvider("https://json-rpc.NODE_ID.blockchainnodeengine.com?key=YOUR_BNE_KEY")) # After — Chainstack w3 = Web3(Web3.HTTPProvider("YOUR_CHAINSTACK_ENDPOINT")) print(w3.eth.block_number) JavaScript with ethers.js: import { JsonRpcProvider } from "ethers"; const provider = new JsonRpcProvider(process.env.ETHEREUM_RPC_URL); const block = await provider.getBlockNumber(); console.log("Current block:", block); TypeScript with viem: import { createPublicClient, http } from "viem"; import { mainnet } from "viem/chains"; const client = createPublicClient({ chain: mainnet, transport: http(process.env.ETHEREUM_RPC_URL), }); console.log(await client.getBlockNumber()); Polygon and Solana — what’s different Polygon. Mechanically the same as Ethereum — JSON-RPC surface identical, env-var swap pattern applies as-is. The chain-specific consideration is the heimdall vs bor split: if your BNE setup gave you access to heimdall consensus-layer endpoints, confirm your Chainstack node configuration matches. The Erigon archive client is available from the Business plan. For latency-sensitive trading on Polygon, Chainstack Trader Nodes provide regional low-latency endpoints. More on the Chainstack Polygon blog tag. Solana. The migration is a direct URL swap on the JSON-RPC side, but Solana also gives you tools BNE did not offer. For real-time streaming workloads, the Yellowstone gRPC Geyser plugin is available as an add-on from the Growth plan — typed events streamed from validator memory with sub-50ms latency, useful for trading bots, indexers, and analytics that previously polled getProgramAccounts. For latency-critical trading, Chainstack Trader Nodes add Warp transactions for direct-to-leader landing on Solana (Warp also covers Ethereum and BNB Smart Chain). The Solana trading infrastructure 2026 guide goes deeper. Pricing: flat RU vs credit multipliers This is where Google’s migration guide goes quiet. Chainstack and Quicknode use fundamentally different billing models: Chainstack charges 1 Request Unit per full-node call and 2 RU per archive call, flat across all methods. Quicknode uses API Credits with per-method multipliers. For EVM, every standard method costs 20 credits per request. Heavy methods — debug_traceCall, debug_traceBlockByNumber, trace_block — cost 40 credits. On Solana, every method costs 40 credits regardless of complexity. The dedicated BNE migration page collects customer notes from teams that switched off Quicknode after running into exactly this overage pattern. That gives a baseline of 20x credits-per-request on EVM and 40x on Solana compared to Chainstack Request Units. Below is the full multiplier table extracted from the Chainstack interactive calculator as of June 2026. Quicknode credit multipliers, per method EVM — 20 credits per request: eth_call, eth_chainId, eth_blockNumber, eth_gasPrice, eth_estimateGas, eth_feeHistory, eth_maxPriorityFeePerGas, eth_syncing, eth_getBalance, eth_getCode, eth_getStorageAt, eth_getLogs, eth_getFilterChanges, eth_getBlockByNumber, eth_getBlockByHash, eth_getBlockReceipts, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getTransactionCount, eth_sendRawTransaction, net_version, web3_clientVersion. EVM heavy — 40 credits per request: debug_traceCall, debug_traceBlockByNumber, debug_traceBlockByHash, trace_block. Solana — 40 credits per request, for every method: getAccountInfo, getProgramAccounts, getBalance, getMultipleAccounts, getTokenAccountsByOwner, getTokenAccountBalance, getTokenSupply, getSignatureStatuses, getSignaturesForAddress, getTransaction, getConfirmedTransaction, getLatestBlockhash, getRecentBlockhash, getBlockHeight, getSlot, getMinimumBalanceForRentExemption, simulateTransaction, sendTransaction, logsSubscribe. On Chainstack, all of the above cost 1 Request Unit (full) or 2 RU (archive). No method has a different multiplier. Real-world workload pricing The interactive calculator maps those per-method multipliers into final monthly bills across four workload profiles. Numbers as of June 2026: Workload profileChainstackQuicknodeAlchemyQN markup vs ChainstackDefault (general reads)$49 (Growth)$208$1754.2xData (logs + archive heavy)$199 (Pro)$703 ($499 sub + $204 overage)$7883.5xDeFi$49 (Growth)$212$1764.3xWallet$49 (Growth)$242$1804.9x Chainstack pricing calculator with the Data workload profile: an Ethereum indexer running 66.7M monthly requests dominated by eth_call, eth_getLogs, and eth_getFilterChanges. The Pro plan ($199) absorbs the entire workload in included Request Units. Quicknode Scale ($499) hits its credit ceiling and adds $204 in overage. Open the calculator and run your own numbers →. Two patterns matter beyond the headline: Chainstack’s “usage and additional fee” is $0 across all four profiles. The monthly subscription covers the included Request Units, and the profiles fit within them. On Quicknode the same profiles always show a “subscription + usage” structure — included credits run out, overage stacks on top. Quicknode’s best-value plan changes by workload. Default fits in Growth, Data needs Scale, DeFi needs Build. A team picking a Quicknode plan based on initial light traffic gets force-upgraded as soon as archive or logs queries appear — exactly the workloads BNE attracted because BNE gave archive nodes by default. For Solana workloads the gap is the largest. The 40-credit-per-request rate applies to every method, including the ones your indexer or trading bot calls thousands of times per second: getProgramAccounts, getAccountInfo, getTokenAccountsByOwner, getSignaturesForAddress. Plug your actual method distribution into the Chainstack calculator before committing — the number that comes back is often the deciding factor on its own. Validate and cut over Once you have a Chainstack node provisioned and your endpoint URLs swapped, run through this before you decommission BNE: Test your actual RPC methods. Replay a recent day of production traffic against the Chainstack endpoint. Compare responses and latency percentiles. Particular attention to archive queries, debug/trace methods, and WebSocket subscription behaviour. Check throughput at your real rate. Review the throughput guidelines and add the Unlimited Node add-on if you need a flat-fee high-volume tier. Run blue-green in production. Use a feature flag or weighted load balancer. Start with 10% traffic on Chainstack, observe error rates, ramp gradually. Keep BNE as fallback until you are confident. Set up access rules and IP allowlists for the new endpoint via the access rules guide before exposing it to production traffic. Decommission. Delete BNE nodes from your Google Cloud console once Chainstack is stable. Google deletes Blockchain RPC endpoints automatically on December 15, 2026, but BNE nodes you delete yourself to stop the meter. When Chainstack isn’t the right answer A few cases where the migration off BNE is not a straightforward win for Chainstack: You need GCP Marketplace consolidated billing. Chainstack is not listed on GCP Marketplace. If your finance team requires single-invoice procurement through Google Cloud, this needs a sales conversation rather than a self-serve migration. Your workload is dominated by light reads under the included Request Units of any provider. At very low volumes (sub-3M RU/month), every provider has a free tier and the pricing-model differences become irrelevant. Pick the developer experience you prefer. You operate an in-house infrastructure team and want full ownership. Self-hosting your own nodes is a real option, especially if you already run validators or relay infrastructure. If you have the operational maturity to run nodes from scratch, you may not need any managed provider. You need debug or trace on the free Developer plan. Debug and trace methods on Global Nodes require a paid plan. If your prototype depends on debug_traceCall and you cannot commit to Growth, plan accordingly. You need a chain Chainstack doesn’t support. Chainstack covers 70+ protocols, but very niche or brand-new chains may not be available — check the protocols list before committing. Conclusion The migration mechanics off BNE are simple: swap the URL, remove the BNE API key from headers or query params, and let your application keep running. For most workloads a Global Node is the right default. Dedicated and Trader options exist for specific shapes — isolation and latency — and the official migration doc is the canonical reference for the mapping. The harder decision is which provider you migrate to. Google’s recommendation to use Quicknode is one path. It is also a commercial partnership, not the result of a workload-by-workload comparison. For BNE workloads that lean archive-heavy or trace-heavy — exactly the workloads BNE attracted by offering archive nodes — credit-based billing at 20x on EVM and 40x on Solana produces bills 3–5x higher than flat Request Units. Run the numbers against your real method distribution before committing. The migration window is shorter than the December date suggests. June 15 is when your safety net disappears: no new BNE nodes for testing, no parallel cutover from a clean source. Start now, validate against your real workload, and use the AI agent runbook if you want the discovery and swap done in minutes rather than days. See why teams switched from Quicknode → Create a free Chainstack account → FAQ How long does the migration take? For a simple endpoint swap with no archive dependencies, most teams complete cutover in 2–4 hours of focused work plus a week of parallel-run validation. If you use the AI agent migration path, the endpoint discovery and swap can be done in minutes — the validation week is the same. What happens if I miss the December 15, 2026 deadline? Google deletes the nodes and endpoints. Any application still pointing at BNE URLs returns connection errors. There is no grace period. Can I keep billing through GCP Marketplace? Chainstack is not currently listed on GCP Marketplace. Billing is direct with Chainstack. If consolidated cloud billing is a hard requirement for your finance team, raise it with Chainstack sales early — there are workarounds for enterprise contracts. Does Chainstack support the same JSON-RPC methods I used on BNE? For Ethereum, yes — full JSON-RPC compatibility including the debug and trace namespaces on Dedicated Nodes and on Global Nodes on paid plans. See the debug and trace APIs reference for per-protocol availability. BNE disabled debug and admin by default; on Chainstack, debug/trace is enabled via node configuration on supported plans. I relied on VPC Service Controls — what is the equivalent? Two options. Dedicated Nodes give you isolated infrastructure under Chainstack’s management — self-serve from the Pro plan and above, and the simpler choice for most cases. Hybrid hosting goes further: the nodes run inside your own cloud account, with Chainstack’s interface managing them. Hybrid is contact-sales only, takes longer to set up (no instant Bolt deploy, no daily automated backups by default), and is billed as subscription plus node management fee rather than Request Units. If your compliance team requires nodes inside your VPC and you have time before December 15, contact Chainstack to scope a hybrid deployment. Otherwise, a Dedicated Node in your preferred region is the faster path. What is the cleanest way to test in parallel before cutover? Provision the Chainstack node, point a staging copy of your application at it, and replay a recent day of production traffic. For trading and indexing workloads, run both endpoints live in shadow mode (Chainstack receives a mirrored copy of production traffic but its responses are not used) for at least 72 hours before flipping any real traffic. Related reading Same comparison, different angles Chainstack vs Quicknode vs Alchemy: most cost-effective blockchain API in 2026 Quicknode RPC provider overview (2026) How to migrate your blockchain RPC endpoints to Chainstack For specific workloads Solana trading infrastructure in 2026 Deep dive into Ethereum trace APIs Canonical references Official Chainstack BNE migration docs Migrate to Chainstack with AI agent #### How to migrate from Grove to Chainstack (2026 guide) Introduction Grove — originally Pocket Network Inc., founded in 2017 by Michael O’Rourke, Valeria Benitez Florez, Pabel Nunez, and Luis Correa de Leon — has wound down after nine years. The Grove Portal settled more than a trillion requests across 60+ blockchains during its run. Now the rpc.grove.city and docs.grove.city domains no longer resolve, paid customers were migrated to the free Pocket Network Foundation endpoints at api.pocket.network starting November 2025, and in July 2026 Grove the company published its farewell note. Two groups of teams are affected — and the fix looks slightly different depending on which one you’re in: Apps still calling https://<chain>.rpc.grove.city/v1/<app-id> — these endpoints are offline. Your calls are throwing DNS errors right now, and you need a new provider before anything else works. Apps that followed Grove’s redirect to api.pocket.network — these calls still respond, but you’re on the free Pocket Foundation’s shared, rate-limited public endpoints with no SLA. Fine for prototyping; not what you want as the read path for a production dApp. This guide is for teams in either bucket making the move to a dedicated RPC provider. It walks through the endpoint swap, the one code change you actually need (authentication), the chain mapping, and the validation you should do before decommissioning anything. The official Chainstack migration doc is the canonical reference; this article covers the same ground with the context and the trade-off calls Chainstack has run into with teams moving off Grove. What actually happened The grove.city site as of July 2026 — the farewell note that replaced the Grove Portal. The Grove wind-down happened in two stages, and understanding which stage affected you changes what you need to do. November 2025 — the gateway wind-down. Grove announced it was stepping away from operating the Grove Portal and moving up the stack. This came right after two protocol milestones: the Shannon upgrade shipped June 3, 2025, and PATH 1.0 — the reference gateway implementation — reached its milestone on November 4, 2025, enabling anyone to launch a permissionless Pocket gateway. Paid and public traffic migrated to new public endpoints hosted at api.pocket.network, managed by the Pocket Network Foundation with round-robin load balancing across PNF and community gateways (DevDAO Cloud, Pokt.ai, Stakenodes). The handoff was orderly — same JSON-RPC methods, same chain coverage, host swap only. 2026 — the pivot and the closure. Grove used the freed-up team to build a creator-payments platform on the x402 protocol, which ran for five months and settled ~6,000 payments from about 1,000 fans to 400 creators. In July 2026, the company published a farewell note and closed. The rpc.grove.city and docs.grove.city subdomains stopped resolving. If your code still has rpc.grove.city URLs, you already know because your app is throwing DNS errors. If you followed the November redirect to api.pocket.network, your calls still work — Pocket Network itself continues under the PNF as a non-profit, and the Foundation runs the public endpoints as part of its F-Chains “public good” program with routing across 5,000+ independent supplier nodes. But you are now on shared, unmetered infrastructure with no dedicated capacity, no isolation, and no support contract. That is the exact reason most teams move to a paid provider even when the free path still resolves. What migration actually looks like For most Grove users, the migration is a one-line URL swap. Both Grove and Chainstack speak standard JSON-RPC over HTTPS. The methods and responses are identical. The one meaningful code change is authentication. Grove endpoints were open. No key, or an optional app-id in the URL path (https://eth.rpc.grove.city/v1/YOUR_APP_ID). Anyone with the URL could call them. The current Pocket Foundation successor endpoints follow a similar open pattern with a chain subdomain (https://eth.api.pocket.network) — also key-free. Chainstack endpoints authenticate every request. The default method is an auth token embedded directly in the endpoint URL. You copy the full HTTPS endpoint from the Chainstack console and use it as-is — no separate Authorization header, no query parameter to add, no code changes beyond the URL itself. In practice: // ethers.js — before (Grove, retired) const provider = new ethers.JsonRpcProvider( "https://eth.rpc.grove.city/v1/YOUR_APP_ID" ); // ethers.js — after (Chainstack) const provider = new ethers.JsonRpcProvider( "YOUR_CHAINSTACK_ENDPOINT" ); const block = await provider.getBlockNumber(); console.log(`Current block: ${block}`); Same pattern in Python: from web3 import Web3 # Before — Grove (retired) # web3 = Web3(Web3.HTTPProvider("https://eth.rpc.grove.city/v1/YOUR_APP_ID")) # After — Chainstack web3 = Web3(Web3.HTTPProvider("YOUR_CHAINSTACK_ENDPOINT")) print(f"Current block: {web3.eth.block_number}") Non-EVM chains work the same way. On Solana, you point your client at the Chainstack Solana endpoint and keep calling the standard Solana JSON-RPC methods. On Sui or TRON — the pattern is identical, only the RPC surface changes. If you need something other than URL-embedded auth — basic auth for infrastructure that can’t carry secrets in URLs, the Chainstack Platform API key for programmatic node management, or the gRPC x-token for streaming workloads — see Authentication methods. Most teams start with the default and never revisit it. The fastest migration path: AI agent Before the manual steps: if you use Claude Code, Codex CLI, Cursor, Windsurf, Gemini CLI, Antigravity, or any other agentic coding tool, the fastest migration is to let the agent do it. Chainstack publishes a runbook for exactly this. Paste the following into your agent and approve the plan it generates: get docs.chainstack.com/docs/migrate-to-chainstack-with-ai.md Pasting the one-liner into Claude Desktop fetches the Chainstack migration runbook — the agent then walks through Assess, Plan, and Implement phases. The agent scans your codebase for Grove endpoints (and any other RPC URLs), checks coverage against Chainstack, plans the swap, and executes after you approve. It uses the Chainstack MCP server for live deployment options and pricing. Full details in the migrate to Chainstack with AI guide. The manual steps below are for teams that prefer to migrate by hand or want to understand what the agent is doing. Chain mapping Every chain Grove supported that Chainstack also supports maps directly. The subdomain in your Grove URL tells you what to look for: Grove subdomainChainstack protocolethEthereumbaseBasearb-oneArbitrumopOptimismpolyPolygonbscBNB Smart ChainavaxAvalanchegnosisGnosis ChainlineaLineascrollScrollsonicSonicopbnbopBNBharmonyHarmonykaiaKaia (ex. Klaytn)solanaSolanasuiSuitronTRON Chainstack supports 70+ chains total, so if you were on Grove for a subset of these, this is also a chance to consolidate other RPC infrastructure onto a single provider. The protocols and networks page is the authoritative current list. Two edge cases worth flagging. If you were using Grove for a chain not on this table — some of the more experimental Cosmos SDK chains, or something added to Pocket recently — check the Chainstack list first; if it is not there, it may still be available as a dedicated deployment via Chainstack sales. And if your app was using an app-id-per-chain pattern on Grove (one Portal application, many chain endpoints), that maps to one Chainstack project with multiple nodes — same organizational shape, different terminology. Picking your Chainstack node type Grove Portal was effectively one product. Chainstack has four, and picking the right one is where teams either overthink or underthink the migration. The right default for most Grove users is a Global Node (docs) — load-balanced, routes requests to the nearest healthy region, covers standard queries for standard workloads. This is the closest analog to what Grove Portal gave you: a URL, geographic redundancy behind it, no capacity planning required. Most Grove migrations land here. You need a different node type when your workload has specific characteristics: Predictable high steady traffic → Global Node with the Unlimited Node add-on. Flat monthly fee at a fixed RPS tier. This is what you want if you know your traffic profile and want to lock in cost. Isolation, compliance, or dedicated capacity → Dedicated Node (docs). Exclusive infrastructure, archive mode, full debug/trace. If Grove’s shared model was already borderline for your compliance posture, Dedicated is the direct upgrade. Trading and latency-critical workloads → Trader Node with the Warp transactions add-on. Regional low-latency endpoints, direct-to-leader landing on Solana, Ethereum, and BNB Smart Chain. Nodes on your own infrastructure → Chainstack Self-Hosted. Your hardware, your data, with a Kubernetes-native control plane on top. Right choice if compliance requires nodes on your own hardware. Start with a Global Node unless you have a clear reason not to. The other options are not upgrades — they are different, for specific workload shapes. Migrating The mechanics, in order: 1. Create a Chainstack account and deploy a node. Sign up with your GitHub, X, Google, or Microsoft account — no credit card required for the free tier. Create a project, then deploy a Global Node for the chain you are migrating first. Deploying a new node — pick your protocol and network. Grove users migrating from eth.rpc.grove.city select Ethereum chain here. 2. Copy the endpoint. Open the node’s Access and credentials tab and copy the HTTPS endpoint. The auth token is already in the URL — no separate configuration needed. The Access and credentials tab in the Chainstack console — the HTTPS endpoint already includes your auth token, no separate header configuration needed. 3. Swap the URL in your code. The cleanest way is via environment variables, if you are not already using them. Replace the Grove URL with the Chainstack endpoint: # Before ETH_RPC_URL=https://eth.rpc.grove.city/v1/YOUR_APP_ID # After ETH_RPC_URL=YOUR_CHAINSTACK_ENDPOINT If you have hardcoded URLs in config files (hardhat.config.js, foundry.toml, Docker files), this is a good moment to move them to env vars while you are here. The next migration you do — provider or otherwise — will be minutes instead of hours. 4. Test the actual methods your code uses. Not just eth_blockNumber — the specific calls your application depends on. For a straightforward dApp that is standard reads and writes. For an indexer, archive queries and log range calls. For a trading bot, transaction submission latency under real conditions. The debug and trace APIs reference covers what’s available where. curl -X POST \ -H "Content-Type: application/json" \ --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ YOUR_CHAINSTACK_ENDPOINT 5. Run parallel for at least 24 hours before decommissioning anything. If you were on the free api.pocket.network endpoints, keep them as a fallback until you are confident. If you were on paid Grove that is now offline, this step is moot — you are already on the new endpoint by necessity. Chainstack’s dashboard shows request counts, error rates, and latency per node — monitor for the first day before turning off the old path. What Chainstack adds that you did not have on Grove Grove was a solid decentralized gateway with a clean developer experience. The switch to Chainstack adds a few things that only start to matter once you have real production traffic: Dedicated capacity. Grove Portal was multi-tenant across a decentralized supplier network. Chainstack Global Nodes are load-balanced but the capacity is yours to allocate — you are not competing with other users’ traffic bursts for QoS. Higher rate limits and burst tolerance. Free tiers on shared infrastructure have hard ceilings that get hit at exactly the wrong moment. Paid Chainstack plans scale linearly, and the Unlimited Node add-on removes per-request accounting entirely at an RPS-tiered flat fee. Archive and debug/trace on paid plans. Not just eth_getBalance at any block, but the full debug_* and trace_* namespaces on Ethereum, Polygon Erigon, and the other chains where they are meaningful. Direct support. If a chain has an incident or a new fork introduces breaking behavior, you have someone to open a ticket with rather than watching community channels. 1 Request Unit per full call, 2 per archive. Flat billing across all methods — no per-method credit multipliers. Compared to providers charging 20 credits per EVM request and 40 on Solana, this is the difference that changes the shape of your monthly bill. Run your own numbers on the interactive pricing calculator. None of these matter for a hobby project. All of them start mattering the moment you have paying users or a business that depends on the read path staying up. Common issues during migration A few things that come up more often than they should: IssueCauseFix401 UnauthorizedYou added an Authorization header thinking Chainstack works like Grove-with-an-app-id. Chainstack embeds the auth token in the URL, not a header.Remove the Authorization header and copy the full endpoint URL from the node access details page.Archive queries returning errorsYou are hitting a Global Node without archive access.Upgrade to a plan with archive support, or deploy a Dedicated Node in archive mode for the chain you need. See features availability for per-plan coverage.debug_traceTransaction not supportedDebug and trace on Global Nodes require a paid plan. Free Developer tier does not expose these methods.Upgrade to at least Growth if your prototype depends on debug_* or trace_* namespaces.WebSocket disconnectsLong-lived connections drop occasionally on every provider — not Chainstack-specific.Add reconnect logic with exponential backoff to your WSS client. Standard practice regardless of provider.Method not found on SolanaSome Solana methods require specific node configurations (Trader Node, Yellowstone gRPC, or specific plan).Search the Chainstack docs for the exact method name to confirm required node type. When Chainstack is not the right answer A few honest cases where the migration is not a straightforward win: Your workload is dominated by light reads under any free tier. At very low volumes, every provider has a free plan and the pricing-model differences do not matter. Pick the developer experience you prefer. You need decentralization as a hard architectural requirement. If your product’s positioning depends on being served by a decentralized supplier network — some governance tools, some pro-decentralization dApps — the Pocket Network Foundation’s free api.pocket.network endpoints or a self-hosted Pocket gateway via PATH may be a better fit than any centralized provider, Chainstack included. For higher throughput on the decentralized path, Pocket also offers application staking — stake POKT on-chain for dedicated access proportional to your stake. You want to run your own infrastructure. Chainstack Self-Hosted is the middle ground — your infrastructure, your data, with a Kubernetes-native control plane on top. Worth looking at if your compliance team wants nodes on your own hardware. For a full DIY vs managed comparison, see DIY vs Chainstack Self-Hosted. Conclusion Nine years, more than a trillion requests, an orderly two-stage wind-down. The Grove closure was as clean as these things get in Web3 — a documented handoff to Pocket Network Foundation endpoints, months of transition, and a clear final note. Most teams affected have already made a move. The remaining decision is whether the api.pocket.network free endpoints are enough for your workload, or whether you want dedicated capacity, higher throughput, archive access, and support. The Chainstack migration itself is one line. Copy the endpoint from the console, swap the URL in your code, run a validation pass, and decommission the old configuration. If you use an AI coding agent — Claude Code, Codex, Cursor, Windsurf — the migrate to Chainstack with AI runbook does the endpoint discovery and swap for you. Create a free Chainstack account → FAQ Do my Grove endpoints still work? rpc.grove.city endpoints stopped resolving in July 2026 when Grove closed. If your code still points at them, calls are failing with DNS errors. api.pocket.network public endpoints continue to work under the Pocket Network Foundation, but they are free, shared, and load-balanced across community gateways with no SLA. How long does the migration take? For a straightforward URL swap, most teams complete the code change in under an hour and validate over the next day or two. If you use an AI coding agent to discover and swap endpoints, the code change is minutes; the validation window is the same. Do I need to change my JSON-RPC method calls? No. Grove and Chainstack both expose standard JSON-RPC. Every method your Grove code called works on Chainstack with the same signature and response format. The only code difference is authentication, and that is handled entirely by the URL. What happens to my existing Grove authentication (app-id in URL path)? Chainstack’s auth token is already embedded in the endpoint URL you copy from the console — same URL-in-path pattern, different token format. Remove the Grove app-id from your URLs and replace the entire endpoint with the Chainstack one. Which chain node type should I pick? Global Node for most workloads — load-balanced, geo-routed, closest analog to Grove Portal. Dedicated Node if you need isolation, guaranteed capacity, or the full debug/trace namespace. Trader Node if you are running latency-sensitive trading workloads. Unlimited Node add-on if you want a flat monthly fee at a fixed RPS tier instead of per-request accounting. Is Pocket Network the same as Grove? No. Pocket Network is the underlying decentralized RPC protocol, run by the Pocket Network Foundation. Grove was the first gateway built on top of it, operated by a separate company (originally Pocket Network Inc., renamed Grove). The protocol continues; the gateway is retired. Free api.pocket.network endpoints are run directly by the Foundation. Can I keep using free Pocket Network endpoints alongside Chainstack? Yes. Some teams keep api.pocket.network as a fallback path for non-critical reads while running production traffic through Chainstack. On EVM chains, eRPC or a similar client-side router can split traffic by method or fail over between the two. For non-EVM chains, you would need to handle the fallback in application code. Related reading Canonical references Official Chainstack Grove migration docs Migrate to Chainstack with AI agent Authentication methods Protocols and networks Other migration guides How to migrate your blockchain RPC endpoints to Chainstack — general migration guide How to migrate from GCP Blockchain Engine to Chainstack — Google Cloud sunset migration Chainstack vs Quicknode Chainstack vs Alchemy Pocket Network / Grove background Grove’s Next Chapter (Nov 2025) — the original wind-down announcement Pocket Network Foundation — successor operator of api.pocket.network Pocket Network roadmap — where the protocol goes from here Grove farewell note — the closing statement #### How to migrate your blockchain RPC endpoints to Chainstack Your RPC provider sits between your app and every chain it touches. Every call you make — reading state, submitting transactions, listening for events — goes through it. So when that provider is slow, unreliable, or missing support for the chain or method you need, you feel it immediately. Your users feel it too. Most developers switch providers for one of three reasons: they hit a rate limit wall they can’t negotiate around, they need a chain or node type that isn’t supported, or the reliability just isn’t there anymore. Whatever brought you here, the migration itself doesn’t have to be painful — but it does need to be done in the right order. Skip the planning step and you’ll find out what you missed in production. This guide walks through the full process: finding every endpoint in your codebase, verifying Chainstack covers what you need, testing before you touch anything live, and making the actual swap cleanly. What you need before starting Access to your codebase — source files, .env, config files A Chainstack account — free to start Your Chainstack API key — Settings → API Keys 30–60 minutes — more if you have a lot of endpoints Step-by-step guide Step 1: Find every endpoint in your codebase The first mistake people make is assuming they know where all their RPC endpoints are. They swap the obvious ones, ship it, and then something breaks in a background job or a config file they forgot about. Don’t guess. Scan everything — source code, environment files, Hardhat and Foundry configs, Docker files, CI pipelines. RPC URLs end up in surprising places. Source code — look for hardcoded https:// or wss:// RPC URLs Environment files — .env, .env.local, .env.production Config files — hardhat.config.js, foundry.toml, truffle-config.js, YAML/JSON Docker and CI files — docker-compose.yml, GitHub Actions, CircleCI These commands will catch most of them: # Find known provider URLs grep -r "infura.io\|alchemy.com\|quicknode.com\|ankr.com\|blastapi.io" . \ --include="*.js" --include="*.ts" --include="*.env" --include="*.json" --include="*.yaml" # Find anything that looks like an RPC endpoint grep -rE "https?://[a-zA-Z0-9.-]+\.(io|com|net)/[a-zA-Z0-9]+" . \ --include="*.js" --include="*.ts" For each endpoint you find, record the chain and network, the protocol (HTTP, WebSocket, gRPC, Geyser), and the RPC methods your code actually calls — especially if you’re using anything beyond standard reads, like debug_traceTransaction or historical archive queries. Step 2: Check what Chainstack supports Before deploying anything, verify that Chainstack covers your chains and node requirements. Don’t rely on memory or assumptions here — the fastest way to waste time is migrating to a node that doesn’t support the methods you need. The best place to check is the Chainstack docs — look up each chain you found in Step 1 to confirm supported networks, node types, and available methods. If you’re using the Chainstack MCP at https://mcp.chainstack.com/mcp, you can query this programmatically. Chainstack has four node types. Which one you need depends on what your code does: Global Node — load-balanced, routes requests to the closest available location, covers standard queries for most use cases Unlimited Node — flat-fee add-on for any existing node, predictable monthly costs with no per-request overage charges, pick an RPS cap that fits your throughput Trader Node — regional, low-latency endpoints with Warp transaction support Dedicated Node — exclusive compute resources, full customization, debug and trace APIs WebSocket — verify wss:// is available for that chainSolana streaming — check Geyser plugin supportgRPC — verify per-chain Some features can’t be set up via API and need manual configuration in the Chainstack console: Dedicated node deployment — contact Chainstack sales Solana Yellowstone gRPC Geyser plugin — node Add-ons tab Unlimited Node add-on — node Add-ons tab MEV protection — node details page Warp transactions — node details page IP allowlisting / access rules — node Security tab Queue these up before you start deploying so they don’t block you mid-migration. Step 3: Test before you swap If you already have Chainstack nodes deployed, test them against your actual RPC methods before touching production. This is the step most people skip and then regret. Send real test requests for each method your code uses. A basic call: curl -X POST \ -H "Content-Type: application/json" \ --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ YOUR_CHAINSTACK_ENDPOINT A debug/trace call: curl -X POST \ -H "Content-Type: application/json" \ --data '{"jsonrpc":"2.0","method":"debug_traceTransaction","params":["0xYOUR_TX_HASH",{}],"id":1}' \ YOUR_CHAINSTACK_ENDPOINT If your app makes batch calls or polls at high frequency, test at that throughput too — not just single requests. Record what works, what fails, and any 429 rate limit responses. Step 4: Plan the migration With your endpoints inventoried and Chainstack support confirmed, map out the full replacement before writing a single line of code. Every old endpoint gets a specific Chainstack equivalent — either an existing node or one you still need to create. https://mainnet.infura.io/v3/… → your Chainstack Ethereum mainnet endpoint — existing node wss://eth-mainnet.g.alchemy.com/… → your Chainstack Ethereum mainnet WebSocket endpoint — same node https://polygon-mainnet.g.alchemy.com/… → need to create — confirm archive requirement first https://solana-api.projectserum.com → flag: check Geyser — may need Add-on Stop here and review the plan. Don’t proceed until every endpoint has a mapped replacement, node type requirements are confirmed, and any manual console setup items are queued. Answering these questions now costs minutes. Answering them in production costs much more. Step 5: Deploy new nodes For any endpoints that need a new Chainstack node, the fastest path is through the console: Log in to console.chainstack.com Create or select a project Click Add node Choose chain → network Select Global Node for instant deployment Once deployed, copy the HTTPS and WSS endpoint URLs from the node details page. Step 6: Replace the endpoints The cleanest approach is environment variables — swap the value, not the code. # before ETH_RPC_URL=https://mainnet.infura.io/v3/YOUR_KEY # after ETH_RPC_URL=YOUR_CHAINSTACK_ENDPOINT If you have hardcoded URLs in config files, move them to environment variables while you’re here. Future migrations will take minutes instead of hours. // hardhat.config.js — before networks: { mainnet: { url: "https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY" } } // hardhat.config.js — after networks: { mainnet: { url: process.env.ETH_RPC_URL } } WebSocket connections follow the same pattern: // before const provider = new ethers.WebSocketProvider("wss://eth-mainnet.g.alchemy.com/v2/YOUR_KEY") // after const provider = new ethers.WebSocketProvider(process.env.ETH_WS_URL) Step 7: Verify everything works Run your full test suite. Then manually confirm the things tests often miss: Basic read calls return expected data (eth_blockNumber, eth_getBalance) debug_trace* or trace_* calls work if your code uses them WebSocket connections establish and receive events Archive queries return historical data at the correct block No 429 errors under normal load Error handling responds correctly to Chainstack’s error format Monitor for the first 24 hours. Chainstack’s dashboard shows request counts, error rates, and latency per node — use it. Common issues IssueFix401 UnauthorizedYour Chainstack endpoint URL already contains your credentials. No separate Authorization header needed. Copy the full URL from the console.Archive queries returning errorsYou’re hitting a full/elastic node. Create an archive node for that chain and update the endpoint.debug_traceTransaction not supportedSwitch to an archive with debug/trace node. Not all node types expose these methods.WebSocket disconnecting frequentlyAdd reconnect logic with exponential backoff. Best practice regardless of provider.Method not found on SolanaSome Solana methods require specific node configurations. Search the Chainstack docs for the method name to confirm support and node type. What to do if something is unsupported Chain not in the docs — it may be available as a dedicated deployment. Contact Chainstack sales. Method not in the docs — treat it as unsupported and flag it before migrating. Don’t assume. Technical issue with an existing node — open a ticket at support.chainstack.com. Something unclear after reading the docs — contact support. Don’t guess. Wrapping up A provider migration is one of those tasks that feels risky until you’ve done it once. The risk is real — but it’s concentrated in the planning phase. Find everything, verify support, test on real methods, map it out before you touch code. Do those four things and the actual swap is just find-and-replace. If you run into anything the docs don’t cover, Chainstack support is the right place to start — not guessing, not assuming, and definitely not finding out in production. Start on Chainstack for free → #### How to mint Solana SPL tokens in 2 minutes This guide will show you how to mint Solana SPL tokens in just 2 minutes. To start, make a directory for your project. mkdir solana token Now move into that directory cd solana-token And now you need to configure your client with an RPC node. In this case, we are going to use Chainstack in order to launch a Solana Devnet node. If you do not have a Chainstack account yet, you can sign up for free in order to follow along with this tutorial. After you have your account, you can go ahead and deploy a node by following the steps in the video below. Once your node is running, you can click on it to see its details. Scroll to the bottom of the page and grab the HTTPS endpoint. Now go ahead and add that HTTPS endpoint into your client configuration. config set --url https://nd-560-135-593.p2pify.com/2586ee2280f80a8953f2ff1b6f4077b4 Now you should have the RPC URL set, as long as with the web socket URL to go with it. Now we are going to generate a new Solana account on the Devnet, which we will do with solana-keygen. We will do this in a new subdirectory of the directory that we’ve just created called “wallet”, and we’ll name this keypair1.json solana-keygen new --outfile /wallet/keypair1.json You should see that a new account has been created, along with its public key. Get funds from the faucet You need to take the public key and fund it with some Devnet Solana in order to mint your tokens. You can use this faucet https://solfaucet.com/ in order to request some Devnet tokens. Just input your address there and click on Devnet. Now we need to make sure that the account that we’ve just created is the default signer in our client, which we can do with the Solana config command. solana config set --keypair /wallet/keypair1.json Now we can go ahead and start creating the SPL token itself. Start by doing: spl-token create-token This will call the default token program on devnet through the Chainstack node that we deployed earlier, and this will be about 9 decimals by default. Now we need to create the token account, which we can do with: spl-token create-account {input address of the token that was generated here} Now that this account is generated, we can go ahead and mint our SPL token. We can do this with: spl-token mint {input token address here} 1000 Recap of what you did in order to mint Solana SPL tokens: You’ve set up a project. Created an account. Funded that account with devnet tokens. Created a token. Minted a token. You should have the 1000 minted tokens in your token address. You can open the Solana devnet explorer and search for your address in order to check its balance. Check the “Tokens” section, and you should have the 1000 tokens in there. And that’s a wrap. If you are looking for more solana-web3.js tutorials, make sure to check out our blog and developer portal. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to retrieve historical data from a Uniswap V3 liquidity pool We received a question from one of our community members, and we decided to make a tutorial in order to answer it. The question was “Is there a special function in a smart contract that allows you to view, and query the historical data of a contract?”. In order to answer this question we need 3 things: A function that we will use to query the state of the blockchain. An access point to the blockchain that we will retrieve the data from, aka a blockchain node. A way of actually retrieving the data. Uniswap V3 pool example For this tutorial, we will take the wrapped ETH (WETH) – USDC pool from Uniswap V3 as an example 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640 and we will use a Chainstack node to interact with the blockchain. Before retrieving the historical state of this pool, let’s first try to retrieve the data for the current state of the network, as of the latest block. For this purpose, we will use etherscan.io. You can do this in multiple ways, but let’s keep things very simple. In case you don’t know, Etherscan is a great tool for interacting with the data on the Ethereum blockchain. Let’s retrieve the exchange rate for the WETH-USDC Uniswap V3 liquidity pool. Open up this link in a new tab. This is the contract address of the WETH-USDC pool on UniswapV3, and call the slot0 function at #11. Just click on the name of the function and then click the “Query” button—check the image below. Figure 1: Querying the slot0 method in the Uniswap V3 smart contract on Etherscan; Source: Etherscan This is a read-only operation and you do not need to pay gas fees because it is not changing the state of the blockchain. This function will read the changes of the latest block and it returns the square root price of the exchange rate of the WETH-USDC tokens. How to query the historical state of a blockchain Depending on how far back you want to query the state of the blockchain you may need an archive node or a full node. An Ethereum archive node, as opposed to a full node, allows developers to access the historical state of the blockchain at any point in the past, up to the genesis block, whereas a full node, allows you to query the historical state only up to the latest 128 blocks. If you want to query the state of the blockchain beyond the latest 128 blocks, then you will need an archive node instead of a full node. Deploy your own node If you do not have a Chainstack account yet, you can sign up for free in order to follow along with this tutorial. After you have your account, you can go ahead and deploy a node by following the steps in the video below. We offer both full nodes and archive nodes for Ethereum, but please note that for archive nodes you will need to subscribe to one of our paid plans. The full nodes can be deployed for free. For the purpose of this tutorial, we will deploy a full node and query the data from a block that’s within the latest 128 blocks, so that we do not need an archive node, and you can follow along for free. Figure 2: Deploying an Ethereum Mainnet node on Chainstack; Source: Chainstack console Once your node is running, you can click on it to see its details. Scroll to the bottom of the page and grab the HTTPS endpoint, you will need it in the following steps. Figure 3: Obtaining HTTPS endpoint for deployed Ethereum Mainnet node; Source: Chainstack console Using eth_call to retrieve historical data from the blockchain Next, we are going to use the eth_call method with curl. This is a read-only call. We will send a query call to the chain using the slot0 function at a specific block in the past. You can find a code sample in our documentation here. Starting from the sample that we provide in our docs, we will fill in the different fields in the code. curl --request POST \ --url {paste HTTPS endpoint here and delete curly braces} \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --data ' { "jsonrpc": "2.0", "method": "eth_call", "id": 1, "params": [ { "to": "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640", "data": "0x3850c7bd" }, "latest" ] } ' In the code above, you must replace the -- url with your HTTPS endpoint from the Chainstack node that was deployed earlier. We are now querying the node with the eth_call method which does a simulation call. In our case, it will just query the chain to the WETH-USDC Uniswap V3 liquidity pool. In the to field, you can input the address of the smart contract that you want to query. In the “data” field we need to provide the signature of the slot0 function from the smart contract. In Solidity, if you want to find out a function’s signature, you need to take the function, do a Keccak256 encoding of it, and then take the first four bytes out of it, and that’s your function signature. If it sounds too complicated, don’t worry, we have you covered. You can use what we like to call the EVM Swiss Army Knife. Just open up the Solidity function signature generator and input slot0() in the first field and then copy the signature. Figure 4: Generating Solidity function signatures; Source: Chainstack EVM Swiss Army knife For the block number, you can either leave “latest” or you can provide any other block number as long as it is in the last 128 blocks. If you want to query the blockchain beyond the latest 128 blocks, then you need an archive node, the rest of the process being the same. The block number needs to be provided in Hex format. If you need to convert a Decimal to Hexadecimal format, you can use our EVM Swiss Army Knife again. Just input the block number in the Decimal field, and then copy the Hexadecimal value at the bottom. Figure 5: Converting decimal to hexdecimal; Source: Chainstack EVM Swiss Army knife Recap of what we did You deployed your own node and got access to your HTTPS endpoint. We are doing an eth_call to the contract. We added the WETH-USDC Uniswap V3 contract address in the code above. This is the smart contract that we will call. We are sending the method which is the function signature of the slot0 function. We added the block number in Hex format. Now you can send the call, and see the results. The result will be returned in Hexadecimal format. If you liked this tutorial, make sure to check out our blog for more. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to run a self-hosted blockchain node on HOSTKEY It’s 2am. Your on-call goes off. Users can’t transact, your dApp is returning errors, and your team is scrambling. You check your infra — everything looks fine. Then you check Alchemy’s status page. Degraded service. Estimated resolution: unknown. You’re down because someone else’s infrastructure is down. And there’s nothing you can do except wait. This is the hidden cost of managed RPC providers. They’re convenient until they’re not — and when they fail, they take your product down with them. Rate limits, shared infrastructure, opaque SLAs, and zero visibility into what’s actually happening under the hood. The alternative is running your own node. Full control, no dependencies, no surprises. And with Chainstack pre-installed on HOSTKEY servers, it’s not the week-long DevOps project it used to be. This guide walks you through the entire setup — from picking a server to having a live Ethereum node. What is Chainstack? Chainstack is a managed blockchain infrastructure platform built for developers and enterprises who need reliable, production-grade access to blockchain networks. From Global Nodes to Dedicated and Self-Hosted deployments, Chainstack provides the infrastructure layer for Web3 applications that can’t afford downtime. The Self-Hosted option is for teams who want full control — your hardware, your endpoints, your data. HOSTKEY is a certified Chainstack partner that ships servers with Chainstack pre-installed, so you skip the manual setup entirely. Before you start You’ll need: A HOSTKEY account (sign up at hostkey.com) A domain name (optional, but recommended for production) An SSH key pair (public key ready to paste)  SSH key pair — a way to access your server securely without a password. If you’ve never set one up, run this in your terminal: ssh-keygen -t ed25519 -C "your@email.com" Hit Enter through all the prompts. Then run: cat ~/.ssh/id_ed25519.pub That output is your public key — copy the whole thing, you’ll paste it into the server config in Step 5. Step-by-step guide Step 1: Choose Chainstack as your software Head to hostkey.com/apps/developer-tools/chainstack and click Deploy App. On the server configuration page, you’ll see the Software section at the top. Chainstack should already be selected — it’s the pre-configured option for this page. The OS is set to Ubuntu 22.04, which is the recommended environment for Chainstack. You only get one OS option here, and that’s intentional: the server is fine-tuned specifically for running blockchain nodes. Don’t change it. Chainstack pre-selected as software with Ubuntu 22.04 OS on the HOSTKEY deployment page. Source: HOSTKEY Step 2: Pick your data center location Scroll to the Location section. You’ll see a grid of countries with real-time ping measurements from your browser. Available locations include the Netherlands, Germany, United Kingdom, France, Italy, Spain, Finland, Iceland, Turkey, Poland, Switzerland, and the USA. Which one should you pick? Lowest latency to your users or dApps — pick the closest region Proximity to other validators or nodes — some chains have denser node clusters in specific regions (Western Europe is generally strong) Regulatory considerations — if you need data residency in a specific country, filter by that The ping numbers shown are live. Germany and Italy typically show the lowest latency in Western Europe. The Netherlands and the UK are solid all-rounders. Data center location selector showing real-time ping measurements by country. Source: HOSTKEY Step 3: Select your server HOSTKEY offers three server types: Virtual Servers (VPS/VDS) — virtualized hardware shared at the infrastructure level, but with dedicated resources allocated to you. Good starting point for full nodes and RPC endpoints. Lower cost, faster provisioning. Bare Metal Dedicated Servers — physical hardware, exclusively yours. No noisy neighbors, predictable performance. The right choice for archive nodes or anything running at production scale where consistent I/O matters. Servers with GPU — available in a limited set of locations. Relevant if your setup involves ZK-proof generation or other GPU-accelerated workloads alongside the node. Not needed for standard Chainstack deployments. Location availability varies by server type — not every country has bare metal or GPU options. If a specific location matters to you, check what’s available there before committing to a server category. Server type selection: VPS/VDS, Bare Metal, and GPU options available. Source: HOSTKEY Step 4: Configure networking Under the Network section, set your public IP and traffic limits. Public IP: The default is 1 IPv4 at no extra cost. That’s enough for a single node. Traffic options: 3 TB / 1 Gbps — $0/mo (included) 5 TB / 1 Gbps — $4.69/mo 10 TB / 1 Gbps — $17.59/mo Archive nodes and heavily-queried RPC endpoints can burn through bandwidth fast. If you’re serving external traffic or running a public RPC, go with at least 5–10 TB. Note: Ports 25, 587, 465/tcp and 5060/udp are closed by default on virtual servers. If you need them open for any reason, contact HOSTKEY support. Network configuration panel with public IP and traffic limit options. Source: HOSTKEY Step 5: Set up automation (SSH, scripts, domain) The Automation section is where you configure access and post-install behavior. SSH Key — Paste your public SSH key here. This gives you root access to the server immediately after it’s provisioned, without needing a password. Check the Before You Start section for more information.  Post Install Callback URL — Optional. If you’re building automated infrastructure, you can point this to a webhook that fires once the server is ready. Useful for triggering CI/CD pipelines or infrastructure orchestration. Cloud-init / Post Install Scripts — You can drop a shell script or cloud-config here that runs on first boot. For example, to auto-configure firewall rules or pull your Chainstack configuration from a private repo. Domain — If you want to reach the Chainstack panel via a domain (e.g., node.yourproject.com), enter it here. Make sure your DNS is pointed at the server’s IP before it provisions, or expect a short delay while delegation propagates. Automation section with SSH key, post-install callback URL, and domain fields. Source: HOSTKEY Step 6: Review and checkout The right-hand panel shows your total. Payment periods: 1 month — standard rate 3 months — 10% off 6 months — 20% off 12 months — 30% off For production infrastructure you plan to run long-term, the 3-month option is the practical choice. The example config shown — Netherlands VDS with Chainstack, 3 TB traffic, 1 IPv4 — comes to $189.67 for 3 months (down from $210.74). Long-term agreements include a discounted rate and cannot be cancelled early. Plan accordingly. Click Checkout, complete payment, and your server will be provisioned with Chainstack pre-installed. Order summary showing pricing tiers and discount options by payment period. Source: HOSTKEY After deployment Once your server is ready, you’ll receive an email with the server IP and connection details. You can also find everything in the HOSTKEY control panel under Info → Tags. 1. Open the Chainstack web panel The link to the Chainstack management interface is in the webpanel tag in your server’s Info section. Open it in your browser — you’ll see the Chainstack login screen. 2. Get your password SSH into your server: bash ssh root@<server_ip> Then run: bash yq '.cp-auth.env.CP_AUTH_BOOTSTRAP_PASSWORD' /root/.config/cp-suite/values/cp-control-panel-*.yaml Copy the output and paste it into the Password field on the login screen. Username is admin. You can also find the password in /root/chainstack_admin_credentials.txt 3. Change your password Once logged in, go to Settings and set a new password. Don’t skip this. 4. Deploy your first node Go to the Nodes menu and click Create node. Select your protocol and configuration, review the summary, and click Create Node. The node will be up in approximately 10 minutes — after that it will start syncing, which takes significantly longer depending on the network. For the full node deployment walkthrough, see the HOSTKEY Chainstack documentation. 5. Get your RPC endpoint Once the node is running, the RPC endpoint is available directly from the Chainstack panel. Point your dApp, indexer, or wallet backend at it — this is your private, rate-limit-free connection to Ethereum. Summary There’s no meaningful downside to owning your node once it’s running. The setup cost is 15 minutes. What you get in return is a private RPC endpoint that’s fully yours— no shared infrastructure, no rate limits, no one else’s outage becoming your problem. Your node will start syncing immediately. From here: connect your dApp, set up monitoring, and plan for scale. Chainstack handles the node management, HOSTKEY handles the hardware — your team handles everything that actually matters. Deploy your Chainstack node on HOSTKEY → FAQ How long does it take to set up a self-hosted blockchain node on HOSTKEY? The server provisioning and initial Chainstack setup takes about 15 minutes. After that, the node itself spins up in approximately 10 minutes — but syncing to the chain tip takes significantly longer depending on the network and node type. What’s the difference between a VPS and bare metal server for running a blockchain node? VPS is virtualized hardware with dedicated resources allocated to you — lower cost, faster provisioning, good for full nodes and RPC endpoints. Bare metal is physical hardware exclusively yours, with no noisy neighbors and predictable I/O — the right choice for archive nodes or production-scale deployments. Do I need DevOps experience to run a Chainstack self-hosted node on HOSTKEY? No. HOSTKEY ships servers with Chainstack pre-installed. You need basic SSH access to retrieve your admin password, but the node deployment itself is done through the Chainstack web panel — no manual client configuration required. How much bandwidth does a self-hosted blockchain node use? It depends on the chain and traffic load. HOSTKEY includes 3 TB/month free. Archive nodes and publicly-exposed RPC endpoints can exceed this quickly — for those use cases, the 5–10 TB plans are recommended. Additional resources How to deploy a self-hosted Ethereum node with Chainstack Self-hosted blockchain node: DIY vs Chainstack Self-Hosted #### How to run a self-hosted blockchain node on velia.net You don’t really know what your RPC provider’s infrastructure looks like. You know what their status page tells you, what their docs claim, and what you can infer from response times. Everything else — the noisy neighbors, the rate limit tuning, the shared bandwidth, the failover logic that may or may not work the day you actually need it — is invisible to you. That’s fine until it isn’t. When something breaks on shared infrastructure, you’re not at the front of the queue. You’re not in the queue at all. You wait, your users wait, and your post-mortem ends with “third-party outage” — a sentence that has never once made anyone happier. The fix is to stop renting access and start owning the node. With Chainstack Self-Hosted as a one-click install on velia.net bare metal, this is a checkout away. No DevOps marathon, no chasing Geth/Reth/Lighthouse compatibility matrices, no provisioning scripts you’ll regret in six months. This guide walks you through the whole thing — server pick to live node. What is Chainstack? Chainstack is a managed blockchain infrastructure platform for teams that need production-grade RPC access without becoming an infrastructure team. The product line spans Global Nodes, Dedicated Nodes, and Self-Hosted — three layers of how much of the stack Chainstack runs for you versus how much you run yourself. Self-Hosted is the deepest control option: your hardware, your endpoints, your data, your network policies. Chainstack handles the node software lifecycle — deployment, health checks, updates, self-healing — and stays out of everything else. velia.net is a Chainstack partner offering Chainstack Self-Hosted as a one-click software option on its web3 server line. Before you start You’ll need: A velia.net account (sign up) A payment method (card or bank transfer, EUR billing) An SSH key pair for server access (you’ll paste it during checkout) Optionally, a domain name if you want to reach the Chainstack panel via a hostname instead of an IP SSH key pair — how you log into the server without a password. If you don’t have one already, run this in your terminal: ssh-keygen -t ed25519 -C "your-email@example.com" Press Enter through the prompts. Then: cat ~/.ssh/id_ed25519.pub That’s your public key. Copy the full output — you’ll paste it during checkout. Step-by-step guide Step 1: Open the launch config Velia is running an 80% first-month discount with ChainstackSH80 on the Chainstack web3 launch configuration. Start here: Deploy Chainstack Self-Hosted on velia.net → That link opens the configurator for the E-2286G SSD in Strasbourg, France: 6-core Intel Xeon E-2286G at 4.00 GHz 32 GB DDR4 ECC RAM 1× 960 GB SSD IPMI/KVM included From €69/month standard. From €13.80 first month with ChainstackSH80. This is a solid box for evaluating Chainstack Self-Hosted on Sepolia or Hoodi testnets at base spec. For Ethereum mainnet, bump storage in the configurator (Step 2) — mainnet needs 2 TB+ of NVMe, the default 960 GB SSD won’t fit it. For anticipated scale or higher-tier hardware, contact us and we’ll scope a configuration with you. Step 2: Configure hardware Scroll down past the header into the Product configuration panel. The hardware decisions are the first three blocks: RAM — 32 GB by default. Bump to 64 GB (+€22/mo) if you’re running heavier execution clients or multiple nodes on one box. Storage — 1× 960 GB SSD by default. For more storage take 2× 1.92 TB SSD Data Center Edition (+€60/mo), available as No RAID or Software RAID 1. NVMe SSD (Data Center Edition) — No NVMe by default. Adding 1× 960 GB NVMe (+€20/mo) or 2× 960 GB NVMe (+€40/mo, RAID 1 optional) is worth it for I/O-heavy workloads — node sync and DB writes get noticeably faster on NVMe than on SATA SSD. The right column shows a live Configuration summary that updates as you toggle options. Step 3: Pick Chainstack Self-Hosted under Management Software This is the step that makes everything else work. Scroll down to Management Software and select Chainstack Self-Hosted. By default this block is set to “No management software” — if you skip it, you’ll get bare Velia hardware with no Chainstack layer on top, and you’ll be back to manual node installation. Pick Chainstack Self-Hosted explicitly. Underneath the option Velia notes: “Requires Ubuntu 24.04. If ‘NO OS’ is selected, we will install Ubuntu 24.04.” In other words, you don’t need to touch the Operating System block below — leaving it on “No installation (I’ll do the installation myself via KVM/IPMI)” lets Velia auto-install Ubuntu 24.04 under Chainstack. If you’d rather pick the OS yourself, choose Ubuntu 24.04 explicitly from the OS list. Step 4: Confirm network and optional add-ons The remaining blocks govern network and optional services. For most first deployments the defaults are fine: Power Supply — UPS-protected terminal. Fixed, no choice. Bandwidth — 1 GBit port with 100 TB monthly included; extra traffic billed at €1 per TB. Switch to 1 Gbit unmetered (Flatrate) (+€100/mo) if you’re running a public RPC endpoint with heavy egress. IPv4 Network — single IP address by default. Take Subnet /29 (5 usable IPs, +€11/mo) if you’re planning multiple services behind the same box. IPv6 Network — IPv6 enabled. Fixed, no choice. Internal Network — 1 GBit/s private port (+€11/mo). Useful if you’re going to add more Velia servers later and want them on a private segment. Backup — Acronis Cyber Backup Cloud at 100 GB / 200 GB / 500 GB / 1 TB tiers (+€6 / +€11 / +€28 / +€50/mo). Worth it for production data; skip for pure evaluation. Step 5: Add to cart, apply the promo, and check out In the Configuration summary panel on the right, pick your term (1 month is the default; longer terms may be in the dropdown) and click Add to cart. On the cart and checkout screens you’ll go through: Account login or signup Contact and billing details (EUR billing, commercial customers only — no VAT shown in displayed prices) An SSH key pair for server access (recommended) — Velia also supports password-based access if you’d rather skip the key Promo code — enter ChainstackSH80 to apply 80% off the first month. The discounted first month starts from €13.80 (down from €69), depending on the add-ons you selected in Steps 2–4. Standard pricing resumes from month two. Payment Submit the order. Provisioning is fast because you’re getting actual bare metal that’s already racked and pre-imaged — typically minutes, not hours. Once it’s ready, Velia will email you the server IP and access details. After deployment Your server is live. Two things to do next: log into the Chainstack panel and deploy your first node. 1. Find the Chainstack panel URL SSH into the server and check the installer output for the Control Panel URL. The exact URL depends on how the services are exposed on your install — see the first-login guide for the exposure options (LoadBalancer, NodePort, Ingress, or port-forward). Open the URL in your browser. You’ll land on the Chainstack login screen. 2. Retrieve the bootstrap password SSH into the server: bash ssh root@<server_ip> Then retrieve the auto-generated admin password: bash yq '.cp-auth.env.CP_AUTH_BOOTSTRAP_PASSWORD' /root/.config/cp-suite/values/cp-control-panel-*.yaml Username is admin. Paste the password into the login form. 3. Change the admin credentials immediately Click Settings in the left sidebar. Under Personal Information, change both the username (away from default admin) and the password. Once you save, the bootstrap password from the values file is no longer valid — store the new credentials somewhere you’ll find them later. 4. Deploy your first node Open the Nodes menu and click Add node to start the deployment wizard. You’ll pick: Protocol — Ethereum (additional protocols on the roadmap). Network — Ethereum Mainnet, Sepolia testnet, or Hoodi testnet. Node type — full node (validator support is on the roadmap for late 2026). Deployment preset — pre-configured with the Reth execution client and Prysm consensus client, tuned for stability and performance. Complete the wizard and Chainstack provisions the node on your server. Spin-up takes around 10 minutes; sync time depends on the chain — Hoodi syncs in minutes to hours, Sepolia in hours, Ethereum Mainnet full in a few hours with a snapshot or days without.without. 5. Get your RPC endpoint Once the node is live, open its details page in the panel. You’ll find the connection details: Execution client HTTP — JSON-RPC over HTTP (port 8545) Execution client WSS — JSON-RPC over WebSocket (port 8546) Consensus client HTTP — Beacon API (port 5052) These endpoints are internal Kubernetes service addresses by default. To use them from outside the server, expose the services via LoadBalancer, NodePort, or Ingress — see managing nodes in the docs. Point your dApp at the exposed endpoint — a private connection with no rate limits, no shared infrastructure layer between you and the chain. Summary The pitch is short. The work is short. You get bare metal in a tier-1 European data center, a node deployment workflow that runs through a web panel instead of through hand-rolled Ansible, and a first month from €13.80 that lets you evaluate the whole stack for less than a casual lunch. In return, you stop sharing infrastructure with strangers, stop hitting rate limits during launches, and stop reading other people’s status pages. Deploy Chainstack Self-Hosted on velia.net → FAQ How long does it take to get a node running on velia.net? Server provisioning is typically minutes since the hardware is pre-racked. Node deployment through the Chainstack panel takes about 10 minutes. Initial chain sync is the long part — that depends entirely on the protocol and node type, from a few hours for an Ethereum full node up to several days for archive. What can I run on the E-2286G SSD launch config? With the default 32 GB RAM and 960 GB SSD: Sepolia and Hoodi testnet full nodes, evaluation deployments, and dev/staging setups on Chainstack Self-Hosted’s currently supported scope (Ethereum Mainnet, Sepolia, Hoodi). For Ethereum Mainnet, scale storage up in the configurator — 2× 1.92 TB SSD covers the 2 TB minimum. The base 960 GB SSD isn’t enough for mainnet state. As more protocols come to Chainstack Self-Hosted, contact us for hardware sizing. Do I need DevOps experience to use Chainstack Self-Hosted on velia.net? No. The Velia configurator installs Chainstack Self-Hosted on Ubuntu 24.04 automatically when you pick that option under Management Software. Chainstack then handles node deployment through its web panel. Basic Linux familiarity is enough — you SSH in once to retrieve the bootstrap password, and after that you live in the browser. Where is the launch config located? Strasbourg, France. EU jurisdiction, GDPR-relevant, with strong peering across European validator clusters. What does the ChainstackSH80 code do? It gives you 80% off the first month on the E-2286G SSD launch configuration accessed via this checkout link — from €13.80 for month one, down from €69 standard, depending on the add-ons you pick in the configurator. Standard pricing resumes from month two. Additional resources How to deploy a self-hosted Ethereum node with Chainstack Self-hosted blockchain node: DIY vs Chainstack Self-Hosted How to run a self-hosted blockchain node on HOSTKEY Introducing Chainstack’s partnership with Velia.net #### How to run Hummingbot on Chainstack: multi-chain DEX trading without RPC bottlenecks TL;DR Your market-making strategy can be perfect, but if your RPC endpoint stalls for 800ms during a swap, the price you priced against is already gone. Hummingbot v2.15.0 added Chainstack as a native RPC provider in Gateway, so the same bot can place orders on Solana DEXs and EVM DEXs through a single Platform API key — no juggling Helius for Solana and Infura for Ethereum and hoping both stay healthy. This guide walks through installing Hummingbot, wiring up a Chainstack key for Solana and the EVM lineup Gateway supports, and running your first swap. Why RPC is the silent variable in DEX trading Most Hummingbot guides focus on the strategy layer — spreads, inventory skew, candle indicators, executor configs. That’s the part you control. The part you don’t control is the RPC endpoint sitting between your strategy and the chain, and on a DEX it absorbs more failure modes than any other component. When Hummingbot decides to place a limit order on a CEX, the trade is a single HTTP request to the exchange’s API. When it decides to swap on Uniswap or Raydium, the same intent fans out into a dozen RPC calls: pool state reads, quote simulation, balance checks, transaction construction, simulation, broadcast, and confirmation polling. Every one of those calls is a chance for the endpoint to time out, return stale data, or rate-limit you mid-sequence. The failure modes get worse the closer you get to production: A public Solana endpoint enforces 100 requests per 10 seconds per IP, and 40 per single RPC method in the same window. A single Jupiter route lookup can burn that budget before the bot decides whether to trade. Public EVM endpoints frequently disable eth_getLogs over wide ranges, which breaks any strategy that reconstructs historical fills. Shared “free tier” private endpoints from any provider compete for capacity with hundreds of other tenants — your latency spikes correlate with their traffic, not yours. The bot doesn’t know any of this. It sees a hung promise or a 429, retries, and by the time it succeeds, the spread it was working against has moved. You pay for that gap in slippage, missed fills, or wrong-side inventory. What v2.15.0 actually changed Hummingbot Gateway is the middleware that sits between the main Hummingbot client and the on-chain world — it standardizes DEX endpoints across Solana and the EVM family into one API. Until late 2025, Gateway shipped with a hardcoded notion of an RPC endpoint: one nodeURL per network, defined in conf/chains/<chain>.yml. In v2.9.0 the team refactored that into a provider abstraction. Instead of just a URL, each chain config could point at a named provider, with the credential stored centrally. The first two providers wired into the new system were Helius (Solana) and Infura (EVM). That worked, but it left a structural awkwardness: anyone running a multi-chain bot had to maintain credentials with two different vendors, each with its own dashboard, its own billing, and its own definition of what “uptime” meant. v2.15.0 closed that gap by adding Chainstack as a native provider that covers both sides — Solana and the EVM lineup — through a single account and a single Platform API key. Quoting the Hummingbot Foundation’s June 2026 release announcement: Gateway adds Chainstack as a cross-chain RPC provider for Solana and EVM networks for lower latency and more reliable swap execution. There’s a subtle but important architectural difference in how Chainstack integrates. Helius and Infura are URL-templated providers: Gateway has a hardcoded URL pattern for each, and your API key gets substituted into it at runtime. Chainstack works differently — Gateway calls the Chainstack Platform API at startup and routes traffic to a node you’ve already deployed in your Chainstack project. The Hummingbot docs describe it as API-driven node discovery, and the practical effect is that as Gateway adds support for new chains, your existing Chainstack credential automatically covers them as long as you have a node deployed. What “multi-chain” actually means here This is worth being precise about, because every RPC provider claims it. And the precise version is more interesting than the marketing version. Helius is a Solana specialist — excellent at Solana, with optimized transaction sending, WebSocket monitoring, and Jito tip support, but it doesn’t serve any EVM network. If your Hummingbot setup trades Raydium and Uniswap, Helius covers half of it. Infura, conversely, is an EVM specialist. Through Gateway it currently supports Ethereum mainnet, Arbitrum, Avalanche, Base, BNB Chain, Celo, Polygon, and Sepolia — but no Solana. So the other half of the same bot needs a different vendor. Chainstack through Gateway covers the same EVM lineup plus Solana, all behind one credential. Per the official Hummingbot RPC providers doc, the currently-routable networks are: EVM: ethereum mainnet, arbitrum, polygon, optimism, base, avalanche, bsc, celo, sepolia Solana: mainnet-beta, devnet That’s the version of “multi-chain” that matters for a Hummingbot operator today: one provider, one credential, every chain Gateway can talk to. Beyond Gateway, Chainstack runs nodes on 70+ networks — the broader Hyperliquid, Berachain, Unichain, Linea, Katana ecosystem — and as Hummingbot Gateway adds support for those chains, the same credential covers them without re-onboarding. Prerequisites Before installing anything, get the accounts in order. A machine with at least 4 GB RAM and Docker installed. Hummingbot officially supports Linux, macOS, and Windows via Docker. Source builds work too but Docker is the path of least resistance. A Chainstack account — the free Developer plan is enough to walk through this tutorial, and gives you 3M request units per month with 25 RPS, which covers a single low-frequency bot. For production scale you’ll want the Growth or Pro tier, which unlock Trader Nodes for Solana and higher RPS ceilings across EVM chains. A wallet with a tiny amount of native gas on whichever chain you plan to trade first — SOL for Solana, ETH for Ethereum, MATIC for Polygon, and so on. Use a fresh wallet for this; never point Hummingbot at a private key holding meaningful funds while you’re still learning the configs. Setting up Chainstack in Gateway Step 1 — Install Hummingbot and Gateway Hummingbot ships as two coordinated services: the Python-based client (which runs your strategy and CLI) and the TypeScript-based Gateway (which talks to chains and DEXs). For DEX trading you need both. The cleanest install is via the official Docker deployment scripts. Clone the repo and run the bootstrap: git clone https://github.com/hummingbot/deploy-examples.git cd deploy-examples/hummingbot_files ./create.sh The script asks for an instance name, a config password, and which version to pull. Pick latest or version-2.15.0 explicitly. Once it finishes, the Hummingbot client is running in a Docker container and you can attach to it with: docker attach hummingbot Gateway is a separate container that the client expects on a known port (15888 by default). The same deploy-examples repo has a gateway_files directory with its own create.sh. Run it the same way and accept the defaults. When both containers are up, the Hummingbot client header should show GATEWAY: 🟢 ONLINE in the upper right. Run gateway ping to confirm — you should see your chains responding through their default public RPC endpoints. That’s the baseline state we’ll improve. Step 2 — Deploy a Chainstack node Chainstack’s Gateway integration uses API-driven discovery, which means Gateway will look up your project’s deployed nodes at startup rather than reading hardcoded URLs from your config. So before you touch any YAML, deploy at least one node for each chain you plan to trade. Log into the Chainstack console and create a project. Inside the project, click Add node and pick the networks you want Hummingbot to use. For a multi-chain bot a reasonable starting set is: Solana mainnet Global Node — geo-load-balanced across regions. Ethereum mainnet Global Node — for any Uniswap V3 or V4 strategy. Base mainnet Global Node — a lot of current Hummingbot DEX volume lives on Base. Each node provisions in seconds. You don’t need to copy the per-node URLs anywhere — Gateway will discover them automatically once you give it the Platform API key in the next step. (You can still grab the URLs for debugging or for non-Gateway scripts; they live under the node’s Access & credentials tab.) Step 3 — Create a Chainstack Platform API key This is the credential Gateway actually needs. It’s different from the per-node authorization keys you see in the access tab — it’s a platform-level token that lets Gateway enumerate your project’s nodes. Open console.chainstack.com/user/settings/api-keys, click Create key, give it a descriptive name (e.g. “Hummingbot Gateway”), and copy the generated key. Store it somewhere — you’ll need it once, in the next step. ⚠️ Treat the Platform API key like a deployment credential, not a per-application API key. It can list and read all nodes in your account. Don’t paste it into a public repo or share it across machines you don’t control. Step 4 — Wire Chainstack into Gateway Gateway as of v2.11+ centralizes all third-party API keys in one file: conf/apiKeys.yml. This is a change worth flagging — earlier docs (and earlier blog posts) referred to per-provider files like conf/rpc/helius.yml and conf/rpc/infura.yml, but the current pattern is one flat keys file plus a rpcProvider switch in each chain config. The wire-up is three steps, all run from inside the Hummingbot client. 1. Add the Chainstack key to apiKeys.yml: gateway config apiKeys update When prompted, set the chainstack value to the Platform API key you just generated. Equivalently, edit conf/apiKeys.yml directly: chainstack: 'YOUR_CHAINSTACK_PLATFORM_API_KEY' 2. Switch each chain’s provider to Chainstack: gateway config ethereum update # When prompted for rpcProvider, change from `url` to `chainstack` gateway config solana update # Same — change rpcProvider from `url` to `chainstack` The url value here is Gateway’s term for “use the literal nodeURL from the chain config” — i.e., the default public endpoint. Switching to chainstack tells Gateway to ignore that URL and route through the discovery flow instead. You can also edit the YAMLs directly. The result should look like this: # conf/chains/solana.yml defaultNetwork: mainnet-beta rpcProvider: chainstack # conf/chains/ethereum.yml defaultNetwork: mainnet rpcProvider: chainstack Note what’s not in those files — no endpoint URLs, no per-network entries, no per-node auth tokens. That’s the discovery flow in practice: the only Chainstack-specific thing Gateway needs to know is “use Chainstack,” and the Platform API key in apiKeys.yml does the rest. 3. Restart Gateway and verify. Gateway re-reads its config on restart and resolves your nodes through the Platform API. Watch the startup logs — you should see Chainstack discovery announcing the nodes it found: Chainstack API key configured Chainstack service initialized: node ND-123-456-789 (solana/solana-mainnet) for solana/mainnet-beta Solana (defaultNetwork: mainnet-beta): Block #427,223,441 Chainstack service initialized: node ND-987-654-321 (ethereum/ethereum-mainnet) for ethereum/mainnet Ethereum (defaultNetwork: mainnet): Block #25,342,330 The ND-... identifiers are your Chainstack node IDs — same ones visible in the console. If you see them in the log, discovery worked. Confirm a chain is live with a status call directly to Gateway’s REST API: curl "http://localhost:15888/chains/solana/status?network=mainnet-beta" From inside the Hummingbot client, gateway ping shows the same thing in a friendlier format: solana (mainnet-beta): - RPC URL: https://<your-chainstack-solana-node> - Current Block: 427223441 - Native Currency: SOL - Status: ✓ Connected If you don’t see Chainstack discovery in the logs, the usual suspects are: the API key wasn’t saved (re-run gateway config apiKeys update), the chain config still has rpcProvider: url instead of chainstack (check the YAML directly), or no node is deployed in your Chainstack project for the requested network (the discovery flow needs a running node to route to). For the canonical step-by-step with the exact log output and curl verification commands, Chainstack publishes a dedicated walkthrough: Using Chainstack as a Hummingbot Gateway RPC provider. If anything in this section drifts out of date as Gateway evolves, that’s the source of truth. Step 5 — Verify with a read-only swap quote Before connecting a wallet — which means handing Hummingbot a private key — verify that quotes actually route through your Chainstack node. A quote is a read-only call: it asks the DEX what you’d get if you swapped, simulates the route against current chain state, and returns a price. No signature, no gas, no risk. Hit Gateway’s REST API directly with curl. For Solana via Jupiter: curl "http://localhost:15888/connectors/jupiter/router/quote-swap?network=mainnet-beta&baseToken=SOL&quoteToken=USDC&amount=1&side=SELL" For Ethereum mainnet via Uniswap (this one needs a wallet address for routing logic, but no signing): curl "http://localhost:15888/connectors/uniswap/router/quote-swap?network=mainnet&baseToken=WETH&quoteToken=USDC&amount=1&side=SELL&walletAddress=YOUR_WALLET_ADDRESS" A successful response returns the output amount, the route, and the price impact. If you get one back, the full path works: Hummingbot client → Gateway → Chainstack-discovered node → Solana or Ethereum → DEX program/contract → and back. That’s the integration verified end-to-end without committing any capital. Step 6 — Connect a wallet and run a real swap Now you can connect a wallet and execute an actual trade. gateway connect solana gateway connect ethereum Hummingbot will prompt for the wallet’s private key and store it encrypted with your config password. (Use a fresh, low-balance wallet, as noted in the prerequisites.) Check balances to confirm the wallet sees its funds through the new endpoint: gateway balance Now run a real swap. Gateway’s swap command takes the form gateway swap <connector>/<type> [base-quote] [side] [amount]: gateway swap jupiter/router SOL-USDC BUY 0.01 Or on Ethereum: gateway swap uniswap ETH-USDC BUY 0.01 Gateway fetches the route from the DEX, simulates the transaction against your Chainstack-backed endpoint, and executes it. The same command shape works for raydium, orca, meteora, pancakeswap, and the rest of the connector lineup — Gateway abstracts the DEX, Chainstack abstracts the chain. This is where the multi-chain story stops being theoretical. The exact same Hummingbot instance, with the same Platform API key, can route a swap on Solana and a swap on Base in the same trading session. There’s no provider switch, no second dashboard to check when something stalls. Step 7 — Wire it into a strategy A one-off gateway swap is just a connectivity test. The actual point of Hummingbot is the strategy framework — V2 strategies (PMM, XEMM, arbitrage, executors) that decide when to swap. Once Gateway is talking to Chainstack, every V2 strategy that uses a DEX connector inherits the new endpoint automatically. There’s no per-strategy config change. A typical multi-chain market-making setup might run: A Uniswap V3 PMM controller on Base, quoting around a WETH-USDC pool. An Orca Whirlpool LP executor on Solana, providing concentrated liquidity around a SOL-USDC tick range. An arbitrage controller watching the price gap between the two and shifting inventory when it widens. All three components talk to their chain through the same Chainstack-backed Gateway. The arbitrage executor benefits most: its edge depends on detecting the price gap before anyone else does, and the latency floor on a geo-routed Global Node — with sub-100ms reads in major regions — is what makes that detection viable. If the strategy graduates into something genuinely latency-sensitive (sandwich-aware market-making, cross-DEX arbitrage with tight thresholds, MEV-adjacent flows), the natural next step is to upgrade the Solana node to a Trader Node and the EVM nodes to Dedicated Nodes. The Hummingbot config doesn’t change — the discovery flow just picks up the upgraded node next time Gateway restarts. When to upgrade from the Developer plan The free tier is a real plan, not a teaser — 3M request units per month, 25 RPS, 99.9% uptime, full access to every chain in the catalog. It’s enough for one bot running a moderate-frequency strategy on one or two chains. You’ll know it’s time to upgrade when you start seeing these patterns: SPL token operations failing on Solana. This one’s not subtle — the Developer plan restricts getProgramAccounts and getTokenAccountsByOwner, which Gateway connectors use to read SPL token balances. If your bot trades anything other than native SOL on Solana, token-balance checks and parts of the swap flow will fail with a method-not-available error until you move to a paid plan. The fix is a paid Trader Node, which serves both methods without restriction. 429s under burst load. Your bot is fine for hours, then a sudden market move spikes its request rate (re-quoting, re-simulating, cancelling old orders) past 25 RPS. Hummingbot retries gracefully, but every retry adds latency that costs you fills. The Growth plan moves the ceiling to 250 RPS, which absorbs most spikes. The official Hummingbot RPC docs explicitly recommend “upgrading to a paid tier” as one of the two fixes for rate-limit errors — the other being increasing your bot’s tick_size. Slot lag on Solana reads. If getSlot from your endpoint is consistently 1–2 slots behind what you see on an explorer, you’re reading stale state and pricing against a world that’s already moved. A Trader Node deployed in your bot’s region typically eliminates that gap, with Warp Transactions and Jito ShredStream available for the send path. Multiple bots, one endpoint. Each Hummingbot instance shares the rate limit. Two bots on the Developer plan compete for the same 25 RPS budget. The Unlimited Node add-on gives you a fixed RPS tier per node with no per-method billing — predictable cost regardless of how many bots are pointed at it. The economic logic is straightforward: if your bot’s expected daily P&L is larger than a Growth subscription, the upgrade pays for itself in slippage avoidance alone. Operational hygiene A few things that aren’t strictly “setup” but separate the bots that survive their first month from the ones that don’t: Keep one node per network in the project tied to your Hummingbot key. Gateway picks the first running node it finds that matches the chain and network. If you have a Solana mainnet Trader Node and a Solana mainnet archive node in the same project, which one Gateway picks isn’t deterministic. Either use separate projects (and separate Platform API keys) for separate workloads, or keep the project Hummingbot reads from to one node per network. Run Gateway and the client on the same machine, in the same Docker network. Cross-machine setups introduce variable latency between the two services that compounds with chain latency. Localhost is free; use it. Monitor your Chainstack endpoints, not just your bot. The Chainstack console shows per-method RPS, error rates, and p95 latency. If your bot’s fill rate degrades, check the endpoint metrics first — it’s usually a symptom, not a cause. Use distinct API keys per environment. Don’t point your live bot and your backtest at the same Platform API key. Backtests can hammer historical RPC methods (eth_getLogs, getSignaturesForAddress) hard enough to push you near rate limits and starve the live bot of capacity. Generate a separate key in the Chainstack console and route accordingly. Set timeouts that match the chain. Solana’s confirmRetryInterval defaults to 0.5s and confirmRetryCount to 10 — that’s 5s of polling before Hummingbot gives up on a transaction. On a Trader Node you can tighten both. On a busy public chain like Ethereum during a congestion event, you may want to loosen them. Why this matters beyond a release note Adding a third RPC provider to a Hummingbot release notes page is, on the surface, an incremental update. What it actually changes is the architectural assumption that a DEX bot needs a different vendor for every chain class it touches. That assumption was a real tax on Hummingbot operators. It meant two billing relationships, two dashboards, two sets of rate-limit math, two regional latency profiles to reason about, and two support channels to escalate to when something stalled at the wrong moment. For a hobbyist running one strategy on one chain it didn’t matter. For anyone running serious multi-chain inventory, it was friction that compounded with every chain added. Collapsing that into one provider — one with SOC 2 Type II and ISO 27001 compliance, 99.99% uptime SLAs on paid tiers, and a single console showing latency across Solana, Ethereum, Base, Polygon, Arbitrum, BNB Chain, and the long tail of L2s — turns “multi-chain trading” from an operations problem back into a strategy problem. Which is what Hummingbot was supposed to be in the first place. The full v2.15.0 release also shipped CLMM fixes for Orca and Meteora, a new Lighter perps connector, Hyperliquid stability improvements, and Tailscale support for private bot control. But the part worth migrating for, if you’re running any DEX strategy past prototype scale, is the one that makes “what RPC am I using?” a question you stop having to ask. Sign up for a free Chainstack account → FAQ What changed in Hummingbot v2.15.0 for RPC providers? v2.15.0 added Chainstack as a built-in RPC provider in Gateway, alongside the existing Helius (Solana) and Infura (EVM) integrations from v2.9.0. Chainstack is the only Gateway provider that covers both Solana and the full EVM lineup behind a single credential. How is Chainstack different from Helius and Infura in Hummingbot Gateway? Helius is Solana-only and Infura is EVM-only — both use URL-templated configs where you paste a per-network endpoint. Chainstack uses API-driven node discovery: you provide one Platform API key and Gateway calls the Chainstack Platform API at startup to find your deployed nodes for each chain. One credential, both chain classes, no URLs to rotate. Do I need separate API keys for Solana and EVM if I use Chainstack? No. One Chainstack Platform API key covers your entire account. As long as you’ve deployed nodes for the chains you want to trade, Gateway’s discovery flow routes each one automatically. That’s the multi-chain win versus running Helius and Infura side by side — one billing relationship, one dashboard. What’s the difference between a Platform API key and a node endpoint authorization key? A node endpoint authorization key is embedded in your RPC URL and authenticates HTTP calls to one specific node. A Platform API key is an account-level credential that lets Gateway enumerate all nodes in your project via the Chainstack Platform API. Gateway needs the Platform key — you create it under Settings → API keys in the Chainstack console. Why does my Hummingbot Solana swap fail with a “method not available” error on the free plan? Because the Chainstack Developer plan restricts getProgramAccounts and getTokenAccountsByOwner — the two Solana RPC methods Gateway connectors use to read SPL token balances. Any swap involving an SPL token (anything other than native SOL) will fail until you upgrade. The fix is a paid Trader Node, which serves both methods. The official Chainstack tutorial flags this explicitly in its troubleshooting section. When should I upgrade from the free Developer plan? Three signals: (1) any Solana SPL token swap fails with a method-restriction error — not optional for production Solana trading; (2) bursts past 25 RPS during market events trigger 429s; (3) getSlot consistently lags 1–2 slots behind explorers. The Growth plan raises throughput to 250 RPS; a Trader Node eliminates slot lag and method restrictions both. Additional reading Using Chainstack as a Hummingbot Gateway RPC provider Solana trading infrastructure 2026: MEV, nodes, latency How to build a Solana trading bot Top 7 trading bots on Hyperliquid in 2026 Hummingbot Gateway RPC Providers documentation #### How to run your own Solana node: manual RPC setup guide (2026) The manual setup instructions in this article are not maintained for accuracy. Your best option to get a running node in seconds is to deploy a Solana node with Chainstack – the best Solana RPC node provider. With Chainstack, you skip manual package installs, catch-up sync time, and surprise maintenance work. Instead, you focus on building dApps while Chainstack delivers high-performance, production-grade Solana RPC endpoints backed by global infrastructure and 24/7 support. Introduction The easiest way to run a Solana RPC node is with Chainstack: Sign up with Chainstack. Deploy a managed Solana RPC node. Get the deployed node’s endpoint. That said, this post provides step-by-step instructions on running a non-validating Solana RPC node and connecting it to the mainnet cluster, which could be helpful if you are benchmarking Chainstack against a self-hosted setup or researching best practices for Solana RPC providers. This tutorial uses the Agave node client by Anza. See Agave documentation. RPC node hardware requirements ComponentRequirementCPU– 2.8GHz base clock speed or faster– 16 cores / 32 threads minimum– SHA extensions instruction support– AMD Gen 3 or newer– Intel Ice Lake or newer– AVX2 instruction support– AVX512f support is helpful– Higher clock speed preferred over more coresRAM– 512 GB or more for all account indexes– Error Correction Code (ECC) memory recommended– Motherboard with 512GB capacity suggestedDisk– PCIe Gen3 x4 NVME SSD or better for each storage component:  • Accounts: 1TB+ with high TBW (Total Bytes Written)  • Ledger: 1TB+ with high TBW (consider larger for longer transaction history)  • Snapshots: 500GB+ with high TBW  • OS: 500GB+ (SATA acceptable)– Important: Accounts and ledger should NOT be stored on the same disk– Samsung 970/980 Pro series SSDs recommended See also the community maintained Solana hardware compatibility list. Manual Solana node setup: step-by-step 1. Prepare and mount disks Remember to make sure each of the two mounted disks is 1TB+ in size. We will store our data in /var/solana on two different mounted disks: disk #1 for ledger and config — /var/solana/data disk #2 for accounts — /var/solana/accounts Partition the NVMe disks: root@solana-node-01:~# sgdisk -Z --new=1:2048:0 --typecode=1:8300 /dev/nvme1n1root@solana-node-01:~# sgdisk -Z --new=1:2048:0 --typecode=1:8300 /dev/nvme2n1 Refresh the partition table: root@solana-node-01:~# partprobe /dev/nvme1n1root@solana-node-01:~# partprobe /dev/nvme2n1 Format the new partitions with XFS: root@solana-node-01:~# mkfs.xfs /dev/nvme1n1p1root@solana-node-01:~# mkfs.xfs /dev/nvme2n1p1 Label the filesystems: root@solana-node-01:~# xfs_admin -L disk1 /dev/nvme1n1p1root@solana-node-01:~# xfs_admin -L disk2 /dev/nvme2n1p1 Update /etc/fstab with labels: root@solana-node-01:~# sudo bash -c 'cat >> /etc/fstab <<EOF LABEL=disk1 /var/solana/data xfs defaults 0 0 LABEL=disk2 /var/solana/accounts xfs defaults 0 0 EOF' Mount the filesystems: root@solana-node-01:~# mount /var/solana/dataroot@solana-node-01:~# mount /var/solana/accountsroot@solana-node-01:~# mkdir -p /var/solana/{data/{ledger,config},accounts/snapshots} 2. sysctl additional values Increase the memory mapped files limit, increase the UDP buffer size, and optimize the kernel parameters: root@solana-node-01:~# bash -c "cat >/etc/sysctl.d/20-solana-additionals.conf <<EOF fs.nr_open=1048576 kernel.hung_task_timeout_secs=600 kernel.nmi_watchdog=0 kernel.pid_max=131072 kernel.sched_min_granularity_ns=10000000 kernel.sched_wakeup_granularity_ns=15000000 kernel.timer_migration=0 net.core.rmem_default=134217728 net.core.rmem_max=134217728 net.core.wmem_default=134217728 net.core.wmem_max=134217728 net.ipv4.tcp_fastopen=3 vm.dirty_background_ratio=10 vm.dirty_expire_centisecs=36000 vm.dirty_ratio=40 vm.dirty_writeback_centisecs=3000 vm.dirtytime_expire_seconds=43200 vm.max_map_count=2000000 vm.stat_interval=10 EOF" root@solana-node-01:~# sysctl -p /etc/sysctl.d/20-solana-additionals.conf 3. Create a user for Solana root@solana-node-01:~# adduser solana root@solana-node-01:~# chown solana:solana /var/solana/data/ root@solana-node-01:~# chown solana:solana /var/solana/accounts/ 4. Install Solana CLI The Solana CLI tool will install the Agave node client through a script at the next step. Install the CLI tool by following the Agave docs: Install Solana CLI. 5. Create a run script solana@solana-node-01:~$ mkdir /home/solana/bin && cd /home/solana/bin solana@solana-node-01:~$ bash -c "cat > validator.sh <<EOF #!/bin/bash set -o errexit set -o nounset set -o pipefail [ -f /var/solana/data/config/validator-keypair.json ] && echo "Identity exists" || (/opt/solana/solana-release/bin/solana-keygen new -o /var/solana/data/config/validator-keypair.json --no-passphrase --silent && echo "Identity created" ) /opt/solana/solana-release/bin/agave-validator \ --ledger "/pv-disks/disk1/ledger" \ --identity "/pv-disks/disk1/config/validator-keypair.json" \ --known-validator 6WgdYhhGE53WrZ7ywJA15hBVkw7CRbQ8yDBBTwmBtAHN \ --known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \ --known-validator C1ocKDYMCm2ooWptMMnpd5VEB2Nx4UMJgRuYofysyzcA \ --known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \ --known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ \ --known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \ --known-validator GwHH8ciFhR8vejWCqmg8FWZUCNtubPY2esALvy5tBvji \ --entrypoint entrypoint.mainnet-beta.solana.com:8001 \ --entrypoint entrypoint2.mainnet-beta.solana.com:8001 \ --entrypoint entrypoint3.mainnet-beta.solana.com:8001 \ --entrypoint entrypoint4.mainnet-beta.solana.com:8001 \ --entrypoint entrypoint5.mainnet-beta.solana.com:8001 \ --expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \ --snapshots /pv-disks/disk2/snapshots \ --no-voting \ --private-rpc \ --rpc-bind-address 127.0.0.1 \ --rpc-port 8799 \ --gossip-port 8801 \ --dynamic-port-range "8000-8020" \ --full-rpc-api \ --wal-recovery-mode skip_any_corrupted_record \ --enable-rpc-transaction-history \ --enable-cpi-and-log-storage \ --init-complete-file "/pv-disks/disk1/init-completed" \ --limit-ledger-size 100000000 \ --account-index program-id \ --account-index spl-token-owner \ --account-index spl-token-mint \ --account-index-exclude-key kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6 \ --account-index-exclude-key TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA \ --accounts-index-path "/pv-disks/disk2/accounts_index" \ --accounts-index-memory-limit-mb 204800 \ --accounts "/pv-disks/disk2/accounts" \ --expected-shred-version 50093 \ --rpc-pubsub-enable-block-subscription \ --block-verification-method unified-scheduler \ --minimal-snapshot-download-speed 50000000 \ --maximum-snapshot-download-abort 10000 \ --log - EOF" solana@solana-node-01:~$ chmod +x validator.sh 6. Create a service for Solana root@solana-node-01:~# bash -c "cat > /etc/systemd/system/sol.service <<EOF [Unit] Description=Solana Validator After=network.target StartLimitIntervalSec=0 [Service] Type=simple Restart=always RestartSec=1 User=solana LimitNOFILE=1000000 LogRateLimitIntervalSec=0 Environment="PATH=/bin:/usr/bin:/home/solana/.local/share/solana/install/active_release/bin" ExecStart=/home/solana/bin/validator.sh [Install] WantedBy=multi-user.target EOF" 7. Install Prometheus Node Exporter Install the Prometheus Node Exporter to export node metrics that you can later feed into your monitoring tools. Note that you may want to change the version to the latest one here download/v1.3.1/ root@solana-node-01:~# wget https://github.com/prometheus/node_exporter/releases/download/v1.9.1/node_exporter-1.9.1.linux-amd64.tar.gz root@solana-node-01:~# tar xvfz node_exporter-1.9.1.linux-amd64.tar.gz root@solana-node-01:~# mv node_exporter-1.9.1.linux-amd64/node_exporter /usr/local/bin/ root@solana-node-01:~# useradd -rs /bin/false node_exporter root@solana-node-01:~# tee /etc/systemd/system/node_exporter.service<<EOF [Unit] Description=Node Exporter After=network.target [Service] User=node_exporter Group=node_exporter Type=simple ExecStart=/usr/local/bin/node_exporter [Install] WantedBy=multi-user.target EOF …if you need to change port: root@solana-node-01:~# tee /etc/prometheus.conf<<EOF ARGS=--web.listen-address=localhost:9101 EOF Change /etc/systemd/system/node_exporter.service to the ExecStart string to look like this:ExecStart=/usr/local/bin/node_exporter $ARGS …continue: root@solana-node-01:~# systemctl daemon-reload root@solana-node-01:~# systemctl start node_exporter root@solana-node-01:~# systemctl enable node_exporter root@solana-node-01:~# systemctl enable --now sol 8. Install and configure Nginx Enable secure access to your Solana’s node endpoint with Nginx. 8.1 Install Nginx root@solana-node-01:~# apt update && apt install nginx root@solana-node-01:~# cd /etc/nginx/sites-available/ root@solana-node-01:~# vim default 8.2 In location /, set proxy_pass http://solana, save root@solana-node-01:~# cd ../ && vim nginx.conf 8.3 At the end of the http section, add: upstream solana{ server 127.0.0.1:8799; } Save. 8.4 Set your domain name, if needed In /etc/nginx/sites-available/default, add the string server_name {{YOUR DOMAIN NAME HERE}} in the server section. 8.5 Test the Nginx configuration by executing the following: root@solana-node-01:~# nginx -t 8.6 Reload Nginx root@solana-node-01:~# systemctl reload nginx 9. Obtain the SSL certificate 9.1 Install Certbot root@solana-node-01:~# apt install certbot python3-certbot-nginx 9.2 Obtain and apply the certificate root@solana-node-01:~# certbot --nginx -d {{YOUR DOMAIN NAME HERE}} 10. Enable basic authentication on the endpoint Run: root@solana-node-01:~# apt install apache2-utils -y root@solana-node-01:~# cd /etc/nginx/ root@solana-node-01:~# htpasswd -c .htpasswd {{YOUR_BASIC_AUTH_USER}} Edit the Nginx configuration: root@solana-node-01:~# cd sites-available/ root@solana-node-01:~# vim default Add the following lines inside the server section: auth_basic "Authorization required"; auth_basic_user_file /etc/nginx/.htpasswd; Restart Nginx: root@solana-node-01:~# nginx -t root@solana-node-01:~# systemctl restart nginx You can set up a Solana RPC node at Chainstack instead. That’s why: Instant deployment. Spin up a managed Solana RPC node in under a minute: no CLI wrangling, no missed dependencies. Global coverage. Low-latency routes across multiple regions with automatic failover keep your application responsive worldwide. Predictable pricing. Transparent usage-based plans, starting with free 3M monthly requests on the Developer plan, and no hidden fees. Advanced tooling. Built-in metrics, access rules, and WebSocket support make it easy to monitor, secure, and scale your project. Battle-tested reliability. Chainstack powers thousands of production workloads and is trusted by leading Web3 teams building on the Solana blockchain. Deploy your Solana RPC node with Chainstack today and experience the best Solana RPC provider firsthand. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights, pump_fun bot sniping Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. Conclusion This tutorial walked you through the basics of setting up a non-validating Solana RPC node with a protected RPC endpoint. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to secure your RPC endpoints with access rules on Chainstack  Unsecured RPC endpoints face unauthorized traffic that inflates costs and triggers rate-limiting. Access rules solve this by filtering requests based on domain or IP address keeping your RPC node healthy. Learn how to configure access rules on Chainstack, implement domain and IP-based filtering, and combine them with other security measures for comprehensive RPC endpoint protection. Potentially your RPC endpoints are likely serving more than just your own traffic – if you’re running a DApp on Ethereum, Solana, Base, or any major chain, your unsecured RPC API endpoints may be exposed and used by someone else. It’s not uncommon for bots, browser extensions, or even other developers to piggyback off your infrastructure, using up bandwidth, inflating costs, and putting your API keys at risk. This is the cost of leaving your RPCs unprotected.  While good as a start, API keys are less secure than access rules that perform checks on every individual request before it even reaches your node. If you want to restrict RPC access at the network level, Chainstack lets you set access rules by domain or IP address. Whether you’re deploying a production dApp or simply running backend analytics, you can lock down your endpoints to only accept requests from the frontends or servers you trust.  Here’s how access rules work and how you can easily set them up on Chainstack.  Why you need to secure your RPC endpoints  RPC endpoints fail under pressure, and unsecured ones fail faster. When your endpoints are public or only protected by API keys, you’re essentially running an open server that anyone can hit.  While many factors affect RPC reliability, setting up access rules is one of the first steps we recommend in our RPC setup guide. API keys can authenticate requests, but they don’t filter out where those requests come from. If you want to keep your infrastructure safe, you need a way to block unwanted traffic before it reaches your node.  And that’s what access rules do: they determine the origin of each request, whether by domain or IP, even before anything is processed.  What are access rules? Access rules are security filters that validate incoming traffic before it reaches your RPC endpoints. They verify that the source of the request — either the HTTP Origin header or IP address — matches your configured allowlist and rejects ones that don’t.  There are two types of access rules you can configure:  Allowed origins — Limit access based on the HTTP Origin header, so it’s only possible to make requests from a set list of domains or subdomains.  IP addresses — Limits access to a defined set of IP addresses, blocking traffic from all others.  How access rules work  When a request is made to your node endpoint, Chainstack compares it against your set access rules. Its logic of filtering goes like the following:   If you have access rules configured, the request only gets processed if it matches at least one of your rules.   If no access rules are configured, all requests pass through and get processed normally, subject to your standard API key authentication.  If a request doesn’t match any rule, the request gets rejected immediately with an error response and never reaches your node.   This filtering happens at the network edge before any node resources are consumed. Rejected requests don’t count toward your usage or billing. The system uses an allowlist approach, as only explicitly permitted sources can connect, making it the most effective RPC access control mechanism available.  How to set up access rules on Chainstack  Getting access rules configured takes a few minutes, and once they’re active, your endpoints start rejecting unauthorized traffic right away. The process involves creating rules for specific domains or IP addresses, then turning them on when you’re ready to start filtering.  Prerequisites  You’ll need a few things before getting started:  A Chainstack Global Node – Access rules are only available for Global Nodes, not dedicated nodes.  Admin access to your Chainstack project.  Know what to whitelist – Figure out which domains (like myapp.com) or IP addresses (like 203.0.113.50) need access before you start adding rules.  Step-by-step RPC access control setup on Chainstack   You can add access rules directly from the Security tab of your node details page in the Chainstack console. Here’s how:  Open your Chainstack project.  Click on your network  Click on your node name  Switch to the Security tab Hit the + Add button to create a new access rule Find your new rule, hover over it, click the pencil icon, then click Activate That’s it. Your RPC node protection method is now live and filtering requests. You can turn rules on and off whenever you need to without affecting your node. Adding an allowed origin rule  Use this rule type to restrict RPC access based on the HTTP Origin header, typically for frontend apps.  In the Add access rule modal, choose Allowed origin.  Type the domain in the input field (examples: myapp.com, myapp.example.com, or *.myapp.com) Click Create to save your configuration.  Hover over the newly created rule, click the pencil icon, and click Activate.  The rule will start working immediately. Turn rules on/off as needed without downtime.  Supported origin formats:  Exact domains: myapp.com, app.example.com Wildcards: e.g. *.example.com (matches any subdomain) Wildcard rules use the * character to match any subdomain. For example, *.example.com will match app.example.com, api.example.com, and staging.example.com. Adding an IP address rule  IP rules lock down access to specific servers or infrastructure that always connects from the same address.  Setup: Pick IP address in the Add access rule modal  Enter your IP address  Hit Create to save the rule  Supported IP formats:  IPv4: 192.168.1.100 IPv6: 2001:db8::1 Limitations: One IP per rule. CIDR notation is not supported.  Managing access rules on Chainstack  Once created, all your rules will show up in the Security tab under Access rules. From there you can turn them on or off, or delete ones you don’t need anymore.  Check the full documentation for more detailed options.  Best practices for RPC access security  While access rules offer essential filtering at the network level, pairing them up with other security controls creates layers of protection that are harder to breach. Here are our top RPC node protection methods:    Enable strict access rules – Allow only the domains or IPs you trust. Avoid wildcards like *.myapp.com unless strictly necessary.  Don’t rely on a single control – Access rules are just one layer. Use them alongside API keys, method allowlists, and rate limits.  Apply per-IP rate limiting – Most providers, including Chainstack, enforce this. If your rules are too open, you’ll hit provider limits fast.  Block high-cost methods – Calls like eth_getLogs or eth_trace* can be resource-intensive. If your app doesn’t rely on them, block or limit them at the access layer.  Add WAF rules upstream – A Web Application Firewall helps drop junk traffic before it even hits your node.  Use HTTPS and check CORS headers – Always encrypt RPC traffic. For frontend apps, make sure the Origin header is present and correct, browsers handle this by default.  Combine origin and IP filters – Use origin-based rules for frontend access, IP-based for backend services. Stacking both gives you tighter control.  Conclusion   Access rules let you control who can call your RPC endpoints, before any traffic hits them. That means fewer surprise spikes, tighter security, and more predictable billing.  The setup process is the same for all networks, whether you’re running Ethereum RPC nodes for DeFi protocols, Solana endpoints for trading bot, or using Base RPC API for Web3 apps. Access rules work best combined with API keys and rate limiting. They solve the specific problem of traffic source control, but they’re part of a broader security strategy.  Get started with access rules on Chainstack Global Nodes – they’re available for Ethereum, Solana, Base, Polygon, Arbitrum, and 70+ other chains.  Further reading   How to store your Web3 dApp secrets: Guide to environment variables: Learn how to properly store private keys, access tokens, and other secrets in your Web3 dApp.   5 essential factors for setting up RPC node endpoints: Access rules are just one layer; this guide helps you implement the rest.  Power-boost your project on Chainstack  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform.  Input your workload and see how affordable Chainstack is compared to other RPC providers.  Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Optimism, Avalanche, TON, Ronin, zkSync Era, Starknet, Scroll, Aptos, Fantom, Cronos, Gnosis Chain, Klaytn, Moonbeam, Celo, Aurora, Oasis Sapphire, Polygon zkEVM, Bitcoin and Harmony mainnet or testnets through an interface designed to help you get the job done.  To learn more about Chainstack, visit our  Developer Portal or join our Discord server and Telegram group.   Are you in need of testnet tokens? Request some from our faucets. Multi-chain faucet, Sepolia faucet, Holesky faucet, BNB faucet, zkSync faucet, Scroll faucet.  Have you already explored what you can achieve with Chainstack? Get started for free today.  #### How to track swaps on Uniswap with web3.js? In just 5 minutes you will learn how to leverage web3.js and WebSocket endpoints to monitor swaps on Uniswap. The idea for this tutorial came from one of our Discord members who had a very specific data task on Ethereum. This user wanted to monitor the Uniswap router contract to know whenever an ETH to token swap happens. For example, if someone is swapping 1 ETH to USDC, he wants to extract the transaction ID, the address, and so on, to be displayed in real-time as it gets confirmed. At first, it seems like an easy task, but if you dive a little bit deeper, you will realize that it’s more complex. In case you don’t know, the Uniswap router contract does not emit swap events. Swap events are only emitted on the pair itself, not on the router contract. We’ll be utilizing WebSocket subscriptions to look through every new block that’s added to the Ethereum blockchain, and then within that block, look through each transaction, see if it’s a swap on Uniswap, and then display that information. While it may sound a little bit complicated, it’s really simple in implementation. Let’s utilize web3.js and WebSocket endpoints to track swaps on Uniswap. Import the base libraries Before we start we need one major base library, and that is web3.js. This will be the only library that we’ll be using, and it will act as our foundational layer of connectivity with the blockchain. const { Web3 } = require('web3'); Define the RPC node Now that we have Web3 imported, we need to define an RPC node. We can define this in a variable called NODE_URL. const NODE_URL = "input your WSS endpoint here"; //your Chainstack WebSocket endpoint Deploy your node and get your WebSocket endpoint If you do not have a Chainstack account yet, you can sign up for free in order to follow along with this tutorial. After you have your account, you can go ahead and deploy an Ethereum node by following the steps in the video below. Once your node is running, you can click on it to see its details. Scroll to the bottom of the page and grab the WSS execution endpoint. Define the Web3 object with RPC as a constructor const web3 = new Web3(NODE_URL); Define three key variables We only need to find two types of swaps. Either swapExactETHForTokens or a separate method called swapExactETHForTokensSupportingFeeOnTransferTokens, which achieves essentially the same goal, but it’s for a different type of token. This means that we’ll need to define three key variables. Uniswap router address. We will use the V2 router because it’s easier to show in this example. The ID of the swapExactETHForTokens method. The ID of the swapExactETHForTokensSupportingFeeOnTransferTokens method. const UNISWAP_ROUTER_ADDRESS = "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"; const SWAP_EXACT_ETH_FOR_TOKENS_SIGNATURE = "0x7ff36ab5"; const SWAP_EXACT_ETH_OR_TOKENS_SUPPORTING_FEE_ON_TRANSFER_TOKENS_SIGNATURE = "0xb6f9de95"; Create function subscribeToNewBlocks Now that we have our variables defined, we can go ahead and create a new function called subscribeToNewBlocks. async function subscribeToNewBlocks() { const subscription = await web3.eth.subscribe('newBlockHeaders'); subscription.on('data', handleNewBlock); } async function handleNewBlock(blockHeader) { console.log(`Got new block: ${blockHeader.number}`); const block = await web3.eth.getBlock(blockHeader.number, true); block.transactions.forEach((tx) => { if(tx.to && tx.to.toLowerCase() === UNISWAP_ROUTER_ADDRESS.toLowerCase() && (tx.input.startsWith(SWAP_EXACT_ETH_FOR_TOKENS_SIGNATURE) || (tx.input.startsWith(SWAP_EXACT_ETH_OR_TOKENS_SUPPORTING_FEE_ON_TRANSFER_TOKENS_SIGNATURE))) { console.log("-----------------------------------------------------") console.log(`Incoming swap transaction: ${tx.hash}`); console.log(`From: ${tx.from}`); console.log(`Value: ${web3.utils.fromWei(tx.value, "ether")} ETH`); console.log("-----------------------------------------------------") } }) } subscribeToNewBlocks(); The subscribeToNewBlock function will monitor the Ethereum blockchain, and whenever a new block is created, it will return it so that we can get close to real-time data. The handleNewBlock function will log every time it finds a new block. Then, it will fetch that block, and loop through the transactions that were included in that block. If it finds transactions where the to address a.k.a. receiver is THE UNISWAP_ROUTER_ADDRESS, and the method ID matches the method ID of either SWAP_EXACT_ETH_FOR_TOKENS_SIGNATURE or SWAP_EXACT_ETH_OR_TOKENS_SUPPORTING_FEE_ON_TRANSFER_TOKENS_SIGNATURE, it will return that transaction’s hash, the sender, and the amount of ETH that was swapped for a particular token. Let’s recap what you did You’ve imported Web3. Created a Chainstack WebSocket endpoint, and used it in the definition of our Web3 object. Defined 3 key base variables including the Uniswap V2 router address, and the two method IDs. Defined the subscribeToNewBlocks function. Created the function that handles the data when it gets it, which is the handleNewBlock function. Now, if you run the code it should return the latest block that got confirmed, along with the swap transactions within it. Congratulations if you got to the end of this tutorial, now you know how to track swaps on Uniswap in real-time on the Ethereum blockchain. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to use Solflare wallet with Chainstack What is Solflare? Solflare is a popular wallet for the Solana network which allows users to buy, store and swap tokens & NFTs. It is one of a few wallets which supports custom nodes, and this article will guide you through the process of setting up Solflare with Chainstack. Why do you need a custom endpoint? There are several reasons for a user to implement their own custom endpoint. Congestion. The default endpoint for Solflare is the Solana official endpoint : https://api.mainnet-beta.solana.comThis address is automatically set up and initially is the same across all the users, making it amazingly easy to get up and running. This also means this address is probably the most widely used endpoint in the network and it is shared among many users. Transactions through this endpoint may experience high latency.Stability and connectivity. It is always a good idea to have a backup endpoint that is available 24/7 just in case the main one fails. Setting up custom endpoints with Chainstack protects yourself from network instability, as well as makes transactions faster and fault-tolerant.Cost. Chainstack provides a free endpoint on the Developer subscription. Anyone can start developing without worrying about the cost. How to set up a Solana node? Follow this guide to set up a Chainstack Solana node. Once the node is successfully deployed, the HTTPS endpoint will be available for consumption. 1. Open Solflare, and click Settings > Network. 2. Select Add custom node. 3. Fill in the name and RPC address. Example: 4. Check if the custom RPC is listed and pre-selected. There it is, your Solflare wallet is ready for use. Conclusion That is the end of this article. If you have any question, feel free to ping us in our Telegram/Discord. Happy coding, Cheers! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How to use the Solana Geyser plugin to stream data with Yellowstone gRPC Yellowstone gRPC Geyser plugin has been the go-to for high-performance Solana streaming with typed schemas, validator memory access, and sub-50 ms latency. We’ve now made it 10× more affordable with plans starting at $49/month, and this guide shows you how to get started. Every Solana project depends on timing. Whether it’s a trading bot or a wallet tracker, you need a way to see changes the moment they land on-chain. Polling RPC calls gets the job done, but it wastes compute, adds latency, and forces you to reprocess the same state over and over. That’s why most developers move to streaming. Streaming Solana with the Yellowstone gRPC Geyser plugin Built on the Geyser plugin, Yellowstone gRPC streams events straight from validator memory. That means you don’t have to parse raw strings yourself as typed messages land faster (often in under 50 ms) with filters applied before the data ever reaches your app. This makes Yellowstone gRPC the natural fit for workloads where reliability matters, like: Trading and mint bots that can’t afford to miss a swap. Wallet alert services built around account changes. Dashboards and mini indexers pushing filtered data into a DB or queue. For a long time, cost was the barrier that kept builders from choosing Yellowstone gRPC first. That’s why at Chainstack, we introduced an entry plan for smaller teams, starting at $49/month. It gives you production-grade streaming without overbuying or patching around missed events. Yellowstone gRPC stream types and when to use them Once you’re on gRPC, the main choice is which stream to tap into. Each one has a different use case: accounts — follow wallets or PDAs. Balance changes, token updates, program state. transactions — full tx detail. Good for swap trackers, trading bots, program calls. transaction_status — lighter than transactions. Just tells you if it confirmed or failed. slots — react to slot boundaries. Useful for pacing or time-based logic. blocks — full block content. Use it for ordering, timestamps, analytics. blocks_meta — block headers and leader info only. Nice for lightweight analytics. entries — raw validator feed. Mostly for research or digging deep. Each connection lets you run up to five filters of the same type. Keep them focused, and if you need more, spin up another stream. How to use Solana gRPC Geyser plugin You technically can run Yellowstone gRPC yourself. But most builders will tell you it’s the hardest part of the stack: managing hardware, snapshots, upgrades, storage, networking, and recovery on a validator. That’s a lot of overhead for one plugin. The other option is managed access. Providers will give you Geyser as an add-on, but most start around $500–$1,000/month. That’s fine if you’re a big team, but for testing a bot, wiring up wallet alerts, or keeping a dashboard live, it’s paying for streams you’ll never use. That’s why we rolled out a new entry tier on Chainstack — only $49/month for production-grade Yellowstone gRPC. It’s up to 10× more affordable than other options available on the market, and if you need more later, you can scale without changing your stack. Here’s how the plans line up: $49 → 2 streams, up to 50 accounts. Good for testing bots, alerts, and dashboards. $149 → 7 streams. Enough to split staging and prod. $449 → 25 streams. Full fan-out for heavier workloads. The plugin is available from the Growth plan and up. You’ll find it directly in the console marketplace, and setup takes just a couple of clicks. How to enable Yellowstone gRPC on Chainstack Log in to your Chainstack account (or create one if you don’t have one yet). Create a new project, or pick an existing one. Deploy a Solana Global Node. Open the node once it’s live. Go to Add-ons → Yellowstone gRPC Geyser Plugin → Install. Solana Geyser example for real-time token tracking Here’s a step-by-step walkthrough showing how to use Yellowstone gRPC to stream token activity in real time,  in this case tracking swaps on Raydium and mints on Bonk.fun. If you want the full breakdown with code, filters, and setup, check out our detailed guide on real-time Solana analytics for Raydium and Bonk.fun tokens with the Geyser plugin. Wrap up Yellowstone gRPC has become the standard for reliable Solana streaming, with typed events, sub-50 ms latency, and data straight from validator memory. It’s built for production, but now it’s also priced so smaller teams can use it from the start. If you just want to test a bot, track mints, or wire up alerts, you can begin with our new Yellowstone gRPC Geyser plugin plan, starting at only $49/month. And when the workload grows, scaling to more streams is simple without changing your stack. Enable Yellowstone gRPC → FAQ What is the Solana Geyser plugin? The Geyser plugin is a Solana validator add-on that streams real-time data out of validator memory. It lets you subscribe to accounts, slots, transactions, and blocks without polling. What is Yellowstone gRPC? Yellowstone gRPC is an implementation of the Geyser plugin that uses gRPC to deliver typed, structured events. It’s faster and more reliable than WebSockets, with sub-50 ms latency. When should I use WebSockets instead of Yellowstone gRPC? Use WebSockets for lightweight dashboards, explorers, or alerts where a dropped update is fine. Switch to Yellowstone gRPC when you need typed data, filtering, and guaranteed delivery in production. What stream types are available with Yellowstone gRPC? You can subscribe to accounts, transactions, transaction_status, slots, blocks, blocks_meta, and entries. Each covers different needs, from wallet changes to full block data. How do I get access to Yellowstone gRPC? You can run it yourself by managing a validator, but it’s complex. Managed access through providers is easier but often starts at $500–$1,000/month. On Chainstack, it’s available from only $49/month. Do I need a dedicated validator to use Yellowstone gRPC on Chainstack? No. Chainstack runs the validator infrastructure for you. You just enable the plugin on a Solana Global Node through the console. Can I use Yellowstone gRPC for trading bots? Yes. gRPC is a better fit than WebSockets for bots and mint snipers since you get typed events, low latency, and fewer missed updates. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. If you want to mess around with it, we’ve put together a bunch of examples and repos you can pull from: Solana Geyser Python tutorial Pump.fun and Bonk.fun sniping bot with Geyser Listening to pump.fun token mints using Geyser Listening to programs with Yellowstone gRPC (Node.js) Yellowstone repo Rust example Go example #### How to сonnect Chainstack MCP server to Claude What if Claude could check an Ethereum wallet balance, deploy a Solana node, or search Chainstack’s docs — all from a single prompt? With the Chainstack MCP server, it can. MCP (Model Context Protocol) is an open standard by Anthropic that lets Claude talk directly to external tools and APIs. Connect it to Chainstack and your AI assistant gets live access to 70+ blockchain networks, your node infrastructure, and the full Chainstack documentation — without leaving your IDE or chat window. This guide walks you through setup for Claude Desktop, Claude.ai, and Claude Code. What is the Chainstack MCP server MCP (Model Context Protocol) is an open standard by Anthropic that gives Claude secure, structured access to external tools and APIs. Chainstack is a blockchain infrastructure provider (RPC nodes for 70+ networks: Ethereum, Solana, Base, Polygon, Arbitrum, and more). Chainstack MCP server lets Claude: search Chainstack documentation; deploy and manage Global or Trader Nodes via the MCP server; make direct JSON-RPC calls to Ethereum, Solana, and all other chains available on the platform. ServerURL / repoTransportStatusChainstack MCP (unified)https://mcp.chainstack.com/mcpStreamable HTTP✅ Current Available tools No API key required: ToolWhat it doessearch_docsSearch Chainstack documentation — RPC methods, deployment guides, code examplesget_doc_pageFetch the full content of any documentation pageget_platform_statusCheck platform status, active incidents, and network healthget_chainstack_pricingGet current pricing informationcontact_chainstackReach the Chainstack team API key required (get one at console.chainstack.com/user/settings/api-keys): ToolWhat it doesget_organizationGet your organization name and IDget_deployment_optionsList available blockchain, cloud, and region combinationslist_projectsList all your projectscreate_projectCreate a new projectget_projectGet project detailsupdate_projectUpdate a project’s name or descriptiondelete_projectDelete a projectlist_nodesList all nodes with status and endpointsget_nodeGet a node’s full details including RPC endpointscreate_nodeDeploy a new blockchain nodeupdate_nodeRename a nodedelete_nodeDelete a noderequest_testnet_fundsRequest testnet tokens Prerequisites Claude account — a paid plan is required for remote MCP via “Custom Connectors”; any plan works for claude_desktop_config.json. Claude Desktop — download at claude.ai/download and sign in with your Anthropic account. Node.js ≥ 18 — required for npx. Check with: node -v. Chainstack account — sign up at console.chainstack.com/sign-up. Create an API key under Settings → API Keys (shown only once — save it). Optional Claude Code CLI: npm install -g @anthropic-ai/claude-code. Where Is claude_desktop_config.json OSPathmacOS~/Library/Application Support/Claude/claude_desktop_config.jsonWindows%APPDATA%\Claude\claude_desktop_config.jsonLinux~/.config/Claude/claude_desktop_config.json Quickest way to open it: Claude → Settings → Developer → Edit Config — the file will be created automatically if it doesn’t exist. Connecting to Claude A cloud server combining documentation search, platform management, and RPC access. No local installation needed. Quickest setup Paste this into Claude Code or Claude Desktop chat: get mcp.chainstack.com The agent will open the discovery page and handle all configuration steps automatically. Option 1: Install as a skill (Claude Code) A lightweight alternative to full MCP registration — the skill file tells Claude Code how to call Chainstack tools on demand without adding them permanently to context. Best if you don’t need Chainstack tools in every session. bash mkdir -p ~/.claude/skills/chainstack curl -o ~/.claude/skills/chainstack/SKILL.md https://mcp.chainstack.com/skill Restart Claude Code or start a new session. Claude will automatically pick up the skill. Option 2: Register as MCP server Chainstack tools are always available in context. Use any of the methods below. Claude Desktop — via mcp-remote Claude Desktop only supports stdio natively — connect remote HTTP servers using the mcp-remote proxy. Add to claude_desktop_config.json: json { "mcpServers": { "chainstack": { "command": "npx", "args": ["mcp-remote", "https://mcp.chainstack.com/mcp"] } } } Fully quit Claude Desktop (Cmd+Q on macOS) and relaunch. A 🔨 tools indicator should appear in the chat input area. Claude.ai / Claude Desktop — via “Custom Connectors” Go to Settings → Connectors → Add custom connector and enter: https://mcp.chainstack.com/mcp. Claude Code CLI bash claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp # Available across all projects: claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp --scope user # Verify: claude mcp list Passing the Chainstack Platform API key bash claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp \ --header "Authorization: Bearer YOUR_API_KEY" -s user Example prompts EVM: “Get the ETH balance of 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on Ethereum mainnet.” “Trace transaction 0xabc…def and explain what happened step by step.” “Simulate this transaction with a modified sender balance.” Solana: “What’s the SOL balance of Gh9ZwEmdLJ8DscKNTkTqPbNwLNNBjuSzaG9Vp2KGtKJr?” “Get recent prioritization fees and recommend a priority fee for a swap.” Documentation: “How do I enable the Yellowstone gRPC Geyser plugin on my Chainstack Solana node?” “Which chains on Chainstack support Warp transactions?” Platform operations (unified MCP): “Deploy a new Chainstack Global Node on Ethereum mainnet.” “Scan my repo for RPC URLs and suggest Chainstack replacements.” Troubleshooting ProblemSolution🔨 indicator not showingFully quit Claude Desktop (Cmd+Q / Quit from tray) — config is only read on startupJSON parse errorValidate claude_desktop_config.json with a JSON linter — a stray comma or bracket breaks everythingnpx not foundUse the full path in command (find it with which npx)Relative path errorAll paths in args must be absoluteStreamable HTTP not workingClaude Desktop doesn’t support remote HTTP natively — wrap with npx mcp-remote <URL>401 Unauthorized on RPCChainstack endpoints already embed credentials in the URL — no Authorization header neededPlatform actions failingCreate a Platform API key under Settings → API Keys and pass it via --header "Authorization: Bearer KEY"Logs for debuggingmacOS: ~/Library/Logs/Claude/mcp*.log · Windows: %APPDATA%\Claude\logs\ Conclusion Once connected, Chainstack MCP turns Claude into a live blockchain development assistant — you can query on-chain data, deploy and manage nodes, and search Chainstack’s documentation without leaving your IDE or chat interface. The unified server at mcp.chainstack.com/mcp requires no local setup and works across Claude Desktop, Claude.ai, and Claude Code. For node management and platform operations, grab your API key at console.chainstack.com/user/settings/api-keys — public tools like documentation search and platform status work without one. Get started for free → FAQ Do I need a paid Claude plan to use Chainstack MCP? For Claude Desktop via claude_desktop_config.json — any plan works. For remote MCP via “Custom Connectors” in Claude.ai — a paid plan is required. Do I need a Chainstack API key? Not for documentation search, platform status, and contacting Chainstack. You do need one for node deployment and project management. Get it at console.chainstack.com/user/settings/api-keys. What chains does Chainstack MCP support? All chains available on the Chainstack platform — including Ethereum, Solana, Base, Polygon, Arbitrum, and more. See the full list at chainstack.com/protocols. Claude Desktop shows no tools after setup — what’s wrong? Make sure you fully quit Claude Desktop (not just close the window) before relaunching. The config file is only read on startup. Also validate your claude_desktop_config.json with a JSON linter — a single stray comma breaks parsing silently. Can I use Chainstack MCP without Claude Desktop? Yes. Claude Code CLI (claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp) and Claude.ai via Custom Connectors both work without Claude Desktop. Related reading Chainstack MCP server documentation Blockchain RPC nodes for AI agents MCP for Web3 builders: Solana, EVM and Documentation Migrate blockchain RPC endpoints to Chainstack #### How Utility NFTs are redefining the future of digital assets Blockchain technology and the rise of NFTs have ushered in a new era in digital innovation. Amidst this revolution, one form of NFT is subtly redefining the way we perceive digital ownership—Utility NFTs. These are not just digital collectibles, but tokens that offer real-world benefits, privileges, and rights to the token holders. As the NFT market sees exponential growth, Utility NFTs are gaining prominence for their unique capabilities and potential to shape the future of blockchain technology. From reinventing the ticketing system for events to enabling unique privileges in the explosive gaming industry, Utility NFTs have already started stirring the waters. But how does this work? And what could the future of Utility NFTs look like? This blog post will take you on a journey through the world of Utility NFTs, exploring what they are, how they work, and how they could redefine multiple sectors in the years to come. What are Utility NFTs When delving into understanding Utility NFTs, the focus pivots towards ‘utility’—the element that expansively maps their applicability beyond the traditional ‘digital collectibles’ realm. Utility NFTs essentially refer to virtual assets that accord token holders with certain privileges, benefits, or services. In simple terms, these NFTs serve up a ‘right’ to the user to access a certain utility or advantage. Let’s illustrate this with an example. Imagine a scenario where a concert organizer, Mr. Lee, chooses to leapfrog from traditional paper tickets to Utility NFT tickets. These tickets are digitized representatives of their real-world counterparts, each bearing unique data such as ticket numbers and seat numbers. However, the crux is that they provide the token holders with additional layers of perks. Figure 1: NFT tickets on sale on the YellowHeart marketplace Being digitally encrypted on the blockchain, these tickets ensure optimal security, offer immutable originality verification, are easily transferable, and cannot be duplicated due to their unique attributes—all characteristics of standard NFTs. But besides this, utility NFTs infuse added privileges, taking the appeal of NFTs up a notch and opening up new horizons for blockchain-based solutions to transform the financial world. The true power of utility NFTs does not merely end at digital collectibles. They encompass a broad spectrum of assets, from digital art to real estate to gaming content. In essence, they grant holders access to exclusive rights to a particular asset, a feature that positions utility NFTs at the cutting-edge of blockchain-driven innovation. How Utility NFTs work The core technology that powers Utility NFTs is the same that underpins all forms of NFTs—blockchain, a decentralized ledger system that adds an unparalleled layer of security and transparency to all transactions. Primarily built on Ethereum’s blockchain, utility NFTs stand out due to the combination of their unique attributes and the practical benefits they confer on holders. They encompass the same structural brilliance as other NFTs and maintain their uniqueness with the help of cryptographic encryption. However, they have an added element of ‘functionality.’ For instance, in a concert setting, NFT tickets can ensure seating placement, event entry, and permanence, all while being digitally trackable, uniquely assigned, and unduplicable. The operational mechanics of utility NFTs mirror that of standard NFTs, encapsulating each transaction’s uniqueness with an exclusive ID and metadata that cannot be reproduced or duplicated. This character of NFTs is sustained by smart contracts which are self-executing contracts with the agreement’s conditions directly written into lines of code. Given that Utility NFTs are still in their blooming phase, their full potential across various sectors is yet to be realized. Unique characteristics of Utility NFTs Utility NFTs have begun to showcase their significance in business and popular culture. This new trend has influenced even existing NFT collections to evolve into Utility NFTs—a real-world example is the prominent Bored Ape Yacht Club, which now offers exclusive access to events and the ability to mint new NFTs. The transformation from classic to utility-infused NFTs unlocks a multitude of added privileges. What sets Utility NFTs apart is that beyond offering proof of ownership, they also include inherent utility or use-cases. Whether it’s a digital ticket to an exclusive event or governance rights within a decentralized community, the scope of utility NFTs extends much beyond mere ownership of the token itself. Figure 2: Fungible vs non-fungible tokens; Source: Apriorit Utility NFTs advantages over traditional tokens The advantages of Utility NFTs over traditional tokens are numerous. They are capable of building community, proving and incentivizing ownership, and even protecting our planet. The technology for this transformative shift is already here; how we utilize it is limited only by our imagination and creativity. Enhanced digital transfer security: Utility NFT marketplaces tailored for various sectors promise heightened security and data integrity. This advancement significantly reduces the risks of cyber fraud and manipulation, such as tampering with crucial information or fraudulent transactions like counterfeit deeds. Streamlined ownership verification: The blockchain-based creation of Utility NFTs guarantees secure and unalterable records of ownership, drastically cutting down on paperwork and notary services. This leads to a decrease in fraud potential and expedites processes like property buying and leasing. Efficient asset trading: Transactions involving tokenized assets like Utility NFTs are governed by smart contracts. These contracts define transfer conditions and autonomously execute verified transactions, fostering efficient and trustworthy coordination among various stakeholders, including financial institutions, legal entities, and escrow services. Increased market liquidity: Utility NFT tokenization is set to break down barriers in asset transactions, streamlining processes, cutting out unnecessary intermediaries, and lowering entry costs. This approach enhances market liquidity, allowing a broader range of participants to engage in buying and selling. Improved price discovery: Fractionalizing Utility NFTs leads to more precise insights into their fair market value. Pricing a part of an asset can offer a more accurate valuation, avoiding the discrepancies often found in estimates from different experts. Today’s discussion about Utility NFTs truly stresses on the ‘Utility’ aspect, which sets this asset class apart. Its unmatched characteristics prove that Utility NFTs are a lot more than just digital collectables. These assets go beyond the realm of art and gaming, providing token holders with a right to use certain services or benefits that they would otherwise be unable to access. Use cases for Utility NFTs Utility NFTs, with actual real-world use cases, could be the transformative force turning NFTs from solely being an investment obsession to a novel way to work, play, and interact. The core of Utility NFTs lies in their ability to provide holders certain rights and privileges otherwise unavailable in conventional setups. Utility NFTs are carving out their niche in various industries, extending their influence beyond just GameFI and into real estate, art, and fashion. The journey of discovering the broad spectrum of utility that these unique tokens can offer is only just beginning. Figure 3: Use cases for Utility NFTs; Source: Liquiditeam GameFi Utility NFTs The gaming industry has always been a powerful incubator for revolutionary technologies. With the massive technological growth, gamers have shifted from clunky gaming machines in arcades to sleek, online, and live-streaming games. Blockchain and NFTs have been introduced to e-games as GameFi and Play-to-Earn, allowing players to earn a passive income through their gaming skills. Utility NFTs in games allow players to claim ownership over in-game assets such as avatars and merchandise, giving them the power to trade them on NFT marketplaces. Figure 4: Axie in-game asset NFT marketplace listing; Source: Bankless Utility NFTs in real estate The practical application of Utility NFTs in the real estate sector is already underway, moving beyond just theoretical discussions. A notable example is Michael Arrington’s listing of an apartment on the Propy real estate platform, which was sold as an NFT. This property, originally acquired using Ethereum smart contracts, achieved a significant milestone by becoming the first-ever real estate NFT, selling for over $93,000. Figure 5: Michael Arrington interview with Propy CEO Natalia Karayaneva; Source: Propy YouTube Similarly, Prometheus, a real estate development company, made a significant impact by selling two luxury homes in Portugal for cryptocurrency. These transactions were groundbreaking, not just as property sales, but for incorporating NFTs into the ownership process. These examples highlight the emerging possibilities of merging NFTs with real estate, signaling a new era in property transactions and ownership. Art and fashion industry Utility NFTs The Art and Fashion domains have widely accepted the advent of Utility NFTs with numerous projects launched to represent real-world items like merchandise, clothes, jewelry and art pieces in a digital avatar. Fashion brands can utilize NFTs to conduct online auctions with a secure, provable winner selection method. Augmented reality could potentially enable users to try out different looks with virtual clothing in the metaverse. A notable example of this is the collaboration between Paris Saint-Germain F.C., a prominent football club, and Blvck Paris, a cutting-edge fashion label. The two brands joined forces for a unique collaboration that blends sports, fashion, and digital creativity. This innovative collection featured both physical and digital fashion pieces, with the highlight being a digital-first release of fashion NFTs. These NFTs, debuted exclusively on the Crypto.com marketplace, offering early access to the physical apparel as well as additional perks for their holders. ⚫ 𝐁𝐋𝐕𝐂𝐊  𝐱  𝐏𝐒𝐆 🔴🔵 is officially LIVE! https://t.co/1zo3U8ERDl pic.twitter.com/5xUoxFiezN— Blvck Paris (@BlvckParis) November 15, 2023 Figure 6: Paris Saint-Germain Utility NFTs for Blvck Paris Fashion; Source: Twitter The surge of Utility NFTs simply confirms one fact—this digital breakthrough is here to stay and expand. The future looks promising, with innovative use cases being explored every day. The wave of Utility NFTs is certainly transforming the digital landscape as we know it. Utility NFTs in music An illustrative case of Utility NFTs in the music industry is Kings of Leon’s March 2021 initiative. They made history with their album “When You See Yourself,” releasing it not just on traditional platforms like Spotify and iTunes, but also as a series of Utility NFTs, each with unique utilities. Figure 7: Kings of Leon – When You See Yourself Utility NFT video; Source: YouTube These Utility NFTs weren’t limited to digital formats. One variant offered digital artwork, a music download, and even a redeemable physical vinyl edition of the album. Another Utility NFT in the series provided access to premium seats at the band’s concerts. The innovative approach paid off. Within days, Kings of Leon amassed two million USD from their Utility NFT sales. This example from Kings of Leon opens up a realm of possibilities for Utility NFTs in various fields. If Utility NFTs can offer front-row concert experiences, they could potentially replace traditional season tickets in sports, offering year-long access to football games and more. The potential applications of Utility NFTs in enhancing experiences and offering unique perks are vast and varied. Utility NFTs for travel and cruise ticketing While the concept of Utility NFTs in travel hasn’t been fully realized yet, it’s on the horizon. Notably, major cruise lines like Norwegian, Carnival, and Celebrity Cruises have already ventured into Utility NFTs with art collections, hinting at the potential expansion into ticketing. In the realm of travel and cruises, Utility NFTs can significantly enhance loyalty programs, identity verification, and security. Figure 8: Norwegian Prima Inaugural Sailing – September 2022 NFT; Source: Norwegian Cruise Line Loyalty programs are particularly promising. Imagine integrating Utility NFTs to reward frequent travelers transparently and securely, akin to digital achievement badges. For instance, a customer who accumulates 1,000 air miles could receive an Utility NFT, unlocking a range of benefits associated with that mileage tier, easily verifiable at checkout. Utility NFTs can also streamline identity verification and enhance security. Ownership of an NFT can serve as a simple yet effective form of identity confirmation during transactions, making processes like claiming loyalty rewards as effortless as a button click. Moreover, the inherent security features of Utility NFTs—their immutability and traceable history—can foster more transparent and secure operations, benefiting both the service providers and customers. As the travel and cruise industry explores these avenues, Utility NFTs stand to revolutionize how services are offered and accessed, adding value and convenience to every stakeholder involved. Sports ticketing with Utility NFTs While arts and travel have been exploring Utility NFTs, sports events are another promising domain for their application. The integration of Utility NFTs into sports ticketing offers significant advantages. Firstly, Utility NFT tickets can streamline the ticket purchasing process, offering fans a more efficient way to access games and matches. This digital approach can eliminate the need for traditional, often cumbersome, ticket-buying methods. Secondly, the security benefits are noteworthy. The combination of blockchain’s immutability and a comprehensive digital record significantly reduces the risk of fraud. This security extends beyond ticketing to the safe purchase of merchandise and memorabilia, ensuring authenticity and protecting buyers. Moreover, Utility NFTs in sports aren’t just about ticketing. They open the door to complete control over royalties and distribution, a topic that deserves extensive discussion. This dual advantage – enhanced convenience and heightened security – marks a significant evolution in how sports events manage ticketing and related transactions. Decentralized identity and Utility NFTs Decentralized identity, a vital topic in the Web3 sphere, includes concepts like Identity Utility NFTs, Decentralized Identities (DIDs), Self-Sovereign Identities (SSIs), and Verified Credentials (VCs). These terms, while closely related, each represent slightly different aspects of the same overarching idea. For example, CollectID is making significant strides in employing Utility NFTs for identity purposes. By partnering with major entities like Kappa and sports teams such as FC Köln, Deportivo de La Coruña, and Bayer Leverkusen, CollectID is influencing the landscape significantly. The primary advantages of this Utility NFT-based identity approach include transferring data ownership back to users and simplifying the verification process across various stages. While the ease of verification is evident, the real novelty lies in how this method addresses privacy concerns across various sectors like marketing and sales, offering a fresh perspective on data privacy and user autonomy. Name Service Utility NFTs Another aspect of decentralized identities, distinct from individual human identities, revolves around naming services. This concept might seem abstract to those not familiar with tech jargon, but it essentially relates to domains and platform identifiers. This approach reimagines the traditional Web2 Domain Name Service (DNS) in the Web3 context. Here, owning a specific NFT corresponds to having rights over a website domain name, turning it into a digital asset that can be held in a digital wallet. A prime example is the Ethereum Name Service (ENS), which operates similar to conventional domain registration but uses time-bound NFTs to signify ownership. Figure 9: Vitalik Buterin’s ENS website; Source: vitalik.eth.limo ENS seamlessly integrates with web browsers through an IPFS connection, but there are other services tailored to specific platforms. For instance, Campfire Usernames are exclusive to the Campfire Exchange, functioning as searchable elements within that ecosystem. Unlike the “.eth” domains of ENS, Campfire’s “.fire” domains primarily act as identifiers for creator profiles, rather than as broader web addresses. Notable Utility NFT projects In the dynamic landscape of the blockchain, several outstanding projects employing Utility NFTs are setting precedents and paving the way forward. GET Protocol: GET Protocol offers an innovative infrastructure blend, catering to the global events industry and enhancing NFT Ticketing benefits for organizers, artists, and their fans. Each ticket sold is instantly minted into an NFT, with the added advantage that buyers don’t need any blockchain or cryptocurrency knowledge to purchase and use their tickets. Furthermore, GET equips event organizers with tools to oversee and benefit from secondary ticket sales, capturing revenue and data that would otherwise be missed. VeeFriends: Spearheaded by eminent entrepreneur Gary Vaynerchuk, VeeFriends provides token holders access to the VeeCon conference—the world’s first-ever NFT-ticketed event. The community given to token owners allows for mutual learning, idea exchanges, and exclusive networking opportunities. Doodles: A collection of 10,000 NFT characters curated by Burnt Toast, Doodles extend beyond aesthetic appeal to offer functional value. The ownership of a Doodle token allows users to participate in community-led decisions and future developments of the project. World of Women: This project seeks to uplift and educate women, boosting their presence in the NFT and wider Web3 space. Token holders are granted ownership rights to the underlying artwork and privileged access to exclusive events and meet-ups. Crypto Baristas: This progressive NFT project provides a comprehensive caffeine experience, offering token holders exclusive perks at future café locations, the online store, and on merchandise. The advent of these progressive projects demonstrate compelling implementations of utility NFTs while burgeoning their acceptance and adaptability in broader communities. Figure 10: The Non-Fungible Token (NFT) ecosystem; Source: TheBlock The future of Utility NFTs The yet nascent field of Utility NFTs holds a future replete with transformative possibilities. As we progressively traverse into the digital age, they pose significant potential to supersede conventional norms across various sectors. We envision a not-so-distant future where Utility NFTs could seamlessly replace tangible cards like insurance cards and loyalty cards, opening new avenues for users to access healthcare, discounts, event entrances, and more. By incentivizing sales through redemption of NFTs for existing or future benefits, businesses can efficiently align the interests of consumers and sellers alike, bidding adieu to traditional paper tokens. Couple this with the burgeoning metaverse, and the potential of utility NFTs heightens. They could emerge as the gatekeepers of exclusive experiences in a virtual, shared world, from game entrance tickets to access to other exclusive virtual environments. Utility NFTs, thus, hold the promise to establish ownership, foster community building, and contribute to environmental causes. The technology that backbones Utility NFTs is already here, and how we harness it will be determined by the limitations of our creativity. Bringing it all together The advent and evolution of Utility NFTs underline an exciting chapter in blockchain technology and digital ownership. They possess the potential to disrupt the way we perceive value, enabling programmable functions and features that provide tangible benefits to token holders. However, it’s important to note that the exploratory phase of Utility NFTs is still in its infancy and has a long way to go. Despite the remarkable progress and innovative use cases so far, the full potential of Utility NFTs and their widespread industry applications remain to be realized. With the world rapidly advancing towards decentralized and digital solutions, it would not be an exaggeration to say that Utility NFTs could serve as a major facilitator in this transition, potentially reshaping numerous sectors and experiences in the process. From health insurance cards to season tickets, from loyalty programs to exclusive virtual environments, the utility of NFTs is only limited by our imagination. But one thing is for sure—Utility NFTs are here to stay, and we are just at the beginning of understanding the vast and transformative potential they hold. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### How Whale Alert delivers blockchain alerts to 3M users with zero incidents Whale Alert monitors billions of blockchain transactions and delivers over 85,000 alerts to more than 3 million users across multiple blockchain networks. Running real-time analytics at this scale requires reliable infrastructure. After migrating their Polygon infrastructure to Chainstack, the team reduced incidents from weekly failures to zero. “Ever since we switched to Chainstack for Polygon, zero issues. We’ve gone from weekly incidents to zero incidents. And you actually know what the f*** you’re talking about — that’s really good.” — Frank S., Founder of Whale Alert Who is Whale Alert? Whale Alert is a blockchain analytics platform with a mission to become the Bloomberg Terminal for crypto. Founded in 2018 in the Netherlands, the platform focuses on bringing transparency to the crypto ecosystem by tracking large blockchain transactions across multiple networks and publishing real-time alerts and analytics. The platform aggregates on-chain signals across multiple blockchains — large transaction alerts, wallet activity, market sentiment metrics — and packages them into actionable intelligence for traders and investors. Its newest capabilities include real-time analytics such as SOPR metrics, realized profit data, and total transaction volumes for over 100 different assets: data that was previously only available to professional traders. Where most analytics platforms focus on a single chain like Ethereum or Bitcoin, Whale Alert’s differentiator is breadth. The team wants every meaningful on-chain signal, for every major blockchain, available in one place. If it’s a signal, if it can help someone make a trade, Whale Alert wants to surface it. That ambition created an infrastructure problem that would define the company’s early years. Main challenge: a jungle of node providers Building a cross-chain analytics platform means one thing above all else: you need reliable, accurate node access — across as many blockchains as possible, simultaneously. Whale Alert started, like many Web3 teams, by running their own nodes. A Bitcoin node. An Ethereum node. It didn’t take long to realize this path was unsustainable. “It’s just too expensive, and it takes up way too much of our time.” Self-managed nodes are a full-time engineering job. Configuration is complex, syncing issues are common, and costs scale fast. So the team turned to managed node providers — and discovered a different kind of problem. The node provider market is a jungle. Quality varies wildly. Chain coverage is fragmented. Pricing is all over the place — for some obscure chains, one provider quoted $4,000 per month. Whale Alert found themselves juggling Alchemy, GetBlock, Chainstack, ChainNodes, and others simultaneously, trying to stitch together coverage for a growing list of blockchains. The result was operational chaos: Unsynchronized nodes causing double transaction hashes and block reordering Corrupt trace data that broke their sanity checks Support teams who were slow, and often didn’t understand the underlying problems Polygon becoming a near-daily emergency — nodes out of sync meant corrupted database state, requiring Whale Alert to roll back a full week of data and re-ingest everything from scratch That last point deserves emphasis. Whale Alert runs rigorous sanity checks on every block — verifying transaction hash uniqueness, correct block ordering, and valid address balance histories. When their Polygon node provider failed those checks, the only fix was a database reset and hours of re-ingestion. This was happening almost every week. “We wanted one provider that does everything well — at the lowest possible cost, but also with the largest stability. We were fed up.” Why Chainstack? The decision to consolidate on Chainstack came down to three factors. Quality of support that actually solves problems: Most node providers have one strong engineer and a support team that relays messages back to them slowly. Chainstack’s support was different — fast, knowledgeable, and willing to dig into real technical issues alongside the Whale Alert team. Breadth of chain coverage: Chainstack’s catalog of supported networks aligned with Whale Alert’s multi-chain ambitions better than any single alternative. The best partnership offer: Whale Alert wasn’t just looking for a vendor — they were looking for a partner. After evaluating multiple providers, the conversation with Chainstack stood out. “You guys made the best offer. We had the best talk with you, so we decided — you know what, we’re going with Chainstack.” What changed after switching Whale Alert’s architecture means they pull blockchain data from node providers into their own database, run analysis on it, and generate alerts through their API. There’s no direct connection between their customers and Chainstack — but the quality of that upstream data flows through everything downstream. The impact of switching was immediate and measurable. Polygon: From weekly crises to zero incidents This is the headline result. Before Chainstack, Whale Alert’s Polygon integration triggered sanity check failures almost every week. Each failure meant: Identifying the corrupted data window Rolling the database back approximately one week Re-ingesting all of that data from scratch Hours of engineering time lost per incident Since migrating Polygon to Chainstack: zero incidents. Start building on Polygon with Chainstack → Centralized costs and better visibility Running four or five node providers simultaneously made it nearly impossible to track infrastructure spend. With Chainstack as the primary provider, costs became centralized and transparent — easier to monitor, easier to optimize. Operational calm Perhaps harder to quantify but equally valuable: the Whale Alert team stopped firefighting node issues and returned to building. Weekly incident response became a thing of the past. Results at a glance MetricBefore ChainstackAfter ChainstackPolygon data incidents~WeeklyZeroNode providers managed4–5 simultaneouslyConsolidatedDatabase reset frequencyMultiple times per monthNoneCost visibilityFragmented across vendorsCentralized What’s next Whale Alert is actively expanding their blockchain coverage and sees Chainstack as the natural partner for that growth. When Chainstack’s Tempo Mainnet went live, it highlighted an opportunity: launching support for a new chain in Whale Alert simultaneously with a Chainstack maixnnet launch, creating a joint go-to-market moment for both platforms. It’s a collaboration model the team is keen to build on. Bottom line For teams building multi-chain data infrastructure, the stakes around node reliability are high. Bad data doesn’t just mean a bad product — it means engineering time lost to incident response, database resets, and debugging problems that originate upstream. Whale Alert’s experience illustrates what the right node provider looks like in practice: stable data you can trust, support that understands your problems, and coverage broad enough to match your ambitions. If you need stable node access across multiple chains — and you actually need the data to be correct — that’s what Chainstack is for. More ways teams use Chainstack Trust Wallet increased ROI by up to 400% using a custom Chainstack gateway. CertiK slashed Ethereum archive costs by 70%+ while strengthening Web3 security. Nexo lowered Debug & Trace costs by 5X+ using Elastic Business data profiles. #### HyperEVM /evm vs /nanoreth: when to use each endpoint This guide covers the two HyperEVM JSON-RPC paths: /evm and /nanoreth what each one returns, why both exist, and exactly when to use each. TL;DR Every Chainstack Hyperliquid node exposes the same HyperEVM state over two paths: /evm is the standard path. It behaves like any Ethereum JSON-RPC. The correct choice for dApps, wallets, contract calls, and transaction submission. /nanoreth is the full-data path. It includes system transactions. The correct choice for indexers, block explorers, analytics pipelines, and trace-level debugging. Both paths are always active on the same node. Select per request by appending the path to the endpoint URL. Prerequisite Hyperliquid Architecture 📖 This guide will cover HyperEVM in detail. If you wish to learn in detail about Hyperliquid and it’s architecture, dive into Hyperliquid HIPS and Hyperliquid Architecture Why build on HyperEVM? HyperEVM is embedded inside a purpose-built L1 financial system. Smart contracts on HyperEVM can read live order book depth, oracle prices, perp positions, and vault balances through precompiles without any external price feeds. The HyperEVM is live. This is a major step toward the vision of housing all finance by bringing general-purpose programmability to Hyperliquid’s performant financial system. The initial mainnet release of the HyperEVM includes:1. HyperEVM blocks built as part of L1 execution,… pic.twitter.com/sleqk1N7T5— Hyper Foundation (@HyperFND) February 18, 2025 For developers, this means: no external oracle dependency for price data smart contracts that compose directly with live order book state a single consensus layer governing both trading execution and EVM finality familiar tooling: Foundry, Hardhat, ethers.js, viem all work without modification What is HyperEVM? Hyperliquid runs two execution environments under a shared HyperBFT consensus layer: HyperCore HyperCore is the native trading engine. It manages the on-chain Central Limit Order Book (CLOB), perpetuals execution, spot markets, margin logic, vault logic, and liquidations. Exposed via the /info and /exchange APIs. 🤔 For a detailed understanding of the /info and /exchange endpoints, refer to the Hyperliquid API blog. HyperEVM HyperEVM is EVM compatible execution layer, secured directly by HyperBFT consensus. It is a fork of the Cancun hardfork (without blobs) and supports EIP-1559. HYPE is the native gas token on HyperEVM. HYPE uses 18 decimals on both networks. HyperEVM runs two block types simultaneously on a shared, incrementing block number sequence. This dual-block architecture decouples block speed from block size allowing users to have faster confirmations and builders to have more compute for batch operations, complex contracts etc. Block typeDurationGas limitSmall blocks1 second2 millionBig blocks60 seconds30 million The initial configuration is set conservatively, and throughput is expected to increase over successive technical upgrades To use big blocks, submit: {"type": "evmUserModify", "usingBigBlocks": true} Because both layers share state, actions that happen in HyperCore can be reflected on the HyperEVM ledger. /evm The /evm path is the hl-node-compliant JSON-RPC interface. It speaks standard Ethereum JSON-RPC exactly as Ethereum tooling expects it. Any Ethereum library, pointed at this URL with chain ID 999 works without modification. Block responses only contain user-signed EVM transactions. Protocol-generated system transactions are stripped out before the response is returned. This is intentional, most EVM tooling has no handling for unsigned protocol entries, and dApps have no use for them. Chainstack exposes the /evm path with full standard Ethereum JSON-RPC method set available on Chainstack. For eg: fetch the latest block number to verify the connection is live. import requests url = "<https://hyperliquid-mainnet.core.chainstack.com/><KEY>/evm" payload = { "jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1 } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) 🤔 Deploying a contract? Use big blocks. Set evmUserModify: usingBigBlocks: true on the HyperCore account first. Big blocks allow 30M gas vs 2M on small blocks. See the Chainstack guide on forking HyperEVM with Foundry. /nanoreth Before moving to /nanoreth, system transactions need to be understood first. System transactions HyperCore and HyperEVM share state under one consensus layer. When HyperCore processes an action that has an EVM-side effect eg: a HYPE bridge from HyperCore to HyperEVM, a spot token transfer, a liquidation event, HyperBFT injects a synthetic record into the EVM block to reflect that state change on the EVM ledger. These records look like transactions in block data, but they are not user-initiated. No private key signed them. The protocol generated them. These are system transactions. System transactions always originate from one of these protocol-controlled addresses. Both appear frequently in full block data returned by /nanoreth. Bridge deposits: USDC or HYPE arriving from HyperCore into HyperEVM via the native transfer mechanism. The canonical native transfer address is 0x2222222222222222222222222222222222222222. Sending HYPE to this address moves it from HyperCore to HyperEVM Liquidation settlements: On-chain liquidation events from HyperCore reflected as EVM state changes Oracle writes: Price data and state written into HyperEVM from the L1 oracle layer Precompile-triggered writes: Initiated by smart contracts calling CoreWriter Below is a system transaction as returned by /nanoreth on block 0x202e371. { "hash": "0xd41d8cd98f00b204e9800998ecf8427e...", "from": "0x2222222222222222222222222222222222222222", "to": "0xUserAddress...", // HYPE recipient on EVM side "value": "0x16345785d8a0000", // 0.1 HYPE in wei "gasPrice": "0x0", // always zero, protocol-generated "gas": "0x0", // always zero "input": "0x", // no calldata "v": "0x0", "r": "0x0", "s": "0x0" // no ECDSA signature } With system transactions understood, /nanoreth makes immediate sense. It is the same JSON-RPC interface, on the same node, returning the same chain data with system transactions included in every block response. Nanoreth is a high-performance Rust-based archive node implementation derived from the reth Ethereum client, adapted for HyperEVM. It reads raw block data from Hyperliquid’s real-time S3 stream, the same authoritative source the protocol itself uses. This gives it two capabilities that /evm does not provide: complete block data including system transactions full historical state from genesis with trace method support Eg: Fetch the same block retrieved from /evm earlier, this time from /nanoreth. The transaction count in the response will be higher, system entries are now included. curl -X POST <https://hyperliquid-mainnet.core.chainstack.com/><KEY>/nanoreth \\ -H "Content-Type: application/json" \\ -d '{ "jsonrpc": "2.0", "method": "eth_getBlockByNumber", "params": ["0x202e371", true], "id": 1 }' # transactions array now includes system tx: { "number": "0x202e371", "transactions": [ { "hash": "0xabc...", "from": "0x1234...", "gasPrice": "0x3b9aca00" // user tx }, { "hash": "0xdef...", "from": "0x2222222222222222222222222222222222222222", "gasPrice": "0x0", // system tx — HYPE bridge deposit "v": "0x0", "r": "0x0", "s": "0x0" } // ... additional user txs ] } /evm vs /nanoreth The two paths share the vast majority of the standard Ethereum JSON-RPC method set, since they run on the same node against the same chain state. The differences come down to: System transactions are stripped from all block and receipt responses. Any method that returns block contents will silently omit system entries Querying a system transaction hash on /evm returns null Transaction submission is available on /evm only, /nanoreth is a read path /nanoreth adds ****a complete block data with system transactions included, plus the full trace and debug method suite (debug_traceTransaction, trace_block, trace_replayTransaction, etc.) /nanoreth also provides full historical state from genesis, making eth_call usable at any past block number System transactions always carry gasPrice: 0x0 Method/evm/nanoretheth_getBlockByNumber / eth_getBlockByHashtransactions array excludes system txtransactions array includes system txeth_getBlockTransactionCountByNumber / ByHashcount excludes system txcount includes system txeth_getBlockReceiptsreceipts array excludes system tx receiptreceipts array includes system tx receipteth_getTransactionReceipt for a system tx hashreturns nullreturns the receipteth_getTransactionByHash for a system tx hashreturns the transactionreturns the transactioneth_getSystemTxsByBlockNumber / ByHashreturns system txsreturns system txsdebug_* / trace_* / ots_* methodsunchangedunchangedAll non-system-tx methods (regular blocks, txs, receipts, traces)unchangedunchanged Refer to the Chainstack Hyperliquid Methods for a full endpoint and method availability matrix. WebSockets HyperEVM also exposes standard Ethereum WebSocket subscriptions. This is important because /evm and /nanoreth are not limited to HTTP JSON-RPC requests. Both paths support real-time subscriptions over WebSockets as well. Polling blocks repeatedly with eth_blockNumber or fetching receipts in loops introduces latency and unnecessary RPC overhead. For real-time applications such as dashboards, bots, explorers, and indexing systems, WebSockets are the correct approach. The WebSocket endpoint follows the same path distinction as HTTP: /evm : wss://hyperliquid-mainnet.core.chainstack.com/YOUR_KEY/evm /nanoreth : wss://hyperliquid-mainnet.core.chainstack.com/YOUR_KEY/nanoreth 📖 See the full method availability table on Chainstack docs for all websockets subscriptions. Hyperliquid Builder Tools Archive nodes and full historical data Nanoreth: Rust-based HyperEVM archive node implementation used for full historical indexing, tracing, and system transaction visibility. Dual Block Architecture: Official documentation explaining HyperEVM’s small-block and big-block execution model. Smart contract development These tools work against /evm exactly like Ethereum RPC infrastructure. Foundry: Smart contract development and deployment framework. Hardhat: Ethereum development environment fully compatible with HyperEVM. ethers.js: JavaScript Ethereum interaction library. viem: Type-safe TypeScript Ethereum interface. web3.py: Python Ethereum interaction library. Big Block Python SDK Example: Example showing how to enable big blocks for large deployments. Blogs and guides Hyperliquid API Guide: Guide covering /info, /exchange, and WebSocket APIs. Hyperliquid Architecture Explained: Deep dive into HyperCore, HyperBFT, and execution architecture. Hyperliquid HyperBFT Explained: Consensus and accounting internals. /evm vs /nanoreth: Hyperliquid node configurations Forking HyperEVM with Foundry: Guide for local HyperEVM development and testing. Hyperliquid Methods Reference: Full RPC method compatibility and availability table. Considerations Choosing between /evm and /nanoreth is mostly about understanding whether your application needs protocol-level visibility or standard wallet-facing behavior. Hash conventions: System transaction hashes differ between /evm and /nanoreth. If your system stores transaction hashes from one path and queries them on the other, lookups for system transactions will return null. Store the path alongside the hash, or normalize to one convention at ingestion time. Block transaction counts: eth_getBlockTransactionCountByNumber returns different values on each path for any block containing system transactions. If your protocol logic uses transaction count as a signal, ensure you query the same path consistently. Archive workloads on /nanoreth: /evm is optimized for application-facing workloads. Heavy historical workloads should use /nanoreth instead. This separation improves performance and avoids unnecessary protocol-level overhead for standard application traffic. Rate limits: The public RPC at rpc.hyperliquid.xyz/evm is rate-limited to 100 requests per minute per IP which is suitable for experimentation. At that limit, a simple polling loop at 1-second intervals will hit the ceiling within two minutes. Any bot, indexer, or analytics pipeline needs a private endpoint. Chainstack RPC infrastructure avoids rate-limit bottlenecks and provides more predictable latency. Key management: All execution depends on private key signing. Compromised keys mean full account exposure. Use dedicated API wallets, hardware security modules, or vaults for production systems. Conclusion HyperEVM gives you two paths on the same node for a reason: application traffic and infrastructure workloads have different requirements, and a single interface cannot serve both well. /evm keeps standard Ethereum tooling working without modification. /nanoreth keeps indexers, explorers, and analytics pipelines from operating on incomplete data. Both paths are available on every Chainstack Hyperliquid node, on the same endpoint, switchable per request. No separate connections, no additional configuration — append the path and you’re reading from whichever layer your application needs. Deploy a Hyperliquid node → FAQ What is the difference between /evm and /nanoreth on HyperEVM? Both paths expose the same chain state over standard Ethereum JSON-RPC. The difference is what block responses include. /evm strips system transactions before returning block data, so existing Ethereum tooling works without modification. /nanoreth includes system transactions in every block response, giving indexers and analytics pipelines complete visibility into protocol-generated state changes like bridge deposits and liquidation events. What are system transactions in HyperEVM? System transactions are protocol-generated records that HyperBFT injects into EVM blocks to reflect HyperCore state changes on the EVM ledger. They are not user-initiated — no private key signed them. They always carry gasPrice: 0x0 and empty ECDSA signature fields (v, r, s all zero). Common examples include HYPE bridge deposits from HyperCore to HyperEVM, liquidation settlements, and oracle price writes. Can I submit transactions through /nanoreth? No. /nanoreth is a read-only path. Transaction submission is only available on /evm. If your application needs to both send transactions and read full block data including system transactions, use /evm for writes and /nanoreth for reads. Do /evm and /nanoreth return different transaction counts for the same block? Yes, for any block that contains system transactions. eth_getBlockTransactionCountByNumber returns a lower count on /evm because system entries are excluded. If your application uses transaction count as a signal, query the same path consistently — mixing paths will produce inconsistent results. Can I use WebSockets with both paths? Yes. Both /evm and /nanoreth support real-time WebSocket subscriptions in addition to HTTP JSON-RPC. The endpoint structure follows the same path distinction: wss://…/YOUR_KEY/evm and wss://…/YOUR_KEY/nanoreth. For live applications — dashboards, bots, indexers — WebSockets are preferable to polling because they eliminate the latency and RPC overhead of repeated eth_blockNumber calls. Why do system transaction hashes differ between /evm and /nanoreth? System transactions exist in /nanoreth block data but are absent from /evm responses. When a system transaction hash is queried on /evm, the response is null. If your system stores transaction hashes from one path and queries them on the other, lookups for system transactions will silently fail. Store the path alongside the hash at ingestion time, or normalize to a single path convention before building any hash-based lookup. #### Hyperledger Global Forum 2020 Recap Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. This year, we released the first-ever managed services for Hyperledger Fabric 2.0 at the Hyperledger Global Forum alongside dozens of other exciting updates, demos, and news. Here are 3 announcements that we found the most interesting from across the 4 days so that you’re kept up to speed.  1. ConsenSys, Microsoft, and EY launches Baseline protocol to accelerate Enterprise adoption of Ethereum  The Baseline protocol is a series of tools that enables enterprises to deliver secure and private business processes via the public Ethereum Mainnet without storing sensitive data on-chain. Read the full announcement here.   2. ScanTrust, Unilever provide end-to-end meat traceability for over 30 million units of product Developed in partnership with Unilever, ScanTrust’s meat provenance use case has traced over 30 million units of Unilever’s Knorr soup since the project went live in July 2019. The solution utilizes patented copy-proof serialized codes on its packaging that can only be used once to trace data on its goods, and subsequently stores this data on blockchain to ensure tamperproofing. This has allowed Unilever to enhance consumer trust in its soup products. End-to-end pork traceability with Unilever session with ScanTrust 3. Large system integrators see their use cases moving to production Companies like everis NTT Data, Hitachi, and Accenture were all present at this year’s forum to report on the progress of their use cases since moving to production. These projects spanned across a variety of use cases globally, including supply chain and smart cities. everis NTT Data’s ongoing IoT+ Blockchain project Latest blockchain developments in blockchain adoption in APAC Panel with Hitachi Blockchain for smart cities session with Hitachi Accelerating blockchain for supply chain panel with Accenture, IBM, and Intel A crucial event for the industry Overall, we were incredibly impressed with this year’s event and would like to extend our deepest gratitude to the organizing team. The entire week was jam packed with updates of use cases already in production and important discussions pertaining to the future of Hyperledger. We are already looking forward to next years event. What were your key take-aways from this year’s Hyperledger Global Forum? Watch our demo session below or read our full launch announcement here. Hyperledger Fabric 2.0 in 5 clicks Demo with Chainstack Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Hyperliquid agent wallets and nonce state machine In Part 4, we built and signed a HIP-3 deployment action. We passed the action to the SDK, received a signature, and continued into the market lifecycle. That was enough for deployment. But it left the most important part of the authorization path hidden. The signing helper sits on the most fragile boundary in a Hyperliquid integration. An API wallet can sign without owning the funds. A sub-account can receive an order without having a private key. The vaultAddress is not an unsigned routing hint. A nonce is not simply the previous Ethereum nonce plus one. Even two Python dictionaries containing the same fields can produce different signatures. In this deep dive, we will strip away the helper and follow one order from a Python dictionary to Msgpack bytes, from those bytes to a Keccak hash, and from that hash to the EIP-712 signature HyperCore verifies. Along the way, we will make four things explicit: who actually signs an agent-wallet order which account the signed action is allowed to mutate why serialization is part of the security boundary how Hyperliquid’s nonce model supports concurrent trading without becoming replayable By the end, the signature will no longer look like a magic {r, s, v} object. It will be a concrete authority request whose exact bytes we can reproduce, mutate, recover, and test. The Signature Helper Is Hiding an Authority System Before looking at the bytes, we need to separate identities that are easy to collapse into the word “wallet.” Four addresses can participate in one order Master account: owns the funds and account configuration. Signing key: produces the signature. It can belong to the master or to an approved API wallet. Recovered signer: the address HyperCore derives from the signature and the payload it reconstructs. Target account: the user, sub-account, or vault whose state the action attempts to change. For an order signed directly by the master, these identities mostly collapse: master account = signing key = recovered signer = target account An API wallet separates custody from execution: master account | approves API wallet | API wallet signs an L1 action | HyperCore recovers the API-wallet address | authorization maps it back to the master A sub-account adds one more target: master account | approves API wallet | API wallet signs | vaultAddress selects the sub-account The official documentation uses API wallet and agent wallet for the same concept. The agent is a signer, not the account whose balances we query. Account-state queries still use the master or sub-account address. The API page makes that terminology explicit. Each row below is an approved agent: a name, a public signing address, an expiration time, and a control for revoking the authorization. If we query balances with the agent address, HyperCore usually returns an empty account. The agent holds authority, not the trading state. “Which wallet placed this order?” is not precise enough. We need to ask which key signed, which address was recovered, which master approved it, and which signed target received the action. Creating a key is not the same as approving an agent Generating a private key locally only gives us a key pair: agent = Account.create() print(agent.address) It does not create any authorization relationship inside HyperCore. The master must approve that address with an approveAgent action. After the approval is accepted, the agent can sign supported L1 actions for the master. The agent still does not become the owner of the account. The lifecycle is: generate a new key -> derive the agent address -> master signs approveAgent -> submit the authorization -> read the authorization back -> agent signs L1 actions -> rotate to another new key The frontend shows both sides of that boundary at once. Hyperliquid displays the generated API-wallet address, while the connected master wallet receives a typed-data signature request whose primary type is HyperliquidTransaction:ApproveAgent. The private key belongs only to the new agent and must be saved before authorization. It is redacted in the screenshot below. Now we can look at the two signatures involved in that flow. Hyperliquid Uses Two Signing Schemes Agent approval and agent execution are signed as different messages. The master authorizes an API wallet with the readable, user-signed HyperliquidTransaction:ApproveAgent EIP-712 message. Orders, cancels, and many other exchange operations then use the compressed L1 signing scheme. An L1 action follows this path: action dictionary | Msgpack action bytes + nonce + vault-address marker and optional address + optional expiration marker and timestamp | Keccak-256 connectionId | { source, connectionId } | EIP-712 { r, s, v } The small EIP-712 object at the end is called a phantom Agent. It is not the API-wallet authorization record. It is the typed envelope used to sign the hash of the L1 action. A Hyperliquid L1 signature does not authorize a JSON object. It authorizes one exact byte sequence. Setup once The examples use Python 3.11+ and version 0.24.0 of the official Python SDK: python3 -m venv .venv source .venv/bin/activate python -m pip install "hyperliquid-python-sdk==0.24.0" Each program below is complete. Save the code under the filename shown in its run command and execute it from the same folder. Complete example: sign and recover both messages The first program contains the whole path. It creates deterministic fixture keys, signs the master’s approveAgent message, signs an L1 order with the agent, and recovers both signers locally. The keys are deliberately public test fixtures. Never fund them. """Sign and recover two Hyperliquid messages without submitting anything. The private keys below are public deterministic fixtures. Never fund them. """ import copy import json from eth_account import Account from hyperliquid.utils.signing import ( action_hash, construct_phantom_agent, recover_agent_or_user_from_l1_action, recover_user_from_user_signed_action, sign_agent, sign_l1_action, ) MASTER_KEY = "0x" + "11" * 32 AGENT_KEY = "0x" + "22" * 32 NONCE = 1_900_000_000_000 APPROVE_AGENT_TYPES = [ {"name": "hyperliquidChain", "type": "string"}, {"name": "agentAddress", "type": "address"}, {"name": "agentName", "type": "string"}, {"name": "nonce", "type": "uint64"}, ] master = Account.from_key(MASTER_KEY) agent = Account.from_key(AGENT_KEY) # The master authorizes the agent with a user-signed EIP-712 action. approve_action = { "type": "approveAgent", "agentAddress": agent.address, "agentName": "part5-demo", "nonce": NONCE, } approve_signature = sign_agent(master, approve_action, is_mainnet=False) recovered_master = recover_user_from_user_signed_action( copy.deepcopy(approve_action), approve_signature, APPROVE_AGENT_TYPES, "HyperliquidTransaction:ApproveAgent", is_mainnet=False, ) # The agent signs an L1 order through the phantom Agent envelope. order_action = { "type": "order", "orders": [ { "a": 0, "b": True, "p": "100000", "s": "0.001", "r": False, "t": {"limit": {"tif": "Alo"}}, } ], "grouping": "na", } connection_id = action_hash( order_action, vault_address=None, nonce=NONCE, expires_after=None, ) phantom_agent = construct_phantom_agent(connection_id, is_mainnet=False) order_signature = sign_l1_action( agent, order_action, active_pool=None, nonce=NONCE, expires_after=None, is_mainnet=False, ) mainnet_signature = sign_l1_action( agent, order_action, active_pool=None, nonce=NONCE, expires_after=None, is_mainnet=True, ) recovered_agent = recover_agent_or_user_from_l1_action( order_action, order_signature, active_pool=None, nonce=NONCE, expires_after=None, is_mainnet=False, ) print( json.dumps( { "warning": "PUBLIC TEST KEYS — NEVER FUND", "approveAgent": { "master": master.address, "agent": agent.address, "recoveredSigner": recovered_master, "matchesMaster": recovered_master.lower() == master.address.lower(), }, "l1Order": { "connectionId": "0x" + connection_id.hex(), "phantomSource": phantom_agent["source"], "recoveredSigner": recovered_agent, "matchesAgent": recovered_agent.lower() == agent.address.lower(), "networkSignaturesDiffer": order_signature != mainnet_signature, }, "submitted": False, }, indent=2, ) ) Run it: python 01_sign_and_recover.py The output proves both authority transitions: matchesMaster: true means the approval recovers the master matchesAgent: true means the order recovers the agent phantomSource: "b" identifies the testnet L1 signing envelope networkSignaturesDiffer: true proves that changing the network source changes the signature submitted: false confirms that the program stayed offline The master did not sign the order. The agent did. HyperCore can recover that agent, look up its authorization, resolve the controlling master, and then validate the account targeted by the request. Signed Fields That Look Like Metadata The easiest signing bugs come from values that look unimportant to an application but are part of the signed preimage. The connection ID commits to four values: the exact Msgpack serialization of the action the eight-byte big-endian nonce the optional target address the optional expiration timestamp The next complete program changes one value at a time. Complete example: mutate the signed preimage """Show which values change a Hyperliquid L1 action's connection ID.""" import json from hyperliquid.utils.signing import action_hash NONCE = 1_900_000_000_000 SUBACCOUNT_ADDRESS = "0x" + "33" * 20 def order_action(size: str = "0.001") -> dict: return { "type": "order", "orders": [ { "a": 0, "b": True, "p": "100000", "s": size, "r": False, "t": {"limit": {"tif": "Alo"}}, } ], "grouping": "na", } def connection_id( action: dict, vault_address: str | None = None, expires_after: int | None = None, ) -> str: value = action_hash( action, vault_address=vault_address, nonce=NONCE, expires_after=expires_after, ) return "0x" + value.hex() canonical_action = order_action() reordered_action = { "grouping": canonical_action["grouping"], "orders": canonical_action["orders"], "type": canonical_action["type"], } results = { "canonical": connection_id(canonical_action), "withSubaccountTarget": connection_id( canonical_action, vault_address=SUBACCOUNT_ADDRESS, ), "withExpiresAfter": connection_id( canonical_action, expires_after=NONCE + 30_000, ), "differentFieldOrder": connection_id(reordered_action), "sizeString0.0010": connection_id(order_action(size="0.0010")), } print(json.dumps(results, indent=2)) print("allConnectionIdsDifferent =", len(set(results.values())) == len(results)) Run it: python 02_signed_preimage_mutations.py The final line is: allConnectionIdsDifferent = True Every mutation created a new commitment. Why each mutation matters The reordered dictionary contains the same key-value relationships as the canonical dictionary. But Msgpack serializes map entries in insertion order, so it produces different bytes. The same rule applies to decimal strings. "0.001" and "0.0010" may describe the same mathematical number, but they are different signed strings. This is why signing code should not pass an action through arbitrary JSON transformations. Sorting fields, removing trailing zeroes, inserting defaults, or converting strings to floating-point values can silently change the signature domain. The withSubaccountTarget result demonstrates that vaultAddress is not attached after signing. It is part of the commitment. An intermediary cannot redirect a valid master-account order to a sub-account or vault. The withExpiresAfter result proves that the optional expiration is also signed. The API documentation adds two practical constraints: user-signed actions such as a Core USDC transfer do not support expiresAfter a stale expiresAfter rejection consumes five times the usual address-based rate limit Expiration is a safety mechanism, but it is not a free cancellation mechanism. Mainnet and testnet behave slightly differently. The connection ID is unchanged, but the phantom-agent source changes from "b" on testnet to "a" on mainnet. The first complete program proved that the resulting signatures are different. Why local recovery can still mislead us Recovering the expected address locally is necessary, but it is not sufficient. If the recovery code repeats the same serialization bug as the signing code, both functions can agree with each other while disagreeing with HyperCore. HyperCore reconstructs the protocol payload independently. When it reconstructs different bytes, it can recover an unexpected address and return an error such as: L1 error: User or API Wallet 0x... does not exist. The address can change when the malformed input changes, making the error look random. The correct comparison is: our serialized bytes versus official SDK serialized bytes versus the action and metadata actually submitted Signer recovery tests the final cryptography. It does not prove that we signed the protocol’s intended message. Nonces Are a Concurrency Primitive Ethereum requires the next sequential transaction nonce for an address. That model is a poor fit for an order book where multiple workers may create orders and cancels concurrently. One delayed request should not block every later request from the same signer. Hyperliquid instead stores the 100 highest nonces per signer. A new nonce must: not have been used before be larger than the smallest nonce retained in the set fall inside the permitted window around the block timestamp The documented window is: (T - 2 days, T + 1 day) where T is the block’s Unix timestamp in milliseconds. This permits requests to arrive out of order while still preventing replay. But it moves the concurrency problem into the client. Every worker using the same private key shares one nonce set, even when the actions target different sub-accounts: agent key A -> master order agent key A -> sub-account order agent key A -> vault cancel all three consume nonces from agent key A The nonce belongs to the signer, not to the target account. Why a millisecond timestamp is not enough Using int(time.time() * 1000) directly fails when two workers sign during the same millisecond. The third standalone program gives six workers the same clock value. It first uses the timestamp directly and then repeats the experiment with a locked monotonic allocator. """Compare timestamp-only nonces with a locked monotonic allocator.""" import json import threading from concurrent.futures import ThreadPoolExecutor from dataclasses import dataclass, field from typing import Callable FIXED_TIME_MS = 1_900_000_000_000 WORKERS = 6 @dataclass class MonotonicNonceAllocator: clock_ms: Callable[[], int] _last: int = 0 _lock: threading.Lock = field(default_factory=threading.Lock) def next(self) -> int: with self._lock: now = self.clock_ms() self._last = max(now, self._last + 1) return self._last def fixed_clock() -> int: return FIXED_TIME_MS def run_workers(allocate: Callable[[], int]) -> list[int]: with ThreadPoolExecutor(max_workers=WORKERS) as executor: return list(executor.map(lambda _: allocate(), range(WORKERS))) unsafe = run_workers(fixed_clock) allocator = MonotonicNonceAllocator(fixed_clock) safe = run_workers(allocator.next) print( json.dumps( { "unsafeTimestampOnly": unsafe, "unsafeUniqueCount": len(set(unsafe)), "monotonicAllocatorSorted": sorted(safe), "safeUniqueCount": len(set(safe)), }, indent=2, ) ) Run it: python 03_nonce_allocator.py All six timestamp-only workers produced the same nonce, so unsafeUniqueCount is 1. The monotonic allocator produced six unique values even though every worker observed the same clock tick. For multiple processes or machines, an in-memory lock is not enough. We need one of three designs: a shared atomic counter a dedicated signing service a separate API wallet for each execution process The official documentation recommends using separate agent keys for separate processes. Because nonce state is tracked per signer, each agent becomes its own concurrency domain. The agent-pruning replay trap The most surprising rule appears during key rotation. An API wallet and its nonce state may be pruned when: the agent is deregistered the agent expires the account that registered it no longer has funds If the old nonce set is removed, previously consumed nonces may no longer be remembered. Re-registering the same agent address could make old signed actions replayable. Rotate an agent by generating a completely new private key. Never reactivate an old agent address. Key rotation is not only secret replacement. It is nonce-domain replacement. Where an AI Agent Belongs Once we separate intent from authority, the safe place for an AI agent becomes much clearer. A production system should not distribute an agent private key to every strategy process: market-data workers | strategy or AI agent | unsigned intent deterministic risk policy | validated Hyperliquid action signer + nonce allocator | signed payload submission worker | HyperCore | state reconciliation The AI layer may propose an intent: { "intent": "place_limit_order", "coin": "ETH", "side": "buy", "size": "0.01", "limitPrice": "1800", "timeInForce": "Alo" } It should not: hold the private key choose the final nonce build arbitrary signed bytes select an unrestricted target account submit actions that bypass deterministic checks The policy layer should validate the allowed action types, accounts, assets, order size, price deviation, reduceOnly requirements, expiration bounds, and network. Only then should the signing service construct the canonical action, allocate a nonce, and sign it. The model proposes intent. Deterministic code grants authority. This boundary does not make the strategy correct. It limits what a wrong, compromised, or hallucinating strategy is able to authorize. Summary Hyperliquid’s agent-wallet model separates custody from high-frequency execution. The master authorizes an agent through a readable user-signed action. The agent then signs compressed L1 actions without requiring the master wallet to approve every order. Sub-accounts and vaults remain keyless targets, selected through an address that is itself committed into the signature. That flexibility depends on exact serialization. Field order matters. Decimal-string representation matters. The target address matters. Expiration matters. The network source matters. Nonces belong to the signer rather than the target. Removing an agent can prune nonce history, which is why an old agent address must never be reused. The way we should think about that is not: Waller signs JSON It is: An exact byte sequence defines an authority request Once we can see and test that byte sequence, we can build the next layer safely: a production execution agent with WebSocket state reconciliation, deterministic risk checks, atomic nonces, idempotent client order IDs and order batching. The infrastructure side of that boundary The signing model in this article looks like a single-machine concern. The production system that uses it isn’t. The diagram earlier — market-data workers, strategy layer, deterministic risk policy, signer service, submission worker, state reconciliation — has infrastructure requirements at every layer: Market-data workers need WebSocket streams for fills, order-book snapshots, and user events. HTTP polling misses fills and accumulates stale position data — the exact conditions that turn a well-designed signer into a source of duplicate orders. Signer service and nonce allocator need private RPC with predictable latency. Two workers racing on the same signer key against a rate-limited public endpoint produce nonce collisions, not just retries. Submission worker needs stable connectivity because a submitted-but-not-acknowledged action forces the reconciliation layer to guess whether the order landed. Guessing wrong is how strategies produce duplicate positions. State reconciliation needs archive access for authoritative fill and position history — the source of truth when WebSocket streams reconnect. The public Hyperliquid endpoint is rate-limited to 100 requests per minute per IP. That is fine for signing tutorials and not close to fine for running any of the four layers above in production. Chainstack runs private Hyperliquid RPC endpoints that remove that ceiling. You get both HyperEVM paths (/evm for standard EVM traffic, /nanoreth when you need system transactions), plus /info and /exchange for the action flows this article walks through, WebSocket streams for the reconciliation layer, and archive access for fill history. Testnet nodes and a HYPE faucet are available for building and stress-testing the signer service before it touches mainnet funds. Spin up a Hyperliquid node in under one minute → FAQ Does an agent wallet hold any funds or account state? No. An agent wallet is a signing key with authority delegated by a master through an approveAgent action. If you query balances with the agent address, HyperCore usually returns an empty account. Funds, positions, sub-accounts, and account configuration all live on the master. The agent holds authorization to sign specific L1 action types on the master’s behalf — nothing else. Can I rotate an agent by re-registering the same address? No. Re-registering a previously deregistered agent address is unsafe. When an agent is deregistered, expires, or its registering account runs out of funds, HyperCore may prune the agent’s nonce state. If the old nonces are no longer remembered, previously consumed nonces become replayable. Always rotate by generating a completely new private key. An old agent address must never be reused. Why does reordering fields in an action dictionary change the signature? Because Hyperliquid signs the Msgpack serialization of the action, not the semantic content. Msgpack serializes map entries in insertion order. Two Python dictionaries with the same keys but different insertion order produce different bytes, different Keccak hashes, and different signatures. This is why signing code should not pass an action through arbitrary JSON transformations, sorting, or default-injection before signing. Can multiple workers share one agent wallet without nonce collisions? Within a single process, yes — with a locked monotonic allocator over int(time.time() * 1000). Across processes or machines, an in-memory lock isn’t enough. Two workers observing the same clock tick will produce identical nonces. The Hyperliquid documentation recommends a separate agent wallet per execution process; each agent becomes its own concurrency domain because nonce state is tracked per signer, not per master. What’s the difference between vaultAddress and the recovered signer? The recovered signer is derived from the signature — HyperCore recomputes the connectionId from the action bytes and recovers the address that signed it. vaultAddress is a separate field committed into the signed preimage that selects which account (master, sub-account, or vault) the action targets. An agent’s signature does not implicitly authorize its own sub-accounts; vaultAddress is signed, not attached after the fact, so an intermediary cannot redirect a valid order to a different target. Does expiresAfter give me a free way to cancel an order? No. expiresAfter is a safety mechanism, not a cancellation primitive. A stale expiresAfter rejection consumes five times the usual address-based rate limit, so relying on expiration to “cancel” orders will get your signer rate-limited fast. It also isn’t supported on all action types — user-signed actions like Core USDC transfers reject it. Use explicit cancel actions for cancellation and reserve expiresAfter for defense against replay of stale intent. Related reading The Hyperliquid series Part 1: Architecture, clearinghouse, agent keys, cross-margin Part 2: HyperBFT, sub-accounts, spot and perpetual accounting Part 3: HyperEVM precompiles and the CoreWriter bridge Part 4: HIP-3 builder-deployed perpetuals and the new trust boundary HIP context Hyperliquid HIPs explained: HIP-1 to HIP-4 Hyperliquid HIP-4 vs Polymarket: outcome markets in 2026 Practical infrastructure Hyperliquid API guide: endpoints, SDK, and WebSocket #### Hyperliquid API guide: endpoints, SDK, and WebSocket TL;DR Most Hyperliquid integrations break at the same point: polling the Info API where a WebSocket subscription belongs, or hitting the Exchange API directly without understanding the signing model. This guide covers all three interfaces — Info, Exchange, and WebSocket — so you pick the right one from the start. For developers, Hyperliquid exposes three main interfaces: Info API → read data (prices, order books, positions) Exchange API → signed trading actions WebSocket → real-time updates The typical workflow is simple: fetch market data → evaluate liquidity → sign using Python SDK and place an order → track it via WebSocket or polling. The system is fast (~500ms blocks) and supports high throughput, making it suitable for bots, dashboards, and execution systems. Why build on Hyperliquid? 📖 Want to start building right away? Jump to the “Hyperliquid API” section below. Unlike most exchanges that split execution across off-chain order books and on-chain settlement, Hyperliquid processes ~200,000 orders per second with ~500ms block times while running the entire trading lifecycle fully on-chain making execution, matching and settlement verifiable. That means a fully trustless environment where the order book lives on-chain enabling real price discovery with liquidity driven by active trading in complete transparency. 2/ What is Hyper Liquid? As traders ourselves, we were frustrated with existing platforms – we wanted something that combined the smooth and instant UX of CEXs while being fully decentralized, self-custodial, and safe. When we couldn’t find it, we set out to build it ourselves.— Hyperliquid (@HyperliquidX) November 10, 2022 It gets better. Because everything happens on-chain, users always stay in control of their funds. There’s no custody layer and no need to trust an exchange. Your keys, your funds. This removes the kind of counterparty risk seen in collapses like FTX. In practice, you get the speed and experience of a centralized exchange, but with full transparency and self-custody by default. For developers building on Hyperliquid, it becomes real simple: no need to sync off-chain + on-chain state no hidden matching logic same data source for everyone As of May 2026, Hyperliquid reached $4.31T in cumulative trading volume with $906.21M in platform revenue. The builder ecosystem grew to 10.56M users and $232.16B in combined builder volume. Source: https://hyperscreener.asxn.xyz This guide covers the full developer surface: what each endpoint does, how to call it in Python, how to stream data over WebSocket, and how to stay within rate limits. Hyperliquid is available on Chainstack offering both HyperEVM and HyperCore RPC access, with just a few clicks. Check out how to setup a Hyperliquid RPC node here: https://youtu.be/nvK9V2Jh2Dk How Hyperliquid API works: HyperCore, HyperEVM, and HyperBFT Hyperliquid has three core components at the protocol level: 1. HyperCore (Trading Engine) On-chain order book Matching engine Liquidation logic Every action placing an order, canceling or filling becomes part of on-chain state. 2. HyperEVM (Smart Contract Layer) HyperEVM is Hyperliquid’s native EVM-compatible execution environment. supports Ethereum-compatible smart contracts compatible with familiar Ethereum tooling shares the same state and consensus layer as HyperCore Applications built on HyperEVM can interact seamlessly with HyperCore, enabling users to launch tokens, build apps, and trade within a unified ecosystem. 3. HyperBFT (Consensus Layer) HyperBFT is the foundation of the Hyperliquid blockchain. variant of HotStuff consensus ~500ms block time single-block finality HyperBFT enables a distributed set of validators to agree on the global state of the network. This unified state includes all applications built on both HyperCore and HyperEVM. This is what enables high throughput (~200k orders/sec), fast confirmation and consistent global state. 📖 This guide will cover how to use Hyperliquid API. If you wish to learn in detail about Hyperliquid, dive into Hyperliquid HIPS and also refer Hyperliquid Architecture. Hyperliquid API Hyperliquid is a fully on-chain Central Limit Order Book (CLOB) DEX that operates on its own Layer-1 blockchain. This exposes 3 different endpoints that developers can access: Info: fetch information and read data Exchange: trading and managing orders WebSocket: real-time data streaming Hyperliquid also provides a testnet to safely test all integrations before moving to production. Hyperliquid Info API: how to query market data This is the primary data access layer. Instead of multiple REST endpoints like /markets, /orders, etc., Hyperliquid uses a single POST endpoint with typed queries. No authentication required. Endpoint: /info Params: type: 'meta' All on-chain state read from the chain flows through this one endpoint. The only thing that changes is the type field in the request. Fetch perpetuals metadata, including universe and margin tables using meta : import requests url = "<https://hyperliquid-mainnet.core.chainstack.com/><KEY>/info" payload = { "type": "meta", "dex": "" } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) Similar to meta, but for spot markets instead of perps. Use spotMeta : import requests url = "<https://hyperliquid-mainnet.core.chainstack.com/><KEY>/info" payload = { "type": "spotMeta" } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) l2Book returns the live order book for a given asset. import requests url = "<https://api.hyperliquid.xyz/info>" payload = { "type": "l2Book", "coin": "ETH" } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) It is important to note that this is only a snapshot. For real-time updates, switch to WebSockets ( see “WebsSockets” section below ) ⚠️ Some methods are only available on the public Hyperliquid infrastructure. If you wish to check all available types that can be requested, see all hyperliquid methods here. Hyperliquid Exchange API: how to place and manage orders This is the execution layer of Hyperliquid, everything that changes state flows through here. Placing orders, canceling them, updating leverage, or moving funds are all submitted to this endpoint and committed on-chain. Mainnet: https://api.hyperliquid.xyz/exchange Testnet: https://api.hyperliquid-testnet.xyz Unlike the info endpoint, interacting with the Exchange endpoint directly requires manual signing, payload encoding, and strict formatting. Authentication is handled entirely through cryptographic signatures. Hyperliquid provides an official Python SDK that already handles everything: build the requests payload signing submission to the exchange endpoint This allows focus on trading logic instead of low-level cryptography. Installation pip install hyperliquid-python-sdk At a high level, exchange actions fall into two categories. The SDK handles all the complex details of message formatting and signing depending on the action that needs to be performed. L1 Actions (trading ops) All trading operations use a phantom agent from the actions hash and signed locally using your private key on “Exchange” domain using Msgpack binary format. Chain ID: 1337 Actions order: place a single order cancel: cancel a single order by OID modify: modify an existing order updateLeverage: set the leverage for the asset, cross-margin or isolated ❓ The SDK’s sign_l1_action() utility handles all the actions. Developers do not need to interact with this signing method. If using SDK, the exchange class will handle the signing for you. For a complete list of L1 actions and detailed examples, refer to: https://docs.chainstack.com/docs/hyperliquid-l1-action-signing User Actions (admin ops) These are administrative actions that are not directly tied to the L1 order book state but manage funds and account state. They use direct EIP-712 signing on “HyperliquidSignTransaction” domain. Chain ID: 0x66eee (421614 in decimal) Actions usdSend: used to move USDC between Hyperliquid accounts internally spotSend: Initiates a withdrawal of USDC to an L1 wallet via the bridge. The SDK also provides these URLs in hyperliquid.utils.constants: from hyperliquid.utils import constants mainnet_url = constants.MAINNET_API_URL testnet_url = constants.TESTNET_API_URL It is recommended to start on testnet with small amounts. Actions signed for one network are not valid on the other. Always verify behavior on testnet before connecting production keys and real funds. Configure: The SDK reads credentials from a config.json file when using the example utilities. Copy the example file and edit it with your keys: First, copy the example configuration file: cp examples/config.json.example examples/config.json Now, open examples/config.json and edit it: { "secret_key": "YOUR_PRIVATE_KEY_HERE", "account_address": "YOUR_PUBLIC_ADDRESS_HERE" } secret_key: Your 64-character hexadecimal private key (prefixed with 0x). This can be the key for your main wallet or a dedicated API wallet. account_address: The public address of your main Hyperliquid account. This is required, especially if you are using an API wallet’s secret_key. At this point, the client is ready to send signed transactions via the exchange endpoint with any action. All interactions follow a consistent structure: { "action": { ... }, "nonce": <timestamp>, "signature": { ... } } action : defines what operation to perform (place order, cancel, etc.) nonce : prevents replay attacks (current timestamp) signature : proves ownership of the wallet initiating the action Each request modifies on-chain state and is processed by the matching engine. Place an Order using/exchange endpoint The order action places a single limit order. The order field keys in the raw payload use short names to minimize payload size. import requests url = "<https://api.hyperliquid.xyz/exchange>" payload = { "action": { "type": "order", "orders": [ { "a": 0, "b": True, "p": "50000.0", "s": "0.01", "r": False, "t": { "limit": { "tif": "Gtc" } } } ], "grouping": "na" }, "nonce": 1705234567890, "signature": { "r": "0x0000000000000000000000000000000000000000000000000000000000000000", "s": "0x0000000000000000000000000000000000000000000000000000000000000000", "v": 27 }, "vaultAddress": None } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) KeyFull nameDescriptionaassetAsset index from meta responsebisBuytrue = buy, false = sellppriceLimit price as a decimal stringssizeOrder size in base assetrreduceOnlyIf true, order only reduces an open positionttypeOrder type: limit with tif, or triggerccloidOptional client-assigned order ID (128-bit hex) Withdraw using/exchange endpoint Withdraw USDC to an L1 wallet via the bridge. This is a User Action, signed with direct EIP-712 on the “HyperliquidSignTransaction” domain, distinct from L1 Actions. The SDK handles the difference automatically. After making this request, L1 validators sign and send the withdrawal to the bridge contract. Withdrawals typically complete in approximately 5 minutes. import requests url = "<https://api.hyperliquid.xyz/exchange>" payload = { "action": { "type": "withdraw3", "hyperliquidChain": "Mainnet", "signatureChainId": "0xa4b1", "destination": "0x1234567890abcdef1234567890abcdef12345678", "amount": "500.0", "time": 1705234567890 }, "nonce": 1705234567890, "signature": { "r": "0x0000000000000000000000000000000000000000000000000000000000000000", "s": "0x0000000000000000000000000000000000000000000000000000000000000000", "v": 27 }, "vaultAddress": None } headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) print(response.text) Alternatively, if using Python SDK: # Withdraw 100 USDC to an L1 wallet address result = exchange.withdraw_from_bridge("100", "0xDestinationAddress") print(result) 🤔 For more complete, end-to-end SDK examples, refer to: https://github.com/hyperliquid-dex/hyperliquid-python-sdk/tree/master/examples Hyperliquid WebSocket API: real-time data streaming Polling /info repeatedly introduces latency and inefficiency. By the time data is fetched and processed, market state may already be outdated. For any system beyond simple scripts: trading bots, dashboards, execution engines, WebSockets are essential. They stream updates continuously as new blocks are produced (~500ms). Mainnet: wss://api.hyperliquid.xyz/ws Testnet: wss://api.hyperliquid-testnet.xyz/ws WebSockets follow a simple subscribe → stream pattern: Open a connection Send a subscription request Receive continuous updates All messages are JSON-based and event-driven. Example usage to subscribes to BTC order book updates: import asyncio import json import websockets WS_URL = "wss://api.hyperliquid.xyz/ws" async def main(): async with websockets.connect(WS_URL) as ws: # subscribe to BTC trades await ws.send(json.dumps({ "method": "subscribe", "subscription": { "type": "l2Book", "coin": "BTC" } })) while True: msg = await ws.recv() data = json.loads(msg) print(data) asyncio.run(main()) For the full list of websockets feeds: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions The server closes connections that are idle for 60 seconds. Send a ping message every 20 seconds: { "method": "ping" } Server response: { "channel": "pong" } Full heartbeat behavior: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/timeouts-and-heartbeats Hyperliquid Python SDK and developer tools Official SDK Official Python SDK: Core SDK for interacting with Hyperliquid, including trading, market data, and account management. SDK documentation: Guides, examples, and full API reference for the Python SDK. Community SDKs nktkas/hyperliquid: Lightweight TypeScript SDK for trading and market data. nomeida/hyperliquid: TypeScript client focused on usability and broad API coverage. infinitefield/hypersdk: Rust SDK optimized for high-performance trading systems. CCXT: Multi-language trading library supporting Hyperliquid (Python, JavaScript, PHP). CCXT Hyperliquid Python: Dedicated Python wrapper for CCXT’s Hyperliquid integration. Analytics and Infrastructure HyperEVM Explorer: On-chain explorer for tracking Hyperliquid activity. DeFiLlama – Hyperliquid: Analytics for TVL, volume, and protocol metrics. Status Page: System status, uptime, and incident monitoring. Core Documentation Primary API Docs: Full API overview for developers. Info Endpoint: Reference for market and account data queries. Exchange Endpoint: Trading and order execution API reference. WebSocket API: Real-time data streaming via WebSockets. Rate Limits: API usage limits and constraints. Production considerations Before building on Hyperliquid, account for the following: Leverage Risk: Trading perpetuals involves leverage and volatility. Losses can exceed expectations if positions are not managed properly. Market Risk: Order book systems can be influenced by manipulation strategies: Spoofing, placing fake orders to mislead participants Frontrunning, trading ahead of visible order flow Latency Sensitivity: Although fast (~500ms blocks), performance depends heavily on: Server location (recommended: us-east-1) WebSocket reliability Network conditions Rate Limits: Two systems: IP-based limits (REST usage) Address-based limits (trading actions) Improper design can throttle your system. On-Chain Constraints: Even with high throughput: Block timing still matters Execution is deterministic Failed transactions are possible Key Management: All execution depends on private key signing: Compromise = full account risk Use secure key storage (HSM, vaults) Liquidity Fragmentation: Not all markets have equal depth: Smaller pairs may have thin books Slippage can be significant Conclusion Hyperliquid represents a shift in exchange design: a fully on-chain order book with performance approaching centralized systems. By combining high throughput, low latency, and deterministic execution, it creates a new category of infrastructure for trading applications. For developers, the platform is cleanly structured: Info API for data Exchange API for execution WebSocket for real-time systems The barrier to entry is low, with no API keys, standard EVM wallets, and simple SDKs, but the ceiling is high. You can build anything from lightweight dashboards to high-frequency trading systems on top of the same primitives. The ecosystem is still early. Most advanced tooling such as analytics layers, strategy engines, and automation frameworks remains underbuilt. That leaves a wide surface area for developers to explore. The order book is on-chain. Getting started with Hyperliquid on Chainstack The public Hyperliquid endpoints work for experimentation, but production trading systems need something more reliable. Chainstack runs fully synced, managed Hyperliquid nodes — both mainnet and testnet — with private HTTPS and WebSocket RPC URLs, 99.9%+ uptime SLA, and global infrastructure optimized for low latency. You get dedicated access to both HyperCore and HyperEVM from one endpoint, without the overhead of running your own node or competing for throughput on a shared public API. Deploy a Hyperliquid node on Chainstack → FAQ What is the Hyperliquid Info API? The Info API is Hyperliquid’s read-only data layer. It’s a single POST /info endpoint where the type field determines what you get — market metadata, order books, account positions, funding rates, and more. No authentication required. How do I authenticate with the Hyperliquid Exchange API? There are no API keys. Authentication is handled entirely through cryptographic signatures. L1 trading actions (orders, cancels) are signed with your private key on the “Exchange” domain using Msgpack. Administrative actions (withdrawals, transfers) use EIP-712 signing. The official Python SDK handles both automatically. What is the difference between HyperCore and HyperEVM? HyperCore is the trading engine — it runs the on-chain order book, matching engine, and liquidation logic. HyperEVM is the Ethereum-compatible execution layer where you deploy Solidity smart contracts. Both run under the same HyperBFT consensus and share the same state. Does Hyperliquid have rate limits? Yes, two separate systems. IP-based limits apply to REST requests via the Info API. Address-based limits apply to trading actions through the Exchange API. The thresholds are documented in the official rate limits reference. How do I connect to the Hyperliquid WebSocket API? Connect to wss://api.hyperliquid.xyz/ws (mainnet) or wss://api.hyperliquid-testnet.xyz/ws (testnet). Send a JSON subscription message with a method: "subscribe" field and your chosen feed type. Send a {"method": "ping"} every 20 seconds to keep the connection alive — the server closes idle connections after 60 seconds. Can I use the Hyperliquid Python SDK on testnet? Yes. The SDK exposes constants.TESTNET_API_URL for testnet. Actions signed for mainnet are not valid on testnet and vice versa. Always test on testnet with small amounts before connecting production keys. Additional resources Hyperliquid architecture deep-dive Hyperliquid HIPs explained Trading bot starter repo How to get a Hyperliquid RPC endpoint Best Hyperliquid RPC providers in 2026 #### Hyperliquid architecture: Clearinghouse and Agent Keys If you’ve been following my recent series on EVM storage slots and the granular mechanics of Solana’s Token-2022 extensions, you know that optimizing smart contract architecture is ultimately an endless battle against the underlying execution environment. Whether we are writing Solidity, Vyper, or Rust, we spend our careers trying to squeeze maximum performance out of systems designed to do a million different things. But what if you didn’t have to compromise? What if, instead of fighting the virtual machine, you built a Layer 1 blockchain from the ground up to do exactly one thing perfectly? This is the premise of Hyperliquid. In Part 1 of this new series, we are going to step away from generic execution environments and zoom out to look at the macro-architecture of an App-Chain. Specifically: the Clearinghouse as a unified state tree, Hyperliquid Agent Keys and how they enable bot trading without MetaMask, and native cross-margin across spot and perpetual positions. The L1 dilemma: why build a sovereign chain? To understand what Hyperliquid is, we have to look at the specific engineering problem it was built to solve: creating a fully on-chain Central Limit Order Book (CLOB) that can mathematically rival the latency of centralized exchanges. When protocol engineers attempt to build high-frequency trading engines on existing blockchains, they inevitably hit a wall at the state-transition layer. The Ethereum & Rollup Bottleneck The EVM is a global, sequential state machine. Every transaction must be processed one after the other. More importantly, general-purpose VMs carry a massive “latency tax” because they must dynamically meter gas for every computation. When a user places an order on a generic rollup, the VM must load the contract, parse the calldata, execute generic opcodes, and write to the state trie. For a market maker trying to update their quotes 1,000 times a second to avoid arbitrage, dynamically metering generic bytecode is incredibly inefficient. The Solana Bottleneck Solana seemingly solves the sequential problem via the Sealevel parallel runtime. By requiring transactions to declare their read/write accounts upfront, the SVM can process non-overlapping transactions simultaneously. However, an order book inherently requires shared state. If a thousand users are trading the SOL/USDC pair, they must all mutate the exact same market account (the PDA). Because they are fighting over the same data structure in memory, this creates state contention. The parallelization engine degrades into a single-lane highway, hard-capping the maximum theoretical throughput for that specific market and forcing sequential execution anyway. The App-Chain Solution Hyperliquid was invented because the founders realized a fundamental architectural truth: To achieve sub-millisecond finality and handle 100,000+ orders per second, the order book cannot live inside a smart contract. The order book must BE the blockchain. The dual-engine architecture: HyperCore & HyperEVM Hyperliquid solves the app-chain composability problem with a dual-engine architecture: HyperCore, a closed state machine handling all order book operations natively in memory, and HyperEVM, a full EVM environment where Solidity contracts can read HyperCore state in real time via precompiles — no bridge, no oracle lag. Both engines share the same block space and consensus layer, HyperBFT. For a full breakdown of this architecture, see What is Hyperliquid? — this article picks up from there. The Сlearinghouse: unified state & native cross-margin If HyperCore is the engine, the Clearinghouse is the database. In traditional finance, a clearinghouse is a centralized entity that sits between buyers and sellers to guarantee trades, manage margin requirements, and execute liquidations. In traditional DeFi, this role is awkwardly duct-taped together using fragmented smart contracts. Let’s look at the generic VM approach to margin: If you want to trade Spot and Perps on an Ethereum rollup, you are dealing with entirely separate state islands. Your Spot assets sit in a Uniswap liquidity pool or your wallet. Your Perp margin sits inside a specific vault contract. If you own 1 Spot BTC and want to use it as collateral to short ETH, you have to execute multiple transactions: borrow USDC against your BTC on some platform, bridge it to a perp DEX, and deposit it into their margin contract. This state fragmentation leads to massive capital inefficiency and smart contract risk. The Hyperliquid solution: The L1 as the Clearinghouse In Hyperliquid, the Clearinghouse isn’t a smart contract, it is the fundamental state tree of the HyperCore L1. Because the developers control the actual execution client, they built a unified data structure that natively understands a user’s portfolio as a single, global entity. To see exactly how this unified state is managed, we can look at the data structures required to deserialize the L1’s clearinghouseState via the API. Here is the actual Rust representation of a user’s Clearinghouse state, as seen in standard Hyperliquid SDKs: use serde::{Deserialize, Serialize}; // The root state object returned by the L1 Clearinghouse #[derive(Serialize, Deserialize, Debug)] pub struct ClearinghouseState { #[serde(rename = "marginSummary")] pub margin_summary: MarginSummary, #[serde(rename = "crossMarginSummary")] pub cross_margin_summary: MarginSummary, #[serde(rename = "crossMaintenanceMarginUsed")] pub cross_maintenance_margin_used: String, pub withdrawable: String, // The unified array of all active market positions #[serde(rename = "assetPositions")] pub asset_positions: Vec<AssetPosition>, pub time: u64, } // Global risk parameters calculated natively in memory by the node #[derive(Serialize, Deserialize, Debug)] pub struct MarginSummary { #[serde(rename = "accountValue")] pub account_value: String, // Total portfolio value (Spot + Perp PnL) #[serde(rename = "totalNtlPos")] pub total_ntl_pos: String, // Total notional position size #[serde(rename = "totalRawUsd")] pub total_raw_usd: String, // Raw USDC balance #[serde(rename = "totalMarginUsed")] pub total_margin_used: String, // Aggregate margin locked } // An individual position object within the state #[derive(Serialize, Deserialize, Debug)] pub struct AssetPosition { pub position: Position, #[serde(rename = "type")] pub position_type: String, } #[derive(Serialize, Deserialize, Debug)] pub struct Position { pub coin: String, // Asset ticker (e.g., "BTC") pub szi: String, // Size of the position pub leverage: Leverage, #[serde(rename = "entryPx")] pub entry_px: String, // Entry Price #[serde(rename = "positionValue")] pub position_value: String, #[serde(rename = "unrealizedPnl")] pub unrealized_pnl: String, #[serde(rename = "marginUsed")] pub margin_used: String, } #[derive(Serialize, Deserialize, Debug)] pub struct Leverage { #[serde(rename = "type")] pub leverage_type: String, pub value: u32, } Notice the critical architectural difference here: the MarginSummary fields (account_value, total_margin_used) are pre-calculated at the root level of the struct. The developer doesn’t have to write a smart contract to aggregate a user’s collateral across a dozen fragmented liquidity pools. The L1 execution client does the heavy lifting natively on every tick. Protocol-Level Cross Margin & Portfolio Abstraction This unified architecture unlocks true, protocol-level cross-margin. Through Hyperliquid’s Portfolio Margin account abstraction, the L1 state machine unifies your spot holdings and perpetual positions into a single global balance. If you bridge USDC to Hyperliquid and buy 1 Spot BTC, the L1 immediately recognizes that asset’s USD value. How Hyperliquid Agent Keys let bots trade without MetaMask When you build a sovereign App-Chain, you usually introduce a massive point of friction: the wallet. Historically, if you wanted to trade on other chains, you had to download a new proprietary wallet extension, manage a new seed phrase, and learn a completely new address format. Hyperliquid bypassed this UX nightmare entirely. Your primary account on Hyperliquid is simply your standard Ethereum address. But how does a non-EVM execution layer securely verify transactions signed by an Ethereum wallet? And more importantly, how do you solve the high-frequency trading problem, because you certainly cannot click “Sign” in MetaMask a thousand times a second. The answer lies in two brilliant architectural choices: EIP-712 Native Integration and the Agent Key Architecture. The L1 wallet (EIP-712 signatures) Hyperliquid’s L1 natively understands the secp256k1 elliptic curve used by Ethereum. When you interact with the exchange via MetaMask, you aren’t broadcasting a standard Layer 1 Ethereum transaction. Instead, you are signing a structured data payload using the EIP-712 standard. The HyperCore validator nodes are explicitly programmed to take these EIP-712 signatures, recover the Ethereum public address of the signer, and authenticate the L1 state mutation (like bridging funds or withdrawing). This EIP-712 address acts as your Root Authority Key. While it delegates trading permissions to temporary Agent Keys (explained shortly) , the HyperCore L1 strictly requires signatures from this Main Wallet for any critical state mutations, such as withdrawing funds or transferring assets, effectively acting as the secure vault for your underlying capital. 📖 Wallet overview and all the possible actions can be found here. Agent Keys Using EIP-712 is great for deposits and withdrawals, but it creates a fatal bottleneck for trading. If a bot needs to execute a complex grid-trading strategy, waiting for a user to manually approve a signature prompt for every single order is impossible. Hyperliquid solves this by allowing users to delegate strict, scoped permissions to a secondary, localized keypair known as an Agent Key. Here is how the architecture works: Key Generation: Your bot (or the web UI) generates a fresh, random cryptographic private/public key pair locally in memory. This is the Agent. The Delegation Action: Your Main L1 Wallet (via MetaMask) signs a specific L1 Action called ApproveAgent. This payload tells the HyperCore state machine: “I authorize this new Agent public key to execute trades on my behalf.” Local Signing: From that point on, your bot uses the Agent’s private key to sign the actual buy and sell orders locally in microseconds, entirely bypassing MetaMask. Here is what the raw ApproveAgent action payload looks like when sent to the L1 (Image attached above): { "action": { "type": "approveAgent", "hyperliquidChain": "Mainnet", "signatureChainId": "0xa4b1", // Arbitrum One "agentAddress": "0xYourGeneratedAgentPublicKey...", "agentName": "0xByteBeetle_GridBot_v1" }, "nonce": 1713563456000, "signature": "0xSignatureFromMainL1Wallet..." } Example: you can find here the option to generate wallet agent. Example of message signing: Shows the EIP-712 signature The security boundary The genius of the Agent Key architecture is its scoped authority. When the HyperCore L1 receives an order signed by an Agent, it checks the state machine to verify that the Main Wallet delegated authority to it. If verified, the order is executed. However, Agents are mathematically restricted to trading. If a hacker manages to steal your bot’s Agent private key from your server, the worst they can do is place bad trades. They cannot withdraw your USDC, transfer your spot assets, or change your account settings (Take a look at the note under the API in the first image). The L1 state machine will strictly reject any withdrawal Action signed by an Agent Key. those critical state mutations require a signature directly from the Main L1 Wallet. Summary By decoupling the trading engine from a generic VM and baking it directly into the state machine, Hyperliquid solves the latency and state contention problems at the root architectural level. Furthermore, by heavily utilizing EIP-712 and Agent Keys, it manages to provide the blazing speed of a centralized exchange without sacrificing the self-custody and familiar UX of the EVM ecosystem. We have fundamentally shifted from thinking about smart contract optimizations to thinking about protocol-level memory management and native API actions. On Chainstack, you can deploy private Hyperliquid endpoints in minutes — fully synced, monitored, and backed by a 99.9% uptime SLA — so you can focus on building, not on infrastructure. Deploy a Hyperliquid node on Chainstack → FAQ What is HyperCore in Hyperliquid? HyperCore is the native trading layer of the Hyperliquid L1 — a purpose-built state machine baked directly into the validator software. It handles order placement, spot transfers, collateral management, and liquidations entirely in memory, enabling 200,000+ orders per second without metering arbitrary bytecode. What is HyperEVM? HyperEVM is the Ethereum-compatible execution layer running alongside HyperCore on the same consensus. Developers deploy standard Solidity contracts here using ethers.js, Foundry, or Hardhat. Unlike other EVM chains, HyperEVM contracts can read HyperCore state — prices, positions, margin — in real time via precompiles, without external oracles. What is the Hyperliquid Clearinghouse? The Clearinghouse is the unified state tree of HyperCore. It manages every user’s spot holdings and perpetual positions as a single global entity, enabling native cross-margin without bridging or multiple transactions. What are Agent Keys on Hyperliquid? Agent Keys are scoped keypairs that your main Ethereum wallet delegates trading permissions to via a single ApproveAgent action. The Agent Key can place and cancel orders locally in microseconds — but cannot withdraw funds or change account settings. Those actions always require the main wallet signature. How does EIP-712 work on Hyperliquid? Hyperliquid’s L1 natively understands Ethereum’s secp256k1 curve. When you interact with the exchange, you sign structured data using EIP-712. Validators recover your Ethereum address from the signature and authenticate the state mutation — so any standard Ethereum wallet works as your root authority key with no chain-specific setup. What is HyperBFT? HyperBFT is Hyperliquid’s custom consensus mechanism that secures both HyperCore and HyperEVM simultaneously. It provides Byzantine Fault Tolerance optimized for low-latency order book operations, enabling sub-second finality across the entire chain. Related Reading What is Hyperliquid? RPC, API, and trading infrastructure How to build a Hyperliquid trading bot How to build a Hyperliquid on-chain activity tracker Best Hyperliquid RPC providers in 2026 Most cost-effective Hyperliquid RPC providers in 2026 Mastering Hyperliquid — full guide series #### Hyperliquid HIP-3: builder-deployed perpetuals In Part 1, we established the architectural thesis behind Hyperliquid. A fully onchain order book cannot behave like a centralized exchange if every order, cancel, and liquidation has to pass through a generic virtual machine. In Part 2, we went inside HyperCore. We traced HyperBFT finality, spot and perpetual accounting, sub-accounts, and the lifecycle of a trade from signed action to L1 state transition. In Part 3, we crossed the boundary between HyperEVM and HyperCore. Precompiles gave Solidity a native read path into exchange state. CoreWriter gave contracts a constrained write path back into the financial state machine. Now we reach the next architectural question. Who decides which markets that financial state machine should run? Historically, the answer was the core protocol team. HIP-3 changes that. A builder who satisfies the deployment requirements can create a separate perpetual DEX inside HyperCore, define markets, update their oracles, choose margin parameters, cap open interest, and eventually halt or settle trading. The matching engine is still HyperCore. The orders are still HyperCore actions. The balances and positions are still native L1 state. But the meaning and operation of a market can now come from an external deployer. HIP-3 leaves the clearinghouse in place while introducing a new trust boundary inside it. A Market Is More Than a Ticker It is tempting to describe HIP-3 as permissionless listings. That description captures the direction of the design, but it hides both the protocol gates and the state being created. A deployer still has to satisfy the current staking and deployment requirements. More importantly, deployment does not add a token symbol to a frontend menu. It creates a new perpetual market inside HyperCore. A perpetual contract gives traders long or short price exposure without a fixed expiration date. Unlike a dated futures contract, it does not automatically settle on a predetermined day. A position can remain open while the trader satisfies the market’s margin requirements. Funding payments help manage persistent differences between the perpetual price and its reference price. If the trader’s collateral can no longer support the position, HyperCore can liquidate it. The underlying does not have to be a cryptocurrency. For example, CRDO is the stock ticker associated with Credo Technology, a company that provides high-speed connectivity products for data centers and network infrastructure. The live annotation for para:CRDO (will be explained below) says that the market tracks the value of one Credo share. A para:CRDO position does not provide equity ownership, voting rights, custody of shares, or direct access to the underlying company. It is a collateralized perpetual derivative. Its profit and loss depend on the market’s price process, position size, funding, and margin state. This is what makes the full market name important. The market identifier is not simply CRDO. It is para: CRDO. The para prefix identifies the builder-deployed DEX. CRDO identifies an asset registered inside that DEX (read more here). Another deployer could register the same short symbol inside a different namespace and create a separate market with a different asset ID, oracle process, order book, margin configuration, and lifecycle. The full {dex}:{coin} name is therefore part of the market’s identity. That identity connects four layers of state: Market definition: the DEX namespace, collateral token, asset annotation, oracle updater, and size precision. Price formation: the oracle price, optional mark inputs, local order-book state, update timing, and mark-price constraints. Risk configuration: the margin table, margin mode, leverage boundaries, and open-interest caps. Economic lifecycle: funding inputs, fees, halting, and final settlement. HIP-3 gives the deployer authority over important inputs in those layers. It does not give the deployer a separate matching engine or independent accounting system. Orders still enter HyperCore. HyperCore still maintains the order book, matches trades, records positions, applies margin accounting, performs liquidations, enforces protocol constraints, and processes settlement actions. The deployer supplies the market-specific configuration and operates the price process that gives the contract its economic meaning. This creates two distinct trust domains. You trust HyperCore to execute the configured rules consistently. You also trust the deployer and oracle updater to define a coherent market, submit defensible prices, select appropriate risk limits, and halt or settle the market responsibly. That is the architectural change introduced by HIP-3. Market execution remains shared inside HyperCore, but market definition and part of the operational control plane move to the builder. The right question is no longer only: “Does Hyperliquid run this market?” The better question is: “What does this perpetual contract represent, which properties does HyperCore enforce, and which inputs does this deployer control?” The HIP-3 Deployment Lifecycle A HIP-3 market does not become operational through one permanent listing call. Deployment is a gated state machine. The builder must qualify to deploy, inspect the current auction, register the DEX and its first market, verify the resulting state, configure market-specific controls, and then operate the oracle for as long as the market remains live. The lifecycle is easier to reason about as a sequence of protocol states: satisfy the current stake requirement → inspect the deployment auction → submit registerAsset2 with the DEX schema and initial asset → verify the DEX namespace and market metadata → configure margin, funding, fees, and open-interest controls → maintain oracle and mark inputs → monitor deposits, limits, and market state → halt and settle the market when required The hands-on section later in this article implements the read, construct, sign, submit, and verify boundaries separately so students can inspect every transition before it mutates testnet state. Step 1: satisfy the current staking requirement The current HIP-3 specification states that a mainnet deployer must maintain 500,000 staked HYPE. It currently says that the staking requirement is maintained for a minimum of 183 days after the DEX is deployed. The settlement section separately says that once all assets are settled, the deployer’s required stake is free to be unstaked. The documentation does not explicitly explain how an early settlement interacts with the 183-day minimum. These are versioned protocol requirements, so a deployment tool should display the current requirement and link to the specification immediately before the action rather than silently hardcoding it. Step 2: inspect the deployment auction DEX creation is rate-limited through the perpetual deployment auction. Under the current rules, the first three assets in a deployed DEX do not require separate asset-auction participation. Later assets enter a Dutch auction shared across all builder-deployed perpetual DEXs. The registerAsset2 documentation adds another path. A deployer currently receives seven reserve deployments. Setting maxGas to zero consumes one reserve deployment at the current auction price, even if the auction has not ended. The documentation therefore warns builders to query the auction before signing. maxGas=0 is not a harmless default. Under the current action reference it consumes a reserve deployment at the current auction price. The testnet script later in this article refuses zero and queries the auction before signing. The official SDK exposes that read through query_perp_deploy_auction_status(). The response includes the auction start time, duration, starting gas, current gas, and final gas once known. Registration creates the DEX and first market together The first deployment transition is more compact than the high-level diagram suggests. registerAsset2 can initialize a new DEX and register its initial asset in the same signed action. The action carries two groups of state: schema defines the DEX, including its full name, collateral token, and oracle updater. assetRequest defines the market, including {dex}:{coin}, size decimals, initial oracle price, margin table, and margin mode. If schema is omitted, the same action registers another asset in an existing DEX. The DEX name must currently contain two to four characters. The asset name follows the builder-perpetual format {dex}:{coin}, which is why the live market is para:CRDO rather than only CRDO. A returned transaction response is not the end of the verification path. The builder should read the DEX back through perpDexs, then read the market through meta or metaAndAssetCtxs. The state transition is complete only when the expected namespace, market, margin configuration, and updater are discoverable through HyperCore information endpoints. Registration is the beginning of operations Once a market exists, the deployer can modify market-specific state through additional perpDeploy variants. The current deployer-action reference includes actions for: Funding multipliers and funding interest rates Margin tables and margin modes Open-interest caps Fee recipient and fee scale Oracle sub-delegation Growth mode and market annotation Trading halt and settlement The oracle is the continuous part of the lifecycle. The documentation permits setOracle calls no more frequently than once every 2.5 seconds and expects an update every 3 seconds even when prices have not changed. After 10 seconds without an update, stale marks fall back to the local mark price. The docs explicitly say that builders should not rely on this fallback. Settlement is also an explicit state transition. haltTrading cancels open orders and settles positions at the current mark price. The action can later resume trading, which allows the same asset slot to be recycled. This is why registration should not be described as permanent market availability. The deployer remains responsible for operating and eventually resolving the market. The perpDeploy Action Envelope Deployer operations use the exchange action interface. The outer action identifies the perpDeploy family, while the nested field selects the operation. A market registration action follows this shape: type PerpDeployAction = | { type: "perpDeploy"; registerAsset2: RegisterAsset2 } | { type: "perpDeploy"; setOracle: SetOracle } | { type: "perpDeploy"; haltTrading: HaltTrading } // Margin, funding, fees, limits, annotations, permissions, and other // operator actions are documented in the official current reference. This abbreviated union shows only the variants used in this article. Consult the HIP-3 deployer-action reference for the current complete set. The newer asset-registration structure is registerAsset2: type RegisterAsset2 = { maxGas?: number assetRequest: { coin: string szDecimals: number oraclePx: string marginTableId: number marginMode: "strictIsolated" | "noCross" | "normal" } dex: string schema?: { fullName: string collateralToken: number oracleUpdater?: string } } collateralToken selects the asset traders use for margin and settlement. It is not a liquidity pool, and registering zqjx:DEMO does not create a spot token. This structure already shows why a HIP-3 market is not merely a ticker. coin defines the namespaced symbol. szDecimals controls size precision. oraclePx initializes the price domain. marginTableId selects the leverage and maintenance-margin schedule. marginMode constrains how trader collateral can be shared. The optional schema field initializes DEX-level configuration. It carries the DEX’s full name, collateral-token index, and oracle-updater address. It does not define the economic contract behind an individual ticker. Per-market display metadata belongs to setPerpAnnotation, which supports a category, description, display name. A serious interface should surface that annotation together with the DEX namespace and operator documentation rather than infer contract meaning from the short ticker alone. The official Python SDK still exposes the older perp_deploy_register_asset helper, which serializes the older registerAsset variant. Because the current action reference documents registerAsset2, the lab below constructs and signs the raw current envelope explicitly. Inspect the installed SDK and the live action reference again before any production deployment. The durable mental model is the signed action, not a particular helper method. Hands-on HIP-3 lab on testnet The safest way to teach HIP-3 is to separate reading, action construction, and state changes. Each example below shows the Python logic first and then the output captured from a real run. To keep the article easy and readable, the snippets omit imports, command-line parsing, JSON formatting helpers, and repeated validation functions. The complete runnable programs will be linked in the GitHub repository at the end of the article. Read a live HIP-3 market without a wallet Start with a public testnet market. This code creates only an Info client. It does not load a wallet, sign an action, or submit a transaction. TESTNET_API_URL = "https://api.hyperliquid-testnet.xyz" dex_name = "test" coin = "test:ABC" info = Info(TESTNET_API_URL, skip_ws=True) # Find the DEX and preserve its index because the index is part of the # HIP-3 action asset ID. dex_entries = info.perp_dexs() dex_index, dex = next( (index, item) for index, item in enumerate(dex_entries) if isinstance(item, dict) and item.get("name") == dex_name ) metadata, contexts = info.post( "/info", {"type": "metaAndAssetCtxs", "dex": dex_name}, ) universe = metadata["universe"] market_index = next( index for index, item in enumerate(universe) if item["name"] == coin ) limits = info.post("/info", {"type": "perpDexLimits", "dex": dex_name}) status = info.post("/info", {"type": "perpDexStatus", "dex": dex_name}) annotation = info.post("/info", {"type": "perpAnnotation", "coin": coin}) auction = info.query_perp_deploy_auction_status() action_asset_id = 100_000 + dex_index * 10_000 + market_index snapshot = { "network": "testnet", "auction": auction, "dex": dex, "market": { "actionAssetId": action_asset_id, "metadata": universe[market_index], "context": contexts[market_index], "annotation": annotation, }, "limits": limits, "status": status, } print(json.dumps(snapshot, indent=2)) Output: As we can see test is DEX index 1, and test:ABC is market index 0 inside that DEX: asset = 100000 + perpDexIndex × 10000 + indexInMeta = 100000 + 1 × 10000 + 0 = 110000 That 110000 value is what a normal HyperCore order action uses to route an order to this builder-deployed market. Construct the current registerAsset2 and setOracle actions Before a private key enters the workflow, build and inspect the exact wire actions. dex = "demo" coin = "demo:ASSET" updater = "0x1111111111111111111111111111111111111111" # HyperCore represents one HYPE as 100,000,000 native units. max_gas_hype = Decimal("500") max_gas_wei = int(max_gas_hype * Decimal("100000000")) if max_gas_wei == 0: raise ValueError( "maxGas=0 consumes a reserve deployment at the current auction price" ) register_action = { "type": "perpDeploy", "registerAsset2": { "maxGas": max_gas_wei, "assetRequest": { "coin": coin, "szDecimals": 2, "oraclePx": "100.0", "marginTableId": 10, "marginMode": "strictIsolated", }, "dex": dex, "schema": { "fullName": "Classroom Demo DEX", "collateralToken": 0, "oracleUpdater": updater.lower(), }, }, } oracle_action = { "type": "perpDeploy", "setOracle": { "dex": dex, "oraclePxs": sorted([(coin, "100.0")]), "markPxs": [sorted([(coin, "100.0")])], "externalPerpPxs": sorted([(coin, "100.0")]), }, } print(json.dumps({ "mode": "DRY_RUN", "submitted": False, "registerAction": register_action, "firstOracleAction": oracle_action, }, indent=2)) Output: The action reference expresses maxGas in native-token units. 1,000,000,000,000 units as 10,000 HYPE, corresponding to 100,000,000 units per HYPE. The 500 HYPE value above is a test cap, not a recommendation. Query perpDeployAuctionStatus immediately before signing. Do not casually set maxGas to zero: the current action reference says that zero consumes a reserve deployment at the current auction price. Make the expected read failure visible A missing DEX should stop verification immediately. This is the core of the failure path: missing_dex = "__missing_classroom__" dex_entries = info.perp_dexs() match = next( ( item for item in dex_entries if isinstance(item, dict) and item.get("name") == missing_dex ), None, ) if match is None: raise RuntimeError( f"DEX '{missing_dex}' was not returned by perpDexs on testnet" ) Output: Preview registration against live testnet state Only after the offline checks pass should you run the live testnet preflight. private_key = os.environ["HIP3_TESTNET_PRIVATE_KEY"] wallet = Account.from_key(private_key) dex = "zqjx" coin = f"{dex}:DEMO" max_gas_hype = Decimal("500") max_gas_wei = int(max_gas_hype * Decimal("100000000")) info = Info(TESTNET_API_URL, skip_ws=True) if any( isinstance(item, dict) and item.get("name") == dex for item in info.perp_dexs() ): raise RuntimeError(f"DEX '{dex}' already exists") auction = info.query_perp_deploy_auction_status() if Decimal(auction["currentGas"]) > max_gas_hype: raise RuntimeError("current auction gas exceeds the configured cap") collateral = next( token for token in info.spot_meta()["tokens"] if token["index"] == 0 ) action = { "type": "perpDeploy", "registerAsset2": { "maxGas": max_gas_wei, "assetRequest": { "coin": coin, "szDecimals": 2, "oraclePx": "100.0", "marginTableId": 10, "marginMode": "strictIsolated", }, "dex": dex, "schema": { "fullName": "Classroom Demo DEX", "collateralToken": collateral["index"], "oracleUpdater": wallet.address.lower(), }, }, } print(json.dumps({ "mode": "DRY_RUN", "network": "testnet", "wallet": wallet.address, "auction": auction, "collateral": collateral, "action": action, "submitted": False, }, indent=2)) Output: This dry run prepares the registerAsset2 action that would create the zqjx HIP-3 DEX and register its first perpetual market, zqjx:DEMO. Before building the action, it verifies that the DEX name is available, checks that the current deployment-auction price does not exceed the 500 HYPE cap, and confirms that token index 0 is the selected collateral asset, currently USDC. It then prints the unsigned action as JSON without signing or submitting it. A successful output confirms that the preflight checks passed and the action payload was constructed. We dont submit it here to the blockchain. Sign and submit only after explicit confirmation After reviewing the live auction and the complete action, sign with the testnet domain and submit the standard exchange payload: expected = f"DEPLOY {coin}" typed = input(f"Type '{expected}' to submit this TESTNET action: ") if typed != expected: raise RuntimeError("submission cancelled") nonce = get_timestamp_ms() signature = sign_l1_action( wallet, action, None, nonce, None, False, # is_mainnet=False selects the testnet signing domain ) response = API(TESTNET_API_URL).post( "/exchange", { "action": action, "nonce": nonce, "signature": signature, "vaultAddress": None, "expiresAfter": None, }, ) print(json.dumps(response, indent=2)) Verify the state transition A successful submission response is not sufficient. Read the namespace and market back from HyperCore: dex = next( item for item in info.perp_dexs() if isinstance(item, dict) and item.get("name") == "zqjx" ) metadata, contexts = info.post( "/info", {"type": "metaAndAssetCtxs", "dex": "zqjx"}, ) market_index = next( index for index, item in enumerate(metadata["universe"]) if item["name"] == "zqjx:DEMO" ) verified = { "dex": dex, "metadata": metadata["universe"][market_index], "context": contexts[market_index], "limits": info.post( "/info", {"type": "perpDexLimits", "dex": "zqjx"}, ), } print(json.dumps(verified, indent=2)) Call the transition verified only when the expected namespace, market, updater, margin settings, context, and limits are returned. If no registration was submitted, do not manufacture this output. Build and publish an oracle update Construct the oracle action first and print it as a dry-run: dex = "zqjx" coin = "zqjx:DEMO" oracle_action = { "type": "perpDeploy", "setOracle": { "dex": dex, "oraclePxs": sorted([(coin, "100.12")]), "markPxs": [sorted([(coin, "100.10")])], "externalPerpPxs": sorted([(coin, "100.11")]), }, } print(json.dumps({ "mode": "DRY_RUN", "network": "testnet", "iterations": 3, "intervalSeconds": 3.0, "action": oracle_action, "submitted": False, }, indent=2)) Output: Before publishing, verify that the DEX exists, the wallet is an authorized oracle updater, the market’s live szDecimals matches the price validation, and externalPerpPxs contains all assets. Reading a Live Builder-Deployed DEX on Mainnet We do not need deployer credentials to inspect HIP-3 state. The public /info endpoint exposes the read side. First, enumerate builder-deployed DEXs: curl -s https://api.hyperliquid.xyz/info \ -H 'Content-Type: application/json' \ -d '{"type":"perpDexs"}' | jq One live response included the Paragon DEX: { "name": "para", "fullName": "Paragon", "deployer": "0x8888888c43cbb7e1c4132542e46831bffd866ed3", "oracleUpdater": "0x8888888c43cbb7e1c4132542e46831bffd866ed3", "feeRecipient": "0x1770f43c71b8b2977771b73ca4c4cbe0c20412ed" } This object exposes the operating boundary directly. The deployer address controls deployer actions. The oracle-updater address controls the continuous price feed. The fee recipient receives the configured deployer fee share. These roles can be separated. The HIP-3 specification recommends an oracle updater so the continuously active signing key does not need the same authority as the deployer key. Now request market metadata and live contexts for that DEX: curl -s https://api.hyperliquid.xyz/info \ -H 'Content-Type: application/json' \ -d '{"type":"metaAndAssetCtxs","dex":"para"}' | jq The response is a two-element array. The first element contains DEX metadata and the asset universe. The second contains a context object for each asset at the same array index. { "szDecimals": 2, "name": "para:CRDO", "maxLeverage": 10, "marginTableId": 10, "onlyIsolated": true, "marginMode": "strictIsolated", "growthMode": "enabled" } The context at the same index included: { "funding": "0.0000440215", "openInterest": "1083.1", "dayNtlVlm": "367656.8567", "oraclePx": "230.6393", "markPx": "230.8112", "midPx": "230.835", "impactPxs": ["230.46", "231.21"] } These values are observations, not constants. The useful part is the state shape. The metadata tells us what the market permits. The context tells us what the market is doing now. oraclePx anchors the external reference. markPx feeds the risk engine. midPx and impactPxs come from the local order book. Open interest and funding expose the current position and carry state. Finally, inspect the DEX limits: curl -s https://api.hyperliquid.xyz/info \ -H 'Content-Type: application/json' \ -d '{"type":"perpDexLimits","dex":"para"}' | jq The same snapshot returned a total DEX open-interest cap of 50,000,000 and an explicit para:CRDO cap of 25,000,000. This gives us an observable chain of responsibility: Deployer configuration → asset metadata → continuous market context → DEX and asset limits → trader-visible HyperCore state The API is not a marketing page. It is a debugger for the deployed market definition. The Oracle Is the Operational Center Registration is occasional. Oracle publication is continuous. The deployer or delegated oracle updater sends setOracle actions: type SetOracle = { dex: string oraclePxs: Array<[string, string]> markPxs: Array<Array<[string, string]>> externalPerpPxs: Array<[string, string]> } oraclePxs supplies the external reference price for each listed asset. markPxs supplies zero, one, or two additional mark inputs. externalPerpPxs provides a separate external perpetual-price input and must include every asset in the DEX. The tuple arrays must be sorted by coin before signing. This is not cosmetic. Hyperliquid actions are signed over a deterministic serialization. If two implementations order the same economic data differently, they do not sign the same bytes. A Python update using the current SDK can look like this: oracle_pxs = { "demo:ASSET": "100.12", } mark_pxs = [{ "demo:ASSET": "100.10", }] external_perp_pxs = { "demo:ASSET": "100.11", } result = exchange.perp_deploy_set_oracle( "demo", oracle_pxs, mark_pxs, external_perp_pxs, ) The SDK converts these dictionaries into sorted tuple arrays before signing. If you construct the raw action yourself, you must perform that deterministic sorting explicitly. Example of the SDK sorting: The oracle price says what the underlying is worth according to the deployer’s reference process. The mark price says what value HyperCore will use for risk-sensitive calculations after applying its mark construction and constraints. A stale or manipulated oracle can still create serious problems. It can distort funding, disconnect the market from the intended underlying, and push trading toward limits. HyperCore adds bounded behavior around the input, but it cannot prove that the deployer’s economic interpretation of an external asset is honest. HIP-3 therefore creates two different security questions: Did HyperCore execute the submitted action correctly? Did the deployer submit a correct representation of the external market? Consensus can answer the first question. It cannot answer the second by itself. Funding Is Similar, but Not Identical HIP-3 markets use the same broad purpose for funding as other perpetuals. Funding pressures the contract toward its reference price by transferring value between longs and shorts. The funding documentation specifies a more responsive premium formula for HIP-3 markets: premium = 0.5 × (impactBidPx + impactAskPx) / oraclePx - 1 Deployers can also configure funding multipliers and per-asset interest rates within the permitted ranges. The premium is sampled through the hour and used in the hourly funding calculation. Funding is paid every hour. The payment uses position size multiplied by the oracle price and funding rate, not the mark price: funding payment = position size × oracle price × funding rate The oracle updater is not a background service that can be treated casually. Its submitted price affects more than a number in the UI. It participates in the economics that move value between open positions. Trading Uses the Normal HyperCore Path After deployment, traders do not send a special HIP-3 order type. They use the normal HyperCore order and cancel actions with the builder-deployed asset ID. Builder-deployed names use the format: {dex}:{coin} For API actions, the asset-ID documentation defines the integer as: asset = 100000 + perpDexIndex × 10000 + indexInMeta For example, if a builder DEX has index 1 and the asset is the first entry in that DEX’s metadata, the action ID is: 100000 + 1 × 10000 + 0 = 110000 The namespace solves two problems. First, two deployers can list different contracts with the same short ticker without colliding in API representation. Second, HyperCore can route a standard order action to the correct builder-deployed order book. The lifecycle becomes: Trader signs a normal order action → asset ID selects the HIP-3 DEX and market → HyperCore validates margin and limits → the DEX order book matches the order → HyperCore updates positions, balances, and funding state Summary HIP-3 extends Hyperliquid at the market-definition layer. A deployer can register a perpetual DEX, define assets, choose margin parameters, cap open interest, configure funding behavior, delegate oracle updates, and halt trading. Traders then interact with those markets through the same HyperCore order path used elsewhere on the L1. The execution engine remains shared. The market’s operating inputs do not. HyperCore determines how a valid order changes balances and positions. The deployer determines what the contract represents, which price process anchors it, how much leverage it permits, how much exposure it can accumulate, and when it must stop. This separation defines the new trust boundary. For builders, the opportunity is larger than permissionless listings. HyperCore becomes shared financial infrastructure for markets the core team did not define. For traders and integrators, the review surface also becomes larger. It is no longer enough to trust the L1’s execution. You must understand the deployer whose inputs give a particular market its economic meaning. The infrastructure side of that boundary HIP-3 also makes one thing concrete: running a deployer is a continuous infrastructure job, not an occasional one. The oracle updater has to publish at least every 3 seconds. Miss the 10-second stale window and marks fall back to local mark price — a fallback the docs explicitly tell builders not to rely on. Reading market state, monitoring open-interest caps, watching auction status: all of it is continuous polling against the same endpoint. The public Hyperliquid endpoint is rate-limited to 100 requests per minute per IP. That is fine for prototyping and not close to fine for operating a live DEX. Chainstack runs private Hyperliquid RPC endpoints that remove that ceiling. You get both HyperEVM paths (/evm for standard EVM traffic, /nanoreth when you need system transactions), plus /info and /exchange for the HIP-3 read and action flows this article walks through. Testnet nodes and a HYPE faucet are available for building deployer tooling before touching mainnet stake. Spin up a Hyperliquid node in under one minute → FAQ Does trading a HIP-3 market require a different order action than normal HyperCore markets? No. Traders use the standard HyperCore order and cancel actions. The only difference is the asset ID, which encodes the builder-deployed DEX and market index: 100000 + perpDexIndex × 10000 + indexInMeta. Wallets and trading clients that already speak HyperCore need no HIP-3-specific code path — just resolve the {dex}:{coin} name to the right integer and submit the same action. Can a builder halt trading and keep positions open indefinitely? No. haltTrading cancels open orders and settles positions at the current mark price. It’s a terminating action for the affected market, not a pause. Trading can be resumed later, which allows the same asset slot to be recycled, but any positions that existed at halt time are already closed at the mark. Traders should treat any market whose deployer has flagged wind-down intent as exit-only. Does the oracle updater key need the same authority as the deployer key? No, and the HIP-3 specification recommends separating them. The deployer key controls registration, margin tables, fee configuration, and halting. The oracle updater key only signs setOracle actions. Since the updater key has to be online continuously to publish every 3 seconds, keeping it separate limits the blast radius if it’s compromised — the attacker can distort prices but cannot re-configure the market. What happens to the 500,000 HYPE stake if I settle the market early? The current specification is genuinely ambiguous here. The staking section says the requirement is maintained for at least 183 days after DEX deployment. The settlement section says that once all assets are settled, the deployer’s required stake is free to be unstaked. The docs do not explicitly reconcile the two. Assume the 183-day floor holds until the specification clarifies otherwise, and verify against the current action reference before making a business decision on the stake. Can two builder-deployed DEXs use the same collateral token? Yes. collateralToken in the schema is a token index, and multiple DEXs can reference the same one — for example, both para and a hypothetical second DEX can settle in USDC (index 0). Traders holding that collateral can post it as margin across both DEXs, but positions and margin accounting remain scoped to each DEX’s own markets. Sharing collateral does not share risk between DEXs. How often does the oracle updater actually need to publish? Every 3 seconds, with a hard minimum of 2.5 seconds between calls. After 10 seconds without an update, HyperCore falls back to the local mark price for stale marks — behavior the docs explicitly say builders should not rely on. In practice this means the updater has to be a dedicated always-on process with monitored uptime, not a serverless function or a cron job. Related reading The Hyperliquid series Part 1: Architecture, clearinghouse, agent keys, cross-margin Part 2: HyperBFT, sub-accounts, spot and perpetual accounting Part 3: HyperEVM precompiles and the CoreWriter bridge HIP context Hyperliquid HIPs explained: HIP-1 to HIP-4 Hyperliquid HIP-4 vs Polymarket: outcome markets in 2026 Practical infrastructure Hyperliquid API guide: endpoints, SDK, and WebSocket #### Hyperliquid HIP-4 vs Polymarket: outcome markets compared (2026) Hyperliquid is the fastest-growing on-chain exchange in crypto history — $6B+ in daily perp volume as of May 2026, a fully on-chain CLOB running at 200,000 orders per second, and now, as of May 2, 2026, a prediction market primitive built directly into the same matching engine. Polymarket is the opposite story: born in 2020 as a standalone prediction market, it has processed over $21.5B in volume in 2025 alone and raised at an $8B valuation with NYSE as a strategic backer. These two platforms have just become direct competitors. HIP-4 — Hyperliquid Improvement Proposal 4 — went live on mainnet the same week Bloomberg reported Polymarket was pursuing CFTC approval to re-enter the US market. The timing is not a coincidence. The prediction market category is exploding: industry-wide monthly volume hit $21B by mid-2026, and both platforms are racing to own the infrastructure layer underneath it. What makes this comparison genuinely interesting is that HIP-4 is not a separate product — it is a new primitive on the same engine where traders already run perpetual futures and spot. That composability changes the economics in ways that Polymarket’s isolated CTF token model simply cannot replicate. This guide breaks down what HIP-4 actually is, how Polymarket works under the hood, where the two differ on fees, resolution, liquidity, and composability, and which platform fits which workload. Hyperliquid HIP-4 explained: what it is and how it works HIP-4 was announced February 2, 2026 — HYPE rallied 10% on the day — co-authored by Bedlam Research and John Wang (Head of Crypto at Kalshi). It launched on testnet the same week and went live on mainnet May 2, 2026. HyperCore will support outcome trading (HIP-4). Outcomes are fully collateralized contracts that settle within a fixed range. They are a general-purpose primitive that are useful for applications such as prediction markets and bounded options-like instruments. There has been…— Hyperliquid (@HyperliquidX) February 2, 2026 📖 New to Hyperliquid’s proposal system? Hyperliquid HIPs explained: HIP-1 to HIP-4 covers the full governance arc. The formal definition from the Hyperliquid docs: outcomes are fully collateralized contracts that settle within a fixed range. They are a general-purpose primitive useful for prediction markets and bounded options-like instruments. In plain terms: a HIP-4 outcome contract is a binary YES/NO instrument tied to a discrete event, trading between 0.001 and 0.999, with the price representing the implied probability. If you buy YES at 0.62, you profit 0.38 if the event occurs and lose 0.62 if it does not. No leverage, no liquidations. Settlement is in USDH, Hyperliquid’s native stablecoin backed by BlackRock-managed reserves and custodied by JPMorgan. The lifecycle of a HIP-4 market Every outcome market passes through four phases: Deployment — a canonical market (Phase 1) or builder-deployed market (Phase 2) is registered with the validator set, including the oracle specification, settlement time, and event description encoded in the description field. Opening auction — roughly 15 minutes of single-price clearing before continuous trading begins. This is where initial price discovery happens without a market maker. Continuous CLOB trading — the outcome book goes live on the same matching engine as perps and spot. The same maker/taker order types (GTC, ALO, IOC) apply. Outcome volume counts toward protocol-wide fee tier calculations. Oracle settlement and slot recycling — the authorized oracle posts a 0/1 result. For the first canonical market (recurring daily BTC binary), the oracle is Hyperliquid’s own BTC mark price. An optional challenge window exists. After settlement, the slot is recycled for the next market in the series. Fee structure The fee design is deliberately asymmetric compared to Polymarket: Zero fees to open or mint an outcome position Fees apply only on close, burn, or settlement Makers receive no rebates on outcome books (unlike perp and spot books) Users with aligned quote tokens (HYPE staking) get 20% lower taker fees Outcome volume counts toward protocol-wide tier calculations, compounding savings on perps for active prediction-market traders The first canonical market opened May 2 with a daily BTC binary: “BTC above $78,213 on May 3 at 06:00 UTC?” — opening probability 62%, first-hours volume $54,026, OI $79,938. The builder economy (Phase 2) Phase 1 is curated canonical markets approved by the validator set. Phase 2 opens permissionless deployment: builders stake 1,000,000 HYPE per slot (slashable, with burned tokens for oracle manipulation or invalid state transitions). One slot recycles across many sequential markets in a series, so the economics work for teams running 20+ recurring markets per quarter. Builders can set up to 50% additional fee share above the protocol base. Frontends at launch include Outcomexyz, Stratium, hip4.io, and the loris.tools dashboard suite. How to query HIP-4 markets # Fetch all live outcome markets and their metadata curl -X POST https://api.hyperliquid.xyz/info \ -H "Content-Type: application/json" \ -d '{"type": "outcomeMeta"}' Response structure: { "outcomes": [ { "outcome": 123, "name": "Recurring", "description": "class:priceBinary|underlying:BTC|expiry:20260503-0600|targetPrice:78213|period:1d", "sideSpecs": [ { "name": "Yes" }, { "name": "No" } ] } ] } The description field encodes the full contract spec. Asset IDs for outcome trading are derived from outcomeId + binary side, documented under for-developers/api/asset-ids in the Hyperliquid docs. Placing an order on a HIP-4 market (Python SDK) from hyperliquid.exchange import Exchange from hyperliquid.info import Info from hyperliquid.utils import constants import eth_account # Load wallet wallet = eth_account.Account.from_key(PRIVATE_KEY) info = Info(constants.MAINNET_API_URL, skip_ws=True) exchange = Exchange(wallet, constants.MAINNET_API_URL) # Query outcome metadata to get the asset index meta = info.post("/info", {"type": "outcomeMeta"}) outcome_asset_id = meta["outcomes"][0]["outcome"] # map to asset index per docs # Place a limit buy of YES shares at 0.62 implied probability result = exchange.order( "BTC-OUTCOME-YES", # use the mapped asset name from outcomeMeta True, # is_buy = True 100, # size (shares) 0.62, # limit price (= 62% implied probability) {"limit": {"tif": "Gtc"}} ) print(result) The raw exchange-endpoint payload uses the same schema as perps — a (asset index), b (isBuy), p (price), s (size), t (order type) — signed via EIP-712: { "action": { "type": "order", "orders": [ { "a": 123, "b": true, "p": "0.62", "s": "100", "r": false, "t": { "limit": { "tif": "Gtc" } } } ], "grouping": "na" }, "nonce": 1746200000000, "signature": { "r": "0x...", "s": "0x...", "v": 27 } } Polymarket explained: how it works Polymarket runs a hybrid CLOB on Polygon. Outcome shares are Gnosis Conditional Token Framework (CTF) ERC-1155 tokens — every YES/NO pair is fully backed by exactly $1 of pUSD (post-V2) locked in the CTF contract. The CLOB itself matches off-chain (Polymarket-operated), with settlement and token transfers happening on-chain. 📖 Going deeper on Polymarket’s API? Polymarket API for developers: Gamma API, data, and Polygon RPC covers the full stack — CLOB, CTF, UMA resolution, and how to query markets programmatically with Polygon RPC. Multi-outcome events use the NegRisk CTF adapter: a NO token in any market can be converted into one YES token across every other mutually-exclusive market plus residual collateral. This is capital-efficient for election-style markets with many candidates — a mechanism HIP-4’s binary-only Phase 1 does not yet offer. Resolution via UMA Optimistic Oracle Every Polymarket event resolves through the UMA Optimistic Oracle v2 via the open-source UmaCtfAdapter contract: A proposer posts an answer with a $750 USDC bond If undisputed during the 2-hour challenge window, the answer finalizes If disputed once, a fresh request is created (to neutralize griefing attempts) If disputed twice, the question escalates to UMA’s Data Verification Mechanism — a commit-reveal vote by UMA token-holders, resolving in 48–72 hours Polymarket also uses Chainlink Data Streams for fast crypto-resolved markets (BTC price at expiry, ETH price at date) and an internal Markets Team for ruleset clarifications. The UMA DVM has processed hundreds of contested markets; the optimistic layer resolves ~98.5% of requests without escalation. Querying Polymarket markets and placing orders (CLOB V2) from py_clob_client.client import ClobClient from py_clob_client.clob_types import OrderArgs, OrderType from py_clob_client.order_builder.constants import BUY HOST = "https://clob.polymarket.com" CHAIN_ID = 137 # Polygon mainnet client = ClobClient( HOST, key=PRIVATE_KEY, chain_id=CHAIN_ID, signature_type=1, # 1 = proxy wallet (Magic/email login) funder=PROXY_FUNDER # address holding the pUSD collateral ) client.set_api_creds(client.create_or_derive_api_creds()) # Read market data token_id = "<yes-token-id-from-gamma-api>" mid = client.get_midpoint(token_id) price = client.get_price(token_id, side="BUY") book = client.get_order_book(token_id) print(f"Mid: {mid}, Ask: {price}") # Place a GTC limit buy of 5 shares at $0.63 order = OrderArgs(token_id=token_id, price=0.63, size=5.0, side=BUY) signed = client.create_order(order) resp = client.post_order(signed, OrderType.GTC) print(resp) Polymarket’s API surface has four hosts: clob.polymarket.com (order entry + book), data-api.polymarket.com (positions, fills, history), gamma-api.polymarket.com (market and event discovery), and wss://ws-subscriptions-clob.polymarket.com (real-time fills and book updates). Authentication is two-tier: L1 = EIP-712 with private key, L2 = HMAC-SHA256 over API credentials derived from L1. Splitting USDC into YES + NO tokens on-chain // Split 100 pUSD into 100 YES + 100 NO conditional tokens // Required for two-sided market making await ctfContract.splitPosition( collateralToken, // pUSD token address on Polygon parentCollectionId, // bytes32(0) for top-level binary markets conditionId, // from market.tokens metadata in Gamma API [1, 2], // partition: YES = 0b01, NO = 0b10 ethers.parseUnits("100", 6) // 100 pUSD in 6-decimal units ); HIP-4 vs Polymarket: side-by-side comparison The table below summarizes public positioning as of May 2026. FeatureHIP-4 (Hyperliquid)PolymarketLive statusMainnet May 2, 2026; Phase 1 canonical onlyMature; CLOB V2 since April 2026ArchitectureNative on-chain CLOB on HyperCoreOff-chain matching, on-chain CTF settlement on PolygonMarket creationValidator-curated (Phase 1); permissionless with 1M HYPE stake (Phase 2)Permissioned — Polymarket Markets TeamResolutionAuthorized oracle posts 0/1; BTC mark price for first marketUMA Optimistic Oracle + Chainlink Data Streams + Markets TeamCollateralUSDHpUSD (post-V2)Fee on openZeroZero on most markets; 1.56–1.80% peak taker on 15-min crypto marketsFee on settleYes — fees apply on close/burn/settleZero — winning shares redeem $1.00Maker rebatesNone on outcome booksDaily USDC rebates funded by taker feesCross-marginUnified margin with perps and spotNone — isolated to PolymarketMulti-outcomeBinary only in Phase 1NegRisk adapter for multi-candidate eventsThroughputShared 200k orders/sec matching engineLimited by Polygon + off-chain matchingOn-chain matchingFully on-chain CLOBOff-chain matching, on-chain settlement onlyDeFi composabilityHyperEVM can read outcome state; vault integration possibleCTF ERC-1155s technically composable but ecosystem support thinUS accessGeo-blockedInternational platform blocked; US-licensed arm pendingMarket breadthCrypto price binaries only todayPolitics, sports, geopolitics, macro, pop culture Choose by use case For delta-neutral crypto strategies and perp hedging A trader long ETH-PERP facing binary event risk (Fed decision, CPI release, on-chain governance vote) has historically had two options: reduce the position or accept the binary exposure. HIP-4 introduces a third option: buy a YES or NO contract on the same event, in the same margin account, with no additional collateral requirement. The outcome position partially offsets the perp’s directional risk without unwinding it. The mechanics work because HIP-4 positions are 1× isolated with no liquidation — the maximum loss is the entry premium — and because Hyperliquid’s margin engine aggregates across all positions. A $10,000 ETH-PERP long plus $1,000 in BTC-DOWN YES contracts is one portfolio, not two accounts. For traders already running on Hyperliquid, the cost of entry to prediction markets is near-zero. For Polymarket users, this use case is simply unavailable — Polymarket has no perp layer and no cross-margin mechanism. Explore trading infrastructure on Chainstack → For prediction market arbitrage between HIP-4 and Polymarket Both platforms now run overlapping crypto binary markets. Polymarket’s 15-minute BTC markets charge up to 1.56–1.80% peak taker fees (at 50% probability). HIP-4 charges zero on open. A bot that simultaneously quotes on Polymarket and takes on HIP-4 (or vice versa) has a structural edge every time the two platforms misprice the same underlying event. The technical requirements for this strategy: sub-second latency to both CLOBs, simultaneous WebSocket subscriptions to both order books, position management across Polygon (Polymarket) and HyperCore (HIP-4), and collateral bridging logic (pUSD on Polygon vs. USDH on Hyperliquid). The engineering is non-trivial but the fee asymmetry is durable — it exists by design, not accident, and will persist through Phase 1 at minimum. Explore dedicated node infrastructure for low-latency bots on Chainstack → For political, sports, and qualitative event markets This is Polymarket’s home territory and it is not close. The “Will the US strike Iran?” market hit $73M in February 2026. MLB’s exclusive Official Prediction Market Exchange partnership (March 2026) gives Polymarket proprietary real-time Sportradar data for baseball markets. Geopolitics, awards ceremonies, economic indicators, central bank decisions with qualitative outcomes — these all require UMA’s arbitrary-truth resolution machinery. HIP-4’s Phase 1 oracle is Hyperliquid’s own BTC mark price. It cannot resolve “Did Kamala Harris win the Iowa caucus?” until Phase 2 deploys a politically-verified oracle with appropriate dispute mechanisms. For any user whose primary interest is non-crypto prediction markets, Polymarket is the only serious option today. The question is whether Phase 2’s permissionless builder economy changes this — and that answer depends on which external oracle networks builders integrate with first. Platform breakdown Hyperliquid HIP-4 Hyperliquid’s HIP-4 launched with deliberate constraints. The first canonical market is a recurring daily BTC binary — arguably the simplest possible prediction market, one where the oracle is trivially verifiable (Hyperliquid’s own published BTC mark price) and the resolution is unambiguous. This is a sound engineering choice: launch the narrowest possible market, prove oracle reliability, then expand. The infrastructure story is the actual differentiator. Because outcome books live on HyperCore alongside perp and spot books, every piece of trading infrastructure already built for Hyperliquid extends to HIP-4 with minimal modification. Market-makers with existing quote generation, risk management, and hedging logic on Hyperliquid perps can extend to outcome markets at near-zero marginal cost. The HYPE token alignment deserves mention: 97% of protocol fees across all products (including HIP-4) fund HYPE buybacks. This means every outcome market trade is directly accretive to HYPE holders — a flywheel that has no equivalent in Polymarket’s current tokenless structure (a $POLY launch is widely rumored; Gate.io’s pre-market equity contract implied a Polymarket valuation of ~$14B in April 2026 — consistent with the $8B valuation from October 2025 and the $600M round in March 2026). Limitations: Phase 1 is limited to crypto price binaries. No maker rebates on outcome books is a deliberate choice that disadvantages pure prediction-market LPs who cannot spread infrastructure costs across perp/spot. The oracle design for non-crypto events is entirely unspecified — the Phase 2 builder stake (1,000,000 HYPE, ~$40M at recent prices) creates accountability but not a resolution methodology. US traders are geo-blocked. Fit by workload: Delta-neutral crypto hedging: Excellent — unified margin is the defining advantage Crypto price arbitrage vs. Polymarket: Excellent — zero open fees create structural edge Political/sports/macro markets: Limited — Phase 1 oracle cannot resolve qualitative events Polymarket Polymarket is the market leader by every measurable metric: volume ($21.5B in 2025, $25.7B in March 2026 alone), user count (~840k monthly active wallets by Feb 2026), institutional backing (ICE/NYSE strategic investment at $8B valuation October 2025, $600M direct equity round March 2026), and regulatory positioning (QCEX acquisition gives a CFTC-licensed US exchange; CFTC re-entry discussions ongoing per Bloomberg April 2026). The UMA resolution system has processed tens of thousands of markets across every conceivable event category. The ~98.5% optimistic-layer resolution rate means most markets settle without dispute; the DVM escalation path handles edge cases with a documented, token-holder-voted process. Only one market in Polymarket’s history (Barron Trump / DJT) was ever overridden by Polymarket’s internal team — a track record that supports a trust claim that HIP-4 cannot yet make. CLOB V2 (launched late April 2026) introduced pUSD as the native collateral, new SDK requirements (upgrade to v2 packages, EIP-712 signing changes), tiered fees by market category (crypto 7.2%, sports 3%, finance/politics/tech 4%), and a maker rebate program funded by taker fees. The dynamic fee structure on 15-minute crypto markets specifically — peaking at 1.56–1.80% taker at 50% probability — is a direct response to latency arbitrage, and the design explicitly accepts that sophisticated traders will find it cheaper to trade crypto binaries on HIP-4. Limitations: No cross-margin composability with any other DeFi primitive. The maker rebate system incentivizes LPs but the off-chain matching engine means the order book is less transparent than HIP-4’s fully on-chain CLOB. US traders on the main platform remain geo-blocked (a separate US-licensed platform via QCEX is in development). The CTF token model isolates capital — you cannot use a YES token as collateral for anything else. Fit by workload: Political/sports/macro events: Excellent — depth, breadth, and UMA resolution are unmatched Retail prediction markets (non-crypto): Excellent — 60-second onboarding via MoonPay/Stripe fiat, no wallet required Delta-neutral crypto hedging: Limited — no perp layer, no cross-margin mechanism Getting started with Hyperliquid on Chainstack If you are building on HIP-4 — whether a market-making bot, an arbitrage strategy, a HyperEVM vault contract, or an analytics dashboard — the production infrastructure path is: Log in to Chainstack console (or create a free account — no card required, 3M RU/month on the Developer plan) Create a new project and select Hyperliquid Mainnet Deploy a Global Node for shared-endpoint access Or deploy a Dedicated Node for unlimited throughput, WebSocket streaming, and no rate limits (recommended for production bots) Copy your HTTP or WebSocket endpoint — it’s a drop-in replacement for the public api.hyperliquid.xyz endpoint Discover live outcome markets: python import requests ENDPOINT = "YOUR_CHAINSTACK_ENDPOINT" resp = requests.post(ENDPOINT, json={"type": "outcomeMeta"}) for o in resp.json()["outcomes"]: outcome_id = o["outcome"] yes_coin = f"#{10 * outcome_id + 0}" # e.g. "#10" for BTC daily YES no_coin = f"#{10 * outcome_id + 1}" # e.g. "#11" for BTC daily NO print(o["description"], "→", yes_coin, "/", no_coin) Read the order book for a HIP-4 outcome: python # BTC daily YES = coin "#10" (outcome 1, side 0 → encoding = 10*1+0 = 10) book = requests.post(ENDPOINT, json={"type": "l2Book", "coin": "#10"}).json() bids = book["levels"][0] asks = book["levels"][1] print(f"Best bid: {bids[0]['px']} Best ask: {asks[0]['px']}") Note: The standard hyperliquid-python-sdk doesn’t know about HIP-4 out of the box — its coin_to_asset map is built from spotMeta only and won’t resolve #10. You need to fetch outcomeMeta, compute asset IDs (100_000_000 + 10 * outcome_id + side), and inject them into the SDK’s resolver. The Chainstack HIP-4 trading guide has the full SDK patch and working order placement code. Chainstack’s Hyperliquid nodes support both HTTP REST polling and WebSocket streaming — critical for settlement-burst handling when a daily BTC binary resolves and thousands of positions settle simultaneously. Want a working starting point? The chainstacklabs/hyperliquid-hip-4 repo on GitHub includes learning examples and a passive market-maker bot for HIP-4 outcome markets — clone it, drop in your Chainstack endpoint, and you have a baseline to build from. The Chainstack performance dashboard tracks real-time Hyperliquid latency across EU, JP, and US West regions — use it to select the optimal region before deploying your strategy. Hyperliquid is one of eight chains currently tracked (alongside Ethereum, Arbitrum, Base, BNB, Monad, Solana, and TON). Need testnet HYPE for strategy development? Grab from the Chainstack Hyperliquid testnet faucet. The Hyperliquid tooling documentation on Chainstack Docs covers SDK setup, order signing, and outcome market data access patterns. Hyperliquid on Chainstack: SOC 2 Type II and ISO 27001 certified, 99.99%+ uptime SLA, Dedicated Nodes with Bolt fast-sync on Dedicated Nodes for rapid archive access, and the Unlimited Node add-on for flat-rate RPS billing — no surprise overage charges when your bot spikes during settlement events. Infrastructure requirements for production HIP-4 bots Prediction markets look like simple YES/NO bets. Underneath, they are order-matching systems with the same latency and data-access requirements as any CLOB exchange — and in some ways harder, because settlement events create concentrated bursts of state changes that can overwhelm unprepared infrastructure. For HIP-4 specifically, three infrastructure concerns separate a production setup from a toy integration: Settlement-burst handling — when a binary outcome resolves, every position in that market settles simultaneously. A spike of thousands of order state changes hits the RPC layer in a narrow window. Endpoints without adequate throughput will queue or drop requests exactly when you need them most. WebSocket streaming vs. polling — for outcome book depth, real-time fills, and oracle price feeds, WebSocket subscription is the only latency-viable approach. HTTP polling introduces artificial lag at exactly the moments — settlement, high volatility — when you need the freshest data. Archive access for strategy backtesting — HIP-4 market history (fills, order cancels, settlement prices) is available via the info endpoint but requires archive-depth access for historical periods beyond the default lookback. Backtesting a recurring BTC binary strategy across 90 days of daily markets requires archive node access. Rate limits and burst capacity — Hyperliquid’s public endpoint caps at 100 requests/minute. Production market-making bots, arbitrage strategies between HIP-4 and Polymarket, and vault contracts polling outcome state will blow through this within seconds. Cross-product data correlation — HIP-4’s value proposition is margin composability with perps and spot. Any system exploiting this — a delta-neutral vault, a perp hedge with a binary overlay — needs simultaneous low-latency reads from both the perp book and the outcome book on the same connection. For Polymarket, the equivalent concerns are around Polygon throughput (CTF token splits and merges are on-chain), CLOB V2 API authentication (two-tier EIP-712 + HMAC), WebSocket subscription reliability for real-time fills, and position indexing via the Gamma API for multi-market portfolio management. Conclusion The single most important decision criterion for prediction market infrastructure in 2026 is whether you are trading within crypto or about the world. HIP-4 is the better platform for the former; Polymarket dominates the latter — and that division reflects something deeper than feature lists. For delta-neutral crypto hedging and perp overlay strategies: HIP-4 — the unified margin account is structurally unavailable on any standalone prediction market platform For arbitrage between HIP-4 and Polymarket: HIP-4 as the low-fee leg; Polymarket as the high-fee leg — the structural edge is durable through Phase 1 For political, sports, geopolitics, and macro qualitative events: Polymarket — UMA resolution, NegRisk multi-outcome, and market depth are not replicated by anything in Phase 1 For retail users without crypto wallets: Polymarket — fiat onramps, social login, no gas required For builders deploying vault contracts or structured products: HIP-4 on HyperEVM — outcome state is readable by smart contracts in a way Polymarket’s CTF tokens simply do not enable Watch Phase 2: When Hyperliquid opens permissionless builder deployment with external oracle integrations, the political and sports market gap begins to close. The 1M HYPE stake bar is high; the teams willing to meet it will be well-capitalized and motivated. Deploy your Hyperliquid endpoint on Chainstack → FAQ What is the difference between HIP-4 and a regular prediction market? HIP-4 outcome contracts are settled in USDH and live on the same matching engine as Hyperliquid perps and spot, meaning they share unified portfolio margin with other positions. A regular prediction market (Polymarket, Kalshi) is a standalone platform where your capital is isolated — you cannot offset a prediction market position against a derivatives position in the same margin account. Can I trade both HIP-4 and Polymarket simultaneously? Yes, but they are separate platforms with separate collateral. HIP-4 requires USDH on Hyperliquid; Polymarket requires pUSD on Polygon. Arbitrage between the two is technically feasible but requires infrastructure on both chains and collateral management across two ecosystems. Most traders start on one platform and extend to the other as a specific strategy justifies it. Does Polymarket charge fees on winnings? No — winning Polymarket shares always redeem for exactly $1.00 with no fee deducted from the payout. Fees on Polymarket appear as the bid-ask spread in the CLOB and, on certain market categories under CLOB V2 (particularly 15-minute crypto markets), as explicit taker fees that peak around 1.56–1.80% at 50% probability. What infrastructure do I need for a HIP-4 market-making bot in production? At minimum: a WebSocket connection to the HIP-4 outcome book (not just HTTP polling), archive node access for historical market data, and throughput above the 100 req/min public endpoint cap. A Chainstack Dedicated Node removes the rate limit ceiling and provides WebSocket streaming. For settlement-burst handling — when all positions in a daily BTC binary resolve simultaneously — dedicated infrastructure is not optional. Is Hyperliquid HIP-4 available to US traders? No. Hyperliquid geo-blocks US users on both the trading interface and API. Polymarket’s international exchange also blocks US users, but Polymarket has a CFTC-licensed US-facing product via the QCEX acquisition (July 2025) and is actively pursuing CFTC approval to re-open the main exchange to US traders as of April 2026. How is HIP-4 Phase 2 builder stake structured? Builders stake 1,000,000 HYPE per deployment slot — slashable if validators determine the builder manipulated an oracle, caused invalid state transitions, or experienced prolonged downtime. One slot recycles across many sequential markets in a series, so a builder deploying a daily BTC binary that runs for 365 days only needs one slot staked for the entire year. Slashed tokens are burned, not redistributed to stakers. More guides on the Chainstack blog Building a HIP-4 or Polymarket strategy is one piece of a larger stack. If you want to go deeper on either platform’s infrastructure, these posts cover the terrain: Hyperliquid Hyperliquid HIPs explained: HIP-1 to HIP-4 — the full governance arc from token standard to outcome contracts, with step-function settlement mechanics and builder economy details What is Hyperliquid? RPC, API, and trading infrastructure — HyperCore vs HyperEVM architecture, API surfaces, and how developers plug in How to build a Hyperliquid trading bot — from RPC node selection to a working grid bot with WebSocket feeds and order execution Hyperliquid architecture: Clearinghouse, Agent Keys, cross-margin — the unified state tree that makes cross-margin between perps and spot (and now outcomes) possible Polymarket Integrating Chainstack with OpenClaw bot for Polymarket — LLM-powered arbitrage across Polymarket markets via messenger interface How to build a Polymarket bot using Polygon RPC — correlated market detection, hedge portfolios, and why reliable Polygon RPC matters for prediction market bots #### Hyperliquid HIPs Explained: HIP-1 to HIP-4 TL;DR Hyperliquid Improvement Proposals (HIPs) are formal, on-chain protocol upgrades governed by HYPE token holders. Each proposal targets a specific domain: HIP-1 introduced the native token standard and spot order books, HIP-2 embedded an automated liquidity mechanism into HyperCore to solve the cold-start problem for new token launches, and HIP-3 made perpetual futures deployment permissionless for builders who meet the staking requirement. HIP-4, announced February 2, 2026, is the most recent addition. It introduces outcome contracts, binary markets that settle to 0 or 1 in USDH based on whether a specified real-world event occurs. These markets run natively on HyperCore, sharing the same CLOB infrastructure, matching engine, and account system as spot and perpetual markets. Each market moves through a deployment phase, an opening auction, continuous trading, and a final settlement triggered by an authorized oracle. All of this runs on HyperCore, a fully on-chain central limit order book with one-block finality, paired with HyperEVM for general smart contract execution. The two environments share state, and the public API exposes the same endpoints across all market types, making it straightforward for builders to extend existing integrations to new primitives as each HIP activates. Prerequisite Basic understanding of Hyperliquid Familiarity with common DeFi terminologies 📖 It is recommended to read the following blogs about Hyperliquid before you dive into the blog below to get an in-depth understanding about Hyperliquid’s architecture. What are Hyperliquid HIPs? Hyperliquid Improvement Proposal (HIP) is a formal, on-chain protocol upgrade mechanism for the Hyperliquid blockchain. The proposals are authored by builders, reviewed by the community, and implemented directly into HyperCore, the high-performance trading engine at Hyperliquid’s core. The governance model is HYPE token weighted. Any eligible participant can submit a proposal. HYPE holders vote on it, proportional to their stake. If a proposal crosses the approval threshold, the core team integrates it into the protocol stack. This design keeps protocol evolution modular. Each HIP targets one specific domain like token standards, liquidity mechanisms, perpetual markets, and outcome markets rather than bundling broad changes into a single upgrade. This modularity means builders can integrate one primitive at a time without re-architecting existing systems. Hence, the chain never forks but the protocol extends. Hyperliquid architecture overview Before examining Hyperliquid HIPs individually, it helps to understand the execution environment: HyperCore and HyperEVM. HyperCore and HyperEVM shared execution model HyperCore is the fully on-chain central limit order book (CLOB) at the heart of Hyperliquid. All order books, trades, and liquidation is recorded on-chain with one-block finality. There is no off-chain matching layer. This is architecturally significant: the order book state is part of the blockchain state. The consensus mechanism is HyperBFT providing Byzantine Fault Tolerance, runs on a dual-layer design: HyperCore and HyperEVM Source: https://hyperfoundation.org/ HyperCore is paired with HyperEVM, an EVM-compatible execution environment on the same L1. HyperEVM allows Solidity developers to deploy contracts that interact with HyperCore primitives. Standard Ethereum tooling: ethers.js, viem, Foundry, Hardhat works without modification. The two environments share state but are optimized for different workloads: HyperCore handles the high-frequency trading loop, HyperEVM handles general smart contract execution. 📖 For a deeper look at how Hyperliquid’s RPC and API layer works in practice, see What is Hyperliquid? RPC, API, and trading infrastructure. API structure: /info and /exchange The public API exposes two primary endpoints. The /info endpoint handles all read-only queries: market metadata, order book depth, user state, and fills. const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ type: 'activeAssetData', user: '0x31ca8395cf837de08b24da3f660e77761dfb974b', coin: 'BTC' }) }; fetch('<https://hyperliquid-mainnet.core.chainstack.com/API_KEY/info>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); The /exchange endpoint handles all signed write operations: order placement, cancellation, leverage updates, and (for HIP-3/HIP-4) market deployment actions. To know more about authentication on Hyperliquid, read the following documentation to understand L1 actions and user signed actions for administrative operations: https://docs.chainstack.com/docs/hyperliquid-authentication-guide Why Hyperliquid HIPs matter for builders HIPs extend HyperCore in a structured way, adding new market types directly into the core matching and settlement engine. Each proposal introduces a new instrument class while keeping the underlying execution model unchanged. For builders, this creates a stable integration surface. Spot markets, perpetuals, and outcome contracts all run on the same: central limit order book (CLOB) price-time priority matching engine account and margin system API structure (/info for reads, /exchange for writes) Hyperliquid HIPs directly reduce the amount of new infrastructure you need to build every time Hyperliquid introduces a new market type. When a new HIP goes live, that same pipeline continues to work. Supporting a new market becomes a matter of extending your data model rather than redesigning your system. For example: A bot built for spot under HIP-1 can route orders to perpetuals under HIP-3 using the same execution logic. The same bot can trade HIP-4 outcome markets by adjusting position sizing and payoff logic, while reusing order handling, signing, and state tracking In practice, this means a trading system built for one market type already supports the others at a structural level. Differences between HIPs show up as metadata (e.g. asset type, expiry, oracle config) rather than requiring new infrastructure. HIP-1: Native token standard HIP-1 established the formal fungible token standard on Hyperliquid. It introduced a governance-based process for new spot token listings and the on-chain spot order books that back them. Querying spot metadata uses the /info endpoint: // Fetch spot market metadata const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({type: 'spotMeta'}) }; fetch('<https://hyperliquid-mainnet.core.chainstack.com/API_KEY/info>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); The PURR memecoin was the first live deployment of HIP-1 infrastructure. With HIP-2, native liquidity was added for full on-chain spot markets. HIP-2: Hyperliquidity mechanism HIP-2 introduced an on-chain liquidity mechanism embedded directly into HyperCore. When a new spot token launches, Hyperliquidity automatically places buy and sell orders around the current price, seeding the order book with depth before any human market maker participates. When PURR/USDC launched, Hyperliquidity seeded initial depth instantly, real trades executed before any external liquidity provider connected. This solves the cold-start problem that makes new token launches illiquid at inception. The Hyperliquid L1 will support native spot trading, as well as two permissionless standards for native tokens: HIP-1: deploy native tokens and onchain spot order books HIP-2: “Hyperliquidity,” a novel mechanism to permanently commit liquidity to a spot order book for HIP-1… pic.twitter.com/mXlobEumGs— Hyperliquid (@HyperliquidX) March 29, 2024 The mechanism operates continuously for supported tokens, contributing to a stable spread and reducing the impact cost for early traders. From a builder’s perspective, HIP-2 markets are indistinguishable from any other spot market at the API level. The same order book query, same asset index, same fill events. HIP-3: Permissionless perpetuals HIP-3 was activated on Hyperliquid mainnet in October 2025. It made the deployment of perpetual futures markets permissionless. The staking requirement for mainnet is 500k HYPE. A builder meeting the staking requirement can deploy one perpetual DEX. Within that DEX, they control market operation: setting oracle prices, configuring leverage limits, and settling markets if needed. The stake is slashable if a builder triggers invalid state transitions or the oracle price moves more than 50% relative to the start-of-day price without a validator review. Since last week, HIP-3 markets reached new all-time highs of $1B in open interest and $4.8B in 24-hour volume. https://t.co/SdOcpcgDO2— Hyperliquid (@HyperliquidX) February 2, 2026 The ecosystem tracker at trade.xyz, the primary builder deploying under HIP-3, exceeded $2B in single-day volume. Silver and Gold commodity perpetuals launched under HIP-3 reached ~$3B and ~$700M weekly volume respectively, with Hyperliquid holding the deepest on-chain liquidity for gold perpetuals. The NVDA equity perpetual accumulated over $1.2B in cumulative volume. The total market volume reached $4.8B in 24 hours. 📖 If you’re building on top of these markets, this guide walks through how to build a Hyperliquid trading bot from order book data to live execution. HIP-4: Outcome contracts HIP-4 was announced February 2, 2026, with testnet infrastructure active from the announcement date. It introduces a new primitive to HyperCore called outcome contracts: fully collateralized binary instruments that settle to exactly 0 or 1 in USDH based on whether a specified real-world event occurs. Earlier Hyperliquid HIPs (HIP-1, HIP-2, HIP-3) operate on assets with continuous price discovery. Spot and perpetual markets evolve through incremental price updates, with mechanisms like liquidity provisioning (HIP-2) or oracle-guided pricing and constraints (HIP-3) ensuring smooth transitions over time. Outcome contracts follow a different structure: No continuous underlying price process: The instrument represents the probability of a discrete event, bounded in [0,1], rather than tracking an asset price No incremental oracle-driven pricing: Price discovery occurs entirely through the order book during trading; external input appears only at resolution Step-function settlement: The market transitions in a single update from trading price p to final outcome r ∈ {0,1}, instead of converging gradually No funding or basis mechanics: Valuation derives directly from expected payoff, removing the need for funding rates or index alignment This shifts HyperCore from a purely financial trading engine into a generalized marketplace for probabilistic outcomes, while still using the same order book, matching engine, and account system. HyperCore will support outcome trading (HIP-4). Outcomes are fully collateralized contracts that settle within a fixed range. They are a general-purpose primitive that are useful for applications such as prediction markets and bounded options-like instruments. There has been…— Hyperliquid (@HyperliquidX) February 2, 2026 Outcome contracts run natively in HyperCore. They share the same CLOB infrastructure, the same matching engine, and the same trading account system as spot and perpetual markets. There is no separate application, side-chain, or EVM contract handling the primary settlement path. The contract price at any moment represents the market’s implied probability that the specified event will occur. A contract trading at 0.65 implies the market assigns a 65% probability to the event occurring. The contract price p at any point in time is entirely order-book driven. There is no external oracle feeding the market price during trading. The price range is bounded [0.001, 0.999] throughout the trading period, representing the market’s implied probability of the YES outcome. Buying YES at price P: Profit if event occurs = 1 - P Loss if event does not = P Buying NO at price P: Profit if event does not occur = P Loss if event occurs = 1 - P Source: https://app.hyperliquid-testnet.xyz/trade At resolution, a single authorized oracle update sets r ∈ {0, 1}. Trading halts. Resting orders are cancelled. All positions settle to their final PnL. Every HIP-4 outcome market moves through certain phases. Let’s go through each of them from deployment of the market to settlement. Deployment A builder deploys an outcome market into a slot within their event DEX. The staking requirement is 1,000,000 HYPE, double the HIP-3 requirement. This stake is slashable if the builder attempts oracle manipulation or triggers invalid state transitions. Slashed HYPE is burned. Event DEXes are designed with multiple market slots. Once a market resolves, its slot is immediately available for a new event. A single 1M HYPE stake can power a rolling series of markets without requiring re-participation in the deployment auction each time. A recurring market for the price of $HYPE is deployed every 15 minutes. Check out one instance here: Source: https://app.hyperliquid-testnet.xyz/explorer Hash: unique identifier for the deployment Block: the block where the market was created Time: deployment timestamp User: address that initiated the action Type: action used to register the market class:priceBinary: a binary outcome market (YES/NO) underlying:HYPE: the asset being tracked expiry:20260401-1845: when this specific market resolves targetPrice:38: the outcome condition period:15m: new markets are deployed every 15 minutes Each instance (recurring, 15 mins) asks a simple question: will $HYPE be above or below the targetPrice at the specified expiry? Opening Auction Rather than opening into continuous trading directly, each market starts with a single-price clearing auction lasting approximately 15 minutes. This removes first-mover advantage and produces a fair opening price based on the full distribution of submitted orders. During this window, participants submit orders but no matching happens during collection. At the end of the window, the engine runs through all candidate prices The opening price p*selected is the one that the one where the most contracts can trade (max matched volume) All orders are on the better side of p* fill first. Orders exactly at p* share the remaining volume pro rata. Every execution prints at p* (one opening price) Unfilled orders carry forward into continuous trading at their original limit prices Source: https://www.bedlamresear.ch/posts/hip-4-event-futures/ Continuous Trading After the auction clears, the market enters continuous CLOB trading with price-time priority. The mark price is derived from the order book mid-price rather than an external oracle. There is no funding, and price discovery is entirely peer-driven. The valid price range is [0.001, 0.999]. No leverage is permitted. // Fetch outcome metadata const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({type: 'outcomeMeta'}) }; fetch('<https://hyperliquid-testnet.core.chainstack.com/API_KEY/info>', options) .then(res => res.json()) .then(res => console.log(res)) .catch(err => console.error(err)); Settlement When the event resolves, the authorized oracle posts the final outcome via VoteGlobalAction. Trading halts immediately upon settlement. All open positions auto-close in USDH. If a challenge window was configured, oracle outputs can be disputed before settlement finalizes. After settlement, the slot is recycled and available for a new event. This transaction represents the settlement of an outcome market: Source: https://app.hyperliquid-testnet.xyz/explorer outcome:2916: the specific market being settled settleFraction:0: the market resolves to NO (0) details:"price:37": the final observed price used for settlement This was a priceBinary market: Will $HYPE be above 38 at expiry? At resolution, the observed price was 37, which is below the target : 38. As a result: NO resolves to 1 (wins) YES resolves to 0 (loses) Builder tools and ecosystem Platforms like Polymarket (built on Polygon) and Kalshi operate with collateral pools isolated from the rest of DeFi. HIP-4 enables prediction market functionality with USDH settlement, cross-margin against other Hyperliquid positions, and HyperCore execution speed. “On Polymarket you wait for UMA oracle resolution. On Kalshi you wait for the platform to confirm. On Hyperliquid the L1 reads the price and pays you immediately.This is what native settlement looks like.”✅native oracle✅no friction✅instant✅near zero cost for the user https://t.co/81Qm1JEwYs— smartestmoney.hl (@smartestmoney) March 26, 2026 If this excites you to build on Hyperliquid, refer the below links for core references for understanding HIPs, APIs and existing implementations: Hyperliquid HIPs: The official documentation by Hyperliquid to all the HIPs Overview of all Hyperliquid Improvement Proposals, including architecture and design goals API & SDKs: Complete API & SDKs documentation for trading, data access, and integration Trade.xyz: Early HIP-3 deployer for commodity and equity perpetual markets Outcome.xyz: Early HIP-4 builder focused on event-driven DEXs and outcome markets Chainstack: Dedicated RPC infrastructure with WebSocket support, optimized for trading bots, indexers, and production systems Liquid Terminal HIP-4 Docs: Reverse-engineered documentation from bytecode and live transactions; unofficial documentation HypeDexer Testnet Overview: Explorer and dataset reference for tracking outcome markets and on-chain activity 📖 For a practical example of tracking on-chain activity across these markets, see How to build a Hyperliquid on-chain activity tracker. Key considerations for HIP-4 Integrating with HIP-4 outcome markets involves assumptions that differ from perpetuals. Builders should account for these before deploying production systems. Oracle dependency: Settlement depends on an authorized oracle posting a correct binary outcome. If the oracle is compromised or posts an incorrect result, traders can dispute within the challenge window, but resolution may take time. Builders constructing automated strategies around outcome markets should model dispute scenarios in their settlement logic. Expiry-driven load: When multiple outcome markets resolve simultaneously, HyperCore processes a burst of margin recalculations and balance updates. Production integrations should anticipate this load pattern. WebSocket subscriptions handle resolution events more reliably than polling REST endpoints during these windows. Staking concentration: The 1,000,000 HYPE staking requirement for HIP-4 deployment (versus 500,000 for HIP-3) reflects the additional complexity of oracle-dependent instruments. Not every team will be able to meet this threshold. Market creation will be concentrated among well-capitalized builders in the early phases. Validator set size: As of early 2026, Hyperliquid’s validator set has grown to 21 validators. Smaller validator sets increase the importance of monitoring governance decisions that affect validator composition. No official HIP-4 specification: Hyperliquid has published no formal HIP-4 spec. Community documentation at Liquid Terminal was produced by reverse-engineering bytecode and transaction data from testnet. Builders should treat this documentation as exploratory and validate behavior directly against testnet before committing to production patterns. Mainnet phase: HIP-4 mainnet will launch in two phases: curated canonical markets first, permissionless builder deployment second. Builders cannot deploy their own markets on mainnet until phase two. No date for either phase has been confirmed. Conclusion Hyperliquid HIPs represent a deliberate approach to protocol evolution: modular, governance-driven, and additive. Each proposal extends HyperCore with a focused primitive without requiring existing integrations to be rearchitected. HIP-1 laid the foundation with a native token standard, HIP-2 solved liquidity bootstrapping, HIP-3 opened perpetual market deployment to builders, and HIP-4 brings outcome contracts natively into the same execution environment. HIP-4 in particular expands what builders can construct on Hyperliquid. Outcome contracts open the door to prediction market functionality, event-driven structured products, and cross-market arbitrage, all settled in USDH and margined within the same account as other Hyperliquid positions. Early volume data from HIP-3 deployments like commodity and equity perpetuals points to real demand for these kinds of builder-deployed primitives. HIP-4 is still on testnet, with permissionless deployment following canonical markets in phase two. But the infrastructure is already live and the API surface is consistent with every prior HIP. Builders who start integrating now will be positioned before the market opens. Get a Hyperliquid RPC endpoint on Chainstack to start building. Start building on Chainstack→ FAQ What is a Hyperliquid Improvement Proposal (HIP)? A HIP is a formal, on-chain protocol upgrade for Hyperliquid, governed by HYPE token holders. Builders author proposals, the community votes proportional to stake, and approved changes are integrated directly into HyperCore. What is the difference between HIP-3 and HIP-4? HIP-3 made perpetual futures deployment permissionless for builders who stake 500k HYPE. HIP-4 introduces outcome contracts — binary markets that settle to 0 or 1 — with a higher staking requirement of 1M HYPE due to oracle dependency. How do outcome contracts work on Hyperliquid? Outcome contracts are binary instruments priced between 0.001 and 0.999, representing the market’s implied probability of an event occurring. They go through an opening auction, continuous CLOB trading, and settle to 0 or 1 in USDH when an authorized oracle posts the final result. Can I build on HIP-4 on mainnet right now? Not yet for permissionless deployment. HIP-4 mainnet launches in two phases — curated canonical markets first, builder deployment second. No date for either phase has been confirmed. Testnet infrastructure is active. Do I need to rewrite my trading infrastructure for each new HIP? No. All HIPs run on the same CLOB, matching engine, and API structure. A system built for spot under HIP-1 can extend to perpetuals and outcome contracts by adjusting metadata and payoff logic, not by rebuilding infrastructure. What staking is required to deploy a HIP-4 outcome market? 1,000,000 HYPE, double the HIP-3 requirement. The stake is slashable if the builder attempts oracle manipulation or triggers invalid state transitions. Slashed HYPE is burned. Related Reading What is Hyperliquid? RPC, API, and trading infrastructure How to build a Hyperliquid trading bot How to build a Hyperliquid on-chain activity tracker Best Hyperliquid RPC providers in 2026 Most cost-effective Hyperliquid RPC providers in 2026 Mastering Hyperliquid — full guide series #### Hyperliquid HyperBFT: spot vs perp, and sub-accounts If you read Part 1 of this series, we established a fundamental architectural reality: if you want to build a fully on-chain Central Limit Order Book (CLOB) capable of mathematically rivaling centralized exchanges, you cannot force it into a generic virtual machine. General-purpose VMs carry a massive latency tax because they must dynamically meter gas for every computation. To achieve sub-millisecond finality and handle massive throughput, the order book cannot merely live inside a smart contract, the order book must be the blockchain. This is exactly the thesis behind Hyperliquid. But knowing why a protocol built a sovereign, dual-engine architecture (HyperCore and HyperEVM) is only half the battle. The real engineering magic lies in how they actually pull it off. How does a network process 200,000 orders per second without choking on state contention? How do we achieve the deterministic, one-block finality that high-frequency market makers demand? And perhaps most importantly for EVM developers: how do standard Solidity contracts natively interact with a closed, highly-specialized financial state machine without relying on external, lagging oracles? In Part 2 we go under the hood — dissecting how Hyperliquid HyperBFT achieves deterministic one-block finality, how Spot and Perp accounting differ at the L1 state level, and how sub-accounts enable programmatic risk isolation for trading bots. The engine room, Hyperliquid HyperBFT and one-block finality 📖 For a high-level overview of Hyperliquid HyperBFT, see What is Hyperliquid? — this section goes deeper into why deterministic finality is a hard requirement for market makers. To build a decentralized exchange that institutional market makers actually want to use, you have to solve the “finality problem.” In traditional blockchain environments like Ethereum or its rollups, finality is probabilistic. You submit a transaction, it sits in a mempool, it gets picked up by a block builder, and then you wait for several block confirmations (or in the case of optimistic rollups, a massive challenge period) to be absolutely certain your transaction won’t be reverted in a chain re-org. Even on highly optimized parallel networks like Solana, you are dealing with a layered finality model where leaders can occasionally skip slots, creating micro windows of uncertainty. For a yield farmer depositing USDC into Aave, a 12-second block time with probabilistic finality is perfectly fine. But for a market maker algorithmically updating their quotes 1,000 times a second across dozens of assets, uncertainty is money loss. If a bot sends an API request to cancel an order, it needs to know immediately and irrevocably that the order is off the book before quoting the next price. If there is even a fractional risk of a block re-org bringing that cancelled order back from the dead, the market maker will get arbitraged. This strict requirement for deterministic execution is why Hyperliquid had to build its consensus layer from scratch. Hyperliquid utilizes a custom consensus algorithm known as Hyperliquid HyperBFT, which was heavily inspired by Hotstuff and its successors. Rather than relying on probabilistic models, HyperBFT operates on a deterministic, one-block finality model. Once the validator set agrees on a block, the state transition is permanent. There are no chain re-orgs and no waiting for epoch finalization. Because the underlying consensus guarantees immediate permanence, every single order, cancel, trade, and liquidation executed by the network happens transparently with this exact one-block finality inherited directly from HyperBFT. This architecture practically eliminates the predatory MEV dynamics that plague EVM automated market makers. On generic chains, block builders can actively hold your transaction in the mempool, observe your slippage tolerance, and inject their own trades before and after yours to sandwich your execution. On Hyperliquid, the sub-millisecond block times and strict sequencing of Hyperliquid HyperBFT force transactions into the matching engine at breakneck speeds, fundamentally protecting the integrity of the Central Limit Order Book (CLOB) from traditional block-reordering attacks. The architecture of accounting, spot vs. perps Before a transaction can even hit that blazing-fast matching engine we discussed, the L1 has to know exactly what kind of assets it is managing. This brings us to the fundamental differences in how Hyperliquid handles state. The protocol’s core execution layer, HyperCore, includes fully onchain perpetual futures and spot order books. However, from an engineering perspective, Spot and Perps require vastly different accounting architectures. Spot Mechanics: Asset Transfers Spot trading is mathematically straightforward. If you place a limit order to buy 1 Spot BTC using USDC, and that order is matched, the resulting state transition is essentially a two-way asset transfer. The network deducts USDC from your balance and credits you with 1 BTC. You now hold the underlying base asset. In an EVM context, this is equivalent to a simple ERC-20 transfer function updating two balances. On Hyperliquid, it is a native state mutation handled instantly within the node’s memory. Perp Mechanics: Native Collateral Management Perpetuals are a completely different beast. When trading perps, you aren’t transferring base assets, you are trading synthetic contracts. This means the L1 state machine is strictly tasked with managing collateral, tracking entry prices, and processing liquidations natively within the L1. Every time the index price updates or a trade executes, the node software must calculate your Unrealized PnL, check your maintenance margin requirements, and determine if your account is solvent. On generic networks, processing this complex state across thousands of active positions creates massive compute bottlenecks. On HyperCore, this margin logic is baked directly into the validator client. It never has to load a smart contract to figure out if you are liquidatable. It knows intrinsically. The Unified Advantage: Protocol-Level Portfolio Margin This stark architectural contrast between Spot and Perps brings us back to the Portfolio Margin concept we explored in Part 1. Because the developers control the actual L1 execution client, they built a unified data structure that natively understands both straightforward spot balances and complex perpetual margin requirements. It unifies your spot holdings and perpetual positions into a single global balance. If you hold that 1 Spot BTC we mentioned earlier, the native Clearinghouse state immediately recognizes its USD value and allows you to use it as cross-margin collateral for your Perp positions. There is no bridging assets between protocols and no depositing into fragmented smart contract vaults, just native, protocol-level capital efficiency. Reading Raw L1 State with curl: Master Wallet Example To see how this architectural risk isolation translates into reality, look no further than the native UI. https://app.hyperliquid-testnet.xyz/subAccounts Notice the exact state of this wallet (0x09174...274e8). The Spot Account Equity holds $798.65, while the Perps Account Equity is empty. If you were building a frontend for a traditional EVM protocol, rendering these two columns would require the client to make asynchronous balanceOf calls to completely different smart contracts. But because Hyperliquid is a specialized L1, the frontend doesn’t query smart contracts, it directly queries the validator node’s in-memory state. We can actually bypass the UI entirely and verify this strict class separation using the native API. If we fire a standard curl request to the L1’s /info endpoint, we can ask the node to deserialize the state for this exact Ethereum address. To check the Perps account (which the UI shows as empty), we query the clearinghouseState: curl -X POST https://api.hyperliquid-testnet.xyz/info \ -H "Content-Type: application/json" \ -d '{"type": "clearinghouseState", "user": "0x09174CC31425746672737a0c3d06Fb27E82274e8"}' | jq Output { "marginSummary": { "accountValue": "0.0", "totalNtlPos": "0.0", "totalRawUsd": "0.0", "totalMarginUsed": "0.0" }, "crossMarginSummary": { "accountValue": "0.0", "totalNtlPos": "0.0", "totalRawUsd": "0.0", "totalMarginUsed": "0.0" }, "crossMaintenanceMarginUsed": "0.0", "withdrawable": "0.0", "assetPositions": [], "time": 1776982271519 } Because we haven’t executed a usdClassTransfer to move funds into the Perps engine, the L1 returns a marginSummary with a totalRawUsd of "0.0". But if we change the request type to query the Spot engine (spotClearinghouseState), the node instantly returns the isolated Spot state: curl -X POST https://api.hyperliquid-testnet.xyz/info \ -H "Content-Type: application/json" \ -d '{"type": "spotClearinghouseState", "user": "0x09174CC31425746672737a0c3d06Fb27E82274e8"}' | jq Output { "balances": [ { "coin": "USDC", "token": 0, "total": "798.0", "hold": "0.0", "entryNtl": "0.0" }, { "coin": "TZERO", "token": 1204, "total": "0.0", "hold": "0.0", "entryNtl": "0.0" }, { "coin": "UETH", "token": 1242, "total": "0.006404022", "hold": "0.0", "entryNtl": "2.67278865" }, ... ], "tokenToAvailableAfterMaintenance": [ [ 0, "798.0" ] ] } This specific response explicitly shows the isolated Spot state of this account. But if you look closely at the payload, it reveals exactly how the HyperCore execution engine manages internal accounting. The Architecture of Asset IDs Look at the balances array. Under UETH (Testnet ETH), it says "token": 1242. In the Hyperliquid API response, the "token" field does not represent how many tokens you own. Instead, it represents the internal numeric Asset ID (or Token Index) assigned to that specific asset by the L1 state machine. Your actual balance is tracked under the "total" field. Why does the API use these numbers? As we discussed earlier, Hyperliquid is optimized for extreme high-frequency trading. When a trading bot sends a raw JSON order payload to the network, passing string tickers like "UETH" or "USDC" wastes bytes and compute time. Instead, the network assigns a strict integer ID to every single asset. USDC is 0. UETH is 1242. Solving the UI Mystery: Equity vs. Balance This JSON also solves a major point of confusion for developers migrating from generic EVMs. If you look at our UI screenshot from earlier, the Master Account showed a Spot Account Equity of $798.65. But looking at the JSON, your USDC "total" is only 798.0. Where did the extra 65 cents come from? The UI does not just display your raw cash. “Equity” represents the total aggregated USD value of every single asset sitting inside that Spot account natively calculated by the L1. If we do the math based on our raw JSON: USDC: $798.00 UETH: ~ $0.64 (The live USD value of 0.006404022 ETH) $798.00 + $0.64 = $798.64 (which the UI rounds to $798.65 based on micro-fluctuations in the ETH oracle price). Available Equity Finally, look at the very bottom of the payload at the second data structure: tokenToAvailableAfterMaintenance. It returns a nested array: [0, "798.0"]. The 0 is the internal L1 Asset ID (which we just established is USDC). The "798.0" is the free capital. In high-frequency trading, your "total" balance is rarely the same as your usable balance. If you place a limit order to buy an asset, that order hasn’t filled yet, but it locks up capital. The L1 matching engine immediately updates your "hold" field to reflect this. If you are writing a quantitative trading bot, you don’t want to manually loop through the balances array, find your total, and mathematically subtract your holds just to figure out if you have enough free capital to execute your next trade. Instead, the tokenToAvailableAfterMaintenance field does the heavy lifting for you. It explicitly tells your bot exactly how much raw USDC (Token 0) is free to be deployed, withdrawn, or transferred to the Perps account right now, natively factoring in any locked funds. Because your "hold" is currently "0.0", the L1 confirms your full 798.0 USDC is available. While we have another $0.65 of equity sitting in UETH, you cannot use ETH to place a direct bid on a BTC trading pair. You would have to sell the UETH first. Therefore, the L1 correctly isolates your available purchasing power and reports it as exactly 798.0 USDC. The transfer boundary: you can’t spend what’s “isolated” This architectural isolation leads to a critical operational rule that often trips up new developers: The Spot and Perp engines are legally distinct states. If you have 798 USDC in your Spot account, your Perp account is still mathematically zero. You cannot simply “open a long” using your Spot balance. To move capital between these two engines, you must execute a specific L1 transaction called a usdClassTransfer. Think of it as an internal bridge between two high-frequency servers. When you move USDC from Spot to Perps: The Spot engine debits your balance and marks the transaction as final. The Perp engine credits your collateral and updates your marginSummary in the next block. This isn’t just a UI quirk, it’s a safety feature. By requiring an explicit transfer, the protocol ensures that a massive liquidation in your high-leverage Perp account can never “leak” into your Spot account and sweep your long-term asset holdings. (you will see code examples in next blog) The portfolio: a direct window into L1 state https://app.hyperliquid-testnet.xyz/portfolio If you were building this dashboard for a traditional Ethereum DEX, populating this page would be an infrastructural nightmare. You would need to query a centralized indexing server (like The Graph), run dozens of asynchronous RPC calls to different smart contracts to fetch balances, and ping external oracles just to calculate the USD value of your holdings. But because Hyperliquid is a specialized App-Chain, this Portfolio UI is essentially just a visual wrapper around the exact curl commands we ran earlier. The frontend does not query a backend database; it queries the validator node directly. When you load this page, the UI hits the /info endpoint, grabs your clearinghouseState and spotClearinghouseState, and does the basic arithmetic we just walked through: It matches the internal Asset IDs (like 0 for USDC and 1242 for UETH) to their human-readable tickers. It checks the native oracle prices (explained later) to calculate the USDC Value of your volatile assets. It checks the tokenToAvailableAfterMaintenance array to display the Available Balance, natively hiding any capital locked in open limit orders. There are no smart contracts acting as middlemen. What you see on this screen is the exact, millisecond-accurate state of your account sitting in the RAM of the network’s validators. The architecture of sub-accounts: programmatic risk isolation If you are a trader running five different algorithmic strategies, you do not want your high-leverage momentum bot sharing the same margin pool as your low-risk statistical arbitrage bot. In a standard EVM environment, you would have to generate five completely different Wallet seed phrases and fund them all separately, incurring massive UX friction and gas fees for every internal transfer. Hyperliquid solves this natively at the protocol level. Your Master Account can programmatically spawn Sub-Accounts. What exactly is a Sub-Account? A sub-account is a unique 0x address that acts as an isolated sandbox for your capital. To the L1 state machine, a sub-account is treated as a first-class citizen. This means it has its own independent clearinghouseState and spotClearinghouseState. If we wanted to check the health of a specific bot, we wouldn’t query the Master Account and filter through the mapping. We simply fire the exact same curl request we used earlier, but swap in the sub-account’s unique address. Sub-accounts do not have private keys. You cannot “log in” to a sub-account via MetaMask because it doesn’t have its own EOA credentials. Instead, its authority is derived strictly from your Master Account. When a trading bot submits an order for a sub-account via the API, it uses the Master Account’s Agent Key to sign the payload, but includes a specific field: vaultAddress (the sub-account’s address). The L1’s execution engine sees the Master signature, verifies the ownership, and then executes the trade against the sub-account’s isolated margin pool. ℹ️ Note: Before you start spawning bots, there is a specific protocol guardrail you need to know about: You can create up to 10 sub-accounts only after your Master Account reaches $100,000 in trading volume. Anatomy of a trade: a microsecond lifecycle We have officially proved that our isolated Spot wallet has 798.0 USDC of free capital ready to deploy. Now, let’s put it to work. To execute a trade, you navigate to the trading interface. https://app.hyperliquid-testnet.xyz/trade When you look at this trading module, you aren’t just looking at a UI, you are looking at a real-time visualization of the L1 State Machine constraints. The “Available to Trade” Logic: Notice the value 725.74 USDC. As we saw in our spotClearinghouseState curl command, this isn’t just a balance pulled from a wallet. This is the tokenToAvailableAfterMaintenance value. The UI is subtracting any capital currently “locked” in other open limit orders. From click to Consensus When you hit that teal Buy button, a specific chain of events is triggered in microseconds: Signing: Your browser (or API agent) signs a localized transaction. Unlike Ethereum, this isn’t an “approve” and “swap” two-step dance. It is a single, signed instruction. Ingestion: The transaction hits a validator. Because of HyperBFT, it doesn’t wait in a public mempool to be “sniped.” It is sequenced immediately. Matching vs. Settlement: The matching engine checks if there is a resting “Sell” order at your price. If matched: The L1 atomically updates the balances (the total field in our JSON) for both parties. If not matched: Your USDC is moved from total to hold, and your order is published to the book. Finality: Within one block, the trade is immutable. There is no “pending” state, the moment the UI updates, the state transition on the blockchain is already history. Output The confirmation: L1 state verification If you recall from Part 1, we defined a blockchain as a shared state machine. This image, taken from the “Order History” tab, is a visual serialization of that state. It confirms multiple architectural truths we’ve just discussed. Let’s dissect this snapshot: Status: Open. This confirms that the custom consensus mechanism we analyzed (HyperBFT) has achieved finality. This isn’t a “pending” transaction waiting for confirmation or a mempool ingestion notification. This means the L1 state has been updated, and the Central Limit Order Book (CLOB) now recognizes your buy bid at 0.60212. Order ID: 51953570647: This isn’t a hash. It is a unique L1 Order ID. As we learned during our curl command analysis, string lookups are expensive for a high-performance exchange. The HyperCore matching engine uses this integer ID as the index for all future operations, such as cancels or partial fills. Order Value and Capital Management. While entered a size of 120 USDT, the next column: Order Value 72.25 USDC. This confirms that USDC is the native settlement asset for the Spot engine. This is the transaction: this transaction offering exactly 72.25 USDC to buy 120.00 USDT at the defined price. Summary We have spent this section using the Hyperliquid UI and raw API calls as a “visual debugger” to prove a fundamental point: this is not just a website, it is a direct window into a specialized L1 state machine. Every balance, every equity calculation, every available capital figure you see on screen is a live serialization of validator RAM — no smart contracts, no indexers, no oracles in between. For production systems querying this state at high frequency, the public testnet endpoint won’t cut it — it’s rate-limited and shared. On Chainstack, you get a private Hyperliquid endpoint with dedicated throughput, 99.9% uptime SLA, and WebSocket support for real-time streaming. The same curl commands we ran throughout this article work out of the box against your Chainstack endpoint. Deploy a Hyperliquid node on Chainstack → What’s Next? Now that we understand the architectural “why” and the intuitive “how,” it is time to peel back the another layer. In Part 3, we are leaving the browser behind and diving straight into the low-level code. We will dissect the HyperEVM precompiles that bridge Solidity to the matching engine, and start building custom agents using the SDKs. FAQ What is Hyperliquid HyperBFT and how does it achieve one-block finality? HyperBFT is Hyperliquid’s custom consensus algorithm inspired by HotStuff. It operates on a deterministic finality model — once validators agree on a block, the state transition is permanent. There are no re-orgs and no waiting for epoch finalization, which means every order, cancel, and liquidation is immediately irreversible. What is the difference between Spot and Perp accounts on Hyperliquid? Spot and Perp are two legally distinct states on HyperCore. Your Spot account holds base assets like USDC and tokens. Your Perp account holds collateral for margin trading. You cannot open a perp position using funds in your Spot account — you must first execute a usdClassTransfer to move capital between the two engines. What is usdClassTransfer on Hyperliquid? usdClassTransfer is a native L1 action that moves USDC between your Spot and Perp engines. It is an explicit transfer — Spot debits, Perp credits in the next block. This isolation is a safety feature: a liquidation in your Perp account can never sweep your Spot holdings. What are Hyperliquid sub-accounts and how do they work? Sub-accounts are isolated 0x addresses spawned from your Master Account. Each has its own independent clearinghouseState and spotClearinghouseState. They have no private keys — trading bots sign orders using the Master Account’s Agent Key with a vaultAddress field. You can create up to 10 sub-accounts after your Master Account reaches $100,000 in trading volume. What is tokenToAvailableAfterMaintenance in the Hyperliquid API? It is a field in the spotClearinghouseState response that returns your free, deployable capital after accounting for any funds locked in open limit orders. For trading bots, this is more useful than the raw total balance — it tells you exactly how much capital is available to deploy right now without having to manually subtract holds. What are Asset IDs in the Hyperliquid API? Asset IDs are internal integer indexes assigned to every asset by the HyperCore state machine. USDC is always 0. Other tokens get numeric IDs (e.g. UETH = 1242). The API uses integers instead of string tickers to minimize bytes and compute time for high-frequency trading operations. Related Reading What is Hyperliquid? RPC, API, and trading infrastructure Hyperliquid architecture: Clearinghouse and Agent Keys How to build a Hyperliquid trading bot Best Hyperliquid RPC providers in 2026 Mastering Hyperliquid — full guide series #### Hyperliquid: HyperEVM precompiles, CoreWriter, and HyperCore bridge In Part 1, we established the core architectural tradeoff behind Hyperliquid: a fully on-chain order book cannot behave like a centralized exchange if every order, cancel, and liquidation has to fight through a generic VM. In Part 2, we went one level deeper. We looked at HyperBFT, spot vs perp accounting, sub-accounts, and the lifecycle of a trade from click to L1 state transition. Now we reach the layer that matters most for builders: how does Solidity actually touch this specialized state machine? HyperEVM is not just an EVM chain deployed next to HyperCore. It has native read and write lanes into HyperCore. The read lane is exposed through precompiles. The write lane is exposed through the CoreWriter system contract. This is where Hyperliquid becomes interesting for protocol developers. A Solidity contract can read L1 order book state, oracle prices, spot balances, margin summaries, vault equity, and user positions without waiting for a third-party oracle. It can also send certain actions back into HyperCore by emitting a specially encoded system log. In this post, we are going to unpack that bridge. We will query real HyperCore state from HyperEVM using raw eth_call, decode the integer pricing model, build Solidity wrappers around the precompiles, and then inspect how CoreWriter turns bytes into HyperCore actions. Why HyperEVM needs native HyperCore reads On a normal EVM chain, a smart contract only knows about EVM state. If a lending protocol needs the BTC price, it calls an oracle. If a vault wants to know a user’s position on an exchange, it needs an off-chain keeper, a Merkle root, a signed message, or a bridge message. If a strategy contract wants to reason about an order book, it usually cannot read the order book directly because the order book lives somewhere else. That separation creates a familiar latency stack: The exchange state changes. An off-chain process observes the change. The process pushes the update to a contract or oracle. The consuming contract reads the delayed representation. This is fine for many DeFi applications, but it is a poor fit for an exchange-native chain. Hyperliquid has a different constraint. HyperCore already owns the financial state: orders, positions, spot balances, margin, vault equity, oracle prices, and liquidations. HyperEVM exists next to that state. So the obvious question is: How can Solidity read HyperCore without pretending that HyperCore is an external chain? The answer is precompiles. Precompiles are special addresses where the EVM does not execute deployed bytecode. Instead, the client recognizes the address and runs native logic. Ethereum already uses this model. HyperEVM extends the idea to expose HyperCore state. The important architectural point is this: HyperEVM contracts do not read an oracle copy of HyperCore. They call native precompiles that return HyperCore state as of the EVM block construction point. That means the bridge is not a third-party data feed. It is part of the node’s execution environment. This is the same shift we saw in Solana Token-2022 extensions. Instead of pushing meaning into external conventions, the protocol exposes explicit state through the execution layer itself. The read precompile map HyperEVM read precompiles live in a compact address range starting at: 0x0000000000000000000000000000000000000800 Each address corresponds to one native HyperCore query. Some of the most important ones are: 0x0000000000000000000000000000000000000800 position 0x0000000000000000000000000000000000000801 spotBalance 0x0000000000000000000000000000000000000802 userVaultEquity 0x0000000000000000000000000000000000000803 withdrawable 0x0000000000000000000000000000000000000806 markPx 0x0000000000000000000000000000000000000807 oraclePx 0x0000000000000000000000000000000000000808 spotPx 0x0000000000000000000000000000000000000809 l1BlockNumber 0x000000000000000000000000000000000000080a perpAssetInfo 0x000000000000000000000000000000000000080b spotInfo 0x000000000000000000000000000000000000080c tokenInfo 0x000000000000000000000000000000000000080e bbo 0x000000000000000000000000000000000000080f accountMarginSummary 0x0000000000000000000000000000000000000810 coreUserExists The full list with struct definitions is in Hyperliquid’s L1Read.sol reference on the Interacting with HyperCore docs page. The first thing to notice is that these are not normal Solidity functions. If you write an interface like this: interface WrongOracle { function oraclePx(uint32 index) external view returns (uint64); } and call it at 0x0000000000000000000000000000000000000807, the EVM will send a 4-byte function selector before the argument. That is not what the precompile expects. The precompile expects raw ABI-encoded input only. For oraclePx(uint32 index), the calldata is just: abi.encode(uint32(index)) Taken from L1Read.sol No selector. No method ID. Just the argument payload. That is why the official helper contract wraps the call using low-level staticcall. The pattern looks like this: library HyperCoreRead { address constant ORACLE_PX = 0x0000000000000000000000000000000000000807; function oraclePx(uint32 index) internal view returns (uint64) { (bool ok, bytes memory out) = ORACLE_PX.staticcall(abi.encode(index)); require(ok, "oraclePx precompile failed"); return abi.decode(out, (uint64)); } } This is a subtle but important difference from a normal contract interface. Note. A precompile is not a normal Solidity contract with a function dispatcher. It is a reserved address where the VM/client runs native protocol logic. In a normal contract, the first 4 bytes of calldata tell the contract which function to execute. In a precompile, the address itself already selects the native operation. The calldata format is whatever that precompile defines. For Hyperliquid read precompiles, that format is raw ABI-encoded arguments, so the helper uses low-level staticcall to send exactly that payload. Price reads: oracle price and BBO Let’s query a real precompile directly. We will use testnet and read the oracle price for perp asset index 3. The calldata is a single ABI-encoded uint32: 0x0000000000000000000000000000000000000000000000000000000000000003 Now call the oracle price precompile: curl -s -X POST https://rpc.hyperliquid-testnet.xyz/evm \ -H "Content-Type: application/json" \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "eth_call", "params": [ { "to": "0x0000000000000000000000000000000000000807", "data": "0x0000000000000000000000000000000000000000000000000000000000000003" }, "latest" ] }' The output at the time of testing was: { "jsonrpc": "2.0", "id": 1, "result": "0x000000000000000000000000000000000000000000000000000000000009a255" } Decode the result: 0x9a255 = 631381 At first glance, this looks wrong. BTC is not trading at 631381. This is where the integer model matters. HyperCore does not return floating point numbers. It returns scaled integers. For perps, the Hyperliquid docs define the conversion as: human price = raw price / 10^(6 - szDecimals) The /info endpoint tells us that testnet perp index 3 is BTC and has: { "name": "BTC", "szDecimals": 5, "maxLeverage": 40, "marginTableId": 54 } You can check that with: curl -s -X POST https://api.hyperliquid-testnet.xyz/info \ -H "Content-Type: application/json" \ --data '{"type":"meta"}' So the divisor is: 10^(6 - 5) = 10 The human price is: 631381 / 10 = 63,138.1 Now the value makes sense. The key idea is that the precompile is returning the L1 integer representation, not a frontend-formatted decimal string. Photo was taken with a delay If you build a Solidity protocol on top of these values, this is the exact place where bugs happen. A contract that assumes all prices are 1e8 scaled will silently misprice assets with different szDecimals. Reading the best bid and offer The same pattern applies to the best bid and offer precompile. The precompile lives at: 0x000000000000000000000000000000000000080e It takes an asset index and returns two uint64 values: struct Bbo { uint64 bid; uint64 ask; } you can find all the relevant structs in L1Read.sol All relevant structs are in L1Read.sol from the Hyperliquid docs. Let’s query the same BTC perp index: curl -s -X POST https://rpc.hyperliquid-testnet.xyz/evm \ -H "Content-Type: application/json" \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "eth_call", "params": [ { "to": "0x000000000000000000000000000000000000080e", "data": "0x0000000000000000000000000000000000000000000000000000000000000003" }, "latest" ] }' The output was: { "jsonrpc": "2.0", "id": 1, "result": "0x000000000000000000000000000000000000000000000000000000000009a33a000000000000000000000000000000000000000000000000000000000009a42a" } This is two ABI words packed together: bid raw = 0x9a33a = 631610 ask raw = 0x9a42a = 631850 Using the same BTC divisor: bid = 631610 / 10 = 63161.0 ask = 631850 / 10 = 63185.0 The spread is visible directly from HyperCore state. Just an EVM static call into the native order book state. Here is a Solidity wrapper: library HyperCoreBbo { address constant BBO = 0x000000000000000000000000000000000000080e; struct Bbo { uint64 bid; uint64 ask; } function bbo(uint32 asset) internal view returns (Bbo memory) { (bool ok, bytes memory out) = BBO.staticcall(abi.encode(asset)); require(ok, "bbo precompile failed"); return abi.decode(out, (Bbo)); } } Note. Under the hood, this is exactly the same ABI behavior as the raw curl call. Solidity just makes the decode more readable. Account state: balances, positions, and margin Prices are only the first layer. The more interesting precompiles expose account-level state. For example, the spot balance precompile returns: struct SpotBalance { uint64 total; uint64 hold; uint64 entryNtl; } This maps directly to what we saw in Part 2. When a user places a resting spot buy order, their entire balance does not disappear. Some of it is moved into hold. The UI then shows “available to trade” by subtracting the locked capital. In Solidity, the read looks like this: library HyperCoreBalances { address constant SPOT_BALANCE = 0x0000000000000000000000000000000000000801; struct SpotBalance { uint64 total; uint64 hold; uint64 entryNtl; } function spotBalance(address user, uint64 token) internal view returns (SpotBalance memory) { (bool ok, bytes memory out) = SPOT_BALANCE.staticcall(abi.encode(user, token)); require(ok, "spotBalance precompile failed"); return abi.decode(out, (SpotBalance)); } } A protocol can now reason about the difference between total balance and usable balance. That matters for several use cases: A vault contract can check if a user still has enough idle spot collateral. A liquidation helper can verify whether a user is already locked into open orders. A structured product can gate deposits based on Core balances instead of asking the user to move everything into an ERC20 wrapper first. Perp positions expose another layer: struct Position { int64 szi; uint64 entryNtl; int64 isolatedRawUsd; uint32 leverage; bool isIsolated; } The sign of szi tells you the direction: szi > 0 long szi < 0 short szi = 0 no position The margin mode is also explicit. isIsolated tells you whether the position is using isolated margin. isolatedRawUsd only makes sense in that context. This is very different from a normal EVM integration where the exchange state must be reconstructed from logs or queried from an off-chain API. With HyperEVM precompiles, the contract is not parsing history. It is reading the current native state. The account margin summary precompile goes even higher level: struct AccountMarginSummary { int64 accountValue; uint64 marginUsed; uint64 ntlPos; int64 rawUsd; } This is the kind of primitive that normally lives inside a centralized exchange risk engine. On Hyperliquid, it is exposed to the EVM. That creates a different design space: A contract can require a minimum account value before allowing an action. A vault can observe margin usage without mirroring every fill. A liquidation or insurance mechanism can compare user risk against live HyperCore values. A strategy contract can check both market price and user state inside one EVM transaction. The important limitation is that all of this is read-only. Precompiles let Solidity observe HyperCore. They do not mutate it. For mutation, HyperEVM uses a different path, and that is CoreWriter. CoreWriter: the write lane back into HyperCore Read precompiles are synchronous. You call them, the EVM returns data, and your contract continues execution. Writes are different. The full CoreWriter.sol reference is on the Interacting with HyperCore docs page. Taken from CoreWriter.sol HyperCore is not an ERC20 contract. You cannot call placeOrder() on a Solidity order book. The order book is the native L1 state machine. So HyperEVM writes use a system contract: 0x3333333333333333333333333333333333333333 The deployed CoreWriter contract on HyperEVMScan exposes a single conceptual operation: interface ICoreWriter { function sendRawAction(bytes calldata data) external; } The contract emits a log. HyperCore later reads that log and processes the encoded action. This is a very different mental model from calling another EVM contract. When you call CoreWriter, you are not directly mutating the order book inside the same EVM frame. You are enqueuing a HyperCore action through an EVM-originated event. The action bytes have a small header: byte 0 encoding version bytes 1-3 action id, big-endian bytes 4+ raw ABI-encoded action fields In Solidity zero-indexed terms: data[0] = 0x01; // version 1 data[1] = 0x00; data[2] = 0x00; data[3] = actionId; data[4..] = abi.encode(...); For example, the USD class transfer action has action ID 7 and fields (uint64 ntl, bool toPerp). The full list of actions and their IDs is in the Interacting with HyperCore docs. A minimal helper looks like this: interface ICoreWriter { function sendRawAction(bytes calldata data) external; } contract UsdClassTransfer { address constant CORE_WRITER = 0x3333333333333333333333333333333333333333; function transferUsdClass(uint64 ntl, bool toPerp) external { bytes memory payload = abi.encode(ntl, toPerp); bytes memory data = bytes.concat(hex"01000007", payload); ICoreWriter(CORE_WRITER).sendRawAction(data); } } This is where the architecture becomes visible. The EVM contract does not know how to update HyperCore balances directly. It only knows how to emit a correctly encoded instruction. HyperCore remains the authority that validates and executes the state transition. The same pattern applies to other CoreWriter actions. For a limit order, the action ID is 1, and the fields are: ( uint32 asset, bool isBuy, uint64 limitPx, uint64 sz, bool reduceOnly, uint8 encodedTif, uint128 cloid ) The time-in-force encoding is: 1 = ALO 2 = GTC 3 = IOC The docs specify that limitPx and sz are sent as 10^8 * human readable value for this CoreWriter action. That is another place where developers can get burned. The read precompile price scaling and the write action encoding are not the same thing. An order helper: contract HyperCoreLimitOrder { address constant CORE_WRITER = 0x3333333333333333333333333333333333333333; uint8 constant TIF_ALO = 1; uint8 constant TIF_GTC = 2; uint8 constant TIF_IOC = 3; function placeLimitOrder( uint32 asset, bool isBuy, uint64 limitPx, uint64 sz, bool reduceOnly, uint8 tif, uint128 cloid ) external { bytes memory payload = abi.encode(asset, isBuy, limitPx, sz, reduceOnly, tif, cloid); bytes memory data = bytes.concat(hex"01000001", payload); ICoreWriter(CORE_WRITER).sendRawAction(data); } } This is intentionally low-level. In production you would not expose raw limitPx, sz, and tif without validation. Timing and safety traps The hardest part of this design is not the byte encoding. It is timing. HyperEVM does not replace HyperCore. It runs under the same umbrella L1, but EVM blocks and HyperCore state transitions are distinct phases. On an L1 block that produces a HyperEVM block, the ordering is: The L1 block is built. The EVM block is built. EVM to Core transfers are processed. CoreWriter actions are processed. The full block-phase description is in the HyperCore ↔ HyperEVM transfers docs. This has a concrete consequence. If a contract tries to initialize a Core account through an EVM to Core transfer and then use CoreWriter from that same account in the same block, the CoreWriter action can still fail. The account has to exist on HyperCore before the EVM block is built. This is the kind of bug that looks impossible if you only think in EVM terms. In Solidity, you are used to synchronous composition: call A call B state from A is visible to B But CoreWriter crosses an execution boundary. It emits an action that HyperCore processes after the EVM block phase. So the mental model should be: EVM execution emits intent. HyperCore later validates intent. HyperCore mutates native financial state. There is also a deliberate fairness rule: Order actions and vault transfers sent through CoreWriter are delayed onchain for a few seconds. The reason is to prevent contracts from using HyperEVM as a backdoor to skip the normal L1 mempool path and gain a latency advantage. This means a CoreWriter order is not a free high-frequency trading primitive. It is better understood as a composability primitive. Practical safety checklist Before building on these primitives, there are a few rules worth making explicit. Treat invalid precompile inputs as expensive The read precompiles can fail on invalid inputs, such as invalid asset IDs or invalid vault addresses. When that happens, the failed call can consume all gas passed into that precompile call frame. Do not forward unbounded gas into arbitrary user-selected precompile calls. Wrap reads behind allowlists: require(asset < maxKnownAsset, "invalid asset"); For vault reads, validate vault addresses before calling. Keep decimal conversion close to the read Do not scatter raw price conversion across the codebase. If oraclePx returns raw integers, create one helper that takes szDecimals and returns the normalized value. Example: function normalizePerpPrice(uint64 raw, uint8 szDecimals) internal pure returns (uint256) { uint8 divisorDecimals = 6 - szDecimals; return uint256(raw) * 1e18 / (10 ** divisorDecimals); } Now every downstream contract consumes 1e18 scaled values instead of trying to remember HyperCore’s raw format. Separate read scaling from write scaling Read precompile price scaling is based on asset metadata. CoreWriter limit order fields use their own action encoding, where limitPx and sz are encoded as 10^8 * human readable value. Do not reuse one scaling helper for both directions unless it explicitly distinguishes read normalization from write encoding. Remember that CoreWriter actions are emitted by msg.sender When a contract calls CoreWriter, the action is on behalf of the contract address, not the EOA that called your contract. That means your contract address itself must be meaningful on HyperCore for the action you are sending. This is different from the API wallet model where an agent signs on behalf of a master account. Build for asynchronous confirmation A CoreWriter call only proves that the EVM transaction emitted the action. It does not prove that HyperCore accepted and executed the action. Your application should track the later HyperCore execution result. A clean architecture looks like: EVM contract emits local event with action details. Indexer watches the EVM event. Indexer watches L1 explorer or HyperCore state for execution. UI shows “enqueued” first, then “executed” or “rejected”. This matches the actual architecture instead of pretending the write path is synchronous. Summary HyperEVM precompiles and CoreWriter are the bridge between two very different execution models. The read side is synchronous and contract-friendly. A Solidity contract can call native precompiles to observe HyperCore prices, balances, positions, vault equity, staking state, and margin summaries. The data comes back as raw ABI-encoded integers and structs, which means the developer has to handle scaling and decoding correctly. The write side is intentionally different. CoreWriter does not expose a friendly order book contract. It emits a raw action log with a version byte, an action ID, and ABI-encoded fields. HyperCore later consumes that action and decides whether it is valid. This split preserves the architectural boundary we have been discussing since Part 1. HyperCore remains the high-performance financial state machine. HyperEVM gives builders a programmable surface over that state machine. The precompiles let contracts see the native exchange. CoreWriter lets contracts express intent back to it. The most important mental shift is this: HyperEVM composability is not about porting a CLOB into Solidity. It is about giving Solidity controlled read and write access to a CLOB that already exists at the L1 level. Deploy a Hyperliquid node on Chainstack → FAQ What are HyperEVM precompiles? HyperEVM precompiles are reserved addresses starting at 0x0000000000000000000000000000000000000800 where the node runs native logic instead of executing deployed bytecode. They give Solidity contracts direct read access to HyperCore state — oracle prices, spot balances, perp positions, vault equity, and margin summaries — with no third-party oracle in between. The full list of precompiles and their return types is defined in Hyperliquid’s L1Read.sol reference. What is CoreWriter on Hyperliquid? CoreWriter is a system contract at 0x3333333333333333333333333333333333333333 that lets HyperEVM smart contracts send actions to HyperCore. It exposes a single function, sendRawAction(bytes calldata data), which emits a log that HyperCore later reads and executes. CoreWriter is the write lane back into HyperCore for actions such as limit orders, USD class transfers, vault deposits, and staking operations. Can Solidity contracts read HyperCore state directly? Yes. A staticcall to the right precompile address returns HyperCore state as raw ABI-encoded data, guaranteed to match HyperCore state at the time the EVM block is constructed. There is no external oracle in the loop — the data comes from the node’s execution environment itself. Contracts can read positions, spot balances, prices, vault equity, margin summaries, and more without waiting for a keeper or bridge message. Are CoreWriter actions atomic with the EVM transaction that emits them? No. A CoreWriter call in the EVM transaction only emits an action log. HyperCore processes that action in a later phase, after the EVM block is built and after EVM-to-Core transfers are processed. This means a successful CoreWriter call proves that the action was enqueued, not that HyperCore accepted or executed it. Applications should track the eventual HyperCore execution result separately — for example, by watching L1 explorer events or reading updated precompile state on a subsequent block. Why are some CoreWriter actions delayed on-chain? Order actions and vault transfers sent through CoreWriter are intentionally delayed on-chain for a few seconds. The reason is fairness: without the delay, HyperEVM contracts could bypass the normal L1 mempool path and gain a latency advantage over traders submitting orders directly. This means a CoreWriter order should be understood as a composability primitive, not a high-frequency trading primitive. Regular CoreWriter actions that are not order-related, such as USD class transfers or staking deposits, are not subject to this delay. Why do prices returned by oraclePx look wrong? The precompile returns the L1 integer representation, not a human-readable decimal. For perps, divide the raw value by 10^(6 - szDecimals) to get the human-readable price. For spot markets, divide by 10^(8 - base asset szDecimals). Applying the wrong scaling factor — or worse, assuming all prices are 1e8 scaled — is one of the most common bugs when building on top of HyperCore precompiles. Read perpAssetInfo or spotInfo for the correct szDecimals before scaling. Additional resources Build better with Hyperliquid What is Hyperliquid? RPC, API, and trading infrastructure How to get a Hyperliquid RPC endpoint for DeFi (2026 guide) Best Hyperliquid RPC providers in 2026 Hyperliquid testnet HYPE faucet Understanding Hyperliquid infrastructure and RPC nodes #### Hypernative: Mitigating Web3 risks with resilient Chainstack infrastructure Securing Web3 by enhancing resilient infrastructure and real-time threat detection “Chainstack’s robust infrastructure has significantly enhanced our ability to secure Web3 environments effectively. Their reliable and scalable solutions have exceeded our expectations, enabling Hypernative to focus on protecting digital assets from emerging threats with greater efficiency and reliability.” Lior Betzalel, VP R&D Hypernative At Chainstack, we understand how crucial effective security measures are for protection against potential threats to digital assets, protocols, and applications. This is where our collaboration with industry leader, Hypernative, truly shines. Hypernative has distinguished itself from the pack through its determined battle against zero-day cyberattacks, protecting digital assets and Web3 applications from significant losses. With an ever-vigilant guard over a total value of $3B, Hypernative has saved more than $50M from falling into the hands of cyber miscreants to date. So, how did we at Chainstack assist this influential name in Web3 security reach these dizzying heights? Let’s find out! How Hypernative started with Chainstack When we first connected with Hypernative, they were already using a range of node providers. As we understood, they expected us to contribute crucial multi-chain support with a good UI and competitive pricing. For a company deeply engaged in extracting blockchain data, robust and reliable node API access was a requirement they laid emphasis on. We understood that Hypernative’s needs were comprehensive. Fetching raw block data, transaction data, and reliably executing other specific API calls regularly termed the team’s needs. Hypernative had challenges related to the response time and the need for durability in its infrastructure which we acknowledged and improved over time. Our multi-chain support, competitive pricing, reliable nodes, and receptive customer service appealed greatly to Hypernative’s scalable requirements. The crux of our relationship has not merely been about aligning our offerings with Hypernative’s needs, but also about growth and scale that benefits both parties. Hypernative has tapped into our diverse services using Chainstack Global Nodes for real-time data processing, which offer a superior edge with improved load balancing and redundancy and dedicated for historical tasks. Hypernative on Chainstack in numbers Our impactful partnership with Hypernative is best reflected through the compelling numbers: We currently support 20 active Global Nodes, delivering high reliability, scalability, and multichain support that Hypernative relies on. Our solutions benefit Hypernative in managing data across diverse protocols including Arbitrum, Avalanche, Base, BNB Smart Chain, Ethereum, Fantom, Gnosis, Optimism, Polygon, Starknet, and zkSync Era. A striking figure of 425.8M+ Global Node requests have been processed via our nodes, characterizing the magnitude of requests Hypernative handles. When we break down the regions, Dallas sees the highest number of requests with a total of 265.1M, followed by Chainstack Global Nodes’ count of 160.7M. This showcases our wide network coverage, confirming our commitment to service availability at all times. Looking at the protocol usage, zkSync Era leads the pack with 249.9M requests, whereas BNB Smart Chain comes in second with a noteworthy request count of 139.6M. It is followed by Ethereum at 21.1M and Starknet at 15.2M protocol requests. For Archive requests, this includes handling 54.8% eth_getTransactionReceipt, 13.6% eth_call, and 6.6% debug_traceTransaction requests, among others. Simultaneously, for Full requests, our services processed 41.7% eth_call and 16.4% starknet_getTransactionReceipt, followed by 9.1% starknet_blockNumber. Figure 1: Hypernative full and archive node RU allocation These statistics reflect our ongoing commitment to deliver the highest value for Hypernative with each interaction. Our multi-chain capability is imperative in this context, standing as a testimony to our prowess in the sector. What is Hypernative? Hypernative, a trailblazer in the world of Web3 security, is steadfast in thwarting zero-day cyberattacks and safeguarding digital assets, protocols, and Web3 applications from significant financial losses. Hypernative monitors over 30 chains, covering security, technical, financial, governance and other risks. Hypernative Platform detected 99.5% of hacks last year with less than 0.001% false positive rate and saved more than $50 million of funds to date.. Not only do they focus on comprehensive security monitoring, but they also offer poignant insights into governance, economic issues, and on-chain activities—an all-round security powerhouse. Working with leading organizations across various industries, Hypernative has been an exemplary sentinel, vigilantly monitoring assets like protocols, contracts, and wallets. What’s unique about Hypernative is its ability to detect, monitor, and manage a wide spectrum of risks in real time. The company offers 24/7 monitoring services that cover governance, security, economic, and on-chain activities, providing users with precise insights to avoid unnecessary risk. One of Hypernative’s key strengths is its swift and efficient reaction to potential Web3 threats. The platform’s real-time protection system has already detected over 764,433 risks, triggered 33,042 alerts, and diligently monitored 1,443 protocols. Meanwhile, Hypernative’s innovative platform is capable of customizing alerts and integrating them into user workflows via APIs, emails, Slack, and built-in alerts inbox which is an appealing facet for many relying on Hypernative for its Web3 operations. From always-on governance and security monitoring, preemptive risk detection, focused and accurate insights, to workflow integrations; Hypernative offers a comprehensive Web3 security solution. “Our collaboration with Hypernative highlights Chainstack’s capacity to support cutting-edge Web3 security. Their commitment to safeguarding blockchain environments matches our own, enabling us to enhance and scale our solutions effectively together.” Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together In the frontier of Web3 security, every partnership counts. At Chainstack, our collaboration with Hypernative stands as a testament to our shared commitment to fortifying the digital space. The platform’s impressive track record in mitigating risks and providing robust protection to digital assets, protocols, and applications resonates deeply with our mission. Our multi-chain support, reliable nodes, and competitive pricing have proven to be an asset to Hypernative’s operational strategy. We are proud to meet the team’s comprehensive needs through our accessible, flexible, and effective managed blockchain services. Furthermore, our commitment to responsive customer service has ensured we continue to add value to Hypernative’s already commendable efforts in the realm of Web3 security. Our partnership with Hypernative, driven by a common goal of enhancing Web3 security, has been a journey of mutual growth and exciting challenges. As this journey progresses, we at Chainstack look forward to fostering deeper relations and achieving new milestones with Hypernative, making the Web3 ecosystem a safer place to navigate. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ignite the Subnets: Benqi and Chainstack join forces with Avalanche For a long time, the potential and promise of blockchain technology have been stifled by significant barriers to entry, especially for solo Web3 developers. Against this backdrop, we are thrilled to announce our partnership with Benqi in a joint effort to make Avalanche Subnets that much more accessible. With the launch of Benqi’s Ignite program, we’re witnessing a major shift in the Avalanche ecosystem, and we’re thrilled to be a part of it. Together, we are paving the way for accelerated appchain development and innovation across Web3. Build your own Avalanche Subnets on Chainstack with Benqi Avalanche Subnets are a pivotal innovation in the world of Web3 appchains. These Subnets stand out within the Avalanche ecosystem for offering the ability to create a custom blockchain network, according to your specifications. Leveraging this dynamic feature on Chainstack, you gain the ability to dictate the operational parameters of your blockchain, including the choice of virtual machines, validation protocols, and reward mechanisms for each Subnet. A Subnet, represents a group of Avalanche validators tasked with reaching consensus across one or more blockchain networks. Unique to each blockchain, Subnets can oversee the validation of multiple blockchain networks. Notably, the Avalanche Primary Network, which is considered a distinguished Subnet, operates three principal blockchains: the Platform Chain (P-Chain), the Contract Chain (C-Chain), and the Exchange Chain (X-Chain). Avalanche Subnets advantages Autonomous networks: Subnets allow for the creation of networks with tailored execution logic, fee configurations, and security measures, ensuring that performance remains stable regardless of the activities in other Subnets. Built-in interoperability: Thanks to Avalanche Warp Messaging, Subnets are inherently interoperable, facilitating effortless communication and transactions between different Subnets. Tailored for specific applications: Subnets enable validators to adhere to particular hardware specifications, ensuring the network runs at peak efficiency. Enhanced compliance and privacy measures: With Subnets, you can implement specific regulations and privacy guidelines, including geographic, licensing, and KYC/AML considerations, alongside the provision for private Subnets accessible only to authorized validators. Choice in validation participation: Within this diverse network, validators have the freedom to select the Subnets they wish to validate, optimizing their computational resources. And speaking of Avalanche Subnets validators, this is where Chainstack and Benqi’s Ignite program come into play. On one hand, we at Chainstack, provide you with options to deploy your Avalanche Subnets validators at a click of a button, while the Benqi Ignite program serves to provide you with the staking collateral needed to push your Subnet live. Let’s explore the Ignite program in detail. What is the Benqi Ignite program? The Ignite program is a game-changer for Avalanche Subnets, radically simplifying the deployment of both Subnets and their validators. The Ignite program provides an affordable and accessible alternative to the traditional approach that requires substantial financial investment to complete. And considering these are outside the reach of many,, we’re excited to support this initiative and help lower the barriers to entry for aspiring Web3 developers and builders wanting to harness the power of cutting-edge L2 appchain technology. Through our combined efforts and the introduction of staking rentals for validation services, we’re opening the door for many more to start their own Subnets, democratizing the process, while nurturing the Avalanche ecosystem. This model drastically reduces the capital required to launch an Avalanche validator. By handling the validators on Chainstack, Benqi gives clients the option to rent AVAX, spreading staking costs over time and significantly lowering the entry barrier for Avalanche Subnets. Figure 1: The Benqi Ignite program’s mechanism; Source: Benqi How Benqi’s Ignite program works To ensure developers get the most out of the Ignite program, it has been designed with two different validation options in mind—Pay As You Go (PAYG) and Stake. Here’s a closer look at each: Pay As You Go (PAYG): No minimum stake required. Offers a rental model to lower capital requirements for launching an Avalanche validator, increasing accessibility. Allows Web3 developers to pay in USDC, AVAX, or QI; requires inputting a NodeID and setting a staking duration. Ignite provides all necessary AVAX for validator launch. Stake: Requires a minimum stake plus an additional amount in QI. Operates without any fees for usage. Enables Web3 developers to earn staking rewards in proportion to their AVAX stake. Allows claiming of AVAX and QI stakes plus all network rewards, including delegation fees, at the end of the staking period. Both options aim to make deploying Avalanche Subnets more flexible and affordable, fostering an inclusive environment for developers and organizations. Through the collaboration with Benqi and Avalanche, these staking options are designed to empower a broader community within the Avalanche ecosystem. Bringing it all together We anticipate that our collective efforts together with Benqi and Avalanche will foster a more dynamic Avalanche ecosystem. This refreshing start marks an important chapter in our journey toward a more accessible and inclusive Appchain development. Through our partnership, we also trust that these advancements will have wider implications in the blockchain industry. As we craft an environment conducive to growth and innovation, we’re hopeful it will inspire further commitment across Web3. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Ignite the Subnets: How Benqi powers hundreds of Avalanche validators with Chainstack Our collaboration with Chainstack marks a pivotal step in enhancing the Avalanche ecosystem, offering a seamless experience for deploying Subnets. By simplifying complexities, we’re building bridges for developers to bring their ideas to life. Dan Mgbor, Co-Founder, Benqi At Chainstack, our mission has always been to streamline the complexities of blockchain technology, making it more accessible and efficient for our partners. In this spirit, our collaboration with Benqi stands as a testament to our shared vision of fostering innovation within the Avalanche ecosystem. Whether it’s about effortless decentralized lending, easy crypto borrowing, or launching Avalanche validators and Subnets, Benqi has provided an accessible platform for professionals in every corner of Web3. However, the complexity of such processes and the technical challenges they pose have always been a concern. And that’s where Chainstack came into play. How Benqi started with Chainstack From the get-go, Benqi saw Chainstack as more than just a service provider. Instead, Benqi viewed us as a proactive partner, perfectly equipped to support their endeavors. Benqi needed our services, but more so our expertise to simplify the technicalities of spinning up validators for their clients’ Avalanche Subnets. This feature was instrumental in their decision to adopt Chainstack, as it provided the perfect solution to their Ignite product’s integration needs. Our commitment to flexibility, reliability, and offering a seamless user experience further fostered their conviction. Taking full advantage of our services, Benqi reduced the traction of funding validators, deploying Subnets effortlessly, and relying on our infrastructure for total customer satisfaction. Chainstack enabled Ignite to back countless validators, hinting at an even brighter future. Benqi on Chainstack in numbers Our partnership with Benqi through their Ignite program has been pivotal in addressing the high costs associated with deploying Avalanche Subnets. Traditionally, the requirement to stake 16,000 AVAX presented a significant financial hurdle, limiting accessibility for many potential participants. However, our collaboration has led to a groundbreaking solution that democratizes access to the Avalanche ecosystem. Through the Ignite program, we have facilitated the launch of hundreds of Avalanche validators, a testament to our joint commitment to fostering growth and inclusivity within the blockchain ecosystem. This initiative not only supports developers by offering staking rental for validators, eliminating the need for substantial upfront capital but also enhances the operational efficiency and communication among participants. Figure 1: Benqi Ignite validator funding mechanism; Source: Benqi By streamlining the process of spinning up validators for Avalanche Subnets, Chainstack has removed operational friction and ensured the reliability of these critical network components. This reliability is essential for maintaining the performance of the Avalanche Subnets and for the success of decentralized applications built on them. The broad and stable set of validators we’ve helped establish through the Ignite program opens up new avenues for the development of robust, decentralized applications, leading to a richer and more adaptable Avalanche ecosystem. As a chosen partner, we’re proud to provide Benqi—and by extension, their users—with a platform that is not only more accessible but also reliable, scalable, and efficient. In summary, our successful collaboration with Benqi reflects a shared vision for a more inclusive and democratized blockchain infrastructure. By reducing the financial and operational barriers to entry, we are enabling a wider range of developers to innovate and build on the Avalanche network, thereby contributing to the ecosystem’s growth and diversity. What is Benqi? Benqi is a game-changer in the Avalanche space. As an all-encompassing suite of protocols, Benqi is providing an array of services to its 100,000+ users, redefining the way digital asset interactions take place. Investing in digital assets with Benqi means facing a treasure trove of options. With over $858M worth of value locked and counting, Benqi offers three primary services: Liquid Staking, Markets, and Ignite. Benqi Markets, a central feature of the suite, empowers users to lend, borrow and earn interest effortlessly with their digital assets. It operates under a permissionless framework and offers a transparent view of interest rates around the clock, driven by real-time market supply and demand. The result? A feature for users to supply and withdraw liquidity instantaneously and borrow from the liquidity market with their existing assets as collateral. Taking it a step further, Benqi Liquid Staking breaks new ground over traditional staking methods. It provides an Avalanche liquid staking option that tokenizes staked AVAX. This tokenization allows users to fully utilize their yield-bearing assets within various DeFi applications, providing unmatched utility and flexibility. Figure 2: Benqi Liquid Staking workflow; Source: Benqi Finally, Benqi’s innovative Ignite program enables builders to launch Avalanche Subnets, by creating opportunities for validator stake rentals. This initiative paves the way for a more affordable and accessible approach compared to the traditionally costly procedures, thus democratizing the horizons for Web3 developers and innovators eager to explore the potentials of L2 appchain technology in the ecosystem. Working with Benqi has been a powerful example of how strategic collaborations accelerate growth. Together we’ve made it easier for Web3 developers to deploy their own Avalanche Subnets, paving the way for a more vibrant and inclusive future one subnet at a time. Eugene Aseev, CTO & Co-founder, Chainstack Bringing it all together At Chainstack, we champion the ambitions of our clients, and Benqi is no exception. By providing the team with a comprehensive solution to their friction points, notably by facilitating the launching of Avalanche validators, we empowered them to reach their full potential and garner success in the digital asset market. Our partnership with Benqi isn’t just built on a shared vision for the future of Web3—it’s fueled by the common ambition to remove barriers to blockchain adoption. With Benqi’s impressive suite of services and Chainstack’s robust infrastructure, we’re providing optimal solutions to address the needs of Web3 developers and institutions alike. The Benqi case is a testament to what we can accomplish when we combine innovative products, dedicated support, and powerful infrastructure for a more open, efficient, and user-friendly Web3. Our journey with Benqi is the epitome of our commitment to enable scalable and accessible solutions. As we look to the future, our collaboration stands as a beacon of progress, continuously striving to lower barriers and empower the next generation of blockchain innovators. Through our continued efforts, we are excited to nurture and witness the growth of a more inclusive, efficient, and vibrant Avalanche landscape. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### IguVerse on Chainstack: Leading a new social paradigm in Web3 Balancing the network load on BNB for seamless social gaming Chainstack’s resolution to the network load issues we experienced was both swift and smooth. We saw greater performance uplift across our DApp infrastructure once the changes went live overall. We are quite happy with the outcome and haven’t faced the need to reopen the case ever since. Mariusz Beltowski, Technical Director, IguVerse IguVerse paves the way for socialize-to-earn on Web3 IguVerse is an online social-network type of game that allows multiple players to engage with gameplay mechanics through social networks or social media. In recent times, the play-to-earn business model has evolved into the concept of real-world action to earn, where players can perform activities in the real world and earn rewards. Move-to-earn gained popularity a year ago and ushered in a new era for play-to-earn games. IguVerse has developed a new concept called “socialize-to-earn,” which leverages social media and pet lovers’ interests to provide rewards for simple daily tasks and social media activities. Social media is a crucial tool for disseminating information, and many projects have gained popularity by utilizing platforms like Facebook. Such projects have a high engagement rate and garner significant attention due to the platform’s popularity. Figure 1: IguVerse promo video Their concept’s most significant advantage is that players collaborate and interact on social media, organically promoting the project on the platform. This results in an exponential increase in the game’s popularity as each player posts about it, drawing their friends’ attention to the game. Because of this, an explosive initial momentum in both popularity and demand is a given. Blockchain technology empowers users to own assets without permission. A sophisticated player-owned economy will encourage skilled players to reach advanced levels. Up until now, the DApp has generated over 800K mobile downloads from both app stores, 100K Daily Active Users (DAUs), and a whopping 4M+ worth of NFTs sold on the platform. Figure 2: IguVerse DApp key stats; Source: IguVerse Social gamification meets AI, Web3, and NFTs Using AI/ML technologies, the IguVerse GameFi app reimagines the concept of NFTs. It establishes user-generated NFTs as a new standard, surpassing anonymous collections with NFT 2.0. IguVerse presents an innovative game mechanic, “socialize-to-earn,” alongside two additional concepts: “move-to-earn” and “play-to-earn.” Users may receive rewards by completing simple tasks such as sharing pet photos on social media or taking care of virtual pets by walking and feeding them. Figure 3: IguVerse revenue model; Source: IguVerse IguVerse’s pet-centric social-network game merges the three most popular game mechanics in the genre: “socialize-to-earn,” “move-to-earn,” and “play-to-earn” into a single app. The app revolutionizes the Web3 gaming industry by incorporating social and community elements into GameFi. This pioneering idea brings pet owners worldwide together in a single app and offers them cryptocurrency rewards by engaging in their everyday social media routine. Figure 4: IguVerse dual token model; Source: IguVerse A case of high network load on BNB Like any social-network game, IguVerse generates an incredible amount of interactions. But while this is much less of a challenge with a Web2 approach, having such engagement and recording it on-chain is a completely different story. And being able to process them efficiently can be game-changing. That is why, the IguVerse development team, above anything else, needed a swift response and resolution from our support team when the platform faced an overwhelming network load on BNB. Due to the sheer volume of interactions being logged on IguVerse, the amount of compute resources their nodes required to perform was growing at an exponential rate. This resulted in failed transactions and desync issues once hardware limits were reached. Swiftly balancing the load with Chainstack Once IguVerse reached out to inform us of the issue, our support engineers responded swiftly in taking up the case. Upon closer inspection, we discovered the root issue in the overwhelming amount of requests some power IguVerse users generated during playtime. Because of this, the need to tweak the load balancer setup and adapt it better to such edge cases became apparent. So, to treat the issue at its root and permanently resolve further occurrences, Chainstack engineers worked to allocate additional hardware resources in augmenting the load balancer setup towards optimal performance. With the changes going live, IguVerse, saw a steady decrease in the compute resources being used for platform operations until settling down to levels within parameters. Resolution summary The IguVerse social network game generates a lot of interactions, during playtime which posed a challenge when logging these interactions on-chain. This led to failed transactions and desync issues due to the overwhelming amount of compute resources needed to handle these interactions. The IguVerse team contacted Chainstack for support and we identified the root cause as an excessive number of requests generated from some users on the platform. Chainstack engineers allocated additional hardware resources to the load balancer setup and adapted it to better fit the edge cases to treat the issue at its root. This resolved the issue and streamlined the compute resources needed for the effective platform operations of IguVerse. IguVerse enjoys a smooth and steady infrastructure performance with no service interruptions or causes for distress ever since. At the time of writing, IguVerse continues to deliver an outstanding Web3 experience to its users across the world. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Indexing blockchain data to life with Dedicated Subgraphs ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. Subgraphs migrated to Ormi. See migration details Blockchain technology is fundamentally transforming the landscape of data management and transaction processing, offering unprecedented levels of security, transparency, and decentralization. However, this innovative technology is not without its challenges, particularly when it comes to managing and indexing blockchain data. The inherent complexity of working with blockchain data arises from several key factors: Volume and variety of data: Blockchains continuously grow in size due to the constant addition of new blocks. This ever-expanding volume of data, comprising diverse types of transactions and smart contract interactions, demands robust and scalable indexing solutions to ensure efficient data retrieval and analysis. Real-time processing needs: For many applications, such as DeFi and GameFi platforms or real-time trading systems, accessing up-to-date blockchain information is crucial. This necessitates the development of high-throughput, low-latency indexing solutions, capable of handling real-time data. Interoperability challenges: With the proliferation of multiple blockchain networks and protocols, interoperability becomes a significant concern. Creating a unified system that can effectively index and query data across various blockchains is a complex task that involves addressing issues of compatibility and standardization. We noticed how developers grappled with them, so we took these concerns aboard and set out to engineer a solution. Solving blockchain data indexing one query at a time For applications that need to access specific data, efficient and seamless blockchain data indexing is key. And when you’re indexing data on blockchain networks, let’s just say it pays to have a plan—because structuring your on-chain data in a way that’s easily readable and analyzable can seriously level up the performance of your blockchain-based applications and platforms. Subgraphs are like open APIs—and with them, you can seamlessly query data from any application using The Graph indexing protocol. By offering faster, better, and more reliable infrastructure, Dedicated Subgraphs serves as a single point of access for all your data across any blockchain. Our Subgraphs are tailored to deliver incredible performance, high precision, and bulletproof reliability for your DApp. By supporting numerous blockchain protocols, we’ve made it easier than ever for developers and researchers to tap into blockchain data efficiently and effortlessly. Our enterprise-grade infrastructure guarantees you’ll stay ahead in this fast-paced decentralized world with access to up-to-date, accurate on-chain data at your fingertips. Figure 1: Dedicated Subgraphs supported protocols; Source: Chainstack Query blockchain data without the nodes There’s a first for everything. And here at Chainstack, we’re proud to provide the first of its kind solution that lets you query Subgraphs without running any nodes or infrastructure. We handle everything, from deployment to maintenance, so you can focus on what matters – building your applications and growing your business. We take reliability seriously. It’s a non-negotiable feature and we’ve got your back. Say goodbye to sleepless nights worrying about service availability and hello to calm, knowing that we hold a 99.9% availability rate. This means that you can rely on Dedicated Subgraphs for access to your blockchain data anytime, anywhere, without a hitch. Boasting the fastest real-time indexing solution on the market, coupled with solid service level agreements (SLAs) and 24/7 support, we provide the backbone you need to drive your blockchain data indexing to new heights. With Dedicated Subgraphs, you’re not just getting a service—you’re getting a partner dedicated to your blockchain journey every step of the way. Figure 2: Dedicated Subgraphs vs Hosted Service comparison; Source: Chainstack Migrate your Subgraphs in a few clicks We get it – migration can sound like a big job. But with Dedicated Subgraphs, migrating subgraphs from a hosted service is outrageously easy. It’s just a few clicks, and voila! All you need to do is to input the IPFS link and deploy, and the syncing process starts immediately. With the indexing process fully automated, you get to focus on what’s important. And when that’s done? Your subgraph data is ready to be consumed via the GraphQL endpoint. Easy as pie. We ensure seamless integration of our Subgraphs with your existing systems, powered by our robust and reliable backend infrastructure. Deploying and syncing Subgraphs couldn’t get any more straightforward. You may never want to go back! Do you have a protocol that we don’t support currently? No worries. As long as it’s supported by The Graph or is EVM compatible, we can still query smart contract data using our custom hosting service. Just provide us with the RPC node endpoint, and we’ll handle the rest. Appchains: Beyond basic blockchain data indexing At Chainstack, we like to go a step further. Yes, we provide high quality, reliable indexing for major blockchain protocols – but why stop there? We believe in making all of your data accessible, and that includes appchains. So what are appchains? Simply put, these are specialized blockchains that are designed to serve a single DApp. They can run independently or in tandem with other blockchains, allowing for greater scalability and dedicated use. Unleashing the power of Subgraphs, now you can query real-time data from appchains and index on-chain activities. Yes, that’s right. With Dedicated Subgraphs, you can push the boundaries of what’s possible with blockchain data indexing and unlock a wealth of insights from your appchains. Blockchain data fit for your budget Finding a reliable, efficient, and scalable blockchain solution shouldn’t have you breaking the bank. That’s why we have simplified the pricing for our Dedicated Subgraphs, so you don’t have to do any complex math just to get your finances in order. We offer a flat fee for a fixed number of requests and the flexibility to pay-as-you-go. On our platform, you’ll bid farewell to hidden fees or unexpected charges—only fair, transparent, and straightforward pricing. Here’s three awesome use cases you can tackle with it: High-velocity trading In DeFi, real-time access to historical transactions or token data is vital. Our Subgraphs facilitate instant access, enabling DeFi applications to operate smoothly and be up-to-date with the latest data. You, as a DeFi DApp developer, can be assured of seamless data streaming and querying for your ground-breaking decentralized finance applications. Immersive GameFi For you game developers out there, envision hassle-free tracking and visualization of in-game analytics. Our Dedicated Subgraphs empower you to tap into real-time in-game data, facilitating dynamic player economies and tracking NFTs. With us, you can create immersive gaming experiences with unparalleled data insights. Real-time analytics In the world of blockchain, staying updated with on-chain activities can provide remarkable insights for research and analytics. Dedicated Subgraphs offer real-time data streaming, keeping you informed on the latest on-chain activities. Use them to make data-driven decisions and stay ahead of the curve in your research endeavors. We know how complex DApp development can be. Our Subgraphs make it quick and simple to fetch custom smart contract data, aiding you in crafting ideal decentralized applications. With Chainstack at your side, we’re simplifying your DApp development journey, one subgraph at a time. Real-time blockchain data tailored for the DeFi industry For developers keen on diving into the DeFi space, we offer an exclusive opportunity to experience the Chainstack DeFi API, currently in closed beta. This suite of tools is specifically tailored to access real-time and historical data from an array of DeFi protocols like Uniswap, SushiSwap, Lido, Aave, and OpenSea. It empowers you to engage in lending, borrowing, trading, and yield farming, through a well-curated and controlled environment. This makes the Chainstack DeFi API a vital asset for those looking to monitor, analyze, and make strategic moves in the DeFi ecosystem. Ask to participate. Bringing it all together We’ve always believed in an inclusive, easy-to-use, and efficient blockchain world where data indexing isn’t cumbersome but an empowering process. That’s the vision driving us, and that’s the vision that brought Dedicated Subgraphs to life. By integrating Dedicated Subgraphs into your blockchain projects, you—our valuable Web3 developers—are indeed bringing in reliability, flexibility, and speed. Not to mention the 24/7 support and customized solutions we are willing to offer to make your blockchain journey a success. Our efforts are continuously aimed at improving and making blockchain more accessible and user-friendly for our community. With Dedicated Subgraphs, we move one step closer to that objective. We invite you to embark on this journey with us. Let’s build something amazing together! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Infrastructure and analytics come together for Avalanche subnets In brief Launch your own subnet for the speed and reliability with Chainstack; peek into your subnet for insights and analytics with Covalent. Get the same smooth uniform experience that thousands of public chain developers come to rely on with Chainstack and Covalent. Introduction With the Avalanche protocol, you can build your own blockchain protocol(s)—complete with a custom blockchain virtual machine—and launch it as a network that is validated by a set of the same validators that are securing the main Avalanche network. Your custom blockchain protocol running as a network and secured by the Avalanche mainnet validators is called a subnet. Subnet use cases  There is no limit or discovery end to the subnet uses at this stage, but the primary cases so far can be summed as the following: Single-purpose blockchains—from private networks to storage (SpacesVM) and timestamp (TimestampVM) networks. Layer 2 blockchains—to scale to your own network while still being part of the Avalanche mainnet. Example: Crabada’s Swimmer Network. Legal network requirements. Examples: geographical location of validators, licensing of validators, compliance with regulatory checks. The subnet creation process overview The mechanics of creating a subnet are the following: Create your own blockchain virtual machine. You can use the Avalanche Virtual Machine (AVM) as base to create and exchange digital assets or use the Ethereum Virtual Machine (EVM) as base to run smart contracts on your subnet. Create the genesis state for your network. Run a validator node securing the Avalanche main network to validate your subnet or approach an existing validator. Add at least one of the Avalanche main network validators to your network. Register your network with the Avalanche mainnet Platform Chain (P-Chain). Whitelist your registered subnet with the validators securing your network. Join the subnet innovation with Chainstack and Covalent  Get the same blockchain experience with subnets you are used to and that thousands of developers and entrepreneurs rely on with the public chain networks from Chainstack and Covalent.  Create, run, and maintain your subnet with Chainstack.  Get the full analytics for your subnet with Covalent. Avalanche is the protocol allowing for the subnet creation.   Chainstack is a platform that enables users to deploy, run, and manage their custom network and nodes quickly for Avalanche’s subnets.   Covalent’s industry-leading Unified API provides rich, granular data for users hosting their Avalanche subnets on Chainstack. Deploy and scale subnets faster with Chainstack Chainstack allows developers to deploy and sync fully dedicated nodes in minutes while taking care of node management and operations. Developers and builders in Web3, DeFi, GameFi, and the overall blockchain innovation who want to run high-performing projects on Avalanche use Chainstack to deploy Avalanche nodes easily and in the most effective way without needing to invest time and resources in setting up enterprise-grade infrastructure. Chainstack currently serves over 30,000 community members and processes more than 12,000 requests per second. Chainstack is committed to supporting the next leg of innovation in the public blockchain networks space which is Avalanche subnets.  Together with Covalent, we are excited to provide to subnet developers the same uniform and smooth experience that thousands of teams are used to rely on. Your custom VMs get the enterprise-grade treatment with us for infrastructure and the high-level reliability and data-granularity with Covalent.  – Eugene Aseev, CTO and Founder at Chainstack  Build faster on subnets with Covalent’s Unified Blockchain API Covalent has been providing rich, granular data on the Avalanche chain since March 2021. The Covalent unified blockchain API enables developers to pull Avalanche mainnet and Fuji testnet data within seconds by simply changing the chain_ID parameter.  Developers can extract data in seconds without writing indexing code so they can start building in minutes.   These are just a few of many types of best-in-class data developers can access:   Token balances per address  Get NFT transactions for contract  Historical transactions per address  Get all contract metadata  Covalent currently serves 15,000 developers who are creating new use cases every day and have over 1,000 projects using the API.    As blockchain ecosystems and use cases continuously expand, there is an increasing need for custom blockchain features. We’re extremely bullish on Avalanche’s subnets because they give users a convenient blockchain in a box that can be easily adapted to meet their unique needs and scale. We’re thrilled to be providing rich data for developers to build incredible applications.  – Ganesh Swami, CEO at Covalent Run your Avalanche subnet  Contact us to get started with node services for your Avalanche subnet provided by Chainstack.  Sign up for Covalent’s blockchain API key to get historical C-Chain data.  Power-boost your project on Chainstack Connect to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, Solana, Harmony, and Tezos mainnet or testnets through the interface designed to help you get the job done. Get access to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, and Tezos archive nodes to query the entire history of the mainnet—starting at just $49 per month. Choose where you want to deploy, and we will provide you with the dedicated managed infrastructure that can handle high-volume, high-velocity read/write access to the network. To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### Integrating Chainstack with OpenClaw bot for Polymarket Introduction PolyClaw is an innovative OpenClaw skill (formerly known as Clawdbot, then Moltbot) that brings Polymarket trading and arbitrage capabilities directly to your messenger. Built as a messenger-friendly version of the Polymarket Alphabot developed by Chainstack, PolyClaw enables users to monitor markets, execute trades, and discover arbitrage opportunities through a unified interface. This tutorial will show you how to set up and use PolyClaw for automated prediction market trading, leveraging LLM to analyze logical relationships between events. The video below provides a practical overview of PolyClaw’s setup and key features. Key features of the Polymarket OpenClaw bot Market Monitoring: Instantly access trending Polymarket data, including market IDs and current prices Direct Trading: Buy and sell positions through messenger using simple natural language commands LLM-Powered Arbitrage: The ‘Hedge Scan’ feature uses Large Language Models to find logical relationships between markets, not just price correlations Automated Position Management: Track open positions with real-time profit and loss calculations Split + CLOB Execution: Efficient trading through token splitting mechanism and Central Limit Order Book Technical architecture of the OpenClaw bot PolyClaw operates through a synergy of several APIs and blockchain components: ComponentDescriptionOpenClaw/MoltbotBase platform running the skill, can be hosted on any server (e.g., Mac Mini)Polymarket Gamma APIUsed for reading market data, identifying trending topics, and retrieving market IDsChainstack Polygon RPCHandles on-chain transactions on Polygon mainnet, converting USDC into market tokensPolymarket CLOB APIManages the off-chain Central Limit Order Book. When placing a bet, USDC is split into YES and NO tokens, and the unwanted side is automatically soldOpenRouter APIConnects the system to LLMs (free models available) to perform arbitrage opportunity discovery Installation and setup Step 1: Install the OpenClaw bot skill 💡 Note: You can also clone directly from the GitHub repository if you prefer working with Git. PolyClaw is a skill (workflow) for OpenClaw – a customizable AI agent platform. Each OpenClaw instance is unique to the user with their chosen set of skills. Recommended method – installation via ClawHub (official skill marketplace for OpenClaw): clawhub install polyclawcd ~/.openclaw/skills/polyclawuv sync Alternative method – manual installation: cp -r polyclaw ~/.openclaw/skills/cd ~/.openclaw/skills/polyclawuv sync Step 2: Obtain required credentials for OpenClaw bot access PolyClaw requires three keys: Chainstack Polygon RPC endpoint: Sign up at Chainstack (free tier available, sign in with GitHub, X, or Google). Get the RPC URL for Polygon mainnet. Not sure how? We explained it here. OpenRouter API Key: Create a key at OpenRouter for LLM access EVM Private Key: Wallet private key in hex format (starts with 0x) ⚠️ IMPORTANT: Keep only small amounts in this wallet. Withdraw funds regularly to a secure wallet. Only trade with funds you can afford to lose. Step 3: Configure the PolyClaw skill environment Add the following settings to your openclaw.json file under skills.entries.polyclaw.env: "polyclaw": {  "enabled": true,  "env": {    "CHAINSTACK_NODE": "https://polygon-mainnet.core.chainstack.com/YOUR_KEY",    "POLYCLAW_PRIVATE_KEY": "0x...",    "OPENROUTER_API_KEY": "sk-or-v1-..."  }} Step 4: Enable trading (First-Time Setup) Before your first trade, you must set Polymarket contract approvals (one-time operation, costs approximately 0.01 POL in gas): uv run python scripts/polyclaw.py wallet approve This command will submit 6 approval transactions to the Polygon network. You only need to do this once per wallet. Step 5: Prepare funds for the Polymarket bot The system requires bridged USDC (USDC.e) on the Polygon network: Purchase USDC on any crypto exchange Transfer it to Polygon network via bridge or exchange If necessary, convert to USDC.e through a DEX like QuickSwap You’ll also need a small amount of POL for transaction gas fees How PolyClaw executes trades Split + CLOB Mechanism PolyClaw handles Polymarket’s Conditional Token Framework (CTF) automatically. When you buy a position, the skill: Split: Splits your USDC.e into equal YES and NO tokens Sell: Sells the side you don’t want via the order book Result: Returns your desired position at the effective market price Example of buying YES at $0.65: Split: $2 USDC.e → 2 YES + 2 NO tokens Sell: 2 NO tokens @ $0.35 → recover ~$0.70 Net: Paid ~$1.30 for 2 YES tokens (effective price: $0.65) Arbitrage logic in the PolyClaw skill PolyClaw moves beyond traditional trading by searching for logical implications between disparate markets. How the OpenClaw bot finds logical relationships The LLM analyzes whether the outcome of Market A logically implies the outcome of Market B. For example, if ‘Candidate X wins the presidency’ logically implies ‘Party Y wins the Senate’, the system identifies this relationship. Important: Only logically necessary implications are accepted. Simple correlations and ‘likely’ relationships are rejected by the system. Coverage Tiers TierCoverageDescriptionTier 1 (HIGH)≥95%Near-arbitrage, minimal riskTier 2 (GOOD)90-95%Strong hedging positionsTier 3 (MODERATE)85-90%Decent but noticeable riskTier 4 (LOW)<85%Speculative (filtered by default) Using the PolyClaw skill in practice When using PolyClaw through OpenClaw bot, you interact with natural language. For example: “What’s trending on Polymarket?” – Get market IDs and prices “Buy $50 YES on market” – Execute a trade “Show my positions” – View your portfolio “Find hedging opportunities” – Run LLM arbitrage scan Advanced: Direct CLI Usage (for developers) You can also interact directly with the skill scripts: 1. Browse trending markets: uv run python scripts/polyclaw.py markets trending 2. Search markets by keyword: uv run python scripts/polyclaw.py markets search "election" 3. Check wallet balance: uv run python scripts/polyclaw.py wallet status 4. Buy a position: uv run python scripts/polyclaw.py buy <market_id> YES 50 5. View positions: uv run python scripts/polyclaw.py positions Complete Workflow Example for PolyClaw skill 💻 Code Examples: For detailed code implementation and advanced examples, see the scripts directory in the GitHub repository. Ask the bot: ‘What’s trending on Polymarket?’ – Get market IDs Run: ‘Run hedge scan limit 10’ – Wait for LLM analysis (takes a few minutes) Review results – You’ll see coverage tiers and market pairs for hedging Open position: ‘Buy $25 YES on market abc123’ – Take position on target market Hedge: ‘Buy $25 NO on market xyz789’ – Take position on covering market Track: ‘Show my PolyClaw positions’ – Check entry prices and P&L Troubleshooting Issue: CLOB order failed / IP blocked by Cloudflare Polymarket’s CLOB API uses Cloudflare protection that blocks POST requests from many IP addresses. The solution is to use a rotating residential proxy with retry logic. Recommended setup (IPRoyal or similar): export HTTPS_PROXY="http://user:pass@geo.iproyal.com:12321"export CLOB_MAX_RETRIES=10 The CLOB client automatically retries with new IPs until finding an unblocked one. Typically succeeds within 5-10 attempts. Issue: Hedge scan finds 0 results or spurious results Model quality matters. The default nvidia/nemotron-nano-9b-v2:free works well. If using a different model, some may find spurious correlations (false positives), while others return empty responses. Try explicitly specifying the recommended model: uv run python scripts/polyclaw.py hedge scan --model nvidia/nemotron-nano-9b-v2:free Issue: Insufficient USDC.e Check your balance – you need USDC.e (bridged USDC) on Polygon: uv run python scripts/polyclaw.py wallet status Important security warnings This is experimental software. The private key is stored in the configuration file for convenience Keep only small amounts of funds in the bot Regularly withdraw funds to a secure wallet Only trade with funds you can afford to lose The code has not been audited for security This software is provided as-is for educational and experimental purposes – it is not financial advice Conclusion PolyClaw represents a powerful tool for automated prediction market trading, combining blockchain technology and artificial intelligence capabilities. Using Chainstack infrastructure for Polygon network access, this skill opens new possibilities for discovering arbitrage situations based on logical relationships between events. It’s important to remember that prediction market trading carries risks, and all code is provided ‘as-is’ without warranties. Always conduct your own research and trade responsibly. Run trades, scan markets, and hedge with logic. All from your messenger. Try the PolyClaw skill today Useful Resources PolyClaw GitHub Repository: polyclaw Original Polymarket Alphabot: polymarket-alpha-bot ClawHub (Official OpenClaw skill marketplace): clawhub.ai Chainstack Documentation: Creating a Polymarket trading OpenClaw skill Polymarket: polymarket.com OpenRouter: openrouter.ai #### Introducing Archive request support with Debug & Trace for Chainstack Global Nodes We are thrilled to announce that Chainstack Global Nodes now support Archive Node requests with Debug & Trace, offering developers unparalleled access to historical blockchain data. This enhancement empowers you to explore the entire history of any blockchain, enabling richer insights and more robust applications. At the core of this update is our globally distributed, geo-load-balanced Global infrastructure, which has been optimized to handle the increased demands of Archive Nodes. This means you can access historical data with the same speed, reliability, and responsiveness you’ve come to expect from Chainstack. Chainstack Global Nodes so far Let’s take a closer look at the statistics. Since their launch in late June last year, Chainstack Global Nodes have been delivering exceptional performance. In a mere two months, our Global Nodes managed to handle an impressive volume of requests, reaching tens of billions monthly. And sure, billions of requests does sound impressive, but what does it really mean in practical terms? Until now, Chainstack Global Nodes have successfully managed billions of such requests with an outstanding 99.9% uptime and exceptional 25,000+ RPS recorded. Currently, Global Nodes account for over 40% of our total Global Nodes request usage, and we anticipate this figure to rise. This trend underscores the growing preference for Global Nodes among developers, reflecting their significant reliance on this technology within the Web3 community. These figures aren’t just for show; they indicate the tangible impact that Global Nodes are having on the blockchain ecosystem. They highlight the ease, stability, and reassurance these advanced decentralized technologies bring to the Web3 developer community. For both experienced developers and newcomers alike, Chainstack Global Nodes guarantee superior performance, ensuring that everyone involved in blockchain development has access to the best tools for the job. Unlocking the power of Archive Nodes with Debug & Trace Archive nodes provide access to the entire history of a blockchain, including all transactions and state changes. This is invaluable for developers who need to analyze historical data, verify past transactions, or build applications that require a complete view of the blockchain. Building on top of this robust foundation, Debug & Trace APIs provide Web3 developers tools to observe, track, and debug operations within blockchain networks. These APIs deliver insights into transactions, block activities, and smart contracts’ execution, simplifying the process of pinpointing and fixing problems in decentralized applications. With the addition of Archive Node support with Debug & Trace, our Global architecture adapts to the increased data demands, ensuring a smooth and seamless experience for users and developers alike. The result? You can now access historical blockchain data with lightning-fast responses and near-zero latency, all while enjoying the robustness and security of our award-winning Global infrastructure. Archive requests with Debug & Trace for Chainstack Global Nodes are now available for the following Mainnets at launch day: Ethereum BNB Smart Chain Polygon Optimism Base Ronin Additionally, these requests will also support these Sepolia testnets with more coming soon: Arbitrum Base Optimism Ronin Starknet zkSync Update: Archive requests with Debug & Trace for Chainstack Global Nodes are now available on Solana as of 25/04/2024. Elevating your Web3 experience Our globally distributed Global infrastructure has been designed to handle the most demanding workloads, and the addition of archive node support is no exception. By intelligently distributing traffic across multiple locations, Global Nodes minimize disconnections and maximize performance, delivering a reliable Web3 API for your global blockchain enterprise. We have also supercharged scalability, ensuring our Global infrastructure can handle the increased demands of archive nodes. Our award-winning geo-load-balanced architecture has been proven to manage tens of thousands of simultaneous requests per second, ensuring smooth performance on a global scale. With exceptional fault tolerance, our globally-distributed nodes detect disruptions and reroute traffic ensuring uninterrupted access to historical blockchain data. And, of course, security remains a top priority. Our Global infrastructure offers robust protection against DDoS attacks and ensures secure, encrypted interactions. Chainstack Global Nodes with archive support safeguard your Web3 experiences, making them faster, smoother, and more reliable in the ever-evolving world of decentralized technology. Feature highlights Complete blockchain history: Access the entire history of any network, including all transactions and state changes. Powerful auditing API: Track and replay blockchain interactions with extensive Debug & Trace tools. Geo-load-balancing: Route requests to the nearest server based on users’ geographic locations, reducing latency and improving performance. Adaptive routing: Adapt to changing network conditions and manage traffic effectively, ensuring optimal service delivery. Exceptional scalability: Handle high demand with ease, accommodating growth without compromising performance. Persistent fault tolerance: Deliver consistent service by detecting issues and redirecting traffic away from problematic locations with zero interruption. Robust security: Protect your operations from malicious actors and DDoS attacks while ensuring secure and encrypted interactions. Bringing it all together With Chainstack Global Nodes now supporting archive requests, you have the tools you need to build high-performance DApps that scale, catering to users who demand the very best. Harness the power of our globally distributed load-balancer service to access historical blockchain data with speed, reliability, and security. Join us in shaping the future of Web3—your turn to BUIDL high-performance DApps that scale, catering to those who demand the very best. Chainstack’s Global infrastructure with full support for archive node requests is here to help you succeed in your quest. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing Bolt: The Chainstack technology made for simple node synchronization Every distributed ledger network is run by a collection of nodes whether public, private or consortium in nature. These nodes interact with blockchain networks to facilitate several activities such as querying data, executing transactions, managing wallets, and many more. Also, as with all decentralized networks, each of these nodes keeps a copy of all network transactions.  While this concept isn’t necessarily complicated, the process of developing and deploying a blockchain, and its associated nodes, can be intimidating. This perception is especially true for companies that have established project budgets and specifications to which they must adhere. With 43% of organizations identifying blockchain as critically relevant, there is an apparent need to make this process easier.  Source: Deloitte’s 2018 Global Blockchain Survey That’s why Chainstack developed Bolt, a technology that makes node syncing and subsequent blockchain deployment simple. But what exactly is node syncing and why has it proven to be a pain point for adopters of blockchain technology?  As mentioned, nodes act as the backbone of any distributed ledger network. However setting up a truly synced node requires time, effort, and extensive technical knowledge. And let’s not forget that without these nodes, there’s no access to a blockchain network. To understand the real value of Bolt lets first delve into the typical process of node synchronization.  Synchronizing a conventional public node When initiating node synchronization on a public network, the intent is to download a copy of the existing blockchain. While downloading these pre-existing blocks is typically a quick process, it’s all of the associated data that slows down the process dramatically. This includes information such as account balances, smart contract code, and other stored data.   All of this information must be downloaded and cross-checked with the latest blocks independently – that’s a lot of information. On the public Ethereum mainnet, participant nodes track the balance, nonce, and other data associated with users and smart contracts.  This information must be cryptographically linked to each block so that nodes can verify if accounts have been subject to tampering. This cryptographic linking results in a massive data structure containing all individual accounts and intermediate cryptographic proofs known as a state trie.  To establish a truly synchronized node, you must download all of this account data, as well as all the associated cryptographic proofs to verify that no one in the network is trying to deceive you. This process produces a substantial collection of data points, but there’s even more to consider. While the node collects all of this data, the network is simultaneously moving forward and recording more transactions. Ultimately, you’re trying to gather all the recent data while also working to obtain all past blockchain activities.  And until you gather all of this data, your local node remains unusable since it can’t cryptographically prove anything about the blockchain accounts. Although this example refers to a public blockchain node, the same scenario can arise on private or consortium networks as they become more extensively used.  But what exactly are the challenges associated with node synchronization?  The challenges of blockchain node setup There are several challenges associated with the deployment of a blockchain network and its associated nodes. As mentioned, these issues are typically characteristic of public ledgers such as Ethereum and Bitcoin. However, mega-consortia blockchains handling massive amounts of data succumb to similar pressures.  Slow synchronization  When synchronizing hundreds of GB of blockchain data, all while trying to keep up with new network activity, it’s going to take awhile. Typically this translates to hours or even days – as they say time is money.  Data corruption and network instability  As all the data items stored in blocks are downloaded and linked together, corruption in one block can corrupt the entire blockchain. This scenario may occur as a result of a poor network connection amongst a myriad of other reasons. As a result, you could wait days for node synchronization only to find all your efforts have been a waste.   The cost of hardware and network traffic  Depending on the cost of network traffic for a particular distributed ledger, there could be significant costs associated with initial node synchronization. There’s no guarantee of how much this may cost – the amount of data is immense, and the volume increases continuously.  The synchronization process is also extremely disk intensive, requiring a lot of writes. This can put excess stress on your valuable hardware while consuming substantial amounts of disk space. Ultimately, this requires resynchronization to clear disk space or the constant expansion of storage capacity.  Evolution of Free Disk Space During Synchronization  Bolt makes blockchain node setup easy  With the downsides of conventional node syncing assessed, it’s easy to show you why Bolt is a game changer. Whether you’re planning to deploy a public, private, or consortium blockchain network, Bolt has you covered.  Saving you time  To speed up the syncing process, Chainstack creates regular snapshots of the ledgers we support. When a node creation request is initiated, our platform restores the ledger on the node from the latest snapshot. As a result, there is no need to sync all the way through the blockchain. Instead, only the data added since the latest ledger snapshot needs to be downloaded.  This functionality ensures you have a fully synced node in just minutes – not hours or days. Bolt is a simple and robust technology that helps you spawn any number of nodes quickly and without the need for technical know-how.  Saving you money  As mentioned, the cost of network traffic can be significant when syncing a node due to the immense volume of data being downloaded. And although a fully synced node still requires the appropriate hardware to perform optimally with Bolt, Chainstack takes care of this for you. As a platform user, you’ll never worry about hardware costs or the high disk impact of syncing activities. You avoid investing in expensive hardware and potentially costly network traffic – that’s a win.  Bolt makes the future user-friendly  Bolt was developed to cut down on the time and money required to get a blockchain network up and running. With 84% of organizations reporting some involvement in blockchain technology, it couldn’t come at a better time. While conventional node synchronization requires significant time, money, and technical knowledge – Bolt makes the process simple.  Operating through an intuitive user interface, Bolt handles all the complexities of node synching and subsequent blockchain deployment. Through the use of innovative tools like Bolt, hurdles to blockchain adoption can be overcome. Like many others in the decentralized ecosystem, the Chainstack team understands that the future is user-friendly. Try it out for yourself; the future of blockchain deployment is only a few clicks away!  Explore Chainstack Try Chainstack for free Access our developer resources and community Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing Chainstack Elastic Subgraphs: DeFi data made easy ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. Subgraphs migrated to Ormi. See migration details It’s been an exciting journey in the world of decentralized finance, and today, we’re making it even more exhilarating with the release of our Elastic Subgraphs. As The Graph concludes its host service, we bring you an enhanced experience on Chainstack with our upgraded Subgraphs that are simple yet effective, providing a seamless transition for users. This release is about offering greater access to DeFi protocols, providing efficient query data without the need for deployment or programming. Simplifying your interaction with DeFi protocols like Uniswap, Curve, and PancakeSwap has never been easier. It works just like plug-n-play! Understanding the differences between our new Elastic and Dedicated Subgraphs is crucial, so allow us to walk you through it. From the cost-free compute of Elastic Subgraphs to the more personalized support of Dedicated Subgraphs, we aim to offer options that best suit your needs. Let’s explore! Access major DeFi protocols with Elastic Subgraphs As a Web3 developer, we know you are always on the lookout for streamlined ways to interact with different DeFi protocols. With the release of Chainstack Elastic Subgraphs, we’ve got just the solution for you. Our console now supports default access to 8+ major DeFi protocols—including the likes of Uniswap, Curve, PancakeSwap, and others. This massive leap forward means you can now query DeFi data more efficiently than ever before. From getting real-time prices to analyzing liquidity pools, you no longer need to switch between multiple interfaces or write complex codes. Just a few clicks in the Chainstack platform, and you’re all set to obtain valuable data from your selected DeFi protocol with utmost ease. This is one of the many ways we’re walking the extra mile to make your blockchain development journey smoother, easier, and more productive. Elastic and Dedicated Subgraphs comparison Now that we’ve leveled the playing field by including support for numerous major DeFi protocols, let’s venture further into the possibilities that our Elastic and Dedicated Subgraphs open up. On one hand, we have Elastic Subgraphs, which come available in console by default, require no added compute costs, and offer broad support for over 8+ major DeFi protocols. This gives you an out-of-the-box solution to query data using only request units (RUs), saving you the time, effort and cost associated with compute resources: Available in console by default Supports 8+ major DeFi protocols No compute cost 1 subgraph request = 20 request units (RUs) Try Demo Opposing this, we offer Dedicated Subgraphs, tailored for more advanced needs. While they require deployment and development and carry a minimal $0.1/hr compute cost, they offer the advantage of supporting over 9 networks—a boon for developers looking for versatility in their projects: Requires deployment and development Supports over 9 networks $0.1/hr Compute cost 1 subgraph request = 20 request units (RUs) Try Demo Whether you’re leaning towards the cost-efficient Elastic Subgraphs or the versatile Dedicated Subgraphs, choosing Chainstack equates to picking a solution designed with the developer in mind. Now that we’ve unraveled the features and opportunities, the power’s in your hands to make the choice that suits your developmental needs best. Transitioning from data APIs to Subgraphs Data APIs have been the go-to workhorse for many Web3 developers, but the transition to Subgraphs opens up an unprecedented breadth of possibilities. With the Elastic Subgraphs release, you’ll now find former data APIs in the Subgraphs section, offering a seamless transition experience. The benefits of this move are two-fold. Firstly, Subgraphs offer a higher degree of flexibility and precision than traditional Data APIs. You will be able to conduct more specific and nuanced queries, and obtain more exact and comprehensive results. Secondly, the shift supports a sustainable, long-term solution. Subgraphs are inherently more scalable and adaptable to emerging trends in the blockchain space, safeguarding your development projects against future changes. The migration from Data APIs to Subgraphs is a significant step forward for us at Chainstack, and we firmly believe it will be a valuable transformation for the Web3 development community as well. How to get started with Chainstack Subgraphs Eager to roll up your sleeves and dive into the world of Chainstack Subgraphs? Here’s a quick guide to getting started: Start by navigating to the Subgraphs section on the Chainstack platform. Here, you’ll find all the necessary tools and resources to begin your journey. Next, select the subgraph you’re interested in from our expansive list of popular DeFi protocols. With Elastic Subgraphs, support for multiple DeFi protocols comes by default, saving you the time and effort typically required for deployment. If you’ve been using our Data APIs, you’ll find them conveniently located in the Subgraphs section. Try Elastic Try Dedicated We designed this process with simplicity in mind, ensuring you can kick-start your Subgraph exploration without any hurdles. But if, for any reason, you find yourself unsure or needing assistance, remember that our support team is always ready and eager to assist you. Your success with Web3 development on the Chainstack platform is our primary goal. Bringing it all together We believe that our new Elastic Subgraphs, coupled with the existing Dedicated Subgraphs, offer an unparalleled experience for Web3 developers. These tools provide robustness and flexibility, empowering you to interact with DeFi protocols like never before. This major release is just one of the ways we’re constantly striving to make blockchain development more accessible, efficient, and seamless. As always, your feedback and success are invaluable to us. If you have any questions or need help navigating these new features, don’t hesitate to reach out to our support team. We are thankful for your continued trust in Chainstack. Together, lets keep pushing the boundaries of what’s possible in the realm of blockchain technology. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing Chainstack’s partnership with BreezeHost We’re partnering with BreezeHost — an independent, in-house–engineered hosting provider delivering cloud VPS, bare metal dedicated servers, and GPU instances with 99.9% uptime SLA and 24/7 expert support. Chainstack Self-Hosted is available pre-installed on BreezeHost servers. Deploy and operate blockchain nodes across major protocols from a single control panel — with self-healing automation and enterprise-grade reliability built in from the ground up. What you’re getting Chainstack Self-Hosted on BreezeHost gives you: Self-healing and auto-updates — nodes recover from failures automatically, with built-in high-availability options. Any major protocol, instant setup — select the network and node type, snapshots speed up initial sync. Monitoring and observability — built-in health tracking, configurable alerts, observability-ready metrics. Right-sized configurations — protocol-specific recommendations that improve stability and cut waste. Enterprise-grade security — encryption, access controls, and deployment on infrastructure you control. Your keys, your nodes, your rules. Built-in integrations — plug into common tooling so Self-Hosted fits your existing stack and workflows seamlessly. Built for high-throughput RPC applications, trading bots, and production apps that need reliable access without DIY node management. Get started Chainstack Self-Hosted panel is included at no extra cost with all BreezeHost plans. Use code CHAINSTACK50 to get 50% off your first month — Cloud VPS with Chainstack Self-Hosted from $29.50/mo, Bare Metal from $45/mo. Get Offer → About BreezeHost BreezeHost is an independent, in-house–engineered hosting provider built by people who actually run servers, write software, and care about doing things the right way. Founded in 2022 and now part of Limestone Networks, BreezeHost delivers cloud VPS, bare metal dedicated servers, GPU instances, and colocation services — all powered by software they built themselves, on infrastructure they designed for the future. Connect with us Join our Discord, Telegram, and follow us on X. Sign up for a free Developer account or explore our plans here. Learn more about Chainstack Self-Hosted. Want to run production-grade blockchain nodes on your own infrastructure? Contact our team to find the right setup for your workload. #### Introducing Chainstack’s Partnership with HOSTKEY We’re proud to announce our partnership with HOSTKEY — a bare metal and VPS provider with data centers across Europe and the USA. Starting today, Chainstack Self-Hosted is available as a pre-installed application on HOSTKEY servers. Teams can deploy a fully operational blockchain node in literally a few clicks on hardware they fully own and control. As part of this partnership, HOSTKEY customers can run production-grade blockchain infrastructure with: One-click Chainstack deployment — pre-installed and ready to work the moment your server is live Full infrastructure ownership — your data, your keys, your configuration Fine-tuned server configurations — hardware optimized specifically for blockchain node workloads 13 server locations — the Netherlands, Finland, Germany, Italy, France, Iceland, Turkey, Poland, the USA, the UK, Spain, Switzerland and France Chainstack Self-Hosted on HOSTKEY is available now on both VPS and Dedicated Servers.  Deploy here → About Hostkey As a global provider headquartered in the Netherlands, HOSTKEY delivers high-performance dedicated servers and cloud infrastructure for businesses where downtime isn’t an option. Combining enterprise-grade hardware with a global footprint, HOSTKEY helps companies scale with confidence while maintaining total control over their environment. Whether you’re managing intensive workloads or scaling at speed, HOSTKEY provides the stability and flexibility you need to stay ahead. Connect with us Join our Discord,Telegram and follow us on X Sign up for a free Developer account or explore our plans here Learn more about Chainstack Self-Hosted Want to run production blockchain nodes on your own infrastructure? Contact our team to find the right setup for your workload. #### Introducing Chainstack’s partnership with Serverside.com We’re partnering with Serverside.com — a dedicated bare metal provider built for teams who need reliable, high-performance infrastructure with full control over their environment. Chainstack Self-Hosted is available pre-installed on Serverside.com servers. Blockchain nodes, ready to go the moment your server is live. Running blockchain infrastructure at scale can be difficult, and costly if not done right. The protocols evolve quickly, deployment patterns vary widely, and downtime is unforgiving. Chainstack abstracts that complexity into a unified management layer that works across protocols and environments. We’re excited to bring it to our blockchain customers at Serverside.com and see what they build on top of it. Clay Berndt  ·  CEO, Serverside.com What you’re getting Chainstack Self-Hosted on Serverside.com gives you: Self-healing and auto-updates — nodes recover from failures automatically, with built-in high-availability options Any major protocol, instant setup — select the network and node type, snapshots speed up initial sync Monitoring and observability — built-in health tracking, configurable alerts, observability-ready metrics Right-sized configurations — protocol-specific recommendations that improve stability and cut waste Built for high-throughput RPC applications, trading and automation systems, and production apps that need reliable access without DIY node management. Get started Get 10% off blockchain-ready Serverside.com servers with Chainstack Self-Hosted pre-installed. Get the offer → About Serverside Serverside.com provides a scalable and sustainable alternative to traditional cloud solutions, delivering the flexibility and scalability of the cloud with the cost efficiency and control of on-premise infrastructure. Connect with us Join our Discord, Telegram, and follow us on X Sign up for a free Developer account or explore our plans here Learn more about Chainstack Self-Hosted Want to run production-grade blockchain nodes on your own infrastructure? Contact our team to find the right setup for your workload. #### Introducing Chainstack’s Partnership with Tempo We’re proud to announce our partnership with Tempo as part of their partner cohort, supporting teams bringing high-performance payments onchain. As Tempo develops its payments-optimized chain, Chainstack will enable builders to run payment-first infrastructure with: Low-latency, globally routed RPC for predictable execution Flat-fee Unlimited Nodes for scalable, high-volume workloads High-performance Dedicated Nodes designed for payment lanes and settlement flows Our mission is to provide the ecosystem with reliable, enterprise-grade infrastructure for production-ready payment applications — with the throughput, resilience, and operational consistency required by modern financial systems. Full Chainstack support for Tempo — including Global Nodes and Dedicated Nodes — with the Mainnet launch. About Tempo Tempo is a payments-native Layer 1 blockchain co-developed by Stripe and Paradigm, designed specifically for high-volume stablecoin transactions. Unlike general-purpose blockchains, Tempo focuses on predictable execution, built-in compliance, and real-world financial use cases such as merchant payouts, payroll, remittances, and global money movement. Targeting 100,000+ TPS, sub-second finality, and dedicated payment lanes that guarantee blockspace for transfers, Tempo is architected to solve the bottlenecks that have prevented blockchain from supporting production-grade payment flows at scale. Tempo also introduces a set of payment-optimized protocol features: TIP-20 token standard, extending ERC-20 with built-in memos, role-based access control, and compliance hooks. Native account abstraction, enabling passkeys, fee sponsorship, batching, and gasless UX through TempoTransactions. Fee flexibility, allowing fees to be paid in USD-denominated stablecoins instead of volatile native assets. Privacy and compliance primitives, including allowlists/blocklists, ISO-20022-style reconciliation memos, and opt-in privacy. Currently operating in a testnet, Tempo is building an ecosystem supported by partners such as Visa, Klarna, Deutsche Bank, Shopify, Revolut, OpenAI, and DoorDash, positioning itself as a serious contender in the rapidly growing landscape of blockchain-based payments. Connect with us Join our Discord server, Telegram group, and follow our X. Sign up for a free Developer account, or explore Growth and Business plans here. Use our pricing calculator to estimate usage and node requirements. Want to learn more about building payment-native applications or preparing for Tempo’s upcoming releases? Contact our team to explore how Chainstack can support your Tempo-powered products with low-latency infrastructure, trusted RPC, and scalable node deployments. #### Introducing Chainstack’s partnership with velia.net We’re partnering with velia.net — a dedicated server provider based in Germany, delivering enterprise-grade bare metal infrastructure purpose-built for Web3 and blockchain workloads. Chainstack Self-Hosted is available pre-installed on velia.net web3 servers. Blockchain nodes, ready to go the moment your server is live. What you’re getting Chainstack Self-Hosted on velia.net gives you: Self-healing and auto-updates — nodes recover from failures automatically, with built-in high-availability options. Any major protocol, instant setup — select the network and node type, snapshots speed up initial sync. Monitoring and observability — built-in health tracking, configurable alerts, observability-ready metrics. Right-sized configurations — protocol-specific recommendations that improve stability and cut waste. Enterprise-grade security — SOC 2 and ISO certified infrastructure with DDoS protection and slashing protection for validators. Built for DeFi infrastructure, Layer 2 solutions, and any production app that needs reliable RPC access without DIY node management. Get started Use code ChainstackSH80 for 80% off your first month — Chainstack Self-Hosted starting from €13.80/mo. Claim your offer → About Velia.net velia.net is a dedicated server provider delivering high-performance bare metal infrastructure with 99.9% uptime SLA and enterprise NVMe storage, built for teams that need low-latency, enterprise-grade infrastructure for demanding workloads. Connect with us Join our Discord, Telegram, and follow us on X Sign up for a free Developer account or explore our plans here Learn more about Chainstack Self-Hosted Want to run production-grade blockchain nodes on your own infrastructure? Explore Chainstack Self-Hosted → #### Introducing Corda managed service on Chainstack Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. It is only recently that the word “consortium” has become fashionable again. Often driven by the perception that many enterprises are not willing to collaborate, doubts exist that this both-old-yet-new type of organization stands to offer any value. Technical and governance issues among the budding consortia are often cited to be one of the biggest barriers to enterprise blockchain adoption, but human collaboration issues are typically larger than the tech itself. The fact of the matter is that many of the world’s enterprises are running on massive inefficiencies because they rely heavily on the processes and systems that are both weak and outdated. Hundreds of staff-years and billions of dollars are being lost to the reconciliation and validation of data involved in information exchange. Enabling multiple participants within a network to access accurate, real-time information eliminates the tedious processes that are traditionally involved in secure data transfer and sharing. Across industries, distributed ledger technology promises to provide us with a way to unlock the value that has been lost through inefficient collaboration. Blockchain technology optimizes collaboration, enabling enterprises to realize their true potential. Here at Chainstack, we like to say that blockchains extend collaboration, turbocharging consortia into the era of the mega-consortium. Optimizing entire markets is the new opportunity and enterprise blockchain is the key to delivering on this. Richard Gendal Brown R3 Corda This past year we’ve seen significant activity within the enterprise blockchain space­ and some very, very large blockchain-powered consortia. In particular, solutions built on Corda seem to be making the rounds. Voltron is a finance platform that leverages Corda to provide documentary trade finance users with global connectivity, real-time synchronized updates, full data provenance, and audit. Its pilot involved over 50 banks across 27 countries in 2018. The Corda-powered Marco Polo blockchain network connects the leading financial institutions like BNP Paribas, Commerzbank, ING all together on a single business network. Among governments, Corda has been utilized in projects to develop digital currencies with the Monetary Authority of Singapore and the Bank of Thailand. This list goes on. Corda was built with the sole purpose of creating a universally interoperable business blockchain network. Its solution to interoperability introduces a shared underlying network on which private networks can be built. This means that businesses both create and maintain private networks, but also easily interact with other private networks that exist on the shared network through a CorDapp.                                                       We’re fond of this idea because the interoperability and ecosystem vitality are correlated. The promise of the benefits of a network necessarily depends on the ability of its participants to interact seamlessly. Without which, private blockchain networks remain what R3 describes as islands of silo-ed data assets. Now, businesses have the potential to transfer data with any other business already on the Corda Network, even if they do not already share a private network. At the same time, this is only significantly useful if most of the organizations you want to transact with are on this network. Without participants or an extended network, the value of an interoperable application remains meaningless. After all, one necessarily needs a network before one can start experiencing the benefits of the network effect. The value of being a part of an interoperable network grows exponentially as it increases in size. And the R3 team recognizes this very well. Corda managed service on Chainstack This is why we are proud to announce the availability of Corda managed service today. This means that now anyone can effortlessly deploy consortium Corda networks based on the latest Corda open source version 4.1 in a few clicks and start running CorDapps in no time. All supercharged by Chainstack’s battle-tested multi-cloud orchestration engine. Our offering is a fully automated, self-service solution providing a convenient way for customers and partners to create new Corda networks, invite participants, dynamically add or remove nodes, install or remove CorDapps—all from a single interface. We made complex operations like NMS, doorman, notary services deployment and behind the scenes installation of CorDapps invisible to the users so that they can focus on the application business logic and not on the infrastructure. Moreover, our strategy is to never compromise on the quality of service—that’s why, for instance, we decided to use PostgreSQL as a database backend for Corda nodes by default instead of file-based H2 database which has known performance limitations. As part of this strategy, we run the official distributions of blockchain software without modifying it to be always up to date with the recent improvements and fixes. Not even mentioning that by design all networks and nodes running on Chainstack have auto-healing capabilities that make network operation reliable and smooth for the participants. Choosing to support Corda was an easy decision for us. We first met the R3 team back in 2018 in a developer bootcamp. We’ve encountered the Corda team on many other occasions from thereon. In fact, they were present with us as we celebrated the launch of our platform back in April 2019. Since then, in each successive encounter we’ve had, we’ve only grown increasingly impressed. Numerous discussions with existing Corda users helped us to refine the platform requirements and create a vision of an ideal managed solution. From MonetaGo, SIX, and HSBC, we’ve seen some of the largest names joining the Corda ecosystem this year. Only a month ago, Mastercard announced a new partnership with R3 to develop a new blockchain-enabled cross-border payment solution. R3 is truly partner-driven like Chainstack—it is home to one of the largest ecosystems of hundreds of customers and partners. Nothing says this more than the work being done at the Corda Network Foundation, an independent, neutral body established as a solution to many of the universal governance issues that plague enterprise blockchain projects to date. Empowering the developers and business networks Corda is showing the world that realizing the potential of blockchain-based consortia is possible. With Chainstack’s new Corda managed service, we hope to make it easier for the hundreds of enterprises already building on Corda, and the thousands more that will soon join the growing Corda ecosystem. We have been working very closely with the Corda team to get this right, and more resources will be poured into deeper integration and support over the next few months to make onboarding onto Corda as effortless as possible. Future support will include the ability to join Corda Testnet and Corda Network, manage identities on the network, and automate the network and node orchestration via an API. We’re excited to announce bringing the simplicity of Chainstack’s deployment to the Corda ecosystem. We are redefining the way enterprises can start optimizing processes by making it easier to collaborate better with Corda. Explore Corda with Chainstack Register and launch a Corda network for free Build a CorDapp with Chainstack Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing Corda Network on Chainstack Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Less than six months ago, we introduced managed Corda services onto Chainstack, giving our users the ability to automatically deploy high-performing consortium Corda networks and access the world of industry-changing CorDapps in just a few clicks. Since then, we’ve continued to work very closely with the R3 team, this time focusing on bringing our Chainstack magic to the Corda Network. Today, we are excited to announce the launch of the Corda Network automated onboarding on Chainstack. Now, enterprises can access the Corda Network in minutes instead of weeks with zero configuration effort. To help you get started, we’re also giving you $200 in credit to join the Corda Network on Chainstack, so that you can start experimenting for free. Corda Network—a global blockchain business network Launched in January 2019, the Corda Network is the underlying, open shared blockchain network that links entities using Corda Open Source or Corda Enterprise by providing business networks with a common layer of identity and consensus. Without intrachain interoperability, private networks remain what R3 describes as islands of siloed data assets. The network is governed by the Corda Network Foundation, an independent not-for-profit body. While the Corda Network is open to businesses of any size, industry, or location, all new entities are required to undergo a screening process during onboarding–a heavily manual and tedious process that spans several days. These checks are made to ensure that only legitimate entities can participate on the network, protecting participants and ensuring that they are able to transact safely. The entity must also simultaneously navigate between managing their certificate signing request information, X.500 fields, identities, trust root files, and deploying and configuring their Corda nodes. Chainstack’s new automated onboarding drastically simplifies this process. Once on the Corda Network, you can interact and transact with any other participating business network or entity on the network using CorDapps. This means that businesses can not only create and transact among private networks with trusted partners but also easily interact with hundreds of other nodes on the Corda network. Imagine the Marco Polo Network, with their over 70 participating banks, being able to connect to Contour, B3i, and other business networks across industries—trade finance, insurance, supply chain, healthcare, and more. This is how enterprises will be able to unlock the true value of distributed ledger technology, all while retaining the security and privacy they need. Be a part of one of the fastest growing consortia Chainstack’s identity management and Corda Network support provide businesses with a novel way to rapidly onboard and begin transacting with a world of CorDapps. Chainstack enables users to: Easily manage all identities and node certificates for the Corda Network (both production and pre-production) in a secure environment. Quickly create certificate signing requests for the Corda Network without having to handle any advance node configuration. Monitor your certificate signing requests success or failures in real time. No platform lock-in. Users can export their identities to be able to deploy elsewhere. How to join the Corda Network on Chainstack in 3 easy steps Register a legal entity with Corda Network and sign the agreement. Retrieve your legal name and enter the Chainstack Identity wizard. Create an identity in your secure vault and wait for it to be approved by the operator. Read more here. Once you have successfully onboarded onto the Corda Network, you can start deploying high-performing Corda nodes and begin interacting with your CorDapps in minutes—all from a single dashboard. Helping the Corda Network achieve scale with automated onboarding Onboarding is crucial to the value of a network because it gives it the ability to scale. As more entities onboard onto the Corda network, new possibilities of intra-network activity emerge as there are now more participants to transact with. This is how the value of the network will exponentially grow, and this is exactly how Chainstack’s automated onboarding will enable the Corda Network to achieve its vision of establishing itself as the global blockchain network for business, by making it easy for you to join. Next steps But that’s not all. Together with R3, we are making this process even simpler, and there will be yet another exciting announcement very shortly. In the meantime, come see what we’ve built. If you are currently keen on being a part of the future of enterprise blockchains, we invite you to unlock a world of possibilities with the Corda Network. You can sign up for a Developer plan at console.chainstack.com or learn more on our docs site. Feel free to contact us at if you need any ideas about how to get up and running. More on the Corda Network How “public-permissioned” blockchains are not an oxymoron A curated list of awesome Corda resources Top 5 facts about the Corda Network Corda Documentation Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Introducing new Growth tier and reduced costs for all plans TL;DR: Whether you are just starting out, already working on an MVP or PoC, or are now ready to deploy, we are on your side and want to support you along the way. For this reason, we have created a brand new Growth plan at $19 per month, slashed the Business plan monthly price 50%—down to $49. Node usage rates are reduced too and are now uniform across all cloud providers. Check the new pricing! Growth plan Fitting right between the starter Developer plan and the more mature Business plan, the Growth plan is what we had an overwhelming number of requests for. As your blockchain project moves from being a prototype or an MVP to the one with real users and requiring a small team to operate, the Growth plan at the fixed cost of $19 + dedicated node usage cost is your door into the adoption territory. You can also run multiple shared nodes, such as Ethereum mainnet and Ropsten testnet, for $19 flat, no usage cost. Reduced Business plan fixed cost We slashed the fixed Business plan cost in half—down to $49. Reduced usage rates The node usage costs have gone significantly down—as much as 55% for some cases. A dedicated Ethereum mainnet node on the Growth plan now costs $307 per month—$288 usage cost + $19 fixed cost. A three-node consortium network on the Growth plan now costs $473 per month—$454 usage cost + $19 fixed cost. Two dedicated Ethereum nodes (one mainnet, one testnet) and two dedicated Bitcoin nodes (one mainnet, one testnet) on the Business plan now cost $1417—$1368 usage cost + $49 fixed cost. It used to cost $1611 on the Business plan on Amazon Web Services—$1512 usage cost + $99 fixed cost. Uniform usage rates for all cloud providers The reduced usage rates are now the same for all cloud providers that we currently support, including the new ones that we’ll introduce. Custom plans for enterprise needs The Enterprise plan is now unique for each customer. Talk to us and we’ll make sure there’s a deal that works for you. That’s it. Five small steps for the pricing, one big leap for the developer blockchain adoption. Changes for existing customers For all existing Business plan customers: The usage rates on your subscription are updated, effective immediately.You will be transitioned to the lower fixed subscription cost automatically starting from the next billing cycle. Start building today Check the new pricing plans.Sign up.Build today. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram groupSign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Introducing new hosting options: Bring your own cloud, extended AWS and Azure capabilities Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. At Chainstack, we empower innovators by providing an open platform that enables a seamless experience of building on the blockchain. Since day one, we made it possible for our customers to deploy networks and nodes on the Chainstack-managed hosting layered over Amazon Web Services, Google Cloud Platform, and Microsoft Azure, while covering major regions such as the US, Europe, and APAC. This provided one of the most, if not the most, flexible managed blockchain services hosting offering in the market. However, we soon realized that this was not enough. With the release of Chainstack 2.2, we worked to close this gap. Today we are adding new deployment options to Chainstack, including seamless private hosting integration and enhanced AWS and Azure support. Bring your own cloud to Chainstack Over the course of many months of customer interviews and careful listening, we have heard many businesses and builders needing a solution for the resources they already owned or that were provided for by their customers. We had numerous conversations with boutique and large software houses, Fortune 500s of finance and legal industries, large-scale exchanges and traders, exploring with them what would have been the best way to maximize the impact of Chainstack for them and their clients. Common reasons for needing a private hosting option included: Complexity behind compliance, data protection, and localization challenges. Organizations already committed to infrastructure with cost-saving options, for example, AWS Reserved Instances or Saving Plans. Project stakeholders require more control and flexibility over resource sizing and deployment locations. Colocation of applications with blockchain nodes to get the lowest latency possible. Today we are releasing the private hosting feature, initially supporting Amazon Elastic Kubernetes Service with 20 regions available around the globe. Our customers now can: Increase network resiliency and decentralization through hosting regional distribution. Meet compliance requirements imposed by data localization standards. Leverage cost optimization options offered by their infrastructure providers. Colocate their applications with blockchain deployments managed by Chainstack. The best part is that Chainstack will continue to orchestrate private deployments, monitor health and activity, perform upgrades, and provide highly responsive support—within the same easy to use Chainstack UI and API. In addition to the EKS support for Amazon, we are already working on the next phase, which will extend our private hosting to other cloud providers and bare metal setups. If you would like to participate in the early testing of this next phase, feel free to contact us. We were looking for a solution that would offload our engineering team from DevOps and network management efforts. With Chainstack’s private hosting, we now can launch projects in European jurisdictions and seamlessly hand-off projects to our customers, all deployed on a secure, easy to use and fully managed platform. Stanislav Synko, CEO of Aleph One Aleph One, a FinTech Software Consultancy company working across North America and Europe, migrated their Hyperledger Fabric networks to Chainstack as an early adopter of Chainstack private hosting. They now perform 90% of their blockchain application development and testing on Chainstack. AWS US East support The blockchain industry has matured and evolved in many aspects over the past few months, and our customer base has significantly grown and diversified. In particular, Ethereum developers and entrepreneurs have found a trusted ally in us for their network access needs, especially for data discovery use cases like trading or indexing, largely depending on low latencies and fast transaction propagation speeds. To make sure that our growing community of builders and traders succeed, with this new release we will be supporting one of the most concentrated Ethereum mainnet locations in the world for our Chainstack-managed hosting—Amazon’s Ashburn data center. Thanks to the new hosting location, our customers will benefit from significantly lower times for transactions discovery and finalization, thus gaining a robust competitive advantage. This adds on to the existing rapid deployment feature Bolt, thanks to which our customers can deploy fully synced full and archive, mainnet and testnet dedicated nodes in minutes rather than hours and days. New Azure capabilities With Chainstack 2.2, we are also extending the availability of Ethereum and Bitcoin nodes in Microsoft Azure, with all mainnet and testnet, shared and dedicated options now fully supported. We hope that this change will help support the robustness of the infrastructure provided to the blockchain community as it will diversify deployment options for public blockchain nodes and provide an alternative other than what is already available on the market. Chainstack status Finally, we wish to remain at the forefront of engineering excellence, demonstrated by a track record of consistently near-perfect uptime. For this reason, we are launching a status page which includes historical uptime data and real-time information about Chainstack services availability. What’s next? We believe in the power of the decentralized web, and we strive to remain a core Web3 infrastructure provider. We believe that only by keeping a personal connection with our customers we can continuously improve and make Chainstack a better service every day. A big thank you from the entire team to all the early adopters and participants in customer development interviews who helped us validate how our hosting options could make innovators increase their ROI by adopting Chainstack. Watch out for new customer stories in our blog to get inspired by what our customers are building with us! With the market state in mind, from the OCC letter published in the first week of 2021 to a myriad of successful DeFi applications making their way to tangible market share, we feel that the blockchain industry is progressing on its path through Gartner’s slope of enlightenment towards a world where collaboration is enabled through blockchain. We will continue to innovate, push the boundaries of what can be achieved through precision engineering, and include a wider set of protocols. Our mission will remain to build and grow the most flexible and complete managed blockchain services provider on the market while making sure our customers get the best-valued service for its price with the highest quality. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.Have you already explored what you can achieve with Chainstack? Get started for free today. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing real-time Solana streaming with Yellowstone gRPC Geyser We’re excited to introduce Yellowstone gRPC Geyser, a real-time streaming service for Solana to Chainstack. Available now on Chainstack from the Growth plan, Yellowstone gives you lightning-fast access to Solana blockchain data—perfect for developers building next-gen DeFi apps, bots, dashboards, and analytics. Forget slow polling and heavy infrastructure. Yellowstone delivers real-time updates over a high-performance streaming protocol built for scale. $149 per month7 streams per account. $449 per month25 streams per account. Available for Global Nodes: Growth, Pro, Business, and Enterprise plans. Why Yellowstone? Tracking real-time activity on Solana has always been a challenge. The traditional way relies on constantly calling getProgramAccounts to check for changes—every few seconds—then processing huge amounts of data just to detect a single event. It’s slow, expensive, and hard to scale. Yellowstone changes everything. With Yellowstone, you get a direct stream of updates from Solana—accounts, transactions, blocks—delivered instantly to your app. No more polling. No more complex backend logic. Just clean, real-time data. Want to understand the getProgramAccounts method in detail? Check out our guide on Solana RPC methods and the Ultimate Solana Developer Guide. Key benefits Traditional ApproachYellowstone StreamingRepeated API calls every few secondsOne real-time stream per use caseFull dataset parsing to detect changesTargeted updates streamed instantlyExtra RPC calls for every eventMetadata fetched only when neededLatency: 60 seconds+Latency: Less than 1 secondHigh load on nodesMinimal node impact If you’re new to the core building blocks on Solana, explore our Solana Glossary or dive into the Mastering Solana series for deep technical primers on accounts, tokens, and program structure. What can you build with Yellowstone? Yellowstone is perfect for any project that needs real-time blockchain data: Live DEX monitoring (Raydium, Orca, Pump.fun) Real-time DeFi dashboards Trading bots and signal pipelines Token and wallet trackers Transaction indexers Need a reference for working with Solana DEX data? See our walkthrough on querying and analyzing Raydium data with Python. Powered by gRPC—built for performance Yellowstone uses gRPC over HTTP/2 for fast, efficient streaming. What does that mean for you? Lower latency: Updates stream the moment they happen Smaller payloads: Data is sent in compact binary format Smarter connections: One stream for multiple topics Easy integration: Auto-generated SDKs across languages Want to compare how this fits into broader RPC patterns? See Powerful Chainstack infrastructure optimized for Solana and how we support high-performance workloads across methods. Get started today Yellowstone is available now on Chainstack: Create account at Chainstack Create Solana node Purchase Geyser plugin Setup your streams Start streaming Solana Yellowstone gRPC Geyser is now live. If you’re building real-time infrastructure, streaming account state, indexing transactions, or operating in latency-sensitive environments—this is for you. To get started, activate Yellowstone directly in your Chainstack Console. Need more context before diving in? Browse our full Solana tool suite, or troubleshoot known issues using our Solana development error master guide. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing the Chainstack referral program You’ve probably already told someone to use Chainstack. A teammate, a founder friend, someone in a Discord server or a thread on X. You vouched for the infrastructure, explained why it’s reliable, maybe even walked them through getting started. Starting today, that recommendation is worth something. How it works The Chainstack Referral Program is simple: share your personal referral link, and when someone signs up and upgrades to a paid plan, you earn 20% of their subscription spend — for a full year. Every month they stay on a paid plan, the rewards hit your Chainstack balance automatically. No manual tracking. No waiting to find out if the referral counted. Just a link, a signup, and recurring rewards. Your referral link is already waiting for you in your Chainstack dashboard. You don’t need to apply, opt in, or do anything special to get access. If you have an account, you’re already in. How to get started Getting started takes about a minute. Create a free account — sign up and access the Chainstack console Get your referral link — open Settings → Referral program in the console Share it anywhere — in tutorials, communities, videos, threads, or DMs Start earning — earn 20% for one year from every referral that upgrades Who to refer The short answer: anyone building on Web3. Chainstack supports thousands of teams running RPC infrastructure — from solo developers prototyping their first dApp to large teams running high-traffic DeFi protocols. If you know a dev, a founder, or a team that’s still piecing together their infrastructure from multiple providers, Chainstack is a straightforward upgrade. Think about the people you’ve already sent to Chainstack. Or the ones you’ve been meaning to. A teammate spinning up a new project. A founder friend who’s been complaining about unreliable nodes. Someone in a Discord who asked what RPC provider you use. Those conversations happen naturally — the referral program just makes them count. What you can do with the rewards Rewards are credited directly to your Chainstack account balance. You can use them toward any Chainstack service — nodes, APIs, or anything else on the platform. If you’d rather take the money out, you can withdraw anytime by contacting support. There’s no complicated redemption process, no points system, no expiration. The rewards sit in your account and reduce your next invoice, or you request a payout. That’s it. Why 20% for a full year is a big deal Most referral programs pay a one-time flat fee. You refer someone, you get a $50 credit, done. The Chainstack Referral Program works differently — you earn a percentage of what your referral actually spends, every month, for twelve months. That means the reward scales with the value of the person you refer. If they’re running serious infrastructure at scale, your earnings reflect that. And because it’s recurring for a year, a single good referral can generate meaningful returns over time without any additional effort from you. The infrastructure already speaks for itself Chainstack is already the infrastructure layer for thousands of Web3 teams. Multi-chain node and API access, predictable pricing, global distribution, and reliability that holds up under real production workloads. When you refer someone to Chainstack, you’re not pushing a product you need to sell — you’re pointing people toward something that works. That’s the best kind of referral. Not a pitch, just an honest recommendation from someone who’s already building on it. Get started Your referral link is in your dashboard. Share it, and start earning. Get my referral link → Build on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing the new Chainstack Business plan We’re introducing the new Chainstack Business plan — rebuilt for DeFi teams, high-traffic dApps, and any project that has outgrown entry-level infrastructure. At $499/month, it brings 200M request units, 600 RPS, SSO, role-based access, and 20 nodes — everything a scaling team needs without the complexity of a custom enterprise contract. If you’re running production workloads, managing a growing team, or simply tired of watching your request quota — here’s everything that’s included and why it matters. What’s included 200M request units per month The centerpiece of the Business plan is 200M included request units per month — a significant step up from the 80M on the Pro plan. More included requests mean more predictable infrastructure costs. Instead of constantly monitoring usage and worrying about overage charges, you get a large, reliable quota that covers the demands of production workloads. Whether you’re querying blockchain data, serving end users in real time, or running automated pipelines, 200M Request units gives you the headroom to build without second-guessing your infrastructure. For context, 200M Chainstack Request units is equivalent to approximately 5B Alchemy Compute Units or 4B Quicknode API Credits — making the Business plan one of the most competitive options in Web3 infrastructure at this scale. And if you go over? Extra usage on the Business plan costs $10 per 1M Request units — significantly lower than on lower-tier plans. Compare it yourself → 600 requests per second throughput The Business plan supports 600 RPS — up from 400 RPS on Pro. Whether you’re running a trading bot, a real-time dashboard, or a high-frequency dApp, 600 RPS keeps your application performing under load without throttling or surprises. 20 nodes With 20 nodes included, you have the flexibility to spread your infrastructure across multiple blockchains, environments, or use cases — all within a single plan. Need dedicated nodes for mainnet and testnet? Multiple chains? Separate environments for different products? Twenty nodes gives you room to architect your setup the right way, without compromising where it doesn’t make sense. The Business plan also includes access to Dedicated Nodes — fully isolated infrastructure with guaranteed performance and uptime, ideal for production-grade applications that need complete control over configuration, network access, and data privacy. Role-based access and unlimited users As your team grows, so does the need for proper access control. The Business plan includes multi-user role-based access, letting you assign permissions based on what each team member actually needs to do. Developers get what they need to build. Admins manage infrastructure. Analysts access data. Everyone works within their scope — reducing risk and keeping your environment clean and auditable. There’s no cap on users either. The Business plan supports unlimited users, so you’re never forced to choose who gets access as your team scales. Single Sign-On (SSO) Authenticate your entire team through your existing identity provider with Single Sign-On. Less friction, better security, and one less set of credentials to manage — SSO is exclusive to the Business plan and above. Archive data access Need to query historical blockchain state beyond the latest 128 blocks? The Business plan includes archive data access across all supported protocols. Archive node requests count at 2 Request units per request, giving you the flexibility to mix regular and archive queries within your monthly quota. Global Node and WebSockets The Business plan includes access to Chainstack’s Global Node — geo-balanced, ultra-reliable RPC API infrastructure designed for unbounded performance. Requests are automatically routed to the nearest available endpoint, keeping latency low regardless of where your users are. WebSockets support is also included, enabling persistent, real-time connections for applications that need to stream on-chain events without constant polling. Platform API and automation The Business plan unlocks the Chainstack Platform API, giving you programmatic control over your infrastructure. Automate node provisioning, manage projects, monitor usage — all through a clean API rather than clicking through a dashboard. Marketplace apps and add-ons The Business plan includes access to the Chainstack Marketplace, where you can extend your infrastructure with ready-made add-ons — including Unlimited Node, a flat-fee RPS-tiered endpoint for nonstop performance with unlimited API calls. Chainstack Business is the top choice for EVM projects For EVM-based projects, the numbers speak for themselves. Running a realistic EVM trading workload — contract calls, transaction lookups, block queries, event indexing — here’s what the same usage costs across providers: Chainstack Business: $499/month — $0 extra. Save 66%. QuickNode Business: $1,294/month — 2.6x more expensive. Alchemy Pay-As-You-Go: $1,447/month — 2.9x more expensive. Chainstack Business vs QuickNode vs Alchemy for EVM methods; Source: Chainstack The difference comes down to multipliers. QuickNode and Alchemy apply 20–60x per-method multipliers that inflate costs unpredictably. Chainstack charges 1 Request unit per request, period. Chainstack Business is the top pick for Solana devs For Solana developers, the savings are even more dramatic. Running a realistic Solana DeFi load — 80M getAccountInfo, 40M getProgramAccounts, 30M getTokenAccountsByOwner, 25M getTransaction, 15M getBalance, 10M getSignatureStatuses — here’s what the same 200M requests costs across providers: Chainstack Business: $499/month — $0 extra. Save 88%. QuickNode Business: $3,999/month — 8x more expensive. Alchemy Pay-As-You-Go: $1,449/month — 2.9x more expensive. Solana methods on QuickNode carry 40x multipliers. On Chainstack, it’s always 1 Request unit per request. Chainstack Business vs QuickNode vs Alchemy for Solana methods; Source: Chainstack See full plan comparison → Who is this plan for? The Business plan is built around real use cases — here’s who it’s a natural fit for: DeFi protocols and trading platforms that need high throughput and zero downtime. When your users are executing trades in real time, 600 RPS and 200M included requests mean your infrastructure never becomes the bottleneck. Peanut Trade runs market making at scale on Chainstack — exactly the kind of latency-sensitive, high-frequency workload the Business plan is built for. Growing engineering teams that need access control. As your team scales, you can’t have everyone sharing the same credentials. Role-based access and SSO let you manage who can do what — without friction. Multi-chain projects running across several networks or environments. With 20 nodes included, you can cover mainnet, testnet, and multiple chains without consolidating where it doesn’t make sense. Whale Alert monitors large transactions across multiple blockchains simultaneously — 20 nodes gives exactly the kind of multi-chain coverage that makes this possible. Analytics and data-heavy applications that require archive data. If you need to query historical state beyond the latest 128 blocks, archive access is included — no separate plan required. CertiK slashed their Ethereum archive costs significantly by switching to Chainstack — a perfect example of how included archive access changes the economics for data-heavy teams. Ready to upgrade? Head to your billing settings to switch to the Business plan. If you’re currently on the legacy $349 Business plan, note that switching to the new plan is a one-way move — there’s no option to revert back. Have questions? Reach out to us at support@chainstack.com — we’re happy to help you figure out if this plan is the right fit for your use case. Get started on the Business plan → Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing the new Pro plan: Power, Performance, Simplicity At Chainstack, we’re redefining what value means in Web3 infrastructure. Our new Pro plan is simply unmatched—80M requests for just $199. More than most projects will ever need, at the simplest pricing in Web3. No hidden fees, no surprises—just seamless scaling at an unbeatable price. Upgrade to Pro now and scale your Web3 infrastructure with premium performance and advanced features. Until March 7th, get your first month for just $150 on your first upgrade—an exclusive offer to power up at the best price! Go to the Chainstack console to claim your discount before it’s gone! Why Pro? The Pro plan is an unmatched offer in Web3 infrastructure—no one has ever done this before. It’s the true gateway to building at scale, delivering high-speed and cost-efficient blockchain access with no compromises. Key benefits: 80M requests per month (≈ 2B CUs/API Credits) 400 RPS for high-speed performance Only $12.5 per extra 1M RU (one of the lowest costs in the industry) Global Node, Trader Node, Unlimited Node, and Dedicated Node support Chainstack Subgraphs Warp transactions for ultra-fast execution Debug & Trace API for deep analytics Unlimited users & projects All of this for just $199/month. Performance and usage With 80M requests per month (≈ 2B CUs/API Credits) and a 400 RPS throughput, the Pro plan ensures your project can handle high-demand workloads efficiently. Additional usage is also cost-effective, with extra 1M request units priced at just $12.5—an unmatched for this price scaling without worrying about excessive fees. Nodes and infrastructure The Pro plan offers robust node support, including Global Node, Trader Node, Unlimited Node, and Dedicated Node. This means you get access to high-speed transaction propagation and enhanced blockchain connectivity. Additionally, Chainstack Subgraphs allow for powerful data indexing and querying. The Warp Transactions feature ensures ultra-fast execution, while the Debug & Trace API provides deep insights for developers looking to optimize their applications. Platform features and security The Pro plan includes essential platform features to support teams and projects at scale. With 15 included projects and unlimited users, collaboration is seamless. Developers get access to node logs and the Platform API, while security is reinforced with multi-user role-based access logs and Two-Factor Authentication (2FA). Additionally, the Marketplace integration opens up third-party tools to extend functionality further. The best value in Web3 infrastructure When it comes to blockchain infrastructure, cost-efficiency and transparency are crucial. Many providers impose hidden fees and complex pricing structures, making it difficult to predict your monthly costs. At Chainstack, we ensure flat and transparent pricing across supported networks—helping developers avoid unpredictable expenses and stay focused on building. Figure 2: Chainstack method call and request comparison; Source: Chainstack Let’s look at the numbers for EVMs and Solana: Chainstack Pro is top choice for EVM projects For EVM-based projects, Chainstack Pro is literally unbeatable. We designed the Pro plan to deliver 2x higher RPS on average, largest request quota, and lowest extra usage pricing—all for just $199/month. Unlike other providers, which apply aggressive method-based multipliers, Chainstack offers flat, predictable pricing, allowing you to scale without unexpected costs. Benchmarking real-world EVM workloads To truly compare cost efficiency, we’ll examine an average EVM load profile—a realistic mix of commonly used RPC methods in high-throughput applications. These include contract calls, transaction lookups, event indexing, and gas estimation, all fundamental to DeFi platforms, NFT marketplaces, and blockchain analytics tools. By evaluating how Chainstack, QuickNode, and Alchemy handle this workload, we can see how pricing scales in practical scenarios. This breakdown highlights the impact of method-based multipliers on total costs and demonstrates why Chainstack Pro offers the most predictable and affordable pricing for EVM developers. Chainstack Pro: $199/month for 80M request units, with no extra usage fees, (+ extra 25M left). QuickNode Scale: $703/month, including a $499 subscription fee and $204 in additional usage costs—making it 3.5x more expensive than Chainstack. Alchemy PAYG: $666/month, entirely usage-based, with high method multipliers driving up costs unpredictably. Figure 3: Chainstack Pro vs QuickNode vs Alchemy for EVM methods; Source: Chainstack Cost breakdown per EVM method eth_call: 13.3M calls for Chainstack, 266M API Credits on QuickNode (20x multiplier), 346M Compute Units on Alchemy (26x multiplier). eth_getLogs: 10M calls for Chainstack, 200M API Credits on QuickNode (20x multiplier), 600M Compute Units on Alchemy (60x multiplier). eth_blockNumber: 3.4M calls for Chainstack, 68.8M API Credits on QuickNode (20x multiplier), 34.4M Compute Units on Alchemy (10x multiplier). eth_estimateGas: 40M calls for Chainstack, 800M API Credits on QuickNode (20x multiplier), 800M Compute Units on Alchemy (20x multiplier). Why EVM developers choose Chainstack Pro More than 72% cost savings compared to QuickNode and Alchemy Flat $199/month pricing with no surprise fees No aggressive multipliers inflating per-method costs The best cost-to-performance ratio, ensuring high-throughput scaling With Chainstack Pro, developers can confidently scale their EVM applications without worrying about skyrocketing costs, making it the most cost-effective and transparent choice in the market. Chainstack Pro is top pick for Solana devs For Solana developers, Chainstack Pro offers unmatched value, delivering superior RPS, the highest request quota, and the lowest extra usage fees—all for just $199/month. While competitors rely on method-based multipliers that inflate costs, Chainstack keeps pricing simple and transparent, ensuring predictable scaling without hidden fees. Benchmarking real-world Solana workloads To accurately compare cost efficiency, we’ll examine a realistic Solana load profile—a mix of commonly used RPC methods essential for high-throughput applications. These include account lookups, transaction status queries, and token ownership checks, all fundamental to DeFi platforms, NFT marketplaces, and blockchain analytics tools. By evaluating how Chainstack, QuickNode, and Helius handle this workload, we can see how pricing scales in real-world scenarios. This comparison highlights the impact of method-based multipliers on total costs and demonstrates why Chainstack Pro offers the most predictable and affordable pricing for Solana developers. Chainstack Pro: $199/month for 80M request units, with no extra usage fees. QuickNode Scale: $941/month, including a $499 subscription fee and $442 in additional usage costs, making it 4.7x more expensive than Chainstack. Helius Growth: $755/month, including a $49 subscription fee and $706 in additional usage costs, making it 3.8x more expensive than Chainstack. Figure 4: Chainstack Pro vs QuickNode vs Helius for Solana methods; Source: Chainstack Cost breakdown per Solana method getProgramAccounts: 11.8M calls for Chainstack, 473.9M API Credits on QuickNode (40x multiplier), 118.4M Compute Units on Helius (10x multiplier). getTokenAccountsByOwner: 13M calls for Chainstack, 523.2M API Credits on QuickNode (40x multiplier), 13M Compute Units on Helius (1x multiplier). getSignatureStatuses: 1.6M calls for Chainstack, 64.4M API Credits on QuickNode (40x multiplier), 1.6M Compute Units on Helius (1x multiplier). getAccountInfo: 18M calls for Chainstack, 721.9M API Credits on QuickNode (40x multiplier), 18M Compute Units on Helius (1x multiplier). Why Solana developers choose Chainstack Pro More than 79% cost savings compared to QuickNode and Helius Flat $199/month pricing with no surprise fees No aggressive multipliers inflating per-method costs The best cost-to-performance ratio, ensuring high-throughput scaling With Chainstack Pro, developers can confidently scale their Solana applications without worrying about skyrocketing costs, making it the most cost-effective and transparent choice in the market. Bringing it all together The Chainstack Pro plan is the undisputed best choice for developers looking for maximum performance, cost efficiency, and scalability. With the highest request quotas, lowest extra usage prices, and most predictable costs, you can focus on building without worrying about infrastructure expenses. Whether you’re working on DeFi, NFT marketplaces, trading platforms, or large-scale Web3 applications, Chainstack provides the fastest, most affordable, and most scalable infrastructure available today. Highest RPS for your money Most generous request quota Lowest extra usage price No hidden fees, ever Transparent, flat pricing Ready to scale? The Pro plan is available now, offering the perfect blend of cost-efficiency and high performance. Whether you’re a fast-growing startup or an established Web3 business, Chainstack provides the infrastructure to support your journey. Start building with Chainstack Pro today! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Introducing Unlimited Node—The end of RPC pricing complexity Unlimited Node is a new billing add-on that gives your project unlimited RPC requests within a chosen RPS (requests per second) capacity—for a flat monthly fee. In an industry where pricing models are often complex, relying on per-request billing, method-based multipliers, and punitive usage tiers, Unlimited Node offers a clear alternative. As an optional add-on, it can be enabled for any existing node on the Chainstack platform, instantly converting it into an Unlimited Node. With Unlimited Node, you benefit from unrestricted request volume within the selected requests-per-second (RPS) tier, eliminating unpredictable costs and enabling seamless scalability. This model ensures developers and organizations can build and deploy applications with confidence, without worrying about unexpected usage fees or overage penalties. A game-changer in blockchain infrastructure pricing Unlimited Node is available starting from the Growth plan, and you can mix and match Unlimited Nodes and quota-based nodes within the same project for ultimate flexibility. Key benefits: Flat monthly pricing: Complete control over your infrastructure budget. Unlimited requests: Use as much as you need within your RPS tier. Simple RPS tiers: Pick from 25 to 1,000 RPS. All networks included: Available across all supported chains. Always-on performance: Reliable node access, built for production. Use your node however you want—bots, trading systems, data backfilling, AI agents, monitoring scripts—without worrying about request costs or usage spikes. Unlimited Node was built for real Web3 builders With Unlimited Node, we’re launching the first truly predictable, flat-rate billing model for RPC nodes—available for everyone, not just enterprise deals or custom setups. Unlimited Node is perfect for: Trader infrastructure Web3 data analytics Wallet providers Multi-chain DApps Whatever your use case, Unlimited Node gives you the power to scale without fear. How it works Deploy a Global Node from the Chainstack console. Open the node details and apply the Unlimited Node add-on. Choose your RPS pricing tier based on your needs and budget. Start building—without worrying about infrastructure costs ever again. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Is your EVM node good enough? A while ago, I built a tool called the EVM speed tester. It was built for one of the most fundamental questions in the blockchain space—how fast a node can spot transactions in the mempool of EVM chains. Speed tester is a pure front-end web application; what it does is uncomplicated: A set of nodes listen to the network mempool to spot the same transaction identified by its hash and to retrieve it.The node with the shortest time between the transaction initiation and the moment it can retrieve it from the mempool wins the race.To make it fair, they take turns in sending the transactions. However, this tool can be expanded—and we’ve received great feedback to do so. There are many other important aspects of a node—other than just transaction spotting. People spend a lot of time and money to find the right tool, but not everybody understands right away that it is equally important to find the right node. Hence, here is another tool to help. Node performance insider Node performance insider is an analysis tool for EVM nodes. It is lightweight, plug-and-play-ready, and hassle-free. It provides basic information and common metrics for a node: for example, chain ID and network latency; the tool also measures some other less common metrics, for example, total gas value in the transaction pool. Before starting, there are a few things you should know. Use a WebSocket endpoint if possible.By default, the tool stops monitoring in 20 seconds. This can be changed in the source code.Depending on the node, a huge number of requests will be generated during testing, the faster the node is.Usually, around 200 requests are sent every second to the node but it can go higher than that. Generally speaking, the number of requests = number of transactions received + 1000/network latency (ms). If the network latency is as low as 10ms, it generates 100 requests more than a slow network.If any metric does not show, this is normal.Some node providers do not expose some namespaces like txpool. Some node providers limit the request rate from users. All of that will result in an incomplete report. Detailed explanation and system requirements are included in the latter part of this article. If everything goes well, you should see something like this: Should you find it difficult to understand this report, please keep on reading. In the following section, I will explain what is peer count, network latency, transaction volume, and the tx pool value, as well as why they are important to users. What happens after a blockchain transaction is sent Firstly, let us see how the transaction works on EVM: When a transaction is initiated from a client—for example, your laptop—it is first sent to the EVM node to which the client is connected. Then a special series of interactions happens among the connected nodes, aka the blockchain network. A blockchain is all about “transactions”, “nodes”, and “blocks”. There are two types of nodes for EVM networks: regular nodes and miner nodes. When a transaction reaches an EVM node, it is immediately broadcast out to the network. The transaction gets propagated to and stored in other nodes until it is “mined”. The “container” a node keeps the unfinalized transactions in is called txpool. Txpool is very important for a miner node. Miner nodes are no different from others except they have the ability to create “blocks”. For proof-of-work blockchains like Ethereum and Bitcoin, the miners compete with each other by constantly solving difficult hash questions. Once a miner wins the competition, it is then granted the right to “mine” a block. A block contains transactions. Only after a transaction enters a block, it is considered finalized. Each transaction contains “gas”. Gas is the fee paid to the miner as a reward. The transactions in txpool with high gas always get picked up first. After a new block is created, the miner notifies the network about the news. Other nodes in the network eventually receive the new block and merge it into their local blockchain, with the highest block number on the tail. And that completes the full cycle of a transaction on EVM. Choose the right type of node What makes a node good or bad, really depends on its use case. For DApps, network performance is probably a very important part of the user experience. Imagine a user who wants to sell an asset ASAP but the network is so congested, that the requests keep getting bounced back and delayed. Devastating. By the way, check out how to get yourself a fault-tolerant setup as an end user. For miners, one of the important factors is the volume of transactions they receive and the gas fee in these transactions. Hypothetically, more transactions means a higher probability of getting a good transaction with a higher gas fee, hence more profit. Network latency is probably the least important metric for miners. Algo traders need the best of both worlds. A low latency network allows the trading endpoint receives and send information quickly. High transaction volume and timely block updates speed up the trading strategies optimization. About the performance insider configuration Not all providers give full access to the nodes. If you are using a free endpoint, it is likely that you can’t see all of the metrics because some namespaces are closed or the request rate limit. By the way, the Chainstack free RPC endpoint doesn’t set request limits. Chainstack dedicated node gives you full access to all namespaces necessary for this tool. Use Chainstack. Sign up with Chainstack.Deploy a full or an archive node.  Anyway, to summarise, the following namespace is needed for each part. How to improve performance Reducing network latency Most requests, for example, sending transactions and getting account balances, do not require node-to-node communication. All information needed is stored locally on the node. Network latency can be reduced by improving Internet speed and bandwidth. However, the most important factor may be geographical location. Below is a test conducted against the same node from different sides of the world. You can see the huge difference in network latency. Test result from Singapore Test result from São Paulo For DApp developers, it is important to find a host that is closer to the users. If the users are from around the world, hosting nodes in multiple regions could be an effective solution compared to upgrading network infrastructure. Improve transaction quality In general, the more transactions a node receives, the better; the higher the gas fee, the better; the higher the transaction value, the better. But all of these are not configurable by default. They depend on the network condition and the neighbours, aka peers. If a user wants high transaction volume, they probably want to deploy the node close to a node the DEX is running.If a user wants a speedy transaction, they probably want to deploy the node close to a strong miner. Geographical location can be another factor too. For example, a node in the US and a node in Japan may behave completely differently in the daytime and night-time. A node in the US EST may receive a lot of transactions in the daytime but very little at night, but the situation is the other way round in Japan. You can use this tool to visualize the node performance at different times and regions, and find out the best node to match your need. Conclusion If you have any questions, feel free to ping me on Twitter. I am also consolidating information for different node providers. If you can, please send a screenshot of your report and the following information to me on Twitter/Telegram/Discord, at your convenience. I will consolidate the information and share it in the next blog when I have enough. Your location.Your node provider.Geo-location of the node.Price of the plan. That is the end of this article. Thanks for reading. Happy coding. Cheers! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Jito explained: bundles, tips, and how MEV works on Solana This guide covers how MEV works structurally on Solana, what Jito provides at each layer, and how to plug into that infrastructure with real tooling. TL;DR By mid-2026, the Jito-Solana client runs on more than 95% of active stake, and Jito tips account for over 60% of all priority-fee volume on the network. Most developers building on Solana encounter MEV before they understand it. Jito is the dominant MEV infrastructure layer on Solana. For builders, Jito exposes four operational surfaces: Jito-Solana: modified validator client running on ~95%+ of staked SOL Block Engine: off-chain auction system for MEV-maximizing transaction bundles Bundles: groups of 1–5 transactions executed atomically with tip-based ordering ShredStream: direct shred delivery from Jito-connected validators for sub-slot latency The typical MEV flow: searcher detects opportunity → assembles bundle → submits to block engine with tip → block engine runs auction → winning bundle lands atomically in validator block. Prerequisites Before working through this guide, it is recommended to go through: Types of nodes on Solana Basic DeFi primitives MEV on Solana MEV (Maximal Extractable Value) is the value captured by influencing the order, insertion, or exclusion of transactions within a block. On Solana, this surfaces as arbitrage across AMMs (like Raydium or Orca), liquidations on lending protocols (like Project 0 (ex-Marginfi) or Kamino), and back-runs after large swaps. Solana’s architecture makes MEV structurally different from Ethereum: SolanaEthereumBlock time~400ms~12sMempoolShared gossip networkPublic mempoolOrdering controlLeader-basedBuilder/proposer separationMEV layerJito Block EngineMEV-Boost relaysAtomic executionBundles (max 5 txns)Bundles (flashbots-style) On Solana, a leader validator controls block ordering for their assigned slot. Jito extends this by running an off-chain auction layer, the block engine, that determines the highest-value bundle ordering before passing it to the validator. The validator earns tips, the searcher gets guaranteed execution order. What is Jito? Jito Labs builds and maintains high-performance MEV infrastructure for Solana. The system operates across four components: Jito-Solana: a modified fork of the Agave validator client Block Engine: the off-chain auction and bundle routing service Bundle API: the JSON-RPC and gRPC interface for searchers ShredStream: low-latency shred delivery for downstream consumers Each component is independently useful. Together, they form the production MEV stack for Solana. Jito Architecture Validators run Jito-Solana, a modified Agave client. This client connects to the Jito Block Engine and accepts profitable bundle submissions in addition to normal transactions. Searchers, dApps, and Telegram bots connect to the block engine and submit transactions and bundles over gRPC or JSON-RPC. The block engine simulates submitted bundles, runs parallel auctions at 50ms ticks, and determines the highest-value combination to pass to the validator. The validator executes the winning bundles atomically and collects the tips. Tip revenue flows back to validators and their stakers, including JitoSOL liquid staking holders. Block Engine endpoint: https://mainnet.block-engine.jito.wtf To route to a specific region, specify the desired region: RegionEndpointNew Yorkhttps://ny.mainnet.block-engine.jito.wtfAmsterdamhttps://amsterdam.mainnet.block-engine.jito.wtfFrankfurthttps://frankfurt.mainnet.block-engine.jito.wtfTokyohttps://tokyo.mainnet.block-engine.jito.wtfSalt Lake Cityhttps://slc.mainnet.block-engine.jito.wtf For the full list of regions: https://docs.jito.wtf/lowlatencytxnsend/#api ⚠️ Pick the endpoint geographically closest to your submission infrastructure. Latency between your searcher and the block engine directly affects auction competitiveness. Searcher Scan visualizing 345 active searchers, 1,000 recent bundles, 1.4K SOL in tips, and the distribution of whale and retail bundle activity across the network. source: https://explorer.jito.wtf/searcher-scan Bundles Standard transactions submitted via gossip are visible to other network participants before they land. A searcher running an arbitrage between Raydium and Orca needs to ensure that their two-leg trade executes in order, without any transaction slipping between the legs. Bundles guarantee this. Max 5 transactions per bundle Executed sequentially in the specified order Atomically, all succeed or all fail Compete against other bundles via tip auctions at the block engine Minimum tip: 1,000 lamports per bundle If any transaction in the bundle fails or is invalidated, the entire bundle reverts — no partial execution. The block engine runs parallel auctions at 50ms ticks. Bundles with intersecting account lock patterns (write-write or read-write on the same account) compete in the same auction. Bundles that touch completely separate accounts run in independent auctions, parallelism is exploited where possible. Within a single auction, bundles are ordered by tip-per-compute-unit efficiency. Bundle usage has become a core part of Solana’s execution layer, with billions of bundles flowing through the block engine over the past year. source: https://explorer.jito.wtf/ Submitting a bundle: Endpoint: POST https://mainnet.block-engine.jito.wtf/api/v1/bundles curl https://mainnet.block-engine.jito.wtf:443/api/v1/bundles -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "id": 1, "method": "sendBundle", "params": [ [ "AT2AqtlokikUWgGNnSX5xrmdvBjSaiIPxvFz6zc5Abn5Z0CPFW5GO+Y3rXceLnqLgQFnGw0yTk3NtJdFNsbrwwQBAAIEsXPDJ9cMVbpFQYClVM7PGLh8JOfCD6E2vz5VNmBCF+p4Uhyxec67hYm1VqLV7JTSSYaC/fm7KvWtZOSRzEFT2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUpTWpkpIQZNJOhxYNo4fHw1td28kruB5B+oQEEFRI1i3Wzl2VfewCI8oYXParnP78725sKFzYheTEn8v865YQIDABhqaXRvIGJ1bmRsZSAwOiBqaXRvIHRlc3QCAgABDAIAAACghgEAAAAAAA==" ], { "encoding": "base64" } ] }' Jito implements a sandwich detection mechanism at the block engine level. When a bundle matches the pattern of a known sandwich (a buy transaction before a victim transaction and a sell transaction after it), the block engine rejects it. This is enforced at the infrastructure level — the block engine will discard bundles that match sandwich patterns, protecting users submitting through Jito-enabled paths. Check out this example bundle using the protection. source: https://explorer.jito.wtf/bundle/0748de4fd7a60c419da9fb09781157ab08e7b0adfbd664193c91f51e49af5491 Tips Tips are the economic signal inside the Jito system. A tip is a SOL transfer from the searcher’s wallet to one of eight Jito tip accounts. The validator receives this tip in exchange for including your bundle at its specified position in the block. Retrieve current tip accounts: curl https://mainnet.block-engine.jito.wtf/api/v1/getTipAccounts -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "id": 1, "method": "getTipAccounts", "params": [] } ' This returns a list of eight accounts. Include a SOL transfer to any one of them as the final transaction in your bundle. Tip sizing: Minimum tip: 1,000 lamports During high competition (active token launches, major liquidation events): tip floors rise substantially Query current tip market via REST: https://bundles.jito.wtf/api/v1/bundles/tip_floor WebSocket tip stream: wss://bundles.jito.wtf/api/v1/bundles/tip_stream The tips volume showing over 1.1 million SOL paid through Jito auctions, with clear spikes during periods of elevated MEV activity in the last year. source: https://explorer.jito.wtf/ Tip vs. priority fee: These two mechanisms are distinct and both apply to bundles: Priority FeeJito TipWhat it paysSolana base fee layerJito Block Engine auctionRecipientValidators (base protocol)Jito validator + stakersRequired forBase transaction inclusionBundle ordering priorityMinimumDynamic (compute units × fee rate)1,000 lamports A bundle requires both a valid priority fee on its transactions and a tip to a Jito tip account. Omitting the priority fee risks base-layer rejection; under-tipping on the Jito side means lower auction priority. source: https://explorer.jito.wtf/fee-stats Validators running the Jito client receive tips in exchange for including the bundle at the right position in the block. Because Jito also operates a liquid staking pool on top of this validator network, a portion of those tips flows back to ordinary stakers who have deposited SOL through the protocol. The TipRouter NCN (Node Consensus Network) decentralizes this distribution further, routing 6% of MEV tips to JitoSOL stakers and JTO governance token holders. ShredStream ShredStream is Jito’s low-latency block data delivery service. To understand what it does, let’s understand how Solana actually moves block data across the network. When a Solana leader validator produces a block, it splits the block data into small packets called shreds. These shreds propagate through the Turbine protocol, a tree-based broadcast network, to reach other validators and RPC nodes. A node receiving shreds via standard Turbine sits multiple hops away from the producing validator. Each hop adds time. ShredStream short-circuits this entirely. It streams shreds directly from Jito-connected validators to ShredStream subscribers without waiting for the Turbine fanout to reach them. The practical effect is hundreds of milliseconds of saved latency on incoming block data. For competitive MEV, this is the margin between detecting an opportunity within the current slot and detecting it in the next one. Use cases: HFT bots that need to react to chain state inside a slot MEV searchers monitoring on-chain state for triggers RPC operators serving latency-sensitive applications (DEX aggregators, trading frontends) Any infrastructure needing the freshest possible chain state Setup: ShredStream runs via a proxy that subscribes to Jito-connected validators. The proxy handles the direct shred delivery and exposes the data locally. Run via Docker with host networking recommended for lowest latency: docker run -d \ --network host \ jitolabs/shredstream-proxy:latest \ --block-engine-url https://mainnet.block-engine.jito.wtf \ --auth-keypair /path/to/keypair.json \ --desired-regions amsterdam,ny \ --dest-ip-ports 0.0.0.0:8001 View logs with docker logs -f jito-shredstream-proxy The full setup guide, including native binary and firewall configuration, is available at docs.jito.wtf/lowlatencytxnfeed. If you prefer not to run your own proxy, ShredStream is already included: Chainstack’s Solana Global Nodes include Jito ShredStream by default. In 2026, ShredStream has become standard for any infrastructure provider serving latency-sensitive customers, often wired in by default through the Yellowstone Geyser plugin. Chainstack pairs ShredStream with the Yellowstone gRPC Geyser plugin for structured real-time Solana data streaming: account updates, transaction confirmations, and slot notifications over gRPC, with ShredStream providing the sub-slot delivery path. For RPC access, Chainstack’s Global Nodes for Solana are geo-balanced across regions and include ShredStream integration, making them suitable as the RPC layer for MEV-adjacent infrastructure without operating your own validator. BAM BAM is the latest infrastructure milestone from the Jito ecosystem. Built on top of the existing Jito stack, BAM introduces TEE (Trusted Execution Environment)-based transaction sequencing using AMD SEV-SNP, separating transaction ordering from block validation entirely. Over 50% of Solana validators now run BAM. pic.twitter.com/GuB03fbONB— Jito (@jito_sol) June 5, 2026 BAM implements transaction sequencing through Trusted Execution Environments, enabling programmable block construction via custom plugins. The system operates through BAM Nodes that privately sequence transactions using hardware-based secure enclaves, and BAM Validators that execute the ordered transactions. The ordering is cryptographically attested at every step. The plugin framework opens an entirely new design space for application builders. Apps gain direct control over their transaction sequencing. Oracles can update instantly when needed. Orders can be cancelled without spamming the network. Developers can define application-specific ordering logic as BAM plugins, supporting use cases like priority cancellations for options protocols, synchronized oracle updates, and time-sensitive execution primitives. BAM also introduces a new value layer across the Jito network. All Jito fees, both BAM and block engine, route to the DAO Treasury. Plugin adoption directly benefits the Jito DAO. Validators, developers, and stakers each have a defined earning path within the system. This section is a light introduction to BAM and what it brings to the Jito ecosystem. For a deeper dive into the architecture, plugin development, and validator onboarding, visit bam.dev. Jito builder tools Developers building on Solana do not always need bundles. Whether to use them depends on the application. Bundles are useful when: Multiple transactions require atomic execution Liquidations must execute in order Arbitrage depends on deterministic settlement Trading strategies compete during congestion Standard transactions are often sufficient for: Wallet transfers NFT applications Consumer applications General-purpose protocol interactions Understanding this distinction helps teams choose the right execution path. When bundles are the right choice, the tools below provide everything needed to integrate them into any stack. Jito SDKs jito-py-json-rpc: Python SDK for interacting with the Jito Block Engine. Send transactions, submit bundles, and query tip accounts directly from Python applications. jito-js-json-rpc: JavaScript and TypeScript SDK for Node.js and browser environments, covering bundle submission, status polling, and tip account management. jito-rust-json-rpc: Rust SDK for high-performance MEV workflows. Designed for latency-sensitive searcher infrastructure built in Rust. jito-go-json-rpc: Go SDK for the Jito Block Engine API, covering the same bundle and transaction endpoints as the other language clients. Jito Resources docs.jito.wtf: Official Jito documentation covering bundles, tips, ShredStream setup, and rate limits. explorer.jito.wtf: Live MEV explorer with bundle history, tip distributions, and slot-level analytics. Tip floor REST API: Current tip floor data for calibrating bundle bids. Block Engine global endpoint: Primary bundle submission endpoint. ShredStream setup: Proxy setup guide for sub-slot block data delivery. RPC and Geyser Solana Global Nodes with ShredStream: Geo-balanced Solana RPC with Jito ShredStream included by default. Yellowstone gRPC Geyser plugin: Real-time account, transaction, and slot streaming over gRPC for latency-sensitive data pipelines. Solana MEV protection: Documentation covering MEV protection strategies on Solana. Solana trading infrastructure 2026: Overview of the full Solana trading stack for production systems. Improve Solana RPC latency with ShredStream: Guide on reducing RPC latency using ShredStream integration. Start for free: Get a Solana RPC node with ShredStream included. Ecosystem Jito Explorer: Bundle and tip analytics across the Jito network. BAM: TEE-based programmable block sequencing built on the Jito stack. Raydium: AMM and primary arbitrage surface on Solana. Orca: Whirlpool-based AMM, high tip-auction volume. Project 0: Lending protocol, active liquidation competition via Jito bundles. Kamino Finance: Yield and lending, liquidation-relevant for MEV searchers. Drift Protocol: Perpetuals DEX and BAM validator partner. Conclusion With over 95% of Solana’s staked SOL flowing through Jito-client validators, the block engine and its bundle auction are the production path for any strategy requiring execution guarantees. The architecture is layered and each piece has a distinct function. For builders in 2026, the practical checklist is: Use Jito bundles for any multi-transaction strategy requiring atomic execution Set priority fees on transactions and tips on your bundles, both are required Integrate ShredStream or use an RPC provider with ShredStream baked in (e.g. Chainstack’s Global Nodes) to minimize reaction latency The infrastructure is mature, the tooling is well-documented, and the adoption numbers confirm that operating outside this stack means competing at a structural disadvantage on every high-value transaction. Reliable Solana RPC node infrastructure Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers. Start building on Solana now → FAQ Do I need Jito bundles for every Solana transaction? No. Most applications can use standard Solana transactions without interacting with Jito at all. Bundles are primarily useful when multiple transactions must execute atomically, such as arbitrage, liquidations, complex DeFi workflows, or latency-sensitive trading strategies. For wallet transfers, NFT interactions, and typical consumer applications, standard transactions are usually sufficient. What’s the difference between a Jito tip and a Solana priority fee? They serve different purposes and are paid through different mechanisms. Priority fees increase the likelihood that a transaction is included by the Solana runtime during periods of congestion. Jito tips are bids submitted to the Jito Block Engine auction to improve a bundle’s ranking against competing bundles.For competitive bundle execution, both typically matter. A high tip with an insufficient priority fee can still fail to land, while a well-priced priority fee without a competitive tip may lose the Jito auction. Can bundles be partially executed? No. Bundles are atomic. A bundle can contain up to five transactions, and they execute sequentially in the specified order. If any transaction fails, all transactions in the bundle are reverted. This guarantees deterministic execution for strategies that depend on multiple state transitions occurring together. Does Jito eliminate MEV on Solana? No. Jito does not remove MEV; it provides infrastructure for discovering, auctioning, and executing MEV opportunities more efficiently. MEV still exists in the form of arbitrage, liquidations, back-runs, and other transaction-ordering opportunities. Jito’s role is to create a transparent auction mechanism that routes value to validators and stakers while improving execution guarantees for searchers and builders. When should I use ShredStream? ShredStream is primarily valuable for latency-sensitive infrastructure. Common use cases include MEV searchers monitoring state changes in real time, high-frequency trading systems, RPC providers serving trading applications, and DEX aggregators and routing engines that depend on the fastest possible market data. If your application is not competing on sub-second execution speed, the complexity of integrating ShredStream may not provide meaningful benefits. Additional Reading Solana trading infrastructure 2026: MEV, nodes, latency Solana node types: validator, RPC, and trader nodes How to improve Solana RPC latency with ShredStream Solana: estimate priority fees with getRecentPrioritizationFees #### Kiln: How to manage $13B+ in stakes with Chainstack Subgraphs ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. “Chainstack has been instrumental in helping us scale effortlessly while managing billions of requests across multiple protocols. Their robust subgraph solution has streamlined our operations and enabled us to confidently navigate the complexities of managing $13B+ in staked assets.” Kevin Lefevre, VP Engineering, Kiln At Chainstack, we’re passionate about pushing the boundaries of blockchain technology. We understand that managing digital assets and staking rewards effectively can be a complex task. That’s why when Kiln, the leading digital asset rewards management platform, approached us, we recognized an opportunity to create a robust, scalable solution that could navigate the intricacies of high-demand operations across multiple protocols. Let’s explore! What is Kiln? Kiln is a frontrunner in the field of digital asset rewards management. It offers businesses an innovative platform for earning rewards on their digital assets or integrating whitelabel earning functionalities into their products. Powering over $13B worth of programmatically staked crypto assets, Kiln’s prominent presence extends far and wide but most notably on the Ethereum network, running approximately 4.55% of it with zero slashing events. Figure 1: Some of the 40+ supported protocols on Kiln; Source: Kiln Kiln’s capabilities aren’t confined to managing stakes. They also cater to a wide range of industry leaders, such as custodians, ETP issuers, exchanges, and wallets, providing them with lucrative opportunities for unlocking new monetization strategies, integrating staking into their crypto ETPs, and enhancing their investment products’ value propositions. Figure 2: How integrating Kiln DeFi works; Source: Kiln By offering an all-in-one, API-first platform, Kiln simplifies earning processes and reduces barriers to entry in the crypto world. The services range from a comprehensive dashboard for tracking earn programs, enterprise-grade Validators-as-a-Service on all Proof-of-Stake chains, to a unified API for integrating and reporting on earn programs. Figure 3: Kiln’s product architecture; Source: Kiln Kiln’s commitment to security further cements its position as a trusted partner for any organization venturing into the world of digital asset reward management. This can be seen in the meticulous collection the dedicated team maintains and updates regularly. In doing so, they provide a clear overview of compliance and controls, as well as valuable resources like audits, pentests, and others. Figure 4: Kiln’s Trust Center dashboard; Source: Kiln How Kiln Started with Chainstack Kiln required a high-performance infrastructure that could scale with their growth, providing multi-protocol support for chains like Arbitrum, BNB Smart Chain, Ethereum, Optimism, Base, Polygon, and Solana. Moreover, a robust blockchain data solution was vital for their operations. Chainstack provided the solution Kiln needed. By automatically routing traffic to the nearest most performant node, our Global Nodes created a persistent fall-back chain for Kiln, alleviating Kiln’s challenges of managing in-house RPCs.  At the same time Chainstack Subgraphs provided seamless access to blockchain data at a fraction of the time and effort the team had previously needed. In turn, this enabled them to reduce operational overhead and fully focus on doing what they do best – creating exceptional staking experiences for their userbase worldwide. Figure 5: Why Web3 pioneers like Kiln choose Chainstack Subgraphs; Source: Chainstack Today, Kiln uses Chainstack to effortlessly handle billions of requests across multiple protocols and subgraphs. Our partnership has unlocked new opportunities for the team, allowing them to lead with confidence and redefine the staking landscape. Kiln on Chainstack in numbers When speaking about billions of requests, by far the spotlight goes to our Subgraphs, with Kiln leveraging over 25 of these. They have processed an astounding 5.16B+ requests. Of these, 2.87B+ were on the BNB Smart Chain mainnet, while 2.02B+ on the Arbitrum mainnet, as biggest contributors. Figure 6: Protocols Kiln builds on with Chainstack Subgraphs; Source: Chainstack Moreover, Kiln currently leverages a staggering 97 active Global Nodes, across 8+ protocols. These nodes have shouldered a notable 670.11M requests, demonstrating the robust performance and reliable service of our award-winning architecture standard. Figure 7: Protocols Kiln builds on with Chainstack Global Nodes; Source: Chainstack These figures not only reflect the scale of operations but also the trust that Kiln has placed in our services. Every node, every request, and every subgraph underscores the seamless integration, scalability, and performance that Chainstack has delivered. And this couldn’t make us prouder! “At Chainstack, we’re passionate about empowering industry leaders like Kiln to push boundaries. Their use of Chainstack Subgraphs and Global Nodes showcases how having the right Web3 infrastructure can drive operational efficiency and innovation in the staking landscape.” Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together Throughout our journey with Kiln, our focus was on empowering the team to harness the full potential of their digital asset reward management platform. With Chainstack Subgraphs and the globally-distributed and geo-load-balanced nodes we provided, we aimed to remove operational burdens and pave the way for Kiln’s smooth foray into various blockchain protocols. Indeed, our partnership has helped Kiln successfully manage high-demand operations, handle billions of requests across multiple protocols, and do all these with significant reductions in operational overhead. It’s the type of collaboration we aim for at Chainstack: a partnership that not only solves present challenges but also carves a path for future growth and innovation. As we move forward together, we remain committed to supporting Kiln with enterprise-grade RPC and data infrastructure. For the Web3 developers and industry leaders who trust Kiln for their digital asset rewards, this partnership is a promise: a promise of stability, scalability, and relentless innovation. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Linear: How Chainstack Subgraphs catalyze DeFi “We’ve drastically reduced deployment times and service interruptions with Chainstack Subgraphs. Especially across BNB and Ethereum.”  The Linear Team ⚠️ Important notice This article refers to Chainstack Subgraphs, a service that is no longer available. As blockchain infrastructure pioneers, we always keep a pulse on innovators who are redefining decentralized finance. Linear, a groundbreaking platform offering seamless access to a range of synthetic assets and DeFi services, stands as a bright testimony to such trailblazers. As a strategic infrastructure partner, we have been fortunate to take part in Linear’s transformative journey, assisting in improving the team’s development processes while reducing downtime with our swift and reliable Chainstack Subgraphs. Let’s explore! Figure 1: Linear’s 2024/5 roadmap; Source: Linear What is Linear? Linear—a name renowned in the decentralized finance space—echoes a versatile platform where users can trade synthetic assets efficiently, seamlessly, and cost-effectively. But Linear isn’t just about trading; it also brings a powerful streak of innovation to the arena of decentralized financial services. Linear opens the door to a thriving ecosystem featuring applications like Builder, Exchange, Bridge, Liquidator, and a peer-to-peer Marketplace. With each application playing a unique role—from staking and building ℓUSD in Builder, trading a variety of synthetic assets in Exchange, to asset transference through its Bridge feature—Linear continually amplifies the ease, access, and applicability of DeFi products for its users. Figure 2: The peer-to-peer Linear Marketplace; Source: Linear Adding to this robust ecosystem, Linear is set to transform trading further with the introduction of its Perp DEX. This perpetual trading platform allows traders to hold leveraged positions without expiry, creating opportunities for strategic trading, risk management, and flexible responses to market movements. And by launching PerpDEX, Linear reinforces its commitment to providing cutting-edge tools that empower traders and help shape the future of decentralized finance. Figure 3: The Linear PerpDEX introduces perpetual trading; Source: Linear What characterizes Linear is its commitment to community-centered governance. In fact, the platform allows its community to propose changes and shape the future trajectory of the protocol. Each governance decision taken is designed with the long-term growth and sustainability of the protocol in mind. Backed by industry-recognized security protocols, high scores from audits, a recent integration with Chainlink’s CCIP, and an expansive community following across major social channels, Linear has cemented its position as a formidable player in the DeFi space. Moreover, its presence on major exchange platforms, including Binance, KuCoin, and Uniswap, further strengthens its footprint in the ever-evolving decentralized landscape. How Linear started with Chainstack For Linear, the journey with Chainstack began out of a strategic need to bolster their software development projects. Linear was wrestling with slow deployment and update times for subgraphs, which historically took from 7 to 14 days. It wasn’t just that. They also grappled with a lack of support for incremental updates, a limitation that resulted in significant delay times. Addressing these pain points, we brought our high-performance Chainstack Subgraphs to the table. Our reputation for superior uptime and the ability to accomplish faster, more efficient deployments had a profound impact, ultimately reducing update times to just 2 days for Linear. Figure 4: Chainstack Subgraphs deliver 99.99%+ uptime; Source: Chainstack status Soon enough, the team acknowledged Chainstack Subgraphs as the optimal choice due to its ease of use, outstanding performance, and the ability to handle timely updates. This recognition marked the beginning of our partnership, leading to successful expansion across several blockchain networks and the optimization of the Linear platform all across the board. Linear on Chainstack in numbers Since the start of our collaboration, we’ve seen Linear make impressive use of Chainstack’s Subgraphs, achieving operational excellence across a variety of use cases. With 25+ active Subgraphs running across BNB Smart Chain, Ethereum, and test networks, Linear has leveraged our platform to support its DeFi services. These Subgraphs collectively process an astounding amount of data, with the highest RUs recorded at 756M for the Linear Liquidator and 356M for its oracle subgraph. Both are critical to ensuring low-latency and high-reliability operations for the platform. Linear also diversified operations across multiple networks, highlighting our exceptional support for Ethereum and BNB Smart Chain. Figure 4: Chainstack Subgraphs supported protocols; Source: Chainstack Finally, the ability to monitor, manage, and optimize these subgraphs ensures that Linear continues to deliver exceptional DeFi services, reinforcing their position as a leader in the blockchain space. These are a testament to the key role Chainstack plays in empowering Linear’s growth and success. “At Chainstack, we thrive on helping pioneers like Linear achieve their vision. Seeing our Subgraphs drive their efficiency and scalability is the ultimate validation of our mission.”  Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together Our partnership with Linear underscores Chainstack’s commitment to bolstering DeFi application development, facilitating seamless trading of synthetic assets, and propelling the future of blockchain technology. Pipeline challenges, such as slow subgraph updates and stretched deployment times, were transformed into dynamic solutions as the core of our collaboration. High uptime, faster subgraph updates, efficient real-time management—were key to bringing in a paradigm shift in Linear’s operational efficiency. Our interaction with Linear goes beyond, painting an enthusiastic picture of collective growth within an evolving DeFi landscape. In an era where digital currency and blockchain technology are influencing traditional finance constructs, Linear is driving a significant shift. As they continue to prosper, fostering a vibrant, participative community around their offerings, we at Chainstack feel immense pride to be a part of their journey. We are eager to continue nurturing this relationship, fueling further advancement and scaling new heights in the DeFi ecosystem. Figure 5: Chainstack Subgraphs demo; Source: Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### LinkPool on Chainstack: Facilitating Entry Into the Chainlink Oracle Network What is LinkPool? LinkPool is a third-party Chainlink focused company, ecosystem developer, and node operator that is engaged in developing the tools and the infrastructure for node operators on the network. Additionally, LinkPool aims to break down the barriers of participation to the Chainlink Network through its staking and infrastructure services, and to increase transparency in the network through the Chainlink Market analytics platform. The company was founded shortly after the Chainlink token offering in 2017 and was one of the first independent node operators that went live on Chainlink mainnet in June 2019. What does LinkPool do? Since its founding, LinkPool has set out to achieve the following: Be at the forefront of all Chainlink services being offered on every network with the highest up-time Increase transparency in the Chainlink Network Reduce the barrier of entry to meaningfully participate in the Chainlink Network for all tiers of users: Retail users Enterprise users (Data providers, institutions, enterprises, funds, firms, etc.) Power users (users who wish to operate a node, develop external adaptors, build their own dApps) For retail users, LinkPool has developed a set of pooled staking contracts. When staking goes live in the Chainlink Network, retail holders will have the ability to explicitly stake their LINK in a trustless manner onto a node, and payouts will be made proportionally to the total amount of staked LINK each user has put up for collateral in the node based on the specifics of the underlying service agreement. This enables participation by retail LINK holders and contributes to further securing the Chainlink Network. LinkPool also helps onboard enterprises into web3 by integrating Chainlink into their existing processes, creating custom integrations for new types of data, and by providing infrastructure consultation. Apart from that, LinkPool has also played an integral role in developing relevant documentation, resources, and tools for dApp developers and node operators. Part of this initiative was the creation of the first of its kind data feed directory – the Chainlink Market. This in effect created a crucial bridge between developers and operators that allowed them to connect to data sources with ease in leveraging the powerful features behind the Chainlink Network. LinkPool was initially part of the group of three nodes behind the launch of Chainlink’s mainnet. It has since evolved its business model entirely and scaled up the Chainlink Market into the analytics powerhouse that it is today. This development journey led LinkPool’s growth from a supporting revenue generator to a fully-fledged Node-as-a-Service (NaaS) platform that manages node operations for both small players and enterprise customers within the Chainlink network. How did LinkPool come across Chainstack? Before digging down into the details of how LinkPool discovered Chainstack, it is essential to have a better understanding of just how Chainlink works. In order to participate in the network and parse data as a node, a constant and stable full node connection is necessary. Taking into account that the majority of DeFi’s TVL hangs in the balance of accurate price fees, this means that downtime cannot be tolerated. That’s why in order to power their infrastructure, LinkPool needed a robust full node provider that could serve as a backup to fill any void at a moment’s notice in the event there was ever a disruption within LinkPool’s internal full node network. On top of that, the provider needed to offer a flexible payment plan that could meet LinkPool’s demanding usage requirements at an optimal cost without major impacts on profitability. It was not only performance and cost that the LinkPool team was looking for, though. Because of their active engagement in the development of Chainlink’s infrastructure, their development team sought a responsive provider whose founders would be interested in going the extra mile, as well as working together with LinkPool in expanding and improving the products and services they needed. After a thorough search and evaluation of possible options, LinkPool discovered Chainstack as the provider that offered the best experience. How does Chainstack’s offer match LinkPool needs? LinkPool uses a range of third-party full node providers for backup proxy purposes that are regularly evaluated and regulated. Despite the constant scrutiny, however, Chainstack has maintained a prime position in LinkPool’s ranking list, never moving an inch from the top, serving as their go-to option for RPC node provision. Chainstack has scored highly not only in terms of performance, but affordability just as much in the eyes of the LinkPool development team. Being able to connect to multiple nodes across protocols without additional charges to Chainstack’s total usage cap was a welcome sight among them. On top of that, the generous calls quota to archive nodes that LinkPool tends to use frequently made Chainstack stand out from competing providers, and became a perfect fit for the platform’s needs. Overall, thanks to the support of a diverse set of chain protocols that LinkPool needed, paired with exceptional performance, customer service, and pricing, Chainstack became a match made in heaven for their team. It was due to these outputs that kept Chainstack at the top of LinkPool’s provider rankings. Outcome After integrating the platform’s services with Chainstack’s robust full node infrastructure, LinkPool saw unparalleled up time, even under stressful network conditions. In doing so, LinkPool experienced the required stability needed for effective operation of the platform. Considering just how much is at stake in securing the majority of DeFi’s TVL, this reliability alleviated a major stress factor. Chainstack’s team was happy to engage with LinkPool’s development team directly in identifying the most adequate solutions in responding to the platform’s exponential growth and growing set of requirements that came with it. Essentially, our responsiveness and availability evolved with their demands, allowing their team to focus on what they did best – creating an exceptional environment for participating in the Chainlink Network. After a smooth integration process, LinkPool could rest easy knowing that a stable and responsible full node infrastructure partner was there to meet them in a time of need. Through this forged relationship, LinkPool is best positioned to contribute to the stability of the network which will facilitate the continued growth of a decentralized world rooted in cryptographic truth built on Web3 applications. What does LinkPool like about Chainstack? After extensive and ongoing evaluation, we’ve found Chainstack’s services are the most reliable, cost-effective, and have the support necessary to use as our primary backstop when operating Chainlink nodes. Ian Read, Director of Operations, LinkPool What does Chainstack like about LinkPool? The oracle problem is one of the most critical questions in Web3 development and its successful resolution is not only a matter of protocol but supporting infrastructure just as well. That is why it is such a pleasure to work with initiatives like LinkPool which have taken the enormous responsibility of facilitating the development and successful operation of the oracle protocol, integral to the DeFi boom. Eugene Aseev, Founder & CTO, Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Lootex on Chainstack: Powering a transparent trading environment for digital asset creators Lootex is a blockchain-based platform that allows digital asset creators to protect and trade their works. By providing a secure and transparent trading environment, Lootex enables creators to realize the full value of their digital assets. What does Lootex do? Lootex provides a number of benefits to digital creators. First, it allows creators to protect their works from unauthorized use or theft. Second, it provides a transparent and secure platform for trading such digital assets. This allows creators to get the best possible market environment for their works, and to ensure that they are fairly compensated for their creations. By unlocking the full value of digital creation, Lootex helps empower creators in enriching the user experience. Ever since its launch, Lootex has managed to accumulate a significant user base of more than 80,000 MAU with 400+ gaming and collection stores listed on the platform. Ultimately this has successfully generated over $2,000,000 in monthly trading volume. How did Lootex come across Chainstack? When Lootex first began their search, they needed a stable RPC node provider that could also support their main focus on the Binance Smart Chain (BSC) above anything else. Considering their use case and the fact that Web3 traffic can oftentimes spike significantly, this was no easy task. The Lootex team scoured the web to find a robust infrastructure partner, as a potential solution to resolve their BSC stability woes. They compared all the alternatives, including public RPC but none of them could satisfy their needs for utmost node performance. That is when their search led them to discover Chainstack. Looking at the metrics under the hood, the Lootex team quickly realized that Chainstack stood well above the rest in terms of stability, especially for the BSC network, ultimately becoming their choice for infrastructure provider. How does Chainstack’s offer match Lootex needs? Considering their demanding use case, finding a robust infrastructure provider for the BSC network was a top priority for the Lootex team. Minting NFTs and hosting launchpad events can generate a significant amount of traffic in a moment’s notice, which calls for a stable delivery and nothing less. Without such a partner to support their efforts, Lootex would have seen preventable interruptions to their services, ultimately leading to poor user experience and reputational damage. Thankfully, the Lootex team could rely on the effective delivery of RPC requests with Chainstack, thus averting the potential crisis brewing on the horizon. In doing so, Lootex found an adequate partner to adhere to their needs for exceptional stability on BSC. Not only that but thanks to Chainstack’s flexible pricing structure, they could resolve their performance requirements with a solution that is also fit for their budget. Outcome Working together with Chainstack, meant that Lootex could now leave the performance and stability woes of the past right where they belong – in the past. This, in turn, allowed them to free much-needed resources and put them to work in providing a smooth experience for their users, regardless of the load their services are experiencing. Additionally, with the help of Chainstack’s robust RPC infrastructure and detailed reporting, the Lootex team was able to easily provide granular information about transaction delivery and other vital performance metrics to the end-user. Because of this, Lootex could further foster a trustworthy trading environment that is built on transparency. What does Lootex like about Chainstack? “Chainstack provided us with the robust RPC infrastructure we needed to power our services on BSC. Because of this, our team successfully managed to achieve the goal of network stability, which allowed for smooth trading and browsing experience for our users.” David Tseng, COO, Lootex What does Chainstack like about Lootex? “Fostering a creator-friendly environment for virtual assets represents an important step in driving mainstream blockchain adoption. That is why we are excited to work with projects, such as Lootex, which dedicate their efforts to building effective solutions in this avenue.” Eugene Aseev, Founder & CTO, Chainstack What is the most interesting engineering challenge in working together? Considering the demanding case of Lootex, their development team was happy to see a smooth onboarding process that was free of any major bottlenecks. With Chainstack’s help, they successfully managed to deploy the robust infrastructure they needed to power their services on BSC. Following the implementation of Chainstack’s solution, Lootex no longer had to deal with the fallout of dropped requests and synchronization issues. In turn, pairing this with the ability to deliver granular insights about platform usage created a seamless user experience on the platform for both creators and collectors alike. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Lottery smart contract on Cronos blockchain Introduction Cronos is an EVM-compatible blockchain that uses Proof-Of-Authority (POA) to deliver a faster and cheaper finality to its users. As an open-source Layer 1 blockchain, Cronos aims to combine its EVM-compatible infrastructure with other blockchains built on top of the Cronos SDK to enable fast and cheap transfers of assets. In this tutorial, we will learn how to build a lottery smart contract using Solidity, and how to deploy and verify smart contracts on the Cronos blockchain using Hardhat. Setting up a Hardhat project Before writing our smart contract, we need to set up our dev environment. To create a Hardhat project: Create a folder named cronosHardhat (or any other name you like). Open the new folder in the terminal and run the command:npm install --save-dev hardhatThis command downloads the latest version of Hardhat into your directory. To create a sample Hardhat project, run npx hardhat. This will open up a UI interface in your terminal. Select ‘Create a JavaScript project’, and press enter through all the options. This will create a sample Hardhat project in your terminal, and Hardhat will automatically download all the additional dependencies for this sample project using ‘hardhat-toolbox’. Taking a look at Hardhat’s project structure You should now have a basic Hardhat project set up in your directory. Let us take a brief look at some folders and files within the project layout: Contracts: this folder contains all of your smart contracts. Scripts: this folder contains JavaScript files that are used to deploy already compiled smart contracts onto the blockchain. You will typically have to write at least a basic deployment script to deploy your smart contracts. Test: you should ideally test your smart contracts before deploying them to the blockchain. The test folder is where you write those tests. Hardhat uses Mocha and Chai, two very powerful JavaScript libraries to enable testing within its framework. hardhat.config: as the name suggests, this file contains all of the configuration parameters to deploy your smart contracts. Hardhat supports gas optimization, defining multiple networks amongst many other features which can be tweaked via the hardhat.config file. Writing a smart contract in Hardhat Inside the contracts folder, create a new file named Lottery.sol.Inside the file, paste the following code: //SPDX-License-Identifier: MIT pragma solidity ^0.8.17; contract Lottery { address public owner; address payable[] public players; bool public lotteryInProgress; uint public lotteryId; mapping (uint => address payable) public lotteryHistory; constructor() { owner = msg.sender; lotteryId = 1; } function startLottery() public onlyowner{ lotteryInProgress=true; } function alreadyEntered() private view returns(bool){ for(uint i=0; i< players.length; i++){ if(players[i]==msg.sender) return true; } return false; } function enterLottery() public payable { require(lotteryInProgress,"No lottery event is currently in progress"); require(msg.value > 0.5 ether, "Please deposit at least 0.5 Ether"); require(msg.sender!=owner, "As owner, you can't enter the lottery"); require(alreadyEntered()==false, "You have already entered in the Lottery"); require(players.length<=10, "This lottery has maximum participation. Please wait for the next event"); players.push(payable(msg.sender)); } function getRandomNumber() private view returns (uint) { return uint(keccak256(abi.encodePacked( block.timestamp, block.difficulty, block.gaslimit))); } function pickWinner() public onlyowner { require(lotteryInProgress,"No lottery event is currently in progress"); require(players.length>0, "can't pick winners without participants"); uint index = getRandomNumber()%players.length; players[index].transfer(address(this).balance - 0.1 ether); lotteryHistory[lotteryId] = players[index]; lotteryId++; lotteryInProgress=false; players = new address payable[](0); } modifier onlyowner() { require(msg.sender == owner, "Only owner can call this function"); _; } function getWinnerByLottery(uint lottery) public view returns (address payable) { return lotteryHistory[lottery]; } function getBalance() public view returns (uint) { return address(this).balance/(10**18); } function numOfPlayers() public view returns (uint) { return players.length; } function getPlayers() public view returns (address payable[] memory) { return players; } } Let us go over the code quickly: The constructor does two things. First, it sets our wallet address as the ‘owner’ of the address. Since the constructor is called only once in the life cycle of a contract, this value cannot change. Secondly, it sets the lottery ID as 1, which we will increment every time we end a lottery contest. The startLottery() function simply initiates a bool variable. This variable is basically a flag that tells us if a lottery event is currently in progress or not. The enterLottery() function allows new players to enter the contest if their contribution to the lottery pool is greater than 0.5 Ether.It also uses the alreadyEntered() function to check if someone is trying to participate again. If all the other conditions are also satisfied, the participant is added to the list of players eligible to win the lottery. The function getRandomNumber() is our main driver. A lottery should randomly decide a winner. However, solidity does not have a native randomizer function. Moreover, Chainlink VRF, a popular decentralized random-number-generating service, does not yet support Cronos. Hence, our best option is to hash together some varying properties of the blockchain network to generate a pseudo-random number. We use the following global variables as part of our hashing algorithm: block.timestamp block.difficulty block.gaslimit All of these global variables vary in value as per the existing conditions on the blockchain while we are deploying/calling our contract. This makes our number quite random, but not totally so. The hash generated will be pseudo-random, but will work for most cases. pickWinner() is a function that can only be called by the owner of the contract. It uses the getRandomNumber() to select a random index. The address at that index gets transferred all of the Ether in the lottery at that point, minus a 0.1 Ether fee that we keep as a service charge. The last few functions are some simple view functions that we use to keep track of the current parameters of our contract. After pasting in the code, save the file and go to your terminal. Inside there, run the command: npx hardhat compile This will compile all the smart contracts in your contracts folder and generate ABIs for them in the artifacts folder. We now have a smart contract ready to deploy. Setting up our env variables To deploy our smart contracts, we basically need two things: A private key to an EVM-based wallet that has a sufficient number of TCRO tokens, the native cryptocurrency of the Cronos Testnet. If you don’t have TCRO tokens, you can get some from the official faucet. We also need an RPC URL to connect to a blockchain. You can use a public RPC URL;OR you could sign up to Chainstack and use a dedicated URL that will give you a faster and more reliable service. If you don’t know how to set up an endpoint with Chainstack, you can check out this tutorial on our blog. Tutorial on how to set up a public chain node with Chainstack In addition, we will be verifying our smart contract after deploying it on the Cronos testnet. We can do so directly from the command line by using the hardhat-cronoscan plugin. To use the plugin, we need to get an API key from Cronoscan. Login to Cronoscan and get an API key. While it’s possible to directly put your keys into your hardhat.config file, we do not recommend doing this since you could end up pushing this data to online repositories, which can lead to your private keys being compromised. We will use the dotenv package to export our keys securely. To install the dotenv package in your directory, open your terminal, and run: npm i dotenv: To install the dotenv package into your directory. touch .env: To create a new .env file in your directory. Go to your newly created dotenv file and put in your private keys. This is what your dotenv file should look like right now: RPC_URL=https://nd-XXXXXXXXX PRIVATE_KEY=0x2fqXXXXXXXXXXXXXXXXXXXXXu7 API_KEY=XW10AXXXXXXXXXXXXXXXXXG5 Save the dotenv file and run this command in your terminal: source .env This command will load your sensitive data onto your command line. You can run echo $RPC_URL in your terminal to verify if the data is accessible by Hardhat. Configuring hardhat.config As explained before, this file contains all of your configuration for your hardhat project. Go to hardhat.config in your root directory, and paste this code after deleting its contents: require("@nomicfoundation/hardhat-toolbox"); require('dotenv').config(); require("@nomiclabs/hardhat-etherscan"); require("@cronos-labs/hardhat-cronoscan"); module.exports = { solidity: "0.8.17", defaultNetwork: "Cronos_testnet", networks: { Cronos_testnet: { url: `${process.env.RPC_URL}`, accounts: [process.env.PRIVATE_KEY] }, }, etherscan: { apiKey: { cronosTestnet: `${process.env.API_KEY}`, }, }, }; A few things happen here:• hardhat-toolbox is a recent addition to Hardhat that bundles together a variety of commonly used Hardhat packages and plugins into one import.• The hardhat-cronoscan plugin is used in conjunction with the hardhat-etherscan plugin in order to verify contracts deployed on Cronos mainnet or testnet.• We can define multiple blockchain connections inside the networks object. We can also define a default network that Hardhat will fall back to in case we don’t specify a particular network in the command line. This helps in case we have multiple networks defined within the config file, but mostly only use a particular network.• We define the Cronoscan API key inside the etherscan object.hardhat.config supports a lot more configuration parameters, but this is all we need for now. You might notice, however, that we haven’t installed the hardhat-cronoscan plugin yet. To install the plugin, go to the terminal in your root directory, and run: npm i --save-dev @nomiclabs/hardhat-etherscan@^3.1.0 @cronos-labs/hardhat-cronoscan Now save your config file, and run the npx hardhat compile command in your terminal once again. This will make sure that all your contracts are compiled according to the latest configurations of our Hardhat project. Testing in Hardhat Smart contracts are meant to handle money. Thus it is highly recommended that one tests their smart contracts before deploying them to a live blockchain network. For testing, we will connect to the Hardhat network, which is basically a mock blockchain created on your system by Hardhat, and we will test our smart contract using Mocha and Chai libraries through an automated testing script. To begin, open a new terminal in the same directory, and run the command:npx hardhat nodeThis will give us a simulated blockchain in our command line with a list of accounts filled with a bunch of fake ETH. How convenient! We need to install one final plugin to that allows us to leverage the full power of the Chai library. Open your original terminal, and run: npm install --save-dev @nomicfoundation/hardhat-chai-matchers This will add some Ethereum specific capabilites to the Chai library. We will look into this in more detail below. Finally, open hardhat-config.js and add this line to the top of the file: require("@nomicfoundation/hardhat-chai-matchers"); We are now ready to test our Solidity code. Open the test folder, and delete any files present inside. Create a new file by the name of Lottery.js and add the following code inside: const { expect } = require("chai"); const hre = require("hardhat"); describe("Lottery", function () { let owner, player1, player2, lottery; before(async () => { [owner, player1, player2] = await ethers.getSigners(); provider = await ethers.getDefaultProvider(); const Lottery = await hre.ethers.getContractFactory("Lottery"); console.log("Deploying Contract for testing.......") lottery = await Lottery.deploy(); await lottery.deployed(); }); it("Should set owner correctly", async function () { const ownerAddress = await lottery.owner(); console.log("owner from contract is : ", ownerAddress); expect(await ownerAddress).to.equal(owner.address); }); it("Non-owner shouldn't be able to start lottery", async function () { await expect(lottery.connect(player1).startLottery()).to.be.revertedWith("Only owner can call this function"); }); it("Should start lottery event", async function () { let lotteryInProgress = await lottery.lotteryInProgress(); console.log("Current value of lotteryInProgress is : ", lotteryInProgress); await lottery.startLottery(); console.log("New value of lotteryInProgress is : ", await lottery.lotteryInProgress()); expect(await lottery.lotteryInProgress()).to.equal(true); }); it("Player 1 should be 1st participant", async function () { await lottery.connect(player1).enterLottery({ value: ethers.utils.parseEther("2.0") }); let participant1 = await lottery.players(0); player1Balance = await ethers.provider.getBalance(player1.address); console.log("Remaining ETH with player1: ", player1Balance / (10 ** 18)); expect(participant1).to.equal(player1.address); }); it("Player 2 should be 2nd participant", async function () { await lottery.connect(player2).enterLottery({ value: ethers.utils.parseEther("3.0") }); let participant2 = await lottery.players(1); player2Balance = await ethers.provider.getBalance(player2.address); console.log("Remaining ETH with player2: ", player2Balance / (10 ** 18)); expect(participant2).to.equal(player2.address); }); it("pickWinner() function should not be called by non-owner", async function () { await expect(lottery.connect(player1).pickWinner()).to.be.revertedWith("Only owner can call this function"); }); it("pickWinner() function should work correctly", async function () { lottery.pickWinner(); LotteryId = lottery.lotteryId(); let Winner = await lottery.lotteryHistory(LotteryId); let WinnerBalance = await ethers.provider.getBalance(Winner); console.log("Winner is: ", Winner); console.log("Winner address is:", WinnerBalance / (10 ** 18)); expect(await Winner).to.satisfy(function (anyWinner) { if ((anyWinner == player1.address) || (anyWinner == player2.address)) { return true; } else { return false; } }); }); }); This is a lot. Let us go over this code and what it does carefully: The describe() function comes to us via the mocha library. The describe function is basically used to group multiple tests together.It typically contains multiple it() tests, which is also the case here. The before() function is also provided by the mocha library. This function is executed once before the first test in any mocha script. Using this function, we deploy our smart contract to the blockchain, and use the lottery object from the function in the rest of the code. it() functions are singular unit tests with a description to express their indiviual use. we have multiple it() tests in our code. At the end of each it() test, we typically ‘assert’ something. An assertion is basically where you check whether or not your actual results match with your expected outcomes. The Chai library offers us many different kinds of assertions. You can read more about them from their official docs. You must have noticed that our smart contract uses a modifier named onlyOwner(). The role of a modifier is to revert a function with a custom error whenever a require condition fails. The chai-matchers plugin allows us to test these specific reverts, which wouldn’t be possible with only the default Chai library. Our last it() function uses the .to.satisfy assertion to invoke a custom matcher function that ensures that the lottery winner is choosen only from amongst the two participants. Testing a smart contract is a thorough affair that must be conducted carefully. Feel free to tweak this code to add or remove tests as you see fit. The idea behind this section was to get you started with testing in Hardhat. Once you are ready, save the file. In your main terminal, run: npx hardhat test --network localhost This command will run your test scripts on the Hardhat network, provided you actually have the network running on your system. We did that when we ran the npx hardhat node command. This is what your terminal should look like now: Testing in Hardhat All our tests are passing, we are now ready to deploy our smart contract to a live network. Deploying our smart contract We now have our private keys ready to go and have tweaked the config file as per our requirements. We also just tested our smart contract that is now ready to go.This is good stuff already. However, to actually deploy a smart contract through Hardhat, we need to create a deployment script.Inside the scripts folder, go to deploy.js and delete everything inside it. Now paste the following code inside the same file: const hre = require("hardhat"); async function main() { const CronosLottery = await hre.ethers.getContractFactory("Lottery"); console.log("Deploying your contract, please Wait....."); const cronosLottery = await CronosLottery.deploy(); await cronosLottery.deployed(); console.log("CronosToken deployed to:", cronosLottery.address); } main() .then(() => process.exit(0)) .catch((error) => { console.error(error); process.exit(1); }); This is a simple deploy script. We access the deploy function through Hardhat’s runtime environment.To run the deploy script, open your terminal and run: npx hardhat run --network Cronos_testnet scripts/deploy.js We log the address of the contract we just deployed in our console. Go to Cronos testnet explorer and search for your contract address. You will notice that the contract code is not yet visible. That is because we haven’t verified our contract. Let us move on to that. Verifying our smart contract To verify our contract through Hardhat’s command line, we need to use Hardhat’s verify command. We will pass the address of the deployed contract along with the RPC URL of the blockchain network.If you recall, we have already defined a Cronos testnet inside our config file.Open your terminal, and run: npx hardhat verify --network Cronos_testnet {Contract Address} This might take a while, but Hardhat will return a link to your verified contract in the terminal if the verification is successful. Open the link and you should now be able to interact with the contract right from the Cronos testnet explorer itself. Conclusion In this article, we learned how to set up a Hardhat project and how to deploy and verify a smart contract on Cronos testnet. Please note that you can tweak the parameters inside Hardhat’s config file to deploy and verify the same contract on Cronos mainnet with a few minor changes. The Cronoscan API key works for both the mainnet and the testnet.If you are interested in exploring Cronos further, you can deploy your own Cronos node with Chainstack and work with that, or you may just head over to our blog for some more cool web3 tutorials.Happy coding! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Lynx: Reimagining forex and crypto trading with Chainstack Chainstack’s dependable RPC infrastructure has been vital for Lynx. Their low latency and strong uptime ensure our high-leverage trading platform runs smoothly and efficiently. The Lynx Team Lynx is changing the game in the decentralized perpetuals exchange space, and we at Chainstack couldn’t be more excited to share our mutual story. Offering high-leverage trading across crypto, forex, and commodities, Lynx embodies all that Web3 developers dream of—a platform that doesn’t just accommodate, but encourages, the use of any ERC-20 token as collateral. Pretty neat, right? As a major player in the blockchain infrastructure field, our journey with Lynx has granted us valuable insights into their engineering feats and the Web3 developer community as a whole. Join us as we explore how Lynx is revolutionizing the DeFi landscape and providing exciting opportunities for liquidity providers and traders with Chainstack, all while keeping the needs of Web3 developers at the heart of their operations. How Lynx started with Chainstack As a company dedicated to accelerating the adoption of blockchain within global enterprises, at Chainstack, we are always inspired to see how our services facilitate the innovative operations of businesses like Lynx. Lynx initially approached us as they were looking to upgrade their infrastructure. After conducting an extensive competitive analysis of on-chain options, particularly for the Fantom ecosystem, they were seeking a provider that offered consolidation, service improvement, and cost-effectiveness without compromising on performance. Lynx was specifically intrigued by how our offerings provide strong uptime, low latency, and competitive pricing. Being a trading platform of perpetual nature, it was crucial for Lynx to have dependable RPC with a low latency backend service. The premium plans of other providers were coming up as cost heavy, a pinch point we at Chainstack were poised to solve. Our standout features such as our competitive pricing, strong uptime, low latency, and robust support for a vast number of chains offered Lynx the possibility for future expansion. As the competitive analysis showed, we aligned well with Lynx’s needs. We felt confident that our robust and cost-effective services could deliver the level of reliability Lynx required to execute their real-time, always-on backend services. From providing a seamless trading experience to supporting bots that execute crucial financial operations, our engagement with Lynx serves as a testament to our commitment towards enabling efficient and reliable blockchain solutions for businesses. Lynx on Chainstack in numbers With Chainstack’s assistance, Lynx runs 4 active Global Nodes, focusing primarily on the Fantom protocol. Indeed, it’s a round-the-clock job, but the numbers clearly speak for the successful synergy between Chainstack and Lynx—a whopping 30M requests. The cherry on top? We handle all of Lynx’ requests via Chainstack Global Nodes—a testament to their exceptional performance. Now isn’t that something? Well, there’s more to come. Shall we proceed? Beyond handling the technical intricacies of Lynx’s operations, Chainstack was also responsible for managing any potential issues that could disrupt the ease of operations for Lynx. Our proactive and responsive support meant that issues were flagged and fixed before they could snowball into major problems, thus ensuring seamless operations. Considering the scale and complexity of the services required by Lynx, our reliable and consistent delivery has become a cornerstone of Lynx’s operations. This has not only helped Lynx expand its offerings but also become a reliable platform for its users who indulge in high-leverage trading—a niche with increasing popularity among seasoned traders and beginners alike. And, while Lynx continues to spearhead innovative market offerings, we, at Chainstack, are proud to fuel their journey with our robust managed blockchain services. What is Lynx? Emerging as a stalwart within the realm of blockchain trading platforms, Lynx is a decentralized perpetuals exchange renowned for its innovative approach to high-leverage trading. What sets Lynx apart is its unique proposition, enabling any ERC-20 token to serve as collateral, thereby supercharging the value extraction from your favorite tokens. Designed with Web3 developers in mind, Lynx paves the way for enhanced token utility without the necessity for token holders to relinquish their holdings. The implementation of omnichain liquidity pools further bolsters Lynx’s capabilities. This allows for ease of support extension to additional chains and immediate access to robust trading liquidity—a move that magnifies trading volumes and fee generation per liquidity dollar deposited. For traders, Lynx presents a suite of tools to facilitate efficient, low-cost trading activity. These include unique features like gasless trade execution and low liquidation penalties. Meanwhile, liquidity providers enjoy the benefits of single-asset liquidity provision, limited counterparty risks, and advanced price impact modeling to mitigate price manipulation efforts. Transformational in its nature, Lynx continually seeks to evolve and augment the benefits it delivers to its users. Keen on breaking traditional barriers and limitations, Lynx empowers token holders and creates an ecosystem ripe with opportunities for growth and expansion. Web3 developers and blockchain enthusiasts alike find in Lynx a platform geared towards the future of trading. Working with Lynx has demonstrated Chainstack’s ability to deliver essential infrastructure for innovative trading solutions. We are proud to contribute to their success in the decentralized finance space. Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together From our perspective as infrastructure providers committed to empowering blockchain innovations, partnering with Lynx has been an enriching journey. They came to us seeking a robust solution for their advanced decentralized perpetual exchange and we are proud to have fulfilled their expectations. Lynx’s groundbreaking approach to leverage trading has been transformative in the decentralized finance world. By enabling traders and liquidity providers to use any ERC-20 token as collateral, Lynx has revolutionized the crypto, forex, and commodities markets. Chainstack has been crucial in facilitating and maintaining Lynx’s backend services. We are honored to have facilitated Lynx’s growth by providing a stable, secure, and scalable environment that accommodates the needs of a high-leverage trading platform. Our collaboration underscores how the right infrastructure can propel a platform to its zenith. We are proud to be part of Lynx’s growth journey, facilitating a seamless experience for traders and liquidity providers alike, participating in the revolutionary world of high-leverage DeFi trading. We continue to work towards enabling and nurturing such innovations embedded with profound potential. Because at Chainstack, we don’t just build for the present; we empower the future. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Mastering DApp development on Chainstack: Techniques, tools, and best practices At Chainstack, we’re committed to simplifying the intricate world of blockchain deployment and management for developers. We’ve observed how strategies like HTTP batch requests and multicall contracts have been leveraged by Web3 developers to boost their DApp performance. This comprehensive guide is crafted with an aim to venture deeper into these promising techniques, their features, performance, and practical applications. In this guide, we’ll also shed light on the management of Ethereum logs via the eth_getLogs RPC method, discussing its limitations and offering best practices to enhance your DApp’s performance and reliability. Not only that, but we’ll also discuss how to monitor transaction propagation in Ethereum Virtual Machine (EVM) networks using Python, an essential aspect of maintaining the integrity and efficiency of the network. The journey doesn’t end there. For those of you looking to handle real-time data in your DApps, we’ll illustrate the use of WebSocket connections with JavaScript and Python. Lastly, we can’t miss out on the power of multithreading in Python for Web3 requests—a proven methodology that can significantly boost your DApp performance, making it both robust and responsive. This guide is catered to both experienced Web3 developers and those just starting their journey in the world of DApps. We’re confident that it will offer valuable insights that can make Web3 development smoother and more efficient for you. Let’s get started! What are HTTP batch requests? As a Web3 developer, you may often find yourself in circumstances requiring several requests to an Ethereum client. Here’s where HTTP batch requests come in handy. An HTTP batch request enables packing multiple HTTP requests into a single one that gets delivered to the server. This can be particularly beneficial when reducing the load on the server and enhancing the performance of your operations. For instance, if you’re using Ethereum clients that support batch requests, such as Geth, you can leverage this feature for efficient data fetching. These packed requests get handled by the server in one single round trip, which can drastically enhance DApp responsiveness. How to implement HTTP batch requests? To implement an HTTP batch request, send a request with a payload containing multiple request objects in an array as shown below: [ {"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}, {"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":2}, {"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":3}, {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":4} ] The server will send back the results in one response, arranged in the same order as the requests were received. For example: [ { "jsonrpc": "2.0", "id": 1, "result": "Geth/v1.10.26-stable-e5eb32ac/linux-amd64/go1.18.8" }, { "jsonrpc": "2.0", "id": 2, "result": "0x10058f8" }, { "jsonrpc": "2.0", "id": 3, "result": false }, { "jsonrpc": "2.0", "id": 4, "result": "0x1" } ] To run it using curl: curl 'YOUR_CHAINSTACK_ENDPOINT' \\ --header 'Content-Type: application/json' \\ --data '[ {"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}, {"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":2}, {"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":3}, {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":4} ]' Popular Web3 libraries like web3.js and ethers.js support this feature as well. Below is an example of getting ether balances from multiple accounts at once using web3.js. const { Web3 } = require("web3"); const NODE_URL = "YOUR_CHAINSTACK_ENDPOINT"; const web3 = new Web3(NODE_URL); const addresses = [ "0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326", "0x2bB42C655DdDe64EE508a0Bf29f9D1c6150Bee5F", ]; async function getBalances() { const startTime = Date.now(); // Create a batch request object const batch = new web3.BatchRequest(); // Array to hold promises for each request const promises = []; // Loop through each address and add a getBalance request to the batch addresses.forEach((address, index) => { const request = { jsonrpc: "2.0", id: index + 1, method: "eth_getBalance", params: [address, "latest"], }; // Add request to the batch and store the promise const requestPromise = batch.add(request); promises.push(requestPromise); }); // Send the batch request and wait for all responses const responses = await batch.execute(); // Process responses responses.forEach((response, index) => { if (response.error) { console.error(response.error); } else { const balance = response.result; const timeFromStart = Date.now() - startTime; console.log( `${addresses[index]} has a balance of ${Number( web3.utils.fromWei(balance, "ether") ).toFixed(3)} ETH retrieved in: ${timeFromStart / 1000} seconds.` ); } }); } getBalances(); The getBalances function creates a new BatchRequest object using web3.BatchRequest(). The function then loops through each address in the addresses array and creates a new request to get the balance of that address using web3.eth.getBalance.request(). It adds each request to the batch using batch.add(). Finally, the function executes the batch request using batch.execute(). When executed, the requests in the batch are sent to the Ethereum network simultaneously, and the callback functions are executed when the responses are received. What are multicall contracts? Comparatively, a multicall contract also takes on multiple function call objects but executes them together. As a Web3 developer, you can use the multicall contract as a proxy to evoke other contracts on Ethereum. It’s essentially a straightforward implementation that uses Solidity’s call function to broadcast contract calls. The implementation of a multicall contract is straightforward: it uses Solidity’s call function to execute contract calls. This is an example implementation of the multicall’s aggregate function: function aggregate(Call[] memory calls) public returns (uint256 blockNumber, bytes[] memory returnData) { blockNumber = block.number; returnData = new bytes[](calls.length); for(uint256 i = 0; i < calls.length; i++) { (bool success, bytes memory ret) = calls[i].target.call(calls[i].callData); require(success); returnData[i] = ret; } } In summary, this function takes an array of calls, executes each one, and returns an array of the results along with the block number in which the function was called. It is designed to be used as a general-purpose aggregator for calling other contracts on the Ethereum blockchain. How to implement multicall contracts? Anyone can deploy their own multicall contract. In this example, we use MakerDAO’s multicall contract on the Ethereum mainnet, deployed at 0xeefBa1e63905eF1D7ACbA5a8513c70307C1cE441. Below is an example of calling the smart contract using MakerDAO’s helper library multicall.js, which performs the same function as the previous example: const multicall = require("@makerdao/multicall") const config = { rpcUrl: "YOUR_CHAINSTACK_ENDPOINT", multicallAddress: "0xeefba1e63905ef1d7acba5a8513c70307c1ce441" }; const addressArr = [ "0x2B6ee955a98cE90114BeaF8762819d94C107aCc7", "0x2bB42C655DdDe64EE508a0Bf29f9D1c6150Bee5F" ]; async function main() { const startTime = Date.now(); console.log("Started..."); const calls = []; // Retrieve the Ether balance of each Ethereum address in addressArr using the multicall library. for (let i = 0; i < addressArr.length; i++) { const callObj = { call: [ 'getEthBalance(address)(uint256)', addressArr[i] ], returns: [ [`ETH_BALANCE ${addressArr[i]}`, val => val / 10 ** 18] ] }; calls.push(callObj); } const result = await multicall.aggregate(calls, config); console.log(result); const timeFromStart = Date.now() - startTime; console.log(`Result received in ${timeFromStart / 1000} seconds`); } main(); The main function iterates through each address in the addressArr array and creates a call object for each address. These call objects use the multicall library to retrieve the ether balance for each address. Once all of the call objects have been created and added to the calls array, the multicall library’s aggregate function is called with the array of call objects and the configuration object. This function aggregates the results of all of the calls into a single object, which is stored in the result variable. Finally, the code logs the result to the console and calculates the time it took to receive the result, which is also logged to the console. You will need to install the multicall.js library to run this code. HTTP batch request vs multicall contract performance comparison Considering performance, both batch requests and multicall contracts can substantially speed up your DApp. Our tests, based on common use cases such as getting account balance and calling a smart contract, reveal performance improvements with both methods. In this section, we compare the performance of three different approaches: Sending multiple HTTP requests in parallel Sending a batch HTTP request Using a multicall contract We will test these methods based on two common use cases: Getting account balance Calling a smart contract Getting account balance for 30 distinct addresses The testing script for batch requests and multicall contracts is included in the previous sections. Below is the code for sending multiple HTTP requests in parallel: const { Web3 } = require('web3'); const web3 = new Web3('YOUR_CHAINSTACK_ENDPOINT'); var addressArr = [ "0x2B6ee955a98cE90114BeaF8762819d94C107aCc7", "0x2bB42C655DdDe64EE508a0Bf29f9D1c6150Bee5F" ]; async function main() { var startTime = Date.now(); console.log("started"); for (i = 0; i < addressArr.length; i++) { web3.eth.getBalance(addressArr[i]).then(function(result) { var timeFromStart = Date.now() - startTime; console.log("Result received in:" + timeFromStart / 1000 + " seconds"); }); } } main(); Parallel single requestsBatch requestMulticallRound 11.7891.49Round 21.8961.159Round 32.3371.113Round 42.9421.224Round 51.6381.602Table 1: Getting account balance for 30 distinct addresses performance comparison The test was conducted between a server in Europe and a client in Singapore. A total of 15 measurements were averaged, showing that batch requests outperform multicall and normal requests. Compared with sending single requests in parallel, batch requests reduce the total request time by 38%, and multicall reduces it by 18%. Getting the owners of BAYC tokens Below are the testing scripts using web3.js for making smart contract calls. The tests are based on an ERC-721 standard method ownerOf from BAYC’s smart contract. Sending multiple HTTP requests in parallel: const { Web3 } = require('web3'); const web3 = new Web3('YOUR_CHAINSTACK_ENDPOINT'); const abi = [{ "inputs": [{ "internalType": "uint256", "name": "tokenId", "type": "uint256" }], "name": "ownerOf", "outputs": [{ "internalType": "address", "name": "", "type": "address" }], "stateMutability": "view", "type": "function" }]; const contract = new web3.eth.Contract(abi, "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D"); async function main() { const startTime = Date.now(); console.log("started"); for (i = 0; i < 30; i++) { contract.methods.ownerOf(i).call().then(function(result) { console.log(result); var timeFromStart = Date.now() - startTime; console.log("result received in: " + timeFromStart / 1000 + " seconds"); }); } } main(); Sending batch requests: const { Web3 } = require('web3'); const web3 = new Web3('YOUR_CHAINSTACK_ENDPOINT); const abi = [ { inputs: [{ internalType: "uint256", name: "tokenId", type: "uint256" }], name: "ownerOf", outputs: [{ internalType: "address", name: "", type: "address" }], stateMutability: "view", type: "function", }, ]; const contract = new web3.eth.Contract( abi, "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D" ); async function main() { const startTime = Date.now(); const batch = new web3.BatchRequest(); console.log("started"); // Array to hold promises for each request const promises = []; for (let i = 0; i < 30; i++) { const request = { jsonrpc: "2.0", id: i + 1, method: "eth_call", params: [ { to: contract.options.address, data: contract.methods.ownerOf(i).encodeABI(), }, "latest", ], }; // Add request to the batch and store the promise const requestPromise = batch.add(request); promises.push(requestPromise); } // Send the batch request and wait for all responses const responses = await batch.execute(); // Process responses responses.forEach((response, index) => { if (response.error) { console.error(response.error); } else { const ownerAddress = web3.eth.abi.decodeParameter( "address", response.result ); const timeFromStart = Date.now() - startTime; console.log( `${index} token owner is ${ownerAddress} received in: ${ timeFromStart / 1000 } seconds` ); } }); } main(); Multicall contract: const multicall = require("@makerdao/multicall"); const config = { rpcUrl: "YOUR_CHAINSTACK_ENDPOINT", multicallAddress: "0xeefba1e63905ef1d7acba5a8513c70307c1ce441" }; async function main() { var startTime = Date.now(); console.log("started"); var calls = []; for (i = 0; i < 30; i++) { var callObj = { target: "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D", call: ['ownerOf(uint256)(address)', i], returns: [ ['OWNER_ADDR ' + i] ] }; calls.push(callObj); } const result = await multicall.aggregate(calls, config); console.log(result.results); var timeFromStart = Date.now() - startTime; console.log("Result received in: " + timeFromStart / 1000 + " seconds"); } main(); Parallel single requestsBatch requestMulticallRound 11.6931.931Round 21.7171.592Round 31.7121.617Round 42.1031.589Round 52.7851.416Table 2: Getting the owners of BAYC tokens performance comparison The same test was conducted for reading contract calls. The result shows that both batch requests and multicall contracts save around 20% of total request time compared with sending single requests. HTTP batch request vs multicall contract Q&A If I package 100 requests into a single batch request, does that count as 1 request or 100 requests on Chainstack? As an RPC provider, Chainstack counts “request” as RPC calls. After a server receives an HTTP batch request, it “unpacks” the request and processes the calls separately. So from the server’s point of view, 1 batch request of 100 calls consumes 100 requests instead of 1. If I package 100 calls into a single multicall request, does that count as 1 request or 100 requests? In this case, even though it is a very heavy call, it counts as a single request. Is there any hard limit for the number of calls to multicall contracts? The BAYC testing script stops working with 1,040 calls. Which approach works better? Even though tests show that batch requests and multicall contracts improve performance significantly, they do have their own limitations. Requests in a batch request are executed in order, which means if a new block is received during execution, the subsequent results are likely to be different. If you want to use a multicall contract, you should probably deploy your own contract for production just to ensure its availability. Both batch requests and multicall contracts return multiple results in a single response. Both of them require much more computational resources. They can easily trigger “request timeout” errors and “response size too big” errors, which makes them not suitable for complex calls. However, like every technology, they have their limitations. Requests in an HTTP batch are executed in order, indicating any new block received during execution can potentially alter subsequent results. If you’re planning to adopt multicall contracts, we recommend deploying your own contract for production to secure its availability. Despite these minor constraints, using batch requests and multicall contracts can be an efficient way to handle multiple requests and enhance your DApp’s performance on Chainstack. eth_getLogs limitations If you’re a Web3 developer focusing on decentralized applications (DApps), you’ve likely come across eth_getLogs. It’s an Ethereum JSON-RPC endpoint that is used to query logs based on a filter object from the Ethereum blockchain. It’s an essential tool for auditing and retrieving past events emitted by smart contracts and can be accessed directly or indirectly through libraries like web3.js or ethers.js. However, like any tool, eth_getLogs has its limitations, particularly when you’re working with EVM-compatible chains. Each of these networks often has different constraints, and understanding them can greatly improve your DApp’s efficiency. For instance, the eth_getLogs method allows you to choose a range of blocks to fetch events from, but it’s important to use this facility judiciously. Although eth_getLogs is a powerful function, it’s resource-intensive, and a large block range can impact your node’s performance. We’ve experienced that it’s beneficial to limit your block range queries and follow our recommended block range restrictions for various networks. This trade-off between performance and range limits can enhance your application’s performance while ensuring you receive the logs you’re interested in. Additionally, you should know the best practices and efficient ways to use eth_getLogs. For instance, consider the following: Limit the block range: Adhere to the block range limits specific to the network you are working with. This practice helps minimize the chances of receiving an oversized response or encountering a timeout error due to an extended query. Paginate your queries: If you need to retrieve logs over a range that exceeds the network’s limit, divide your request into multiple smaller queries. This approach is akin to pagination in traditional APIs. Here’s an example way of doing that with Web3JS: const { Web3 } = require("web3"); const NODE_URL = "YOUR_CHAINSTACK_ENDPOINT"; const web3 = new Web3(NODE_URL); async function getLogs() { const startBlock = 14204533; const endBlock = 15204533; const range = 5000; const address = '0x4d224452801ACEd8B2F0aebE155379bb5D594381'; const topics = ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef']; for (let i = startBlock; i <= endBlock; i += range) { const fromBlock = i; const toBlock = Math.min(i + range - 1, endBlock); const filter = { fromBlock, toBlock, address, topics }; const logs = await web3.eth.getPastLogs(filter); console.log(logs); } } getLogs(); Filter logs to manage returned data effectively: Retrieving logs from a blockchain can generate a substantial amount of data, especially on a busy network or when querying a large number of blocks. To manage this effectively and avoid unnecessary processing, it is crucial to apply filters to your queries unless you need to retrieve all events at once. How to filter logs to manage returned data example Let’s take it a step further and demonstrate how to fetch and store Transfer event logs from the BAYC smart contract. This project stores event logs in a MongoDB instance, providing a good starting point for creating your own BAYC API. Prerequisites: Node.js MongoDB Atlas account with database setup and dedicated account Chainstack Ethereum node Setup: For this example, we will be using Node.js, so let’s set up a project: npm init -y Next, install the necessary dependencies: npm install web3 dotenv mongodb Now, create .env and main.js files and fill in the following information: .env MONGODB_CONNECTION_STRING="YOUR_MONGO_DB_CONNECTION" CHAINSTACK_URL="YOUR_CHAINSTACK_ENDPOINT" main.js require("dotenv").config(); const { Web3 } = require("web3"); const MongoClient = require("mongodb").MongoClient; async function connectToMongoDB(connectionString) { const client = new MongoClient(connectionString); try { await client.connect(); console.log("Connected to MongoDB"); return client; } catch (err) { console.error(`Failed to connect to MongoDB: ${err}`); return null; } } // Connect to your Chainstack Ethereum node console.log("Connecting to Ethereum node..."); const web3 = new Web3( new Web3.providers.HttpProvider(process.env.CHAINSTACK_URL) ); console.log("Connected to Ethereum node"); // Set the BAYC contract address const contractAddress = "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D"; // BAYC contract address // BAYC contract was created at this block const startBlock = 12686718; const batch_size = 5000; // Stay within Ethereum network limits // Connect to MongoDB connectToMongoDB(process.env.MONGODB_CONNECTION_STRING).then(async (client) => { if (client) { const db = client.db("BAYC"); const collection = db.collection("bayc-logs"); // Get latest block number console.log("Fetching latest block number..."); const endBlock = await web3.eth.getBlockNumber(); console.log(`Latest block number is ${endBlock}`); // Query logs in batches for (let i = startBlock; i < endBlock; i += batch_size) { const toBlock = Math.min(i + batch_size - 1, endBlock); try { console.log(`Fetching events from block ${i} to ${toBlock}...`); /* We can use getPastLogs or getPastEvents getPastLogs return raw data, getPastEvents will do some formatting on the data returned */ const logs = await web3.eth.getPastLogs({ fromBlock: web3.utils.toHex(i), toBlock: web3.utils.toHex(toBlock), address: contractAddress, topics: [web3.utils.keccak256("Transfer(address,address,uint256)")], }); console.log( `Fetched ${logs.length} logs from block ${i} to ${toBlock}` ); // Process logs and store them in MongoDB for (let log of logs) { await collection.insertOne(log); console.log(`Stored log ${log.id} in MongoDB`); } console.log(`Stored logs from block ${i} to ${toBlock} in MongoDB`); } catch (err) { console.error( `Error fetching logs from block ${i} to ${toBlock}: ${err}` ); } } client.close(); } }); Once the files are ready, run the script with the following command: node main.js If everything is set up properly, you will see the following output: ❯ node main.js Connecting to Ethereum node... Connected to Ethereum node Connected to MongoDB Fetching latest block number... Latest block number is 17401394 Fetching events from block 12686718 to 12691717... Fetched 183 logs from block 12686718 to 12691717 Stored log log_5b71b7bd in MongoDB Stored log log_22da2c2a in MongoDB Stored log log_6c6c5129 in MongoDB Stored log log_9b606429 in MongoDB Stored log log_de39154c in MongoDB Stored log log_a49334ff in MongoDB ... ... Stored logs from block 12686718 to 12691717 in MongoDB Fetching events from block 12691718 to 12696717... Fetched 125 logs from block 12691718 to 12696717 Stored log log_e19237a9 in MongoDB Stored log log_7611f848 in MongoDB Stored log log_a8e6d7b7 in MongoDB Stored log log_999b2ede in MongoDB Stored log log_2f4fb9f4 in MongoDB Stored log log_51054a82 in MongoDB ... ... Congratulations, you just set up your own data-processing script! How to monitor transaction propagation in EVM chains with Python As a Web3 developer, you must be aware that achieving optimal performance in your DApp involves understanding and monitoring transaction propagation on Ethereum Virtual Machine (EVM) networks. At Chainstack, one of our goals is to ensure the integrity and performance of our network. And to do this effectively, it’s imperative to monitor how transactions propagate. Monitoring transaction propagation serves several key purposes: Test network performance: Assess the network’s resilience and reaction to multiple transactions issued simultaneously. Identify latency issues: Identify potential causes of propagation delay to enhance network performance. Optimize DApp performance: Feedback from these tests can help optimize your DApp, resulting in reduced transaction time and better user experience. How can you conduct these monitoring activities? At Chainstack, we use Python to monitor transaction propagation and have devised a detailed strategy. Here’s a simplified rundown: Broadcast tansactions: Issue a series of transactions to the network. Monitor propagation: Set a network of listening nodes using Python to monitor how these transactions propagate. Measure performance: Track the time each node takes to receive a transaction, from the time of issuance to the time of receipt. Remember, the aim is not just to get transactions confirmed but to gauge how different parts of the network respond under stress. Look for variations in block time, check if certain sections of the network are slower, and use this feedback to enhance your DApp’s performance. Here’s the full code for an example monitoring tool you can BUIDL with ease: from web3 import Web3 import time from web3.exceptions import TransactionNotFound from concurrent.futures import ThreadPoolExecutor, as_completed import threading # Connect to the Ethereum node w3 = Web3( Web3.HTTPProvider( 'YOUR_CHAINSTACK_ENDPOINT')) # Ethereum address to monitor address = 'YOUR_ETHEREUM_ADDRESS' def pretty_print_transaction(tx): def wait_for_confirmation(tx_hash, block_info): while True: try: receipt = w3.eth.get_transaction_receipt(tx_hash) if receipt is not None and receipt['blockHash']: block_info['blockHash'] = receipt['blockHash'] block_info['blockNumber'] = receipt['blockNumber'] break except TransactionNotFound: pass time.sleep(1) block_info = {'blockHash': None, 'blockNumber': None} # Start a separate thread to wait for the block confirmation_thread = threading.Thread(target=wait_for_confirmation, args=(tx['hash'], block_info)) confirmation_thread.start() print("Transaction details:") print(f" Block hash: {block_info['blockHash']}") print(f" Block number: {block_info['blockNumber']}") print(f" From: {tx.get('from')}") print(f" Gas: {tx.get('gas')}") print(f" Gas price: {tx.get('gasPrice')}") if 'maxFeePerGas' in tx: print(f" Max fee per gas: {tx['maxFeePerGas']}") if 'maxPriorityFeePerGas' in tx: print(f" Max priority fee per gas: {tx['maxPriorityFeePerGas']}") print(f" Transaction hash: {tx.get('hash').hex()}") print(f" Input: {tx.get('input')}") print(f" Nonce: {tx.get('nonce')}") print(f" To: {tx.get('to')}") print(f" Transaction index: {tx.get('transactionIndex')}") print(f" Value: {tx.get('value')}") print(f" Type: {tx.get('type')}") print(f" Access list: {tx.get('accessList')}") print(f" Chain ID: {tx.get('chainId')}") print(f" v: {tx.get('v')}") print(f" r: {tx.get('r').hex() if tx.get('r') else None}") print(f" s: {tx.get('s').hex() if tx.get('s') else None}") # Wait for the confirmation thread to complete confirmation_thread.join() print(f"Updated block hash: {block_info['blockHash'].hex()}") print(f"Updated block number: {block_info['blockNumber']}") def check_pending_transaction(tx_hash, target_address_lower, w3): try: tx = w3.eth.get_transaction(tx_hash) if tx['from'].lower() == target_address_lower or ( tx['to'] and tx['to'].lower() == target_address_lower): return tx except TransactionNotFound: pass return None # Function to check if any transactions from/to the target address are in the mempool def find_mempool_transactions(target_address): local_w3 = w3 transaction_list = [] target_address_lower = target_address.lower() current_block = local_w3.eth.block_number pending_transactions = local_w3.eth.get_block('pending')['transactions'] with ThreadPoolExecutor() as executor: futures = [ executor.submit(check_pending_transaction, tx_hash, target_address_lower, local_w3) for tx_hash in pending_transactions ] for future in as_completed(futures): result = future.result() if result is not None: transaction_list.append(result) return transaction_list # Main function to monitor the mempool def monitor_mempool(address): seen_transactions = set() # Add the print statement here print("Mempool monitoring starting...") while True: current_block = w3.eth.block_number pending_block = w3.eth.get_block('pending') pending_transactions = pending_block['transactions'] print( f"Current block: {current_block}. Pending transactions: {len(pending_transactions)}" ) # Record the start time start_time = time.time() transactions = find_mempool_transactions(address) if transactions: new_transactions = [ tx for tx in transactions if tx.get('hash') not in seen_transactions ] if new_transactions: # Calculate the time taken time_taken = time.time() - start_time print(f"\\nTime taken since last check: {time_taken:.2f} seconds\\n") print( f"Found {len(new_transactions)} new transaction in the mempool involving {address}:" ) for tx in new_transactions: pretty_print_transaction(tx) seen_transactions.add(tx.get('hash')) break monitor_mempool(address) How to run a test using the monitoring tool? To conduct this test, start by executing the Python script. Then, initiate a transaction using MetaMask for simplicity. Your choice of endpoint depends on your objective. If you want to measure the speed at which a transaction reaches the mempool of your own node, use the same endpoint as in the script. If your goal is to determine the time taken for the transaction to propagate across other nodes in the Ethereum network, use a different endpoint. This will provide a more accurate depiction of transaction propagation times across the network. In the Python script, input your endpoint and the Ethereum address you wish to monitor. This could be either the sending or receiving address for the transaction, as the script is designed to track the transaction in both cases. Once the script detects a new transaction in the mempool involving the target address, it will display the transaction’s details in the console. Additionally, it will provide an estimated duration that the script took to locate the transaction. While this figure might not be entirely accurate, it serves as a useful approximation of the transaction’s propagation speed across the Ethereum network. Steps: Start the script. Send a transaction using MetaMask. You will receive a similar log in the console: Mempool monitoring starting... Current block: 3772987. Pending transactions: 84 Current block: 3772987. Pending transactions: 102 Time taken since last check: 2.22 seconds Found 1 new transaction in the mempool involving 0x8f8e7012F8F974707A8F11C7cfFC5d45EfF5c2Ae: Transaction details: Block hash: None Block number: None From: 0x8f8e7012F8F974707A8F11C7cfFC5d45EfF5c2Ae Gas: 21000 Gas price: 2181505086 Max fee per gas: 2181505086 Max priority fee per gas: 1500000000 Transaction hash: 0xebbeaa0ee6e787fa3486db9e1b8ad9ccb1e3ab982462c51fca8fa41143be053d Input: 0x Nonce: 59 To: 0x7ea178aE883bC78Fa540b15F36b1e2a8Ea90F7F7 Transaction index: None Value: 1000000000000000000 Type: 2 Access list: [] Chain ID: 11155111 v: 0 r: 0x1483859043ee02820eead543ce58bf9f5a6ec3cd3b339dc709e1860781aa1e57 s: 0x045fb5f1bb7caf42cbeb2d480fbb1a3ed1a85408154bcb052fbb17417eab5e84 Updated block hash: 0x2b120a75e3a97ba9b77d3764945c4c3c2a328699c13327538fb6dacc4642ff57 Updated block number: 3772988 Testing transaction propagation in the mempool for EVM nodes is crucial for maintaining a reliable and efficient blockchain network. By simulating realistic scenarios and using a combination of network monitoring and custom tests, developers and infrastructure operators can ensure that nodes process transactions in a timely and secure manner. Regularly conducting propagation tests will help identify potential issues, optimize resources, and contribute to the overall health of your blockchain ecosystem. How to handle real-time data using WebSocket? The requirement and expectation of real-time updates is gradually becoming prominent in the sphere of DApp development. And this is where the WebSocket protocol jumps in. It notably stands out when contrasted with HTTP, particularly in situations where the server needs to push updates to the client. At Chainstack, we’ve navigated this landscape to simplify real-time data management for you, the Web3 developer, using WebSockets in both JavaScript and Python. What is the WebSocket protocol? WebSocket is a communications protocol providing full-duplex communication channels over a single TCP connection. In simpler terms, it allows both the client and the server to send data to each other, any time. This makes it an adequate choice for use cases requiring real-time data updates, such as DApp development. How to set up WebSocket connections? WebSocket connections uphold an open line of communication between the client and the server. To establish a WebSocket connection in JavaScript, consider utilizing libraries like web3.js or ethers.js. And for Python, you may utilize web3.py, which offers a WebsocketProvider for this purpose. Here’s a simplified workflow process with JavaScript or Python: Establish a connection with the WebSocket server. Call functions and listen for events in real-time. Handle errors and connection stability. How to handle WebSocket errors and connection stability It’s pivotal to remember that connection stability and error handling are critical when using WebSocket. Unstable network conditions can cause your WebSocket connection to drop. Therefore, building a resilient logic that caters to these fluctuations effectively can pay dividends in improving your DApp’s performance. How to fetch real-time data with WebSocket and Web3JS? The web3.js library integrates subscription functionalities, enabling you to get real-time data from the blockchain effortlessly. First, install the web3.js library by running the following command: npm i web3 The following example demonstrates using the web3.js library to receive real-time block headers, including WebSocket reconnect logic. const { Web3 } = require("web3"); const NODE_URL = "YOUR_CHAINSTACK_WSS_ENDPOINT"; // Reconnect options const reconnectOptions = { autoReconnect: true, // Automatically attempt to reconnect delay: 5000, // Reconnect after 5 seconds maxAttempts: 10, // Max number of retries }; const web3 = new Web3( new Web3.providers.WebsocketProvider(NODE_URL, undefined, reconnectOptions) ); async function subscribeToNewBlocks() { try { // Create a new subscription to the 'newBlockHeaders' event const event = "newBlockHeaders"; const subscription = await web3.eth.subscribe(event); // Changed to 'newHeads' console.log(`Connected to ${event}, Subscription ID: ${subscription.id}`); // Attach event listeners to the subscription object for 'data' and 'error' subscription.on("data", handleNewBlock); subscription.on("error", handleError); } catch (error) { console.error(`Error subscribing to new blocks: ${error}`); } } // Fallback functions to react to the different events // Event listener that logs the received block header data function handleNewBlock(blockHeader) { console.log("New block header:", blockHeader); } // Event listener that logs any errors that occur function handleError(error) { console.error("Error when subscribing to new block header:", error); } subscribeToNewBlocks(); This script sets up a WebSocket connection to an Ethereum node, subscribes to new block headers, and includes logic to handle reconnections. It logs new block headers and errors to the console. How to fetch real-time data with WebSocket and ethersJS? Install the ethers.js and ws libraries: npm i ethers ws The following example demonstrates how to establish a WebSocket connection using ethers.js. This script is designed to subscribe to new block headers and includes a mechanism for automatic WebSocket reconnection. const ethers = require("ethers"); const WebSocket = require("ws"); const NODE_URL = "YOUR_CHAINSTACK_WSS_ENDPOINT"; function createWebSocket() { const ws = new WebSocket(NODE_URL); ws.on("close", () => { console.log("Disconnected. Reconnecting..."); setTimeout(() => { provider = new ethers.WebSocketProvider(createWebSocket()); startListening(); }, 3000); }); ws.on("error", (error) => { console.log("WebSocket error: ", error); }); return ws; } let provider = new ethers.WebSocketProvider(createWebSocket()); function startListening() { provider.on("block", async (blockNumber) => { console.log("New block number:", blockNumber); const block = await provider.getBlock(blockNumber); console.log("Block details:", block); }); } startListening(); This script sets up a WebSocket connection to an Ethereum node, subscribes to new block headers, and includes logic to handle reconnections. It logs new block numbers and their details to the console, ensuring that the connection is re-established if it drops. How to fetch real-time data with WebSocket and Python? Install the websockets library: pip install websockets The following example demonstrates how to establish a WebSocket connection using Python. This script is designed to subscribe to new block headers and incorporates an automatic WebSocket reconnection mechanism. # Import required libraries import asyncio import json import websockets # Replace with your own Ethereum node WebSocket URL eth_node_ws_url = 'YOUR_CHAINSTACK_WSS_ENDPOINT' async def subscribe_to_blocks(ws_url): # Continuously try to connect and subscribe while True: try: # Establish a WebSocket connection to the Ethereum node async with websockets.connect(ws_url) as websocket: # Send a subscription request for the Transfer event logs await websocket.send(json.dumps({ "id": 1, "method": "eth_subscribe", "params": [ "newHeads" ], "jsonrpc": "2.0" })) # Wait for the subscription response and print it subscription_response = await websocket.recv() print(f'Subscription response: {subscription_response}') # Continuously process incoming logs while True: # Receive a log entry and parse it as JSON log = await websocket.recv() log_data = json.loads(log) # Print the log data print(f'New log: {log_data}') print("#"*10) # If there's an exception (e.g., connection error), attempt to reconnect except Exception as e: print(f'Error: {e}') print('Reconnecting...') await asyncio.sleep(5) # Execute the subscription function asyncio.run(subscribe_to_blocks(eth_node_ws_url)) This script establishes a WebSocket connection to an Ethereum node, subscribes to new block headers, and includes logic to handle reconnections. It logs new block headers and any errors to the console, ensuring continuous monitoring even if the connection drops. Applying WebSocket protocol for real-time data can certainly contribute to the overall performance of your DApp and provide a more interactive and responsive experience for the end-user. How to master multithreading in Python for Web3 requests? For a Web3 developer constantly in pursuit of robustness and responsiveness for their DApps, harnessing the technique of multithreading in Python can prove to be a significant advantage. At Chainstack, we realize the potential of this method in handling numerous Web3 requests, and we’re eager to guide you through it. Python’s multithreading functionality allows you to execute multiple threads in parallel. This means that you can send multiple requests concurrently instead of waiting for each request to complete one after the other which can be quite time-consuming. Here’s a brief overview of using multithreading for Web3 requests: Start with your requests: Identify the requirements of repeated Web3 calls in your DApp. Create worker threads: Python’s threading library allows you to create multiple threads (or ‘workers’) to execute your requests concurrently. Queue your requests: Utilize thread-safe queues to manage your threads and their respective Web3 calls effectively. Run and monitor: Execute your program and make sure to handle exceptions and events correctly. Multithreading undoubtedly enhances the performance of your DApp by saving time on each Web3 API call, ensuring that DApp users get a smoother interface with quicker responses. How to create a simple Web3 script without multithreading? Let’s start with a simple example of making Web3 requests without multithreading. We’ll write a script to fetch the balance of an Ethereum address at various block numbers. from web3 import Web3 import time web3 = Web3(Web3.HTTPProvider("YOUR_CHAINSTACK_ENDPOINT")) address = "0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326" start_block = web3.eth.block_number end_block = start_block - 500 def get_balance_at_block(block_num): balance = web3.eth.get_balance(address, block_identifier=block_num) print(f"Balance at block {block_num}: {web3.from_wei(balance, 'ether')} ETH") start = time.time() for block_num in range(start_block, end_block, -1): get_balance_at_block(block_num) print(f"Time taken: {time.time() - start}") Import necessary modules: We import the Web3 module from the web3 package and the time module to measure the script’s execution time. Set up the Web3 provider: Establish a connection to our Ethereum node using Web3.HTTPProvider. Define the Ethereum address and block range: Specify the Ethereum address and the range of block numbers we want to check. Define the function for fetching the balance: The get_balance_at_block function takes a block number as input, fetches the balance at that block, and prints it. Fetch the balance at each block number: Loop over the range of block numbers and call get_balance_at_block for each one. Requests are made sequentially. Measure and print the execution time: Use time.time() to get the execution time and print it. How to create a simple Web3 script with multithreading? Now let’s modify the previous example to use multithreading. This will allow us to make multiple Web3 requests concurrently, potentially speeding up our script. import asyncio from concurrent.futures import ThreadPoolExecutor from web3 import Web3 import time web3 = Web3(Web3.HTTPProvider("YOUR_CHAINSTACK_ENDPOINT")) address = "0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326" start_block = web3.eth.block_number end_block = start_block - 500 max_workers = 100 def get_balance_at_block(block_num): balance = web3.eth.get_balance(address, block_identifier=block_num) print(f"Balance at block {block_num}: {web3.from_wei(balance, 'ether')} ETH") async def main(): with ThreadPoolExecutor(max_workers=max_workers) as executor: tasks = [ loop.run_in_executor( executor, get_balance_at_block, block_num ) for block_num in range(start_block, end_block, -1) ] await asyncio.gather(*tasks) loop = asyncio.get_event_loop() start = time.time() loop.run_until_complete(main()) print(f"Time taken: {time.time() - start}") Additional imports: We import asyncio and ThreadPoolExecutor from concurrent.futures. Creating the ThreadPoolExecutor: Inside the main function, we create a ThreadPoolExecutor with a maximum of 100 worker threads. Creating tasks: Create a list of tasks, where each task calls get_balance_at_block for a different block number, running in the executor. Running tasks concurrently: Use asyncio.gather(*tasks) to run the tasks concurrently. Running the event loop: Use loop.run_until_complete(main()) to run the event loop until the main() function completes. How to organize the multithreading script response? To ensure that the results are displayed in the correct order (by block number), we can modify the code slightly: import asyncio from concurrent.futures import ThreadPoolExecutor from web3 import Web3 import time web3 = Web3(Web3.HTTPProvider("YOUR_CHAINSTACK_ENDPOINT")) address = "0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326" start_block = web3.eth.block_number end_block = start_block - 500 max_workers = 100 def get_balance_at_block(block_num): try: balance = web3.eth.get_balance(address, block_identifier=block_num) print(f"Balance at block {block_num}: {web3.from_wei(balance, 'ether')} ETH") except Exception as e: print(f"Error occurred while getting balance at block {block_num}: {e}") async def main(): with ThreadPoolExecutor(max_workers=max_workers) as executor: loop = asyncio.get_event_loop() futures = [ loop.run_in_executor( executor, get_balance_at_block, block_num ) for block_num in range(start_block, end_block, -1) ] for future in asyncio.as_completed(futures): try: # This will raise an exception if the thread raised an exception result = await future except Exception as e: print(f"Error occurred in thread: {e}") loop = asyncio.get_event_loop() start = time.time() loop.run_until_complete(main()) print(f"Time taken: {time.time() - start}") How to handle errors and exceptions in multithreaded architecture? Proper error handling is crucial in multithreaded applications. Here are some common errors and how to handle them: Rate limit errors: Handle these by catching the appropriate exception in a try/except block and including logic to delay or reduce the rate of requests if you encounter a rate limit error. Thread errors: Limit the number of threads created and catch any exceptions that occur when managing threads. Synchronization errors: Use synchronization primitives like locks, semaphores, or condition variables to prevent race conditions. Unhandled exceptions in threads: Catch and handle exceptions within each thread or use the Future.result() method to handle exceptions in the main thread. Best practices for multithreaded Web3 requests Choose an appropriate number of threads: Balance the number of threads based on the nature of the tasks and the system’s resources. Handle exceptions properly: Use try/except blocks to catch and handle exceptions in each thread. Manage thread lifecycles: Clean up after your threads when they’re done, especially for long-running applications. Avoid shared state when possible: Design your threads to be independent of each other to avoid race conditions. Use appropriate synchronization primitives: If shared state is necessary, use locks, semaphores, or other synchronization primitives. Don’t ignore the GIL: For I/O-bound tasks like network requests, multithreading can provide significant performance benefits despite Python’s Global Interpreter Lock (GIL). Respect the server’s limits: Be aware of the server’s rate limits and avoid making too many requests at once. By following these best practices, you can ensure that your multithreaded Web3 application is efficient, robust, and easy to maintain. However, it’s pivotal to note that working with multithreading doesn’t come without its challenges. Correctly managing threads is critical to avoid any unexpected issues and improve your DApp’s performance. We believe that with time, practice, and the right guidance, mastering multithreading in Python for Web3 requests can become a strength in your Web3 developer arsenal, making your DApps more robust and responsive. Further reading The ultimate guide to building DApps on Chainstack: Explore our ultimate guide covering protocol selection, API authentication, error handling, and more. Ethereum DApp developer tools to help you every step of the way: Accelerate your journey from complete beginner to Web3 pro with the most impactful Ethereum development tools. Web3 Appchains, the future of DApps: Discover how appchains provide an innovative approach to building Web3 applications, significantly improving scalability and performance. Guide to Appchains and how to deploy them on Chainstack: Learn how to deploy Avalanche Subnets, Polygon CDK, zkSync Hyperchains, and Starknet Appchains on Chainstack. How to choose the right blockchain network for your DApp: Understand how to choose the right blockchain network for your project and the differences between L1 and L2 networks. Make your DApp more reliable with Chainstack: Learn how to use multiple Chainstack nodes with load balancer logic to make your DApp more performant and reliable. Bringing it all together Navigating the realm of DApp development involves a plethora of considerations—HTTP batch requests, multicall contracts, understanding eth_getLogs limitations, monitoring transactions propagation in EVM networks, handling real-time data with WebSockets, and mastering multithreading in Python for Web3 requests. At Chainstack, we empathize with the complexities faced by Web3 developers, thus we’re passionate about simplifying these complex nuances. Our aim with this guide was to offer insights into these advanced methodologies and their practical applications. We intended to provide a framework to understand their potential, challenges, and best practices while optimizing DApps on Chainstack. Sincerely, we hope these insights will make your journey smoother and more efficient as a Web3 developer, leading to the creation of DApps that are not only high-functioning but also user-centric and time-efficient. Always remember, each technique presents its own set of opportunities and challenges. The key is to use them judiciously, bearing in mind the specific requirements of your DApp, and your audience. At Chainstack, we’re consistently learning and growing too. So, if you have any thoughts, discoveries, or feedback, we’d love to hear from you. Until then, happy coding! Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### MCP for Web3 builders: Chainstack unified MCP server AI agents, LLMs, coding copilots—whatever you call them—are becoming real collaborators. But they’ve been blind to what matters most: your infrastructure. Chainstack MCP server fixes that. They give models structured access to live docs, RPC data, smart contract storage, and full on-chain state. It’s like putting your AI on blockchain steroids. The way we write and ship code is evolving. With AI models embedded in IDEs and toolchains, development is no longer a solo process. But while AI can write code, summarize APIs, and generate test cases—it still can’t see what’s really happening on your infrastructure. That changes now. What is MCP? The Model Context Protocol (MCP) is a new standard that allows AI agents to securely access external environments—documentation, APIs, infrastructure, and more. Most LLMs are sandboxed. They don’t know anything about your dev stack unless you explicitly feed them the context. That’s a major limitation when working with fast-evolving systems like blockchain. MCP removes that barrier. It allows models to retrieve relevant docs, run live queries, inspect on-chain state, and perform safe, read-only operations—on demand. This turns AI from a code generator into a context-aware partner. Chainstack unified MCP server Everything is now in one place. The Chainstack MCP server at mcp.chainstack.com/mcp combines documentation search, platform management, and live RPC access into a single endpoint — no local setup, no separate installs. Your AI agent can: search Chainstack documentation — RPC methods, deployment guides, code examples; deploy and manage Global or Trader nodes via the MCP server; make direct JSON-RPC calls to Ethereum, Solana, and all other chains available on the platform. Available tools No API key required: ToolWhat it doessearch_docsSearch Chainstack documentation — RPC methods, deployment guides, code examplesget_doc_pageFetch the full content of any documentation pageget_platform_statusCheck platform status, active incidents, and network healthget_chainstack_pricingGet current pricing informationcontact_chainstackReach the Chainstack team API key required (get one at console.chainstack.com/user/settings/api-keys): ToolWhat it doesget_organizationGet your organization name and IDget_deployment_optionsList available blockchain, cloud, and region combinationslist_projectsList all your projectscreate_projectCreate a new projectlist_nodesList all nodes with status and endpointsget_nodeGet a node’s full details including RPC endpointscreate_nodeDeploy a new blockchain nodedelete_nodeDelete a noderequest_testnet_fundsRequest testnet tokens Connect in seconds Quickest setup Paste this into Claude Code, Cursor, or any MCP-compatible agent: get mcp.chainstack.com The agent will open the discovery page and handle all configuration steps automatically. Claude Desktop Add to claude_desktop_config.json: { "mcpServers": { "chainstack": { "command": "npx", "args": ["mcp-remote", "https://mcp.chainstack.com/mcp"] } } } Fully quit Claude Desktop and relaunch. Full guide: How to connect Chainstack MCP server to Claude. Claude Code claude mcp add --transport http chainstack https://mcp.chainstack.com/mcp --scope user Cursor Add to ~/.cursor/mcp.json: { "mcpServers": { "chainstack": { "url": "https://mcp.chainstack.com/mcp", "transport": "streamable-http" } } } Windsurf Add to ~/.codeium/windsurf/mcp_config.json: { "mcpServers": { "chainstack": { "serverUrl": "https://mcp.chainstack.com/mcp" } } } Why this matters AI tools are increasingly central to modern development. But their usefulness depends entirely on the quality of their context and access to the right tools. Chainstack MCP provides that context—first through documentation, then through access to infrastructure. Models no longer hallucinate RPC methods or guess contract formats. They check the docs, validate with live calls, and help you make decisions based on real data. This is how you move from prompt-based coding to AI-native development workflows. Start building The Chainstack MCP server is live at mcp.chainstack.com. If you’re building with Claude, Cursor, Windsurf, or any MCP-enabled assistant — this is the missing link. AI meets RPC. And the future of autonomous development starts here. Lean more about Chainstack MCP → Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Meet Chainstack at CloudFest 2026 CloudFest 2026 is just around the corner — and Chainstack will be there together with our partner Virtuozzo. For the first time, Service Providers can directly monetize blockchain node hosting as a structured, scalable service. As blockchain adoption accelerates, node infrastructure is becoming a core revenue line in a multi-billion-dollar market. At CloudFest, we’ll be showcasing Chainstack Self-Hosted, the first control panel for blockchain nodes, designed to help hosting providers, cloud service providers, and MSPs launch automated blockchain nodes for their customers. You can meet our team at #Stand Z03. Our leadership team will be on-site and available for meetings: Nils Hueneke – CEO Alexandr Redikultsev – Product Director, Infrastructure Nikita Ilin – Head of Marketing Alexey Obukhov – Head of Ecosystem March 23–26 — Booth Z03. If you’re attending CloudFest and want to talk about running blockchain infrastructure as a cloud service or offering it as pre-installed software on your servers, let’s connect. Book a meeting → #### MetaMask and Helios for a trustless RPC client setup Data security and accuracy is always a hot topic even in the Web3 environment as it’s one of the core fundamentals. In this article, we’ll show you how you can use Chainstack and the new Helios light client to go trustless. What is Helios Helios is a trustless Ethereum light client written in Rust by a16z. A light client can participate in the blockchain network without having to run powerful hardware— but does not participate in the consensus and cannot be a validator. A light node will only download block headers containing a summary of the block content and randomly verify some of them, then rely on full nodes to retrieve the rest of the data. This is an important note because many users and DApps rely on nodes provider to retrieve data from the blockchain and trust that they receive the legit information. But now, you don’t have to trust anyone; you can go trustless with Helios. How does Helios work Helios is a very efficient light client; it syncs in a few seconds and does not require any storage from your machine as it uses a full node RPC endpoint to retrieve the necessary data and give you access to the blockchain. The Helios client implements execution and consensus layers, like most Ethereum clients, but the two layers work closely together, so you only need to install and use one software. The consensus layer The consensus layer light client conforms to the beacon chain light client specifications and has access to the beacon chain’s sync committees. The sync committee is a group of 512 validators randomly selected every 256 epochs, which is about 27 hours. This is useful because a validator part of the sync committee will sign every beacon chain block header. So if enough validators sign a specific block header, the block is likely the correct one. This way, Helios can track the head of the chain by asking for a sync committee signature from an untrusted RPC endpoint. The execution layer The purpose of the execution layer here is to use the block headers coming from the beacon chain and use them along with an untrusted execution layer RPC to deliver verified data. This is a good point to mention that Ethereum stores the entirety of its state in the form of a giant Merkle-Patricia tree (MPT). In a nutshell, a MPT gives us a way to deterministically verify the authenticity of small chunks of data. A Merkle-Patricia tree works in such a way that if its root is publicly known and trusted, then the authenticity of any key-value pair from the database can be verified by calling a ‘Merkle proof’.This allows us to authenticate small amounts of data at a time, which could theoretically be reproduced to authenticate much larger chunks of data through repetition and randomization. Helios uses an authenticated state root from the consensus layer. Comparing it to the untrusted execution layer RPC, Helios can locally verify the data. So why would you use Helios? In theory, a node provider with malicious intent could send you the wrong data, compromising your transactions and experience; note that there is no record of such actions by node providers, but it is possible. Using Helios as a proxy between you and your node provider can reassure you that you are receiving accurate data. Note that the Helios software is still experimental, and you should be careful using it as your primary method of communicating with the blockchain or for large transactions, as they mention on the Helios Github repository. Use Chainstack with Helios So now it’s time for the practical part, we’ll show you how you can use Helios with a Chainstack node and implement it on MetaMask to only use verified data for your transactions. Install Helios: Download the Helios installer. curl https://raw.githubusercontent.com/a16z/helios/master/heliosup/install | bash Then run the installer. heliosup When the process is complete, Helios will be installed, and you can verify it by running the -h command. helios -h This command will display the options available, how to use them, and how to create environment variables. cli USAGE: helios [OPTIONS] OPTIONS: -c, --consensus-rpc <CONSENSUS_RPC> [env: CONSENSUS_RPC=] -d, --data-dir <DATA_DIR> [env: DATA_DIR=] -e, --execution-rpc <EXECUTION_RPC> [env: EXECUTION_RPC=] -h, --help Print help information -n, --network <NETWORK> [default: mainnet] -p, --rpc-port <RPC_PORT> [env: RPC_PORT=] -w, --checkpoint <CHECKPOINT> [env: CHECKPOINT=] Set up your Chainstack node Now that we have Helios installed, we need a Chainstack Ethereum node to run it. You can deploy one for free on the developer plan. Follow these simple steps. Sign up with Chainstack. Deploy a node. View node access and credentials. Once you have access to your Chainstack’s Execution client HTTPS endpoint and Consensus client HTTPS endpoint you are ready to start the Helios client and set it up in MetaMask. Start the Helios light client You can start the Helios client with the following command. helios --execution-rpc EXECUTION_CLIENT_HTTPS_URL --consensus-rpc CONSENSUS_CLIENT_HTTPS_URL This will start the Helios client and make its RPC endpoint available on http://127.0.0.1:8545. Figure 1: Helios client start with Chainstack RPC endpoint The console shows where the RPC server is running, the status, and the confidence estimation among the information displayed. The confidence field shows a measure of what percentage of the sync committee signed the block header. Anything below 66% is rejected, as only one validator would need to sign the header, which is relatively simple to fake. Above 66%, it becomes exponentially more complicated, so this is a good measure. Note that at this moment, Helios requires the use of both execution and consensus RPCs. You can start it with only the --execution-rpc flag; this will use a default consensus client provided by Helios. helios --execution-rpc EXECUTION_CLIENT_HTTPS_URL Note that you can run Helios on Goerli as well; simply use a Chainstack’s Goerli node, and add the --network network flag at the end of the command. helios --execution-rpc EXECUTION_CLIENT_HTTPS_URL --consensus-rpc CONSENSUS_CLIENT_HTTPS_URL --network goerli Use Helios with MetaMask At this point, your Helios light client is running and ready to interact with the Ethereum network thanks to the Chainstack RPC endpoint. We can now implement it into MetaMask to make sure that the data we use to send transactions is verified. In this example I set up a Goerli network. Click on the networks tab in MetaMask, and click Add network and then on Add a network manually. Figure 2: Adding a network in MetaMask Fill up the parameters: Network name (can be any name you want): Goerli Helios Chainstack New RPC URL: http://127.0.0.1:8545 Chain ID: 5 for Goerli and 1 for mainnet Currency symbol: ETH Block explorer URL (Optional): the Etherscan URL or leave it empty Figure 3: details to add a network to MetaMask Once you save the new network, you can switch to it in MetaMask and use your secure endpoint. Figure 4: MetaMask running with new RPC endpoint Not only MetaMask MetaMask is by far the most common wallet extension, but there are other options available that you can use with Chainstack. So, now let’s see how we can use Chainstack and Helios with other wallet extensions. Trust wallet Trust wallet is another popular externally owned account (EOA) wallet, and you can download it from the Trust wallet website. Like MetaMask, Trust wallet allows the users to configure networks using custom RPC endpoints, so you can easily use it with Chainstack and Helios. Follow these steps to add a new custom network to your Trust wallet. Go in Settings Click on the Network tab Click Add custom network Figure 5: Trust wallet add custom network The page with the network details will open. The fields to fill up are the same as MetaMask, so let’s set up the Helios RPC on the Trust wallet. Network name (can be any name you want): Goerli Helios Chainstack New RPC URL: http://127.0.0.1:8545 Chain ID: 5 for Goerli and 1 for mainnet Currency symbol: ETH Block explorer URL (Optional): the Etherscan URL or leave it empty Now you are set up and ready to go using Chainstack and Helios with Trust wallet. The Trust wallet support website says they don’t keep any personal information, so this extension might be a good option if you are concerned about privacy. Frame Frame is a privacy-oriented Ethereum wallet; it runs as a desktop application available on macOS, Linux, and Windows and connects to the browser extension allowing you to interact with DApps. For the main part, Frame works just like any other EOA wallet. Still, it includes valuable extra features like read-only accounts and the ability to be injected as a MetaMask emulator. Figure 6: Frame use cases Read-only accounts essentially allow you to set DApps permissions. For example, you can set up an account that can interact with a DApp but cannot sign transactions, increasing security. The Frame extension can be injected into your browser “as MetaMask”. This means that it can emulate MetaMask, allowing you to interact with any Dapp but with the security and extra functions of the Frame wallet. Figure 7: Frame extension UI The Frame wallet gives you many tools to protect and customize your Web3 experience, including the possibility to activate/deactivate networks and set up primary and secondary RPC endpoints. To use Frame with Helios and Chainstack, simply configure a custom network in your Frame desktop app. After you set up your account, click on the Chains icon and click on ADD CHAIN. The fields to fill up are the same, but with the additional possibility of adding a secondary RPC endpoint for redundancy and selecting the chain type. In the following example, I set up the Goerli testnet in Frame, using Helios as the primary endpoint and a Chainstack endpoint as a secondary.  Figure 8: Adding new chain to Frame Note that Frame is still in beta, so it might feel challenging to use in some situations. Conclusion Software like Helios has excellent potential to improve security and the overall Web3 experience as you could integrate it directly into DApps and wallets thanks to Rust’s support for WebAssembly. This allows developers to embed Helios into JavaScript applications. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Metamask transactions tutorial – a developer’s guide to transactions in Ethereum mempool Blockchain transactions This is the first article in a two-part series. Part I — The way of the mask. <– You are here.Part II — The way of the code. These articles discuss some of the reasons behind transaction delays in blockchain networks. They explain how the mempool, transaction fees, and nonce values affect the duration of transaction confirmation.  To keep it beginner-friendly, the articles will focus on the Ethereum network, thus, most of the technical aspects discussed in these articles apply to Ethereum-based protocols. What are transactions in blockchain? Not to state the obvious, but a blockchain transaction doesn’t just show up in the ledger as soon as you send it. The transaction must wait a certain amount of time before it gets picked up by the nodes securing the network (miners or validators) and gets added to a block. Now, the whole “waiting” part of the transaction’s journey can last anywhere from a couple of seconds to a couple of minutes… hours…. days… you get the gist. During this period, the transactions reside in an area of the blockchain node called the mempool (memory + pool).  A mempool is a collection of all the “unconfirmed” transactions that are waiting to be a part of a block. Note that a mempool is not shared among multiple nodes in a network. In fact, each node has its own mempool. Each mempool is configured according to the capacity of the machine and the (Ethereum) client that they run. For example, a Geth node allows you to store 5120 “executable” transactions by default (we will discuss the “executable” part later) . In contrast, a Nethermind node sets a default value of 2048 transactions in the mempool.. This means that everything from the size of the mempool to the number of hosted transactions can vary from machine to machine.  How does blockchain verify transactions? Technically, a transaction’s journey can be summed up as propagation through the memory pools of nodes, until a node adds it to a block. Before entering the mempool, a transaction will be validated by the nodes themselves. The validation process filters out transactions with improper addressing, invalid signatures, data mismatch, etc. Only the valid transactions get to be a part of the mempool.  Most of the transactions usually do not spend more than a couple of minutes (at most) in the mempool, but there are times when they do, and when that happens, having a good understanding of the reasons behind this prolonged delay does make you look like a more knowledgeable blockchain developer. This article shows you the various ways of getting your transaction stuck in the mempool ( for practical learning purposes of course !). The idea is to familiarize yourself with these situations so that you would know what to do when you face one while developing an application. Metamask transactions As developers, our way is the way of the code. But since this is an introductory article, I thought it would be really useful if we could understand the concepts from a high-level user perspective before jumping into code. To do that, we will use MetaMask.  Here is what I want you to do: Set up MetaMask in your browser.Create a couple of accounts in MetaMask. Note: You can get test tokens for your account using various faucets available online.  Now, if you feel that this exercise is lacking a certain developer flair, you can always make it interesting by setting up “your own” blockchain node and using that node to conduct transactions.  To set up your own blockchain node: Head over to Chainstack and set up an account.Deploy a node in Chainstack. Note: Since we are working on the Ethereum network, any Ethereum testnet node will be fine. This article, for instance, uses a Ropsten node. Once you have the node up and running, get the node connection endpoints. After getting the endpoints, you can open up MetaMask and add the new node as part of your network.  How to add a network to Metamask or connect your node? Open MetaMask and click on the network drop-down menu.Click on the Add Network button. In the new window, fill in all the details and click on Save. Note: Different blockchains can have different chain IDs. Based on your network, you can find the corresponding chain IDs online.  And that’s it. Just like that, you have your own node for conducting transactions. Great, so, let’s get cracking.  Blockchain transaction fees A transaction fee, as the name suggests, is a fee that you pay the nodes responsible for the validation and verification of your transactions. The fee acts as an incentive for the people running these nodes. The fee along with the block rewards motivates them to keep the nodes running. Apart from acting as an incentive, the transaction fee (or gas fee, in Ethereum) also helps deter “sus” transactions (spams and such) by effectively making them expensive. (If you want to get really deep into the topic, check out the research: DETER: Denial of Ethereum Txpool sERvices.) While making a blockchain transaction, the user must include a reasonable transaction fee. A “less-than” reasonable fee might get your transaction stuck in the mempool. You see, the transaction fee is a crucial detail that the nodes use in order to prioritize transactions. A higher transaction fee means a better incentive for the node, so, transactions carrying a higher fee get picked up fairly quickly by the nodes for confirmation. The fee, however, is not stable. It depends on the network usage, meaning that a highly congested network (one with high transaction volume) demands a higher transaction fee.   During a period of high network activity, users are free to offer higher transaction fees in order to “out-prioritize” other transactions in the network. This prompts the miners/validators to increase the minimum accepted transaction fee. They do it in order to maximize their incentive. The changing nature of the fee makes it hard for us to pinpoint a definitive value that can be regarded as high/low (in terms of transaction fees).  Source:  Etherscan.io Hence, the chances of getting stuck due to “low fee” is ever-present in a blockchain network.  To get a taste of transaction prioritization due to its fee, you can simply switch between the high, medium, and low options available while conducting a transaction in MetaMask. Do you notice the time difference?  MetaMask uses the latest block’s gas information in order to set the initial prices, but the user is free to edit these amounts. Note: If you are using your own Chainstack node with MetaMask, you can see the function calls that MetaMask makes in order to get the latest block information. The function details will be given under the Method calls metric on the node details page.  To truly make your transaction wait, you can try and set the transaction fee way too low and send a transaction.  Note: While doing this, MetaMask will flash some friendly warnings regarding the low fee, but since we are here to prove a point, we can ignore those warnings.  OK, you successfully got your transaction stuck in the mempool, so, how do we rescue it? Well, in MetaMask, you can either cancel this transaction or you can speed it up.  Now, both these options work by recreating and resubmitting the transaction.   But wait, how come we get to recreate our transaction? What happened to our old transaction? Well, to understand all that, you need to know a bit of nonce wizardry.  Transaction nonce wizardry  By definition, a nonce is a number you can only use once. In account-based protocols like Ethereum, they use a concept called account-nonce. An account-nonce acts like a transaction counter associated with an Ethereum address. They help maintain the order of transactions by keeping track of the number of confirmed transactions from a particular address (and by extension, the account). Each new transaction from an account will be attached to the current account-nonce, and once the transaction is confirmed, the account-nonce gets incremented by 1.  Note: Account-nonce is not stored on the blockchain as part of the account’s state. It is determined dynamically based on the number of confirmed transactions from the account. The above illustration is merely an abstract depiction of its functionality.  You cannot submit a transaction with a previous nonce value. But, while a transaction is still waiting to be confirmed, it is possible to submit another transaction with the same nonce, in hopes of replacing the older, pending transaction. For this to happen, the new transaction will need to have a higher transaction fee in order to give it a higher priority and a higher chance of getting picked up first for confirmation. Once the new transaction gets confirmed, the older, pending transaction will become invalid (due to duplicate nonce) and it will be dropped from the mempool. This is essentially what happens when you “speed up” or “cancel” a transaction in MetaMask.  While speeding up a transaction, you are sending an identical transaction with a higher transaction fee, same nonce, and the same ETH value. Cancelling a transaction involves sending a similar transaction with a higher fee, the same nonce, but 0 ETH value. In both cases, however, you must pay a higher transaction fee. Now, it is possible to define the “how high of a price” parameter in your node. Let’s say you are running a Geth node. There is a parameter in Geth called txpool.pricebump that lets you define the percentage of extra fees that you would have to pay in order to replace a transaction. The default value is 10% in Geth, meaning, if the initial fee was $100, you would need $110 to replace it. If you try and send a replacement transaction with a fee below the pricebump rate, the node will reject it with the message “transaction underpriced.”  How to fix a stuck pending transaction in Metamask? You can do the whole replacing thing manually by enabling the custom nonce option in MetaMask.  To do this: Go to MetaMask settings > advanced, and Turn on the Customize transaction nonce option.  This will enable you to set a custom nonce value for your transaction.  Now, while using a custom nonce, remember that you cannot use any previous nonce values, and if you are planning to use a random nonce value that is much higher than the current account-nonce, know that it comes with its own set of problems (which we will discuss later).  So, to replace a pending transaction, set up a similar transaction with the same ETH value, give the same nonce for the transaction, add a higher transaction fee, and voila! Thanks to the higher transaction fee, your new and improved transaction will most likely get confirmed first and the pending transaction will be dropped.  Minding the gap  Since we are on the topic of nonce values, there is another possible way in which a transaction can get stuck in the mempool and this involves a gap in the nonce value. A nonce gap occurs when a transaction having a higher nonce value reaches a mempool before the preceding transactions. In such a situation, the transactions with the highest nonce value would have to wait for all the previous transactions to be confirmed.  The nonce gap usually occurs due to some fault in application logic or when too many wallets are trying to deal with the same account and in this situation, speeding up the transaction might not do you much good.  To understand the situation better, we can simulate a nonce gap using our MetaMask wallet.  For simulating a nonce gap: Make sure you have the enabled the Customize transaction nonce option.Send a transaction with a higher nonce value (+1 would be sufficient). You can see that the transaction with the higher nonce will remain pending. To get it out of the mempool, you need to fill the nonce gap by sending the transactions carrying all the previous nonce values.  During this process, you might see that the transactions carrying higher nonce values appear to be in the queued state rather than the pending state. This is because the pending state is for transactions that are “executable.” A transaction with a higher nonce value cannot be executed until all the previous transactions have been confirmed and because of that, these “higher nonce value” transactions will remain in the queued state until all the “lower nonce value” transactions get confirmed.   Note: In a Geth node, you can store 1024 queued (non-executable) transactions by default.  Closing notes  So far, we have discussed a couple of methods for getting your transactions stuck in the mempool. There are more intricate situations (like node issues, protocol changes, etc) that cause delays in transactions, but the ones discussed here are the most common and are somewhat within the control of the developer.  In the next article, we will see how we can recreate all the above-mentioned situations using the way of the code.  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### MetaMask under the hood—not just a crypto wallet This is the first article in a two-part series. MetaMask under the hood. <– You are here.Fault-tolerant transactions with MetaMask and Chainstack. The best crypto wallet? Maybe MetaMask is a widely popular browser extension, with more than 30 million monthly users as of the beginning of 2022. MetaMask opened the doors to Web3 for the masses. But how does it work? How does it help us connect to and interact with a blockchain? Is there anything we can do to improve it and make it even more reliable? Defined as a non-custodial wallet, MetaMask allows you to have full control of your access keys. This is great because you can manage your assets how you want, but it also means that there is no “complaints department” to contact if you lose access to your funds or if you send them to the wrong place. Therefore, we want to explain how MetaMask works. This series is divided into two parts and will answer all these questions. You will have a much better idea of what happens behind the curtains when you use MetaMask. This article is the first part of the series where we dive deep into the inner workings, while the second part will show you how to make MetaMask more efficient and reliable using Chainstack. What is MetaMask? MetaMask is a tool that allows you to store tokens, interact with decentralized applications (DApps), and experience Web3. MetaMask is available as a browser extension and as a mobile app on iOS and Android. It was created to help users have a secure, reliable, and easy connection to Ethereum-based blockchains.   More than just a wallet Most people know MetaMask as a crypto wallet, but it is much more than just that. You can consider it a cryptographic account manager that uses cryptography to keep the keys of your account secure. When you create a new account on MetaMask, it generates a new pair consisting of a private and a public key. These keys are essential to guarantee that the transactions executed are legitimately done by the account’s owner, and the user can manage the keys in a variety of ways. An example is a hardware wallet that separates the wallet from the Web3 environment and keeps it safer. Metamask public and private keys  The public key, also known as an address in the Web3 environment, is an alphanumeric character string used to encrypt the transactions that the account makes; and it is available to anyone to see. In Ethereum-based environments, the address begins with 0x. For example: 0x06A85356DCb5b307096726FB86A78c59D38e08ee The private key is also an alphanumeric string of data, but MetaMask associates it to a single account in a wallet. When an account receives a transaction, it uses the private key to decode it and access the funds, and because the private key is unique to that account, other accounts cannot access it. Note that whoever controls the private key controls the account funds. If you lose your private key, you lose access to the account and the funds in it. In short, we can compare the public and private keys to login information for a website, where the public key is your username, and the private key is the password. But in this case you are the holder of the keys, as opposed to the traditional system where the website holds your login information somewhere on a server under their control. And this is one of the things that make Web3 applications different from the traditional Web2 applications. How does MetaMask work? As a browser extension, MetaMask can interact with the web pages that you browse. It injects a global API known as window.ethereum into websites that you visit. This allows the website unrestricted access to a set of JavaScript functions to interact with the blockchain through a node. The window.ethereum object allows websites to read data from blockchains the user connects to, suggest that the user sign messages and transactions, and so on. MetaMask uses this API to identify a Web3 user and what Ethereum network is trying to interact with. Important methods that MetaMask uses from this API include:  Retrieve an account’s balance – eth_getBalanceSend a transaction – eth_sendTransaction Sign messages using the private key – eth_sign   You can find a complete list of Ethereum JSON-RPC API methods in the Ethereum wiki.  How to use Metamask to interact with DApps?  One of the use cases for a tool like MetaMask is to allow its users to interact with decentralized applications, such as DeFi platforms, decentralized exchanges, NFT marketplaces, game applications on a blockchain, and more. MetaMask manages this by allowing you to permit the DApp to retrieve your address to interact with it. Which will look something like this: This is an important feature in MetaMask because it allows you to be in control of what you approve of. Note that anyone can deploy a token’s smart contract, so you should be careful making sure that you are only approving legitimate smart contracts that you recognize. If you approve a malicious smart contract, you risk allowing it to transfer your funds out of your account. How to make transactions in MetaMask? Transactions are sent through a node and are formal actions that can result in simply swapping a token for another, creating a new smart contract, or any other interaction that changes the state of the blockchain. When you interact with a smart contract calling a function that changes the state of the network, MetaMask will initiate the transaction by calling the eth_sendTransaction method. MetaMask will use the ethereum.request method directly to send a transaction. Checkout this Gist, It contains the code for a basic website that allows you to see the JavaScript code to build a transaction and send it using MetaMask. Interact with MetaMask Many parameters compose a transaction, and MetaMask takes care of setting it up automatically, but let’s see what the parameters are and how MetaMaks constructs them. Nonce (ignored) The nonce is a number showing how many transactions an account has made so far. Transactions are always processed in order, and to be valid, the nonce must either be 0 or greater than a previously processed transaction. It is a sensitive parameter, especially if users interact with different DApps from the same account. When initiating a transaction, Metamask will call the eth_getTransactionCount method, which will return the current nonce. If a transaction is sent with a previously used nonce, the transaction will fail. For these reasons, MetaMask currently does not provide application developers with any way to customize the nonce. But as a user, you can set a custom nonce number when you send a transaction. You will need to activate this feature in the advanced settings on MetaMask. Transaction gas limit:  Gas limit is a parameter that MetaMask sets up automatically. It is simply the maximum units of gas that you are willing to pay for a transaction. 21000 units is the standard in EVM compatible networks, and you can retrieved it by using the eth_EstimateGas method. Transaction Gas price:  This is the fee you pay to the network to process the transaction. Generally, the network processes the transaction based on how profitable is for miners or validators. MetaMask makes an estimate likely to include the transaction in the block. The gas price is expressed in Gwei, and you can calculate it by adding the base fee with the priority fee (miner tip).   By calling the eth_getBlockByNumber method, MetaMask receives the base fee from the network, calculated based on the demand for block space.   The priority fee is generally a minimum of 2 Gwei, and this is what MetaMask selects as standard (on Ethereum). Based on this, MetaMask estimates the gas price as follows: (Base fee + priority fee) x gas limit Taking Ethereum as an example, assuming that the base fee is 50 Gwei, your gas price will be: (50 + 2) x 21000 = 1,092,000 Gwei = 0.001092 ETH So summarizing, if you try to send 1 ETH to another address, you will spend a total of 1ETH + gas price, for a total of 1.001092 ETH. You can send a higher priority fee to incentivize the miners and validators to process your transaction faster. To: This is the address that receives the transaction. It is a hex-encoded Ethereum address, and it is always present except when creating a new smart contract. Value: Value is the amount of native currency to send, and it is encoded in hex. Data (optional):  MetaMask uses this parameter when it creates or interacts with a smart contract. Most smart contracts are written in solidity, and applications use an application binary interface (ABI) to interpret the content. When you call a smart contract function, Metamask will use this parameter to tell which function to call by encoding the method and the parameters from the ABI into hex.    As an example, we want to call this function, passing 20 as the parameter. MetaMask will send a transaction with the following data parameter:  0x9fa6dd35000000000000000000000000000000000000000000000001158e460913d00000  This is how to encode a function call:  The first four bytes represent the hashed name of the function and the argument.  0x9fa6dd35  Then encode the parameter in hex, pad to 32 bytes, and add at the end. The number 20 is converted to Wei (20000000000000000000).  1158e460913d00000   If we check the transaction in the block explorer, we can see how it is encoded: Chain ID:   Currently ignored by MetaMask. The Chain ID is a number used during the process of signing and verifying transactions (different from the private key). It distinguishes the different chains and avoid replay attacks, so that transactions are not duplicated on another chain. You can retrieve this data by using the eth_getChainId method.  Conclusion  Now, you should have a better idea of how MetaMask works behind the scenes, why it is so powerful and why so many people use it. I am sure you will not look at it as “just my crypto wallet” anymore. The second part of this article will show you how to make your MetaMask even better and more reliable using Chainstack as an endpoint provider! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Metaplex Solana NFT metadata – How to get NFTs metadata? You are a developer on Solana. Your job is all about NFTs, especially Metaplex NFTs. Through intensive research, you find out the metadata of all Metaplex tokens is stored in an account created during minting. You track down an address with a Metaplex NFT and send over the getAccountInfo RPC call to retrieve NFT metadata. It returns a string that you have never seen before. It is long, it is random, but you just know this is what you are after. Nervously, you open an online decoder for base64, paste the string into the text field, and you see: This is so confusing. A part of this string is correctly decoded, but the majority of it is still just black diamonds with a question mark. You wonder what format it is decoded from. Is it ASCII? UTF-8? You try all formats, but none of them works. Well, you are at the right place. There are essentially two parts to this article: Why doesn’t the decoder work?Python code snippet on Google Colab to the rescue. Hope this article can be the final piece of the puzzle. Why doesn’t the decoder work? Long story short, that is because the original object is not a string, JSON, or any kind of data that can be directly decoded into. Take this STEPN shoe NFT as an example: The original metadata can be found on the explorer tab. It is a JSON object. When the original metadata is processed, it is first transformed into an array of bytes, and then into base64 text for storage purposes. However, the encoding of the original fields is not unified. Some fields are base58 encoded, and others UTF-8 encoded. Comparison between base64 and base58 characters. Even though both methodologies are text-based, the mismatched decoding results in unidentified characters and misinterpretation. Using the source account as an example. To encode the source account, firstly it is decoded to byte data: Then the byte data is encoded into a base64 text: sku0a/f9w7D1gJ82cZokGXec75GzLhtEy2iTHJN0Uzc. The text piece can be found in the original text too—it starts from the 45th character. If this string is decoded backward, but in a different format, for example, UTF-8, it throws an error. This is because UTF-8 does not have the mapping for the original byte data and is unable to interpret the context. How to get NFTs metadata? To decode the metadata information, the first thing we need to know is how the fields were encoded originally. Luckily, it can be found in the Metaplex Python API source code. The source code was moved to this Jupyter notebook on Google Colab to demonstrate how decoding can be done. For readers not familiar with a Jupyter notebook, you can either choose Run all in the Runtime tab to run the code: Or press the run button to run it cell by cell. By doing so, the kernel loads all necessary packages and functions. When it is done, scroll down to the last cell. Change the value of rawdata and press the run button to run the code. If everything goes well, you should see a decoded object displayed. Conclusion Thank you for reading this article, hope it helps. If you have any questions, feel free to ping me on Twitter/Telegram/Discord. Happy coding. Cheers. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Migrate your Robinhood Chain RPC to Chainstack Robinhood Chain shipped in July 2026 and the RPC market around it started forming the same week. Alchemy and BitGo were named at launch. Chainstack shipped Robinhood Chain support three weeks later — Global Nodes, Dedicated Nodes, Full and Archive, on mainnet and testnet, with debug_* methods enabled from day one. Since then teams have been quietly moving their Robinhood Chain RPC to Chainstack. This guide is the reason to do the same, and the two ways to actually do it: paste one line into any AI coding agent, or migrate manually. First 3 months at 50% off Growth with code ROBINHOOD50. Robinhood Chain in two minutes Robinhood Chain is an Arbitrum Orbit L2 for finance and tokenized real-world assets by Robinhood — tokenized U.S. equities (Stock Tokens), onchain lending, agentic trading. Testnet went live February 10, 2026, mainnet on July 1, 2026. As of mid-August 2026: Surpassing $940M TVL Over 420M total transactions since testnet Average block time: ~100 ms (roughly 10 blocks per second) Average transaction cost: ~0.00002 ETH Native DeFi at launch: Uniswap, Morpho, Pleiades Over 120K ERC-4337 smart accounts and 1.6M+ user operations The economically interesting part is the distribution. Robinhood’s retail brokerage user base is now onboardable into onchain finance through a chain that was built for exactly that. RWA workloads don’t behave like generic DeFi — compliance events, audit reconstructions, corporate-action multipliers, and 24/7 settlement all sit in the RPC layer. The cost of getting that layer wrong is direct. Why RPC budgets are getting rebalanced right now A 100 ms block chain rewrites your RPC cost model whether you notice or not. An indexer that polled every block on Ethereum burned ~7,200 requests per day. The same indexer on Robinhood Chain burns ~864,000 — 120× more. If your provider prices per compute unit or per method with a multiplier, this is where the bill quietly ships. Here’s how the three big providers price the same workload: ProviderModelTrace on Arbitrum-familyGrowth-equivalent tierChainstack1 RU per request (2 RU for archive), flat multiplier✅ debug_* on Global Node, paid planGrowth: $49/mo, 20M requests, 250 RPSQuicknodeAPI Credits, 2× multiplier on Trace & Debug, 4× on Arbitrum replay-type methods✅ Available, with multipliersScale: ~$499+/mo base + usageAlchemyCompute Units, variable per methodNot clearly documented for Orbit L2sPay-as-you-go, ~$230/mo for 20M requests Two structural advantages compound for Robinhood Chain workloads specifically: 1. Trace and debug work. Robinhood Chain runs Arbitrum Nitro, so any RWA app doing NAV reconstruction, compliance replay, or forensic audit needs debug_traceTransaction, debug_traceBlockByNumber, and debug_traceCall. Chainstack serves the debug_* namespace on a Global Node paid plan. Quicknode offers trace access at a 2–4× multiplier depending on the method. Alchemy’s trace support for Arbitrum Orbit L2s specifically isn’t clearly documented — worth confirming with them directly before committing to a heavy trace workload. 2. Archive is 2× a full call. Chainstack bills archive requests at 2 RU vs 1 RU standard, a flat multiplier. Quicknode’s stacked multipliers (chain × method × archive) can compound cost on archive-heavy workloads — NAV recalculation, proof-of-reserve, historical compliance queries. For a chain built for RWAs, this matters. For high-cadence indexers where per-request billing burns quota against 100 ms blocks, the Unlimited Node add-on removes per-request billing entirely at a fixed RPS ceiling (25–500 RPS). Dedicated Nodes start from $0.50/hour + storage for teams needing isolated infrastructure. Chainstack also holds a 99.99% SLA on both Global and Dedicated tiers, multi-region coverage across the US, EU, and Asia-Pacific, and SOC 2 Type II compliance for teams that need it. Live latency and uptime numbers across providers are published at compare.chainstack.com if you want to check current figures yourself. How to migrate: two paths Path 1: One paste into any AI coding agent Chainstack’s migration runbook is executable. Paste this into Claude Code, Cursor, Codex CLI, Windsurf, Gemini CLI, or any MCP-compatible agent: get docs.chainstack.com/docs/migrate-to-chainstack-with-ai.md The agent fetches the Migrate to Chainstack with AI runbook and walks through Assess → Plan → Implement: Assess. Scans the codebase for RPC endpoints, identifies protocol and method usage, and checks Chainstack coverage via the Chainstack MCP server. For teams already on Quicknode, the agent pulls billing-period usage directly through the Quicknode Admin API. For Alchemy users, it asks for your usage numbers from the Alchemy dashboard. Then it converts source usage to Chainstack Request Units and produces a live cost comparison. Plan. Lays out endpoint-by-endpoint replacement — which existing Chainstack node covers what, or what new nodes need to be created. Flags dedicated-node needs, add-ons like Warp or Yellowstone Geyser, and anything requiring manual console setup. Implement. After you approve the plan, the agent creates nodes via create_node and swaps endpoint URLs across your codebase. Summarizes what changed. For most teams this is minutes, not weeks. The agent stops at the Plan step and waits for explicit approval before touching anything. Path 2: Manual migration If you prefer to run the migration yourself, the steps are direct. Timing depends on your codebase — a simple app takes an afternoon; a production workload with multiple services and monitored parallel operation takes a couple of days. Inventory. Search the codebase, environment files, config, and secrets manager for RPC URLs pointing at your current provider. Note protocol, network (mainnet or testnet), and any methods that need special handling — debug_*, eth_subscribe for WebSocket, archive queries. For teams using provider SDKs (Alchemy SDK abstracts the URL), inventory happens at the SDK client instantiation level. Estimate. Pull your current RPC usage: the Alchemy dashboard, Quicknode Admin API, or the billing page for other providers. Match your monthly request volume against Chainstack pricing — 1 RU per standard request, 2 RU per archive request — and pick the cheapest plan that covers your volume. Sign up. Create an account at console.chainstack.com. Apply ROBINHOOD50 at checkout for 50% off Growth, first 3 months. Deploy. In the console: Add node → Robinhood Chain → pick Mainnet or Testnet → pick Global Node (shared, geo-balanced, deploys instantly). For Dedicated Nodes (isolated compute, from $0.50/hour), contact the Chainstack team — Dedicated deployment isn’t self-serve through the console. Swap. Copy the HTTPS and WebSocket endpoints from Access and credentials and replace your existing RPC URLs. Keep the old provider live during transition as fallback. Smoke test. Verify the migration covers your actual workload: eth_blockNumber, eth_call against your key contracts, eth_subscribe for pending transactions if you use it, and a debug_traceTransaction on a known transaction if you rely on trace. Chain ID is 4663 for mainnet, 46630 for testnet. Monitor. Compare P50/P95 latency and error rates against your previous provider for the first 24–48 hours. Use Chainstack Compare for a live benchmark cross-reference. Cut over. Once verified, remove the old provider from the config and revoke the API keys. Both paths land you in the same place. Pick AI-agent if the codebase is complex or the team is small. Pick manual if you want end-to-end control over the sequence. Deploy and claim your 50% off Promo code: ROBINHOOD50 What it covers: 50% off the Growth plan — $49/month standard, $24.50/month for 3 months with the code Included: 20M requests/month, 250 RPS, Full and Archive nodes on Mainnet and Testnet, WebSocket, debug_* methods Larger workloads: Business, Enterprise, or Dedicated deployments get a sales-led custom deal — contact the Chainstack team directly Two-click redemption: Claim 50% off → — sign up or log in, code applies at checkout Migration guide → — full AI-agent runbook and manual reference Who’s already building on Chainstack for Robinhood Chain The migration pattern is already visible. Teams shipping onchain financial products on Robinhood Chain have moved their RPC to Chainstack for the pricing predictability, trace availability, and 99.99% SLA — 1inch, Trust Wallet, and Zerion among them. If the teams building a leading DEX aggregator, one of the largest mobile wallets, and a top portfolio product are already on the same infrastructure, the pattern is worth checking. Start building on Chainstack → FAQs Does migration cause downtime? No. Chainstack endpoints are drop-in replacements for standard Ethereum JSON-RPC over HTTPS and WebSocket. Deploy the new node, verify it responds to your workload, swap the URL, and remove the old one after monitoring for 24–48 hours. Both providers can run in parallel during the transition. Am I eligible for the 50% off promo if I’m already on Chainstack? Yes — the promo applies to teams expanding to Robinhood Chain as well as teams migrating their RPC to Chainstack. Apply ROBINHOOD50 when adding Robinhood Chain nodes to your existing account. What happens after the 3-month promo ends? Your plan reverts to standard Growth pricing ($49/month) when the promo period expires. No auto-upgrade to a higher tier. Can I self-host Robinhood Chain nodes instead of using managed? Yes. Chainstack Self-Hosted supports Robinhood Chain Mainnet and Testnet on your own infrastructure — same one-click deployment flow, snapshot bootstrap, self-healing, and observability stack. See the Self-Hosted v2.8.2 release notes for details. Which SDKs and tools work with Chainstack Robinhood Chain endpoints? All standard Ethereum tooling: ethers.js, viem, web3.py, Hardhat, Foundry, Remix, MetaMask. Set the chain ID to 4663 (mainnet) or 46630 (testnet) and point at your Chainstack endpoint. See Robinhood Chain tooling for the full setup. What about Warp transactions or Yellowstone Geyser? Those aren’t available on Robinhood Chain specifically (Warp is for high-throughput transaction submission on chains like BNB Smart Chain). For Robinhood Chain, the equivalent throughput features are the Unlimited Node add-on (fixed RPS ceiling, no per-request billing) and Dedicated Nodes (isolated compute for consistent latency). Where can I benchmark Chainstack against my current provider on Robinhood Chain? compare.chainstack.com publishes live P50/P95/P99 latency, uptime, and regional coverage across all major Robinhood Chain RPC providers. Updated live. Additional resources What is Robinhood Chain? A full builder’s guide — architecture, infrastructure, performance, use cases Robinhood Chain vs Solana: two paths to tokenized RWAs — comparison editorial Chainstack introduces Robinhood Chain support — launch announcement with full coverage details Migrate to Chainstack with AI — AI-agent migration runbook Chainstack MCP server — full tool reference Chainstack Compare — Robinhood Chain — live RPC provider benchmarks Chainstack pricing — plans, RU model, calculator Robinhood Chain testnet faucet — free testnet funds for development #### Migrate your Stable RPC to Chainstack Stable launched in late 2025 as an EVM-compatible Layer 1 built by the team behind USDT0, where dollars — not a volatile gas token — are the unit of account for every transaction. Chainstack shipped Stable Mainnet support on August 5, 2026 — Global Nodes, Full and Archive, with the debug_* namespace enabled on archive from day one. Infra cost is one of the first blockers for a new team shipping on Stable. Since Chainstack added Stable Mainnet support in August, teams have been quietly moving their Stable RPC over to cut that cost. This guide is the reason to do the same, and the two ways to actually do it: paste one line into any AI coding agent, or migrate manually. First 3 months at 50% off Growth with code STABLE50. Stable in two minutes Stable is an EVM-compatible Layer 1 built by the team behind USDT0, purpose-designed so that gas is paid in USDT0 instead of a volatile native token. It runs on StableBFT, a CometBFT/Tendermint proof-of-stake consensus with block times around 0.7 seconds, and reached roughly $557M market cap with ~6,000 holders within weeks of mainnet. Chain ID is 988. Block time: ~0.7 seconds — roughly 17× more blocks per day than Ethereum’s ~12-second average Gas paid natively in USDT0 (18 decimals) — a separate asset from the USDT0 ERC-20 token (6 decimals) Private, always-empty public mempool — no pending-transaction subscriptions ~$557M market cap, ~6,000 holders within weeks of its late-2025 mainnet launch The economically interesting part is the design: a chain where the unit of account is a dollar-pegged stablecoin, not a volatile gas token, built specifically for payments, settlement, and dollar-denominated onchain applications. That makes RPC correctness — not raw speed — the thing that actually matters for a production integration. Why RPC budgets are getting rebalanced right now A 0.7-second block chain changes your polling math whether you notice or not. An indexer that polled every block on Ethereum burned ~7,200 requests per day. The same indexer on Stable burns roughly ~123,000 — about 17× more. If your provider prices per compute unit or per method with a multiplier, this is where the bill quietly ships. Stable also ships three behaviors that will surprise teams porting Ethereum tooling directly, each with real cost or correctness implications: The decimal trap. Native USDT0 gas reports 18 decimals; the USDT0 ERC-20 token (contract 0x779Ded0c9e1022225f8E0630b35a9b54bE713736) reports 6. Mixing them up is a 10^12 error. No public mempool. Pending-transaction subscriptions return nothing. Inbound-payment detection has to move to eth_subscribe log watching on the USDT0 contract instead. No Parity-style trace. trace_* methods return -32601. Tracing goes through the debug_* namespace (debug_traceTransaction, debug_traceBlockByNumber with callTracer) on an archive node instead. Here’s how the field looks today. Stable’s own RPC providers documentation lists Alchemy and Tenderly alongside Chainstack; Quicknode, Uniblock, and OnFinality don’t yet support Stable. ProviderMainnet accessArchive & debugCompliancePricing modelChainstack✅ Self-serve Global Nodes✅ debug_* on archiveSOC 2 Type II, ISO 27001RU-based; flat-fee Unlimited Node optionTenderly✅ Self-serve mainnet RPCSimulation & tracing (its specialty)SOC 2 Type IICredit/unit-basedAlchemy⚠️ Testnet public; mainnet enterprise-gated on requestEnhanced APIsSOC 2 Type IICU-based, method-weighted Two structural points compound for a Stable migration specifically: 1. Mainnet access, not just support. Alchemy lists Stable, but production mainnet access is enterprise-gated on request rather than self-serve — a team prototyping on its public testnet can’t simply flip to a public mainnet endpoint the way they can on Ethereum. Chainstack and Tenderly both offer self-serve mainnet from day one. 2. Continuous reconciliation load punishes per-request billing. A stablecoin backend runs constant eth_getLogs sweeps and balance checks for reconciliation, not occasional bursts. CU-based and credit-based pricing (Alchemy, Tenderly) scales with that volume; Chainstack’s RU model plus the Unlimited Node add-on (flat monthly RPS tiers, $149/mo for 25 RPS up to $3,199/mo for 500 RPS) turns that into a fixed line instead of a bill that scales with transaction volume. Chainstack also holds audited SOC 2 Type II and ISO 27001 certifications and offers Self-Hosted deployment for both Stable Mainnet and Testnet, for teams that need the node inside their own infrastructure perimeter. No public real-time benchmark dashboard covers Stable RPC providers yet — measure latency yourself from your target region before committing. How to migrate: two paths Path 1: One paste into any AI coding agent Chainstack’s migration runbook is executable. Paste this into Claude Code, Cursor, Codex CLI, Windsurf, Gemini CLI, or any MCP-compatible agent: get docs.chainstack.com/docs/migrate-to-chainstack-with-ai.md The agent fetches the Migrate to Chainstack with AI runbook and walks through Assess → Plan → Implement: Assess. Scans the codebase for RPC endpoints, identifies protocol and method usage, and checks Chainstack coverage via the Chainstack MCP server. For teams already on Alchemy, it asks for your usage numbers from the Alchemy dashboard. Then it converts source usage to Chainstack Request Units and produces a live cost comparison. Plan. Lays out endpoint-by-endpoint replacement — which existing Chainstack node covers what, or what new nodes need to be created. Flags anything requiring manual console setup. Implement. After you approve the plan, the agent creates nodes via create_node and swaps endpoint URLs across your codebase. Summarizes what changed. For most teams this is minutes, not weeks. The agent stops at the Plan step and waits for explicit approval before touching anything. Path 2: Manual migration If you prefer to run the migration yourself, the steps are direct. Timing depends on your codebase — a simple app takes an afternoon; a production workload with multiple services and monitored parallel operation takes a couple of days. Inventory. Search the codebase, environment files, config, and secrets manager for RPC URLs pointing at your current provider. Note any code that relies on pending-transaction subscriptions (Stable’s mempool is always empty — this needs to move to eth_subscribe log watching) or Parity-style trace_* calls (these return errors on Stable; the replacement is the debug_* namespace). Estimate. Pull your current RPC usage: the Alchemy dashboard, Tenderly’s usage page, or the billing page for other providers. Match your monthly request volume against Chainstack pricing and pick the cheapest plan that covers your volume, or the Unlimited Node add-on if your load is continuous reconciliation traffic. Sign up. Create an account at console.chainstack.com. Apply STABLE50 at checkout for 50% off Growth, first 3 months. Deploy. In the console: Add node → Stable → pick Mainnet (managed Global Nodes) — Testnet is currently available via Self-Hosted only. Dedicated Nodes aren’t supported for Stable yet. For reconciliation and audit-trail work, deploy an archive node; a full node is enough for real-time payment detection and submission. Swap. Copy the HTTPS and WebSocket endpoints from Access and credentials and replace your existing RPC URLs. Keep the old provider live during transition as fallback. Smoke test. Verify chain ID 988, then check both of USDT0’s decimal formats before anything else: formatEther() for the native 18-decimal gas balance, formatUnits(value, 6) for the ERC-20 token. Confirm eth_getLogs against the USDT0 contract picks up a known transfer, and run a debug_traceTransaction on a known transaction if you rely on trace. Monitor. Compare error rates and latency (especially p95/p99, not just average) against your previous provider for the first 24–48 hours. No public benchmark dashboard covers Stable providers yet, so this comparison has to be your own. Cut over. Once verified, remove the old provider from the config and revoke the API keys. Both paths land you in the same place. Pick AI-agent if the codebase is complex or the team is small. Pick manual if you want end-to-end control over the sequence. Deploy and claim your 50% off Promo code: STABLE50 What it covers: 50% off the Growth plan — $49/month standard, $24.50/month for 3 months with the code Included: 20M requests/month, 250 RPS, Full and Archive nodes on Mainnet, WebSocket, debug_* methods Larger workloads: Business, Enterprise, or Dedicated deployments get a sales-led custom deal — contact the Chainstack team directly Two-click redemption: Claim 50% off → — sign up or log in, code applies at checkout Migration guide → — full AI-agent runbook and manual reference Who’s already building on Chainstack for Stable Stable’s provider ecosystem is still forming since its late-2025 launch, but the migration pattern is already visible — tens of teams are running production RPC on Chainstack for Stable today, drawn by the combination of self-serve mainnet archive access, audited compliance, and flat-fee throughput options that the rest of the field doesn’t fully match yet. Chainstack is listed in Stable’s own RPC providers documentation and on the Stable ecosystem page. Start building on Chainstack → FAQs Does migration cause downtime? No. Chainstack endpoints are drop-in replacements for standard Ethereum JSON-RPC over HTTPS and WebSocket. Deploy the new node, verify it responds to your workload, swap the URL, and remove the old one after monitoring for 24–48 hours. Both providers can run in parallel during the transition. Why does my USDT0 balance look a trillion times too big? Because Stable’s native gas token USDT0 carries 18 decimals, while the USDT0 ERC-20 token reports 6 decimals — a 10^12 gap. Use formatEther() for native gas balances and formatUnits(value, 6) for the ERC-20 token. This is the single most common integration bug when migrating to Stable. I’m porting an existing Ethereum backend — what breaks? Three things trip up most migrations: pending-transaction subscriptions return nothing because Stable’s mempool is private and always empty, so inbound-payment detection has to move to eth_subscribe log watching; Parity-style trace_* methods, eth_createAccessList, and eth_simulateV1 all return errors, so tracing has to go through the debug_* namespace instead; and the native gas token’s 18 decimals versus the ERC-20 token’s 6 decimals is an easy place to introduce a silent unit-conversion bug. Am I eligible for the 50% off promo if I’m already on Chainstack? Yes — the promo applies to teams expanding to Stable as well as teams migrating their RPC to Chainstack. Apply STABLE50 when adding Stable nodes to your existing account. Can I self-host Stable nodes instead of using managed? Yes. Chainstack Self-Hosted supports both Stable Mainnet and Stable Testnet on your own infrastructure — the same one-click deployment flow, snapshot bootstrap, self-healing, and observability stack as managed nodes. This is currently the only way to run a Stable Testnet node through Chainstack, since managed Global Nodes support Mainnet only. Which providers meet compliance requirements for regulated stablecoin work? For MiCA or GENIUS Act workloads, insist on an audited SOC 2 Type II report, not a self-reported claim. Chainstack (SOC 2 Type II plus ISO 27001), Tenderly, and Alchemy hold audited certifications among providers supporting Stable today. Chainstack additionally offers self-serve mainnet archive access without an enterprise-gating step. Where can I benchmark Chainstack against my current provider on Stable? No public real-time dashboard covers Stable RPC providers yet. Run your own latency test from your target region — a curl loop or a k6 script hitting eth_blockNumber and eth_getTransactionReceipt against each provider’s endpoint is enough to surface meaningful p95/p99 differences before you commit. Additional resources Build with Stable on Chainstack — product page and discount CTA Chainstack introduces Stable Mainnet support — launch announcement with full coverage details Stable tooling documentation — SDKs, code examples, the decimal trap in detail Stable methods documentation — full JSON-RPC method reference and Stable-specific behavior Migrate to Chainstack with AI — AI-agent migration runbook Chainstack MCP server — full tool reference Chainstack pricing — plans, RU model, calculator Stable testnet faucet — free testnet funds for development #### Monad & Berachain: Blockchain usage weeks after mainnet 2025 saw a range of developments in the blockchain industry, from multiple cryptocurrency price highs and drops, including a Bitcoin all-time high in October 2025, to the popularity of AI agents, prediction markets, and stablecoins. Monad and Berachain were the most prominent blockchain mainnet launches of 2025, each amid different market conditions and during unique developments in blockchain use cases. Berachain launched in early February 2025, during a period of growing institutional and government adoption. Monad launched in late November 2025, as outlined in a previous deep dive, during a weakening on-chain activity and a visible bear market. This article compares the usage levels of Monad and Berachain, examines the potential impacts of their launch strategies and market conditions on their usage, and analyzes how their levels compare to earlier launches of now-mainstream blockchains like Base and Sui. Before mainnet, there was testnet Before launching on the mainnet, both Monad and Berachain launched a testnet, a separate network for testing their respective chains, which were successful enough to propel a mainnet launch The announcements of testnet launches of Monad and Berachain. Source X The usage levels of testnet serve as a baseline for how many users may use the mainnet. Testnet provides developers and users the opportunity to test, experiment with, and validate a version of the network and the applications built on it before the main network releases. Many also make testnet transactions in hopes of being included in an airdrop of the protocol’s cryptocurrency token when mainnet launches. Monad launched testnet on February 9, 2025, nine months before their mainnet launch. Berachain ran its testnet for over a year before launching mainnet in February 2025. Both Monad and Berachain sent an airdrop of their mainnet tokens to testnet users, but did not explicitly state beforehand that they would do so. From February to September 2025, Monad recorded daily transactions ranging from 5 million to 8 million. On October 14, 2025, Monad announced an airdrop to testnet users who used the test before that date. Testnet transaction volume then dramatically increased to 80 million transactions a day, peaking 9 days later at 196 million transactions a day. Eventually, the Monad Foundation chose to airdrop MON, the primary protocol token, to 288,676 testnet users (including developers who deployed on testnet and users who used products deployed there), as well as to community members worldwide. By the time of the mainnet launch, 76,021 users (assuming unique wallet addresses) had claimed 3.33 billion tokens. A breakdown of MON token allocations in the airdrop and the number of tokens claimed by different types of community members or testnet users. Source: Monad Foundation Berachain’s Artio and bArtio testnets are now deprecated, so testnet transaction data is not readily available. A total of 500 million BERA tokens were allocated to the community, including 8.25 million tokens (1.65 percent of all tokens) for testnet users worldwide, excluding the United States. In total, across testnet users and community members, 1,336 users claimed tokens, significantly fewer than in Monad. Testnet users who receive a mainnet airdrop are typically the first users of mainnet, as they are developers with an active product or users of a product that will migrate to mainnet. Generally, we can expect at least 76,021 wallets to trade 3.33 billion MON tokens in the initial days of the Monad mainnet launch, and 1,336 wallets to exchange 500 million BERA tokens during the first days of the Berachain mainnet launch, along with additional on-chain activity from new users and applications built on the chains. A graph comparing the number of users who claimed the respective mainnet airdrop on Monad and Berachain Post-mainnet blockchain usage The first few days of a mainnet launch typically see a lot of activity as testnet users use their newly airdropped tokens and as general market curiosity builds, but maintaining that momentum requires different market and adoption factors. Sui and Base, blockchains that launched mainnet in 2023, two years before Monad and Berachain, saw mixed success after their mainnet went live. Sui Sui, a high-performance Layer-1 blockchain that uses a unique object-centric model to enable parallel transaction processing, reached its daily transaction volume peak in July 2023, two months following its mainnet launch in May 2023. Since reaching a daily peak of 66 million transactions on July 27, 2023, the daily transaction volume has decreased to an average of 1 million, then recovered to an average of 1.5 million, with some spikes in October 2023, April 2024, and October 2024. July 27, 2023, is the day with the highest daily transactions for Sui. Source: insights4vc via Dune Dashboard Decentralized finance (DeFi) fueled the growth spikes in October 2023 and October 2024. Total value locked (TVL), or the total amount of cryptocurrency assets deposited, staked, or “locked” or secured on Sui, peaked in October 2023, rising 341 percent from three months prior. In October 2024, Sui began supporting USDC, a stablecoin pegged to the US dollar and backed by Circle, and Deepbook, a high-throughput, low-latency decentralized exchange with a fully on-chain order book. Though Sui has not seen the same day-to-day transaction levels, its TVL has remained consistent or grown through the two years, indicating that users are still locking their SUI tokens on the chain. TVL of SUI token has remained steady or grown in the last two years. Source: DeFiLama DeFi remains a significant focus, but community efforts also drove growth as they did in April 2024. Move, a programming language for writing smart contracts on Sui, launched in beta and led to major developer events, including the Sui Basecamp Conference and the Sui Overflow Hackathon. As part of these developer events, Sui saw a peak in part-time and one-time developers but struggled to convert them long-term and did not see another increase until June 2025, after Sui Overflow 2025 ended. A graph of active developers using Sui, showing peaks in part-time and one-time developers in April 2024 and June 2025, both during the Sui Overflow Hackathon. Source: Electric Capital Sui has not seen the same usage levels as when it was first launched, but it has experienced growth spikes driven by major DeFi and community efforts, and its TVL has either remained stable or grown. Base Unlike Sui, Base, an Ethereum Layer 2 blockchain built by Coinbase, has seen consistent growth since its mainnet launch. As a Layer 2 scaling solution, Base processes transactions off-chain and then settles or finalizes them on Ethereum, the Layer-1 blockchain on which it runs. In contrast to Sui, Base does not have a native protocol token (It uses the Ethereum (ETH) token on its network), and standard DeFi metrics such as TVL do not apply in the same way. However, Base had an advantage because it attracts already established Ethereum users looking for cheaper, faster Ethereum-compatible solutions. Like Sui, Base also experienced a drop in transaction volume two months after its launch in August 2023. Then, in March 2024, it saw substantial daily transaction growth and continues to reach new peaks. Base also benefited from the growing popularity of DeFi during the period, with its TVL steadily increasing. Base maintained its growth throughout 2024 and 2025 due to its deep integration with its creator, Coinbase, the world’s second-largest centralized exchange. Coinbase actively migrated many functions to Base, including stablecoin exchanges, wallet defaults, and developer tools. The close connection with Coinbase strengthened Base’s trust and led to adoption by other major companies, including payments on Shopify and stablecoin deposits by JPMorgan Chase. Institutional support builds developer trust when selecting Base as the chain for developing a web3 product. A graph of active Base developers, showing consistent growth across all developers. Source: Electric Capital Post-mainnet hype or success? Though Berachain launched this year and Monad a few weeks ago, their growth patterns show similarities but also unique differences, driven by market conditions and launch approaches compared to Base and Sui. Both achieved tremendous initial success, significantly exceeding the number of active addresses compared to the testnet airdrop users and TVL levels. Monad and Berachain had more active addresses during their mainnet launches and in the weeks afterward than during their testnets. MON token was airdropped to 76,021 wallet addresses. At its peak, 149,248 wallet addresses interacted with MON token. Over the past three weeks, an average of 89,414 wallet addresses used the token, surpassing the initial number of wallet addresses included in the airdrop by 17.62 percent. BERA token has also exceeded expectations. BERA token was airdropped to 1,336 wallet addresses. 48,854 wallet addresses interacted with BERA at its peak. Over three weeks, an average of 13,558 addresses used the token, surpassing initial airdrop addresses by 914.82%. Compared to Sui, Monad and Berachain both reached high TVLs much faster, demonstrating a maturity in the DeFi market over the past two years. ChainDays to achieve a $100 million TVLDays to achieve a $200 million TVLSui188 days237 daysMonad2 daysNot yetBerachainFirst dayFirst day Berachain quickly reached a high TVL due to its proof-of-liquidity structure, which strongly incentivizes specific token lockups. They managed to reach and sustain initial transaction volumes and TVL (of BERA tokens) for at least 3 months after the mainnet launch, longer than both Sui and Base.  Since then, their transaction volume and TVL have decreased by 93 percent (from $2.97 billion at their peak to $195 million now) since the first three months of mainnet. A graph showing daily transaction counts on Berachain. Source: Berachain Foundation via Dune Analytics A graph showing the total value locked (TVL) of BERA token. Source: DeFiLama Though there are no definitive reasons explaining the trends, Berachain might have maintained its usage levels for so long as it benefited from the period of strong DeFi interest, as Sui and Base did during the same time period. Researchers infer that expiring token rewards and their proof-of-liquidity structure, which highly reward only certain staking behaviors, not all, discouraged users from holding their tokens on Berachain.  Monad launched only three weeks ago, but has already experienced stable TVL, much like Sui. Though transaction volumes have decreased since its launch last month, the TVL of MON token has remained steady, hovering just below $200 million. Consistent staking rewards encourage users to stake MON tokens in similar amounts, thereby stabilizing TVL. A graph showing the stability of MON token. Source: DeFiLama This chart shows that the staking rewards revenue, or the amount of rewards users earn by staking MON token, has remained steady over the past three weeks, encouraging users to keep their tokens staked. Source: Monad Foundation via Dune Analytics. Monad still achieved a near $200 million TVL much more quickly than Sui, despite not having a liquidity-driven model like Berachain.  One factor is that the MON token also launched on Solana, one of the most popular networks. Unlike the other chains mentioned, MON token transactions can happen on Monad or on Solana. Throughout the three weeks, Solana users accounted for more than ten to fifteen percent of all active MON token holders.  Despite Solana users accounting for a substantial share of MON token holders, this did not translate into strong, sustained growth. The TVL of the MON token on Solana accounts for only 5.1 million, less than 2.5 percent of the total TVL. This confirms data showing that Solana users holding MON tokens are transacting in small amounts, mostly under 1,000 MON (equivalent to less than 20 USD).  Monad has shown mixed initial success, but as exemplified by Base and Sui, it can supercharge its growth through valuable DeFi mechanisms, community efforts, and institutional partnerships. It is relatively early in this process; its ongoing integration snapshot shows new integrations with apps and developer tools that could drive its growth in the next couple of months or years. Conclusion The first few weeks of a mainnet launch do not necessarily determine its long-term success, as shown by TVL metrics for Sui and Base.  All blockchains analyzed, Monad, Berachain, Sui, and Base showed transaction activity growth during the first few weeks of mainnet launch due to initial hype. Though daily transaction activity for Monad, Berachain, and Sui is variable, specific metrics, such as TVL, tend to remain stable as long as staking rewards stay unchanged. The usage level of a blockchain increases with developer activity, DeFi market conditions, and institutional adoption, which build up over time. Base has gained the most trust and prominence among developers and institutions, enabling it to sustain growth since its mainnet launch two years ago. You can get started with Monad, Berachain, Sui, Base, or more than 70+ chains today via Chainstack. Chainstack gives you the performance and consistency required for production systems. Deploy an RPC endpoint in seconds and scale globally with automated orchestration, uptime guarantees, and developer-friendly tooling. Deploy now Resources Monad Mainnet Dashboard (Monad Foundation on Dune Analytics) Berachain Mainnet Dashboard (Berachain Foundation on Dune Analytics) Base Comprehensive Dashboard on Dune Analytics Chain Overview Sui Dashboard on Dune Analytics Helius Data on Monad on Solana SuiVision Statistics DeFiLama on Monad, Berachain, Sui Developer Report by Electric Capital #### Monad for Builders 2026: Practical implementation guide This 2026 guide explains how to analyze Monad’s performance at the block level using Node.js. The process covers fetching recent blocks through a Chainstack RPC, computing execution and fee-related metrics, and exposing the aggregated results through a simple API for downstream consumption. 💡 New to Monad’s architecture? Start with our “Deep dive into Monad: Speed, performance and more” for a complete overview of how it works. ⚡If you are already familiar with Monad and ready to dive into coding, jump to “Build On Monad” section below. 💡 Prefer diving straight into the code?Get the Monad Metrics project on Utkarshini’s GitHub and start extracting block-level metrics instantly:https://github.com/utkarshiniarora/monad-metrics What is Monad? Monad is an Ethereum-compatible Layer 1 blockchain designed to make decentralized applications fast, affordable, and scalable without sacrificing security or decentralization. At its core, Monad focuses on high transaction throughput and scalability. While traditional blockchains process transactions one after another, Monad introduces optimistic Parallel Execution and Deferred Execution, allowing many transactions to run at the same time. This architecture enables Monad to process up to 10,000 transactions per second (TPS) while maintaining near-zero gas fees and low latency. Monad is fully compatible with Ethereum, complying with the Ethereum Virtual Machine (EVM) and the Shanghai fork. This means developers can deploy existing Solidity applications without any modification, instantly benefiting from Monad’s performance improvements. From a developer’s perspective, it feels like Ethereum, but significantly faster and cheaper. Consensus on Monad is powered by MonadBFT, a high-performance Byzantine Fault Tolerant protocol that delivers 1-second single-slot finality. Transactions confirm almost instantly, making Monad ideal for real-time applications, gaming, prediction markets, and consumer-facing use cases where speed matters. To support this performance, Monad uses MonadDB, a database optimized for parallel reads and writes, ensuring the network can scale efficiently as usage grows. Together, optimistic Parallel Execution, MonadBFT, and MonadDB form the backbone that allows Mo.nad to achieve high throughput without compromising on security, scalability, or decentralization. Ultimately, Monad provides the infrastructure developers need to build dApps that can scale to millions of users, offering very high transaction speeds, low fees, and reliable finality. Its growing ecosystem already includes applications across gaming, prediction, and consumer experiences, all benefiting from Monad’s real-time performance capabilities. Why Use Monad? Monad is built to support anyone interacting with high-performance blockchain systems, from developers and founders to teams building infrastructure and consumer-facing applications. It removes the usual tradeoffs of slow execution, high fees, and complex architectural constraints by delivering fast, scalable, and reliable execution at the base layer. Each core component of Monad contributes directly to better performance, predictable behavior, and a smoother experience across the ecosystem. Parallel Execution Most blockchains execute transactions sequentially, which creates congestion as usage grows. Monad uses optimistic parallel execution, allowing multiple non-conflicting transactions to be executed at the same time. This makes it possible for applications to handle large numbers of users interacting simultaneously without delays, making Monad well-suited for high-activity use cases like gaming, trading, and consumer apps. MonadDB MonadDB is a purpose-built database designed to support parallel reads and writes at high throughput. Traditional blockchain storage layers often become a bottleneck when transaction volume increases. With MonadDB, state access remains fast and consistent even under heavy load, enabling real-time updates and predictable application behavior as your user base scales. MonadBFT Consensus MonadBFT is a Byzantine Fault Tolerant consensus mechanism that provides one-second single-slot finality. Once a transaction is confirmed, it is final and cannot be reverted. This results in fast confirmations and strong security guarantees, improving user experience for payments, interactions, and time-sensitive actions without compromising decentralization. Deferred Execution Monad separates transaction ordering from execution through deferred execution. Transactions are first ordered by consensus and then executed afterward in parallel. This model benefits applications that experience bursts of activity or require many users to interact at once, such as games, prediction markets, marketplaces, and consumer apps. Unlike Ethereum, where transactions are ordered and executed sequentially, deferred execution allows Monad to maximize parallelism while still producing deterministic results. The outcome is higher throughput and lower latency without changing the EVM execution model or introducing developer-facing complexity. Shared Mempool Monad uses a shared mempool where validators observe the same set of pending transactions before block production. This design primarily benefits applications sensitive to transaction ordering, such as DeFi protocols and on-chain markets. By reducing inconsistencies in how transactions are seen and ordered across validators, the shared mempool improves execution predictability and reduces edge cases that arise from divergent mempool views. This makes outcomes more consistent compared to Ethereum’s more fragmented mempool environment, especially under high network load. Carriage Cost and Reserve Balance Monad introduces carriage costs and reserve balances to manage how on-chain state is stored and maintained over time. Applications that consume more persistent state account for the long-term resources they use, rather than pushing those costs onto the entire network. For intel, analytics, and real-time metrics platforms, this model is especially important. These systems often track large volumes of state such as historical data, performance metrics, and indexing metadata. Carriage costs make the cost of maintaining this state predictable and proportional, allowing infrastructure-level applications to scale sustainably without relying on unstable transaction fees or aggressive data pruning. In practice, this means this design enables projects building on Monad to treat the blockchain as a reliable, high-throughput data source while keeping fees low for end users. It also sets the foundation for building richer observability layers on top of Monad, where execution performance, network health, and real-time activity can be monitored continuously and at scale. Prerequisites Before starting, make sure you have: Node.js 18+ A Chainstack account Basic understanding of: JavaScript JSON-RPC Familiarity with REST APIs ✅ Verify your Node.js version using node -v. If it’s below 18, update before continuing Build On Monad We will use: Node.js Yarn or npm Express Axios Dotenv React VS Code or your choice of code editor Set Up Monad on Chainstack Head to Chainstack and create a free account After signing up, you will be navigated to https://console.chainstack.com/. This is where you can manage all your nodes across 70+ protocols Click on “Add node.” Choose Monad and then select “Monad Mainnet” in the network section Click “Next” In the next step, select the type of node. For this project, choose “Global Node.” Give your node a name, review all the settings in the summary, and click “Deploy Node.” Once the node is deployed, click “View Node Details”. Scroll down to the “Access and credentials” section. Here you will find the endpoint URL, copy it and keep it safe. It will be needed in the next step. ⚠️ Do not expose your URL. Store it securely in a .env file and add it to your .gitignore before pushing the code to GitHub. Consider using password-protected endpoints to enhance security. Set Up Environment Create a new project folder: mkdir monad-metrics cd monad-metrics npm init -y Install dependencies: npm install express cors ethers axios dotenv Create an .env file with the following keys: CHAINSTACK_URL=<Your-Chainstack-Endpoint-URL> TOKEN_ID=<Token-Symbol> BLOCK_SAMPLE=<Number-Of-Blocks> CHAINSTACK_URL: The RPC endpoint URL obtained from Chainstack when the Monad node was deployed TOKEN_ID: The symbol of the token whose price you want to track (for example, MONAD). BLOCK_SAMPLE: Number of recent blocks to analyze Create the RPC Provider All network data in this project is fetched directly from a Monad JSON-RPC endpoint. To keep the setup simple and predictable, create a standard ethers.js provider that acts as the single access point for all on-chain reads. Create a file provider.js import { ethers } from "ethers"; export function createProvider(rpcUrl) { const provider = new ethers.JsonRpcProvider(rpcUrl); return provider; } Fetch Block Data The core of the system samples the latest N blocks and computes averages across them. const latestBlock =await provider.getBlockNumber(); const blocks = []; for (let i = latestBlock; i > latestBlock -BLOCK_SAMPLE; i--) { const block =await provider.getBlock(i,true); blocks.push(block); } Each block includes: Timestamp Transactions Gas used Gas limit Base fee (if present) This raw data becomes the foundation for every metric. Compute Metrics Block Time const blockTimes = []; for (let i =1; i < blocks.length; i++) { blockTimes.push(blocks[i -1].timestamp - blocks[i].timestamp); } const avgBlockTime = blockTimes.reduce((a, b) => a + b,0) / blockTimes.length; This gives a real observed block time. Transactions and TPS const txCounts = blocks.map(b => b.transactions.length); const avgTxPerBlock = txCounts.reduce((a, b) => a + b,0) / txCounts.length; constTPS = avgTxPerBlock / avgBlockTime; You also track: const largestBlockTxs =Math.max(...txCounts); This helps identify bursty activity. Gas Usage and Fees const gasUsedArr = blocks.map(b =>Number(b.gasUsed)); const totalTxs = txCounts.reduce((a, b) => a + b,0); const avgGasUsedPerTx = gasUsedArr.reduce((a, b) => a + b,0) / totalTxs; Gas price comes directly from the node: const feeData =await provider.getFeeData(); const gasPriceWei = feeData.gasPrice ??0n; Add Token Price and USD Fee Flow Fetch live token price using CoinGecko: exportasyncfunctionfetchTokenPriceUSD(tokenId) { const { data } =await axios.get( "<https://api.coingecko.com/api/v3/simple/price>", { params: { ids: tokenId, vs_currencies:"usd", }, } ); return data[tokenId]?.usd ??null; } Compute USD metrics: const avgTxCostUSD = tokenPriceUSD ? (Number(gasPriceWei) * avgGasUsedPerTx /1e18) * tokenPriceUSD :null; const feeFlowUSDPerSecond = avgTxCostUSD ? avgTxCostUSD *TPS :null; This answers a critical question: How much value flows through Monad every second? Block Utilization const utilization = blocks.map( b =>Number(b.gasUsed) /Number(b.gasLimit) ); const blockUtilization = ( utilization.reduce((a, b) => a + b,0) / utilization.length * 100 ).toFixed(2) +"%"; High utilization can indicate congestion or demand spikes. Expose Metrics via Express API Finally, serve everything through an API. app.get("/metrics",async (req, res) => { try { console.log("\\n--- Fetching Monad Metrics ---"); const data =awaitgetMetrics(provider); res.json(data); }catch (err) { res.status(500).json({error:"Failed to fetch metrics" }); } }); Run the server: node index.js Your API is now live at: <http://localhost:3001/metrics> The result would look something like this: Consume the Metrics API Once the backend is running, the /metrics endpoint can be consumed by any frontend framework. Since the API returns plain JSON, it works equally well with React, Next.js, Vue, or simple static dashboards. Example: This approach keeps the frontend lightweight. All heavy computation happens server-side, while the UI focuses purely on visualization. Because the API exposes already-aggregated values, the frontend does not need to understand block structure, gas mechanics, or RPC calls. It simply consumes clean, ready-to-use metrics that reflect the current state of the Monad network. Considerations RPC Usage and Sampling Strategy Running a reliable RPC endpoint is essential when working with live network telemetry. Metrics like block time, TPS, and gas usage depend entirely on how fresh and consistent the underlying node data is. Using a managed RPC provider such as Chainstack simplifies this by allowing you to deploy and access fully managed nodes in minutes, ensuring consistent access to Monad’s latest blocks and RPC methods without maintaining your own infrastructure. Keep BLOCK_SAMPLE conservative to balance freshness with request volume. For most real-time use cases, sampling the latest 20–30 blocks over a Chainstack global node provides stable results without unnecessary overhead. Sequential Block Fetching Blocks are fetched sequentially in descending order. This keeps the logic easy to reason about but is not optimal for higher throughput. If you plan to increase sampling depth or refresh frequency, batching requests or parallelizing block fetches can significantly reduce latency. Gas and Fee Accuracy Gas price and base fee values reflect the current network state, not historical averages. During volatile periods, short sampling windows may exaggerate spikes or dips. If you need more stable metrics, introduce weighted averages or longer windows at the cost of responsiveness. USD Conversions Transaction cost and fee flow calculations depend on external price data. If the price API is unavailable or delayed, USD-denominated metrics gracefully return null. For production systems, caching prices or updating them on a fixed interval is recommended. Summary Monad demonstrates how a high-performance, Ethereum-compatible blockchain can remain scalable, fast, and developer-friendly. By combining Parallel Execution, Deferred Execution, MonadBFT consensus, and a purpose-built MonadDB, developers can access real-time block-level metrics without compromising security or decentralization. Looking ahead, Monad empowers developers to: Build scalable dApps that handle high user activity and network throughput. Monitor execution, gas, and fee metrics in real time through simple APIs. Leverage predictable state costs with carriage and reserve balance mechanisms. Running your own Monad node ensures reliable access to live block data. Chainstack simplifies this by letting you deploy fully managed Monad nodes in minutes, providing stable RPC access and the latest network state. Monad is scaling with speed, reliability, and developer-first infrastructure. Reliable Monad RPC provider for production Looking for a reliable Monad RPC provider for production use in 2026?Chainstack provides low-latency, globally distributed Monad RPC infrastructure built for trading, gaming, and stablecoin-powered applications, from development to high-throughput production. With dedicated nodes, high availability, and enterprise-grade security, Chainstack helps teams build, scale, and operate Monad applications without managing infrastructure. Chainstack as a Monad RPC provider Low-latency Monad RPC endpoints powered by global infrastructure Dedicated and global nodes for mainnet and testnets High 99.99% uptime and consistent performance under real-world load Secure access with API keys and role-based permissions Fast setup — deploy a Monad node in minutes Start building on Monad today Start for free, connect your application to a reliable Monad RPC endpoint, and scale with dedicated nodes built for production performance – one of the best RPC providers. Deploy Monad node now #### Moralis and Chainstack announce a partnership to accelerate Web3 development We at Chainstack are happy to announce a partnership with Moralis, the Web3 development platform Chainstack and Moralis are now joining forces in a partnership to further Web3 development! Specifically,  this partnership will see Chainstack provide Moralis project builders and Web3 developers with powerful blockchain node infrastructure and node APIs capable of handling high throughput and scale while Moralis will continue to provide best-in-class blockchain development tools, software and comprehensive DApp development solutions. Moralis and Chainstack complement each other perfectly, as both companies are passionate about lowering the barriers to Web3 and blockchain development. While on hand, Chainstack provides high-performance and accessible “nodeless” deployment of infrastructure, Moralis will be ready to pick things up on the other end and transform it into a powerful “codeless” database. In doing so, this partnership achieves its goal to accelerate mainstream Web3 adoption. By pairing Chainstack’s top-class node APIs with Moralis’ flexible database implementation, we are able to help serve the Web3 industry in the best way possible, push the industry forward, and ensure developers get access to what they need to scale their efforts. What is Moralis? Moralis is a powerful Web3 platform that enables you to build sophisticated DApps with just a few lines of code. It is a fully managed and infinitely scalable Web3 development platform that helps you launch Web3 projects in minutes or hours, rather than weeks and months. A significant part of Moralis’ charm is the platform’s accessibility. As a developer, this means you get the chance to focus more on creating exceptional Web3 experiences with just a few snippets of code. No more wasting time reinventing the blockchain wheel, when you can be creating more value, doing something else. In short, Moralis allows you to easily build and scale Web3 projects without any of the extra complexity that usually comes with it. Whether you’re looking to build NFT projects like your own NFT marketplace, put together the next groundbreaking DeFi protocol, or simply have some fun with a GameFi project, Moralis is there to greet you with open arms. Where does Chainstack come into play? Chainstack is a platform that enables developers to quickly deploy and synchronize nodes, with predictable pricing, high automation, and enterprise-grade infrastructure. This provides an opportunity for Web3 and DeFi developers to build high-performing projects on any of the supported blockchain protocols, with the assurance that the infrastructure can be relied upon regardless of cloud network or location. This is absolutely essential for the successful implementation of Moralis’ backend suite, which is what makes this partnership especially impactful. Having access to a powerful and easily deployable infrastructure directly translates into satisfied customers. Simply put, this ensures that any deployment of Moralis’ suite will run smoothly and without any interruptions, anywhere on the globe. But we are not stopping there. To further facilitate the cooperation, Chainstack will be extending support to Moralis’ users with a dedicated support channel on Discord. Additionally, we will be pooling more product and engineering resources towards integrating both services and platforms in providing the most comprehensive solution for our customers. In doing so, we make sure developers get the best synergy from both offerings but also priceless assistance in setting everything up. Being able to help developers be more successful in their initiatives is always a thrilling experience for us. It is no coincidence that this was one of the reasons for starting our journey and Moralis is the perfect partner to join us in building towards a better Web3 tomorrow.Eugene Aseev, CTO & Founder, Chainstack How will the partnership between Chainstack and Moralis accelerate Web3 development? Chainstack and Moralis are truly a match made in heaven. Not only do we both share an utmost dedication and boundless passion for the development of the Web3 landscape but so do our core offerings complete each other, when paired together: From idea to market, faster than ever before: Chainstack’s managed blockchain services platform made its mark across the Web3 space by creating an accessible way for developers and enterprises to launch and scale decentralized applications. By working together with Moralis, we can further amplify each other’s efforts in this direction, effectively putting the go-to-market time for projects into overdrive. With Chainstack taking care of swift and accessible node deployment and Moralis’ flexible database implementation, this means less time wasted on unnecessary heavy-lifting and more capital being liberated to create extraordinary Web3 experiences. Affordable and accessible development: And speaking of resource deliverance brings us to the next avenue of our collaboration. In our mission to create a better environment for blockchain developers, Chainstack and Moralis will share complementing efforts in advancing accessibility initiatives across Web3. Doing so directly translates into the ever more flexible and modular services that let you set the priorities for deployment. No more hidden costs, forced overcharges, and paying for services you hardly use. You are in complete control of your project’s spending. Just how it was always meant to be. Robust infrastructure with powerful features: The pièce de resistance. This is where Chainstack and Moralis’ synergy truly reaches its pinnacle. With a reliable and robust infrastructure partner by their side, Moralis can easily execute their flexible backend implementations. And best of all, using the high-performance enterprise-grade node APIs Chainstack is known for, means that they can effectively work with clients with even the strictest of requirements, regardless of their size and location. Bigger, faster, stronger in both infrastructure and the powerful feature sets that make it truly worthwhile. An allied campaign to deliver the tools of tomorrow, built solely with the developers in mind, as a richly deserved token of appreciation for moving the Web3 space forward. We couldn’t be more pleased with Moralis’ partnership with Chainstack. Our collaboration will greatly accelerate Web3 adoption and will give developers access to the very best tools in Web3. This partnership will help both those building Web3 projects and the industry as a whole.Ivan on Tech, CEO of Moralis Web3 adoption is set to receive a significant boost thanks to the Chainstack partnership with Moralis. In doing so, we will be able to serve the Web3 landscape in the best way possible, push the industry forward, and ensure its builders get access to the top-performing tools the current technology can offer. Simply put, Chainstack and Moralis will create the easiest and fastest way from idea to market in the blockchain development landscape. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Most cost-effective Hyperliquid RPC providers in 2026 Hyperliquid is a high-performance perps and spot trading L1 with two layers developers actually query: HyperEVM, its EVM-compatible smart contract execution layer, and HyperCore, the native order-book and matching engine. The chain is not slowing down — it currently holds roughly $6.0 billion in TVL and settled $6.1 billion in perps volume in the trailing 24 hours alone. 2026 is the year the Hyperliquid RPC market actually became a market: Quicknode shipped a HyperCore public beta in January 2026 exposing all seven HyperCore data streams over gRPC, Streams, JSON-RPC, and WebSocket, and multiple aggregators now route Hyperliquid traffic behind a single API. The catch: pricing models diverge sharply enough that the sticker price rarely matches the real bill — method-weighted credit and compute-unit billing can push the effective cost of archive reads or high-frequency polling several multiples above a flat-rate alternative. This guide compares the six providers worth evaluating for Hyperliquid RPC in 2026, with the actual cost math laid out per method rather than left to marketing pages. 💡 Already using Chainstack? Jump straight to the Hyperliquid tooling docs or deploy your endpoint in minutes. Why RPC provider choice matters for Hyperliquid Hyperliquid’s dual-layer design means a provider that’s strong on HyperEVM isn’t automatically strong on HyperCore, and vice versa. Reading order-book depth, fills, and funding rates from HyperCore is a different API surface than calling a smart contract on HyperEVM — some providers cover both, several cover HyperEVM only, and that split matters more here than on a single-layer chain. Add in how differently providers price the same call, and the true cost of running a Hyperliquid integration can look nothing like the advertised rate. The criteria below separate a production-grade Hyperliquid endpoint from one that will surprise you on the invoice or under load. Cost predictability and pricing model — flat request-unit pricing (Chainstack) versus method-weighted compute units or credits (Alchemy, Quicknode, HypeRPC). A workload heavy in HyperCore market-data polling or historical reads pays very differently depending on which model it lands on. HyperEVM vs HyperCore coverage — confirm whether a provider actually exposes HyperCore data (order book, fills, funding) or only HyperEVM’s EVM-compatible execution layer. This is the single most consequential Hyperliquid-specific gap between providers. Throughput stability under load — RPS ceilings and how they hold up during volatility spikes, when trading bots and market makers poll hardest. Archive and historical data access — depth and per-request cost of historical HyperEVM state reads, needed for analytics, backfills, and reconciliation. Free-tier reality — a permanent standalone plan (Chainstack, Alchemy) versus a time-limited trial that deactivates afterward (Quicknode’s is 30 days). This matters for prototyping before committing to a subscription. Support quality and responsiveness — a community channel with engineers actually answering on the free tier versus docs-only, and what response-time commitment paid tiers add. SLA and compliance — published uptime guarantee, SOC 2 Type II and ISO 27001 for teams that need audited attestation, not self-reported claims. The table below summarizes public positioning as of August 2026. ProviderPricing modelFree tierDedicated nodesHyperEVM / HyperCoreSOC 2 / ISO 27001 ChainstackFlat 1 RU/call (2 RU archive)Permanent — 3M RU/mo, 25 RPS, no card requiredYes, from $810/mo (testnet); mainnet from $1,475/moBothYes / Yes RouteMeshPer-request, by key/chain/methodFree community endpoint (reads)No (routing layer)HyperEVMNot published UniblockUnified pricing across 300+ chainsFree tier availableNo (routing layer)HyperEVM (routes to Alchemy, GoldRush, Dwellir, Chainstack)Not published HypeRPCCompute units — $0.50/M CU (EU), $0.75/M CU (JP)Starter — 10K requests/mo, 5 RPSYesBothNot published AlchemyCompute units (method-weighted)PermanentNo standard dedicated tierHyperEVM onlyYes / Not published QuicknodeCredits (20 credits/info-endpoint call)30-day trial onlyYes — Hybrid DedicatedBoth, all 7 HyperCore streamsYes / Yes Key takeaways from the comparison: Chainstack offers the only permanent free plan with flat, predictable pricing and full SOC 2 Type II and ISO 27001 certification RouteMesh and Uniblock route across multiple upstream providers rather than running their own nodes — useful for teams that want automatic failover without managing several provider relationships HypeRPC is the only Hyperliquid-exclusive specialist here, covering both HyperEVM and HyperCore with dedicated infrastructure Alchemy covers HyperEVM only — no HyperCore data — but has the most mature general-purpose EVM tooling Quicknode is the most complete on raw feature coverage (all seven HyperCore streams) but has no permanent free tier and credit-weighted billing How to choose a Hyperliquid RPC provider 1. Pricing model — flat vs weighted, and what that means at scale Chainstack bills every Hyperliquid call at a flat 1 RU (2 RU for archive reads). Alchemy, Quicknode, and HypeRPC weight by method — a HyperCore info-endpoint call costs Quicknode 20 credits, while a heavier HyperEVM read like eth_getLogs costs roughly 60 compute units on Alchemy versus roughly 10 for a simple eth_blockNumber call. The formula for comparing them: true cost per call = (method’s CU/credit weight × price per unit) ÷ total units in your plan — multiply by monthly call volume for the real bill. Run your own numbers through the Chainstack cost calculator rather than trusting a headline rate. ProviderUnit weight (info/read call)Effective shape at volume Chainstack1 RU flatPredictable — every call costs the same regardless of method HypeRPCVariable CU by call complexity$0.50–$0.75 per million CU overage, region-dependent Quicknode20 credits (info endpoint)Heavier for market-data polling than a flat-rate model Alchemy~10–60 CU depending on methodArchive/log-heavy calls cost multiples of a simple read 2. Latency consistency vs. average latency For trading bots and market makers, tail latency matters more than the advertised average. A provider that’s fast most of the time but spikes during volatility — exactly when Hyperliquid sees its heaviest order flow — will cost more in missed fills than a slightly slower but consistent one. Check compare.chainstack.com for a live, continuously-updated ranking across tracked chains including Hyperliquid, and benchmark p95/p99 response times against your own target region before committing. 3. Archive and historical data access Analytics, reconciliation, and backfill workloads live on archive access. Confirm depth (how far back), method coverage, and per-request cost before assuming a provider’s archive tier covers your use case — Chainstack prices archive reads at 2 RU versus 1 RU for standard calls, a fixed and known multiplier rather than a variable one. 4. Free-tier reality Chainstack and Alchemy run permanent free plans with no card required. HypeRPC’s Starter tier (10K requests/month, 5 RPS) is also standalone. Quicknode’s entry point is explicitly a 30-day trial, not a permanent tier — fine for a quick prototype, less so for an evaluation that runs longer than a month. 5. When dedicated infrastructure matters Shared endpoints stop being enough once you hit sustained load above the free-tier RPS ceiling, need isolated infrastructure for compliance reasons, or require guaranteed throughput during volatility spikes when every other bot on a shared endpoint is polling just as hard. Dedicated Nodes for Hyperliquid start from $810/month (testnet), scaling to $1,475/month for mainnet archive and $2,037/month for mainnet full nodes; HypeRPC and Quicknode’s Hybrid Dedicated also offer isolated tiers. 6. HyperEVM vs HyperCore coverage This is the criterion unique to Hyperliquid. If your workload only touches smart contracts, HyperEVM-only coverage (Alchemy) is fine. If you need order-book depth, fills, or funding data, you need a provider that exposes HyperCore specifically — Chainstack, HypeRPC, and Quicknode all do; RouteMesh and Uniblock currently route HyperEVM traffic only. 7. Support quality — tiered, not “SLA yes/no” Chainstack runs community support (Discord and Telegram with engineers active in-channel) on the free Developer plan, standard email response from Growth ($49/mo), and 24/7 Enterprise support with fast SLA-backed response on Enterprise. Verify each competitor’s current tier names and response commitments directly — support-tier structures change more often than headline pricing. Choose the right Hyperliquid RPC provider by use case For cost-conscious teams and early-stage builders Early-stage teams need a free tier that doesn’t expire and a pricing model that stays predictable as usage grows from zero to production. A time-limited trial forces a pricing decision before you have real usage data to base it on. Chainstack’s permanent Developer plan (3M RU/month, no card) and flat per-call billing make it the easiest to model early and the cheapest to scale without a pricing-model migration later. HypeRPC’s free Starter tier is a reasonable second option if you specifically need HyperCore data from day one. Explore cost-effective infrastructure on Chainstack → For trading bots and market makers Trading infrastructure on Hyperliquid needs both layers — HyperCore for order-book state and fills, HyperEVM for any on-chain settlement logic — with throughput that holds up specifically during the volatility spikes when order flow is heaviest and every competing bot is polling the same endpoint just as hard. Chainstack, HypeRPC, and Quicknode all expose HyperCore alongside HyperEVM. Quicknode’s all-seven-stream gRPC coverage is the most complete on paper; HypeRPC is purpose-built for exactly this workload; Chainstack’s flat pricing keeps the bill predictable even as polling volume climbs during high-volatility periods. Explore trading infrastructure on Chainstack → For regulated and enterprise deployments High-frequency trading and market-making desks that touch Hyperliquid at institutional volume carry compliance obligations most of the providers in this comparison don’t publicly address. Audited certifications, not self-reported security claims, are what a vendor-risk review actually asks for. Chainstack and Quicknode are the only two providers here with both SOC 2 Type II and ISO 27001 published. HypeRPC, RouteMesh, and Uniblock do not publish either — a real gap worth naming honestly rather than assuming coverage that isn’t documented. Explore enterprise infrastructure on Chainstack → Provider-by-provider breakdown Chainstack Chainstack runs Hyperliquid RPC infrastructure covering both HyperEVM and HyperCore, billed at a flat 1 RU per call (2 RU for archive reads) regardless of method — the same predictable model across all 70+ chains Chainstack supports, not a Hyperliquid-specific exception. The free Developer plan includes 3M RU/month at 25 RPS with no card required, scaling through Growth ($49/mo, 20M RU, 250 RPS), Pro ($199/mo, 80M RU, 400 RPS), Business ($499/mo, 200M RU, 600 RPS), up to Enterprise (from $990/mo). Dedicated Nodes for Hyperliquid start from $810/month for isolated, unmetered access on testnet, scaling to $1,475–$2,037/month for mainnet. Chainstack also holds SOC 2 Type II and ISO 27001 certification, and a Hyperliquid testnet faucet is available for development. Limitations: Dedicated Nodes for Hyperliquid sit at a higher entry price ($810/mo testnet, $1,475+/mo mainnet) than the generic Dedicated Nodes baseline on other chains, reflecting the chain’s own infrastructure requirements — worth budgeting for if you know you’ll need isolation early. Fit by workload: Cost-conscious teams: Excellent — the only permanent free tier with flat billing across HyperEVM and HyperCore alike. Trading bots: Strong — predictable costs even as polling volume spikes during volatility, though Dedicated Nodes are worth evaluating for latency-critical desks. Regulated deployments: Excellent — dual certification and a real SLA give compliance teams something to actually cite. RouteMesh RouteMesh is an RPC aggregation and routing layer rather than a node operator — it routes requests across 10-14 upstream providers per method, including Chainstack, with real-time health scoring and automatic failover. RouteMesh confirms full support for Hyperliquid’s HyperEVM (chain ID 999) among its 1000+ supported chains, with a free community endpoint at lb.routeme.sh/rpc/evm/999. Pricing is split between the free community endpoint (read requests) and a premium tier priced per request by key type, chain, and method. For teams that want automatic failover across many upstream operators without managing separate provider relationships, that’s the pitch. Limitations: HyperEVM only — no HyperCore market-data routing currently. No formal SLA; archive depth depends on whichever upstream serves a given request rather than being something you configure directly. Fit by workload: Cost-conscious teams: Good — a free community endpoint covers basic HyperEVM reads. Trading bots: Moderate — no HyperCore coverage limits it to the EVM side of a trading stack. Regulated deployments: Limited — no published compliance certifications. Uniblock Uniblock is a unified RPC aggregation platform rather than a node operator — it routes requests to upstream providers behind a single API and a single invoice across 300+ chains, including Hyperliquid. Its own documentation names the specific upstream mix for Hyperliquid: traffic routes across Alchemy, GoldRush, Dwellir, and Chainstack — a real, citable detail rather than a generic aggregation claim. For teams juggling multiple chains, the value is consolidation: one API shape and one bill instead of separate integrations per provider, plus higher-level Unified APIs (token, NFT, market data) layered on top of raw RPC. Limitations: Uniblock is not a Hyperliquid-specific infrastructure provider — since it routes to Alchemy for the underlying HyperEVM data, it inherits Alchemy’s HyperEVM-only scope for this chain. No published compliance certifications. Fit by workload: Cost-conscious teams: Good — pooled rate-limit headroom across several upstream providers on one bill. Trading bots: Moderate — HyperEVM coverage only, same ceiling as its upstream providers. Regulated deployments: Limited — no published compliance certifications of its own. HypeRPC HypeRPC, built by Imperator, describes itself as the first dedicated RPC provider for Hyperliquid — shared and dedicated nodes covering both HyperEVM and HyperCore, direct sentry peering with sub-500-microsecond validator connections, and orderbook WebSocket access up to 100 levels of depth. HypeRPC was acquired by Hyperdash in 2026 — pricing below reflects the pre-acquisition public rate card and should be verified directly before committing, since the acquisition may change plans or branding. Pricing ran on compute units: a free Starter tier (10K requests/month, 5 RPS) for testing, a Professional tier at $99/month (1M requests, 50 RPS), and CU overage at $0.50 per million in the EU region or $0.75 per million in JP. Limitations: No SOC 2 or ISO 27001 published — a real gap for institutional buyers. Being Hyperliquid-only means no multi-chain fallback if you also need coverage elsewhere. Fit by workload: Cost-conscious teams: Good — a real free tier, though it’s the smallest here (10K requests/month). Trading bots: Excellent — direct sentry peering and deep orderbook access are built for exactly this workload. Regulated deployments: Limited — no audited certifications to point a compliance review at. Alchemy Alchemy’s Hyperliquid support is HyperEVM-only — no HyperCore query routing or dedicated HyperCore infrastructure. For teams building EVM-native contracts and DeFi protocols on HyperEVM specifically, Alchemy’s mature general-purpose tooling (per-method analytics, request tracing) is a familiar option if you already run other chains through it. Pricing runs on compute units, method-weighted — a simple read like eth_blockNumber costs around 10 CU, while eth_getLogs runs closer to 60 CU. The free tier is permanent, a genuine positive next to Quicknode’s trial-only entry point. Limitations: No HyperCore access at all rules it out for any workload touching order-book data. No standard dedicated node tier. Alchemy’s per-CU pricing is one of the pricier options in this comparison at meaningful production volume — worth running your own numbers through a cost calculator before committing. Fit by workload: Cost-conscious teams: Moderate — permanent free tier, but CU costs climb fast on heavier methods. Trading bots: Limited — no HyperCore means no order-book or fills data at all. Regulated deployments: Moderate — SOC 2 Type II published, ISO 27001 is not. Quicknode Quicknode is the most feature-complete provider in this comparison for Hyperliquid specifically — its January 2026 HyperCore public beta exposes all seven HyperCore data streams through gRPC, Streams, JSON-RPC, and WebSocket from a single endpoint that also serves HyperEVM. For teams that want every available data surface from one provider, that’s a real advantage. Billing is credit-based: all supported /info endpoint methods cost 20 credits per request, and gRPC streaming bills at 10 credits per 0.1 MB of filtered data. Paid plans run from $49/month up to $999/month for the highest non-custom tier. Limitations: No permanent free tier — the entry point is a 30-day trial, not a standalone plan. Method-weighted credit billing can surprise teams once HyperCore streaming or heavy market-data polling enters the mix — worth modeling before committing to a tier. Fit by workload: Cost-conscious teams: Limited — no permanent free plan to prototype against. Trading bots: Excellent — the only provider here with all seven HyperCore streams over gRPC. Regulated deployments: Strong — both SOC 2 Type II and ISO 27001 published. Getting started with Hyperliquid on Chainstack Deploy a production Hyperliquid endpoint in a few steps and build better with Hyperliquid on Chainstack: Log in to the Chainstack console (or create an account). Create a new project Select Hyperliquid as your blockchain protocol Choose network: Hyperliquid Mainnet or Testnet Deploy the node Open Access and credentials and copy your HTTPS and WebSocket endpoints For latency-critical trading workloads, evaluate Dedicated Nodes after the initial deploy — available inside the same project. import { InfoClient, HttpTransport } from "@nktkas/hyperliquid"; const transport = new HttpTransport({ url: "YOUR_CHAINSTACK_ENDPOINT" }); const info = new InfoClient({ transport }); // Fetch current mid prices for all markets on HyperCore const mids = await info.allMids(); console.log(mids); 📖 For the full integration guide, see the Chainstack Hyperliquid tooling documentation. Need testnet funds? Grab some from the Chainstack Hyperliquid faucet. 🤖 You can also access Chainstack Hyperliquid RPC directly from Claude, Cursor, Codex, Windsurf, Gemini CLI, GitHub Copilot, Antigravity, Claude.ai, or ChatGPT using Chainstack MCP. For a fuller agent stack, see the Chainstack Agents page. Conclusion The Hyperliquid RPC market split cleanly in 2026 along two axes: whether a provider covers HyperCore alongside HyperEVM, and whether its pricing stays flat as usage grows or weights by method. Those two questions, more than brand recognition, decide which provider actually fits a given workload. Cost-conscious teams and prototypes → Chainstack’s permanent free tier and flat billing Trading bots and market makers needing full HyperCore depth → Quicknode or HypeRPC Regulated or institutional deployments → Chainstack or Quicknode, the only two with published SOC 2 Type II HyperEVM-only DeFi and contract workloads → Alchemy, if already standardized on it for other chains Deploy your Hyperliquid RPC endpoint on Chainstack → FAQ Q: What’s the difference between HyperEVM and HyperCore RPC access? HyperEVM is Hyperliquid’s EVM-compatible smart contract layer — standard eth_* JSON-RPC methods apply. HyperCore is the native order-book and matching engine, queried through a separate /info API for market data, fills, and funding rates. Some providers (Alchemy) cover HyperEVM only; others (Chainstack, HypeRPC, Quicknode) cover both. Q: Which Hyperliquid RPC provider has the best free tier? Chainstack’s Developer plan is the largest permanent free tier (3M RU/month, 25 RPS, no card required) and covers both HyperEVM and HyperCore. HypeRPC’s free Starter tier is smaller (10K requests/month) but Hyperliquid-specific. Quicknode’s entry point is a 30-day trial, not a permanent free plan. Q: How do I migrate from a public Hyperliquid RPC endpoint to a managed provider? Deploy a node with your chosen provider, copy the new HTTPS/WebSocket endpoint, and swap it into your existing SDK configuration — the API surface is the same. Test against testnet first using the Chainstack Hyperliquid faucet before cutting over production traffic. Q: What latency should I expect from a Hyperliquid RPC provider? This varies by region and provider, and averages hide the tail latency that matters most for trading. Check compare.chainstack.com for live rankings, and benchmark p95/p99 response times from your own target region rather than relying on a single average figure. Q: Do Hyperliquid RPC providers publish security certifications? Chainstack and Quicknode both publish SOC 2 Type II and ISO 27001. Alchemy publishes SOC 2 Type II but not ISO 27001. HypeRPC, RouteMesh, and Uniblock do not publish either certification. Q: Is flat-rate or credit-based pricing cheaper for Hyperliquid RPC? It depends on your method mix. Flat-rate billing (Chainstack) is more predictable and often cheaper for archive-heavy or high-volume polling workloads, since method-weighted models (Alchemy, Quicknode, HypeRPC) charge multiples of a base rate for heavier calls. Run your actual call mix through the Chainstack cost calculator to see the real number for your workload. Additional resources Hyperliquid tooling documentation — Chainstack Docs Hyperliquid available methods — Chainstack Docs Hyperliquid API reference overview — Chainstack Docs Hyperliquid official documentation More Hyperliquid articles on the Chainstack Blog Chainstack pricing #### Multi-chain: The money on the table Multi-chain value locked If you check the top 10 chains for the total value locked (TVL) at Defi Llama, you will see that seven of them are EVM-based, one is EVM-compatible, and two are non-EVM architecture. A snapshot of the top 10 at the time of this post: ProtocolTVLArchitectureEthereum$145.74BEVM-basedTerra (LUNA)$17.14Bnon-EVMBinance Smart Chain (BNB)$14.91BEVM-basedAvalanche (AVAX)$11.08BEVM-basedSolana (SOL)$9.57Bnon-EVMFantom (FTM)$5.76BEVM-basedPolygon (MATIC)$5.33BEVM-basedTron (TRON)$4.71BEVM-basedCronos (CRO)$1.84BEVM-basedAribitrum$1.83BEVM-compatible The Ethereum innovation—both the technology and everything on the smart contract level running on the network—is responsible for roughly 87% of the top 10 value locked. Everything about the top 10 is impressive. The sheer amount of the value locked is impressive. The Ethereum dominance at 66% is impressive. The two non-EVM networks earning their spot is impressive. Each of the EVM networks making it to the top 10 and securely locking as much value as they do (billions) is impressive. Multi-chain user experience The Ethereum network effect is the largest in the blockchain space, and the EVM space is inevitably the most crowded one. You can’t hook up your MetaMask instance to Terra, Solana, or Tron, but you can hook it up to each of the other seven protocols in the list. If you check Chainlist, you’ll get an impressive view of 296 EVM networks that you can connect to in a couple of clicks. Each of the top 10 networks has at least one DEX, and most of them have the word “swap” in their names. And the interface is always instantly recognizable. If you put your Ethereum address in the Blockscan search field, you will see your digital assets across all the EVM chains supported by the team behind Etherscan. And you can also easily traverse all the 10 networks with your digital asset through cross-chain bridges—mostly through Ethereum. The point is, your blockchain and Web3 experience is getting more unified by the day. That’s the user experience. Multi-chain blockchain developer data and experience backed by Chainstack numbers Quick highlights: 10% of all registered customers run more than one node.Half of those running more than one node are multi-chain—running two and more different protocols.If you are originally an Ethereum developer or entrepreneur, you are more open to the idea of multi-chain than if you come from a different protocol originally. As a developer (and entrepreneur), building a Web3 DApp and launching it on just one network may often be the case of leaving the money on the table. The user base is there for you, spilling over to other protocols due to the original Ethereum network effect and the overall experience unification. Simplistically speaking, all you have to do is swap the node endpoint in your DApp, and you are on a different network exposed to a new base of users and digital assets. The multi-chain world has more points to converge than to move in different directions—it’s more uni than multi, really. With the relatively rich data on the nodes deployed that we have here at Chainstack, let’s have a quick glance at what the developers and entrepreneurs are doing. A quick note on Avalanche — at the time of preparing this article, Avalanche is a recent addition on Chainstack, hence the relatively low numbers. 10% of all users need more than one node — Roughly 10% of all registered customers currently active on Chainstack are running more than one node. 52% of the registered customers running more than one node are multi-chain — Of those 10% running more than one node, a bit more than half (52%+) run multi-chain—they run nodes from at least two protocols (all the way to running all 6 public smart contract protocols supported by Chainstack). Binance Smart Chain dominates the overall EVM need — Of all EVM users running more than one node, Binance Smart Chain is responsible for the top 35%. Full distribution (overall):Percentage of protocol nodes for the registered customers running more than one node ProtocolPercentageBinance Smart Chain35%Ethereum30.2%Polygon27.2%Fantom5%Avalanche2.6% Ethereum dominates the EVM multi-chain — Of all EVM users running more than one node, Ethereum is responsible for the top 35%. If you are originally an Ethereum developer, you are more likely to go multi-chain than with any other protocol. Full distribution (multi-chain):Percentage of protocol nodes for the registered customers running more than one protocol ProtocolPercentageEthereum35.2%Binance Smart Chain31%Polygon26.6%Fantom5%Avalanche2.2% Binance Smart Chain dominates the single protocol EVM need — Of all EVM users running more than one node, Binance Smart Chain is responsible for the top 41%. As a developer or entrepreneur running a Binance Smart Chain node, you are more likely to get more Binance Smart Chain nodes than nodes of other protocols. When compared to those running Polygon and Ethereum nodes. Full distribution (single protocol):Percentage of protocol nodes for the registered customers running more than one node but single protocol ProtocolPercentageBinance Smart Chain41%Polygon28%Ethereum22.8%Fantom5.1%Avalanche3.1% Things to conclude The overall blockchain user experience is getting more and more similar by the day both for EVM and non-EVM protocols. The developer blockchain experience is getting more unified as well. When using more than two nodes with Chainstack, over half of all the developers choose to make DApps and blockchains services multi-chain. The true multi-chain experience is, when you put any amount of effort to launch your product, is to support more than one protocol with Chainstack’s reliable nodes. When oversimplified, it’s as easy as swapping the node endpoint in your product to get exposure to a new protocol. Chainstack goes to great lengths to offer the best unified multi-chain experience that the industry is moving to. The protocols aren’t leaving the money on the table. Development teams like Etherscan aren’t leaving the money on the table. The majority of developers using Chainstack aren’t leaving the money on the table. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### MultiChain, an enterprise blockchain solution to build upon In brief This post is a part of the multipart series aimed at developers looking to try their hand out at and get a taste of the enterprise blockchain world. Of all the protocols we have covered so far, MultiChain is the only one that does not have the smart contract capabilities. Any logic that needs to be implemented is offloaded to an application that interacts with the blockchain network. To quote Gideon Greenspan, the CEO of Coin Sciences Ltd, the company behind MultiChain: Philosophically, MultiChain is closer to traditional database architectures, where the database platform provides a number of built-in abstractions, such as columns, tables, indexes and constraints. More powerful features such as triggers and stored procedures can optionally be coded up by application developers, in cases where they are actually needed.Source. So if you are looking to develop a solution that records facts on a ledger or exchanges assets, your best bet is to do an application connected to a MultiChain node. This post focuses on the blockchain part and committing a “Hello, Block!” message to the ledger of a consortium MultiChain network. Architecture On MultiChain accounts are created on the node-level and are not visible to the network, unless a transaction from the account is made and put on the ledger.  Nodes have roles—miner nodes and nodes. Miner nodes verify transactions and propagate blocks. Nodes keep ledger copies. See also a brief MultiChain introduction. Ecosystem  MultiChain is mainly driven by Coin Sciences developers—the company behind the protocol. MultiChain, being a fork of Bitcoin, enjoys connection to the Bitcoin ecosystem. Prerequisites A Chainstack account.A MultiChain network. See Deploy a consortium network. Commit a “Hello, Block!” message to the ledger At this point you should have a MultiChain network deployed as specified in the Prerequisites section. Since MultiChain is a fork of Bitcoin Core, working with it is similar to working with the Bitcoin protocol. Here’s an overview of how you are going to commit a “Hello, Block!” message as a ledger fact: Since MultiChain is a fork of Bitcoin Core, it uses the same unspent transaction output (UTXO) model. This means that any transaction that you create from your address uses the previous input transactions to your address. Unless this is a coinbase transaction—the only type of transaction that is created by miners and needs no input.You will use the unspent transaction output of the coinbase transaction that is in the first block of your MultiChain network.You will construct a raw transaction with the goal of attaching a message to this transaction.You will then attach a message to the transaction.You will sign the transaction.You will send the transaction to the MultiChain network.The transaction with your message attached to it will be picked up by a miner on the MultiChain network and committed to the ledger.You will then use the explorer to view the message committed to the ledger. Get the UTXO of your MultiChain address You need to get the unspent transaction output (UTXO) of the address you are going to use to commit the message. The address is automatically created when you deploy a MultiChain node. Run: curl RPC_ENDPOINT -u "RPC_USER:RPC_PASSWORD" -d '{"method":"listunspent","params":[0,999999,["WALLET_ADDRESS"]],"id":0}' where RPC_ENDPOINT — your MultiChain node’s RPC endpoint. Available under Access and credentials > RPC endpoint.RPC_USER — your MultiChain node’s RPC username. Available under Access and credentials > RPC username.RPC_PASSWORD — your MultiChain node’s RPC password. Available under Access and credentials > RPC password.WALLET_ADDRESS — your MultiChain node’s wallet address. Available under Default wallet > Address. Example: # curl https://nd-123-456-789.p2pify.com -u "user-name:pass-word-pass-word-pass-word" -d '{"method":"listunspent","params":[0,999999,["1KMhZ2btBe98cbdky1drfB5gaZHban8wDdAjQf"]],"id":0}' {"result":[{"txid":"275dd751bfeebc495dbc4665f014f135de9fa426d458d37c74a0febf92e62c97","vout":0,"address":"1KMhZ2btBe98cbdky1drfB5gaZHban8wDdAjQf","account":"","scriptPubKey":"76a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac1473706b700700000000000000ffffffff812aaa5f75","amount":0,"confirmations":11,"cansend":true,"spendable":true,"assets":[],"permissions":[{"for":null,"connect":true,"send":true,"receive":true,"create":false,"issue":false,"mine":false,"admin":false,"activate":false,"custom":[],"startblock":0,"endblock":4294967295,"timestamp":1604987521}]}],"error":null,"id":0} In the output, copy the txid value and the vout value. These are the ID of the unspent transaction and output index of the unspent transaction. You will need them in the next step to create a raw transaction. Create a raw transaction Create a transaction that will use the ID and the index that you received in the previous step. curl RPC_ENDPOINT -u "RPC_USER:RPC_PASSWORD" -d '{"method":"createrawtransaction","params":[[{"txid":"TRANSACTION_ID","vout":VOUT_INDEX}],{"WALLET_ADDRESS":0}],"id":1}' where TRANSACTION_ID — the txid value of the unspent transaction that you received in the previous step.VOUT_INDEX — the vout value of the the unspent transaction that you received in the previous step.WALLET_ADDRESS — your MultiChain node’s wallet address. Available under Default wallet > Address. Example: # curl https://nd-123-456-789.p2pify.com -u "user-name:pass-word-pass-word-pass-word" -d '{"method":"createrawtransaction","params":[[{"txid":"275dd751bfeebc495dbc4665f014f135de9fa426d458d37c74a0febf92e62c97","vout":0}],{"1KMhZ2btBe98cbdky1drfB5gaZHban8wDdAjQf":0}],"id":1}' {"result":"0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d270000000000ffffffff0100000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac00000000","error":null,"id":1} In the output, copy the result value. This is the hex of the transaction that you prepared. Add “Hello, Block!” to the transaction You will now append the raw transaction that you prepared with your “Hello, Block!” message. curl RPC_ENDPOINT -u "RPC_USER:RPC_PASSWORD" -d '{"method":"appendrawdata","params":["TRANSACTION_HEX",{"text":"Hello, Block!"}],"id":2}' where TRANSACTION_HEX — the result value that you received in the previous step. This is the hex of the transaction you prepared. Example: # curl https://nd-123-456-789.p2pify.com -u "user-name:pass-word-pass-word-pass-word" -d '{"method":"appendrawdata","params":["0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d270000000000ffffffff0100000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac00000000",{"text":"Hello, Block!"}],"id":2}' {"result":"0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d270000000000ffffffff0200000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac0000000000000000160573706b6601756a0d48656c6c6f2c20426c6f636b2100000000","error":null,"id":2} In the output, again copy the result value. This is the hex of the transaction that you prepared and that has now the “Hello, Block!” message attached to it. Sign the transaction You must sign the transaction before you can send it. curl RPC_ENDPOINT -u "RPC_USER:RPC_PASSWORD" -d '{"method":"signrawtransaction","params":["TRANSACTION_HEX"],"id":3} where TRANSACTION_HEX — the result value that you received in the previous step. This is the hex of the transaction you prepared and appended with the message. Example: # curl https://nd-123-456-789.p2pify.com -u "user-name:pass-word-pass-word-pass-word" -d '{"method":"signrawtransaction","params":["0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d270000000000ffffffff0200000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac0000000000000000160573706b6601756a0d48656c6c6f2c20426c6f636b2100000000"],"id":3}' {"result":{"hex":"0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d27000000006a47304402205e7ee933fd8d4326b94eb91d612628a7e70bc44a211da15161f2fe0810a9a12a022010afba9c9f2936c04806905413f3842f6f9aec7e7de9618f1c3b5293d509d15f012102c9529cc66527d40325631d8a5d7533ec2d562a9870d66353fa01835349338f2fffffffff0200000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac0000000000000000160573706b6601756a0d48656c6c6f2c20426c6f636b2100000000","complete":true},"error":null,"id":3} In the output, again copy the result value. This is the hex of the transaction that you prepared, attached the message, and signed. Send the signed transaction Send your transaction. curl RPC_ENDPOINT -u "RPC_USER:RPC_PASSWORD" -d '{"method":"sendrawtransaction","params":["TRANSACTION_HEX"],"id":4}' where TRANSACTION_HEX — the result value that you received in the previous step. This is the hex of the transaction you prepared, appended with the message, and signed. Example: # curl https://nd-123-456-789.p2pify.com -u "user-name:pass-word-pass-word-pass-word" -d '{"method":"sendrawtransaction","params":["0100000001972ce692bffea0747cd358d426a49fde35f114f06546bc5d49bceebf51d75d27000000006a47304402205e7ee933fd8d4326b94eb91d612628a7e70bc44a211da15161f2fe0810a9a12a022010afba9c9f2936c04806905413f3842f6f9aec7e7de9618f1c3b5293d509d15f012102c9529cc66527d40325631d8a5d7533ec2d562a9870d66353fa01835349338f2fffffffff0200000000000000001976a91487d23acdf7e4ad72db0e99c5d60886b47241903988ac0000000000000000160573706b6601756a0d48656c6c6f2c20426c6f636b2100000000"],"id":4}' {"result":"e565c6f430b0c254e0dc37ffecf7feed109085590651810daa5d6a5997792fb5","error":null,"id":4} In the output, copy the result value. This is the hash of the transaction that you sent. You will use this hash to view the transaction and your “Hello, Block!” message in the explorer. View your “Hello, Block!” message on the ledger At this point you have committed your message to the ledger. Time to look it up on the immutable MultiChain ledger! Go to your MultiChain project in Chainstack.In the project, click your MultiChain network.Click Explorer.In the explorer, enter the hash of your transaction that you received in the previous step.See your ”Hello, Block!” message. Congratulations! To reiterate what you did from start to finish: You deployed your own consortium blockchain network using the MultiChain protocol.You created a transaction and attached a text message to it.You committed the transaction to the immutable MultiChain ledger. And all of it was pretty easy too. For more sophisticated and real-world scenarios, explore Chainstack tutorials. Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator  to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Myria on Chainstack: Redefining the GameFi landscape with StarkEx Promoting confidence in high-speed, cross-chain gaming experiences with StarkEx Working with Chainstack has reinforced our commitment to user security. Their role in our DAC helps us ensure transactional transparency and reliability, a crucial aspect of our user experience. The Myria Team In an era defined by the convergence of digital advancements and creativity, blockchain technology has emerged as a pioneering force transforming numerous industries. Gaming, a sector known for its dynamic engagement and passion, has not been immune to these transformative forces. With Web3 paradigms and blockchain tech taking center stage, the gaming landscape is undergoing significant changes, heralding the way for innovative industry takes like the ‘play-and-earn’ model. One of the transformative players at the forefront of driving such radical shifts is Myria, setting a prominent example of what can be achieved when gaming meets blockchain. Leveraging an avant-garde gaming ecosystem, paired with a cutting-edge Layer 2 chain, they’ve managed to craft inventive and engaging gaming experiences, sending ripples across the entire landscape. At Chainstack, we’ve had the privilege of partnering with Myria on their pioneering journey toward radical GameFi transformation, underpinning a multitude of initiatives they’ve set out to pursue. So, let us dive deeper into our holistic collaboration and explore just how impactful Myria’s story really is as it unfolds. What is Myria? As a firm example of a groundbreaking Web3 gaming ecosystem, Myria stands tall in our fast-paced world where technology and gaming increasingly intersect. Fusing a Layer 2 blockchain together with a AAA game dev studio puts Myria in a unique position to bridge the gap between gaming and decentralized technology. Going beyond just fun and entertainment into a space, where players are rewarded for their participation, Myria excels with scalability and zero-fee transactions. These priceless advantages, together with instant on-chain interactions and commitment-free minting form the pillars that support its rise to the top in a market, where lag and high costs could prove a deterrent for many. This competitive edge sets Myria well above the rest, opening avenues for expansive growth into GameFi. And the power vacuum, left by previously unsuccessful players, plagued by network clogs and exorbitant participation prices proves to be the perfect place for it. The Myria ecosystem Bringing the best of both decentralized technology and its team’s passion for gaming, Myria offers a unique Layer 2 wallet and NFT marketplace, designed with gamers in mind. The Myria Wallet provides secure, and convenient digital asset storage but goes beyond being just a tool for holding tokens, integrating core functionalities that address the needs of every player. From access to the Marketplace and games like Moonville Farms to Node License purchases—the Wallet sits at the core of the Myria ecosystem. Figure 1: Myria Warrior Viking NFTs; Source: Myria docs In turn, the MYRIA Token, the native currency powering the full breadth of the ecosystem, serves as the primary instrument to engage in staking, governed voting, licensing, and exchange. With such broad utility already, MYRIA plays a crucial role in ensuring the security, decentralization, and overall functionality of the network. And as Myria continues with its rapid growth, further adding to its current 250+ project and 500K+ user tally, its importance is only set to rise with it. Since its inception, Myria has made significant strides in establishing its ecosystem and expanding its reach within the gaming community. The past year has marked several major milestones, including the release of the Myria blockchain, registering over a million users, the successful airdrop of over 900,000 Sigil NFTs, and the launch of the Myria Core SDK. The continual improvement of the Myria SDK and the release of the Myria Developer Portal highlight the platform’s commitment to empowering developers and building valuable, immersive gaming experiences. The Myria Studios vision Myria’s growth is not just about numbers, but also stories and narratives. The Myriaverse, Myria’s in-house lore, frames an evolving narrative for players to engage with. The Myriaverse, threatened by a mysterious space anomaly known as The Rift, forms the backdrop of the lore tied to Myria’s oncoming gaming titles. This mix of gaming and storytelling makes for an immersive player experience and binds the community together with a uniquely captivating narrative. It is exactly this fascinating piece of narrative that was forged by Myria Studios, a visionary game development studio that uniquely adopts the “play-and-earn” model. With this model, Myria Studios embarks on an ambitious journey to redefine how users interact with games. Figure 2: A selection of games on Myria; Source: Myria Their portfolio includes exciting projects like Metarush and 360 Cricket, targeting a diverse set of players and bolstering the studio’s reputation as a creative powerhouse. In essence, Myria Studios seeks to transform the gaming landscape and pioneer a new wave of gaming culture. The Myria Developer Portal and SDK Nurturing a community of developers is integral to the growth and success of any blockchain platform. Myria understands this implicitly, evidenced by their robust developer support in the form of the Myria Developer Portal and Myria SDK. The portal serves as a comprehensive resource center, offering guides, documentation, and essential tools to simplify the development process on the Myria Layer 2 blockchain. The Myria SDK, a dynamic set of development tools, enables developers to seamlessly port their Web3 projects into the ecosystem, fostering innovation and growth on the platform. Figure 3: The Myria ecosystem workflow; Source: Myria docs The community participation bounty Myria democratizes its support network for its Layer 2 platform by providing community members with the opportunity to purchase Myria Node Licenses and operate a Myria Node. These Node operators, in turn, become crucial players in the network’s security and decentralization initiatives, thus strengthening the integrity of the underlying chain. A rewards system further cements this community involvement in network security. Node operators are compensated with MYRIA tokens for their services, creating a mutually beneficial arrangement for both operators and the Myria ecosystem. This approach preserves the robustness and integrity of the platform while promoting accessibility and participation. The engine that drives Myria forward Myria has masterfully merged cutting-edge decentralized technology with high-quality AAA game development while incorporating StarkEx—an L2 scalability engine known for its efficiency. It is exactly this that allows Myria to handle up to 1K Mint, Settlement, and Transfer TPS and 200 MintRequest TPS in real-time, all while offering zero-fee transactions. The quick and reliable StarkEx validation process allows Myria to offer a unique experience to its users, reflecting transactions as complete on the application’s front end without waiting for on-chain finalization, even for complex transactions. This speed and efficiency are key in a market where lag and high costs could be deterrents for many users. To fully harness the advantages of integrating with StarkEx, Myria needed to implement a Data Availability Committee too, however. And this is where we chimed in! Our partnership with Myria was centered exactly on resolving this critical need. Protecting transparency with the Myria DAC The creation of the DAC provides assurance to users – a reliable mechanism to service withdrawal requests during emergencies, thus diminishing the overall reliance on StarkEx Operators. In these emergency situations, the Application Smart Contract (ASC) steps in, pausing new state updates and authorizing only direct user withdrawals. These withdrawals are secured by a valid Merkle proof, aligned with the most recent state, ensuring the highest level of integrity even in challenging times. As an active participant in the Myria DAC, Chainstack ensures the platform’s transparency, security, and reliability. We accept all state transitions, compute the subsequent state, sign the new state commitment, maintain a private and secure copy of the off-chain data, and check the receipt of a STARK proof aligned with a corresponding state commitment. Should Myria face difficulties fulfilling withdrawal requests, we step in to assist users in recovering their funds. We make our secure copy of the off-chain data publicly accessible and assist users in reclaiming their funds directly from the ASC using the revealed Merkle path. In doing so, we at Chainstack offer a safety net for Myria users, providing a recovery route for their funds even in the event of platform failure or an inability to service withdrawal requests. Resolution summary Putting Myria into overdrive: StarkEx powers Myria to handle up to 1K standard TPS and 200 MintRequest TPS in real time, all free of transaction fees. Lightning-fast validation: Leveraging StarkEx, Myria offers swift and reliable transaction validation for an enhanced user experience. Unlocking StarkEx’s full potential: Our collaboration with Myria centered around a crucial Data Availability Committee that optimizes the benefits of its StarkEx integration. Securing transparency: As a DAC member, Chainstack plays the role of a guardian, ensuring utmost transparency, security, and reliability, while verifying state transitions and STARK proofs. Dependable crises lifeline: Chainstack stands ready to assist Myria users in regaining access to their funds during emergencies, serving as a reliable safety net. Bringing it all together As we look back on our fruitful collaboration with Myria, it’s evident that the unique fusion of gaming and blockchain is not merely a passing trend but a revolutionary shift that’s redefining industries. The era of GameFi, powered by entities like Myria, is only just beginning, and the success of our collaboration is a testament to this future. Myria’s avant-garde approach, enabled by StarkEx’s L2 capabilities, and fortified by our partnership in creating a robust Data Availability Committee, showcases the true potential of what can be achieved when gaming meets blockchain. As it stands, Myria continues to redefine the boundaries of the gaming industry, creating immersive experiences for players, while staying true to its core principles of fairness, decentralization, and user empowerment. At Chainstack, we are incredibly proud of our role in this transformative journey. Our contributions have helped fortify the platform’s security, transparency, and reliability, even in emergency situations. As an active member of the DAC, we continue to remain committed to supporting Myria’s user base and sustaining the platform’s robustness. The future holds much promise, with our continued partnership set to unlock new possibilities, and further drive Myria’s growth in the GameFi space. As we move forward, we are excited about the boundless potential that the Myria ecosystem presents and look forward to being part of this pioneering shift toward a new era of blockchain-based gaming. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### NEAR Block Explorer – The NEAR Tutorial Set NEAR is deprecated on Chainstack and is no longer available for new deployments. Data works best when it is organized. Sure, with blockchain you have a structure that collects and organizes all the transactional data from a network, but how can a user access or view this data? How can they know the current state of things in the network without going through the hassle of writing long lines of code or better yet, how can one browse through the information in a blockchain network without knowing much about coding at all? Well, for all this and much more, you have a neat little tool called the block explorer. A block explorer is a staple in every blockchain developer’s arsenal. As indicated by the name, a block explorer helps you explore the data in a blockchain network. Along with the information about all the transactions and blocks that get generated in a blockchain network, the explorers also provide detailed overviews regarding the network activities themselves. This can include the time it takes to generate a block, the number of transactions in a day, etc. Every blockchain platform comes with its own block explorers and they provide the users (both technical and otherwise) with organized data regarding the network.  Understanding a block explorer not only helps us understand the data in the network but also provides insights into the working of the network itself.  With a clever, intuitive design and neatly presented data, block explorers are one of the best first tools to learn in order to understand a blockchain network.   The Near Block Explorer  In our NEAR tutorial, we discussed how the NEAR protocol stands out in terms of scalability, performance, and, of course, seamless end-user experience. With features like readable addresses, wallet-less (initial) interactions, etc., NEAR makes it easy for anyone to get started with the network. Another cool feature of the NEAR protocol is the availability of highly useful tools that help us in our development journey and the focus of this article is on one such tool, the NEAR explorer (in case it wasn’t obvious). The NEAR block explorer is a blockchain explorer for the NEAR network. It was built by the NEAR team itself and it helps you explore and view the details of all the NEAR transactions, smart contract interactions, account and block details, etc. The NEAR explorer comes with a sleek design that highlights the network information.  Understanding the block explorer  The search bar  As with many other block explorers, the key element of the NEAR explorer is a search bar that allows you to search for transactions, blocks and account details using their corresponding identification elements.  Due to the readable account address feature, searching the details of an account is especially easy in NEAR.  The node and block details  Right below the search bar, the explorer provides specific details about the network itself, here the information is divided based on the elements (nodes and blocks) that it represents. Within the Nodes section, you can see the details like Nodes online, which tell you the number of active nodes currently running in the NEAR network. The section also displays the number of nodes that are participating in the validation process.  The Blocks section gives you a general overview of block generation in the network. It shows you the current block height, i.e., the index of the most recent block  Note: The total number of blocks in the network will be block height + 1, as the block count starts from the genesis block, which is block 0.  While observing the block height, you might see that the number gets frequently updated and the reason for this constant updation can be found in the next bit of information that is provided in the block section, which is the Avg block time. The average block time tells you the amount of time it takes to generate a single block within the network and given the performance of the NEAR network, a new block gets generated every second (approximately).  NEAR network transaction details  The Transactions section gives information regarding the transactions happening in the network. The 24hr Total gives the total number of transactions that took place in the past 24-hour window. Note: The 24-hour window is calculated per second and thus the 24hr total field is updated every second. This causes fluctuations in the number of transactions following the change in the Avg block time, i.e., a decrease in the average block time will show an increase in the 24hr total and vice versa.  As with many other protocols, NEAR calculates the amount of computation required for a transaction execution using a unit called the gas. Users should pay for the gas to execute their transaction and the price of the gas is given in the gas price field. In NEAR, you pay for the gas using the native NEAR currency and the price is given as the amount of NEAR per Tgas.  One Tgas equals 1012 units of gas.  Digging deeper into the blockchain explorer  Right, now that we have covered the “first-page” of the NEAR explorer, let’s dig deep and see what else we get to explore. The Explore button in the top right corner of the page shows us specific elements that we can “explore”:  Accounts  Blocks   Transactions  Nodes   Charts and Stats  Accounts  The accounts option takes you to a page that lists all the accounts that were created in the NEAR network. The page displays: The account ID  The native currency balance in the account   Date of creation   The account IDs can be in both readable format and otherwise (64-character string): If you click on any of the accounts, the explorer will show you the details specific to that account. This includes the following: Field FunctionTransactionsNumber of transactions sent and received by the accountStorage UsedThe amount of storage used by the account (Bytes)Native Account Balance The NEAR balanceValidator Stake The NEAR balance in case you are staking NEAR to participate in the validation processCreated At The date of creationCreated by Transaction  The ID of the transaction that created the account The balance profile field on the page helps you track the placement of your NEAR tokens, i.e., whether you have staked it, locked it in a contract, etc. The transaction section shows the list of transactions to and from the account. Blocks  The blocks option shows you the list of all the blocks that are generated in the network, the page shows the:  Block index  Number of transactions in the block  Block hash  Status  As with accounts, clicking on one of the blocks will give you the details regarding the block, which include:  Field FunctionTransactionsThe number of transactionsReceiptsThe number of “actionable” objects included in the transactions (we will be discussing this in the upcoming tutorials) StatusThe status of the blockAuthorThe author of the blockGas UsedThe total amount of gas usedGas PriceThe price of gasCreatedThe time of the block creationHashThe hash of the BlockParent Hash The hash of the previous block The transaction section on the page will include the details of all the transactions included in the block.  Transaction The transaction option lists the details of all the transactions happening in the network. The details include:  The action  Transaction identifier  Transaction status  The account that sent the transaction  When you click on the transaction identifier, it will show you the following details of the transaction:  Field FunctionSigned ByThe account that sent the transactionReceiverThe account that is receiving the transactionStatusThe status of the transactionTransaction FeeThe fee that was paid for the transactionDeposit ValueThe total amount transferred between the accountsGas UsedThe unit of gas used by the transactionAttached GasThe gas included with the transactionCreatedTime of transaction creationHashTransaction HashBlock HashThe hash of the block that the transaction is a part of On the transaction page, you can also find the details of the action of the transaction and the plan of transaction execution.  Nodes The nodes option gives you the list of all the nodes that are either participating or in line for participating in the validation process. The page also gives you certain stats regarding:  The number of validating nodes  The Total supply of NEAR tokens  The total amount of NEAR that is staked  The current price(stake) to become a block-producing validator (seat price)  The list of nodes includes the details like:  Node location  Node status  Validator details  The fee  Number of delegators, i.e., people entrusting their tokens with these validators for staking  Amount staked  The cumulative stake details  The details of the nodes that are actively participating in the validation process will be provided first, followed by the nodes that are in line. The set of validators remains constant for a specified amount of time. In NEAR, this time interval is called an Epoch. The nodes page provides the details regarding the current Epoch at the start of the page.  Charts and stats   As the name suggests, the charts and stats option provides various graphical charts and statistics related to various network activities. You can use this page to get a consolidated view of all the network activities. Some of the major data include:  Total number of transactions  Daily gas usage  Account and contract creation details  The graphical representation of the data makes it easier for the user to understand the history and the current state of the network.  Exploring testnet  You can use the same NEAR explorer to explore the details of the NEAR testnet. To explore the testnet, all you need to do is select the network from the dropdown list at the top left corner of the NEAR explorer page.  Since the testnet is a mirror of the mainnet that is used for testing and deployment purposes, the testnet explorer also follows suit when it comes to functionality. The testnet explorer works the same way as the NEAR explorer and you can retrieve all the given information as the ones mentioned above.  Conclusion  A block explorer is an integral tool when it comes to blockchain development. Understanding the tool and the data presented using it will help you understand a lot about the network itself. The NEAR explorer provides an easy way to access the data that is stored within the NEAR network and understanding the NEAR explorer will help you better understand NEAR and ease up your NEAR development journey.  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### NEAR protocol tutorial set – Learn how to deploy DApps on NEAR – Quickstart with JS NEAR is deprecated on Chainstack and is no longer available for new deployments. This is the first article in “The NEAR tutorial set”, which aims to help you break into the NEAR ecosystem and build highly scalable applications on top of the NEAR network. In this article, we will see how to quickly deploy a NEAR DApp using the JavaScript SDK. Introduction Exploring blockchain protocols is quite fun. Every new protocol is essentially a variant that puts forth a solution to the general problem of attaining the right amount of scalability and performance for decentralized computation (and by extension, decentralized applications) in order for it to gain mass adoption. Some variants follow a fix-as-you-go approach, where they improve the underlying architecture and protocol as the demand for performance increases and then there are other protocols that come with inherent solutions that helps it to scale according to the performance demands. NEAR belongs to the latter class of variants. NEAR is branded as a community-operated cloud platform on top of which people can deploy and run decentralized applications. This article is all about exploring the basics of NEAR and seeing how quickly we can deploy an application on top of it.  What is NEAR protocol? NEAR is a general-purpose, Layer 1 blockchain protocol that uses the proof-of-stake consensus mechanism. What this means is that with NEAR, you have a base layer blockchain that uses the proof-of-stake algorithm to reach an agreement regarding the data that is to be stored in the chain and you can use the NEAR platform to build virtually any kind of application.  Once you build a DApp, the growth of the application revolves around the ease with which it can onboard new users and deliver a seamless user experience. In order to encourage both these features, a large part of the NEAR design philosophy is built around the ease of use or usability of an application. NEAR allows developers to build DApps that can provide an all-too-familiar experience to the end user. This involves providing functionalities like wallet-less (initial) interaction, readable account addresses, etc. Apart from smooth onboarding, to sustain the user base, the application should also be able to provide and maintain high performance, even during times of great network demand. For this, NEAR relies on an elegant solution called sharding.  Split the load through sharding As all of us might know, a blockchain network is a collection of computational devices, referred to as nodes. These nodes take care of the processing, validation, propagation, and storage of transactions in the blockchain network. When you analyze some of the most popular blockchain networks out there, you can see that when a new node joins a network, the amount of computational effort that it contributes (based on its role) is the same as the average computational effort of the network (as per the role), meaning as the network load increases, every node in the network will equally feel the pain. This strategy may not be optimal in the long run as all the nodes will get overworked every time there is an increase in network traffic, and this leads to processing delays and a decline in performance. A simple alternative to this strategy is to split the overall computational effort of the network among its participants. This is the essence of sharding. In a sharded blockchain network, the chain is split into separate fragments or shards and a subset of nodes are given the responsibility of maintaining these shards.   In such a network, the nodes are only required to put forth the computational effort required to maintain a particular shard and not the entire network. Each shard can perform computational tasks, independent of each other. This means that as the number of nodes increases, the processing capacity of the network also increases. Given that there is no upper limit to the number of nodes that can join the network, one can theorize that networks like NEAR, which uses sharding, can be scaled to infinity. This sounds exciting, but what about the uniformity of data across the chain? How do we take care of the data consensus in such a “partitioned” network? Validation through proof of stake As mentioned previously, NEAR uses proof of stake consensus. In this mechanism, a node must stake a certain amount of NEAR tokens in order to participate in the decision-making process. The nodes that participate in the process are called validators, and in NEAR, a new set of validators is chosen every 12 hours (an epoch). The selection of validators is done via an auctioning mechanism and a user who does not run a NEAR node can also participate in the process by delegating or entrusting his tokens with a validator of his choice. Compared to the proof-of-work consensus, in NEAR, if a validator is proven to be malicious, the stake that they deposited to partake in the consensus process will be slashed, meaning, they will lose all their stake. Since the payout of a malicious action might not be worth the stake, it ensures good behaviour among the validators in the network.  Note: In the NEAR network, based on the computational capabilities, a validator node can either choose to validate and produce a chunk (a group of transactions from a shard) or a block (a group of chunks). A Serverless experience So, with NEAR, we are talking about the proof-of-stake-based sharded blockchain network, in which nodes called the validators take care of the consensus process. Now, given the complexity of the architecture, a developer might feel a bit overwhelmed when it comes and developing applications on top of the network. But as we have already established, ease of use is at the core of the NEAR design principles, so apart from a strong network and a seamless end-user experience, NEAR also comes with a serverless computing model, meaning that to develop an application on top of NEAR, a developer need not worry about the underlying architectural management.  To put this feature to the test, let’s see how quickly someone with a basic understanding of the platform (yes, I am talking about us) can deploy and run an application on top of it.  A NEAR DApp  This section is all about quickly creating and running an application on top of the NEAR network, so before we get started with the app-building process, make sure you have the following things installed on your system: Node.js and npm  All done? Great, now let’s build a NEAR DApp. NEAR smart contracts As with countless other DApps, the core component of a NEAR application is also the smart contract. A smart contract essentially helps define the logic of the application and in NEAR you can write the smart contract using one of these two languages: Rust  TypeScript  Note: Since TypeScript is the most popular of the two languages, we will be using it to develop our smart contract. Regardless of the language that you choose, when compiled, all NEAR smart contracts are converted to a WebAssembly (.wasm) file. A project in seconds  NEAR has this neat little functionality where it allows us to create and deploy a sample project with minimal coding. To try this out: Create a new folder. Open a new terminal in the folder. Type the following command. $ npx create-near-app@latest When you run this command, it will prompt you to select the following: Preferred language (TypeScript). Preferred template (Vanilla JavaScript). A name for your application. You may also choose to install all the required NPM packages.  After execution, the command will generate a project structure complete with:   A TypeScript smart contract. A basic front-end for your application. Some integration test files.   The smart contract will be stored in the contract/src folder.   import { NearBindgen, near, call, view } from 'near-sdk-js'; @NearBindgen({}) class HelloNear { greeting: string = "Hello"; @view({}) // This method is read-only and can be called for free get_greeting(): string { return this.greeting; } @call({}) // This method changes the state, for which it cost gas set_greeting({ greeting }: { greeting: string }): void { // Record a log permanently to the blockchain! near.log(`Saving greeting ${greeting}`); this.greeting = greeting; } } The contract is built using the JavaScript SDK package (near-sdk-js). In the contract, you can see that it stores and retrieves a greetings message using the two functions:  set_greetings()  get_greetings()  Every function (and the contract class) in the contract is preceded by a decorator. They are used to add annotations and extra information about the functions (or the class).  To build the given contract, open a terminal in the root folder of the project and type,  $ npm run build The command will compile the contract and store the corresponding WebAssembly file of the contract inside the contract/build folder. And with that we have a compiled contract in our hand, now all we need to do is to deploy it onto the network.  Setting up an account  Before we start deploying the contract onto the network, we need to set up a NEAR account.  These accounts are used to store different assets, conduct transactions and have other general interactions with the network. In NEAR, instead of the public key hash, users can allocate human-readable IDs for account identification. This means that you can create accounts with IDs like account.near. This is very similar to a website domain name, and it provides a super convenient way to use and remember accounts in the NEAR network. The length of the account ID can be anywhere between 2 and 64 characters. In NEAR, users can also create multiple “sub-accounts” from one main account. Since there is a limit to the length of the account ID, you can only create a finite amount of sub-accounts.   Every account in NEAR can hold a single contract. While building large applications, multiple contracts are stored across the sub-accounts originating from the main account.  To create an account, we can use a NEAR wallet. You can create an account in both the NEAR testnet and the mainnet, for development purposes, we usually stick to testnet accounts.  To create a testnet account: Head over to https://wallet.testnet.near.org/ and click Create Account. This will prompt you to enter a human-readable ID for the account. Provide an ID with the given requirements and click on Reserve my Account ID. The next step is to select a method for securing the account. You can select the Secure Passphrase and click Continue. This will show you 12 random words and you are required to safely store these words. Once you saved them, click on Continue. Next, the wallet will ask you to enter a random word from the passphrase in order to verify the phrase. Once you enter the right word, it will take you to the newly generated account.  And with that, we have created a testnet account. Once you open the account, you may notice that the account will already have close to 200 NEAR test tokens available. This is the NEAR way of making things easy for the developer. Deploy smart contract  Now that we have an account, we can use it for deploying and storing the contract. To do this, we need the help of the near-cli tool. This is a command line tool that helps you interact with the NEAR network. To install near-cli, use the following command: $ npm install -g near-cli Once you have the CLI tool installed, you can use the following command to deploy the contract to our account.   $ near deploy --accountId example-contract.testnet --wasmFile example.wasm  As you can see, the command takes the account ID and the location of the compiled WebAssembly file as the parameters.   In NEAR, there is an even simpler way to deploy and run your contracts in a testnet and this involves the NEAR dev-deploy command. This command: Automatically generates a temporary account in the testnet. Deploys the contract onto that account. Unlike the deploy command, the dev-deploy command only requires the location of the WebAssembly file as a parameter: $ near dev-deploy --wasmFile example.wasm In our sample project, we will be using this command to deploy the contract, so open a terminal in the root folder of the project and type: $ npm run deploy This will call the dev-deploy command and deploy our contract onto a testnet. The command also creates a new folder /neardev in our project folder. This folder will contain the details of the temporary account that we have created.  Once you deploy the contract, you can view the transaction on the NEAR block explorer using the link provided at the end of the command execution  A quick interaction  Now that we have the contract up in the chain, we can interact with it using the front end provided by the sample application. To run the front end, open a terminal in the project root folder and type: $ npm run start This will spin up the application using the localhost. You can view it at http://localhost:1234 Once you click on the sign-in option, the application will automatically connect to your testnet account and it will let you interact with the contract.  In the backend, the contract interaction is handled using /frontend/near-interface.js file and /frontend/near-wallet.js helps you connect with the wallet. To connect and interact with the wallet, we use the near-api-js package. Note: The near-api-js is a complete library used for interacting with the NEAR blockchain. Once you connect to the network using the library, it lets to interact with wallets, accounts and smart contracts that are part of the network. In the coming tutorials, we will be extensively using this library while building applications. And just like that we deployed and interacted with a basic application running on top of the NEAR network.  Wrapping up  This tutorial was all about giving you an introduction to the NEAR ecosystem and helping you understand the various elements that make up the NEAR network and the NEAR application development process. In the coming tutorials, we will dive deep into the various aspects of NEAR and learn how to create more complex applications using the platform. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### NEAR smart contracts tutorial – Hello World with JS – NEAR protocol tutorial set NEAR is deprecated on Chainstack and is no longer available for new deployments. In this article, we will be looking into the elements of a JavaScript-based NEAR smart contract, and we will also see how to use the NEAR Command Line Interface (CLI), a powerful tool that lets you interact with the NEAR network. Introduction Greetings fellow BUIDLers; welcome to the third article in the NEAR protocol tutorial set: Learn how to deploy DApps on NEAR The NEAR block explorer The previous articles gave you a detailed overview of the NEAR protocol, its features, and of course, a neat little tool called the NEAR explorer. So, by now, you are equipped with almost all the knowledge required in order to start building your own NEAR DApps, well, almost! A crucial part of the DApp building puzzle that we have yet to explore is the structuring of a NEAR smart contract. Sure, we have ways to quickly set up the codebase for a simple DApp, but I am talking about complex DApps with tons of cool functionalities. To create one of those, you need to understand the components of a NEAR smart contact and how to use them. Also, creating and deploying a smart contract is step one towards building your own DApps; after that, you need to find ways to interact with the contract. Fret not; this article covers all that and much more. So let’s get started. Understanding a NEAR smart contract Like its counterparts, NEAR smart contracts are essentially executable programs stored on the NEAR network. In NEAR, after you write a contract, it gets compiled into WebAssembly, and from there, it gets deployed onto an account in the NEAR network. Once the network associates a contract with an account, the users are free to interact with it. One of the major differences between an Ethereum smart contract and one in NEAR is that you can write NEAR smart contracts using general-purpose programming languages like JavaScript, TypeScript, or Rust. In this article, we will be using pure JavaScript to write a NEAR smart contract. Setting up the environment Alright! before we start writing contracts, make sure that you have the following dependencies installed on your system. Node.js (^v16) A code editor (VS Code, preferably) Once all the requirements are installed, we can use the create-near-app package to quickly set up a NEAR project. To use the package: Create a new directory Open a new terminal in the directory Type the following command: npx create-near-app@latest The command will ask you to select a: Preferred language (TypeScript) Preferred template (No frontend) Name for your application (hello-world…maybe) You can also select the option for installing all the required NPM packages. Once all that is said and done, the package will create a properly structured codebase, complete with a sample smart contract inside the contract/src directory. Now, the package, as per our command, generates a smart contract written in TypeScript, but since the article promises a pure JavaScript-based contract, you can delete the TypeScript file inside the contract/src directory (one with the .ts extension) and create a new JavaScript file in its place (contract.js). Note that TypeScript is like a superset of JavaScript, which means that any valid JavaScript code is also valid TypeScript code. However, TypeScript has some additional features that are not present in JavaScript. So, if you are a TypeScript aficionado, feel free to use TypeScript for the contract. Also, if you open the contract/build.sh file, you will find the command for building (compiling) our contract and generating the corresponding WebAssembly file. Since we are using a JavaScript (.js) file for this article, make sure to edit the command and replace <file_name>.ts with the name of your JavaScript file (contract.js, in this case). The build.sh shell script comes with the create-near-app package, and it helps you build your contracts. You can also build your contracts by manually running the command mentioned in the shell script. Ok, with that, we have everything we need in order to develop our smart contract, so let’s get to it. Writing the smart contract Now, we will be writing a voting contract (a bit of a cliché, I know!). Our contract will enable the users to: Add new candidates Cast votes View the list of candidates View the result The imports To start things off, open the contract.js file (inside the contract/src directory) in your code editor and add the following lines: import { NearBindgen, call, view, near, UnorderedMap, initialize, assert, } from "near-sdk-js"; Now, this is a pretty straightforward import statement that adds a couple of useful things to our contract (we will explain each of them soon). As you can see, all the entities are being imported from a single package, the near-sdk-js. This package gets automatically installed when we generate the codebase using create-near-app. Class declaration After the import statement, we can declare our contract class: @NearBindgen({})//decorator export class voteContract { //write functions here } In NEAR, a contract is defined using a class; within this class, we can add all the required properties and functions. Based on your use case, you can even declare other “non-contract” classes within the same file, but the class containing the core contract logic should be preceded or decorated using NEAR Bindgen. The decorator @NearBindgen({}) separates the “contract” class from the rest and also helps generate the code to: Convert the class into a valid NEAR contract Set the visibility of public functions Serialize objects for internal storage and communication with external actors Setting default values Once we have declared the class, we can start working on the functions for setting some default values and state initialization: @NearBindgen({}) export class voteContract { constructor() { this.vote_map = new UnorderedMap("vote-map"); this.owner_id = ""; } @initialize({}) init(_owner_id) { this.owner_id = _owner_id; } } The constructor() function, as per usual, helps set the default values for the class attributes (the ones referred to using this keyword) upon contract deployment. Here, we are using it to create a new class attribute called vote_map, which contains an empty UnorderedMap, and also to create owner_id, a class attribute for storing the account ID of the user who deployed the contract. The UnorderedMap works exactly like a Python dictionary or mapping in Solidity. It helps model the data as key-value pairs. Here, we will use this to map the name of the candidates to the corresponding votes that they receive. In NEAR, complex structures like UnorderedMap should be initialized using a unique prefix (vote-map, in our case). This prefix is used to identify the structure’s keys in the serialized state. Apart from UnorderedMap, the NEAR SDK provides a set of other complex data structures that the developers can use while writing smart contracts. To learn more about these data structures, you can refer to the official NEAR docs. After the constructor() function, we declared an initialization function, init(). The purpose of this function is to help set the initial state values. The initialization function should be decorated using the initialization macro—@initialize({}). Here, the init() function is used to set the account ID of the user deploying the contract onto this.owner_id class attribute. We will pass the user’s account ID to the init() function when we deploy the contract. By default, the initialization functions are public functions, meaning that they can be called by anyone. Keeping with the safety practices, it is best that you declare them as a private function or a function that can only be called by the account that hosts the contract (the contract’s account). To do this, we need to modify the @initialize({}) decorator: @NearBindgen({}) export class voteContract { constructor() { this.vote_map = new UnorderedMap("vote-map"); this.owner_id = ""; } @initialize({privateFunction: true}) //private function init(_owner_id) { this.owner_id = _owner_id; } } In the contract, you can also make the initialization function mandatory. This will prevent other “state-changing” functions from being executed before you initialize the state. For this, you need to modify the @NearBindgen({}) decorator and add the requireInit parameter: @NearBindgen({requireInit: true}) export class voteContract { constructor() { this.vote_map = new UnorderedMap("vote-map"); this.owner_id = ""; } @initialize({privateFunction: true}) init(_owner_id) { this.owner_id = _owner_id; } } Adding the functions Once we set the default values, we can work on the rest of the functions. In the NEAR smart contracts, apart from what we just saw ( constructor(), init() ), there are two other types of functions, they are: Call functions View functions A call function is what you call a “state-changing” function. These functions contain the code for manipulating the state. These functions can also call other contracts. A view function can only read the state data and cannot cause any changes to it. These functions are free for everyone to access, and users can call a view function without needing a NEAR account. The call and view functions are decorated using @call({}) and @view({}) decorators, respectively. So, as discussed, let’s write the functions for adding and viewing candidates, casting a vote, and viewing the results: //add new candidates @call({}) addCandidate({ _candidate_name }) { //getting the account ID of the user who called this function let caller_id = near.predecessorAccountId(); //make sure that only the owner can add new candidates assert(caller_id == this.owner_id,"Only owner can add candidates") //add the candidate name to the map, //along with the default number of votes (o) this.vote_map.set(_candidate_name,0); } //view the list of candidates @view({}) listCandidates({ }) { //get the keys(candidate names) from the unorderedmap return this.vote_map.keys.toArray(); } @call({}) castVote({_candidate_name}) { //get the number of votes obtained by a candidate //and update it let currentVote = this.vote_map.get(_candidate_name) + 1; //increment the vote and add it to the map this.vote_map.set(_candidate_name,currentVote); } @view({}) showResult(){ //convert the map to an array and return it return this.vote_map.toArray(); } Here, you can see that the addCandidate() and castVote() functions are decorated with @call({}), while the others are decorated using @view({}). This basically points to the nature of these functions i.e. whether they are a call function or a view function. The addCandidate() function takes the name of the candidate as the parameter (_candidate_name) and, using the assert() statement, makes sure that the account ID of the person calling the function (caller_id) and the account ID of the person who deployed the contract (this.owner_id) are one and the same. If they are not the same, the function will throw an error and halt its execution. The idea is to prevent anyone other than the contract owner from calling this function. The castVote() function takes the name of the candidate as a parameter and gets the number of votes (using the get(<key>) function) that is stored against the candidate’s name in our UnorderedMap. The value is then updated and added back into the UnorderedMap using the set(<key>,<value>) function. Both the get() and set() functions come as part of the map structure. The listCandidates() function is a view function that takes the keys (candidate names) from our UnorderedMap and returns them. The showResult() function converts the UnorderedMap into a list of lists (carrying the candidate’s name and votes) and returns them. Once you add all the functions, the completed smart contract should look something like this: import { NearBindgen, call, view, near, UnorderedMap, initialize, assert, } from "near-sdk-js"; @NearBindgen({requireInit: true}) //set mandatory initialization export class voteContract { constructor() { // creating a map for tracking the candidates // and the number of votes they receive this.vote_map = new UnorderedMap("vote-map"); //creating a variable for storing the account id of the contact owner this.owner_id = ""; } //initialize the account id of the contract owner @initialize({privateFunction: true}) init({_owner_id}) { this.owner_id = _owner_id; } //add new candidates @call({}) addCandidate({ _candidate_name }) { //getting the account ID of the user who called this function let caller_id = near.predecessorAccountId(); //make sure that only the owner can add new candidates assert(caller_id == this.owner_id,"Only owner can add candidates") //add the candidates' name to the map, //along with the default number of votes (o) this.vote_map.set(_candidate_name,0); } //view the list of candidates @view({}) listCandidates({ }) { //get the keys(candidate names) from the unorderedmap return this.vote_map.keys.toArray(); } @call({}) castVote({_candidate_name}) { //get the number of votes obtained by a candidate //and update it let currentVote = this.vote_map.get(_candidate_name) + 1; //increment the vote and add it to the map this.vote_map.set(_candidate_name,currentVote); } @view({}) showResult(){ //convert the map to an array and return it return this.vote_map.toArray(); } } To deploy the contract onto the network, you must build (compile) it and create the corresponding WebAssembly file. To build your contract, open a terminal in the root directory of your project and use the following command: npm run build This will compile your contract and store all the output files in the contract/build directory. Within the directory, you will find the corresponding WebAssembly file of your contract (<project-name>.wasm), along with other artifacts. So, now that we have a compiled contract, let’s deploy it. Smart contract deployment To deploy the contract, we will use the NEAR CLI tool. This tool allows the users to: Access accounts Deploy and interact with contracts This tool is automatically installed by the create-near-app package, and you can use it by opening a terminal in the project root directory and typing the following command: npx near This will display all the available NEAR CLI commands and their usage: NEAR CLI commands and usage You can install the NEAR CLI tool globally onto your system using the following: npm install -g near-cl This will allow you to directly run the tool from anywhere within your system without the npx prefix. In this article, we are using and running the NEAR CLI package from within our project directory, hence the npx prefix. To deploy a smart contract to the NEAR network, you would also require a valid NEAR account (a NEAR testnet account will suffice). You can use the previous tutorial to learn how to set up a NEAR account. Accessing the account Once you have the CLI tool and the account, the first thing that you need to do is to log in to your account. You can use the following NEAR CLI command in order to access your testnet account: npx near login This will automatically open a page in your browser that will prompt you to select the account that you want to access: Accessing your NEAR testnet account Once you authorize access to the account, the CLI tool will log in to your account. Deploy contract Now, we can deploy the contract using the following command: npx near deploy --wasmFile contract/build/<file-name>.wasm --accountId <your-account-id> --initFunction init --initArgs '{"_owner_id":"<account-id>"}' The command takes in the path to the WebAssembly (.wasm) file, the user account ID, the name of the initialization function (init(), in our case), and the parameter value for the init() function. After deploying the contract and initializing it with the value, the command will output the transaction ID. Since we are running the CLI commands from within our project directory, the path to the WebAssembly file is kept relative to the directory. If you are running it from any other location, be sure to provide the correct (absolute) path to the WebAssembly file. Once the contract is deployed, we can use the CLI tool and contract ID (the account ID of the contract) to interact with it. Here’s how you can call the addCandidates() function using the NEAR CLI: npx near call <contract-id> addCandidate '{"_candidate_name":"alice"}' --accountId <user-account-id> Here, the command takes in the contract ID (account ID of the contract), the function’s name, the required parameter values, and the account ID of the user invoking the function. Since addCandidate() is a call function, we have to use the call keyword at the start of the command. To view the list of candidates, we can use the following command: npx near view <contract-id> listCandidates As you can see, with view functions like listCandidates(), you don’t need to add the account ID of the user invoking it since these functions are free for all to access. All the other call and view functions in the contract follow the same command pattern, do play around with it. And with that, we have successfully created, deployed, and interacted with a JavaScript-based NEAR smart contract. Conclusion This article is aimed at giving you an overview of the various elements involved in a NEAR smart contract and showing you how to use them in order to create complex contracts. In the coming tutorials, we will further explore NEAR smart contracts and write actual scripts for testing, deploying, and interacting with the contracts and will do all this from your own NEAR node, hosted in the Chainstack Platform. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### New Solana NFT projects live monitoring with Candy Observer Overview NFTs generated a total of more than 40B transaction volume in 2021, and still going. There are new tokens generated every second, and this number increases exponentially day by day. Solana, with close to 2.5M active monthly accounts, 0.4 second network confirmation time, and cheap transactions, is a natural fit for the NFT market, among other things. This is confirmed by Metaplex, the biggest NFT protocol on Solana, that generated over 5M NFTs in less than a year since its launch. Would it be useful to have a tool that sends a notification every time an NFT is minted on Solana and does so in real time? With Solana being a recent addition to Chainstack, I am going to explain the inner workings of how Metaplex works, how Solana works, and how to listen to the Solana network over WebSocket through a Chainstack node. And I’m going to do it through Candy Observer—a lightweight and installation-free tool that you can create yourself and that demonstrates how to listen live to NFT minting on Solana. Prerequisites A Solana mainnet node with a WebSocket endpoint: To get one: Sign up with Chainstack.Deploy a Solana node.Get the deployed node’s WSS endpoint. Using Candy Observer The live code: Candy Observer is a lightweight web app. Whenever a new Solana NFT is created using Candy Machine—a Metaplex program, the minting event is captured by Candy Observer and displayed to the user: A sample of results received Open Candy Observer. Enter the WebSocket endpoint address in the text field.Click connect.Wait until the status changes to Connected, then click start. Simple as it is, now the code is up and running. The app monitors the Solana network for new NFTs. When a new token is created, the app gets notified about the transaction. Clicking the public address that the Candy Observer displays will get you to the Solana explorer with the minted NFT information. That is everything about the web app itself. If you are interested in learning more about the Candy Machine, NFT minting on Solana, subscribing to programs, or how to extend this app, the rest of this article elaborates on these. Read it, it’s fun and educational. Inner workings Metaplex and Candy Machine Candy Observer is watching the Candy Machine v2 program—the most popular tool for NFT minting on Solana. Thousands of creators upload their art pieces and mint NFTs using Candy Machine every day. All NFTs are searchable on the Solana explorer with the public address: Metaplex is a decentralized protocol and a collection of tools designed to facilitate launching and selling of NFTs. Candy Machine is one of the major projects owned and maintained by Metaplex. The process of creating a new NFT is called “minting“. Minting is always a transaction. For the full flow of a token mint with Metaplex, see Metaplex docs: Creating the Token Mint. To study this process with a real-life example: Visit the Solana explorer.Search for “NFT candy machine program”. A “program account” page for the Candy Machine is opened. The public address of the Candy Machine program can be found here too. This is the address hardcoded in the Candy Observer web app. Scrolling down the page, all the transactions for this program are listed below. Hit the Refresh button to get the latest transactions. Click on any of the signatures, the transaction detail page opens. The address of the newly minted NFT can be found here. As well as the details of the minting process. On-chain programs Notice all the programs involved in the transaction? They are on-chain programs—a unique feature on Solana. Think of on-chain programs as pieces of customized code running on the network itself. They are stored in a special “account” called program account. The Candy Machine program is addressed at cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ, which you have already seen in the previous step. The Candy Machine program facilitates various other system programs to conduct the minting process and makes the process easy for users. WebSocket endpoint An endpoint is the door to the blockchain network. Solana’s free WebSocket endpoint is wss://api.mainnet-beta.solana.com, which times out every minute. For best experience, it’s good to create your own endpoint (as stated in the Prerequisites section) on Chainstack with a free developer account, there is no usage fee either. WebSocket subscription Solana provides a set of RPC APIs which are unique to the protocols. Candy Observer leverages on the logsSubscribe API to constantly listen to the network and receive notification whenever an NFT is “minted”. The initial JSON message looks like this: var message = JSON.stringify({ "jsonrpc": "2.0", "id": 1, "method": "logsSubscribe", "params": [ { "mentions": [ "cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ" ] }, { "commitment": "finalized" } ] }) When running, the app subscribes to the global transaction logs and finds any transaction that is related to the Metaplex Candy Machine. The response object contains its public address, slot number, and detailed instructions of the transaction. Candy Observer code The implementation is straightforward—there are just three main parts (see below). Initializing the WebSocket: socket = new WebSocket(websocketurl); Sending an initial message, which initializes listening on all transactions to catch the ones that contain the Candy Machine’s public address: async function init() { if (socket) { var message = JSON.stringify({ "jsonrpc": "2.0", "id": 1, "method": "logsSubscribe", "params": [ { "mentions": ["cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ" ] }, { "commitment": "finalized" } ] }) socket.send(message); document.getElementById("info").innerHTML += "<p>Start listening</p>"; console.log("start listening") } } Whenever a token is newly generated, a message is received over the WebSocket, the information is shown on the page: socket.onmessage = function(message) { try{ data = JSON.parse(message.data); infodiv.innerHTML += "<p>New token: <a href='https://explorer.solana.com/tx/" +data.params.result.value.signature+ "' target='_blank'>"+ data.params.result.value.signature+"</a></p>"; console.log(data) console.log(data.params.result.value.signature) } catch(error){console.log(error)} }; Conclusion Solana is unlike any of the other blockchain protocols—it has its own concepts and technology, and it is fun to play with. Try it out. Read more about the Solana programming model, JSON RPC API, and try out a detailed tutorial on how to deploy your own program on Solana. Happy coding! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Newgem on Chainstack: Connecting emerging artists with demand for digital creations Newgem is a Europe-based marketplace for NFTs, emerging artists, and creators. The cross-chain platform helps users create, purchase, sell, and auction their digital creations on the Ethereum, Polygon, and Avalanche networks. What is Newgem? The Newgem platform serves to connect emerging artists and creators with the ever-growing demand for NFTs by means of direct on-chain access to create collections and trade them in an effective manner. Developed completely in-house, Newgem offers an accessible easy-to-use interface that lowers the complexity of its operations with transparent cost structure that is anyone can understand. Currently, the platform offers layman’s explanations for every step involved in the process within its documentation, further facilitated by relevant images and videos. How did Newgem come across Chainstack? When they kickstarted their search, Newgem needed a reliable node provider that can power their operations and listen to events emitted by their smart contract for the Ethereum, Polygon, and Avalanche networks. To find a fitting option for their needs they crawled through relevant alternatives via search and consulted user opinions on YouTube. Some of them did not offer support for the chains they were looking to use, while others could not adequately match the user-friendliness or reliability criteria, they had laid out prior. How does Chainstack’s offer match Newgem needs? Once the Newgem development team came across Chainstack, our platform seemed to be a perfect fit for all of conditions they were looking for. First and foremost, Newgem found that Chainstack services offered both HTTPS and WSS node endpoints, which was how they intended to connect to the RPC infrastructure in the first place. Second, the Chainstack platform supported all the blockchain protocols their development team was looking to integrated – Ethereum, Polygon, and Avalanche. In turn, having the option to connect to all of these via both HTTPS and WSS was exactly what they needed for their backend implementation. And lastly, considering Newgem was trying its best to avoid having to use multiple providers for doing the same thing, Chainstack came forward as the perfect option to adhere to this need. Outcome Thanks to the Chainstack platform’s easy-to-use and self-explanatory UI, Newgem found no need to consult with our team in solving any woes when running their services on top our robust infrastructure. Because of this, their development team was able to onboard swiftly themselves, while settings things up for live operations on production. What does Newgem like about Chainstack? We saw no need for assistance from the Chainstack team in getting everything to run smoothly. Everything was laid out clearly so we could just follow the process and succeed in doing so with ease. After integrating with Chainstack services, Newgem operations have been running as smooth as butter. Miguel Franco, CMO, Newgem What does Chainstack like about Newgem? Considering the exponential growth of NFTs within the Web3 landscape, seeing new solutions like Newgem that help further facilitate the entire process for both artists and buyers is certainly a welcome sight to behold. At Chainstack, we applaud such efforts, while looking forward to the next step in the development of NFTs within the larger Web3 ecosystem. Eugene Aseev, Founder & CTO, Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Nexo lowers Debug & Trace costs by 5X+ with Elastic Business data profile Empowering DeFi by bridging traditional banking and blockchain technology. Embracing Chainstack’s cutting-edge blockchain infrastructure has empowered Nexo to significantly enhance operational efficiency and innovation. By leveraging this reliable platform, we’ve unlocked unparalleled access to blockchain services, aligning with our vision of a more accessible and secure digital ecosystem. Together, we’re setting industry benchmarks, demonstrating the transformative potential when technology meets ambition. Dimitar Bratovanov, Product Manager, Nexo At Chainstack, our job is all about making new connections—connections that allow us to push the boundaries of what’s possible in the world of blockchain. As a vital partner to pioneers like Nexo in the digital assets landscape, we at Chainstack take immense pride in our collaborations. Nexo, a renowned global institution for digital assets in the field of digital finance, has committed itself to advancing professional services in the sphere since 2018. Trusted by millions, it enables users across over 200 jurisdictions to capitalize on the potential of their crypto assets. Alongside these services, Nexo also offers a comprehensive crypto trading platform, a practical solution for staking crypto, an uncomplicated approach to buying crypto using a credit card, and numerous other offerings tailored for novice and seasoned developers alike. How does all this happen behind the scenes? Let us take you on this exciting journey! Why Nexo chose Chainstack as its infrastructure partner When Nexo began evaluating different data providers, they were keen to find a robust solution that would fulfill their expanding blockchain infrastructure needs. With the expectation of finding a robust and reliable partner to support their diverse blockchain requirements, Chainstack emerged as the right choice. Our potential to provide Nexo with the ability to manage high-volume archive and full node requests across multiple blockchains was especially convincing. This was especially crucial because Nexo’s challenge lies in finding a provider that enables extensive tracking of on-chain activities on various chains with structured and transparent pricing. One of the standout features that seemed to resonate with Nexo from the beginning was our capacity to manage high-volume requests across multiple blockchains, minus significant downtime. They also appreciated the flexibility of our offerings, allowing them to scale and upgrade nodes as per demand, coupled with extensive protocol coverage, and a competitive and transparent pricing structure, further solidified our partnership with Nexo. Nexo on Chainstack in numbers Our partnership with Nexo has been marked by significant milestones and numbers that go on to emphasize the effectiveness and stature of our association. Nexo, with its high demand and growing implementation of blockchain technology, deploys a significant eight active Global Nodes with us at Chainstack. These nodes are of utmost importance in managing the large volumes of archive and full node requests that Nexo processes. In numerical terms, this accounts for a staggering 232.3M archive node requests and 40.4M full node requests. Nexo’s operations through Chainstack predominantly utilize the Avalanche, BNB Smart Chain, Ethereum, and Polygon protocols. This diverse protocol integration facilitates efficient tracking of on-chain activities across these blockchains, managing a significant number of requests: 1.2M on the Avalanche protocol, 104.6M on BNB Smart Chain, 38M on Ethereum, and 128.9M on Polygon. Our work with Nexo demonstrates our commitment to providing Web3 developers with high-performing and cost-efficient blockchain infrastructure. Processing an average of 11.4M debug_traceBlockByNumber, 4.3M eth_getBlockByNumber, and 4.2M eth_getBlockReceipts requests over the last quarter, we have delivered utmost value for Nexo with every call. Figure 1: Nexo full and archive node RU allocation Our Business plan, priced at $499, offers immense savings compared to Alchemy’s $11,018 Scale plan and QuickNode’s $2,132 Business plan. This highlights our solution’s cost efficiency, being 30X more affordable than Alchemy and 5X more than QuickNode, underscoring our focus on delivering quality at scale. Figure 2: Nexo data profile price comparison; Source: Chainstack These numbers underscore the seamless symbiosis between Chainstack’s reliable and robust offerings and Nexo’s expanding digital asset operations. It further fortifies our commitment to catering to Nexo’s ongoing needs and ensuring its steady growth in the vast crypto and blockchain industry. What is Nexo? Nexo was established in 2018 and is a leading global institution in digital assets. With vast experience in FinTech and innovative capabilities of blockchain technology, Nexo helps millions of people to unlock the potential of their crypto assets, contributing to the development of an improved ecosystem. Spanning over 200 jurisdictions, Nexo has more than 7M users, and its influence in the crypto space is ever-growing. By processing over $130B in just over five years and supporting 60+ cryptocurrencies, Nexo empowers its users to buy and grow their digital asset portfolio securely. Coupled with a security-first approach and a sustainable model, Nexo presents a robust platform for any crypto-enthusiast. Starting off as a crypto lender, Nexo has grown its capabilities into a 360º service for digital assets which includes yield on assets, a full-fledged crypto exchange, and of course, crypto-backed credit with rates as low as 0% APR. Nexo offers a simple and smooth on-ramp to the world of crypto via its Buy with Card functionality. Users can instantly fund their accounts and earn up to 16% p.a. via various top-up methods such as Visa, Mastercard, or through on-chain crypto transfers. Thus, it’s not just about buying; Nexo allows its users to earn crypto as well. The platform also has a seamless crypto exchange which allows its users to trade 60+ assets without fees, exploring various trading methods and utilizing their crypto holdings. Figure 3: Nexo Credit Hub; Source: Nexo With all these offerings and features, Nexo is not just a lending platform but a comprehensive ecosystem catering to the diverse needs of its user base. Partnering with Nexo has been an extraordinary journey. Their dedication to enhancing the digital finance landscape aligns perfectly with our mission to provide innovators with the best blockchain services out there. Together, we’re paving the way for a future where Web3 is within everyone’s reach. Eugene Aseev, CTO & Co-Founder, Chainstack Bringing it all together Our journey with Nexo marks a milestone in our relentless pursuit of providing the best blockchain services for our customers. It is a testament to Chainstack’s commitment to helping innovative players like Nexo amplify their reach in the digital assets landscape. Nexo, being a leading figure in the digital assets space, harmonizes the capabilities of blockchain, enabling a diverse user base to reap substantial benefits from digital assets. The sheer variety of services offered by Nexo, from crypto trading to lending, staking to borrowing, and even making it easy to buy crypto with a credit card, is a testament to their creative adaptability in the digital realm. Nexo’s journey is a testament to the innovation and limitless possibilities of blockchain, and Chainstack is immensely proud to be a part of it. Together, we are paving the way toward a future where digital assets, driven by the power of blockchain, are accessible to everyone, everywhere. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### NFT minting and creation? A quick guide If you’ve dabbled in digital art, collectibles, and online gaming, chances are you’ve already heard of minting NFTs. Most popular blockchains like Polygon, Solana, and Ethereum support minting NFTs. Even Bitcoin added its NFTs, also known as Bitcoin Ordinals (insert interlink to Ordinals post on Chainstack blog when it’s live). What’s more, minting an NFT is an excellent way to showcase your creativity and earn money in the process. With the rise of NFTs, many different platforms and marketplaces are available to creators, making it easier than ever to get started. Whether you’re an artist, musician, or content creator, creating an NFT can help you build a fanbase and uniquely monetize your work. But what does minting mean exactly, and how do you create your first NFT? Is it difficult to do? Does it cost a lot of money? Whether you are an aspiring digital artist or a metaverse gamer looking to create a rare in-game item, read on to learn more about minting. What is minting? Minting is creating a unique NFT from scratch, just like any physical collectible that is in “mint condition” or brand-new. It’s similar to creating a new piece of artwork, but instead of using paint and canvas, you use digital files like images or videos. Gamers also mint NFTs for blockchain games, such as playable characters, consumables, and in-game resources. Minting is the first step in transforming a digital asset into a unique, ownable, tradable, and collectible NFT. When someone mints an NFT, they permanently etch it into the blockchain, making it immutable. One of the most popular blockchains used for minting NFTs is Ethereum, which allows creators to mint and distribute their unique digital assets using the ERC-721 or ERC-1155 standard. These standards define the rules and properties of a particular NFT, including its ownership, uniqueness, and metadata. How does minting NFTs work? During the minting process, NFT creators can include a variety of metadata that provides additional information about the NFT, such as its title, description, and creation date. This metadata can help collectors understand the context and value of the NFT and can also be used to verify its authenticity and ownership. It also allows NFT marketplaces to categorize and rank them, making filtering and browsing through specific collections easier. Once an NFT is minted, it can be bought, sold, or traded on various NFT marketplaces, much like artwork and collectibles are traded on eBay. The value of an NFT is determined by factors such as its rarity, popularity, cultural significance, purpose, and utility. However, NFT value tends to be volatile and can fluctuate from extreme highs to extreme lows based on the cryptocurrency market conditions. How do I mint an NFT? Here’s how to mint an NFT in a few simple steps for the first time. 1) Choose a blockchain First, you need to choose the blockchain platform hosting your NFT. Ethereum is the most popular blockchain platform for NFT creation, but it’s also one of the most expensive due to gas and fees. There are other more affordable options like Binance Smart Chain, Solana, and Polygon, where you can mint NFTs much cheaper. Each platform has its own set of rules and fees for creating and selling NFTs, so make sure you do your research because minting an entire collection can get expensive! 2) Get registered on an NFT marketplace Then you’ll need to use an NFT marketplace that supports the creation and distribution of NFTs, such as OpenSea, SuperRare, and Magic Eden. Each platform has its own set of rules and fees for minting NFTs, so it’s essential to research and compares the options before choosing an NFT marketplace to launch your NFT. Lastly, select a marketplace compatible with the blockchain you’ve decided to launch your NFT on. 3) Choose your favorite creations The most fun and exciting part is choosing the digital art that will soon become part of the blockchain forever and transform into your first NFT! This can pretty much be an image, video, or any other digital media you’ve created. However, it’s essential to make sure your digital asset is unique and not copied somewhere off the internet. Just remember, you can’t mint an NFT of someone else’s work, as that would violate copyright law and can become a legal issue. 4) Upload and mint your NFT Now it’s time to upload your digital asset and mint it as an NFT on the platform of your choice. You accomplish this with any platform-compatible crypto wallet, such as the Phantom wallet for Solana or Metamask for Ethereum. Each platform has different fee structures, so calculate ahead of time and ensure you have enough crypto to cover gas and minting fees. 5) Listing and pricing your NFT You’ll also need to provide some general information about your NFT, such as its name, description, and any other details you want to include when you list it. Try to set a realistic price for your NFT, which can be in cryptocurrency or FIAT currency if the NFT marketplace supports it. Some marketplaces allow you to set a fixed price, opt to auction your NFTs, or even leave the final price open to negotiation. Final thoughts After uploading your NFT to the blockchain, it joins a digital ledger that records its ownership and transaction history. This means that anyone who buys your NFT can verify its authenticity and ownership history, which adds more value to the NFT. In short, minting an NFT is a relatively simple process, but it’s essential to research and follow the rules of the blockchain platform you’re using. Always create unique and original digital assets, as this will make your NFT more valuable and desirable to collectors. If you have a unique digital asset that you want to turn into an NFT, go ahead and give it a try! That’s it. Happy minting! FAQ What can I mint as an NFT? You can mint any digital media, such as images, videos, music, or tweets. Blockchain games also allow you to mint unique characters out of the NFTs you have, such as “breeding” Axies to create eggs that will spawn into playable NFTs in Axie Infinity. How do I know if my NFT is authentic? Every NFT is unique and has a digital signature that verifies its authenticity. The blockchain ledger also records the ownership and transaction history of each NFT so that you can check its history on the blockchain explorer. NFT marketplaces also provide detailed information on their list of NFTs, providing an added layer of authentication. How do I sell my NFT? You can sell your NFT on a marketplace that supports the blockchain platform you used to create it. Some popular NFT marketplaces include OpenSea, Rarible, and SuperRare. Remember that they all have different fee structures, so always check that you have enough crypto to cover gas and royalty fees before making a purchase. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### NFTs: A beginner’s guide to non-fungible tokens NFT meaning Non-fungible tokens, or NFTs, are a new and exciting technology that has been gaining a lot of attention in the world of blockchain and cryptocurrency. But what exactly are NFTs and what makes them different from other types of tokens? In this blog post, we will explain the basics of NFTs, including what they are, how they work, and how they are being used in the world of art and collectibles. What are NFTs? At their core, NFTs are unique digital assets that are built on top of blockchain technology. Unlike other types of tokens, such as bitcoin or ether, which are interchangeable and can be traded for other cryptocurrencies, NFTs are unique and cannot be replicated or exchanged for other tokens. This makes them ideal for representing ownership of digital assets, such as art, collectibles, or even virtual real estate. NFTs benefits One of the key benefits of NFTs is that they provide a way to verify the ownership and authenticity of digital assets. Because they are built on top of a blockchain, NFTs are immutable and can be easily tracked and traced. This makes it much easier to prove ownership and prevent fraud, which is a major concern in the world of digital art and collectibles. Benefits of NFTs for creators One of the unique features of NFTs is that they can include royalty payments for the creator of the NFT. This means that when an NFT is bought or sold, a portion of the sale price can be automatically paid to the creator of the NFT as a royalty. This can provide a long-term source of income for the creator and can help support the creation of new and interesting NFTs. Types of NFTs There are many different types of NFTs, and each one serves a different purpose. For example, some NFTs are used to represent ownership of digital art, while others are used to represent ownership of virtual real estate or other digital assets. There are also other types of NFTs such as PFP NFTs (profile picture NFTs), gaming NFTs, music NFTs and so on. Non-fungible tokens use case One of the most popular use cases for NFTs is in the world of art and collectibles. Many artists and collectors are using NFTs to create, sell, and trade unique digital artworks. These NFTs can be bought and sold on various NFT marketplaces, such as OpenSea and Rarible, which act as digital galleries for NFT art. Most popular NFT collection – BAYC One of the most popular NFT collections is Bored Apes Yacht Club, or BAYC for short. BAYC is a collection of NFT artworks created by Yuga Labs. The collection features a variety of unique and interesting digital artworks, each with its own distinct style and theme. BAYC has become a popular destination for NFT collectors and has helped to raise awareness of the potential of NFTs in the art world. How to buy or sell NFTs? If you’re interested in buying or selling NFTs, there are a few key things you should know. First, you will need to have a wallet that supports NFTs, such as MetaMask or Coinbase Wallet. This will allow you to store and manage your NFTs securely. NFT marketplaces Next, you will need to find a reputable NFT marketplace where you can buy or sell NFTs. There are many different marketplaces to choose from, each with its own unique features and selection of NFTs. Some popular marketplaces include OpenSea, Rarible, and SuperRare. Once you have a wallet and have found a marketplace, you can start buying and selling NFTs. To buy an NFT, you will need to use a cryptocurrency, such as ether, to pay for the NFT. To sell an NFT, you will need to list it on a marketplace and set a price. In addition to buying and selling NFTs, there are also many interesting NFT collections that you can explore. For example, the Foundation collection features some of the most famous and valuable NFT artworks, while the NBA Top Shot collection features NFTs of highlight moments from NBA games. These collections can be a great way to learn more about the world of NFTs and discover new and interesting digital art. Conclusion In conclusion, NFTs are a unique and exciting technology that is changing the way we think about the ownership and authenticity of digital assets. Whether you’re an artist, a collector, or just curious about the world of NFTs, there are many interesting things that you can learn about them on our blog. If you want to make your own NFT collection, follow our guide that teaches you how to make randomly generated NFTs. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Onicore: Dev Team Lead Dmytro on integrating Global Nodes “We can pull on-chain data in seconds, even for the most complex operations. Our high-demand financial services all rely on Chainstack Global Nodes for the backbone of their operations.” Dmytro, Blockchain Development Team Lead at Onicore Onicore is a company with a clear mission: to provide businesses with the tools they need to integrate FinTech solutions seamlessly. From compliance modules to crypto payments, Onicore’s modular approach makes complex financial operations manageable for businesses worldwide. We spoke with Dmytro, Onicore’s Blockchain Development Team Lead, to learn how Chainstack supports their backend operations, ensuring reliability, scalability, and security for their customers. Challenge: How to integrate on-chain data effectively Onicore’s Cryptoforce module demanded powerful infrastructure that could support its unique and high-demand features—including crypto custody, seamless payments, and real-time transaction monitoring.  Unlike traditional custodial solutions, Cryptoforce allows clients to use the software as a SaaS platform while maintaining full control over their private keys. Transactions are signed on the client’s side, ensuring that Onicore never stores sensitive wallet information. This approach not only enhances security but also eliminates the trust barrier often associated with custodial providers, giving businesses greater confidence in managing their funds. That is why, to meet the requirements of businesses handling everything from day-to-day crypto transactions to enterprise-scale treasury management, Onicore set out on a search for a partner that ensured low-latency on-chain data access and seamless scalability. “We couldn’t afford downtime or delays,” Dmytro explained. “Cryptoforce handles everything from hot wallet operations to multi-signature cold storage, and the infrastructure needs to handle these tasks without fail.” Figure 1: Key advantages of Onicore’s Cryptoforce module; Source: Onicore And with critical FinTech services relying on accurate and fast on-chain data, Onicore’s search for a scalable, reliable solution led them to Chainstack Global Nodes. Solution: Chainstack Global Nodes “Global Nodes delivered exactly what we needed—a robust, reliable network with high-performance access to on-chain data,” Dmytro shared. “Chainstack’s predictable pricing and detailed documentation made integration straightforward, while the nodes’ throughput and uptime stood out.” By leveraging Chainstack Global Nodes, Onicore seamlessly integrated real-time on-chain data from networks like Ethereum, Solana, Base, and BNB Smart Chain. With Chainstack’s infrastructure, Cryptoforce reliably delivers its key features to businesses worldwide: Dynamic custody management: Streamlining fund transfers between hot wallets, multi-signature wallets, and cold wallets to ensure both security and liquidity are optimized. Advanced payment workflows: Supporting unlimited wallet generation for seamless deposits and withdrawals, with tools to create single-use or reusable wallets, built for different use cases. Intelligent risk control: An AML-driven engine that monitors deposits, flags suspicious transactions, and provides automated risk scores, safeguarding clients against operational risks. Figure 2: Core features of Onicore’s Cryptoforce module; Source: Onicore Today, Onicore uses Chainstack Global Nodes to provide real-time, high-throughput on-chain data for Cryptoforce. This allows businesses to monitor deposits, payouts, and internal wallet transfers with unparalleled accuracy and speed. Additionally, our infrastructure supports the execution of customizable AML checks, ensuring secure and compliant transaction management at scale. Results: Reliable infrastructure for growing demands With access to the globally distributed and geo-load-balanced fallback chain of our Global Nodes, Onicore guarantees maximum uptime and automatic failover. In turn, this level of reliability has become essential for Onicore’s operations, empowering them to offer high-demand FinTech services without interruptions—no matter where their customers are located. Chainstack Global Nodes have allowed Onicore to achieve: Uninterrupted service: Cryptoforce handles high-throughput operations and complex crypto custody tasks without delays or interruptions. Scalable performance: Chainstack Global Nodes scale seamlessly with Onicore’s growing customer base and evolving business requirements. Developer-friendly integration: Our comprehensive APIs and docs enabled Onicore’s team to integrate quickly, cutting development time and delivering new features faster. “Chainstack Global Nodes have become our infrastructure MVP,” Dmytro said. “We can deliver secure, fast, and scalable solutions to our customers, knowing the infrastructure will perform flawlessly at any scale.” Figure 3: Chainstack Global Nodes guarantee 99.95%+ uptime; Source: Chainstack “Onicore has created a truly transformative solution with Cryptoforce. By simplifying crypto custody, payments, and compliance for businesses, they’re redefining FinTech. Supporting Onicore’s success highlights what’s possible when you combine groundbreaking technology with reliable Web3 infrastructure.“ Eugene Aseev, CTO and Co-Founder, Chainstack Feedback: Enabling custom traces for precision data insights One of Onicore’s priorities for improving operational efficiency was accessing custom traces for EVM-compatible chains. Custom traces allow developers to retrieve only the specific, targeted data they need, avoiding unnecessary payloads and improving resource utilization. “For large blocks with thousands of internal calls, retrieving all the data creates massive inefficiencies,” Dmytro explained. “Custom traces let us filter exactly what we need, reducing overhead and optimizing performance.” While Chainstack already provides robust Debug & Trace functionality, Onicore highlighted custom traces as a key area for future collaboration. This feature would enable them to further streamline their high-volume blockchain operations, enhance analytics, and optimize compliance workflows. “Custom traces allow us to retrieve only the data we need, cutting down on overhead and improving efficiency,” Dmytro noted. “It’s a tool that enables us to stay ahead in delivering fast, reliable services to our customers.” We remain committed to incorporating customer feedback like Onicore’s to continually refine our offerings and deliver features that meet evolving business needs. Outlook: What’s next for Onicore and Chainstack Onicore plans to expand network integrations and strengthen its analytics capabilities, taking Cryptoforce to the next level. With Chainstack Global Nodes, they’re well-positioned to achieve this: New network integrations: Onicore will add support for emerging chains, expanding their capabilities to meet growing customer demands in industries like DeFi, institutional trading, and cross-border payments. Enhanced analytics tools: By leveraging real-time and historical on-chain data, Onicore plans to deliver advanced monitoring, reporting, and compliance features. These upgrades will empower businesses to analyze transactions, optimize operations, and ensure transparency. “Our next goal is to integrate more protocols and offer deeper analytics for our customers,” Dmytro shared. “With Chainstack, we have the confidence to scale quickly and keep delivering new solutions as our business grows.” Chainstack will continue to play a pivotal role in Onicore’s growth, providing the infrastructure and flexibility needed to explore new opportunities for the team to innovate at scale. With Global Nodes ready to scale, Onicore can confidently do that, delivering next-gen analytics and chain integrations. Conclusion: Bringing it all together Onicore’s story with Chainstack highlights the power of reliable, high-performance infrastructure. By solving key challenges—such as managing secure crypto custody, enabling seamless payments, and delivering real-time on-chain insights—Chainstack Global Nodes have enabled Onicore to redefine what businesses can achieve with Cryptoforce. With Chainstack infrastructure, Onicore is now positioned to take the next leap in its growth journey. They can seamlessly scale operations, explore emerging blockchain networks, and deliver advanced analytics that empower businesses to optimize and expand their financial services. Partnering with Chainstack has accelerated Onicore’s ability to innovate, execute compliance checks effectively, and serve its customers without limitations. For businesses striving to achieve similar results, the key lies in selecting infrastructure that’s built for the demands of today’s FinTech landscape and ready for tomorrow’s growth. Chainstack Global Nodes empower companies like Onicore to focus on innovation, confident that their backend can scale reliably with them. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Open standards for enterprise blockchain implementations Spearheaded by the Enterprise Ethereum Alliance Image credit: Pexels (modified) Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Enterprises now have multiple options to choose from when it comes to selecting distributed ledger technologies (DLT) and consensus protocols. The popular options include Ethereum, Hyperledger Fabric & Sawtooth, Quorum, MultiChain, and Corda. Any organization can implement these protocols on modified code bases where client DApps that interact with various versions of these protocols use custom APIs and tools developed by each organization. The client’s DApps and their APIs could be proprietary solutions, where an enterprise is locked into a single vendor for development and support. A choice of multiple DLT protocols to choose from is great for the enterprise blockchain industry. Without open standards, however, adoption in the industry will be difficult for consortia (representing a collection of organizations) as each of them need to figure out their own set of standards, in addition to figuring out how they will govern their consortium, both on-chain and off-chain. The Enterprise Ethereum Alliance (EEA) consists of more than 500 member organizations and their central goal is “to deliver an open, standards-based architecture and specification” to speed adoption of Ethereum. EEA’s goal is to create a universal set of practices that everyone will follow when designing blockchain applications. Open standards help to ensure that a DApp, for example, created by one project is compatible with the blockchain running on the same protocol built by another project. The Hyperledger Project oversees several open source projects that help blockchain developers. Their mission is to promote open source code within the blockchain space. In October 2018, both the Enterprise Ethereum Alliance (which Quorum is a member of) and the Hyperledger Project announced a partnership in which they each signed up as members of each other’s organization. The aim is to develop open standards for enterprise blockchain implementations jointly. Enterprises adopting a DLT protocol are not obliged to follow the EEA’s open standards. However, it is advised that they do so with their implementations to reduce implementation effort, allow solution compatibility with capabilities and tools that abide by these open standards, and facilitate easier growth of consortia (the primary purpose of DLT protocols). The EEA published version 2 of a client specification and version 0.5 of Off-Chain Trusted Compute Specification in late October 2018. Enterprise Ethereum is based on technologies and concepts of public Ethereum, but this time extending it to meet the performance, permissioning, and privacy demands of enterprises. Client specification 2 highlights The client specification defines the implementation requirements for Enterprise Ethereum clients, including interfaces to the external-facing components of Enterprise Ethereum and how they are intended to be used. This enables an ecosystem where users can change the software they use to interact with a running blockchain, instead of being forced to rely on a single vendor for support. The EEA Architecture stack provides a layered reference model that differentiates between the components available on public Ethereum, and components that enterprises require on their client implementations.   Enterprise Ethereum Architecture Stack The architecture stack for Enterprise Ethereum consists of the following five layers: Application: Consists of DApps, tools to monitor the blockchain, infrastructure contracts and standards (e.g. for role-based access, control network governance), and smart contract development tools Tooling: Contains APIs used for clients to communicate with blockchain nodes, integration with enterprise identity management, and deployment management capabilities Privacy and Scaling: Implements privacy and scaling extensions needed to support enterprise-grade deployments. On-chain privacy mechanisms are being explored such as support for zero-knowledge proofs. Scaling is achieved on two layers. Layer 1 is on-chain and uses mechanisms such as sharding and parallelization. Layer 2 is achieved at the application layer utilizing smart contracts with techniques such as Plasma, State Channels, and Off-Chain computing scaling mechanisms (as per v0.5 of the Off-Chain Trusted Compute Specification). Core Blockchain: Consists of a mechanism to establish consensus between nodes for the acceptance of new blocks and the execution and storage of transactions, both on and off-chain. Network: P2P networking protocols facilitating node interaction (e.g. DEVP2P at present and additional P2P protocols at higher layers of the enterprise stack in the future) Off-Chain trusted compute specification version 0.5 highlights One technique that enterprises can use to increase DLT performance is to execute transaction off-chain within a trusted environment. This draft specification provides a set of APIs that can move transactions off-chain for computation elsewhere, and then move a summary to the “main chain”. The Off-Chain Trusted Compute Specification Version 0.5 has been designed to support the following enterprise needs: Private transactions on a blockchain between mutually-untrusting parties without disclosing transaction details to other parties who also have access to the blockchain Disclosure of partial information to chosen parties on a blockchain, while maintaining the confidentiality of other information from those same chosen parties Offloading selected transactions from the main blockchain to a trusted compute environment to improve performance Attested oracles to provide trusted external information needed for some enterprise use cases These APIs have been reviewed for compatibility with the following trusted compute methods: Trusted Execution Environments (TEEs) Zero-Knowledge Proofs (ZKPs) Trusted Multi-Party-Compute (MPC) The EEA requirements for the Tooling layer (on node and transaction permissioning capabilities, enterprise remote software deployment and configuration, software fault reporting, performance management, security management interaction, historical analysis, and reporting capabilities), and the scaling requirements in the Off-Chain Trusted Computing specifications are of particular interest to us at Chainstack. We’re monitoring the latest EEA developments and aim to align with their open standards to support rapid, enterprise-grade client deployment, monitoring, and build of blockchain implementations. References Enterprise Ethereum Alliance Releases Specification V2 Accelerates Blockchain’s Path to Global Interoperability across Entire Industries, Press Release, Enterprise Ethereum Alliance Enterprise Ethereum Alliance Releases Trusted Compute Application Programming Interfaces to Help Enterprises Get Blockchain Applications to Market, Press Release, Enterprise Ethereum Alliance EEA Specification v2, Enterprise Ethereum Alliance EEA Off-Chain Trusted Compute Specification V0.5, Enterprise Ethereum Alliance EEA Architecture Stack Explained (Video), Enterprise Ethereum Alliance EEA Architecture Stack, Enterprise Ethereum Alliance Hyperledger and Enterprise Ethereum Alliance Join Forces In Enterprise Blockchain Boost, Aaron Stanley, Forbes   Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Optimism blockchain – Ethereum Layer 2 scaling solution One of the most widely used blockchains for smart contracts is Ethereum; As more users sign up, the network becomes more expensive and slower. However, there are many scaling options (layer 2 chains) like Polygon, Optimism, and Arbitrum exist which can scale Ethereum to make it faster and cheaper.  What are Layer 2 chains?  The phrase “Layer 2”, or L2 refers to a protocol that is based on an existing blockchain and used to address the scaling issues of Layer 1 (L1) blockchains. As mentioned above, it is quite challenging for blockchains like Bitcoin and Ethereum to process thousands of transactions per second, which makes the blockchains slow and expensive. This is where layer 2 solutions come into play; these solution helps to scale these existing blockchain.  The current blockchains are not replaced by layer 2 chains. Although layer 2 chains would do the majority of the work, layer 1 serves as the main chain and gives security while layer 2 offers quick transactions, low transaction fees, and the ability to process thousands of transactions per second.  What is Optimism?  Optimism is a layer 2 chain that is built on top of the Ethereum blockchain. Optimism reduces transaction fees and speeds up Ethereum transactions. While every transaction happens on the Optimism, the data is posted to Ethereum and validated there.  With more than 313 million USD locked in its smart contract as of this writing, Optimism is the second-largest layer.  How does Optimism work?  Optimism uses advanced data compression technique known as Optimistic Rollups. They are new methods of scaling the Ethereum blockchain developed by the amazing team behind Optimism Foundation. Rollups can be divided into two categories: optimistic rollups which it developed by the Optimism Foundation, and ZK rollups, often known as zero-knowledge rollups.  Rollups significantly increase processing speeds by moving a large amount of transactions data off-chain. Unlike other sidechains, optimistic rollups still publish a small amount of data on the decentralized layer 1 network to be validated which would increase the security.  Optimistic rollups do not publish proofs of validity for transaction batches posted on-chain since they presume off-chain transactions are valid. This separates optimistic rollups from zero-knowledge rollups that publish cryptographic proofs of validity for off-chain transactions.  In order to stop invalid state transitions from happening, optimistic rollups rely on using fraud proofs. To do this, an Ethereum Optimism transaction must be executed. In simple language, between Layer 1 and Layer 2, the OVM, or Optimistic Virtual Machine, is a sandboxed environment that ensures deterministic smart contract execution.  Because they both serve to execute computation, the OVM and EVM are similar. The OVM, however, just acts as the EVM’s interface. You can see that virtualization occurs through the Execution Manager by comparing EVM and OVM execution.  The Solidity compiler converts Solidity to Yul, which is subsequently converted into EVM Instructions, and eventually into bytecode. After compiling to EVM assembly, you can “rewrite” each opcode in its OVM variant if necessary.  Optimism Bridge  Even though Optimism is a layer 2 chain connected that is connected to Ethereum, it is also a separate blockchain system, meaning if you want to transfer a data from one blockchain to another blockchain, you will need to use a bridge.  A bridge connects two chains and allows NFT (Non-Fungible Token), tokens, and other arbitrary data to be transferred between them.  For common use cases such as moving tokens between blockchains, you can use Standard Token Bridge. It is a smart contract created by the Optimism team and has all the features required to transfer tokens between Ethereum and Optimism.  However, if Standard Token Bridge does not entirely cover your use-case, you can send data between L1 and L2 using the following approach.  Communication basics between layers  Communication between L1 and L2 is enabled by two unique smart contracts known as “messengers.” Because each layer has its own messenger contract, some lower-level communication elements are abstracted away. Here is an example of sendMessage function which is attached to each messenge written in Solidity.  function sendMessage( address _target, bytes memory _message, uint32 _gasLimit ) public; Here is another example, in case you want to call a contract on optimism from a contract on Ethereum.  // A L2 contract contract MyOptimisticContract { doSomething(uint256 myFunctionParam) public { // ... some code goes here } } // And pretend this is on L1 contract MyOtherContract { function doTheThing(address myOptimisticContractAddress, uint256 myFunctionParam) public { ovmL1CrossDomainMessenger.sendMessage( myOptimisticContractAddress, abi.encodeWithSignature( "doSomething(uint256)", myFunctionParam ), 1000000 // use whatever gas limit you want ) } } code from optimism docs  Speed  The calls between Ethereum and Optimism are not instantaneous meaning the exact speed of transactions depends on the directions in which the transactions are sent.  For Layer 1 to Layer 2 transactions  A transaction sent from L1 to L2 can take up to 15 minutes to reach the target L2 contract on the mainnet and 5 minutes on the Optimism Goerli testnet. This is due to the fact that L2 nodes often wait for a certain number of Ethereum block confirmations before performing an L1 to L2 transaction.  For Layer 2 to Layer 1 transactions  The interactions between Layers 2 and 1 cannot be sent for at least a week, so messages sent from Layer 2 will only be received after the week has passed.  It takes a few seconds on goerli and seven days on mainnet to complete the challenge, often known as the fault challenge period. This waiting period is intended to keep Optimism’s functionality secure.  Decentralized and Centralized  You can use Optimism’s message infrastructure to create fully decentralized applications. You can issue a single L1 transaction to allow layer 1 code to call layer 2 at any moment or to update the code.  However, it can be a little challenging to send messages from layer 2 to layer 1. You must initiate a transaction on layer 2 first, then when the fault challenge period has passed, you must initiate a transaction on layer 1 that includes a merkle proof. Due to the high cost of merkle proof verification, this is expensive.  If your app is on a centralized server, the most straightforward approach is to have two providers, one connected to Layer 1 (Ethereum) and the other to Layer 2 (Optimism).  Conclusion   The sole purpose of this post was to provide you with an overview of the Optimism blockchain and the interaction between Optimism and Ethereum. More about optimism and its mechanism will be covered in upcoming posts.  👋 Thanks for reading, See you next time  Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Peanut.trade on Chainstack: running market-making at scale “With Chainstack, we’ve achieved consistently high uptime without the overhead of managing our own infrastructure. The Unlimited Node flat-fee model gives us cost predictability, and the performance is rock-solid — which is absolutely critical for on-chain market-making operations.” — Oleksandr Holofaiev, COO, Peanut.trade Peanut.trade runs high-frequency trading, arbitrage, and market-making on decentralized exchanges (DEXs). It works with token teams to keep liquidity deep and prices stable across on-chain markets. At this scale, even a few seconds of lag or downtime can mean a missed trade and a partner losing confidence. That’s why infra sits in the critical path.  What is Peanut.trade? Peanut.trade helps crypto projects and traders refine their on-chain trading tactics by running algorithmic trading strategies — from cross-exchange arbitrage to automated market-making — across multiple DEXs and blockchains. For token projects, this means deep liquidity and proper pricing. For arbitrageurs and liquidity providers, it means tools to exploit price gaps as soon as they open. Because everything operates live across chains, here reliability is non-negotiable. Trade execution and price updates must clear without delay. Any slippage, stalled order, or imbalance in a pool directly affects partners depending on Peanut.trade’s market-making. That’s why reliable infra for Peanut.trade underpins every trade the platform executes. From in-house nodes to Chainstack  Peanut.trade first ran its own nodes, tracking uptime, headlag, and latency. As Solana and Base are resource-heavy, the team spent a growing amount of time patching, updating, and tuning. When trading volumes increased and new chains were added, that overhead escalated into a major pain point, pulling attention away from algorithm development and trading logic. Peanut.trade also turned to third-party node providers to reduce the in-house overhead. This worked for a while, but new bottlenecks showed up quickly. Some providers couldn’t keep pace with high-frequency trade execution, especially under heavy network load. Others promised reliability on paper but still hit outages or rate limits — usually at the exact moments Peanut.trade needed low-latency access most.Cost models added another layer of friction. Usage-based pricing looked simple until surges in on-chain activity — like token launches or volatile trading windows — drove API request counts through the roof. With usage-based pricing, higher volumes pushed bills up unpredictably.  After hitting those limits, Peanut.trade switched to Chainstack for steady uptime, cross-chain throughput, and predictable costs. Why Peanut.trade chose Chainstack With Chainstack Peanut.trade runs key operations across several blockchains, such as: Balance monitoring Wallet sync Transaction tracking and retrieval (getAccountInfo, getTokenBalance, getTransactions) The team adopted Chainstack’s Unlimited Node plan with flat-fee pricing, covering all RPC and node operations without usage caps: Predictable pricing: The Unlimited Node plan removed per-request fees and throttling allowing them to make as many RPC calls and transactions as wanted across supported chains, for a fixed monthly rate.  Performance and uptime: Chainstack nodes sustain high throughput with low latency. Even under heavy load, Peanut.trade gets real-time data and fast execution.Consistent uptime, backed by SLAs and 24/7 monitoring, keeps operations live during volatile markets. Monitoring and insights: The console shows node usage, API metrics, and error rates, helping the team spot anomalies early and scale ahead of demand. Support: Support is rarely needed in production. During migration, the Chainstack team helped with tuning and integration. With Chainstack’s multi-chain coverage, Peanut.trade now runs on Solana, BNB Chain, Base, and more — from one platform, aligning with their growth strategy. Workload profile Peanut.trade’s trading engine runs at a scale where node performance directly impacts execution. Over the last cycle, Peanut.trade processed more than 500 billion API requests across archive and full nodes. On archive nodes (≈157B requests): eth_getBalance — 7.71% eth_call — 55.79% eth_getLogs — 9.98% eth_getBlockByNumber — 9.21% eth_subscription — 8.32% On full nodes (≈260B requests): eth_call — 21.57% eth_subscription — 14.26% eth_getBlockByNumber — 10.67% eth_getTransactionReceipt — 8.03% eth_getLogs — 6.33% The bulk of requests were state lookups and subscriptions. Archive nodes were used for history and balances, full nodes for execution. Unlimited Node kept up without rate limits or billing spikes. The bulk of requests were state lookups and subscriptions. Archive nodes were used for history and balances, full nodes for execution. Unlimited Node kept up without rate limits or billing spikes. Results with Chainstack Since shifting its infrastructure to Chainstack, Peanut.trade has seen clear gains in performance and efficiency. With 99.9%+ uptime, the system keeps bots live and able to react to market changes in real time. Flat-fee billing also changed how the team manages costs. Spend is fixed each month, even when volumes jump. Compared to usage-based plans, spend is fixed each month, even when volumes jump, saving money and removing the need to track every call. On execution, Peanut.trade’s algorithms now pull state and broadcast transactions with minimal latency. For arbitrage opportunities that may last only seconds, that consistency has meant more fills before spreads close and tighter markets on DEXs. Internally, developers are no longer tied up maintaining nodes. Their focus is back on building strategies and adding features, which has sped up onboarding for new token projects and the development of trading tools. Partners have noticed the change too. Token teams depending on Peanut.trade’s market-making see reliability around the clock. Being able to commit to liquidity with confidence has strengthened trust — and in on-chain markets, that consistency is what sets a provider apart. These outcomes also highlight why we back teams like Peanut.trade. Keeping markets liquid at this scale depends on infrastructure that stays reliable when traffic peaks — and that’s where Chainstack comes in. “On-chain trading and arbitrage are the lifeblood of decentralized markets, and Peanut.trade is at the forefront of this space. Their platform brings much-needed liquidity and efficiency to DEX ecosystems. We are proud to support Peanut.trade’s mission by providing the dependable, high-performance infrastructure they need to operate flawlessly 24/7.”  — Eugene Aseev, Founder & CTO, Chainstack  Bringing it all together Peanut.trade moved from a mix of self-hosted and third-party nodes to Chainstack to keep market-making steady at scale. They now run Solana, BNB Chain, Base, and more on Global Nodes, all managed from one console. With the Unlimited Node plan, the team processes more than 500B API calls per cycle under a fixed monthly spend. For history and state-heavy queries, Archive nodes cover balances and reconciliation. WebSockets stream fills and state changes for real-time trading logic. With uptime backed by SLA, the system holds up under volatile conditions, so engineers can spend their time on strategies instead of node maintenance. Peanut.trade now has consistent performance across networks, stable costs, and the headroom to expand. Chainstack provides the infrastructure; Peanut.trade builds the markets on top of it. More ways teams use Chainstack Peanut.trade solved market-making at scale. Other projects leaned on Chainstack for different reasons: Kiln needed to keep $13B+ in staking rewards transparent. Subgraphs and globally distributed nodes carried the load. QuickSwap pushes more than 2B RPC requests each month. Dedicated Polygon nodes gave their DEX the throughput to handle it. Lynx runs a perpetuals platform where downtime isn’t an option. Global Nodes kept their latency tight through volatile trading. #### Permissioned blockchains are here to stay and why Ethereum will help it By Syahrul Nizam, Chainstack Developer Advocate A Permissioned Blockchain isn’t a blockchain! Everyone on r/cryptocurrency Or is it? As a developer advocate over at Chainstack, I’ve worked closely with both developers who are creating on top of Ethereum and support has been great. It help’s that Ethereum has a great developer community. In fact, it’s the most mature decentralized platform, with thousands of DApps being created regularly. I also came from a background as a hobbyist solidity developer back in my college days. My role here at Chainstack also involves me regularly creating decentralized applications as demonstrators. Blockchain is the future and many Enterprises are currently prototyping and experimenting with their own versions of DApps. Yet there are some limitations that are preventing even more Enterprises in trying out Blockchain. I list them down in the following parts. Slow transaction times One of the issues that constantly bugged me when interacting with my DApps was that DApps are inherently slow. Transactions have to be mined by miners, and even with the release of Ethereum 2.0, the responsibility of including transactions in the next block will be shifted to staking nodes. Despite, Ethereum’s significantly block times of approximately 15 seconds, this is still a considerable wait compared to centralized applications — where function calls are near-instant. Yes, the wait involved for our transactions to be propagated and confirmed is not an issue for some DApps (compound.finance), but it significantly kills of many potential use cases for a decentralized system. Ether as an incentive token Let’s also touch base with the fact that Ether is needed to make transactions on the blockchain. Ether has value because to interact with function calls on the EVM, it is used as fuel to pay the miners. This is undoubtedly a fair system. However, many companies are unwilling to purchase Ether from the market and be at the mercy of massive price fluctuations. Lack of privacy Data is not encrypted by default on the blockchain. This means that anyone can read the data freely. Obviously, this isn’t something that an enterprise wants. Quorum Enter Quorum — a fork of the Ethereum Blockchain developed by JP Morgan. The fact the team over at JP Morgan has decided to fork Ethereum instead of developing a new permissioned blockchain from the ground up speaks volumes about the acknowledgment that JPM is giving to the Ethereum team. Quorum is almost the same as Ethereum, except that: No more miners involved All transactions are free Private transactions are possible Smart Contracts on quorum are also written in Solidity, and all Ethereum development tools that currently work on Ethereum works on Quorum. Frameworks such as truffle work beautifully on Quorum, and there’s even a dedicated part of truffle’s documentation for Quorum! Even better — Metamask can connect to Quorum nodes as if they’re normal Ethereum nodes. The Web3 libraries also work just as how you would expect when interacting with the Ethereum Network. It’s trivial for Ethereum developers to jump over to Quorum, their skillsets are still highly relevant. It can be seen why JPM decided to base Quorum of Ethereum, the Ethereum development scene is highly mature and the myriad of tools make it easy for Quorum to grow. Ethereum and Quorum are two sides of the same coin. The growth of Quorum is highly dependent on how Ethereum changes. As the number of developers for Ethereum grows, the number of Quorum developers indirectly increases too. Just use a database, bro One of the many arguments against permissioned chains is that they’re inherently not decentralized, and thus using a normal database (which is much more efficient) would suffice. There is some truth to this statement, yet trust isn’t a black and white issue with only two options. Trust between companies exists on a spectrum. Let’s take a look at a fictional consortium of companies who all sell chicken. They’ve decided that every year, each chicken will sell for exactly for $2, and only 2000 chickens will be sold per year. How can Company A be sure that Company B is not selling chickens at a lower price and at the stipulated 2000 chickens per year? That’s why contracts are needed. They punish companies who do not follow the agreed rules. Yet, companies can often obfuscate their sales by releasing chickens to the black market for example. This is where a blockchain comes in. Company B can expose the prices of the chicken that is being sold as well as the quantity to other members in the consortium. Company A, C, D can all check on each other that they are indeed following the terms in their agreement as a consortium without needing an external auditor. Quorum’s capability to make private transactions also mean that Companies can hide data that they want to share with certain companies but not others. We can see the strength of a permissioned blockchain (or ledger) in the case of a consortium. Continue working on Ethereum It’s okay if you’re not working on Quorum now — just continue with your passion and build amazing DApps on Ethereum. Grow the Ethereum community. Build robust smart contracts that are safe and secure, while still being efficient. When your company decides to get started on blockchain use cases, recommend them the Ethereum that you love. I’m confident that they will then move to Quorum since it offers the benefits of Ethereum without its flaws. That’s why at Chainstack we have support for both Ethereum and Quorum (7-day trial) — they’re both essential to the decentralized space. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Perspectives with Paul Sitoh – part 1 Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. We sat down with Paul Sitoh virtually, with him in London and us in Singapore. Paul has extensive experience working on blockchain and cloud technologies, and currently heads Blockchain at Elemental Concept and Aladdin Technologies Ltd. in the UK. In this inaugural two-part interview as part of Chainstack’s Perspectives series on our blog, we discuss his journey into the world of the blockchain, his involvement with Hyperledger Fabric, enterprise blockchains, deployment, and several other topics. Perspectives is a series of interviews, where we sit down with industry experts and thought leaders within and beyond the blockchain space. Note: This interview has been edited and condensed for clarity. Paul, with your couple of decades of experience as a technologist, could you start off by telling us about your experience with various technologies and how you actually entered the world of blockchains? After my university in the UK, designing and building Enterprise Resource Planning (ERP) systems was my first choice of career. This was followed by a stint in creating an object-oriented database for the construction industry. I was part of a team trying to build a customized object-oriented database. In the building industry, everything easily fits into an object or a rule, and we wanted to provide a way to extract objects easily. I returned to Singapore to work on a project called CORENET, a government initiative to digitize every building in the whole of Singapore. That was my first brush with something that might be vaguely called ‘smart contracts’. We didn’t call it smart contracts then, but, essentially, we were taking regulation and marking it up in English, so that it could be converted into a computer executable business logic. That opened the possibility of something, which is referred to as a Ricardian contract. I later had stints working in the supply chain and payments industries. So my eventual interest in blockchain was a culmination of all those years of working with various technologies and a variety of problems. As for getting my hands into it, I got the opportunity at IBM. Unlike most people, it wasn’t cryptocurrency or Bitcoin that drew my attention- It was the possibility of using Ricardian contracts and solving pain-points of integrating fragmented systems. So was that the aha moment, the fact that with a blockchain, you could now automate the kind of contracts you were thinking of several years ago? Yes, it was. And that was also the time I got introduced to Ethereum’s smart contracts. And while not smart in the actual sense, it was a flashback to what I was trying to achieve way back — of using plain English to turn it into an executable. That led me further down the blockchain and its possibilities. At this point in time, there are so many interesting things happening in the world of the blockchain, from governance models to the potential that tokenization holds. What areas do you find most exciting in terms of principles or practicality? Having been exposed to the supply chain industry, I can now say that blockchain could certainly solve so many areas in the supply chain industry. This is one field that’s so fragmented, but one that requires a whole new way of thinking. I find people talking about how can they put documents on the blockchain. This only means that they are trying to force fit a powerful new way of doing things into a conventional mindset. Talking about the conventional mindset, is it a fool’s errand to think of blockchain to solve world-scale problems? We could certainly try using blockchain to enfranchise the billions of unbanked in the world. This is lofty indeed. But why not start small, really small? For example, two companies that don’t want to expose their APIs entirely to each other but need to do transact could use a blockchain. This is a textbook case and a real one at that in my experience. Could you dig deeper into this example and tell us what were the scenarios before and after a blockchain was introduced? When we started working with these two entities, they were sharing information via Excel files. They needed to transact and make payments depending on a checklist of done/not-done items, but they were also partially trusting of each other. We originally misunderstood it as a payments problem, but it was quite simply about lack of trust and information sharing. Further, communication and transactions could get quite messy to reflect policy changes. This would, in turn, require another set of updated Excel files. In fact, our initial suggestion of a blockchain was met with an unqualified refusal. After all, why would two companies that operated in a distrusting loop want to expose transactions on the public blockchain? It’s only when we clarified that we would use a permissioned blockchain and, furthermore, no cryptocurrency, that we were able to win them over. A fair bit of consulting and design thinking workshops also helped in articulating how things would work on the blockchain. Coming from a traditional mindset and a regulated industry, I doubt we would have been able to convince the companies without those efforts. When we did finally move the business process to a blockchain, it addressed every one of their bottlenecks in a short span of time. Even as a proof-of-concept and with a system far from flawless (we were using Hyperledger Fabric version 1.0 Alpha release), the two entities reaped more benefits than they could have possibly imagined. Note that for over four years, the two entities had struggled to come up with a risk-free way to open up information to each other. Seen in that context, the blockchain was a leap into the future. There are several businesses that need help articulating the problem they are trying to solve and deciding whether or not they even require a blockchain in the first place? How do you go about using design thinking or any other tool to help such businesses? Design thinking starts off with a persona and their pain points. This approach is helpful in very many cases. In my experience with companies and helping them suss out the need for a blockchain, starting with a persona can be restrictive. Instead, I have found greater value in following an isolate-and-iterate approach.By this I mean, trying to isolate and going directly to the problem and looking at the actors involved. “I then follow an iterative question-answer approach that involves asking the customer ‘What if they were to use a centralized database? Is that a possibility?’, ‘Are they prepared to use a centralized intermediary?’, ‘What’s the level of trust between the two parties: complete trust, partial trust, distrust?’, ‘Do they need provenance and immutability?’, and so on. It’s when all the boxes are ticked that the problem becomes a legitimate use case for a blockchain.” What’s more important, we don’t employ a big-bang approach where blockchain is introduced to change everything. Instead, we slice out a large chunk of some business process into smaller ones and drilling down to the one clear process, where blockchain can make a difference. Once these parts have been accomplished, it’s just a matter of making the right architectural choice in terms of whether it should be a public or permissioned blockchain. This interview continues in part 2. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Perspectives with Paul Sitoh – part 2 Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. This is a continuation of Chainstack’s interview with Paul Sitoh. Read part 1 here. Perspectives is a series of interviews, where we sit down with industry experts and thought leaders within and beyond the blockchain space. Note: This interview has been edited and condensed for clarity. Are there any blockchain projects that you find particularly interesting, either in terms of technology or in terms of what they are trying to achieve? I find Quorum and its adoption of zero-knowledge proofs particularly fascinating. Back in the days, I remember that when we were looking at the use of channels to transact privately between two parties in Hyperledger Fabric, there was a great degree of confusion. Channels could be mistaken for isolated pieces of private communication between two parties, but rather they are more like subnets within a larger network. Zero-knowledge proofs could have avoided all that confusion; especially when there’s no need to exchange data but only to affirm that the data is held by the other party. In fact, most business processes could well do without any exchange of data or movement of documents and, instead, simply rely on recording events and sharing those. A case in point is property deeds-Why does one have to wait for physical documents to indicate transaction finality? Why not just indicate the transfer of ownership on a digital ledger contingent once certain boxes have been ticked? Can enterprise blockchains unlock value through decentralizing some processes? Are enterprise blockchains even realistic, considering that enterprises largely operate in a competitive environment, and enterprise blockchains require a great degree of collaboration? Let’s go back to the case of supply chains. In my past experience with a global auto manufacturer, I remember the difficulty involved in the exchange of data because of the use of different file formats among a large number of players in the ecosystem. But in a supply chain, by nature, parties should be collaborating to some extent. With that as a starting point, a blockchain can be a good fit where parties that need to transact with each other can arrive at a consensus in a more straightforward manner. A concern that most businesses have with blockchains is the total transparency involved. How can competitors still be part of a consortium but go about their competitive moves of, say, offering a larger discount to their key customer without letting its competitor know? That’s where enterprise blockchains with their permissioned approach and Hyperledger Fabric’s channels or zero-knowledge proofs can come into play. “ A lot of education is required to assure companies that using a blockchain won’t lead to disruption to the point of extinction. Instead, it is a powerful tool to reduce friction and lower or, perhaps, eliminate the cost of intermediaries. Such focused messaging can be more impactful than talking about grandiose ideas of industry disruption.” You touched upon communication privacy and channels. In terms of architectural design, is there any other protocol that appears to have addressed privacy in an elegant manner? Quorum does a good job with its use of constellation. One disadvantage is that all the keys are stored on a node, and so all hell breaks loose if the node is compromised. Z-cash with its use of zk-SNARKS is also extremely interesting except that it is computationally intensive. Simplistically put, in my ideal world, one would have zk-SNARKS without its downtime, because the use of extensive crypto-material in the wake of quantum computing could spell disaster. On the topic of deployment, once companies have decided to use a blockchain, where are the hurdles? A key aspect in several companies is a reservation towards the use of the cloud to deploy nodes. Not every business wants to move to the cloud, nor can everything be moved to the cloud. So the ability to deploy a blockchain node on-premise or in a hybrid manner is becoming increasingly important. Consequently, blockchain solution providers that are able to offer an on-premise or hybrid deployment would have a distinct advantage. On that note, do companies you come across have the expertise to successfully deploy a blockchain? Because all said and done, there is a fair bit of complexity in deploying nodes and getting a group of participants to work on a blockchain. Blockchain deployment is complex indeed. And there are various levels where this complexity comes to the fore. In general, bringing together a consortium is a tall order. Managing permissions or governance among consortium members is another difficult topic. Key management is tricky. So, yes, setting up a bare-bones blockchain node is simple enough. But to get the most out of a blockchain, one has to navigate several technical challenges. Regardless of how easy it is to set up a blockchain, there are challenges that cannot be avoided. Taking the question of deployment complexity further, it is a known fact that the level of maturity in tools for blockchain software development still has a long way to go. What’s your checklist for the blockchain ecosystem so that companies can start adopting blockchains in a faster or cost-effective manner? Tools for software developers is definitely a big piece of the need-to-improve landscape. My involvement with the Hyperledger Sawtooth team and interacting with the Hyperledger Fabric protocol highlights how important it is to abstract operational complexity so that developers can focus on creating application logic. Overall, there is still a dearth of robust tools e.g. testing tools for Solidity, and, in particular, tools for rapid deployment on a cloud or in hybrid environments. The latter is where, I believe, Chainstack’s offering can make the entire deployment process so much easier for individual developers and enterprises alike. Any final words or advice for our readers and the blockchain development community at large? My advice is to approach blockchain as you would approach any other problem in software engineering. I don’t believe there is an exclusive form of developer such as a ‘blockchain developer’. As for learning, it is best to get one’s hands dirty and learn through trial and error instead of being fixated on any certification. To be good at blockchain development, it is important to start seeing from the view of an architect, to step back from the code and see the bigger picture, to determine how a blockchain fits into a business’ current scheme of things, and how it can benefit that business. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Picking an enterprise blockchain protocol to develop on: Corda, Kotlin & Java Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. As a Kotlin developer;As a Java developer. In brief This post is a part of the multipart series aimed at developers looking to try their hand out at and get a taste of the enterprise blockchain world. This post focuses on running a “Hello, Block!” smart contract on Corda for developers primarily comfortable with Java and Kotlin. Architecture On Corda, a smart contract is called a CorDapp. Each CorDapp consists of a contract and a flow. The contract establishes the transaction validity, and the flow automates the logic of the exchange between the involved nodes. A CorDapp must be installed on each of the nodes involved in an exchange. Unlike in public blockchain protocols, the smart contracts are not propagated to all nodes in the network. Each exchange is notarized by a separate node called the notary. Ecosystem Corda is mainly driven by R3 developers—R3 is the company behind Corda. Prerequisites A Chainstack account. Two Corda nodes. See Deploy a consortium network and Add a node to a network. Corda “Hello, Block!” in Kotlin Smart contract View the code on Gist. State View the code on Gist. Flow View the code on Gist. Source on GitHub. You can clone the “Hello, Block!” repository to see the full code and experiment with it. Corda “Hello, Block!” in Java Smart Contract View the code on Gist. State View the code on Gist. Flow Flow View the code on Gist. Flow responder View the code on Gist. Source on GitHub. You can clone the “Hello, Block!” repository to see the full code and experiment with it. Build the smart contract and the flow To build the contract and the flow, run ./gradlew build in the root of the cloned repository. This will build the contract and the flow JAR files: /contract/build/libs/contracts-0.1.jar/workflows/build/libs/workflows-0.1.jar Install the smart contract and the flow Install both the contract and the flow on each of the two nodes you deployed. See Installing a CorDapp. Connect to one of the nodes To be able to interact with the CorDapps, you must have the contract and the flow JAR files both locally on your machine and on the node you are connecting to. Copy the previously built contract and flow JAR files to a directory on your machine. Connect to one of your nodes while providing the directory with the JAR files on your local machine. For detailed instructions, see Corda interaction tools. Interact with “Hello, Block!” In the shell, run: start helloBlockFlow target: "LEGAL_NAME" where LEGAL_NAME — the legal name of your second Corda to which you are sending a “Hello, Block!” transaction. To get the node’s legal name, see View node access and credentials. Example: start helloBlockFlow target: "OU=RG-254-409-ND-141-587-071, O=RG-254-409, L=Portland, C=US, ST=Oregon" Output: ✓ Starting Requesting signature by notary service Requesting signature by Notary service Validating response from Notary service ✓ Broadcasting transaction to participants ▶︎ Done Flow completed with result: SignedTransaction(id=F2B267806C09BDEEB0E1E815AC1502EFFCD8C4F19F5701CFE9BECC46871AE47C) Congratulations! What you have just done is: a) deployed a two-node private Corda network; b) built a smart contract in the programming language you are comfortable with; c) interacted with it on your Corda network. And it wasn’t even complicated. For more sophisticated and real-world scenarios, explore Chainstack tutorials. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Picking an enterprise blockchain protocol to develop on: Hyperledger Fabric, Go & Java & JavaScript Chainstack stopped supporting Hyperledger Fabric nodes in July 2024. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. As a Go developer;As a Java developer;As a JavaScript developer. In brief This post is a part of the multipart series aimed at developers looking to try their hand out at and get a taste of the enterprise blockchain world. This post focuses on running a “Hello, Block!” chaincode on Hyperledger Fabric for developers primarily comfortable with Go, Java, or JavaScript. Architecture On Hyperledger Fabric, a smart contract is called a chaincode. A chaincode must be installed on each of the nodes—called endorsing peers—involved in an exchange. Unlike in public blockchain protocols, the smart contracts are not propagated to all nodes in the network. Each exchange is done in a channel. Channels are established between organizations. Organizations that are not part of a channel have no access to the exchange in the channel. Transaction ordering is done by a separate node called the orderer. See also a brief Hyperledger Fabric introduction. Ecosystem Hyperledger Fabric is mainly driven by the Linux Foundation. The Hyperledger Fabric is also one of the largest and most active open-source communities when it comes to the enterprise blockchain protocols. See Comparing leading enterprise blockchains’ developer activity. Prerequisites A Chainstack account. A Hyperledger Fabric network. See Deploy a consortium network. Docker. See Get Started with Docker. Hyperledger Fabric “Hello, Block!” in Go Chaincode View the code on Gist. Source on GitHub. Hyperledger Fabric “Hello, Block!” in Java Chaincode View the code on Gist. Source on GitHub. Hyperledger Fabric “Hello, Block!” in JavaScript Chaincode View the code on Gist. Source on GitHub. Connect to your peer At this point you should have a Hyperledger Fabric network deployed and Docker installed as specified in the Prerequisites section. Export the organization identity of your network and the peer In the platform UI, navigate to your deployed peer. Next to Organization identity, click Export. This will export the peer and the organization certificates and the user in a ZIP archive. Unarchive the exported file. Unarchiving the exported file will create a directory named after your organization’s MSP ID. For example, RG-123-456-MSP. Export the orderer certificate of your network In the platform UI, navigate to your network. Select Service nodes > Orderer. Click Export TLS certificate. This will export the orderer certificate. Place the certificate in the directory that was created at the previous step when you unarchived the exported organization identity file. Place the chaincode in the organization directory In the organization directory on your local machine, create a directory named chaincode. In the chaincode directory, place the three chaincode directories with the chaincodes from the GitHub repository. These are the chaincode files that you will build and deploy to your Hyperledger Fabric network. At this point, you should have on your local machine the directory structure similar to the following one: RG-123-456-MSP |__ ca |__ chaincode | |__ go | |__ java | |__ javascript |__ msp |__ peers |__ tlsca |__ users |__ nd-123-456-789-cert.pem Run the Docker container docker run -v /host/path/to/IDENTITY_DIRECTORY/:/MOUNT_DIRECTORY -it hyperledger/fabric-tools:2.2.0 /bin/ash where /host/path/to/IDENTITY_DIRECTORY/ — path to the directory with the organization identity that you exported at the previous step. MOUNT_DIRECTORY — any name to mount a directory. Example: docker run -v /home/user/RG-123-456-MSP/:/data -it hyperledger/fabric-tools:2.2.0 /bin/ash Provide connection details and certificate paths In the running Docker container, provide the following: export CORE_PEER_ADDRESS=PEER_RPC_ENDPOINT export CORE_PEER_MSPCONFIGPATH=/MOUNT_DIRECTORY/users/ADMIN_USER_DIRECTORY/msp/ export CORE_PEER_LOCALMSPID="MSP_ID" export CORE_PEER_TLS_ENABLED=true export CORE_PEER_TLS_ROOTCERT_FILE=/MOUNT_DIRECTORY/peers/PEER_DIRECTORY/tls/ca.crt export ORDERER_CA=/MOUNT_DIRECTORY/ORDERER_CERTIFICATE export ORDERER_ADDRESS=ORDERER_RPC_ENDPOINT where PEER_RPC_ENDPOINT — the RPC endpoint of your peer. In the platform UI, navigate to your peer; click Access and credentials > RPC endpoint. MOUNT_DIRECTORY — the name of the directory that you mounted at the previous step. ADMIN_USER_DIRECTORY — the directory of your admin user that has the certificates. Exported at a previous step. MSP_ID — the ID of your organization. In the platform UI, navigate to your peer; click Organization identity > MSP ID. PEER_DIRECTORY — the directory of your peer that has the certificates. Exported at a previous step. ORDERER_CERTIFICATE — name and path of the certificate file that you exported at a previous step. ORDERER_RPC_ENDPOINT — the RPC endpoint of your orderer. In the platform UI, navigate to your network; click Service nodes > Orderer > RPC endpoint. Example: export CORE_PEER_ADDRESS=nd-123-456-789.rg-123-456.p2pify.com:7051 export CORE_PEER_MSPCONFIGPATH=/data/users/Admin@rg-123-456.p2pify.com/msp/ export CORE_PEER_LOCALMSPID="RG-123-456-MSP" export CORE_PEER_TLS_ENABLED=true export CORE_PEER_TLS_ROOTCERT_FILE=/data/peers/nd-123-456-789.rg-123-456.p2pify.com/tls/ca.crt export ORDERER_CA=/data/nd-123-456-789-cert.pem export ORDERER_ADDRESS=nd-123-456-789.rg-123-456.p2pify.com:7050 Check your connection peer channel list Example: $ peer channel list 2020-11-09 09:46:00.631 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized Channels peers has joined: defaultchannel Deploy the chaincode Package chaincode peer lifecycle chaincode package CHAINCODE_NAME.tar.gz --lang LANGUAGE --path CHAINCODE_SOURCE_PATH --label CHAINCODE_LABEL where CHAINCODE_NAME — name of your chaincode. LANGUAGE — the programming language of your chaincode: node for JavaScript, golang for Go, java for Java. CHAINCODE_SOURCE_PATH — path to your chaincode source files. The files must be in the directory you mounted earlier. CHAINCODE_LABEL — any label you want to give to your chaincode; can be the same as the chaincode name. This will package the chaincode and place it in the root of your mounted directory. Check that the packaged chaincode is created by doing ls. Example for Go: $ peer lifecycle chaincode package helloBlock_go.tar.gz --lang golang --path /data/chaincode/go/ --label helloBlock_go $ ls bin helloBlock_go.tar.gz src Example for Java: $ peer lifecycle chaincode package helloBlock_java.tar.gz --lang java --path /data/chaincode/java/ --label helloBlock_java $ ls bin helloBlock_java.tar.gz src Example for JavaScript: $ peer lifecycle chaincode package helloBlock_javascript.tar.gz --lang node --path /data/chaincode/javascript/ --label helloBlock_javascript $ ls bin helloBlock_javascript.tar.gz src Install the chaincode on the peer you are connected to peer lifecycle chaincode install CHAINCODE_NAME.tar.gz where CHAINCODE_NAME — name of your chaincode. Example: $ peer lifecycle chaincode install helloBlock.tar.gz 2020-11-09 07:44:36.291 UTC [cli.lifecycle.chaincode] submitInstallProposal -> INFO 001 Installed remotely: response:<status:200 payload:"\nG helloBlock:6ab145685b4602cf429f93536981ea3eab802369e6359fb841fb0a9bcd4a51fb\022\006fabcar" > 2020-11-09 07:44:36.291 UTC [cli.lifecycle.chaincode] submitInstallProposal -> INFO 002 Chaincode code package identifier: helloBlock:6ab145685b4602cf429f93536981ea3eab802369e6359fb841fb0a9bcd4a51fb Check the chaincode installation peer lifecycle chaincode queryinstalled Example: $ peer lifecycle chaincode queryinstalled Installed chaincodes on peer: Package ID: helloBlock:6ab145685b4602cf429f93536981ea3eab802369e6359fb841fb0a9bcd4a51fb, Label: helloBlock Approve the chaincode for your organization The majority of organizations in the channel must agree to the parameters of the chaincode. peer lifecycle chaincode approveformyorg --name CHAINCODE_NAME --package-id PACKAGE_ID -o $ORDERER_ADDRESS --tls --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE --cafile $ORDERER_CA --version CHAINCODE_VERSION --channelID CHANNEL_ID --sequence SEQUENCE_NUMBER --init-required --waitForEvent where CHAINCODE_NAME — name of your chaincode. PACKAGE_ID — the ID of your chaincode installed on the peer. You can get the ID by running peer lifecycle chaincode queryinstalled. CHAINCODE_VERSION — the version of your chaincode as specified in the source files of the chaincode. CHANNEL_ID — use defaultchannel. SEQUENCE_NUMBER — the number of times your chaincode has been defined. Use 1 for your first installation. If you later upgrade your chaincode, use 2 and so on. --init-required — indicates that the chaincode requires initialization. --waitForEvent — indicates to wait for the event from each peer that signifies that the transaction has been committed successfully. Example: $ peer lifecycle chaincode approveformyorg --name helloBlock --package-id helloBlock:e4dcc0b3052e228f77f290a8aae60e7963026ad46f59dbdb45a563a2e36dc628 -o $ORDERER_ADDRESS --tls --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE --cafile $ORDERER_CA --version 1.0.0 --channelID defaultchannel --sequence 1 --init-required --waitForEvent 2020-11-09 07:45:27.742 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [817547cebd7dd66084e7ff852ca8cac35d0c505416a7787ddd81947558280dc7] committed with status (VALID) Commit the chaincode peer lifecycle chaincode commit -o $ORDERER_ADDRESS --channelID CHANNEL_ID --name CHAINCODE_NAME --version CHAINCODE_VERSION --sequence SEQUENCE_NUMBER --init-required --tls --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE --cafile $ORDERER_CA --peerAddresses $CORE_PEER_ADDRESS where CHANNEL_ID — use defaultchannel. CHAINCODE_NAME — name of your chaincode. CHAINCODE_VERSION — the version of your chaincode as specified in the source files of the chaincode. SEQUENCE_NUMBER — the number of times your chaincode has been defined. Use 1 for your first installation. If you later upgrade your chaincode, use 2 and so on. --init-required — indicates that the chaincode requires initialization. Example: $ peer lifecycle chaincode commit -o $ORDERER_ADDRESS --channelID defaultchannel --name helloBlock --version 1.0.0 --sequence 1 --init-required --tls --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE --cafile $ORDERER_CA --peerAddresses $CORE_PEER_ADDRESS 2020-11-09 07:48:29.579 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [df2ce4feadf60dea1d7969a59ef6c512e71334b2d56bd208e0c5980b7a19ee42] committed with status (VALID) Congratulations, you now have a working chaincode on your Hyperledger Fabric network. Interact with the chaincode At this point, there is no difference what chaincode version you installed—Go, Java, or JavaScript. The interaction commands are the same for all of them. Just make sure you use the correct name of your installed chaincode as identified by -n. Write “Hello, Block!” to ledger # peer chaincode invoke -o $ORDERER_ADDRESS --isInit --tls true --cafile $ORDERER_CA -C defaultchannel -n helloBlock --peerAddresses $CORE_PEER_ADDRESS --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE -c '{"Args":["Init","Hello, Block!"]}' --waitForEvent 2020-11-09 07:58:10.249 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [7a5173dcf90d4af184dcb04e7bce35abc238e6c0d4a6f05941bed15a6484aecc] committed with status (VALID) at nd-123-456-789.rg-123-456.p2pify.com:7051 2020-11-09 07:58:10.250 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 002 Chaincode invoke successful. result: status:200 Retrieve “Hello, Block!” from the ledger # peer chaincode query -C defaultchannel -n helloBlock -c '{"Args":["query","Hello, Block!"]}' Hello, Block! Congratulations! You have just had a complete Hyperledger Fabric walkthrough from zero to interacting with a chaincode, and you did so using all the three programming languages that Hyperledger Fabric supports. To reiterate what you did: You deployed a Hyperledger Fabric network in a few clicks and minutes. You created three chaincodes: in Go, in Java, in JavaScript. You connected to a peer on your Hyperledger Fabric network. You installed your chaincode on your peer. You approved the chaincode for use on the channel that your peer is a part of. You committed the chaincode to the channel. You used the chaincode to write “Hello, Block!” to the ledger. You retrieved “Hello, Block!” from the ledger. For more sophisticated and real-world scenarios, explore Chainstack tutorials. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Picking an enterprise blockchain protocol to develop on: Introduction Chainstack stopped supporting Hyperledger Fabric and Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. In brief – what you will learn This post introduces a multipart series aimed at developers and not-yet-developers looking to try their hand out at and get a taste of the enterprise blockchain world. The series is designed to make the developers understand and run a simple “Hello, Block!” smart contract on an enterprise blockchain network in the programming language they are most comfortable with. The “Hello, Block!” is done in five different programming languages covering five different blockchain protocols. Programming languages: Kotlin Java JavaScript Go Python Protocols: Corda Hyperledger Fabric Quorum Ethereum MultiChain A section on each of the protocols gives a simplified architecture overview to let you quickly get a cursory understanding of the protocol mechanics. The overview is schematic and is done in the same style for all protocols so that you can switch between the posts and compare. A skippable introduction or why we are passionate about blockchain, this series of posts, and what we do at Chainstack The world is always changing, but there are a few things you can bet on—things being underground before they go mainstream is one of them. And blockchain is no exception. Twenty-three years ago, Kevin Kelly, co-founder of the ”Wired” magazine, penned and published a highly influential piece titled New Rules for the New Economy—an article that has stood the test of time. There are a total of 12 rules outlined, and together they give an embracive view of the world we live in today. I always recommend this article to anyone willing to understand how and why the world operates today—digital, real, and business as these three have become impenetrably fused. And things being underground before they go mainstream is a simplistic interpretation of Kevin Kelly’s Rule #4 ”The Law of Tipping Points”. What “The Law of Tipping Points” states is that significance always precedes momentum. A tipping point is when all prior effort turns into a momentum, the momentum becomes overwhelming, and the success is then a runaway event that feeds upon itself. In epidemiology, this is when a regional infection spread gets to enough hosts to quickly become an impossible to contain pandemic. The tipping point in biological systems is much higher than that of the human-made world of technology. Why? Because there is usually a significant effort involved to contain an infection and there’s always a strong incentive to lower the barrier to entry into technology. And this strong incentive comes from the digital, real, and business worlds being fused together today. Technology and business are all about win-win scenarios; otherwise there’d be no progress and sustainable success. The world—at least the one we here at Chainstack live in—belongs to developers and technology innovators. This is where some of the most exciting and creative things happen—the things that used to belong to the realms of philosophers, writers, moviemakers, and musicians—all of which moved forth entire generations of people. Remember that an explosion in each of these domains happened on the back of the great effort put into the accessibility of the underlying tools and the knowledge. This is the developer world today, and the blockchain technology is one of the transformational trends. We like that at Chainstack as moving with the trend with strong fundamentals is always exciting. We genuinely care about the industry we are in; we don’t rely on hearsay to understand the state of things in blockchain as we do our own research—see Ethereum Cloud Hosting and Enterprise Blockchains Index. And our research evidences that we are putting significant effort into what matters today and what helps the blockchain industry reach the tipping point of runaway success—the gateway for blockchain developers. Regardless of the operation size, goals, or even aspirations—the gateway for all. Quick blockchain industry facts The blockchain industry is exhibiting significant growth, and the market is expected to increase from 3.9 billion in 2020 to 23.3 billion in 2023. Chainstack’s own analysis of the developer activity around enterprise blockchain protocols confirms that the industry is maturing. Despite the recent world economy’s setback, blockchain job offerings are on a steep growth trajectory. Bottom line—if you are thinking of getting into the blockchain as a developer, today and for the foreseeable future is still the best time to do so. Next Picking an Enterprise Protocol to Develop on: Corda, Kotlin & Java. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. #### Picking an enterprise blockchain protocol to develop on: Quorum, Vyper & Solidity As a Python developer;As a JavaScript developer. In brief This post is a part of the multipart series aimed at developers looking to try their hand out at and get a taste of the enterprise blockchain world. This post focuses on running a “Hello, Block!” smart contract on Quorum for developers primarily comfortable with Python and JavaScript. Vyper is a pythonic smart contract language. Solidity is arguably similar to JavaScript. So, if you are most comfortable with Python, try the Vyper example; if you are into JavaScript, go with Solidity. Architecture On Quorum, a smart contract is called a smart contract. Just like in Ethereum, the smart contracts are propagated to all nodes in the network. Transaction privacy can be established by separate Tessera nodes. See also a brief Quorum introduction. Ecosystem Quorum is mainly driven by ConsenSys. Quorum, being a fork of Ethereum, enjoys connection to the vast Ethereum ecosystem. Prerequisites A Chainstack account.A Quorum IBFT network. See Deploy a consortium network.A version of the Geth client, called GoQuorum, installed. See GoQuorum. Quorum “Hello, Block!” in Vyper programming language Contract View the code on Gist. Source on GitHub. Quorum “Hello, Block!” in Solidity programming language Contract View the code on Gist. Source on GitHub. Deploy the contract At this point you should have Quorum IBFT network deployed and the GoQuorum client installed as specified in the Prerequisites section. Connect to your Quorum node Connect to your Quorum IBFT node with the GoQuorum client. For detailed instructions, see Quorum interaction tools. Example: ~/quorum/build/bin# ./geth attach https://user-name:pass-word-pass-word-pass-word@nd-123-456-789.p2pify.com Welcome to the Geth JavaScript console! instance: Geth/v1.9.7-stable-6005360c(quorum-v2.7.0)/linux-amd64/go1.13.13 coinbase: 0xce6d1ed6ca40a56b81fcb2789d13892628b957b8 at block: 12468 (Thu, 24 Sep 2020 04:08:34 UTC) datadir: /datadir/blockchain/qdata/dd modules: admin:1.0 debug:1.0 eth:1.0 istanbul:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0 > Compile the smart contract To deploy the contract and interact with the contract, you need to get the contract’s bytecode and ABI. The easiest way to do this is to just use the online compilers. ABI stands for Application Binary Interface and it’s something that you use to interact with the contract. Bytecode is the compiled machine code that you deploy on the network as a smart contract. Vyper Use Etherscan’s online Vyper compiler.Paste in the Vyper contract code.Select the compiler version 0.1.x. Click Compile Vyper.You will need the Abi and Bytecode outputs. You can trim down the ABI output and remove fields like Gas as you don’t need that for a Quorum network. You can just use the ABI parameters from later in this tutorial. Solidity Use Remix IDE to compile online.Go to the File explorer tab on the left and click plus sign to add new *.sol file.In the new *.sol file, paste in the Solidity contract code.Click the Solidity compiler tab on the left.Click Compile.On the same tab, there will the Compilation Details button show up. Under the button, click ABI and Bytecode to copy the ABI and bytecode values. You can trim down the ABI output and remove fields like Gas as you don’t need that for a Quorum network. You can just use the ABI parameters from later in this tutorial. Deploy the smart contract code Starting from this point in the tutorial, it doesn’t really matter if you created the contract in Vyper or Solidity, as now you have the compiled machine code that you will deploy. You should be now connected to your Quorum node and be in the GoQuorum JavaScript console. In the console, start by unlocking your Quorum account that you will use to deploy the contract bytecode: personal.unlockAccount("ACCOUNT") where ACCOUNT is the actual Quorum address that was created when you deployed your Quorum node. To get the address, navigate to your Quorum node in the Chainstack UI and copy the Address value under Default wallet. When asked for password, just hit Enter as the default password is blank. Example: > personal.unlockAccount("0x59e41b14a83d2ce5da3ccebb2be1c36f45958e54") Unlock account 0x59e41b14a83d2ce5da3ccebb2be1c36f45958e54 Password: true Set the ABI for the contract: var helloBlock = eth.contract(ABI) where ABI is the contract ABI. You can use the trimmed down version from the example below. Example: var helloBlock = eth.contract([{"outputs": [], "inputs": [], "constant": false, "payable": false, "type": "constructor"}, {"name": "printMessage", "outputs": [{"type": "bytes", "name": ""}], "inputs": [], "constant": true, "payable": false, "type": "function"}, {"name": "setMessage", "outputs": [], "inputs": [{"type": "bytes", "name": "_message"}], "constant": false, "payable": false, "type": "function", "gas": 71004}, {"name": "message", "outputs": [{"type": "bytes", "name": ""}], "inputs": [], "constant": true, "payable": false, "type": "function"}]) Set the bytecode to deploy: var bytecode = 'BYTECODE' where BYTECODE is the machine code you compiled previously. If you used the Etherscan Vyper compiler, just copy the code from the Bytecode field. If you used the Remix IDE Solidity compiler, you must copy the value in the object field and precede it with 0x. Example for Vyper or Solidity: var bytecode = '0x608...' At this point you have the ABI and bytecode set up. Now prepare to deploy from your account that you previously unlocked: var deploy = {from:"ACCOUNT", data:bytecode, gas: 2000000} where ACCOUNT is the actual Quorum address that was created when you deployed your Quorum node and that you previously unlocked. If you forgot the address, get it by navigating to your Quorum node in the Chainstack UI and copying the Address value under Default wallet. Example: > var deploy = {from:"0x59e41b14a83d2ce5da3ccebb2be1c36f45958e54", data:bytecode, gas: 2000000} undefined Prepare to deploy the instance: var helloBlockPartialInstance = helloBlock.new("printMessage", deploy) And deploy: helloBlockPartialInstance This will give you the address of your newly deployed contract. You can also view the address by visiting your Quorum network’s explorer. See Explore a network. Interact with the smart contract In the same console session, set your contract interaction instance: var helloBlockInstance = helloBlock.at(helloBlockPartialInstance.address) And finally interact with the contract: helloBlockInstance.printMessage() Example: > helloBlockInstance.printMessage() "0x48656c6c6f2c20426c6f636b2120496e20567970657221" Decode the output by using web3.toAscii. Example: > web3.toAscii("0x48656c6c6f2c20426c6f636b2120496e20567970657221") "Hello, Block! In Vyper!" Congratulations! What you have just done is: a) created and deployed a smart contract on a private Quorum blockchain network; b) interacted with the contract using the GoQuorum console. For more sophisticated and real-world scenarios, explore Chainstack tutorials. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Pickle Finance on Chainstack: Accelerating growth into new networks DeFi yield aggregator Pickle Finance is a yield aggregator, auto-compounding users Liquidity Provider positions across DApps like Sushi, Curve, and Uniswap, saving them time and money. The governance token PICKLE can be staked as DILL (or PICKLE) to earn a share of the protocol’s revenues and boost users’ farm APY. Since its inception, Pickle Finance’s jars and farms have ballooned into the hundreds. At the time of writing, Pickle Finance holds over $55 million in TVL with over 6000 users. What does Pickle Finance do? There has been phenomenal growth in decentralized finance (DeFi) over the past year. There are many parts of DeFi, from decentralized exchanges, automated market makers, lending platforms, liquidity protocols, stock synthetics, and yield aggregators. A yield aggregator is a service within DeFi that aggregates and compounds yield from other protocols, automates various strategies in token and liquidity staking that are performed across different investment products, such as liquidity pools, vaults, and yield farms. This DeFi option has risen with great popularity among users seeking to invest money and tokens through staking in yield markets. Using a yield aggregator, a user’s profits are maximized by leveraging different DeFi protocols and strategies for elevated returns. Pickle Finance allows users to earn great compounding yields on their deposits in the easiest way possible, automating the compounding process daily and absorbing the gas fees by reducing the number of transactions required. The team at Pickle Finance is also constantly bringing users new opportunities to generate yield on assets, catering to all risk tolerance levels. While there are a few yield aggregators out in the market to choose from, Pickle Finance is uniquely positioned within the DeFi market to scout the most promising protocols, build partnerships, and bring those opportunities to its users. The project is governed by a DAO (Decentralized Autonomous Organization), providing the token holders and community with voting rights to make changes to the protocol, emissions, and more. Pickle Finance also offers its users several other benefits other than just auto-compounding returns and reducing transaction fees. The team provides a smarter choice for alternative investment vehicles that are paired with accurate insights and expert strategies that are viable for all risk profiles and long-term goals in the DeFi ecosystem, no matter what phase the market is currently in. How did Pickle Finance come across Chainstack? In its early days, Pickle Finance started out with their main products, Pickle jars and Pickle farms on the Ethereum mainnet. As the ecosystem grew and a vast number of decentralized exchanges operated across various networks, Pickle Finance eventually expanded into the Polygon network, opening more opportunities for yield aggregation. With the incredible speed of expansion and scale, Pickle Finance had to seek reliable node infrastructure capable of meeting its requirements and providing access to multiple networks. The core development team at Pickle Finance had asked across various other protocols for their preferred solution, and Chainstack, as a top RPC node provider, came in highly recommended among many communities. How does the Chainstack offer match Pickle Finance needs? When Pickle Finance decided to switch to Chainstack, they were looking for a reliable RPC node infrastructure solution that could cost-effectively meet the protocol’s growing needs. The decision has been ratified by the stellar reputation Chainstack holds among many Web3 communities and protocols. Pickle Finance’s growing community is now backed by Chainstack’s reliable and scalable infrastructure. With Chainstack, Pickle Finance is able to consistently process blockchain data and transactions up to 300% faster with greater stability and performance. Chainstack is the geo-balanced go-to solution for multi-chain projects because it can manage and support the deployment of nodes across numerous protocols and networks. Pickle Finance can now focus on developing better products, establishing farming aggregator contracts, and building its strategy of customized selection of Pickle Jars and Pickle Farms to earn yield across multiple assets from different protocols and networks. Outcome Chainstack collaborated with Pickle Finance to significantly scale their yield farms. Chainstack’s team of engineers worked closely with the Pickle team to satisfy all the growing demands of the project. Chainstack’s infrastructure has proven to be a cost-effective and dependable solution to Pickle Finance’s increasing number of yield products on the Polygon network. Pickle Finance now has an expert infrastructure provider working together to further accelerate the development and scale higher, supporting the growth of over 6000 yield farmers on the platform. Chainstack’s multi-chain solution supports a variety of networks in addition to the Ethereum mainnet and the Polygon network, supporting any future expansion plans into other protocols. The Pickle team no longer needs to worry about RPC node maintenance or upgrades because they now have the support of our consistent and dedicated team of engineers. What does Pickle Finance like about Chainstack? I use Chainstack for many personal projects as well as for their reliable infrastructure. Many times, I have received personal support from the Chainstack team without even asking for it and knew that Chainstack would meet the future needs of the protocol. I’ve enjoyed every interaction with Chainstack’s engineering team and look forward to our continued collaboration as Pickle Finance grows. Larry the Cucumber, Pickle Finance What does Chainstack like about Pickle Finance? Many projects, such as Pickle Finance, need the assistance of a skilled engineering and DevOps team to optimize operational procedures and provide enough and dependable infrastructure to support rapid expansion. Glad to have Pickle Finance join us on our mission to make Web3 accessible to everybody, offering outstanding blockchain and DeFi solutions to a wider audience. Eugene Aseev CTO & Founder, Chainstack What is the most interesting engineering challenge in working together? With the aid of the Chainstack infrastructure support, the process of establishing farming aggregator contracts on the Polygon network was eased. Pickle Finance’s core infrastructure integrity is assured by Chainstack as the number of transactions and user interactions rises. This extension into the Polygon network resulted in a significant increase in the number of users, transactions, and harvests, with farms running daily. Using Chainstack, Pickle Finance is able to shift from weekly to hourly harvests, and in various instances, transact and handle harvests smoothly, even when it is carried out within a couple of minutes. Chainstack helps businesses like Pickle Finance to build high-performing products and grow applications by utilizing blockchain infrastructure solutions designed for interoperability, performance, and scalability. Chainstack’s enterprise-grade, user-friendly infrastructure, tools, and services allow developers and project teams to focus on building ground-breaking blockchain solutions while minimizing friction and optimizing operations. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Plasma Faucet: How to get free Plasma testnet XPL Plasma is a blockchain designed for stablecoin-native applications, combining sub-second finality with high-throughput execution, powered by PlasmaBFT consensus. As more teams experiment with payments and settlement flows, reliable infrastructure and test resources become essential for development and testing. Developers are experimenting with smart contracts and stress-testing performance. But test XPL is still scarce, which slows down experimentation. So we decided to ship one. On Chainstack, you can now request Plasma testnet XPL directly from our Plasma faucet. Beyond the faucet, Chainstack provides production-grade infrastructure for Plasma, including reliable RPC endpoints, archive access, documentation, and node management through the Chainstack console. In this guide, we’ll show you how to get free XPL test tokens and start interacting with the Plasma testnet. How the Chainstack Plasma faucet works Before you push anything to mainnet, you dry-run the flow — deploy a contract, test stablecoin transfers, fire transactions against a Plasma testnet RPC, or validate payment and settlement logic. For any of that, you need XPL. We’re one of the first to ship a Plasma faucet built for that. It’s tied to your wallet address and lets you claim 0.05 XPL every 24 hours, with no Twitter authentication in the mix. Just sign in, point it at your wallet, and you’re ready to test. From there, you can use your balance to cover gas on testnet, validate smart contract deployments on Plasma, or run automated checks in your dev loop. And when you’re ready to go beyond test tokens, you can deploy a Plasma node in the console and plug into mainnet or testnet RPCs all in one place. ⚠️ Plasma Faucet requirements: To safeguard against misuse, the Chainstack faucet implements two key checksbefore disbursing funds: The requesting address must have a minimum balance of 0.08 ETH on theEthereum mainnet. The address should have a history of holding ETH on the mainnet; it shouldnot have been recently empty. These precautions help maintain the integrity of the faucet, ensuring fair andequitable access for all users. How to use the Plasma faucet on Chainstack Getting test XPL from our Plasma faucet is simple. Sign in — Log into your Chainstack console. Get your API key — In the console, go to Settings → API keys and copy an active key. You’ll need it to authenticate with the faucet. Open the faucet — Navigate to the Plasma faucet page and paste your API key when prompted. Enter your wallet address — Paste the address you want to fund. Claim tokens — Submit the claim. You’ll receive 0.05 XPL every 24 hours. Confirm balance — Check your wallet or query your Plasma RPC endpoint. Once your wallet has balance, you can use it to pay gas on testnet, deploy contracts, or run integration scripts against the Plasma testnet. If you need stable, high-performance infrastructure, alongside tokens, you can spin up a Global Node for quick tests or a Dedicated Node for latency-sensitive workloads. Both expose HTTPS and WebSocket RPC URLs that slot straight into wallets, frameworks, or custom tooling. Get test XPL What you can do with Plasma testnet XPL On Plasma, nothing moves without XPL, even on testnet. XPL is used to pay gas for smart contract deployments, transaction calls, and anything you send through a Plasma testnet RPC. That makes a faucet a baseline tool if you want to: Test stablecoin transfers and payment flows Run bots or scripts against real RPC responses Validate settlement logic for stablecoin-based applications Backtest or stress-test without burning real funds Onboard teammates or teach flows without risk Once you’ve got tokens in your wallet, the natural next step is to wire them into infrastructure you control. In the Chainstack console, you can spin up a Plasma node, copy the HTTPS or WebSocket RPC URL, and start routing calls through your own endpoint. Deploy a Plasma node Plasma developer tooling Beyond the faucet and nodes, Plasma provides developer tooling you can integrate into your stack. You can interact with the network using standard EVM-compatible tooling over JSON-RPC, making it easy to work with smart contracts, query chain state, and run automated workflows. Plasma works with familiar Ethereum developer tools and libraries, allowing you to reuse existing Solidity code, frameworks, and scripts without custom integrations. For the full set of SDKs, APIs, and integration guides, check the Plasma tooling docs. Wrap up: more for Plasma builders Faucet XPL gets you moving, but production-grade stablecoin and payment workflows need more than just gas. On Chainstack, you can run reliable Plasma RPC infrastructure to query historical data, debug transactions, and stream state changes over WebSocket connections. If you prefer starting from code, Chainstack provides examples and reference implementations that show how to interact with Plasma RPC endpoints using standard EVM-compatible tooling. The Plasma API refers to the standard Ethereum-compatible JSON-RPC interface exposed by Plasma RPC nodes. Between the faucet, stable RPC infrastructure (Global or Dedicated Nodes), and up-to-date documentation, you get an end-to-end setup: test with faucet tokens, validate against production-like infrastructure, and move to mainnet without reworking your stack. Additional resources How to connect to Plasma RPC endpoint for zero-fee stablecoin transfers Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ How do I get Plasma testnet tokens? You can claim them from the Chainstack Plasma faucet. Enter your wallet address and you’ll receive 0.05 XPL every 24 hours. No Twitter authentication is required. Is Plasma EVM-compatible? Yes. Plasma is EVM-compatible, which means you can deploy Solidity smart contracts and use standard Ethereum tooling and libraries. What are XPL tokens used for? XPL is used to pay gas fees on the Plasma network. On testnet, XPL covers smart contract deployments, transaction calls, and interactions sent through a Plasma testnet RPC endpoint. Can I deploy and test smart contracts on testnet? Yes. Plasma testnet is designed for safely deploying and testing smart contracts, running scripts, and validating integrations before moving to mainnet. Are there rate limits? Yes. Public RPC endpoints are shared and subject to rate limits. For predictable performance and higher throughput, you can deploy a Chainstack node and use dedicated RPC endpoints. #### Platform 6, the most comprehensive solution for the off-chain side of decentralized applications, is now on Chainstack We are partnering with Platform 6, the easiest way for innovators, systems integrators, and enterprises to build decentralized applications related to structured business document exchanges. The platform is now available in the Chainstack Marketplace. Beyond the blockchain ledger and the smart contracts, a lot of off-chain components and features must be combined to create an enterprise-class decentralized application, such as user and data management, workflows, interaction with the blockchain framework and other systems, user interface, APIs, and more. Typically, developers have been building such applications by assembling open source and/or commercial components and gluing them together with custom code–making it a complex and time-consuming endeavor that requires a lot of development and testing. Thanks to Platform 6 comprehensive set of tools and services, developers are now able to build transactional blockchain applications in days or weeks instead of months. What is Platform 6? Platform 6 is a unique platform to develop, package and run applications involving business-to-business transactions combining data transformation, automated processes and user actions. It is the easiest way for developers at startups, systems integrators and corporate IT divisions to build enterprise-class decentralized applications related to structured business document exchanges. Supporting enterprise interoperability and compatibility We are thrilled about the partnership and the fact that Platform 6 is now listed on the Chainstack Marketplace. Both our solutions are enterprise-grade, blockchain-agnostic and share the same objective: making developers’ life easier, Chainstack thanks to its incomparable managed blockchain infrastructure that makes it so simple to deploy, manage and scale blockchain networks; and Platform 6 thanks to its unique set of features to develop, package and run the off-chain part of decentralized applications.Emmanuel Thiriez, CEO of Platform 6 Paired with Chainstack’s suite of blockchain managed services, Marketplace add-ons, and APIs, blockchain developers will find their experience transformed, being able to build, deploy and scale their blockchain applications in a way that is enterprise-friendly, efficient, scalable, and flexible. The goal of Chainstack is to help accelerate the adoption of blockchain technology by enterprises. The partnership with Platform 6 marks a great step forward in realizing this vision, as it creates a robust bridge between the blockchain and the enterprise world. Chainstack demonstrates again its commitment to creating an ecosystem of blockchain managed services designed to provide a superior developer experience.Laurent Dedenis, CEO of Chainstack Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today.  #### Play-to-Earn: How crypto games are reshaping the way it’s meant to be played In a world where technology and gaming intersect and evolve at a rapid pace, nothing marks this trend more distinctly than the emergence of Play-to-Earn games. Earning while you play is no longer a fantasy, but a thrilling reality, made possible through advancements in blockchain technology. Play-to-Earn, or “P2E” in shorter form, represents a gaming model where players can earn tangible rewards—including crypto tokens and NFTs—for their in-game triumphs. As opposed to traditional gaming models where players typically spend money on games without any financial comeback, P2E adds a thrilling twist; your character’s adventures in virtual worlds can translate into real-world profits. And this revolution is supercharged by blockchain technology. By operating on a decentralized network, these games can provide a level of transparency and security that’s very appealing to players. Moreover, they offer the exciting prospect of earning money through the gameplay—unlike the “pay-to-win” or “freemium” models commonly found in traditional video games. In Play-to-Earn games, your virtual gaming skills can have real-world value. Games such as Axie Infinity, Eldarune, and Iguverse are leading the way in this thrilling new era for the gaming industry. Join us as we delve into the intricacies of Play-to-Earn games. We’ll explore how they work, what makes them unique, their challenges, and how they are carving out a new economic model within the gaming industry. Whether you’re a seasoned gamer, a blockchain enthusiast, or a curious reader, this exploration will provide an insight into the evolution of the gaming industry towards a player-centered economy. What are Play-to-Earn games? Play-to-Earn games are a new model of video games that reward players for in-game achievements with assets that hold real-world monetary value, marking a significant shift from the traditional gaming models we’ve grown accustomed to. These games utilize blockchain technology and its key feature of decentralization to offer a unique gaming experience where players’ in-game achievements are rewarded with assets of real-world monetary value. The Play-to-Earn model is not restricted to blockchain games. Any traditional online game that allows players to sell items they earn or buy within an in-game marketplace for real-world money can technically be considered a Play-to-Earn game. However, the decentralized nature of blockchain gaming eliminates many of the restrictions and provides significantly more earning potential for dedicated gamers. Figure 1: The video game player community; Source: Chainlink For many around the world, especially in developing countries, Play-to-Earn games have become a lifeline, providing an alternative way of making a living in times of economic hardship. The concept of earning while playing has revolutionized the gaming industry, providing a whole new level of interactivity and monetization. The evolution of Play-to-Earn games The concept of Play-to-Earn is not entirely new. Games like Second Life and Entropia Universe have long allowed players to earn and cash out virtual currency. However, the combination of cryptocurrencies, NFTs, and DeFi / GameFi mechanisms in today’s blockchain games have pushed the boundaries of what’s possible. Blockchain makes the Play-to-Earn model viable, advantageous, and appealing for players. It ensures transparency, fairness, and security while enabling the seamless exchange of assets across different platforms. The technology also offers innovative game design possibilities, injecting unpredictability and suspense that keep players engaged and entertained. With blockchain, in-game economies become more democratic and less confined by the whims of game developers. Players can freely trade their assets with others, offering a novel way for gamers to earn cryptocurrencies that they can exchange for real-world money. Blockchain technology is changing the way we look at online gaming, taking it beyond mere entertainment. The Play-to-Earn model stands as an impactful demonstration of how blockchain can redefine sectors, opening avenues previously unimagined. Benefits of Play-to-Earn games The upside of Play-to-Earn games can be multifold. Primarily, they allow players to be compensated for their time and commitment to the game. This shakes up the traditional gaming paradigm where players pour money into a game for digital goods but never see any return. In a Play-to-Earn game, the player is an active participant in the game’s economy. They have the opportunity to earn real money through their in-game decisions and skill levels. This model grants players financial autonomy and can result in a significant income for successful and dedicated gamers. There is also a sense of true ownership and more significant interaction. The blockchain records all transactions transparently and immutably. Thus, an asset bought or earned in a game becomes truly owned by the player, like a physical item in the real world. They can trade, sell, or hold these assets as they see fit, opening new dimensions of strategy and planning. Here are some key reasons why gamers and non-gamers alike are exploring P2E games: Earn real rewards: Play-to-Earn gamers can earn cryptocurrency and NFTs from their in-game accomplishments—assets that have real-world value beyond the gaming environment. Ownership over in-game items: Because items are tracked on decentralized blockchain networks, gamers can take full ownership of the items and assets they earn from gameplay. This adds a layer of value and tangibility to their gaming experiences. Participation in strong communities: Gamers often network with other community members in online forums, where they share in-game strategies, experiences, and make personal connections. This social aspect of P2E games can be immensely gratifying. New economic opportunities: Many individuals use Play-to-Earn games as a supplementary income source, creating new streams of revenue—sometimes even more profitable than traditional job markets. Entertainment: Beyond the financial benefits, Play-to-Earn games offer unique and immersive gaming experiences that are a source of pure fun! By providing utmost control to the players and rewarding their efforts with tangible benefits, Play-to-Earn games create an empowering and fun environment that holds the potential to revolutionize the world of online gaming. However, like any other industry, it’s not devoid of criticisms and challenges, which are essential to understanding the complete picture of P2E gaming. Challenges for Play-to-Earn games While there are evident advantages of Play-to-Earn games, it is essential not to overlook the potential pitfalls and challenges. For one, the gaming experience can become heavily influenced by the game economy, which may overshadow the elements of fun and enjoyment. As the players’ in-game activities can either result in earning or losing real money, the pressure could lead to an overly competitive environment. Also, the regulatory aspect of these games is still under scrutiny. As P2E merges the realms of gaming and finance, it navigates a gray area in terms of regulation and tax implications. Governments around the world are still figuring out how to govern and tax in-game profits, creating uncertainty for players. Lastly, as these games involve considerable financial transactions, they could become potential targets for hackers and scammers. Safety and security are paramount concerns, reinforcing the need for robust security measures and responsibilities both by game developers and players. Here’s a quick recap of the pitfalls that Play-to-Earn players should be mindful of: Price volatility: Given the inherently volatile nature of cryptocurrencies, earnings from these games can fluctuate drastically, posing a risk to players relying on it for steady income. High entry barriers: Some Play-to-Earn games require an initial investment to get started. For example, in Axie Infinity, players must first acquire three Axies—an investment which can run up to hundreds of dollars. Risk of scam: Like any digital frontier, the realm of Play-to-Earn games is prone to scams and malicious activities. It is crucial for players to do their research and rely on trusted sources. Tax implications: Players must acknowledge the tax obligations that come with crypto earnings from Play-to-Earn games, which adds an element of complexity. Interoperability: Blockchain’s lack of cross-communication is a hurdle for Play-to-Earn games. With users preferring to stay on one blockchain and the unsustainability of deploying games on multiple chains, we need efficient solutions as blockchain technology advances and broadens. Figure 2: Fragmented gaming and blockchain ecosystems; Source: Chainlink Also, it’s worth mentioning that the monetary aspect could potentially detract from the fun and relaxation that games usually provide, turning it into more of a job than a leisurely activity. As with all things, balance is the key. The Play-to-Earn model is an exciting development in the gaming world, but participants need to navigate it with vigilance and care, being aware of both the advantages and the potential drawbacks it brings. With a thorough understanding and the right strategy, the world of Play-to-Earn gaming could indeed be a rewarding playground. Differences between Play-to-Earn and traditional games Comparing Play-to-Earn games with traditional video games, a significant difference lies in Play-to-Earn games’ potential for revenue generation. Traditional video gaming was mostly an entertaining pastime; however, the Play-to-Earn model has shown that video gaming can also be a revenue-generating activity. Unlike traditional video games like World of Warcraft or Minecraft, the kind of remuneration Play-to-Earn games offer the players stands as a stark difference. Traditional games never allowed players to cash out their in-game victories in real-world money. However, blockchain has revolutionized this model. It brought in the Play-to-Earn model, allowing players to buy and sell characters, skins, abilities, and items on an open market. Consequently, the native currency of the video game can be used outside of the games’ economy, allowing players to exchange their real money for game cryptocurrency, and vice versa. Here’s a comparison: Ownership: Unlike traditional games where players lease digital assets, Play-to-Earn games operate on blockchain technology, allowing players to achieve true ownership over in-game assets, which they can trade or sell. Monetization: Conventional games rarely offer players a way to monetize their skills or time spent in the game, and in-game purchases often serve cosmetic purposes. On the other hand, Play-to-Earn games enable players to earn tokens with real-world value that they can cash out, making their gaming activities potentially lucrative. Community participation: While traditional games often have passionate communities, Play-to-Earn games take this a step further. Many P2E games have community governance structures, allowing players to vote on various aspects of the game’s future. Costs and profits: Traditional games often require a one-time purchase or subscription fee, but subsequent in-game assets come at no additional cost. In contrast, the starting costs for Play-to-Earn games can be higher, as players might need to buy initial assets. However, Play-to-Earn games also put forth opportunities for players to make profits through trading and other in-game activities. User demographics: Play-to-Earn games have found popularity among a wide demographic, including gamers looking for profitable opportunities, crypto enthusiasts, and even people in developing nations looking for additional income sources. In conclusion, while traditional games focus on entertainment and user engagement, Play-to-Earn platforms lean towards user profitability and efficacy. However, this doesn’t detract from the entertainment value they provide, but rather adds a unique layer of interest and engagement. How Play-to-Earn games work Play-to-Earn games reward players with digital assets that have real-world value, as players progress in the game. These rewards can take the form of cryptocurrencies or NFTs. As an amalgamation of traditional gaming and the investing world, Play-to-Earn games create a fresh realm that hugely enriches the player experience beyond game-specific achievements. At the heart of this gaming model is the blockchain network, whether it is a typical Layer 1 chain, like Ethereum, or a dedicated one like Ronin. Game designers use these platforms and their associated tools to create crypto-compatible gaming experiences. They can tokenize the game items, which, being traced on the blockchain network, give the players rightful ownership of these assets. For example, in a game like Axie Infinity, players can become proud owners of Axies—the collectible creatures used to battle others in the game. These Axies, being NFTs, are entirely under the ownership of the player. The player can sell these Axies on the game’s native marketplace or secondary NFT marketplaces, earning the game’s native tokens in return. Figure 3: Axie in-game asset NFT marketplace listing; Source: Bankless These tokens, having real-world value, can be converted into a government-issued fiat currency via a cryptocurrency platform, suggesting how players can reap benefits in tangible forms. Controlling value creation in Play-to-Earn games In the Play-to-Earn gaming ecosystem, value creation is no longer strictly controlled by the game developers. Instead, power falls onto the hands of the players, who can earn real value through their gaming activities. This shift of power is a significant departure from traditional gaming models. Previously, value would be created whenever a player bought a game or made in-game purchases. For free games, value would be extracted from advertising revenue. No matter how many hours the players dedicated to the game, the content they created, or the experiences they contributed to, they would not get a cut from it. Play-to-Earn games flip this model around. By allowing players to earn cryptocurrency and NFTs, the players are the ones creating the economic activity. The more engaging and rewarding the game is, the more players it will attract, and the more value it will generate. In a way, as players are now essential for value creation, this model can be rewarding for both the players and the developers, creating a mutually beneficial situation. Figure 4: Tokenizing in-game assets; Source: Chainlink However, this shift in power dynamics also implies responsibilities for the players. They need to manage their assets, understand the game’s economy and keep track of the legal implications in their local jurisdictions. Hence, navigating the Play-to-Earn model successfully requires skill, knowledge, and diligence. Closed vs open game Play-to-Earn economies An essential aspect of understanding Play-to-Earn games better involves the comparison between closed game economies (traditional games) and open game economies (blockchain-powered games). In a closed game economy, the game developers maintain total control. They dictate in-game prices, regulate supply and demand, and retain ownership of in-game assets. Consequently, gamers can’t earn real-world value from their in-game achievements. Any virtual earnings remain confined within the game’s ecosystem. Thus, while you might acquire a rare item in a traditional video game, it remains the property of the game, and it’s prohibited and impossible in most cases to sell these items for real-world money. On the other hand, an open game economy like those in Play-to-Earn games are governed by smart contracts, and players are free to buy, sell, trade, and own their in-game assets, thanks to blockchain technology. These games allow players to earn and build up wealth via their in-game achievements and activities. Players can even leverage these assets to accrue further value, such as renting or selling them in the marketplace. Open game economies mark a revolutionary change, heavily disrupting the gaming industry. They provide financial opportunities and decentralize wealth and power from the developers to the players. Figure 5: Closed vs open in-game economies; Source: Chainlink However, with these newfound opportunities come challenges and responsibilities, ranging from understanding the game’s mechanics and market trends to acquiring basic cryptocurrency and NFT knowledge. Thus, while intriguing and profitable, the Play-to-Earn space is also complex, necessitating thorough research and understanding from its participants. How to get started with Play-to-Earn games As the Play-to-Earn model gains traction, many gamers and non-gamers are eager to start their journey in this new gaming niche. Here are some steps beginners can take: Understand the dynamics: Before diving in, it’s vital to familiarize yourself with how Play-to-Earn games work. Take time to read up on blockchain technology, NFTs, and cryptocurrency basics. Choose the right game: Not all Play-to-Earn games operate the same way. Some might require a high initial investment, while others might be more beginner-friendly. Spend time researching different games, their mechanisms, potential earnings, and their communities to find one that suits you best. Set up a crypto wallet: Since Play-to-Earn games use cryptocurrencies, a crypto wallet is necessary to manage and trade your crypto assets. You might also need to purchase game-specific tokens to get started. Start playing and learning: There’s no better way to understand the game than by playing it. Ensure you are aware of the game’s rules, mechanics, and strategies. It’s also helpful to connect with the game’s community to gain insights and tips. Manage your earnings: Be smart about managing your in-game profits. Every earnings you make are subject to real-world taxes. Also, consider the volatility of cryptocurrencies before converting your earnings. Stay updated: The crypto and gaming industry move fast, and new Play-to-Earn games are constantly being developed. It’s beneficial to stay current with recent trends and developments in this space. Remember, while the potential earnings of P2E games might be enticing, one should also pay attention to the risks involved. Take one step at a time, and most importantly, make sure to enjoy the game itself. Notable Play-to-Earn games The allure of Play-to-Earn games reaches far and wide. Here is an overview of some of the popular games that have capitalized on this trend: Axie Infinity: Axie Infinity, a pioneering game in the Play-to-Earn model, lets users collect, breed, raise, and battle Axies—fantasy creatures residing in the Axie Infinity universe. Built on the Ethereum blockchain, each Axie represents an NFT with a distinctive genetic makeup. Players can earn Small Love Potions (SLPs), the in-game currency, by winning battles and completing daily tasks. SLPs can be traded for other cryptocurrencies, thereby delivering real-world income. Eldarune: Eldarune takes the GameFi model a notch higher by incorporating multifaceted earning opportunities. Active earnings come from PvP battles, campaigns, competitions, token drops, and NFT rewards. Meanwhile, passive income streams include staking ELDA tokens, NFT lending, farming, and liquidity provision. These income sources keep players invested long-term, creating a sustainable in-game economy that mirrors real-world financial systems. IguVerse: IguVerse is a multiplayer social game that revolutionizes play-to-earn mechanics by combining “Socialize-to-Earn,” “Move-to-Earn,” and “Play-to-Earn” into one online platform. The game encourages real-life activities and social media interaction, incentivizing players with rewards for tasks like sharing pet photos. The concept unifies pet owners globally into one platform and incentivizes typical social media activity with cryptocurrency rewards. While these games offer a direct pathway from gaming to earning, players must always consider these video games’ inherent volatility and risks. Like any investment, players should thoroughly research and understand how each game operates before participation. Bringing it all together Play-to-Earn games are revolutionizing the gaming industry by enabling players to own their in-game assets and even monetize these assets for real-world benefits. From granting players the power to earn cryptocurrency and NFTs, fostering strong online communities, to defining an entirely new economic model, Play-to-Earn games are a testament to the dynamic union of gaming and blockchain technology. Remember games like Axie Infinity, Eldarune, and IguVerse, each offering unique approaches to the Play-to-Earn model. The gaming world is witnessing an incredible transformation towards player-centric economies with opportunities for everyone to play, earn, and own. As the landscape of Play-to-Earn games continues to unfold, it’s a thrilling time to be a gamer and an investor. Keep exploring, strategizing, and playing! Always remember to start with a secure digital wallet, understand the game’s dynamics, approach with a strategy, and most importantly, have fun! This is just the beginning of a new era of gaming. Stay tuned for more developments in this exciting space. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Polygon and Chainstack announce a partnership to power-boost Web3 adoption We are joining forces with Polygon (previously known as Matic) to provide intuitive, robust, and high performing blockchain infrastructure so that developers and enterprises can build projects on “Ethereum’s Internet of Blockchains” without any scaling or accessibility limitations. We are excited to be part of the next phase growth of Polygon, a protocol and a framework for building and connecting Ethereum-compatible blockchain networks. We hope that our partnership will help bring the Web3 infrastructure to the business world and further widen the opportunities for developers and start-ups in this thriving ecosystem. Having grown exponentially and gained wide adoption within the Web3 community over the past year, Polygon’s Layer 2 solutions are paramount to keep lower gas fees and support high transaction throughput. Polygon provides scalable, secure and instant transactions on a sidechain based on an adapted implementation of Plasma framework for asset security and a decentralized network of Proof-of-Stake (PoS) validators. The network is currently live and is powered by the MATIC token used for staking to secure the chain, in addition to being used to pay for transaction fees on the network. With Polygon, any project can easily spin up a dedicated blockchain network combining the best features of stand-alone blockchains and Ethereum. Additionally, these blockchains are compatible with all the existing Ethereum tools such as MetaMask and Remix and can exchange messages among themselves and with Ethereum. What is Polygon? Polygon is a protocol and a framework for building and connecting Ethereum-compatible blockchain networks. Polygon aims to create a more generalised scaling solution to overcome the limitations imposed to projects wanting to leverage the thriving Ethereum ecosystem without compromising on security, low transaction fees, and transaction speed. Polygon is uniquely positioned to be the solution to solve this issue thanks to: One-click deployment of pre-set blockchain networks. An interoperability protocol for exchanging arbitrary messages with Ethereum and other blockchain networks with native support for message passing (tokens, contract calls, etc.) and bridges to external systems. Growing set of modules for developing custom networks with high customizability, extensibility and upgradeability, short time to market, and the collaboration of a large community. Availability of adaptor modules for enabling interoperability for existing blockchain networks. Modular and optional ‘security-as-a-service provided by either Ethereum, or a by a pool of professional validators. A developer experience equivalent to Ethereum, with no protocol level knowledge required, no token deposits, and no fees or permissions. User experience comparable to Web2, ‘zero-gas’ transactions and instant (deterministic) transaction finality. How will the partnership between Chainstack and Polygon power-boost Ethereum’s “Internet of Blockchains”? In this long-term collaboration, Chainstack will facilitate the creation of several solutions and tools that will make deploying Polygon’s infrastructure as easy as sending an email. Public RPC service: Public RPC endpoints that do not require authentication and will remain free of charge for the foreseeable future for both Polygon PoS mainnet and testnet. The Polygon community can now interact with Polygon PoS blockchain and smart contracts via brand-new RPC endpoints built and operated by Chainstack. This will further increase the accessibility of Polygon’s Layer 2 chain, which has so far seen widespread adoption with 100+ DApps, ~10M transactions and ~230K unique users. The public RPC endpoints have an agreed IP-based fair usage limitation of 50 requests per second and 1500 per minute for both testnet and mainnet. While currently only the Polygon PoS is included in this service, in the future Chainstack will continue to support the expansion of the ecosystem with more blockchains as part of a long-term partnership. Complete Polygon support on Chainstack: Chainstack platform makes running a blockchain node radically simple so that developers can focus on building their application instead of worrying about node availability, costly maintenance and upgrades, or uptime. In the coming weeks, Chainstack will launch automatic deployment of Polygon PoS nodes, adding it to the existing portfolio of enterprise-grade ready infrastructure, which already includes Ethereum, Bitcoin, Quorum, and MultiChain. We hope that this will not only make the creation of new applications easier but that it will also open more opportunities for enterprises to build their blockchain projects on Polygon. Support on the Chainstack platform will open up the opportunity for custom SLAs, rapid prototyping and bespoke development with Chainstack’s professional services, compatibility with Chainstack Marketplace tools and services, as well as our widely praised highly responsive customer support. Block explorer for the Polygon PoS chain: Anyone will be able to view, query and track in real time all the transactions carried out on Polygon PoS network. Thanks to this co-funded initiative, the Polygon community will have access to a new explorer which promises to be highly resilient and available, being built on Chainstack’s own infrastructure. The rapid adoption of Polygon has resulted in the need for strong infrastructure that can support the high throughput on-chain txns from 150+ Dapps on Polygon. We are pleased to collaborate with Chainstack to make the blockchain experience seamless for users and developers. Sandeep Nailwal, Co-Founder and COO, Polygon In addition to the platform and protocol technical supporting the acceleration of the Polygon ecosystem growth, over the coming weeks and months Chainstack will help accelerate the growth of the Polygon ecosystem with a number of community initiatives and marketing campaigns. These will be targeted to both individual developers and to businesses alike, with the primary goal to support sustainable and widely accessible accelerated ecosystem growth for the entire Polygon community. The partnership between Polygon and Chainstack has the potential to greatly accelerate Web3 adoption in the wider business community. Polygon’s community has now a trusted ally to help power-boost experimentation, adoption, and scalability. We remain a highly accessible and secure platform that helps businesses incorporate Web3 into their existing systems and supports the development of a Web-native ecosystem. Eugene Aseev, founder and CTO of Chainstack Connect with the community To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group. Sign up for a free Developer account, or explore the options offered by Growth or Business plans here. Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Polygon Growth: Polygon developer ecosystem growth backed by Chainstack data Introduction Polygon—a decentralized scaling platform that started as Layer 2 to Ethereum—launched its mainnet as Matic in mid-2020, a perfect time for the user adoption boom that followed on Ethereum and Ethereum-based networks later in 2020, and is still happening today. Rebranded into Polygon in February 2021, the project expanded into becoming a suite of scalability solutions, including Polygon PoS commit chain, Polygon Hermez ZK rollup and other architecture solutions. Polygon network growth Polygon attracted more than 50 DApps even before launching its mainnet in 2020, which at the time made Polygon the most adopted Layer 2 solution right at the start. Polygon has been on a steep growth trajectory ever since. A year after the launch, in mid-2021, Polygon went through a meteoric rise in transaction volume and exceeded the Ethereum transaction count by 18%. At the same time, Polygon’s native DEX—QuickSwap—exceeded the transaction volume of Uniswap by 20%. The explosive rate of the Polygon adoption manifested in the user numbers, developers, dapps, and the overall transaction volume has been and remains to be fully supported by the Chainstack infrastructure. Chainstack is a highly accessible, secure platform and a trusted ally for the Polygon community.Eugene Aseev, Founder and CTO of Chainstack Polygon developers’ growth backed by Chainstack data Chainstack launched Polygon support in May 2021 and went on an x4 increase in the number of deployed nodes in the first two months. After the initial burst in the developer deployed nodes, the month-over-month growth stabilized at an average of 20% increase per month. The total growth in the deployed node numbers from the launch of Polygon nodes on Chainstack in May 2021 until the end of February 2022 is an impressive 2827%. Other data points: 6% of all Polygon nodes currently active on Chainstack are archive nodes.20% of all projects running Polygon nodes are multi-chain—they run at least one other non-Polygon node for their DApps and services. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Polygon’s Second Life: Rebuilding traction via payments TL;DR 2023 was rough for Polygon: layoffs, a flat token, and L2 competitors pulling ahead. Rather than keep fighting for DeFi dominance, Polygon pivoted to payment infrastructure. The Polygon 2.0 vision reframed the network as an ecosystem of interconnected ZK chains. Rio and AggLayer turned Polygon into payments-grade infrastructure with instant finality, 5,000 TPS, and cross-chain liquidity that now supports OP Stack and Arbitrum Orbit, not just Polygon CDK.  The pivot landed, with small USDC transfers more than doubled in early 2025, treasury funds moved onchain, and major payment processors plugged the network into mainstream commerce. Polygon is now where BlackRock, Franklin Templeton, and Stripe settle real money. If stablecoins become default rails for cross-border payments, Polygon is already ahead of the game. The story behind this pivot starts with an unusually candid admission from Polygon’s leadership. Introduction: the underdog admission On Christmas Eve 2023, Polygon co-founder Sandeep Nailwal posted something unusual for a crypto founder. No hype. No promises of a supercycle. Just a blunt admission.        It had been a painful year. Layoffs hit 19% of the team, the token flatlined while competitors rallied, and Arbitrum had seized the TVL crown as Base and a wave of new L2s carved up whatever market share remained. Rather than keep fighting for DeFi dominance, Polygon had started building out payments infrastructure, assembling a dedicated team and retooling the network for a use case most L2s weren’t prioritizing. The strategic pivot: why payments? Polygon 2.0 vision (June 2023) The groundwork started six months earlier. In June 2023, Polygon Labs unveiled Polygon 2.0, a four-layer architecture that would turn the network into an ecosystem of interconnected ZK chains rather than a single L2: A shared staking layer let validators secure multiple chains with one stake An execution layer enabled sovereign ZK chains to run independently while settling to Ethereum An interop layer built on the LxLy bridge aggregated ZK proofs from those chains into a single proof before posting to Ethereum A common proving layer standardized ZK proof generation across all chains in the ecosystem The MATIC token would become POL, with a 2% annual emission split between validator rewards and a community treasury. Validators could now earn from multiple chains simultaneously rather than just one. Reading the market  The stablecoin market was also shifting. Total market cap crossed $200 billion in late 2024 and hit $250 billion by mid-2025, but the growth wasn’t coming from DeFi speculation. Cross-border payments and remittances were driving volume, particularly in emerging markets. Tron had dominated that segment for years, but rising TRX prices created a problem. As TRX went from $0.12 in early 2024 to $0.32 by late 2025, USDT transfer fees on the network climbed from around $1.60 to over $4, with spikes as high as $9. For users sending $20 or $50 at a time, that math stopped working. Polygon built a dedicated payments team to go after that gap. No other major L2 had done the same. Infrastructure upgrades: making Polygon payments-grade The Rio upgrade (October 2025) The vision needed infrastructure to back it up. In October 2025, Polygon shipped the Rio upgrade, the most significant overhaul to the PoS chain’s architecture since launch. The core change was a new block production model called VEBloP, or Validator-Elected Block Producer. Instead of multiple validators producing blocks simultaneously, the network now elects a single producer for longer spans while backups stand ready to step in. This eliminates chain reorgs entirely. For payments, that matters. A transaction confirmed on Polygon stays confirmed. No rollbacks, no uncertainty about finality.  Rio also introduced stateless validation, allowing nodes to verify blocks without storing the full chain state. Hardware requirements dropped significantly, making it cheaper to run infrastructure. Throughput hit 5,000 TPS, with a roadmap targeting 100,000 TPS under what Polygon calls its GigaGas initiative. AggLayer: the interoperability bet The other half of the infrastructure bet is AggLayer, Polygon’s interoperability layer. The Unified Bridge went live in February 2024 with two chains connected: Polygon zkEVM and OKX’s X Layer. Rather than requiring wrapped tokens for cross-chain transfers, the bridge lets native assets move between connected chains through a shared liquidity pool.  In February 2025, pessimistic proofs went live on mainnet, adding a verification layer that tracks deposits and withdrawals across all connected chains to prevent any single chain from draining the bridge. That opened AggLayer to chains beyond Polygon CDK. OP Stack support shipped in May 2025. Source: The Agglayer Thesis: Connecting Every Chain in Web3) What changed  Polygon’s role in everyday USDC payments, institutional settlement and merchant access all shifted meaningfully in the last two years. The same network that once competed mainly on DeFi throughput is now tied directly into both retail users and TradFi. Small value USDC transfers on Polygon grew sharply in 2025, with sub-$1,000 activity more than doubling the first half of the year and reaching hundreds of millions of dollars in monthly volume. Polygon now processes a large share of US based USDC transfers in the 100 to 1,000 dollar band, reflecting growing use by individuals and small businesses rather than large speculative flows. Institutional settlement followed the retail usage. Franklin Templeton’s Franklin OnChain U.S. Government Money Fund (FOBXX) enabled peer-to-peer transfers of its BENJI tokens in 2024, turning a tokenized U.S. government fund into something that could move more fluidly onchain. In late 2025, BlackRock’s BUIDL fund deepened its presence on Polygon with a single 500 million dollar onchain deposit, cementing the network as a meaningful venue for tokenized U.S. Treasuries. At the same time, stablecoin payments reached far beyond the crypto-native world. Integrations such as Stripe, DeCard and major payment processors tied Polygon based USDC and other stablecoins into existing card and checkout rails, making it possible to pay at hundreds of millions of merchants using familiar commerce flows. Polygon increasingly functions as the underlying infrastructure for stablecoin spending in everyday online and point-of-sale transactions, rather than only as a venue for DeFi activity. The future outlook The payment traction is real, but it hasn’t shown up in the token price. POL hit $1.29 in March 2024. By late 2025, it trades around $0.11, down roughly 90 percent even as network activity and institutional adoption climbed. The disconnect is hard to ignore. Part of the explanation is branding. Polygon migrated from MATIC to POL in September 2024, pitching it as an upgrade, but a lot of retail holders never caught on. Co-founder Sandeep Nailwal has acknowledged that users outside crypto-native circles often don’t realize their old MATIC holdings are now POL. He has recently floated the idea of reverting to the MATIC ticker after hearing persistent complaints from retail traders in markets like the Philippines and Dubai.   The deeper question is whether payment infrastructure translates to token value at all. Most stablecoin transfers on Polygon are denominated in USDC, not POL. Fees are fractions of a cent by design. The network can keep growing without POL capturing much of the upside. Conclusion A year ago, the obvious way to track Polygon was TVL. That number still exists, but it’s not where the action is. Payment volume, stablecoin transfers, merchant integrations—those are the metrics that moved in 2025, and they’re the ones Polygon is now building around. Whether that’s enough depends on what you’re measuring. As infrastructure for moving dollars, Polygon has a stronger case than it did in 2023. As a token bet, that’s less clear. Reliable Polygon RPC infrastructure Getting started with Polygon on Chainstack is fast and straightforward. Developers can deploy a reliable Polygon node for Polygon mainnet RPC access within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Polygon RPC access, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and stablecoin-powered payments infrastructure. With Polygon low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Polygon RPC endpoint for production, and scale with dedicated nodes designed for consistent low latency and high throughput. Delpoy Polygon Node Now #### Polymarket API for developers: data, CLOB, and Polygon RPC TL;DR Polymarket is a decentralized prediction market built on Polygon where real-world events are turned into tradable probability markets. Through the Polymarket API, developers can access market data, trading infrastructure, and settlement systems programmatically. Users buy and sell outcome tokens priced between 0 and 1, reflecting the market’s current belief about what will happen. Under the hood, the platform combines an off-chain order book for fast matching with on-chain settlement using the Conditional Token Framework, while UMA’s oracle handles final resolution. For developers, this creates a clean system where market data, trading, and settlement are all accessible through well-defined APIs and standard EVM tooling. From a builder’s perspective, the platform is split into clear layers. Gamma API provides public market discovery, the CLOB powers trading and order execution, the Data API exposes user-level analytics, and WebSockets handle real-time updates. You can go from fetching markets to placing and tracking orders with just a wallet, API credentials, and a Polygon RPC endpoint. The workflow is straightforward, fetch a market, inspect liquidity, sign and submit a limit order, and monitor both off-chain status and on-chain settlement events. The result is a flexible foundation for building trading bots, analytics dashboards, or entirely new interfaces on top of prediction markets. With low fees, fast confirmation times, and transparent on-chain data, Polymarket turns global sentiment into something developers can query, analyse, and act on programmatically, while still carrying the usual risks of trading, liquidity constraints, and oracle-based resolution. What is Polymarket? Polymarket is a decentralised, non-custodial prediction market deployed on Polygon PoS. For developers, the platform is accessible through the Polymarket API, which provides market data, trading infrastructure, and analytics endpoints. Users trade binary outcome tokens denominated in USDC.e, with prices from $0 to $1 backed by the current market sentiment. Trades execute peer-to-peer through a hybrid off-chain order book (CLOB) and on-chain settlement using the Conditional Token Framework (CTF, ERC-1155). Markets settle transparently via UMA’s Optimistic Oracle, ensuring outcomes match collective consensus. Markets span across various breaking news globally like elections (US presidential races), the future of nations, war, policy decisions, major sports (Super Bowl, Olympics, World Cup), finance and crypto milestones, cultural awards or natural events. This gives users an opportunity to make predictions, hedge risks, or simply track what the world believes will happen next with fast, low-cost, verifiable on-chain transactions on Polygon. markets > media— Polymarket (@Polymarket) June 6, 2025 Polymarket has over 2.4 million traders across 214,735 markets, with approximately $62 billion in total trading volume. Source: https://polymarketanalytics.com/ Source: https://dune.com/datadashboards/polymarket-overview The platform is the official prediction market partner of X (formerly Twitter), with Polymarket outcomes displayed alongside Grok analysis and live X posts, merging social data with market signals. we’re joining forces with Polymarket as our official prediction market partner@X 🤝 @Polymarket— X (@X) June 6, 2025 In October 2025, Intercontinental Exchange, the parent company of the NYSE, invested $2 billion in Polymarket, valuing the platform at $9 billion. We are excited to announce that Intercontinental Exchange (ICE) — the parent company of @NYSE, is making a $2b strategic investment at a $9b post-money valuation. Together, we’re building the next evolution of markets.A special thank you to all those who have supported us… pic.twitter.com/y7Z3koj3IU— Polymarket (@Polymarket) October 7, 2025 Polygon PoS Architecture ➡️ If you are already familiar with the architecture, skip to “Step-by-Step Guide” section below Before exploring Polymarket, it helps to understand how Polygon, the settlement layer for the platform, enables ultra-fast transactions at very low costs. Polymarket’s smart contracts, including the CTF Exchange, the Conditional Token Framework, and USDC, all run on Polygon PoS (Chain ID 137), which provides the foundation for building trading systems, event listeners, and data pipelines on the platform with real-world throughput of ~110 transactions per second, 6.4B+ total transactions processed, an average transaction cost of ~$0.002, and 159M+ unique wallet addresses. For reliable RPC access to Polygon when building on Polymarket, Chainstack provides managed nodes with low-latency endpoints. When building applications that interact with the Polymarket API, reliable Polygon RPC access is essential for monitoring contracts, tracking trades, and submitting transactions. Source: https://polygon.technology/ Polygon PoS operates with a dual-layer architecture. The two layers are Heimdall and Bor. Heimdall-v2: Validator layer Heimdall is a proof-of-stake validation layer built on top of CometBFT. It performs two primary functions: monitors staking contracts deployed on Ethereum mainnet & manages the validator set periodically commits checkpoints to Ethereum ℹ️ A checkpoint is a Merkle root of all Bor block hashes within a given interval. Validators collectively sign the checkpoint; a proposer (selected by stake weight) submits it to the Ethereum root chain contracts. Checkpoints occur approximately every 30 minutes. Once a Polygon transaction’s checkpoint reaches Ethereum, that transaction achieves full L1 finality. Bor: Block producer layer Bor is an EVM-compatible block production layer based on Go Ethereum (Geth) with custom consensus modifications. Block producers are a subset of validators selected by Heimdall at regular intervals in units called spans and sprints. A span is a long window of blocks (6,400 blocks) divided into 100 sprints of 64 blocks each. Within a sprint, a single validator produces all blocks. Bor operates with 2-second block times and EVM compatibility, meaning Solidity contracts, ethers.js, viem, and Foundry all work without modification. All Polymarket on-chain events like OrderFilled, PositionsMerged & ConditionResolution are emitted on Bor: Soft finality: ~ 2 sec/Bor block. Eg: trading bots to confirm fills Full L1 finality: ~ 30 mins/Ethereum checkpoint. Eg: withdrawals to Ethereum Polygon PoS uses POL as its gas token (migrated from MATIC in 2024). Polymarket contracts are deployed at known addresses on Polygon, and all interactions require a small amount of POL for gas, typically under $0.01 per transaction. Polymarket API Architecture The Polymarket API exposes distinct endpoints for different layers: Gamma: Market discovery CLOB: Trading engine Data: Users & analytics WebSocket: Real-time streaming Gamma (market discovery) All market data is available through public REST endpoints. No API key, no authentication, no wallet required. <https://gamma-api.polymarket.com/events?limit=5> Data Model Polymarket structures data using two models: Event: A top-level object representing a question. Contains one or more markets. <https://gamma-api.polymarket.com/events> Market: A specific tradable binary outcome within an event. Maps to a pair of CLOB token IDs, a market address, a question ID, and a condition ID. <https://gamma-api.polymarket.com/markets> Events are further structured in two ways: Single-Market Events: One market represents a single binary outcome Multi-Market Events: Two or more markets forms grouped market pair with distinct outcomes across mutually exclusive possibilities. Eg: This multi-market event consists of multiple markets, each with a Yes/No outcome for a specific price threshold of Crude Oil (CL) by the end of March. 18% chance Crude Oil hits $120 by the end of the month. https://t.co/mpWrVU72SM— Polymarket (@Polymarket) March 18, 2026 To discover events via the /events endpoint, common parameters can be used to filter and sort the desired results ParameterDescriptionlimitMaximum number of results returned (pagination)offsetNumber of results to skip (pagination)orderSort field: volume24hr, startDate, endDateascendingSort direction: true ascending, default falsetag_idFilter by tag IDtag_slugFilter by tag slug instead of IDactiveFilter to only active (unresolved) resultsclosedFilter to only closed/resolved resultsarchivedFilter archived events Eg: Get the first 100 active events with the highest 24-hour trading volume <https://gamma-api.polymarket.com/events?active=true&closed=false&order=volume24hr&ascending=false&limit=100> Each market has outcomes & outcomePricesarrays that map 1:1. Prices represent implied probabilities: { "outcomes": "["Yes", "No"]", "outcomePrices": "["0.20", "0.80"]" } // Index 0: "Yes" → 0.20 (20% probability) // Index 1: "No" → 0.80 (80% probability) Outcome tokens are ERC-1155 assets on Polygon using the Gnosis Conditional Token Framework, they are fully on-chain standard ERC-1155 tokens. Every YES/NO pair in existence is backed by exactly $1 of USDC.e collateral locked in the CTF contract (0x4D97D...76045). ℹ️ Markets are tradable via the CLOB only if enableOrderBook is true. Always check this field before assuming a market has live liquidity. CLOB trading engine The CLOB API is the core trading component of the Polymarket API, responsible for order books, order matching, and trade execution. The system is hybrid-decentralized: an off-chain operator performs order matching with Exchange contract (audited by Chainsecurity), while settlement executes on-chain through signed EIP-712 messages. <https://clob.polymarket.com/> Polymarket’s CLOB APIs can be interacted with: SDK Client: https://docs.polymarket.com/api-reference/clients-sdks REST API: https://docs.polymarket.com/api-reference/introduction ❓ How to choose? If you want the fastest path from zero to a live order, use SDK. It handles EIP-712 struct hashing, HMAC header construction, nonce management. Available in Typescript, python & rust. Use REST if you are in a language without an official client, or if you need to separate key material from execution logic, or are building a trading system with a custom signing server. Setup the Client To interact with the CLOB easily, you can use the official client SDK. The client needs three things at init: the CLOB host, the chain ID (137 for Polygon), and a signer. The signer is your EOA wallet, used later to sign orders and derive API credentials. import { ClobClient } from '@polymarket/clob-client'; const client = new ClobClient( '<https://clob.polymarket.com>', 137, wallet.signer // your wallet used for signing & auth ); Orderbook The order book consists of an array of all active buy (bids) and sell (asks) orders for a market. It is the core primitive for price of tokens. Bids: Buyers willing to pay (highest price = strongest demand) Asks: Sellers willing to sell (lowest price = cheapest supply) Spread: The gap between them The token_id you pass here comes from the Gamma API: it is the numeric identifier for a YES or NO outcome within a specific market. const book = await client.getOrderBook('<token-id>'); console.log("Best bid:", book.bids); // [{ price: '0.62', size: '500' }, ...] console.log("Best ask:", book.asks[0]); console.log("Tick size:", book.tick_size); // will need later for creating order To fetch the same data via REST: const res = await fetch( `https://clob.polymarket.com/book?token_id=<token-id>` ); const book = await res.json(); console.log("Best bid:", book.bids[0]); console.log("Best ask:", book.asks[0]); console.log("Tick size:", book.tick_size); ℹ️ The orderbook endpoint is public so it does not require authentication. Authentication Order placement must be extremely fast on Polygon. Signing every request with a wallet would be slow. Instead the platform uses L1 and L2 authentication layers. L1: Wallet authentication These methods prove you control an Ethereum/Polygon wallet. It requires a signer with a private key because they must sign a message. No gas is spent, a set of credentials bound to your wallet address are created/derived using the following methods createApiKey() deriveApiKey() createOrDeriveApiKey() const creds = await client.createOrDeriveApiKey(); With REST APIs, you construct and sign the EIP-712 typed data manually, then POST the result to /auth/api-key. The four required headers carry your wallet address, the signature, and a nonce used to prevent replay attacks. const nonce = Date.now(); const sig = await wallet.signTypedData(domain, types, { nonce }); const res = await fetch('<https://clob.polymarket.com/auth/api-key>', { method: 'POST', headers: { 'POLY_ADDRESS': wallet.address, // Polygon signer address 'POLY_SIGNATURE': sig, // CLOB EIP-712 signature 'POLY_NONCE': String(nonce), // Current UNIX timestamp 'POLY_TIMESTAMP': String(nonce), // Nonce (default: 0) }, }); const { apiKey, secret, passphrase } = await res.json(); // will need all three in L2 L2: Authenticated trading Once you have an API key, the system switches to API credentials generated in L1 instead of wallet signatures. The SDK computes and attaches this automatically once you pass credentials to the constructor, You never call a login endpoint or manage tokens. const authedClient = new ClobClient( '<https://clob.polymarket.com>', 137, wallet.signer, creds // API credentials from L1 ); Alternatively, for REST APIs, each request must include signed headers derived from your API key: 'POLY_ADDRESS': address, // Polygon signer address 'POLY_API_KEY': apiKey, // User’s apiKey received in L1 Auth 'POLY_PASSPHRASE': passphrase, // User’s passphrase received in L1 Auth 'POLY_SIGNATURE': signature,// HMAC signature for request 'POLY_TIMESTAMP': String(Date.now()), // Current UNIX timestamp Orders All orders are EIP-712 typed data structs signed client-side before submission. When you call createAndPostOrder, the SDK builds the struct, signs it with your wallet, and POST it to the CLOB operator. The operator verifies the signature, checks your balance and allowance, and either matches the order immediately or places it on the book. If matched, the operator submits a settlement transaction to the CTF Exchange on Polygon. Order Types All orders on Polymarket are limit orders. Order types define how those orders are executed once submitted. GTC: Good-Till-Cancelled Rests on the order book at a specified price Remains active until fully filled or manually cancelled Also cancelled if your balance becomes insufficient Eg: Standard limit orders and passive trading strategies GTD: Good-Till-Date Same as GTC, but with a predefined expiration time Automatically cancelled at a specified Unix timestamp Eg: Time-bound or event-driven trades FOK: Fill-Or-Kill Executes immediately against available liquidity Must be filled completely or is cancelled entirely No partial fills allowed Eg: All-or-nothing execution when precision matters FAK: Fill-And-Kill Executes immediately against the order book Fills whatever portion is available Cancels any remaining unfilled amount Eg: When partial fills are acceptable, but you don’t want resting orders Before placing an order, all conditions below must hold before the operator accepts an order. Verify all before your first order: Valid Signature: Order must be correctly signed (EIP-712) Balance: Sufficient USDC.e for buys, or outcome tokens for sells: 0x2791B...84174 Allowance: CTF Exchange approved to spend your USDC.e and tokens: [0x4bFb4...982E](<https://polygonscan.com/address/0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E>) via client : client.setAllowances() API Credentials: Valid L2 API key, secret, and passphrase generated from the L1 step Create Order The price field is the implied probability expressed as a decimal 0.62 means you are willing to pay $0.62 per share (62% probability) size is the USDC.e notional you want to spend or receive tickSize in the options object must match the market’s tick size returned by /book above get tickSize from client: client.getTickSize('<token-id>') get tickSize from REST: /tick-size , pass <token-id> Set negRisk: true only if market.neg_risk is truereturned by /book above. These route through 0xC5d56...0f80a get negRisk from client: client.negRisk('<token-id>') get negRisk from REST: /neg-risk, pass <token-id> import { Side, OrderType } from '@polymarket/clob-client'; const order = await client.createAndPostOrder( { tokenID: '<yes-token-id>', price: 0.62, side: Side.BUY, size: 50 }, { tickSize: '0.01', negRisk: false }, orderType?: OrderType.GTC | OrderType.GTD, // Defaults to GTC ); console.log(resp.orderID); // will need later in getOrder With REST, you build and sign the order struct yourself. The signed order is posted as a JSON body alongside the L2 auth headers. async function createOrder() { const signedOrder = await buildAndSignOrder(); const body = { order: signedOrder, owner: API_OWNER, // UUID of the API key owner orderType: "GTC", "deferExec": false }; const res = await fetch(`${CLOB_URL}/order`, { method: "POST", headers: { "Content-Type": "application/json", ...l2Headers("POST", "/order", JSON.stringify(body)) }, body: JSON.stringify(body) }); const data = await res.json(); console.log("Order ID:", data.orderID); } Track Order getOrder queries the off-chain CLOB state and returns the current status and fill amount. This is the fastest way to check what happened to an order. For final on-chain confirmation that the settlement transaction landed on Polygon, listen for OrderFilled events on the CTF Exchange contract (covered in the step-by-step guide below). The two sources are complementary: CLOB gives you speed, the chain gives you finality. const order = await client.getOrder('<order-id>'); // received above in createOrder console.log(order.status); //(see "Order Status" section below ) console.log(order.size_matched); // USDC.e notional filled so far // All resting orders for this wallet const open = await client.getOpenOrders(); With REST, pass the order ID as a path parameter with L2 headers attached: const orderId = '<order-id>'; const res = await fetch( `https://clob.polymarket.com/order/${orderId}`, { headers: l2Headers('GET', `/order/${orderId}`) } ); const order = await res.json(); console.log(order.status, order.size_matched); Order Status Once the order is placed, the operator continuously runs a matching engine that pairs compatible orders. When a buy order at price X crosses with a sell order at price ≤ X, a match is found. The operator constructs a transaction using both signed orders and submits it to the on-chain exchange contract. The off-chain matching is what enables low-latency execution, no on-chain gas cost per order attempt. The status returned immediately after submission indicates how the operator handled your order: live: Order is resting on the book and waiting to be matched matched: Order matched immediately on submission; settlement is in progress delayed: Marketable order placed into a short delay window (~3 seconds, sports markets only) to prevent information advantage unmatched: Marketable order was not matched during the delay and is now resting on the book Trade Statuses Once matched, the settlement transaction moves through Polygon independently of the CLOB. The operator constructs a transaction using both signed orders and submits to Polygon via the executor. The CTF Exchange contract on Polygon verifies both order signatures, checks that combined conditions are satisfied (price, size, allowance), and performs an atomic swap: USDC moves from the buyer’s wallet, outcome tokens move from the seller’s wallet or are minted. MATCHED: Trade has been matched and sent for on-chain submission MINED: Transaction is included in a Polygon (Bor) block CONFIRMED: Transaction finalized successfully RETRYING: Submission failed and is being retried FAILED: Transaction failed permanently If CONFIRMED, the transaction lands on Bor in approximately 2 seconds. The contract emits OrderFilled, which is the definitive on-chain record of the trade. After the real-world event concludes, markets resolve via UMA’s Optimistic Oracle (0xCB1822...5130), connected to Polymarket via the UMA Adapter (0x6A9D22...F74). A price request is created when the market is initialized A proposer submits the outcome after the event ends A challenge window (~2 hours) allows disputes If undisputed: Outcome is accepted Condition is resolved on-chain If disputed: Escalates to UMA’s Data Verification Mechanism (DVM) Token holders vote on the final outcome Once resolved: Winning tokens can be redeemed via redeemPositions()on the CTF contract. Payout: Winning tokens: $1 per token Losing tokens: $0, worthless One such successful resolution as mentioned by UMA Protocol, co-founder: 95% of @Polymarket users won't know this, but tonight was a win mechanism design and prediction markets.@UMAprotocol is a decentralized oracle for resolving prediction markets. UMA faced its biggest test tonight, and succeeded. The system worked flawlessly—there was no… pic.twitter.com/gBR80bFApO— hal2001.hl (@hal2001) November 6, 2024 Resolution via Chainlink For short-duration markets (e.g., 15 minute crypto prices): Uses Chainlink Data Streams + Automation Resolves automatically on-chain Skips UMA entirely Data The Data API is part of the Polymarket API and focuses on user-level activity and analytics, helping retrieve structured data for tracking positions, performance, and historical activity. <https://data-api.polymarket.com/> Used when building dashboards, analytics pipelines, or monitoring systems: User Positions: Current holdings across markets, including outcome tokens and exposure Trade History: Executed trades with timestamps, prices, and sizes PnL Data: Realized and unrealized profit and loss across positions Activity Feeds: A record of actions tied to a wallet, useful for tracking strategies over time Eg: Fetch user positions const res = await fetch( `http://data-api.polymarket.com/positions?user=<wallet-address>` ); const positions = await res.json(); console.log(positions); Eg: Fetch trade history const res = await fetch( `http://data-api.polymarket.com/trades?user=<wallet-address>` ); const trades = await res.json(); console.log(trades); This layer becomes important once you move beyond placing trades and start analyzing how those trades are performing over time. WebSocket The Polymarket API WebSocket layer delivers real-time updates over persistent connections. For market-making systems and analytics dashboards, WebSocket eliminates polling. ChannelEndpointDataMarketwss://ws-subscriptions-clob.polymarket.com/ws/marketBook snapshots, tick updates, last trade priceUserwss://ws-subscriptions-clob.polymarket.com/ws/userOrder fills, status changes, cancellationsSportswss://sports-api.polymarket.com/wsLive sports market dataRTDSwss://ws-live-data.polymarket.comReal-time data service institutional feed Eg: Real-time market updates const ws = new WebSocket( 'wss://ws-subscriptions-clob.polymarket.com/ws/market' ); ws.addEventListener('open', () => { ws.send(JSON.stringify({ type: 'market', assets_ids: ['<yes-token-id>'], })); }); ws.addEventListener('message', (event) => { const msg = JSON.parse(event.data); console.log(msg); }); Eg: Real-time user updates const ws = new WebSocket( 'wss://ws-subscriptions-clob.polymarket.com/ws/user' ); ws.addEventListener('open', () => { ws.send(JSON.stringify({ type: 'user', // requires L2 auth headers handled separately })); }); ws.addEventListener('message', (event) => { const msg = JSON.parse(event.data); console.log(msg); }); ℹ️ If an authenticated client goes inactive, Polymarket’s server cancels all open orders for that session. Production bots must implement a heartbeat signal to maintain active session status. See more: real-time-data-client library Polymarket API step-by-step integration guide This Polymarket API step-by-step integration guide takes a project from a blank directory to a working Polymarket trading client. Set up a Polygon wallet. Generate an EOA private key using ethers.js or viem. Fund the wallet with a small amount of POL (gas token) for transaction fees, typically $0.01–0.10 worth covers hundreds of transactions. Export the private key as an environment variable. Deposit USDC to your Polymarket profile address: The profile address is the address that holds the trading balance. It corresponds to your EOA or proxy wallet. Bridge or transfer USDC (Polygon-native) to this address. Configure a Chainstack endpoint. Confirm the balance via GET /balance via Chainstack endpoint on Polygon. Install dependencies. npm install @polymarket/clob-client @ethersproject/wallet viem Derive API credentials: Call createOrDeriveApiKey() using your signer. Set USDC and CTF allowances. Run client.setAllowances() once before placing any orders. This sends two transactions to Polygon: one approving the CTF Exchange to spend USDC, one approving the CTF contract. These approvals persist until explicitly revoked. Confirm with client.getAllowances(). Fetch a market from Gamma.: Call GET <https://gamma-api.polymarket.com/markets?active=true&limit=5>. Pick a market. Record its conditionId and the token_id for the YES outcome token. Verify it is active and has volume above your minimum threshold. Query the order book: Call client.getOrderBook('<token-id>'). Inspect the spread, negRisk, tickSize, depth at various price levels, and midpoint. Confirm the market has sufficient liquidity for your intended order size before placing. Place a limit order: Call client.createAndPostOrder() with the token ID, price, size, and OrderType.GTC. Confirm the response contains a valid orderID. Check order status via client.getOrder('<order-id>'). Subscribe to real-time updates: Open a WebSocket to the market channel and subscribe to the token ID. Confirm you receive a full book snapshot on connect followed by incremental updates. For fill notifications, subscribe to the user channel with your API credentials. Connect a Polygon RPC for on-chain monitoring: Use the configured Chainstack endpoint. Set up a watchContractEvent listener on the CTF Exchange for OrderFilled events filtered to your wallet address. This is the definitive on-chain confirmation of a trade. Once all the steps are complete, you can build a range of apps on top of polymarket from simple analytics to find winner wallets to trading bots. 👨‍💻 If you want to see it action: PolyClaw is an OpenClaw skill designed for interacting with Polymarket directly from a chat interface. It connects your Polymarket activity to a messenger-based workflow and helps surface potential arbitrage opportunities by analyzing relationships between different markets. You can explore the implementation here: OpenClaw Skill: https://github.com/chainstacklabs/polyclaw Alpha Bot: https://github.com/chainstacklabs/polymarket-alpha-bot Blog: https://chainstack.com/build-polymarket-bot/ To run this kind of setup reliably, you’ll also need access to blockchain infrastructure. This is where tools like Chainstack come in quietly, providing RPC access to Polygon so your bot can read market data and execute interactions without friction. This setup is not a guaranteed profit machine, but it is a solid playground for understanding how inefficiencies in prediction markets can be detected and acted on programmatically. Polymarket builder tools A range of official and community tools are available to help you build, trade, and analyze data on Polymarket. clob-client (TypeScript): Official CLOB SDK. Handles order placement, order books, and API credential derivation. Works with viem + ethers. real-time-data-client (TypeScript): WebSocket client for live market data. Handles reconnections and subscriptions out of the box. clob-order-utils (TypeScript): Low-level helpers for building and signing EIP-712 orders manually rs-clob-client (Rust): Rust client with alloy signer support and WebSocket streaming. uma-ctf-adapter (Solidity): Connects UMA Optimistic Oracle to CTF for market resolution. Polymarket Agents (Python): Reference implementation for LLM-based autonomous trading agents. PolyClaw OpenClaw Skill: OpenClaw skill designed for interacting with Polymarket directly from a chat. Polygon RPC: Production-grade Polygon RPC (archive + WebSocket + low latency). Useful for bots and indexers. Polymarket Subgraphs (GraphQL): Goldsky-powered subgraphs for positions, order book, activity, open interest, and PnL. Polymarket сonsiderations Even though Polymarket has its benefits, you should take time to understand the risks before participating: Market Risk: If your prediction turns out to be wrong, you can lose the full amount you committed, just like in any other trading environment. Low Liquidity: Some markets may not have enough participants, which can make it difficult to buy or sell positions, especially as the outcome date gets closer. Thin Markets: In markets with low activity, prices can be affected more easily by large trades or speculation. Transparency on-chain helps, but price swings can still happen. Regulatory Availability: Access to prediction markets depends on where you live. Some regions restrict or ban them, and rules can change, so it is important to check your local regulations before using the platform. Oracle Settlement: Final results are determined by external data providers. If there is ambiguity or disagreement about the outcome, resolution and payouts might take longer. Smart Contract Risk: Because the platform runs on blockchain infrastructure, there is always a risk of technical vulnerabilities. Audits and reliable wallets reduce exposure but cannot remove it completely. Only use funds you are prepared to lose, and make sure you understand both the risks and the legal context in your region. Conclusion The Polymarket API turns prediction markets into programmable infrastructure. Deployed on Polygon PoS for fast, low-cost settlement and backed by USDC.e, it exposes a clean set of primitives that developers can build directly on top of. The Gamma API gives you frictionless market discovery with no authentication required. The CLOB handles order submission and real-time book depth through REST and WebSocket. Everything runs on Polygon, meaning the same EVM tooling you already use, ethers.js, viem, Foundry, works without modification. The ecosystem is early. Most of the interesting tools have not been built yet. Whether you are building a trading bot, a probability dashboard, or an analytics pipeline, the architecture is well-documented, the contracts are audited, and the on-chain history is fully transparent. The market is open. Building on Polygon? Deploy your Polygon node on Chainstack → FAQ How do I authenticate with the Polymarket CLOB API? Polymarket uses two auth layers. L1 proves wallet ownership via an EIP-712 signature and returns your API key, secret, and passphrase. L2 uses those credentials for all trading requests via HMAC-signed headers. With the SDK, createOrDeriveApiKey() handles L1 automatically. With REST, sign the typed data manually and POST to /auth/api-key. What is a Polymarket token ID and how do I find it? A token ID identifies a specific outcome — YES or NO — within a market. Retrieve it from the Gamma API: call /markets and inspect clobTokenIds. First element is YES, second is NO. You need it to query the order book, place orders, and subscribe to WebSocket updates. Does Polymarket have a testnet or sandbox? No. All development happens on Polygon mainnet with real USDC.e. To minimize risk, test with very small order sizes ($1 or less) and use FOK or FAK order types so orders don’t rest on the book. What is the difference between the Gamma API and CLOB API? Gamma is market discovery — events, prices, and metadata, no authentication required. CLOB is the trading layer — order books, order placement, and fill tracking, requires API credentials. Most integrations use both: Gamma to find a market, CLOB to trade it. How does Polymarket resolve markets? After an event concludes, a proposer submits the outcome to UMA’s Optimistic Oracle. A ~2-hour challenge window opens for disputes. If undisputed, the condition resolves on-chain and winning token holders redeem $1 per token via redeemPositions(). Short-duration markets use Chainlink Data Streams instead, resolving automatically without the UMA dispute process. What Polygon RPC should I use for Polymarket bots? Public endpoints are rate-limited and unreliable under load — a real problem when your bot monitors OrderFilled events, tracks WebSocket feeds, and submits transactions simultaneously. For production, use a managed provider with dedicated throughput, WebSocket support, and archive access. Chainstack provides low-latency Polygon endpoints with all three. What is the Polymarket API used for? The Polymarket API allows developers to access market data, order books, user activity, and real-time updates programmatically. It is commonly used for trading bots, analytics dashboards, market research tools, and automated trading systems built on Polygon. Additional resources OpenClaw bot for Polymarket blog article PolyClaw SKILL for OpenClaw — Polymarket arbitrage in your pocket video guide How to build a Polymarket bot using Polygon RPC blog article Profit Either Way on Polymarket? (Hedging Bot) video guide Polygon’s second life: Rebuilding traction via payments How to get a Polygon RPC endpoint in 2026 #### Powering Metaverse gaming and social media marketplace – Gamerse on Chainstack Gamerse is a community-driven social hub that connects NFT games with players in a Metaverse social aggregator ecosystem. The project aims at unifying the fragmented NFT gaming landscape and fostering a welcoming environment for all stakeholders to participate. What is Gamerse? Gamerse’s goal is to improve the GameFi experience by helping its users make the most of exciting NFT gaming applications, interacting within the platform, and trading any sort of digital assets within the Metaverse. At the same time, the platform aims at tackling some of the biggest problems in the Gamefi space, such as the case of fragmentation within the landscape. As Web3 gaming projects and communities are scattered across the web and on different blockchains, Gamerse focuses on becoming the leading social hub for Web3 gamers, enthusiasts, and traders to come together to forge new connections, communities and trade their exclusive NFTs. The rapidly growing blockchain-gaming world will benefit greatly from this single central hub, as the discoverability of interesting initiatives improves drastically. While most current blockchain-based gaming projects are focused on connecting to one specific blockchain, Gamerse’s goal is to achieve maximum cross-chain interoperability and connect the many blockchains under a single roof with its platform. The Gamerse marketplace’s role here would be to aggregate gamer-to-gamer trading, acting as a trusted escrow. This means users will be able to easily discover and filter listed NFTs by category, chain, and price for complete transparency. Simply put this would allow you to find what you want and get the info you need — all in just a few clicks. Up until now, Gamerse has made steady waves across the landscape, by doing a successful IDO with its $LFG token on 4 major platforms – Gamezone, 0xBull, Moonstarter, KCCPAD-MEXC CEX listing. This is further highlighted by the platform’s accumulation of over 70 GameFI project partnerships and integrations ever since its launch in October 2021, in addition to the launch of the LFG Polygon Token bridge. How did Gamerse come across Chainstack? When the Gamerse developer team kickstarted their search for a reliable Web3 infrastructure provider, they first and foremost needed one that can successfully manage the BNB Chain staking program and subsequently the Gamerse platform itself. And to achieve this goal, they first set out to explore potential opportunities via relevant search queries, reviews, and recommendations from other tech teams that faced a similar situation. While searching, the Gamerse team stumbled upon several competitor solutions but found that their availability, in terms of multi-chain support, was severely lacking. Considering the platform’s focus on cross-chain interoperability, this could certainly be detrimental to their successful operations, which is why they opted for moving forward with a Chainstack integration in the end. How does Chainstack’s offer match Gamerse needs? Keeping in mind the critical factors outlined above that the Gamerse development team was looking to answer, Chainstack became a perfect fit for their use case in terms of cross-chain capabilities and the scalability of such offerings. Above anything else, however, Chainstack’s ability to support Gamerse efforts and $LFG token on the BNB Smart Chain also became an avenue that matched exceptionally. Apart from that, the Gamerse development team saw a smooth onboarding process thanks to the introductory meeting with one of our Business Development managers, who made sure the entire process was completed effortlessly. And to put the cherry on top, the overall flexibility of Chainstack’s subscription packages guaranteed that Gamerse is truly getting their money’s worth, considering their needs and budget. Outcome Thanks to the Chainstack platform’s intuitive and user-friendly interface, Gamerse saw little need to engage with our team in solving any bottlenecks while running their services on top of our secure and robust infrastructure. In turn, this created a smooth sailing experience and more opportunities for community actions together to look forward to. What does Gamerse like about Chainstack? Chainstack has established itself as one of the leading infrastructure providers in the Blockchain/Web3 space and collaborating with them ensures the reliability and performance of our platform. As a node provider, Chainstack saves us time and resources so our team can focus on accelerating product development and delivering a unifying social hub for the GameFi space. Khaled Jama, Founder/CEO, Gamerse What does Chainstack like about Gamerse? As the growth of the NFT landscape becomes ever so rampant, the need for social marketplaces to unite the fragmented landscape, like that of Gamerse is more apparent than ever. That is why we are thrilled to support such initiatives with powerful and reliable infrastructure that will allow them to focus more on creating an awesome product, while we take care of the rest. Eugene Aseev, Founder & CTO, Chainstack Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Predictive crypto trading: Why AI algorithms thrive in volatility Keeping pace with fast-moving cryptocurrency markets is a challenge that every trader faces. The volatility often correlates to speedy decision-making, granular strategy adjustments, and a constant need for risk management. Here’s where AI and predictive analytics come into the picture. These technological innovations are becoming game-changers, revolutionizing cryptocurrency trading by empowering traders with data-driven decision-making tools, automated strategies, and advanced risk management capabilities. This blog post steps into the fascinating world of AI crypto trading and analytics, exploring how it is fundamentally changing the way trades are conducted. From the utilization of neural networks to enhance prediction accuracy to the ethical considerations surrounding AI’s influence on financial markets, we will take a closer look at a realm where machine learning and advanced algorithms dictate the pulse of cryptocurrency trading. AI and machine learning in crypto trading When we think of machine learning, we usually imagine Netflix suggestion algorithms or voice recognition on our smartphones. Yet, this transformative technology has a far wider reach—it’s making a powerful impact on the frontier of AI in crypto. Seasoned trading veterans and newcomers alike are turning to AI-powered trading bots that incorporate machine learning. These revolutionary tools can analyze colossal volumes of market data, recognize intricate patterns, and ultimately make predictions about lucrative trading opportunities. They’re incredibly efficient, executing trades faster and more accurately than a human could ever manage. But, there’s more to this technological marvel. Figure 1: Algorithmic Trading | Key Statistics; Source: AnalyzingAlpha By introducing concepts such as neural networks and deep learning into the equation, the precision of these predictions can be taken to an unprecedented level. This fusion of AI and machine learning is unlocking possibilities that were once left to financial fiction, putting the power into the hands of every diligent trader out there. AI-powered trading AI-powered trading is more than a cool concept; it signifies a paradigm shift in the world of cryptocurrency. AI-powered trading bots execute trades based on predefined conditions and perform at a pace and precision that humans can’t match, opening a new sphere of opportunities in high-speed, efficient trading. These automated systems eliminate the need for constant monitoring and manual inputs, removing large amounts of strain, stress, and human error from the process. They make rational and timely decisions based on their superior processing capabilities, working tirelessly around the clock, a feature particularly beneficial in the 24/7 cryptocurrency markets. Figure 2: Algorithmic Trading Market, by Region (USD Billion); Source: MarketsandMarkets Moreover, AI-powered trading doesn’t just bring speed; it brings accuracy. These advanced systems accurately predict market movements, apply risk management rules, and execute trades perfectly in line with programmed strategies. And the best part? They perform all these complex actions at split-second speeds. Now, imagine combining this prowess of AI trading with the predictive power of machine learning. The result is amplified potential, refreshing profitability, and transformative success in crypto trading. The power of predictive analytics On the other hand, predictive analytics, another cornerstone of AI cryptocurrency trading, is having a profound effect on trading strategies and decision-making. It unlocks the power of data by using both historical and real-world, real-time data to deliver forecasts about future market trends and movements. This data-driven approach offers a significant advantage to traders. Utilizing predictive analytics reduces uncertainty and guesswork when strategizing for the future. It allows traders to augment their intuition with actionable insights derived from large volumes of data. This means traders can now make better informed, confident decisions that align with evolving market trends. Moreover, predictive analytics can identify potential trading opportunities and risks before they’re apparent to the human eye, allowing traders to capitalize on market trends and adapt their strategies quickly. This proactive approach to trading can often make the difference between profit and loss in the fast-moving cryptocurrency market. But how exactly does AI fit into the predictive analytics equation? Well, AI-driven analytics are what pull these valuable predictions from raw data. Algorithms process massive amounts of market data, sifting through noise, identifying patterns, and deriving meaningful trends. The significance of AI’s role in enhancing the potential of predictive analytics, therefore, cannot be understated. Risk management in cryptocurrency trading Any seasoned trader knows that risk management is at the heart of successful trading. The unpredictable swings of the cryptocurrency market make it particularly crucial. And this is where AI steps in with a solution. AI has the remarkable ability to analyze data, learn from it, and make informed predictions. In the context of crypto trading, this means spotting potential risk factors before they become full-blown issues. When this predictive capability is paired with a robust risk mitigation strategy, it can lead to more significant profits by offsetting potential losses. By continuously learning from market behavior and adjusting its predictions accordingly, AI plays a crucial role in adapting trading strategies in real-time, further enhancing the efficiency of risk management. This combination of AI and risk management provides an exhaustive shield against the inherent risks of trading in volatile markets. AI-driven trading and portfolio management Portfolio management in trading involves the delicate task of balancing the risk and return of a group of financial assets. In crypto trading, where volatility often rules the roost, effective portfolio management can mean the difference between substantial returns and significant losses. Enter AI-driven trading, an innovation that is reshaping portfolio management. AI algorithms, coupled with predictive analytics, provide valuable foresights into market trends, help identify profitable trading opportunities, and shed light on potential risks. This data-guided approach enables portfolio managers to optimize the diversification of assets in their portfolio, balancing risk and reward based on predicted market movements. In risk management, AI’s predictive capabilities power robust strategies that protect investments from potential market downturns. By forecasting risk and automatically reacting to market changes, AI ensures timely, data-guided decisions that can protect assets and secure returns. Figure 3: Which AI use cases will you continue to invest in? (top 5 in ranking order); Source: Zenledger In essence, when it comes to crypto portfolio management, incorporating AI-driven trading strategies is like having an expert advisor by your side—capable of making precise, timely, and data-backed decisions that enhance portfolio performance. Machine learning and its role in trading Machine learning, a vital subset of Artificial Intelligence, introduces adaptability and continuous learning to the trading environment. It’s a type of AI that enables computers to learn from data, discern patterns, and refine predictions without needing explicit programming, offering a dynamic edge to trading predictions. In the context of crypto trading, machine learning models train on vast datasets, including historical pricing, transaction volumes, and various other market indicators. By crunching this data, identifying patterns, and learning from both successful and unsuccessful trades, these models help forecast future market trends and price variations more accurately over time. Two prime examples of machine learning techniques commonly employed in the trading sphere are supervised learning and unsupervised learning. In supervised learning, models are trained on labeled data to predict future outcomes—an ideal approach for predicting price movements. Unsupervised learning, on the other hand, discovers hidden patterns and relationships in unlabeled data—perfect for identifying new trading opportunities or undetected risks. But machine learning’s utility doesn’t just stop at predictions. It also aids in automating trading strategies, executing real-time trades, managing risk, and much more, effectively reshaping the way traders engage with the financial markets. Neural networks and deep learning Neural networks and deep learning form the backbone of many AI models, extending the reach and accuracy of AI predictions. These powerful techniques enable AI systems to recognize and interpret complex patterns, thus enhancing the accuracy of trading predictions. Neural networks function much like the human brain, using interconnected layers of nodes (or “neurons”) to process data and generate outputs. While they can be trained to perform a variety of tasks, one notable application in trading is their ability to process vast amounts of market data and identify non-linear relationships that other algorithms might miss. Deep learning, a subset of machine learning, uses neural networks with multiple layers (hence “deep”) to model and understand complex patterns. It’s particularly useful in analyzing unstructured data, such as market sentiment from social media or news articles, making it a valuable tool for AI-powered trading bots and predictive analytics. Figure 4: Artificial Intelligence vs Machine Learning vs Deep Learning; Source: Singapore Computer Society These advanced techniques help to model the ever-changing dynamics of the cryptocurrency market and augment the decision-making ability of AI trading systems. By understanding trends at a granular level, traders can augment their strategies with deep data insights, therefore increasing their chances of success. Reinforcement learning in autonomous trading strategies Traders often rely on experience and hard-learned lessons to fine-tune their strategies. But what if a machine could learn the same way, but much faster? Reinforcement learning, a subset of machine learning, does exactly that. At its core, reinforcement learning is all about learning from mistakes. In a trading context, AI algorithms equipped with reinforcement learning perform a myriad of trades, learning from each success and failure. Over time, these algorithms improve, making better trading decisions based on the wealth of experience they’ve amassed. The result? Autonomous trading strategies that continuously adapt and evolve, managing to stay a step ahead even in the most turbulent markets. And as these strategies improve, they offer the tantalizing potential of better returns on investment. Sentiment analysis in trading Sentiment plays a critical role in trading decision-making. Public opinion can sway the market, making sentiment analysis a significant factor in AI-powered trading. The primary role of sentiment analysis is to gauge market sentiment and align trading strategies accordingly. AI, particularly Natural Language Processing (NLP), plays a crucial role in analyzing sentiment. By processing data from various sources like social media and news outlets, AI can understand market sentiment at any given moment. This capability assists traders in adapting their strategies to align with the market mood—pushing when the sentiment is bullish, and showing restraint when the sentiment is bearish. In addition to responding to current sentiment, AI can also forecast changes in sentiment. By analyzing sentiment trends, AI can help traders predict upswings and downturns in market mood, further enhancing their trading strategy’s effectiveness. The transforming power of sentiment analysis in AI-powered trading is immense. It allows traders to become proactive rather than reactive, aligning with the market sentiment swings, and making more informed, timely decisions. Emotionless trading: Mitigating biases with AI Emotions are an integral part of human nature, but when it comes to trading, they often lead to irrational decisions. Fear, greed, and even excessive excitement can cloud judgement, leading to impulsive decisions and unfavorable outcomes. This is where AI steps in, bringing a level of rationality to trading. AI trading bots analyze the market based on logical parameters and data-driven insights, keeping emotions out of the equation entirely. This emotionless approach results in unbiased decision making, which, in volatile markets like cryptocurrencies, can make a significant difference. Moreover, AI’s ability to systematically examine and interpret complex data sets, align strategies with market trends, and promptly respond to market shifts ensures that trading decisions are grounded in solid data and logic. This helps keep costly emotional biases at bay, offering traders more consistent returns and reduced risk of potential losses. Figure 5: Algorithmic Trading | Market Statistics; Source: AnalyzingAlpha Overall, by neutralizing emotional biases, AI significantly enhances trading accuracy, consistency, and profitability. Real-time data analysis in AI trading In the dynamic world of crypto trading, real-time data is a game-changer. Real-time data analysis, enhanced by AI, offers enhanced agility, precision, and efficiency, improving trading outcomes significantly. AI-powered systems can process and analyze real-time data from across the globe in the blink of an eye, something human traders simply cannot match. AI systems can monitor multiple markets simultaneously, recognize patterns, and make informed, precise trading decisions based on current market conditions. The power of real-time data goes beyond just speed. It enables traders to respond to market changes instantaneously, adjusting strategies on the fly, and capitalizing on fleeting opportunities that might otherwise be missed. This ‘live action’ analysis ensures traders’ strategies remain aligned with market movements and trends, providing valuable momentum that can lead to improved trading performance. In essence, real-time data analysis, when combined with AI’s processing prowess, significantly enhances traders’ ability to make informed decisions promptly and accurately, contributing to more effective, profitable trading. Further reading Start capitalizing on the intersection between AI and Web3 with these comprehensive Chainstack resources: Solana trading and sniping pump.fun bot: Learn how to create a fully coded Python bot directly interacting with the pump.fun programs & accounts, not relying on any 3rd party APIs. Exploring the new Chainstack ChatGPT plugin: Start retrieving blockchain data effortlessly using natural language with the official Chainstack ChatGPT plugin, regardless of your skill. A look into generative NFTs: Learn about how generative art blends with blockchain technology and NFTs to unlock new financial prospects for artists using AI and more. BonusTrade.AI on Chainstack: Explore how BonusTrade.AI unlocks real-time crypto market insights with reliable low latency high performance Chainstack infrastructure. Brave new adventures in AI+Web3 with Eldarune and Chainstack: See Eldarune successfully tackle multichain performance bottlenecks for a superior AI-driven Web3 gaming experience. Bringing it all together The advent of AI and predictive analytics has ushered in a new epoch in cryptocurrency trading. They’re not just tools but game-changers, leveling the proverbial playing field and enabling traders to navigate the choppy seas of the crypto market with unmatched precision. From real-time trade executions to data-driven predictions, AI streamlines the trading process and brings increased certainty to an inherently unpredictable terrain. With the reinforcement learning’s ever-improving algorithms, traders can watch their strategies evolve and adapt. Aside from its powerful tools, AI also introduces a new ethical dimension to the financial markets, raising vital questions that demand our immediate attention. As we look forward, the possibilities seem boundless. If the current trends are any guide, the convergence of AI and predictive analytics will continue transforming the world of crypto trading in unforeseen ways, opening doors to advancements that, until recently, we could only dream of. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Prepare now for the Solana Agave 2.0 upgrade The Solana Agave 2.0 upgrade is just around the corner, and Chainstack is fully prepared to support you through this major release! This is more than just an upgrade—it’s a significant step in enhancing the decentralization, security, and performance of the Solana blockchain. As a Web3 developer, here’s everything you need to prepare for a seamless transition. Why Solana Agave 2.0 matters? Agave, the new Rust-based client for Solana, is designed to bolster network resilience by moving toward a multi-client structure. Alongside Agave, Solana is introducing the C-based Firedancer client. Together, these clients will decentralize and strengthen the network, requiring all nodes to transition to Agave v2.0 by October 21, 2024. The Agave 2.0 upgrade affects various API methods, phasing out older methods and replacing them with optimized ones. This shift aims to minimize any potential disruptions, with backward-compatible replacements already widely available. Key changes to prepare for If you’re using any of the following deprecated API methods, now is the time to update your calls to ensure compatibility with Agave 2.0: Deprecated methodReplacement methodconfirmTransactiongetSignatureStatusesgetSignatureStatusgetSignatureStatusesgetSignatureConfirmationgetSignatureStatusesgetConfirmedSignaturesForAddressgetSignaturesForAddressgetConfirmedBlockgetBlockgetConfirmedBlocksgetBlocksgetConfirmedBlocksWithLimitgetBlocksWithLimitgetConfirmedTransactiongetTransactiongetConfirmedSignaturesForAddress2getSignaturesForAddressgetRecentBlockhashgetLatestBlockhashgetFeesgetFeeForMessagegetFeeCalculatorForBlockhashisBlockhashValid or getFeeForMessagegetFeeRateGovernorgetFeeForMessagegetSnapshotSlotgetHighestSnapshotSlotgetStakeActivationgetAccountInfo | Solana (alternative approach) How to replace confirmTransaction with getSignaturesStatuses? To replace the deprecated confirmTransaction method with its getSignaturesStatuses replacement, you can use the following: import { Connection, Transaction, SendOptions } from '@solana/web3.js'; async function sendAndConfirmTransaction( connection: Connection, transaction: Transaction, timeout: number = 30000, // 30 seconds default timeout options?: SendOptions ): Promise<string> { // Send the transaction const signature = await connection.sendTransaction(transaction, options?.signers || [], { ...options, skipPreflight: options?.skipPreflight || false }); // Create a promise that will reject after the timeout const timeoutPromise = new Promise((_, reject) => { setTimeout(() => { reject(new Error(`Transaction confirmation timeout after ${timeout}ms`)); }, timeout); }); // Create the confirmation promise const confirmationPromise = (async () => { let done = false; while (!done) { // Get the status of the transaction const response = await connection.getSignatureStatuses([signature]); const status = response.value[0]; if (status) { if (status.err) { throw new Error(`Transaction failed: ${status.err.toString()}`); } // Check if we have enough confirmations if (status.confirmationStatus === 'finalized') { done = true; return signature; } } // Wait a bit before checking again await new Promise(resolve => setTimeout(resolve, 1000)); } })(); // Race between timeout and confirmation try { return await Promise.race([confirmationPromise, timeoutPromise]); } catch (error) { // If it's a timeout error, we should still return the signature if (error.message.includes('timeout')) { return signature; } throw error; } } // Example usage async function example() { const connection = new Connection('CHAINSTACK_NODE'); const transaction = new Transaction(); // ... add your transaction instructions here ... try { const signature = await sendAndConfirmTransaction(connection, transaction, 60000, { skipPreflight: false, // ... other options }); console.log('Transaction confirmed:', signature); } catch (error) { console.error('Transaction failed:', error); } } Chainstack: Ready for Agave 2.0 At Chainstack, we’ve ensured that your infrastructure is fully prepared for Agave 2.0, offering you a smooth and uninterrupted transition: Seamless transition: Chainstack services are ready and fully compatible with Agave 2.0. Enhanced security: Benefit from Agave’s multi-client architecture, designed to increase decentralization and security. Optimized performance: Transitioning to updated API methods means faster and more reliable interaction with the Solana network. To get ready for Agave 2.0, review the Agave v2.0 transition guide and adjust your API calls as needed. Our support team is on standby to assist, ensuring this transition is as seamless as possible for you. Further reading How Chainstack supports high-performance trading on Solana: Learn how Solana Trader nodes ensure 100% landing rates with Priority Fees support and integrate them. Solana reloaded and next gen RPCs: Explore our massive Solana infrastructure update to optimize latency, coverage, and speed for Global Nodes. How to use Program Derived Addresses: Learn how to use Program Derived Addresses for state management in Solana, their benefits, creation process, and practical applications. How to calculate transaction fees programmatically: Get to know Solana’s deterministic fee model and learn how to calculate transaction fees programmatically to optimize your project. How to retrieve historical data effectively: Learn how to retrieve historical data on Solana effectively, using transaction replay, Geyser plugins, 3rd-party services, and others. Master guide to troubleshooting common development errors: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization, blockstore errors, and more. How to overcome the 1000 transaction limit: Learn to handle Solana’s 1000 transaction limit with getSignaturesForAddress. Use pagination and recursion to fetch large transaction lists. What is the right transaction commitment level: Get to know what transaction commitment levels are on Solana and how to make the right choice when it comes to your use case. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Bringing it all together The Solana Agave 2.0 upgrade is a crucial step forward for the network, and at Chainstack, we’re ensuring that you can harness its full potential without any disruptions. By aligning our infrastructure with the Agave 2.0 upgrade, we’re giving you the tools you need to continue building scalable, secure, and high-performance DApps on Solana. Stay informed, stay ahead, and build the future of Web3 together with Chainstack and Solana Agave 2.0. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Private blockchains vs ZK rollups: key tradeoffs TL;DR Enterprises looking for blockchain privacy face two fundamentally different bets: private blockchains say trust the operators, ZK rollups say trust the math. A recent clash between the co-founders of Canton and ZKsync brought this tension into the open, and both sides have billion-dollar institutions building on them right now. This article breaks down what each approach actually does and where the real tradeoffs are. I guess it's that time of the day again to warn about the systemic risk of relying on ZKP for privacy… 🧵 https://t.co/V3EMRfZ4Pz— Shaul Kfir (@ShaulKfir) March 20, 2026 The enterprise privacy problem Enterprises that need blockchain capabilities — settlement, tokenized assets, multi-party workflows — but can’t expose their data on a public ledger have a problem. Think banks settling trades, asset managers issuing tokenized funds, or institutions running cross-border payments. The data is sensitive, often regulated, and not something you’d put on Ethereum for anyone to read. Two approaches have emerged: private blockchains and ZK rollups. Both promise privacy, but they make fundamentally different bets on how to achieve it. A recent back-and-forth on X between Shaul Kfir (co-founder of Digital Asset, behind Canton) and Alex Gluchowski (inventor of ZKsync, behind Prividium) brought this tension into the spotlight. Kfir warned about “the systemic risk of relying on ZKP for privacy.” His core point: “There will ALWAYS be bugs. The question is, when a bug exists, how big is the blast radius?” The inventor of ZKsync fired back: “If this logic held, we would not have aviation.” What matters is redundancy and containment — multiple independent systems catching each other’s failures — and private blockchains relying on trusted operators lack both. Let’s break down what each approach actually is, and where the tradeoffs lie. Private blockchains vs ZK rollups: how each works Private blockchains On public blockchains like Ethereum or Bitcoin, anyone can join the network, run a node, and read every transaction ever recorded. That openness is a feature for decentralization, but a dealbreaker for enterprises that can’t afford to have their trading volumes, counterparties, or internal operations visible to competitors — or to anyone at all. A private (or permissioned) blockchain flips this model. It restricts who can participate: only authorized parties can run nodes, submit transactions, or view data. Think of it as a members-only network where a group of banks could run a shared ledger completely invisible to outsiders. The network operator decides who gets in and what they can see, rather than the network being open by default. Privacy in private blockchains comes from access control. Since only approved participants are on the network, sensitive data never touches a public chain in the first place. Some implementations go further — for example, Canton uses sub-transaction privacy, where each party only sees the parts of a transaction relevant to them. If Bank A and Bank B settle a trade, Bank C on the same network sees nothing about it. The trust model is operator-based. There’s no mathematical proof backing each state transition. If an operator’s keys are stolen or an insider goes rogue, the system relies on access controls and encryption to keep bad actors out, not on cryptographic verification to catch them. ZK rollups ZK rollups were originally built to solve a different problem: scalability. Public blockchains like Ethereum can only process a limited number of transactions per second, so ZK rollups batch thousands of transactions off-chain and submit a compact validity proof back to the base layer. This proof cryptographically guarantees that every transaction in the batch was executed correctly — without the base layer needing to re-execute them one by one. 📖 For a deeper dive into how this works, check out zkEVM and ZK Rollups explained. But here’s where it gets interesting for enterprise privacy: the same cryptographic machinery that lets ZK rollups compress transactions also lets them hide them. A validity proof says “all of these state transitions are correct” without revealing what the transactions actually were. This means you can have a private execution environment where transactions stay confidential, while still anchoring the integrity of the entire chain to a public, decentralized base layer like Ethereum. Prividium is one example that tailors this for institutional use. Technically, it’s a validium — transaction data stays off-chain in the operator’s infrastructure rather than being posted to Ethereum, with only proofs and state commitments anchored on-chain. Each institution deploys its own private chain — Deutsche Bank has launched for tokenized fund management, UBS completed a proof-of-concept for tokenized gold. Transactions stay private, but the chain periodically posts a cryptographic proof to Ethereum verifying that every state transition was valid, without revealing what the transactions were. Even if the operator misbehaves, the proof catches the inconsistency. The math handles integrity, not trusted operators. Auditability, trust, and infrastructure: where they diverge Source: https://x.com/CyprxResearch/status/2038285053671948436 Auditability Auditability is where private blockchains make their strongest case. Kfir’s point: even if the ZK proof system is flawless, a bug anywhere else in the stack causes silent failures. A ZK proof only proves that the bytecode was executed correctly — but if the compiler that generated that bytecode had a bug, the proof will “correctly” verify a wrong action. This isn’t theoretical: a security audit of ZKsync’s compiler uncovered a vulnerability that could have allowed users to withdraw locked collateral. The math worked perfectly — it just proved the wrong thing. This concern isn’t unique to Prividium or ZKsync — it applies to any ZK rollup. Auditability is only as strong as the full stack, not just the proof layer. Trust minimization Trust minimization is where ZK rollups push back. Gluchowski argued that private blockchains have “no cryptographic verification layer and no independent check.” In a private blockchain, if a trusted operator is compromised — whether through stolen keys, an insider going rogue, or a software vulnerability — there’s no independent system that catches the problem. The operator controls the data, and if that control is breached, the damage can spread before anyone notices. This isn’t a weakness specific to Canton — it’s inherent to any architecture where integrity depends on who runs it rather than what the math says. ZK architectures approach this differently by stacking multiple independent defenses on top of each other. First, institutional nodes run within each organization’s own regulated environment, so no single operator has unilateral control. On top of that, zero-knowledge proofs act as a separate integrity layer — every batch of transactions must produce a valid proof before it’s accepted, meaning even a compromised operator can’t push through an invalid state transition without the math rejecting it. And as ZK proof systems mature, multiple independent provers can verify the same computation using different implementations, so a bug in one prover gets caught by another. The idea is that for a failure to go undetected, multiple independent systems would have to fail simultaneously — which is significantly harder to exploit than compromising a single trusted operator. Infrastructure Infrastructure is where the day-to-day reality diverges most. Private blockchains are simpler to operate — no external chain dependency, no proving infrastructure, no gas fees. But you own everything: nodes, key management, upgrades, and the permissioning layer. And if you’re on Canton, your contracts are written in Daml, a domain-specific language with a much smaller talent and security community than Ethereum’s. ZK-based deployments like Prividium add complexity: you need proving infrastructure to generate ZK proofs for each batch, plus the connection to Ethereum for settlement — meaning gas costs, proof submission timing, and finality monitoring. But you get EVM compatibility out of the box: Solidity, Hardhat, existing auditing tools, and a massive developer ecosystem. Chainstack supports ZKsync Era with dedicated nodes and archive access. No separate language to learn, and switching providers doesn’t require rewriting contracts. That EVM point goes deeper than convenience. Ethereum’s smart contract infrastructure has been stress-tested by sophisticated adversarial actors for over a decade, with hundreds of billions at stake. Every exploit fed back into the ecosystem as better audit standards, formal verification tools, and compiler safeguards. Daml, by contrast, is open source but has a far smaller ecosystem. As Gluchowski put it: every maturity concern Canton raises about ZK proofs applies to their own stack — except Daml will face those growing pains with orders of magnitude fewer eyes watching. This generalizes beyond Canton — any private blockchain using a domain-specific language faces the same disadvantage against the EVM ecosystem’s depth. Source: https://x.com/gluk64/status/2037613072521842734 When to choose private blockchain vs ZK rollup Private blockchains make more sense when the environment is tightly regulated and data can’t leave a controlled perimeter. Regulators want to know exactly where data lives, who can access it, and who is accountable when something goes wrong — all three answered by design in a private blockchain. Choose private blockchain if: Participants already share infrastructure trust (e.g. a SWIFT network equivalent) Data must stay within a specific jurisdiction or controlled perimeter All participants are pre-approved and sufficiently trusted Your regulatory framework doesn’t accept public chain anchoring Operational simplicity matters more than cryptographic verification ZK rollups are the stronger pick when trust between participants is limited or when you need the outside world to verify what happened without seeing the details. The math handles integrity — no single operator can manipulate state without the proof system catching it. Choose ZK rollup if: Participants don’t fully trust each other or share a single operator External parties need to verify claims without seeing underlying data Cross-organization settlement or interoperability is required Cost efficiency matters at scale — more volume means cheaper per transaction You want EVM tooling, Solidity, and the existing audit ecosystem Some parameters don’t have a clear winner. Performance depends heavily on configuration — private blockchains offer predictable throughput because you control the hardware, while ZK rollups are improving fast but still subject to proving times and L1 settlement delays. Maturity is similarly hard to call: private blockchains have years of production deployments, but ZK rollups inherit a decade of battle-tested EVM tooling, auditing standards, and smart contract infrastructure — so while the rollup layer itself is newer, the stack underneath it isn’t. And upgradability cuts both ways — private blockchains require coordinating upgrades across all participants, while ZK rollups can push updates faster but concentrate upgrade authority in smaller governance bodies. Here’s a summary of how the two approaches stack up across the dimensions covered in this article: DimensionPrivate BlockchainsZK RollupsPrivacy modelAccess control — only approved participants see dataCryptographic — ZK proofs hide data while proving validityTrust assumptionTrusted operators; no independent check if compromisedMath-based; invalid state transitions rejected by proofsAuditabilityFull visibility within the network, but auditors need explicit accessSelective disclosure; claims are publicly verifiable without exposing underlying dataInfrastructureSelf-contained, simpler to operate; proprietary languages limit talent poolMore moving parts (proving infra, L1 settlement); EVM ecosystem provides tooling and portabilityRegulatory fitStronger today — clear data residency, accountability, and permissioningAnchors to a public chain, which some regulatory frameworks don’t yet acceptInteroperabilityPoor across platforms; bespoke bridges, no shared standardNative L1 composability; cross-chain settlement without custom middlewareCost at scaleEach new participant adds infrastructure overheadBatch amortization — more volume means cheaper per transactionPerformancePredictable throughput and latency; you control the hardwareImproving fast, but still subject to proving times and L1 finalityMaturityYears of production deploymentsRollup layer is newer, but inherits EVM infrastructureUpgradabilityCoordinated across participants; slower but predictableFaster via proxy contracts, but governance authority is more centralized Conclusion The Canton vs ZKsync debate isn’t really about which technology is better — it’s about which threat model you’re designing for. If your biggest risk is regulatory exposure, private blockchains solve that by design. If your biggest risk is operator failure, ZK architectures replace human trust with mathematical verification. Neither is winning yet — Deutsche Bank is live on Prividium while major institutions run on Canton, and the market is still deciding. What’s clear is that the tradeoffs are real on both sides. Private blockchains offer simplicity and regulatory clarity but concentrate trust in operators with no independent check. ZK rollups offer cryptographic guarantees but add stack complexity and inherit proof system risks that the ecosystem is still maturing through. The right choice depends on your regulatory environment, your participants’ trust relationships, and how much complexity your team can absorb. What stays constant is the infrastructure underneath. Whether you’re running nodes for a private consortium or building on a ZK rollup that settles to Ethereum, the reliability of your RPC layer, archive access, and debug tooling shapes what you can actually build and operate. Chainstack provides dedicated nodes, archive data, and enterprise deployments — so your infrastructure keeps up with whichever architecture you choose. Start building on Chainstack → FAQ If a ZK rollup operator gets hacked or turns malicious, what actually stops them from stealing my assets? Two different threats need to be separated. Stealing your assets outright — they can’t. The ZK proof will reject any transaction that moves funds invalidly. The math blocks this even if the operator is fully compromised. Freezing your assets — they can do this by simply refusing to process your transactions or hiding the data needed to prove what you own. Your money isn’t stolen, but it’s inaccessible. This is the real residual risk in ZK systems, and it’s why well-designed ones include an “emergency exit” — a way for users to withdraw directly to Ethereum without the operator’s cooperation. So the honest summary: ZK removes the risk of the operator lying, but not the risk of the operator going silent. Private blockchains have both risks. ZK rollups have only the second. Are ZK rollups safe enough for institutional use? The proof system itself is sound, but the full stack introduces risk. A bug in the compiler, prover, or surrounding infrastructure can cause silent failures even when the math is correct. Institutions evaluating ZK rollups should audit the entire stack, not just the proof layer. Can private blockchains interoperate with public chains? Not natively. Cross-network communication between private blockchains requires bespoke bridges with no shared standard. ZK rollups settle on Ethereum, which gives them native L1 composability — two institutions on separate ZK chains can settle against each other through the base layer without custom middleware. Is Daml a dealbreaker for Canton deployments? Not a dealbreaker, but a real constraint. Daml has a much smaller developer and security community than Solidity. Teams building on Canton face a smaller talent pool, fewer auditing tools, and less battle-tested infrastructure compared to the EVM ecosystem. When does a private blockchain make more sense than a ZK rollup? When regulation demands clear data residency and operator accountability. Healthcare systems under HIPAA, banks in strict jurisdictions, or government registries where every participant must be pre-approved — these environments need a controlled perimeter that private blockchains provide by design. Isn’t a private blockchain just a regular database with extra steps? Partially fair. The meaningful additions are: cryptographic audit trails, multi-party agreement on state without a single database owner, and programmable settlement logic. But the trust model is closer to a database than to a public blockchain — which is either a feature or a bug depending on your threat model. Why does regulatory compliance currently favor private blockchains if ZK proofs are mathematically stronger? Because regulators don’t evaluate math — they evaluate accountability. They want a named operator, a jurisdiction, an audit trail they can subpoena. ZK rollups anchoring to Ethereum satisfy none of those requirements structurally, even if they’re cryptographically superior. Related Reading zkEVM and ZK Rollups explained Demystifying Zero-Knowledge Proofs Getting started with ZKsync on Chainstack ZKsync Era tooling #### Protected endpoints for Ethereum and Quorum nodes on Chainstack With the release of Chainstack 1.3, we are happy to be introducing protected endpoints for all Ethereum and Quorum nodes using basic access authentication. This is in line with our commitment to providing secure and stable development environments for our users and marks the completion of our goal to have all endpoints protected by default for all nodes across all protocols that we support. With this change, we will be deprecating all unprotected endpoints by October 1, 2019 (see timeline below). Read on to find out what you need to know to avoid breakages in your applications running on Chainstack nodes. What does this mean for you? Existing nodes If you are currently accessing a Quorum or Ethereum node on Chainstack using unprotected RPC or WSS endpoints, you will need to transition to using the new endpoints that require username and password before we stop supporting them on October 1, 2019. You can find the protected endpoints at the top of your node’s access and credentials section, with the username and password required to access them listed right below. The old, unprotected credentials will still be listed at the bottom of the section, identified with an ‘unlocked’ icon. New nodes When deploying new Quorum or Ethereum nodes, we encourage you to only use the protected endpoints, shown at the top of your node’s access and credentials section. Connecting to protected endpoints In order to connect to and interact with the new endpoints, you will need to include the username and password in your connection request. For instance, connect to a protected Geth node over RPC with the URL in the following format: geth attach https://USERNAME:PASSWORD@RPC_ENDPOINT where: USERNAME — your Ethereum node access username.PASSWORD — your Ethereum node access password.RPC_ENDPOINT — your Ethereum node RPC endpoint. Example Connect to your node: geth attach https://user-name:pass-word-pass-word-pass-word@nd-123-456-789.p2pify.com Invoke any method from the Web3 Javascript API: > web3.eth.blockNumber8437907 Visit the Chainstack Docs for more information about interacting with your nodes. Timeline September 3, 2019: Chainstack 1.3 released with the introduction of new, protected endpoints. Unprotected endpoints remain accessible and visible in the Chainstack platform.October 1, 2019: Unprotected endpoints to be deprecated, removed from the platform and no longer accessible. Feel free to contact us at support@chainstack.com if you have any questions. Explore Chainstack Website: chainstack.comConsole: console.chainstack.com Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Prototyping in Figma: Tips and tricks In this article I will share a few tips and tricks that I use to make prototyping in Figma even more helpful and easier to use. Before we start, I want to say that prototyping in Figma for me is pure joy, but we can always improve things, right? Let’s keep it short and sweet and dive into details straight away. Custom transitions and micro-interactions Yep, I know that there are a lot of useful built-in transition effects in Figma already, but here I want to talk about custom micro-interactions, complicated transitions and show you how to add them into your Figma prototypes. Let’s take a look at a couple of examples I’ve prepared. To make this kind of interaction, you need Figma and any animation tool of your choice. I used After Effects just because I’m familiar with it. When you have your animated transition, add it to your project between the screens that you want to animate and link them. For the animated layers, use the after delay property— the delay should be equal to the length of the animated transition you have. In the end, it should look like this. If you’re not familiar with any animation tools or simply don’t have any animation software installed on your machine, you can do a lot of stuff with Figmotion. Figmotion is a Figma plugin that helps you animate your designs in Figma without using any third-party software. Here’s an example of how it works: Improve navigation between flows in prototyping mode When I work on a user story, even if it’s the most simple user story in the world, I have at least a few edge cases or validation points that I need to show to the team so we can discuss them. It’s quite frustrating in Figma at the moment. I’ve tried different approaches: I tried to keep my flows in one file and change the starting frame by moving the little blue play button between frames. But it’s inconvenient to find and move this little square when you are showing something to the team plus the loading time. It’s so slow when you reload your prototype (especially if you work with a big file).Then I tried splitting my design files into a few smaller ones and keep open a prototyping tab for each of them. That’s a pain. If the user story you’re working on is big and complicated (it implies a lot of edge cases and different scenarios), Figma can’t keep all prototyping tabs open and reloads them when you present them to the team. On top of that, it’s very hard to navigate between a lot of opened tabs (1 tab per flow * 2 because of the opened prototype window). Here is the best solution that I’ve found. I’ve designed a navigation screen that I put as a first screen in all my prototypes: Grouping flows within one file As I mentioned above, I always have at least a few flows related to a user story. That’s why I need a way to organize them within one file. To do it, I designed a simple element that helps a lot. Hand-off Sometimes I have details related to the implementation of my design files that I need to pass on to the engineers, and they usually work better next to the mockups. That’s why I made a post-it note component, and I use it to specify details related to the implementation of my design. I have all three components that I mentioned above in my UI components library in Figma. It allows me to access them quickly from any file I’m working on. Here is a link to a Figma file with the examples that I’ve mentioned: Figma link. Join our community of innovators To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram groupSign up for a free Developer account, or explore the options offered by Growth or Business plans here.Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.Subscribe to our email updates, and be the first one to know about new releases, partnerships and events. . #### Public Polygon RPC: complete endpoint catalogue If you’re working with Polygon, whether it’s MetaMask, a frontend app, or backend services, this is a full list of public Polygon RPC URLs worth knowing. We’ll also walk through the common issues with public endpoints like rate limits, 429 errors, and inconsistent uptime, to help you decide when public infrastructure is enough and when it’s worth running your own private Polygon RPC through a reliable provider. Polygon is one of the go-to chains for deploying EVM-compatible dApps. Fast finality, low fees, and a massive user base make it a go-to chain for everything from games, onchain tools, to scalable backend logic. Most developers start with a public Polygon RPC. It’s quick to set up, good for prototyping, and widely supported across wallets, SDKs, and tooling. But public infrastructure isn’t built for scale or stability. In this guide, you’ll find a complete list of public Polygon RPC URLs, plus a practical checklist to help you decide when public is fine and when you should be running a private endpoint instead. What is a Polygon RPC URL? A Polygon RPC URL is how your app communicates with the Polygon network. It lets you query blockchain data, broadcast transactions, and interact with smart contracts using standard JSON-RPC methods like eth_call, eth_getLogs, and eth_sendRawTransaction. You’ll see it called a Polygon mainnet RPC, dedicated Polygon RPC endpoint, or simply Polygon RPC. All refer to the same thing: an access point that forwards your requests to a node running on the network. Some endpoints are hosted publicly and shared across thousands of users. Others are private, rate-unrestricted, and dedicated to a specific app or organization. Both serve the same protocol, but with very different levels of reliability, speed, and observability. Public vs Private Polygon RPC Endpoints Public Polygon RPC endpoints are free, rate-limited access points maintained by foundations or infrastructure providers. They’re there to make the network accessible, not to support production workloads. If you’re just testing a contract, running a script, or setting up MetaMask, a public endpoint is usually fine. But under any sustained traffic, especially from frontends or bots, you’ll start to hit walls. Most public RPCs enforce global rate limits. That means if someone else is hammering the same endpoint, your requests might start returning 429 errors. You get throttled without warning, and there’s rarely observability or support. Private Polygon RPC endpoints address this by providing isolated capacity, predictable performance, and access to metrics. You decide how the node is deployed, where it runs, and how it handles failure. To sum it up: Public RPCs work for quick access, low-volume usage, and short-term testing. Private RPCs are built for uptime, performance, and scaling under load. If you’re shipping anything that people rely on, public endpoints won’t hold up. For everything else, they’re a decent starting point. Where to get Public Polygon RPC URLs in 2025 If you’re building with Polygon, there are a few public RPC endpoints available. These are good for testing, local development, or light usage where rate limits and shared capacity aren’t a blocker. Here’s how to find them: Polygon PoS Mainnet RPC URL Polygon PoS is the primary production network used for most Polygon-based dApps and onchain activity. Public RPC URL: https://polygon-rpc.com It works well for light usage, like wallet connections, basic reads, and testing scripts. But it’s a shared, rate-limited endpoint. Under load, you can expect delays or 429 errors. Avoid using it for production traffic or anything with sustained volume. Polygon Amoy testnet (PoS) Amoy is the current testnet for Polygon PoS. It mirrors mainnet behavior and works for deploying contracts, testing dApps, or connecting wallets. Public RPC URL: https://rpc-amoy.polygon.technology Like mainnet, it’s a shared endpoint and subject to global rate limits. Third-party infrastructure aggregators You can also use Chainlist to discover and connect to public Polygon RPC endpoints. Search for Polygon Mainnet or Amoy Testnet and you’ll see a list of available RPC URLs. Remember, these aren’t maintained by Polygon directly, so availability and performance vary. Good enough for dev use, but double-check before relying on them in production. How to get a private Polygon RPC endpoint If you’re running anything stateful, time-sensitive, or user-facing on Polygon, public RPCs will eventually bottleneck your setup. You have no control over traffic, rate limits, or what kind of response times you’ll get. That’s why a switch to private Polygon RPC makes sense. You get stable throughput, access to debug methods, and full observability to operate reliably at scale through a trusted Polygon RPC provider. To deploy your own on Chainstack: Log into the Chainstack console Create a project (or reuse an existing one) Click Create network, select Polygon PoS, then choose Mainnet or Amoy Once deployed, grab your RPC URL (HTTP or WebSocket) and plug it into your stack Create your Polygon RPC endpoint How to Add a Polygon RPC to MetaMask MetaMask doesn’t come preloaded with the Polygon PoS or Amoy testnet networks. Whether you’re using a private RPC URL (e.g. from Chainstack) or a public one, you’ll need to add the network manually. Option 1: Add your private Polygon RPC To use a private Polygon PoS mainnet RPC: Open MetaMask Click the network dropdown → Add network manually Fill in the fields: FieldValueNetwork namePolygon PoSRPC URLyour Chainstack mainnet URLChain ID137Currency symbolPOLBlock explorerhttps://polygonscan.com To use a private Amoy testnet RPC: FieldValueNetwork namePolygon Amoy TestnetRPC URLyour Chainstack mainnet URLChain ID80002Currency symbolPOLBlock explorerhttps://www.oklink.com/amoy (optional) Option 2: Use a public Polygon RPC URL If you don’t have a private endpoint, you can use a public RPC URL instead. These are shared across all users and may be rate-limited or less reliable. Polygon PoS Mainnet (public) RPC URL: https://polygon-rpc.com Polygon Amoy Testnet (public) RPC URL: https://rpc-amoy.polygon.technology Use the same MetaMask steps as above, just paste in the public URL instead of your private one. Best practices for stable Polygon RPC performance If you’re building on Polygon, a few RPC best practices go a long way toward preventing request failures, lag, and untracked bugs: Use HTTP for reads, WebSocket for subscriptions WebSocket endpoints are great for real-time data (e.g. eth_subscribe, pending txs, logs). For everything else, use HTTP—it’s stateless, faster for simple queries, and easier to retry on failure. Rate-limit yourself, even on private RPCs Flooding your own endpoint with concurrent calls is still a bottleneck. Queue requests when possible. Debounce UI-triggered RPC calls. Use batch requests (eth_call, eth_getLogs) to reduce total round trips. Add fallbacks If your primary RPC fails or slows down, route to a secondary (public or backup private) endpoint. Just make sure the failover isn’t silent—log it, alert on it, and measure performance across both. Cache aggressively Don’t hit the chain for static data. Cache token metadata, block numbers, or contract ABI calls locally. You’ll reduce RPC load and speed up your app. Monitor your endpoint If your provider gives metrics (Chainstack does), use them. Track latency, method usage, error rates, and connection timeouts. If you’re self-hosting, at least log and alert on 5xx and 4xx spikes. Wrap Up Public Polygon RPCs are great for getting started. They’re fast to plug in and easy to find, but they’re not built for scale. If you’re building anything that runs in production, you’ll want more control, fewer surprises, and performance you can count on. Whether you’re shipping a dApp, running scripts, or scaling backend services, having your own private Polygon RPC gives you the stability and observability public infrastructure can’t. Create your Polygon RPC endpoint Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Optimism, Avalanche, TON, Ronin, zkSync Era, Starknet, Scroll, Aptos, Fantom, Cronos, Gnosis Chain, Klaytn, Moonbeam, Celo, Aurora, Oasis Sapphire, Polygon zkEVM, Bitcoin and Harmony mainnet or testnets through an interface designed to help you get the job done. To learn more about Chainstack, visit our  Developer Portal or join our Discord server and Telegram group. Are you in need of testnet tokens? Request some from our faucets. Multi-chain faucet, Sepolia faucet, Holesky faucet, BNB faucet, zkSync faucet, Scroll faucet. FAQ What is a Polygon RPC URL? A Polygon RPC URL is the address your app or wallet uses to send JSON-RPC requests to the Polygon network. It’s how you read blockchain data, broadcast transactions, and interact with smart contracts. Example: https://polygon-rpc.com. What is the RPC URL in MetaMask? In MetaMask, the RPC URL is the field where you enter the endpoint for a custom network like Polygon. It tells MetaMask which node to use when interacting with that chain. For Polygon PoS, you can use either a public URL (like https://polygon-rpc.com) or your own private RPC from a provider like Chainstack. How do I get a Polygon address on MetaMask? First, add the Polygon network to MetaMask using its RPC settings. Once added, your existing Ethereum address works automatically on Polygon. You don’t need to create a new wallet, Polygon uses the same address format as Ethereum. #### Public vs dedicated Solana RPC: when to use each On April 30, 2022, Solana’s Candy Machine mint collapsed the entire network. Bots racing to mint NFTs fired off millions of transactions in minutes, validators buckled under the load, and the chain went down for roughly seven hours. It became one of the most cited failure stories in Solana’s history, a cautionary tale about what happens when demand outpaces infrastructure. But that story is dated now. Since then, Solana rolled out QUIC for connection handling, stake weighted quality of service (SWQoS), and priority fees, all designed specifically so a demand spike doesn’t take the whole network down again. The chain itself has gotten much harder to break. What hasn’t gone away is the risk underneath it. During a hot mint or a trading surge, block leaders now prioritize connections from staked validators and reliable RPC providers. That’s good for network stability, but it means if your RPC provider isn’t staked or dedicated, your transactions are far more likely to stall or get dropped, even while the network itself hums along fine. What public RPC actually is How it works Public RPC endpoints, like api.mainnet-beta.solana.com, are free and run by the Solana Foundation or community node operators. Traffic from thousands of unrelated apps hits the same pool of nodes, and none of them get dedicated compute, bandwidth, or memory. You’re sharing hardware with everyone else hitting that endpoint at the same time. What it’s designed for These endpoints exist for prototyping, testing, and learning the JSON-RPC methods, not for sustained production load. Rate limits reflect that, often 40 to 100 requests per 10 seconds per IP, with no guarantee of historical data access. Solana’s own docs are blunt about this: public endpoints aren’t intended for production apps. When public RPC is enough That said, public RPC isn’t something to avoid outright. Hackathons, weekend projects, and early prototypes rarely need more — uptime and speed don’t matter yet at that stage. The same goes for personal scripts, small bots, or one-off data pulls with no real users depending on them. If you’re still learning the JSON-RPC methods themselves, before your app has any production traffic to worry about, public RPC does exactly what it’s built for. The hidden costs of staying public Reliability issues On public RPCs, sendTransaction calls frequently time out or get silently dropped during high congestion — like NFT drops or airdrops — because everyone is hitting the same shared pool. Confirming whether a transaction actually landed requires polling getSignatureStatuses. However, under heavy load, public nodes aggressively rate-limit these polling requests. If a transaction’s blockhash expires (around 60–90 seconds) before you can get a successful response, you have to pass searchTransactionHistory: true to check if it ever landed. This forces a heavy ledger search that public nodes will often throttle, reject, or fail to support entirely. You’re left completely blind, unsure if the transaction failed, is still pending, or succeeded but is invisible due to rate limits. And since these are free community endpoints, there’s no SLA. An outage costs you users, not the provider. User experience impact Inconsistent latency also breaks the actual product experience. A trading dashboard or a game that depends on real-time state updates can’t tolerate response times swinging from 50ms to several seconds depending on who else is hitting the node. Slow confirmations are especially damaging in apps handling money or in-game assets, where users expect near-instant feedback that a transaction went through. Most teams respond by writing retry logic and exponential backoff to survive the rate limits, which works until it doesn’t — and it means engineers spend time building resilience around someone else’s infrastructure instead of shipping product. One technical detail worth calling out here: premium infrastructure providers change the game entirely. Any developer can pass skipPreflight: true to bypass time-consuming local simulation checks, but doing so on a public node usually just means dropped packets during high traffic. Signals your app has outgrown public RPC SignalWhat it looks likeWhat it meansFrequent errors429 responses or connection timeouts during normal, non-spike trafficYour baseline usage already exceeds public rate limitsScaling trafficUser base pushing beyond a few hundred requests per secondShared nodes can’t isolate your load from everyone else’sStakeholder pressureInvestors or partners asking about uptime guarantees and infrastructure resilienceReliability has become a business requirement, not a nice-to-haveLatency-sensitive featuresRoadmap includes trading, gaming, or payments where milliseconds matterPublic RPC’s inconsistent latency becomes a product blockerCompliance needsAudit or regulatory requirements demanding documented infrastructure ownershipShared, third-party infra can’t satisfy accountability requirements At Chainstack, we pair that speed with Warp transactions, which route payloads directly through bloXroute’s ultra-high-speed relay network, pushing your transaction via optimized, staked connections straight to the active leader validator. That’s the kind of infrastructure lever that simply doesn’t exist on public RPCs, where you get one generic, heavily throttled path for every request regardless of urgency. What dedicated RPC solves Performance With dedicated infrastructure, your app stops competing with thousands of unrelated apps for the same compute and bandwidth. Rate limits get matched to your actual traffic patterns instead of a one-size-fits-all cap designed to protect a free public node from abuse. The practical result is lower, more predictable latency — especially on time-sensitive calls like sendTransaction during a mint or getAccountInfo in a live trading flow, where a few hundred milliseconds of jitter is the difference between a good and bad user experience. Capability Dedicated access also opens up methods and data that public RPC can’t really support. Archival nodes let you query historical data without hitting the lookback limits public endpoints impose. Depending on the provider, you also get access to extended APIs, webhooks for event-driven architectures, and Geyser plugins for streaming data directly out of the validator — all things we support on Chainstack. Geographic node placement matters too: running nodes physically closer to your users cuts latency in a way a single, centrally located public endpoint can’t, which is part of why we run infrastructure across multiple global regions. Technical tradeoffs to weigh Cost versus control Dedicated infrastructure has a real monthly cost, but so does downtime or a dropped transaction during a major launch. Self-hosting your own Solana RPC nodes gives you full control over the stack, but it also means owning hardware provisioning, heavy NVMe snapshot management, urgent version upgrades, and 24/7 monitoring. That demands actual DevOps headcount, not just a budget line. As a managed provider, Chainstack removes that operational burden while still providing dedicated compute and bandwidth, giving you isolation without the infrastructure overhead. Elasticity and hybrid setups Dedicated doesn’t have to mean a single, fixed box sized for peak load year-round. With Chainstack, you can scale your node footprint as traffic grows without a full re-architecture. Hybrid setups take this efficiency even further. You can route low-priority, high-volume reads — like continuous getAccountInfo polling — through a cost-effective shared tier. Meanwhile, you send critical, time-sensitive write calls — like sendTransaction during a mint — through dedicated nodes with guaranteed throughput and Warp routing. The result is a budget that scales with what actually needs guaranteed performance, preventing you from over-provisioning dedicated resources for every basic read your app makes. Bypassing JSON-RPC for heavy reads There’s another tier above hybrid setups worth knowing about: skipping JSON-RPC entirely. Geyser plugins let dedicated architecture stream data directly out of the validator into Postgres or Kafka, no request-response cycle at all. This matters most for apps doing heavy indexing, historical queries, or high-frequency account monitoring. Polling JSON-RPC repeatedly for the same data is slow and wasteful at that scale — you’re paying the latency cost of a request every single time, even when nothing’s changed. Streaming flips that: the data pushes to you the moment it changes onchain. It’s also only viable with dedicated or validator-level access. Public and most shared RPC tiers have no path to this kind of pipeline — there’s no validator to plug a plugin into in the first place. Architecture decisions Once you’re running dedicated infrastructure, a few more decisions come into play. Single provider versus multi-provider setup affects your redundancy: one provider is simpler to manage, multiple providers protect you if one has an incident. Load balancing across regions matters if your user base is global (as we discussed earlier), not just where your primary node happens to sit. And failover strategy needs to be decided ahead of time — what happens automatically the moment one node starts degrading, not worked out live during an outage. Choosing between public and dedicated WorkloadPublic RPCDedicated RPCHackathon or weekend prototypeSufficientOverkillPersonal script or one-off data pullSufficientOverkillNFT mint or token launchHigh risk of dropped transactionsBuilt for burst traffic and priority landingReal-time trading or DeFi appLatency too inconsistentPredictable, low latency required for executionOn-chain game with live state updatesRate limits break real-time syncCustom limits match actual usageHistorical data or analytics queriesNo archival guaranteesArchival node access built inHigh-frequency account monitoringPolling hits rate limits fastGeyser streaming bypasses polling entirelyProduction app with real usersNot intended for production, per Solana’s own docsDesigned for production reliability and SLAs Making the transition smoothly Migration steps Run public and dedicated RPC side by side first. That’s the only real way to compare latency, error rates, confirmation times, and other metrics before you commit to anything. While you’re doing that, keep an eye on your actual request volume and which methods dominate your traffic, so you’re sizing a dedicated plan around real usage instead of a guess. Then roll it out in pieces, updating SDK configs or endpoint URLs service by service rather than one hard cutover across the whole app. Testing It is always recommended to load-test against your expected peak, not your average day. Average traffic won’t tell you what happens during a mint or a market spike, which is exactly when you can’t afford surprises. Simulate failover too — kill a node in staging and see what actually happens instead of finding out during a real outage. Finally, before calling the migration done, double-check that your critical calls hold up under pressure. Pay extra attention to heavy queries like getProgramAccounts, which most public nodes heavily throttle into unusability since it scans an entire program’s account state. On dedicated infrastructure, verify that secondary indexing is properly configured so calls like this actually return instead of timing out. Conclusion Dedicated RPC isn’t really a cost line item. It’s more of a marker — it usually means your app has moved past the prototype stage and now has real users depending on it working. Go back to that Candy Machine mint from 2022. The network itself wouldn’t buckle that way today, QUIC and SWQoS took care of that. But your app still could — not because Solana broke, but because your RPC provider got deprioritized while better-connected traffic got through. That gap is only going to matter more over time. As Solana’s throughput ceiling keeps climbing, the constraint stops being how fast the chain can go and starts being how fast whoever is serving you data can keep up. RPC isn’t just plumbing anymore — it’s becoming the actual bottleneck on how fast your app can move. The infrastructure decisions you make now aren’t just about handling today’s traffic. They set the ceiling on how far this app can scale before you’re back here again, rebuilding under pressure instead of by choice. Deploy a Solana node on Chainstack → FAQ Is public Solana RPC completely unusable for production apps? Not literally unusable, but not recommended. It’s possible to run a low-traffic production app on public RPC for a while, but you’re accepting rate limits, no SLA, and no guarantee of consistent uptime as your real risk profile. How do I know if my app has actually outgrown public RPC? Watch for 429 errors or timeouts during normal (non-spike) traffic, sustained usage beyond a few hundred requests per second, stakeholder questions about uptime, or a roadmap that includes latency-sensitive features like trading or live gaming. Any one of these is a signal it’s time to move. How much does dedicated Solana RPC actually cost compared to free public RPC? Public RPC is free, but that’s not really the comparison that matters. The real cost of staying on public RPC shows up as dropped transactions, lost users during a launch, and engineering time spent building retry logic around someone else’s infrastructure. Dedicated plans have a real monthly cost, but it should be weighed against what an outage or a botched mint would cost you. Can I mix public and dedicated RPC instead of switching entirely? Yes, this is a common and cost-effective approach. Route high-volume, low-priority reads (like routine getAccountInfo polling) through a cheaper shared tier, and send time-sensitive writes (like sendTransaction during a mint) through dedicated infrastructure with guaranteed throughput. What’s the difference between dedicated RPC and Geyser streaming? Dedicated RPC still uses the request-response JSON-RPC model, just with isolated compute and better rate limits. Geyser plugins skip JSON-RPC entirely, streaming account and transaction data directly out of the validator into a database like Postgres or Kafka. It’s a step beyond dedicated RPC, and only available with dedicated or validator-level access. Additional resources Build better with Solana How to get a Solana RPC endpoint (2026 guide) Best Solana RPC providers in 2026 Solana trading infrastructure 2026: MEV, nodes, latency Solana node types: validator, RPC, and trader nodes Top 7 Solana RPC providers for enterprise and fintech (2026) #### Querying EVM-based smart contracts with GraphQL GraphQL is an extremely powerful tool on Geth. Compared to JSON-RPC, it is much more lightweight and resource-efficient for data querying. That is why more and more developers are using GraphQL nowadays. However, few developers know that they not only can query data with GraphQL, but they can also query smart contracts just like using eth_call. In this tutorial, you will be guided step-by-step through this process and learn how to interact with a smart contract using GraphQL. Prerequisite A Chainstack dedicated Ethereum node. GraphQL is available on dedicated Ethereum nodes on Chainstack, starting from the Growth plan. Follow this guide to set up your own dedicated node. Once the node is ready, the GraphQL endpoint can be found in your console: Querying a smart contract The first thing we need is a smart contract. Open Etherscan, search for 0xc2edad668740f1aa35e4d8f227fb8e17dca888cd. This is the smart contract for SushiSwap. It will be used as an example in this tutorial. Scroll down to the lower part of the webpage, there are several tabs for viewing and interacting with the smart contract. Navigate to Contract > Read Contract. In this tutorial, we focus on the poolInfo method. The poolInfo method returns the liquidity pool state of SushiSwap. For example, if the input is 1, it returns the current state for the USDC-WETH pool. The smart contract method is written in Solidity, it cannot be used in GraphQL directly. We need its raw transaction payload in the format of: { From:”0x*****************”, To:” 0x*****************”, Data:” 0x*****************” } Calling a smart contract is equivalent to sending a transaction on Ethereum, a from address, a to address, and a data"field must be included in the request body. poolInfo is a read function, so its from address is just a null address: 0x0000000000000000000000000000000000000000 Its to address is the signature of this smart contract: 0xc2EdaD668740f1aA35E4D8f227fB8E17dcA888Cd The data field specifies which function to call, and the arguments for the target function. To target poolInfo(uint256), open an online Keccak-256 hash tool, and enter poolInfo(uint256). From the resulting string, copy the first 8 characters, which is 1526fe27. This is the first part of the data field, it represents the method to call. poolInfo takes a 256 bits unsigned integer as its argument, but the request payload is in hexadecimal format. To transform 256 bits uint into hexadecimal, every 4 bits of uint is mapped to one hexadecimal character. For example: uint256(1) = bit(0001) = 0x0000000000000000000000000000000000000000000000000000000000000001 uint256(16) = bit (1000) = 0x0000000000000000000000000000000000000000000000000000000000000010 uint256(10) = bit (0110) = 0x000000000000000000000000000000000000000000000000000000000000000A The final result contains 64 characters with 63 0s and a 1 at the end. Combining the hexadecimal representation of method string and argument string(s), you have: 0x1526fe270000000000000000000000000000000000000000000000000000000000000001 This is the final input for data field. { from:"0x0000000000000000000000000000000000000000", to:"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd", data:"0x1526fe270000000000000000000000000000000000000000000000000000000000000001" } For more information on Solidity data mapping, reference here. In GraphQL Open the GraphQL UI endpoint in the browser, the URL should be in the format of: https://xxxxxxxx/graphql/ui In the left pane enter: { block { call(data:{ from:"0x0000000000000000000000000000000000000000", to:"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd", data:"0x1526fe270000000000000000000000000000000000000000000000000000000000000001" }) {data status gasUsed} } } Click the run button. The result shows immediately in the right pane. GraphQL can be used to query one or several older blocks too. This allows users to see the liquidity pool in the past. For example: { block(from:15017490, to:15017494) { call(data:{ from:"0x0000000000000000000000000000000000000000", to:"0xc2edad668740f1aa35e4d8f227fb8e17dca888cd", data:"0x1526fe270000000000000000000000000000000000000000000000000000000000000001" }) {data status gasUsed} } } Simple as this: If the message shows missing trie node, that is because the block is no longer available. You need an archive node access the chain state that is 128+ blocks in the past. See also EVM nodes: A dive into the full vs. archive mode. In this case, all you need to do is query a new block or switch to an archive node. Conclusion This is the end of this tutorial. Thanks for reading. If you have any questions, feel free to ping me on Twitter/Telegram/Discord. Happy coding. Cheers! Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Querying full and archive Ethereum nodes with JavaScript Querying full vs archive nodes tutorial on Chainstack Introduction Most EVM-based blockchains usually can run two types of nodes: full and archive nodes.  Chainstack supports many popular EVM-based networks, including Ethereum, Polygon, BNB Smart Chain, C-Chain of Avalanche, Fantom, Harmony.  The main difference between the full and archive nodes is that an archive node stores the entire transactional history of the blockchain since its genesis. On the other hand, full nodes store the most recent states, typically up to the latest 128 blocks. Full nodes may serve older historical data but are inefficient for this task. A detailed explanation of how a full node differs from an archive node is on EVM nodes: A dive into the full vs. archive mode.  In this series, we will focus on retrieving historical data from the blockchain programmatically, switching between a full and archive node provider when necessary. The tutorial is split into two parts that will demonstrate the process using two popular web3 languages: JavaScript and Python. Querying full and archive EVM nodes with JavaScript. <— You are here.Querying full and archive EVM nodes with Python.  Initial setup Let us dive deeper into how we can access the data stored in the network. Some essential functions include getting an address balance and storage at a given position, a contract bytecode, or even the whole transactions included on a given block. We can also query states from a given block for any custom smart contract of our choice. Today’s tutorial will query the blockchain utilizing the web3 library in JavaScript. First, set up a new Node.js project: mkdir full-archive-querys-js && cd full-archive-querys-js npm init –y npm install web3 inquirer We added web3.js, which will be a crucial interface to interact with the blockchain. We also added the Inquirer npm package to build a console application. Our goal is that a user can select some desired query to perform between standard state functions or from a custom smart contract. We will call state functions from the SHIBA INU token contract in this example. Initially, we will create three files: the main script, some utility functions, and the SHIBA-INU (or your custom contract) token contract ABI. cd full-archive-querys-js touch index.js mkdir src && cd src touch utils.js abi.js Overall, our project structure should initially look like this: ├── index.js ├── package.json ├── package-lock.json ├── README.md └── src ├── abi.js └── utils.js Introducing common state functions Let us begin setting up the queries for common state functions. We will implement a few popular ones, like fetching an address ETH balance or getting the transactions mined on a given block. A full and archive node is required to follow up on this tutorial. Get a free public node from Chainstack. Open the utils.js file and add the following code: // Initial Config const Web3 = require("web3"); // Init Full and Archive providers const fullNodeProvider = new Web3("<YOUR_NODE_PROVIDER_ENDPOINT>"); const archiveNodeProvider = new Web3("<YOUR_NODE_PROVIDER_ENDPOINT>"); const ZERO_ADDRESS = "0x0000000000000000000000000000000000000000"; // Returns current block of a network const getCurrentBlock = async () => { return await fullNodeProvider.eth.getBlockNumber(); }; // Checks if performed query needs to be called to an archive node const isArchiveQuery = (error) => { return error.message.includes("missing trie node"); }; // Returns eth balance of a given address in a certain block const getETHBalance = async (address, block) => { console.log( `[QUERYING] Fetching ETH balance from address ${address} at block ${block}` ); try { console.log("[QUERYING] Attempting with Full Node"); return await fullNodeProvider.eth.getBalance(address, block); } catch (error) { if (isArchiveQuery(error)) { console.log("[OLD-BLOCK-QUERY] Switching to archive query"); return await archiveNodeProvider.eth.getBalance(address, block); } return null; } }; // Returns the storage of an address at a given position const getStorageAt = async (address, position, block) => { console.log( `[QUERYING] Fetching storage at position ${position} from address ${address} at block ${block}` ); try { console.log("[QUERYING] Attempting with Full Node"); return await fullNodeProvider.eth.getStorageAt(address, position, block); } catch (error) { if (isArchiveQuery(error)) { console.log("[OLD-BLOCK-QUERY] Switching to archive query"); return await archiveNodeProvider.eth.getStorageAt( address, position, block ); } return null; } }; // Returns the code at a given address and block const getCode = async (address, block) => { console.log(address); console.log( `[QUERYING] Fetching code at address ${address} at block ${block}` ); try { console.log("[QUERYING] Attempting with Full Node"); return await fullNodeProvider.eth.getCode(address, block); } catch (error) { if (isArchiveQuery(error)) { console.log("[OLD-BLOCK-QUERY] Switching to archive query"); return await archiveNodeProvider.eth.getCode(address, block); } return null; } }; // Returns all transactions mined in a block const getBlockTransactions = async (block, full) => { console.log(`[QUERYING] Fetching block ${block} transactions`); try { console.log("[QUERYING] Attempting with Full Node"); return await fullNodeProvider.eth.getBlock(block, full); } catch (error) { if (isArchiveQuery(error)) { console.log("[OLD-BLOCK-QUERY] Switching to archive query"); return await archiveNodeProvider.eth.getBlock(block); } return null; } }; // Prints the result of querying the ETH balance // of an address at a given block const printETHBalanceOf = async (address, block) => { const ethBalance = await getETHBalance(address, block); ethBalance === null ? console.log("Invalid query") : console.log( `[BALANCE-RESULTS] Eth balance of address ${address} at block ${block}: ${ethBalance} $ETH` ); }; // Prints the result of querying the storage at an address // at a given position and block const printStorageAt = async (address, block, position) => { const storageAt = await getStorageAt(address, position, block); storageAt === null ? console.log("Invalid query") : console.log( `[STORAGE-RESULTS] Storage at address ${address} at postion ${position} at block ${block}: ${storageAt}` ); }; // Prints the result of querying the code at a given // address and block const printCodeAt = async (address, block) => { const codeAt = await getCode(address, block); codeAt === null ? console.log("Invalid query") : console.log( `[CODE-RESULTS] Code at address ${address} at block ${block}: ${codeAt}` ); }; // Prints the block transactions of a given block // If full is set to false, it will just print the transaction hashes const printBlockTransactions = async (block, full) => { const blockTransactions = await getBlockTransactions(block, full); blockTransactions === null ? console.log("Invalid query") : console.log( `[TRANSACTIONS] Transactions at block ${block}: \n`, blockTransactions ); }; module.exports = { getCurrentBlock, getETHBalance, getStorageAt, getCode, getBlockTransactions, }; With these functions, you can query the network state of any block since the query execution will transition to the archive node provider if the block to fetch cannot be reached from a full node (usually 128 blocks past the latest block). Introducing custom smart contract queries Even though these typical functions are handy sometimes, most cases require interactions with smart contracts to retrieve their states along the network timeline. For this reason, we will use a popular ERC-20 smart contract token as an example. We choose SHIBA INU, which has been living a long time on the Ethereum mainnet, just for illustration purposes. Of course, any contract that exposes state calls will serve for testing. Just remember that the only interactions that we will perform are state calls. We will not change the network state.  First, let us add the contract ABI to the abi.js file on our node project. Paste the following code into it:  const abi = [ { constant: true, inputs: [], name: "name", outputs: [{ name: "", type: "string" }], payable: false, stateMutability: "view", type: "function", }, { constant: false, inputs: [ { name: "spender", type: "address" }, { name: "value", type: "uint256" }, ], name: "approve", outputs: [{ name: "", type: "bool" }], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: true, inputs: [], name: "totalSupply", outputs: [{ name: "", type: "uint256" }], payable: false, stateMutability: "view", type: "function", }, { constant: false, inputs: [ { name: "sender", type: "address" }, { name: "recipient", type: "address" }, { name: "amount", type: "uint256" }, ], name: "transferFrom", outputs: [{ name: "", type: "bool" }], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: true, inputs: [], name: "decimals", outputs: [{ name: "", type: "uint8" }], payable: false, stateMutability: "view", type: "function", }, { constant: false, inputs: [ { name: "spender", type: "address" }, { name: "addedValue", type: "uint256" }, ], name: "increaseAllowance", outputs: [{ name: "", type: "bool" }], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: false, inputs: [{ name: "value", type: "uint256" }], name: "burn", outputs: [], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: true, inputs: [{ name: "account", type: "address" }], name: "balanceOf", outputs: [{ name: "", type: "uint256" }], payable: false, stateMutability: "view", type: "function", }, { constant: true, inputs: [], name: "symbol", outputs: [{ name: "", type: "string" }], payable: false, stateMutability: "view", type: "function", }, { constant: false, inputs: [ { name: "spender", type: "address" }, { name: "subtractedValue", type: "uint256" }, ], name: "decreaseAllowance", outputs: [{ name: "", type: "bool" }], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: false, inputs: [ { name: "recipient", type: "address" }, { name: "amount", type: "uint256" }, ], name: "transfer", outputs: [{ name: "", type: "bool" }], payable: false, stateMutability: "nonpayable", type: "function", }, { constant: true, inputs: [ { name: "owner", type: "address" }, { name: "spender", type: "address" }, ], name: "allowance", outputs: [{ name: "", type: "uint256" }], payable: false, stateMutability: "view", type: "function", }, { inputs: [ { name: "name", type: "string" }, { name: "symbol", type: "string" }, { name: "decimals", type: "uint8" }, { name: "totalSupply", type: "uint256" }, { name: "feeReceiver", type: "address" }, { name: "tokenOwnerAddress", type: "address" }, ], payable: true, stateMutability: "payable", type: "constructor", }, { anonymous: false, inputs: [ { indexed: true, name: "from", type: "address" }, { indexed: true, name: "to", type: "address" }, { indexed: false, name: "value", type: "uint256" }, ], name: "Transfer", type: "event", }, { anonymous: false, inputs: [ { indexed: true, name: "owner", type: "address" }, { indexed: true, name: "spender", type: "address" }, { indexed: false, name: "value", type: "uint256" }, ], name: "Approval", type: "event", }, ]; module.exports = { abi, }; Now, we can create an instance of the SHIBA INU contract using this JavaScript interface that will allow us to interact with its functions. At the end of our utils.js (just before the exports), create a new instance for the contract using each node provider. /* ############### Smart contract interactions ############### */ const { abi } = require("./abi"); // You can use your own contract address const CONTRACT_ADDRESS = "0x95aD61b0a150d79219dCF64E1E6Cc01f0B64C4cE"; // Init instances of our contract both in the full and archive node providers const fullNodeContract = new fullNodeProvider.eth.Contract( abi, CONTRACT_ADDRESS ); const archiveNodeContract = new archiveNodeProvider.eth.Contract( abi, CONTRACT_ADDRESS ); A web3.eth.Contract instance contains the interface for every method, event, and public variable in the smart contract. We are interested (at first) in the _jsonInterface variable, which will contain an array of every function name along with their required inputs. Inside every object, another variable, stateMutability, indicates if this method changes the network state. For read-only methods, the value will be view, which tells us that this method only reads the smart contract state. To extract this useful metadata, we will implement a getContractCallMethods function that will only return the names and inputs of the view functions. At the end of the utils.js file add: /* Returns the contracts methods that only query a smart contract state and its inputs */ const getContractCallMethods = () => { let contractInputs = []; // The _jsoninterface array contains the methods metadata const contractNames = fullNodeContract._jsonInterface .filter((methodMetadata) => methodMetadata.stateMutability === "view") .map((method) => { contractInputs.push(method.inputs); return method.name; }); return { contractNames, contractInputs, }; }; As told before, for this tutorial, we want to interact with our app through CLI, so the inputs required will be prompted to the user using inquirer.   Inside the src folder, create a new folder called prompts. Then let us create three files:   commonState.js: that will prompt the options to select a common state query. custom.js: this will prompt the options to select a custom smart contract function to query its state, and common.js: that will contain common functions to utilize on the previous files. Now, our project folder structure must look like this: ├── index.js ├── package.json ├── package-lock.json ├── README.md ├── resume.js └── src ├── abi.js ├── prompts │   ├── common.js │   ├── commonState.js │   └── custom.js └── utils.js Querying a common state function Let us focus on querying common state functions first. Every common state function requires some inputs, such as the block and address. Other functions, such as getting the storageAt and block transactions, need some custom inputs, too, so let us focus on writing the scaffolding for this. In our commonState.js file, we will add: const inquirer = require("inquirer"); const { printETHBalanceOf, printCodeAt, printStorageAt, getCurrentBlock, printBlockTransactions, ZERO_ADDRESS, } = require("../utils"); // Builds a prompt for block input const blockPrompt = () => ({ type: "input", default: LATEST_BLOCK, name: "block", message: "Enter the block number to perform the query (blank to use latest block)", }); // Builds a prompt for address input const addressPrompt = () => ({ type: "input", default: ZERO_ADDRESS, name: "address", message: "Enter an address to perfom the query (blank to use zero address)", }); /* Prompts the inputs for the block to query and select if go full details or just the hashes */ const getBlockFull = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([ blockPrompt(), { type: "confirm", default: false, name: "full", message: "Do you wish to get the full transactions output?", }, ]); }; /* Prompts the inputs for the block and the address to perform a query */ const getAddressBlock = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([addressPrompt(), blockPrompt()]); }; /* Prompts the inputs for the block, address and the position to perform a query */ const getAddressBlockPosition = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([ addressPrompt(), blockPrompt(), { type: "input", name: "position", message: "Enter the position of the storage to perform the query (default 0)", default: 0, }, ]); }; We also have some functions that will help us manage these queries declaratively, mainly focused on fetching the results and printing them. In our commonState.js file, add: // Performs query for getting ETH balance const processETHBalance = async () => { const { address, block } = await getAddressBlock(); await printETHBalanceOf(address, block); return; }; // Performs query for getting code at given address const processCodeAt = async () => { const { address, block } = await getAddressBlock(); await printCodeAt(address, block); return; }; // Performs query for getting storage at an address // at a given position const processStorageAt = async () => { const { address, block, position } = await getAddressBlockPosition(); await printStorageAt(address, block, position); return; }; // Performs query for getting a block transactions const processTransactions = async () => { const { block, full } = await getBlockFull(); await printBlockTransactions(block, full); return; }; Finally, we will add the logic required to request the user inputs needed to query a specific function. // Prompts the option to select the common state // query function to call const getCommonsSelection = async () => { return await inquirer.prompt([ { type: "list", name: "commonsOption", choices: [ "Get ETH balance of an address at a given block", "Get storage at an address at a given position and block", "Get code of an address at a given block", "Get block transactions from a given block", ], }, ]); }; // Executes the method select on CLI const processCommonsSelection = async (selection) => { if (selection.includes("balance")) { await processETHBalance(); return; } if (selection.includes("code")) { await processCodeAt(); return; } if (selection.includes("storage")) { await processStorageAt(); return; } if (selection.includes("transactions")) { await processTransactions(); return; } }; module.exports = { getCommonsSelection, processCommonsSelection, }; At the end, the commonState.js file shall look like this: const inquirer = require("inquirer"); const { printETHBalanceOf, printCodeAt, printStorageAt, getCurrentBlock, printBlockTransactions, ZERO_ADDRESS, } = require("../utils"); // Builds a prompt for block input const blockPrompt = () => ({ type: "input", default: LATEST_BLOCK, name: "block", message: "Enter the block number to perform the query (blank to use latest block)", }); // Builds a prompt for address input const addressPrompt = () => ({ type: "input", default: ZERO_ADDRESS, name: "address", message: "Enter an address to perfom the query (blank to use zero address)", }); /* Prompts the inputs for the block to query and select if go full details or just the hashes */ const getBlockFull = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([ blockPrompt(), { type: "confirm", default: false, name: "full", message: "Do you wish to get the full transactions output?", }, ]); }; /* Prompts the inputs for the block and the address to perform a query */ const getAddressBlock = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([addressPrompt(), blockPrompt()]); }; /* Prompts the inputs for the block, address and the position to perform a query */ const getAddressBlockPosition = async () => { LATEST_BLOCK = await getCurrentBlock(); return await inquirer.prompt([ addressPrompt(), blockPrompt(), { type: "input", name: "position", message: "Enter the position of the storage to perform the query (default 0)", default: 0, }, ]); }; // Performs query for getting ETH balance const processETHBalance = async () => { const { address, block } = await getAddressBlock(); await printETHBalanceOf(address, block); return; }; // Performs query for getting code at given address const processCodeAt = async () => { const { address, block } = await getAddressBlock(); await printCodeAt(address, block); return; }; // Performs query for getting storage at an address // at a given position const processStorageAt = async () => { const { address, block, position } = await getAddressBlockPosition(); await printStorageAt(address, block, position); return; }; // // Performs query for getting a block transactions const processTransactions = async () => { const { block, full } = await getBlockFull(); await printBlockTransactions(block, full); return; }; // Prompts the option to select the common state // query function to call const getCommonsSelection = async () => { return await inquirer.prompt([ { type: "list", name: "commonsOption", choices: [ "Get ETH balance of an address at a given block", "Get storage at an address at a given position and block", "Get code of an address at a given block", "Get block transactions from a given block", ], }, ]); }; // Executes the method select on CLI const processCommonsSelection = async (selection) => { if (selection.includes("balance")) { await processETHBalance(); return; } if (selection.includes("code")) { await processCodeAt(); return; } if (selection.includes("storage")) { await processStorageAt(); return; } if (selection.includes("transactions")) { await processTransactions(); return; } }; module.exports = { getCommonsSelection, processCommonsSelection, }; Querying a custom smart contract We also want to be able to query a custom smart contract state. Querying smart contracts state is beneficial if we want to get historical data from them. First, we want to get the inputs from a user required for querying a function in our smart contract. We need a way to build a custom prompt asking the user for these inputs. Let us do this, bearing in mind that every contract can be different and have distinct functions requiring different inputs. Let us add the following code to our custom.js file: const inquirer = require("inquirer"); const { getContractCallMethods, ZERO_ADDRESS, callContractFunctionWithoutParams, callContractFunctionWithParams, } = require("../utils"); /* Builds a new inquirer prompt for each required input for the selected smart contract method */ const buildPrompt = (inputs, latest_block) => { let prompts = []; inputs.forEach((input) => { prompts.push({ type: "input", name: input.name, message: `Enter an ${input.type} for the ${input.name} to perform query`, default: getDefaultValue(input.type), }); }); prompts.push({ type: "input", name: "block", message: `Enter the block number to perform query`, default: latest_block, }); return prompts; }; /* Gets the user inputs required to pass as function parameters in the method selected for the custom contract */ const getUserInput = async (inputs, latest_block) => { const prompt = buildPrompt(inputs, latest_block); const answer = await inquirer.prompt(prompt); const inputsAsArray = Object.keys(answer) .map((key) => answer[key]) .slice(0, -1); const { block } = answer; return { userInput: inputsAsArray, block, }; }; /* Returns the default value of an inquirer prompt based on a smart contract function input type */ const getDefaultValue = (type) => { if (type.includes("address")) { return ZERO_ADDRESS; } if (type.includes("uint") || type.includes("int") || type.includes("enum")) { return 0; } if (type.includes("bool")) { return false; } if (type.includes("bytes")) { return "0x0"; } if (type.includes("array")) return []; if (type.inclues("string")) return ""; return null; }; /* Returns the inputs name and type of a given method */ const getInputsOfMethod = (contractInputs, indexOf) => { return contractInputs[indexOf]; }; /* Returns the index of a method in the methods name array */ const getIndexOfMethod = (contractNames, method) => { return contractNames.findIndex((name) => name === method); }; These methods will ask the user input required regarding each function and return the function parameters entered by the user in array format. The previous is helpful as we can use the spread operator later to pass them as parameters to the function. Finally, as in the common state query prompts, we want a gateway to process the selected option and trigger the desired function to query a state in the smart contract. /* Returns the option selected to query on a custom smart contract. Also returns the contract methods names and their required inputs */ const getCustomSelection = async () => { const { contractNames, contractInputs } = getContractCallMethods(); const { customOption } = await inquirer.prompt([ { type: "list", name: "customOption", choices: contractNames, message: "Select a read-only function from your smart contract", }, ]); return { customOption, contractNames, contractInputs }; }; /* Performs the selection process for a method on the smart contract to query */ const processCustomSelection = async ( selection, contractNames, contractInputs, latest_block ) => { const indexOf = getIndexOfMethod(contractNames, selection); const methodInputs = getInputsOfMethod(contractInputs, indexOf); const { userInput, block } = await getUserInput(methodInputs, latest_block); if (methodInputs.length < 1) { callContractFunctionWithoutParams(selection, block); } else { await callContractFunctionWithParams(selection, userInput, block); } return; }; Note: Since some Solidity types like structs and mappings require a complex way of passing them as parameters (like tuples), trying to call functions that use them will trigger an error. In the end, our custom.js file will look like this: const inquirer = require("inquirer"); const { getContractCallMethods, ZERO_ADDRESS, callContractFunctionWithoutParams, callContractFunctionWithParams, } = require("../utils"); /* Builds a new inquirer prompt for each required input for the selected smart contract method */ const buildPrompt = (inputs, latest_block) => { let prompts = []; inputs.forEach((input) => { prompts.push({ type: "input", name: input.name, message: `Enter an ${input.type} for the ${input.name} to perform query`, default: getDefaultValue(input.type), }); }); prompts.push({ type: "input", name: "block", message: `Enter the block number to perform query`, default: latest_block, }); return prompts; }; /* Gets the user inputs required to pass as function parameters in the method selected for the custom contract */ const getUserInput = async (inputs, latest_block) => { const prompt = buildPrompt(inputs, latest_block); const answer = await inquirer.prompt(prompt); const inputsAsArray = Object.keys(answer) .map((key) => answer[key]) .slice(0, -1); const { block } = answer; return { userInput: inputsAsArray, block, }; }; /* Returns the default value of an inquirer prompt based on a smart contract function input type */ const getDefaultValue = (type) => { if (type.includes("address")) { return ZERO_ADDRESS; } if (type.includes("uint") || type.includes("int") || type.includes("enum")) { return 0; } if (type.includes("bool")) { return false; } if (type.includes("bytes")) { return "0x0"; } if (type.includes("array")) return []; if (type.inclues("string")) return ""; return null; }; /* Returns the inputs name and type of a given method */ const getInputsOfMethod = (contractInputs, indexOf) => { return contractInputs[indexOf]; }; /* Returns the index of a method in the methods name array */ const getIndexOfMethod = (contractNames, method) => { return contractNames.findIndex((name) => name === method); }; /* Returns the option selected to query on a custom smart contract. Also returns the contract methods names and their required inputs */ const getCustomSelection = async () => { const { contractNames, contractInputs } = getContractCallMethods(); const { customOption } = await inquirer.prompt([ { type: "list", name: "customOption", choices: contractNames, message: "Select a read-only function from your smart contract", }, ]); return { customOption, contractNames, contractInputs }; }; /* Performs the selection process for a method on the smart contract to query */ const processCustomSelection = async ( selection, contractNames, contractInputs, latest_block ) => { const indexOf = getIndexOfMethod(contractNames, selection); const methodInputs = getInputsOfMethod(contractInputs, indexOf); const { userInput, block } = await getUserInput(methodInputs, latest_block); if (methodInputs.length < 1) { callContractFunctionWithoutParams(selection, block); } else { await callContractFunctionWithParams(selection, userInput, block); } return; }; module.exports = { getCustomSelection, processCustomSelection, }; Final touches Now, we need to implement our final prompt that will manage to choose if query common state or a custom smart contract function. The common.js file contains the code to select if a user will query a common state function or one given on the custom smart contract, so it serves as a middleware to decide what to execute next. const inquirer = require("inquirer"); const { getCurrentBlock } = require("../utils"); const { getCommonsSelection, processCommonsSelection, } = require("./commonState"); const { getCustomSelection, processCustomSelection } = require("./custom"); let LATEST_BLOCK; // Prompts the main selection panel const getSelection = async () => { LATEST_BLOCK = await getCurrentBlock(); const { mainOption } = await inquirer.prompt([ { type: "list", name: "mainOption", message: "Select the type of functions to query", choices: [ "Common state functions (getBalance, getBlock...)", "Custom contract state view functions", ], }, ]); if (mainOption.includes("Common")) { // Process the common state query options const { commonsOption } = await getCommonsSelection(); await processCommonsSelection(commonsOption); } else { // Process the custom contract state query options const { customOption, contractNames, contractInputs } = await getCustomSelection(); await processCustomSelection( customOption, contractNames, contractInputs, LATEST_BLOCK ); } }; module.exports = { getSelection, }; Finally, and most importantly, our index.js file shall execute the getSelection function to prompt all user inputs. const { getSelection } = require("./src/prompts/common"); const main = async () => { await getSelection(); }; main(); To run a demo of this app, on the projects root folder, we just run node index If we choose to run common state functions queries, it will ask at least for the block number (it will use latest as default). Some other functions will require an address (it will use the zero address by default). Demo of querying the ETH balance of an address on a given block On the other hand, we could query any state call function from our custom smart contract. The inputs will vary depending on the function to query (some functions will not even need an input). Demo of querying the balanceOf method on the SHIBA-INU ERC20 token contract. As always, the complete code is available in the tutorial’s repository.  Conclusion In this post, we have discovered how to perform, programmatically and interactively, state queries to a given network and a custom smart contract. This scripting tutorial allows fetching helpful information about the actual and historical states of the blockchain in an error-based approach. For example, this tool could perform different queries to a network state using both full and archive nodes. This transition is helpful in situations where the calls to an RPC provider get limited, and every one of them needs to be executed in the most efficient way possible. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Querying full and archive Ethereum nodes with Python Querying full vs archive nodes tutorial on Chainstack Introduction Most EVM-based blockchains usually can run two types of nodes: full nodes and archive nodes.   Chainstack supports many popular EVM-based networks, including Ethereum, Polygon, BNB Smart Chain, C-Chain of Avalanche.   The main difference between a full node and an archive node is that an archive node stores the entire transactional history of the blockchain since its genesis. On the other hand, full nodes typically store the most recent states, typically up to the latest 128 blocks. Full nodes may serve older historical data but are inefficient for this task.   A profound explanation of how a full node differs from an archive node is on EVM nodes: A dive into the full vs. archive mode.   In this series, we will focus on retrieving historical data from the blockchain programmatically, switching between a full and archive node provider when necessary. The tutorial is two parts that demonstrate the process using two popular web3 languages: JavaScript and Python. Querying full and archive EVM nodes with JavaScript.Querying full and archive EVM nodes with Python <— You are here. Initial setup Let us dive deeper into how we can access the data stored in the network. Some essential functions include getting an address balance and storage at a given position, a contract bytecode, or even the whole transactions included on a given block. We can also query states from a given block for any custom smart contract of our choice.  Today’s tutorial will query the blockchain utilizing the web3 and inquirer libraries for Python.  First, set up a new Python project:  mkdir full-archive-querys-py && cd full-archive-querys-py pip install web3 inquirer We added web3.py, which will be a crucial interface to interact with the blockchain. We also added the Inquirer Python package to build a console application. Our goal is that a user can select some desired query to perform between standard state functions or from a custom smart contract.  We will call state functions from the SHIBA-INU ERC-20 token contract in this example. Initially, we will create three files: the main script, some utility functions, and the SHIBA-INU (or your custom contract) token contract ABI.  touch main.py mkdir src && cd src touch utils.py abi.json Overall, our project structure should initially look like this:  ├── main.py └── src ├── abi.json └── utils.py Introducing common state functions Let us begin setting up the queries for common state functions. We will implement a few popular ones, like fetching an address ETH balance or getting the transactions mined on a given block. A full and archive node is required to follow up on this tutorial. Get a free public node from Chainstack. Open the utils.py file and add the following code:  # Imports import json from web3 import Web3 from pprint import pprint # Init full and archive provider full_node_provider = Web3( Web3.HTTPProvider( "https://nd-479-987-415.p2pify.com/271156373b36700f7576cf46e68b1262" ) ) archive_node_provider = Web3( Web3.HTTPProvider( "https://nd-072-228-848.p2pify.com/3f7a80739e2f6739cae0256a2660725b" ) ) def to_checksum_address(address): return full_node_provider.toChecksumAddress(address) def to_hex(string): return full_node_provider.toHex(string) # Returns the current block number of a network def get_block_number(): return full_node_provider.eth.block_number # Returns the ETH balance of a given address at a given block def get_eth_balance(address, block): print( "[QUERYING] Fetching ETH balance from address {} at block {}".format( address, block ) ) try: print("[QUERYING] Attempting with full Node") return full_node_provider.eth.get_balance(address, block) except Exception as e: if "missing trie node" in str(e): print("[OLD-BLOCK-QUERY] Switching to archive query") return archive_node_provider.eth.get_balance(address, block) else: print("exception: ", e) return None # Returns the storage of an address at a given position and block def get_storage_at(address, position, block): try: print( "[QUERYING] Fetching storage at address {} at position {} at block {}".format( address, position, block ) ) return full_node_provider.eth.get_storage_at(address, position, block) except Exception as e: if "missing trie node" in str(e): print("[OLD-BLOCK-QUERY] Switching to archive query") return archive_node_provider.eth.get_storage_at(address, position, block) else: return None # Returns the code at a given address and block def get_code(address, block): try: print( "[QUERYING] Fetching code at address {} at block {}".format(address, block) ) return full_node_provider.eth.get_code(address, block) except Exception as e: if "missing trie node" in str(e): print("[OLD-BLOCK-QUERY] Switching to archive query") return archive_node_provider.eth.get_code(address, block) else: return None # Returns the mined transactions in a given block def get_block_transactions(block, full_transactions=False): try: print("[QUERYING] Fetching transactions from block {}".format(block)) return full_node_provider.eth.get_block(block, full_transactions) except Exception as e: if "missing trie node" in str(e): print("[OLD-BLOCK-QUERY] Switching to archive query") return archive_node_provider.eth.get_block(block, full_transactions) else: return None def print_eth_balance_of(address, block): eth_balance = get_eth_balance(address, block) print( "[BALANCE-RESULTS] Eth balance of address {} at block {}: {} $ETH".format( address, block, eth_balance ) ) if eth_balance is not None else print("Invalid Query") def print_storage_at(address, position, block): storage_at = full_node_provider.toHex(get_storage_at(address, position, block)) print( "[STORAGE-AT-RESULTS] Storage at {} at position {} at block {}: {}".format( address, position, block, storage_at ) ) if storage_at is not None else print("Invalid query") def print_code_at(address, block): code_at = full_node_provider.toHex(get_code(address, block)) print( "[CODE-AT-RESULTS] Code at address {} at block {}: {}".format( address, block, code_at ) ) if code_at is not None else print("Invalid query") def print_block_transactions(block, full): block_transactions = get_block_transactions(block, full) print( "[TRANSACTIONS] Transactions at block {}: {}".format(block, block_transactions) ) if block_transactions is not None else print("Invalid Query") With these functions, you can query the network state of any block since the query execution will transition to the archive node provider if the block to fetch cannot be reached from a full node (usually 32-128 blocks past the latest block).  Introducing custom smart contract queries Even though these typical functions are handy sometimes, most cases require interactions with smart contracts to retrieve their states along the network timeline. For this reason, we will use a popular ERC-20 smart contract token as an example. We choose SHIBA INU, which has been living a long time on the Ethereum Mainnet, just for illustration purposes. Of course, any contract that exposes state calls will serve for testing. Just remember that the only interactions that we will perform are state calls. We will not change the network state.   First, let us add the contract ABI to the abi.json file on our node project. Paste the following code into it:  [ { "constant": true, "inputs": [], "name": "name", "outputs": [{ "name": "", "type": "string" }], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "spender", "type": "address" }, { "name": "value", "type": "uint256" } ], "name": "approve", "outputs": [{ "name": "", "type": "bool" }], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [], "name": "totalSupply", "outputs": [{ "name": "", "type": "uint256" }], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "sender", "type": "address" }, { "name": "recipient", "type": "address" }, { "name": "amount", "type": "uint256" } ], "name": "transferFrom", "outputs": [{ "name": "", "type": "bool" }], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [], "name": "decimals", "outputs": [{ "name": "", "type": "uint8" }], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "spender", "type": "address" }, { "name": "addedValue", "type": "uint256" } ], "name": "increaseAllowance", "outputs": [{ "name": "", "type": "bool" }], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": false, "inputs": [{ "name": "value", "type": "uint256" }], "name": "burn", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [{ "name": "account", "type": "address" }], "name": "balanceOf", "outputs": [{ "name": "", "type": "uint256" }], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": true, "inputs": [], "name": "symbol", "outputs": [{ "name": "", "type": "string" }], "payable": false, "stateMutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "spender", "type": "address" }, { "name": "subtractedValue", "type": "uint256" } ], "name": "decreaseAllowance", "outputs": [{ "name": "", "type": "bool" }], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": false, "inputs": [ { "name": "recipient", "type": "address" }, { "name": "amount", "type": "uint256" } ], "name": "transfer", "outputs": [{ "name": "", "type": "bool" }], "payable": false, "stateMutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "owner", "type": "address" }, { "name": "spender", "type": "address" } ], "name": "allowance", "outputs": [{ "name": "", "type": "uint256" }], "payable": false, "stateMutability": "view", "type": "function" }, { "inputs": [ { "name": "name", "type": "string" }, { "name": "symbol", "type": "string" }, { "name": "decimals", "type": "uint8" }, { "name": "totalSupply", "type": "uint256" }, { "name": "feeReceiver", "type": "address" }, { "name": "tokenOwnerAddress", "type": "address" } ], "payable": true, "stateMutability": "payable", "type": "constructor" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "from", "type": "address" }, { "indexed": true, "name": "to", "type": "address" }, { "indexed": false, "name": "value", "type": "uint256" } ], "name": "Transfer", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "owner", "type": "address" }, { "indexed": true, "name": "spender", "type": "address" }, { "indexed": false, "name": "value", "type": "uint256" } ], "name": "Approval", "type": "event" } ] Now, we can create an instance of the SHIBA INU contract using this json interface that will allow us to interact with its functions. At the end of our utils.py, create a new instance for the contract using each node provider.  ########## SMART CONTRACT INTERACTIONS ############## CONTRACT_ADDRESS = "0x95aD61b0a150d79219dCF64E1E6Cc01f0B64C4cE" with open("src/abi.json") as f: abi = json.load(f) full_node_contract = full_node_provider.eth.contract(address=CONTRACT_ADDRESS, abi=abi) archive_node_contract = archive_node_provider.eth.contract( address=CONTRACT_ADDRESS, abi=abi ) A web3.eth.Contract instance contains the interface for every method, event, and public variable in the smart contract. We are interested (at first) in the _functions variable, which will contain a list of dictionaries that holds every function metadata, including its name along with their required inputs. Inside every dictionary, another variable, stateMutability, indicates if this method changes the network state. For read-only methods, the value will be view, which tells us that this method only reads the smart contract state.  To extract this useful metadata, we will implement a getContractCallMethods function that will only return the names and inputs (in dict-form) of the view functions. At the end of the utils.py file add:  def get_contract_call_methods(): pprint(full_node_contract.functions._functions) print(type(full_node_contract.functions._functions)) view_functions = {} for function in full_node_contract.functions._functions: # print(function) if function["stateMutability"] == "view": view_functions[function["name"]] = function["inputs"] return view_functions As told before, for this tutorial, we want to interact with our app through CLI, so the inputs required will be prompted to the user using inquirer.    Inside the src folder, create a new folder called prompts. Then let us create three files:    common_state.py: that will prompt the options to select a common state query.  custom_state.py: this will prompt the options to select a custom smart contract function to query its state, and  common.py: that will contain common functions to utilize on the previous files   Now, our project folder structure must look like this:  ├── main.py └── src ├── abi.json ├── prompts │ ├── common.py │ ├── common_state.py │ └── custom_state.py └── utils.py Querying a common state function Let us focus on querying common state functions first. Every common state function requires some inputs, such as the block and address. Other functions, such as getting the storageAt and block transactions, need some custom inputs, too, so let us focus on writing the scaffolding for this. In our common_state.py file, we will add:  import inquirer from src.utils import * from operator import itemgetter LATEST_BLOCK = "" ZERO_ADDRESS = "0x0000000000000000000000000000000000000000" # Builds a prompt for block input def block_prompt(): LATEST_BLOCK = get_block_number() return inquirer.Text( "block", message="Enter the block number to perform the query (blank to use latest block)", default=LATEST_BLOCK, ) # Builds a prompt for address input def address_prompt(): return inquirer.Text( "address", message="Enter an address to perfom the query (blank to use zero address)", default=ZERO_ADDRESS, ) # Prompts the inputs for the block to query transactions # and select if go full details or just the hashes def get_block_full(): questions = [ block_prompt(), inquirer.Confirm( "full", message="Do you wish to get the full transactions output", default=False, ), ] return inquirer.prompt(questions) # Prompts the inputs for the block # and the address to perform a query def get_address_block(): questions = [address_prompt(), block_prompt()] return inquirer.prompt(questions) # Prompts the inputs for the block, address # and the position to perform a query def get_address_block_position(): questions = [ address_prompt(), block_prompt(), inquirer.Text( "position", message="Enter the position of the storage to perform the query (default 0)", default="0", ), ] return inquirer.prompt(questions) We also have some functions that will help us manage these queries declaratively, mainly focused on fetching the results and printing them. Still, in our common_state.py file, add:  # Performs query for getting ETH balance def process_eth_balance(): address, block = itemgetter("address", "block")(get_address_block()) address = to_checksum_address(address) print_eth_balance_of(address, int(block)) return # Performs query for getting code at given address def process_storage_at(): address, block, position = itemgetter("address", "block", "position")( get_address_block_position() ) address = to_checksum_address(address) print_storage_at(address, int(position), int(block)) # Performs query for getting storage at an address # at a given position def process_code_at(): address, block = itemgetter("address", "block")(get_address_block()) address = to_checksum_address(address) print_code_at(address, int(block)) # Performs query for getting a block transactions def process_transactions(): block, full = itemgetter("block", "full")(get_block_full()) print_block_transactions(int(block), full) Finally, we will add the logic required to request the user inputs needed to query a specific function. # Prompts the option to select the common state # query function to call def get_commons_selection(): return inquirer.prompt( [ inquirer.List( "commons", message="Select a common query to perform", choices=[ "Get ETH balance of an address at a given block", "Get storage at an address at a given position and block", "Get code of an address at a given block", "Get block transactions from a given block", ], ) ] )["commons"] # Executes the method select on CLI def process_commons_selection(selection): if "balance" in selection: process_eth_balance() elif "code" in selection: process_code_at() elif "storage" in selection: process_storage_at() elif "transactions" in selection: process_transactions() At the end, the common_state.py file shall look like this:  import inquirer from src.utils import * from operator import itemgetter LATEST_BLOCK = "" ZERO_ADDRESS = "0x0000000000000000000000000000000000000000" # Builds a prompt for block input def block_prompt(): LATEST_BLOCK = get_block_number() return inquirer.Text( "block", message="Enter the block number to perform the query (blank to use latest block)", default=LATEST_BLOCK, ) # Builds a prompt for address input def address_prompt(): return inquirer.Text( "address", message="Enter an address to perfom the query (blank to use zero address)", default=ZERO_ADDRESS, ) # Prompts the inputs for the block to query transactions # and select if go full details or just the hashes def get_block_full(): questions = [ block_prompt(), inquirer.Confirm( "full", message="Do you wish to get the full transactions output", default=False, ), ] return inquirer.prompt(questions) # Prompts the inputs for the block # and the address to perform a query def get_address_block(): questions = [address_prompt(), block_prompt()] return inquirer.prompt(questions) # Prompts the inputs for the block, address # and the position to perform a query def get_address_block_position(): questions = [ address_prompt(), block_prompt(), inquirer.Text( "position", message="Enter the position of the storage to perform the query (default 0)", default="0", ), ] return inquirer.prompt(questions) # Performs query for getting ETH balance def process_eth_balance(): address, block = itemgetter("address", "block")(get_address_block()) address = to_checksum_address(address) print_eth_balance_of(address, int(block)) return # Performs query for getting code at given address def process_storage_at(): address, block, position = itemgetter("address", "block", "position")( get_address_block_position() ) address = to_checksum_address(address) print_storage_at(address, int(position), int(block)) # Performs query for getting storage at an address # at a given position def process_code_at(): address, block = itemgetter("address", "block")(get_address_block()) address = to_checksum_address(address) print_code_at(address, int(block)) # Performs query for getting a block transactions def process_transactions(): block, full = itemgetter("block", "full")(get_block_full()) print_block_transactions(int(block), full) # Prompts the option to select the common state # query function to call def get_commons_selection(): return inquirer.prompt( [ inquirer.List( "commons", message="Select a common query to perform", choices=[ "Get ETH balance of an address at a given block", "Get storage at an address at a given position and block", "Get code of an address at a given block", "Get block transactions from a given block", ], ) ] )["commons"] # Executes the method select on CLI def process_commons_selection(selection): if "balance" in selection: process_eth_balance() elif "code" in selection: process_code_at() elif "storage" in selection: process_storage_at() elif "transactions" in selection: process_transactions() Querying a custom smart contract We also want to be able to query a custom smart contract state. Querying smart contracts state is beneficial if we want to get historical data from them. First, we want to get the inputs from a user required for querying a function in our smart contract. We need a way to build a custom prompt asking the user for these inputs. Let us do this, bearing in mind that every contract can be different and have distinct functions requiring different inputs. Let us add the following code to our custom_state.py file:  # Builds a new inquirer prompt for each required # input for the selected smart contract method def build_prompt(inputs, block): questions = [] for inputt in inputs: questions.append( inquirer.Text( name=inputt["name"], message="Enter an {} for the {} to perform query".format( inputt["type"], inputt["name"] ), default=get_default_value(inputt["type"]), ) ) questions.append( inquirer.Text( name="block", message="Enter the block number to perform the query", default=block, ) ) return questions # Gets the user inputs required to pass as function # parameters in the method selected for the custom contract def get_user_input(inputs, block): questions = build_prompt(inputs, block) answers = inquirer.prompt(questions) block = answers["block"] del answers["block"] return list(answers.values()), block # Returns the default value of an inquirer prompt # based on a smart contract function input type def get_default_value(input_type): if "address" in input_type: return ZERO_ADDRESS elif "uint" in input_type or "int" in input_type or "enum" in input_type: return "0" elif "bool" in input_type: return False elif "bytes" in input_type: return "0x0" elif "array" in input_type: return [] elif "string" in input_type: return "" return None These methods will ask the user input required regarding each function and return the function parameters entered by the user in array format. The previous is helpful as we can use argument unpacking to pass them as parameters to the function.  Finally, as in the common state query prompts, we want a gateway to process the selected option and trigger the desired function to query a state in the smart contract.  # Returns the option selected to query on a custom # smart contract. Also returns the contract methods names # and their required inputs def get_custom_selection(): contract_functions = get_contract_call_methods() return ( inquirer.prompt( [ inquirer.List( name="custom", message="Choose a function from the smart contract", choices=contract_functions.keys(), ) ] )["custom"], contract_functions, ) # Performs the selection process for a method # on the smart contract to query def process_custom_selection(selection, contract_functions): latest_block = get_block_number() # print("Required Inputs: ", contract_functions[selection]) inputs = contract_functions[selection] user_inputs, block = get_user_input(inputs, latest_block) # print("inputs: ", user_inputs) if len(inputs) < 1: call_contract_function_without_params(selection, block) else: call_contract_function_with_params(selection, user_inputs, block) Important note: Since some Solidity types like structs and mappings require a complex way of passing them as parameters (like tuples), trying to call functions that use them will trigger an error.  In the end, our custom_state.py file will look like this:  import inquirer from .common_state import ZERO_ADDRESS from src.utils import * # Builds a new inquirer prompt for each required # input for the selected smart contract method def build_prompt(inputs, block): questions = [] for inputt in inputs: questions.append( inquirer.Text( name=inputt["name"], message="Enter an {} for the {} to perform query".format( inputt["type"], inputt["name"] ), default=get_default_value(inputt["type"]), ) ) questions.append( inquirer.Text( name="block", message="Enter the block number to perform the query", default=block, ) ) return questions # Gets the user inputs required to pass as function # parameters in the method selected for the custom contract def get_user_input(inputs, block): questions = build_prompt(inputs, block) answers = inquirer.prompt(questions) block = answers["block"] del answers["block"] return list(answers.values()), block # Returns the default value of an inquirer prompt # based on a smart contract function input type def get_default_value(input_type): if "address" in input_type: return ZERO_ADDRESS elif "uint" in input_type or "int" in input_type or "enum" in input_type: return "0" elif "bool" in input_type: return False elif "bytes" in input_type: return "0x0" elif "array" in input_type: return [] elif "string" in input_type: return "" return None # Returns the option selected to query on a custom # smart contract. Also returns the contract methods names # and their required inputs def get_custom_selection(): contract_functions = get_contract_call_methods() return ( inquirer.prompt( [ inquirer.List( name="custom", message="Choose a function from the smart contract", choices=contract_functions.keys(), ) ] )["custom"], contract_functions, ) # Performs the selection process for a method # on the smart contract to query def process_custom_selection(selection, contract_functions): latest_block = get_block_number() # print("Required Inputs: ", contract_functions[selection]) inputs = contract_functions[selection] user_inputs, block = get_user_input(inputs, latest_block) # print("inputs: ", user_inputs) if len(inputs) < 1: call_contract_function_without_params(selection, block) else: call_contract_function_with_params(selection, user_inputs, block) Final touches Now, we need to implement our final prompt that will manage to choose if query common state or a custom smart contract function. The common.py file contains the code to select if a user will query a common state function or one given on the custom smart contract, so it serves as a middleware to decide what to execute next.  import inquirer from src.prompts.custom_state import * from src.prompts.common_state import * # Prompts the main selection panel def get_selection(): questions = [ inquirer.List( "main query", message="Select the type of functions to query", choices=[ "Common state functions (get_balance, get_block,...)", "Custom contract state functions", ], ) ] answers = inquirer.prompt(questions) if "Common" in answers["main query"]: selection = get_commons_selection() process_commons_selection(selection) else: selection, contract_functions = get_custom_selection() process_custom_selection(selection, contract_functions) Finally, and most importantly, our main.py file shall execute the get_selection function to prompt all user inputs.  from src.utils import * from src.prompts import common common.get_selection() To run a demo of this app, on the projects root folder, we just run:  python main.py If we choose to run common state functions queries, it will ask at least for the block number (it will use latest as default). Some other functions will require an address (it will use the zero address by default).  Demo of querying the ETH balance of an address on a given block On the other hand, we could query any state call function from our custom smart contract. The inputs will vary depending on the function to query (some functions will not even need an input). Demo of querying the totalSupply of the SHIBA-INUJ ERC-20 Tken As always, the complete code is available in the tutorial’s repository.  Conclusion In this series, we have discovered how to perform, programmatically and interactively, state queries to a given network and a custom smart contract. This scripting tutorial allows fetching helpful information about the actual and historical states of the blockchain in an error-based approach. For example, this tool could perform different queries to a network state using both full and archive nodes. This transition is helpful in situations where the calls to an RPC provider get limited, and every one of them needs to be executed in the most efficient way possible. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Querying pending transactions with GraphQL from Geth A GraphQL endpoint is a useful alternative to JSON-RPC, especially when querying a large amount of data. Using GraphQL can reduce resource consumption significantly since it is lightweight and more resource-efficient. Currently, GraphQL is natively supported on Ethereum, BNB smart chain, and Fantom. This tutorial shows you how to use GraphQL to fetch pending transaction data from Geth. And compares GraphQL and JSON-RPC in terms of speed and data size. Prerequisites A dedicated Ethereum node from Chainstack.A web browser GraphQL is available on dedicated Ethereum nodes on Chainstack, starting from the Growth plan. Follow this guide to set up your own dedicated node. Once the node is ready, the GraphQL endpoint can be found in your console: Figure 1: GraphQL endpoint access details in the Chainstack console How it works In GraphQL IDE Geth comes with a native GraphQL IDE, users can access it at the following URL: https://**********/graphql/ui All you need to do is fill in the query and click the run button. Figure 2: GraphQL IDE You will get a list of pending transactions in the result panel: Figure 3: GraphQL IDE response to query With JavaScript Create an empty HTML file and paste the following code into it. <html> <header> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script> </header> <body> <div class="result"></div> </body> <script> //Fill in your httpURL and graphQLURL here var httpURL = "" var graphQLURL = "" var startTime = new Date().getTime() console.log("Program start timestamp:" + startTime) var dataGraphQL = '{"query": "query{pending{transactions{hash,gas,s,r}}}"}' $.ajax({ type: "POST", contentType: "application/json", url: graphQLURL, data: dataGraphQL, success: function(res) { resultTime = new Date().getTime() - startTime console.log("graphQL gets result in " + resultTime + "ms") $(".result").text(JSON.stringify(res)); console.log(res); } }); var dataRPC = '{"jsonrpc":"2.0","method":"txpool_content","id":1}' $.ajax({ type: "POST", contentType: "application/json", url: httpURL, data: dataRPC, success: function(res) { resultTime = new Date().getTime() - startTime console.log("RPC gets result in " + resultTime + "ms") console.log(res); } }); </script> </html> Remember to fill in the URL for both http and graphQL endpoints at line 11. Open the HTML file with any browser to see its output: Measuring the performance The above JavaScript code also measures the latency of data retrieval. You need to open the developer console to see it. Figure 4: Measuring latency of data retrieval in the developer console Comparing latency for 7 rounds. GraphQL query time(ms)RPC query time(ms)RPC/GraphQL*100%8131317161.99%8911499168.24%37314281114.74%5811176202.41%30533624118.70%4191025244.63%17352540146.40%Figure 5: Latency comparison results from seven rounds Figure 6: GraphQL response object size Overall, GraphQL takes 60% of the time for data loading. The response object is only 40% in size compared to an RPC endpoint. Please also take note that: In the test case, the RPC endpoint not only returns the pending transactions but also queue transactions.GraphQL does not retrieve the full object. It only contains four fields: hash, gas, s, and r. GraphQL is more resource effective because users can specify which fields to retrieve. Conclusion This is the end of this article. If you have any questions, feel free to ping us on our Telegram and Discord. Cheers! Happy coding. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Quicknode RPC provider overview (2026) Quicknode is a popular blockchain RPC provider that lets developers interact with blockchains without running their own nodes. A Quicknode RPC provider offers API endpoints to read data and send transactions on networks like Ethereum and Solana, making it an essential for decentralized applications that require fast and reliable blockchain access. TL;DR Quicknode known for solid performance, low latency, high throughput, and 99.9% uptime. Key tools include Streams for real-time data, Webhooks for instant on-chain alerts, and dedicated clusters for enterprise users. Its credit-based pricing can make costs unpredictable. Chainstack offers a strong alternative with similar performance and uptime, but with flat, transparent pricing, no hidden throttling, and flexible multi-cloud deployment. Brief history of Quicknode Quicknode was founded in 2017 and has grown into a leading Web3 infrastructure platform. It now supports dozens of networks and powers many high-traffic decentralized apps. Quicknode’s infrastructure handles billions of RPC calls per day for clients including major exchanges, DeFi platforms, and NFT marketplaces. The company’s rapid growth underscores the rising demand for scalable blockchain connectivity. Quicknode core RPC products and services Quicknode offers a suite of services to help developers build and scale on blockchain networks. Its Core RPC API provides globally distributed endpoints for 70+ blockchains, allowing connections to Ethereum, Solana, and many others over HTTP or WebSocket. Key offerings include: Streams: real-time blockchain data feeds and backfilling tools for streaming events or indexing chain data. Link Webhooks: instant notifications of on-chain events, so applications can react to new blocks, transactions, or contract triggers in real time. Link Dedicated clusters: isolated node instances for enterprise users who need maximum performance with no shared resources. Link Additional APIs and tools: specialized APIs and a marketplace of add-ons for extended functionality. Quicknode performance profile Quicknode platform is engineered for speed and reliability across key metrics: Latency: Quicknode delivers very fast response times. In one benchmark it achieved ~86 ms average latency for Ethereum. For Solana, Quicknode p95 latency is around 50 ms, versus ~187 ms on some other providers. Reliability: The network’s automatic regional failover and load balancing keep requests flowing even during outages or spikes. Quicknode also had one of the lowest error rates in independent tests, reflecting a very stable service. Throughput: Quicknode can handle heavy workloads. Entry tiers support 15–50 RPS, while higher plans scale to 250+ RPS. The infrastructure automatically expands to absorb traffic bursts without performance loss. Uptime: Quicknode targets 99.9% availability on paid plans. Its globally distributed, multi-region architecture maintains enterprise-grade uptime, meaning developers can count on the service around the clock. AreaQuicknode strengthsPotential weaknessesPerformanceVery low latency on major chainsNot uniquely faster than top peers in all regionsReliabilityGlobal footprint, failover, 99.9% uptime on paid tiersHigher SLAs usually on higher tiersScaleHandles heavy bursts; high RPS on upper plansPlan limits if credits are exceededFeaturesStreams, webhooks, marketplace, dedicated clustersHigher SLAs are usually on higher tiersPricingFlexible credit model as you growMethod-weighted billing can be hard to predict Quicknode pricing: what to watch The difference becomes clear when the same high-volume workload is priced under request-based billing versus credit-based billing. MetricChainstackQuicknodePlan used in exampleProScaleIncluded usage80M Request Units950M API CreditsWorkload equivalent73.5M method calls73.5M method callsOverage neededNone520M API CreditsPlan price$199$499Overage charges$0$276Total monthly cost$199$775 Quicknode uses a credit-based model, which means effective cost depends on the exact mix of methods your application calls. For low-volume projects this can be manageable, but for production workloads with heavy reads, subscriptions, traces, or burst traffic, forecasting can become harder. Chainstack uses request-based pricing, which is usually easier to model operationally because standard RPC usage maps more directly to monthly traffic. For teams that care about cost predictability as much as raw performance, this difference becomes meaningful quickly. See the full cost comparison → Final thoughts: Quicknode vs Chainstack Both Quicknode and Chainstack deliver high-performance RPC infrastructure, but there are notable differences. Chainstack often matches Quicknode on raw speed and offers more flexibility and cost predictability. Chainstack runs a similarly low-latency global network – in one test its EU latency was the same as Quicknode and it provides a 99.99%+ uptime SLA on a multi-cloud infrastructure. Arbitrum EU Comparison by Latency. Source: Chainstack Grafana Where Chainstack excels is pricing and scalability. Quicknode uses a credit-based model that can incur surprise overage fees when certain calls consume more credits, whereas Chainstack uses transparent request-based plans with flat rates and no hidden throttling. Almost every RPC call counts equally on Chainstack, so costs stay predictable and high volumes won’t trigger performance caps or extra fees. Quicknode is renowned for its speed and broad multi-chain support, making it a strong choice for performance-sensitive applications. However, Chainstack offers comparable performance with more predictable pricing, greater deployment flexibility, and equally robust uptime – a combination that makes it a compelling alternative to Quicknode for many blockchain projects. Try Chainstack with predictable RPC pricing → FAQ Is Quicknode reliable for production use? Quicknode is highly reliable. It operates on a globally distributed infrastructure with automatic failover and regional load balancing to minimize downtime. Independent performance tests show that Quicknode consistently handles high request volumes with over 99.9% success rates. Paid plans come with a 99.9% uptime guarantee, making it suitable for production-grade Web3 applications. Is Quicknode a secure platform? Quicknode implements several security measures to protect infrastructure and customer data. It offers TLS-encrypted endpoints, role-based access controls, and private endpoints for sensitive use cases. While security practices are not always disclosed in full detail, Quicknode is used by major DeFi protocols, exchanges, and enterprises, which indicates a high standard of operational security. For mission-critical workloads, users can opt for dedicated clusters to isolate traffic and improve data privacy. How does Quicknode perform on metrics like latency and uptime? Quicknode delivers low-latency performance, high throughput, and a 99.9% uptime guarantee across paid tiers. What are the main differences between Quicknode and Chainstack? Quicknode emphasizes speed and multi-chain access, while Chainstack offers similarly fast RPC performance with predictable pricing, no hidden request throttling, and more control over node deployment. Does Quicknode charge differently for different types of requests? Yes. Quicknode uses a credit-based pricing model where some requests consume more credits. In contrast, Chainstack uses a flat request-based model, making costs more predictable. Related Reading Chainstack vs Quicknode vs Alchemy: Which blockchain API is most cost-effective in 2026 Alchemy RPC provider overview Helius RPC provider overview dRPC provider overview Ankr RPC provider overview #### QuickSwap on Chainstack: Powering up the mightiest DEX on Polygon QuickSwap provides best-in-class DEX services, giving thousands of people every day access to a sustainable and robust Layer 2 ecosystem. Handling over 2 billion QuickSwap requests per month with peace of mind, Chainstack ensures their Polygon PoS nodes are fast and reliable, leaving users to trust QuickSwap and enjoy the benefits of low fees and fast transaction validation. What is QuickSwap? QuickSwap is a permissionless decentralized exchange (DEX) based on Ethereum, powered by the Polygon network‘s Layer 2 scalability infrastructure and by the QUICK and Dragon’s Quick tokens. By utilizing Layer 2 for transactions, QuickSwap users can trade any ERC20 asset at lightning-fast speed with near-zero gas costs. How did QuickSwap come across Chainstack? Initially, QuickSwap used exclusively one provider, which made maintaining a stable and reliable infrastructure challenging, given the outstanding rate of growth of their platform and the Polygon ecosystem. This meant expending increasingly more resources and team members’ time on maintaining and monitoring the nodes. QuickSwap makes liquidity more accessible to the DeFi community and it is experiencing exponential growth month-on-month, supporting $1.5 billion TVL, $2.3 billion volume, and serving over 40 thousand users every month with a market cap at $480 million. Having only recently launched its Polygon support, Chainstack immediately stood out among all the infrastructure options open to QuickSwap because it makes node infrastructure more cost-effective, especially for high-intensity requests projects. In addition, the top-quality engineering from the Chainstack team uses cutting-edge solutions that can reliably handle even the mightiest among all the Polygon projects. How does Chainstack’s offer match QuickSwap’s needs? The QuickSwap addition of Chainstack’s reliable Polygon nodes to its core infrastructure ensures a stable and performant service during traffic spikes, sitting at over 2 billion calls to the Chainstack nodes per month. Chainstack, with its solid reputation and flawless track record within the Polygon & Web3 communities, was the obvious choice when it comes to scaling our system and improving its performance. Ever since our first contact with the Chainstack team, we have been delighted by the 5-star support we’ve received: amazing response time, highly skilled and solution-oriented team. Trusting Chainstack with our nodes, we can focus on building and adding more platform features, supporting their scaling, and working on an always improving user experience. Sameep Singhania, co-founder of QuickSwap What does Chainstack like about QuickSwap? QuickSwap was created and is backed by some of the industry’s most prominent thought leaders in the fields of Ethereum token and contract standards, as well as Layer 2 scalability. The protocol represents the next stage in the evolution of decentralized trading and is designed to enable the next wave of users to enter DeFi, just like Chainstack represents the next evolution of resilient, business-ready blockchain managed services. What is the most interesting engineering challenge in working together? Because the Polygon network is much faster and cheaper than Ethereum, swapping tokens and yield farming on QuickSwap is extremely cost-effective. However, a rapid increase in QuickSwap adoption cannot happen without resilient infrastructure. Chainstack supports this with a top-notch engineering team to create a shared vision for a rapidly scaling Web3 and mass adoption. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Real-time Solana analytics for Raydium and Bonk.fun tokens with the Geyser plugin Solana moves fast, and getting reliable, low-latency data out of it is harder than it should be. Polling RPC and basic WebSockets subscriptions often lag behind or require complex logic. This guide walks through how to use the Geyser plugin, deployed on a Chainstack Global Node, to stream structured Solana data in real time using Rust or TypeScript. We’ll show how to track Raydium swaps, detect Bonk.fun token launches as they happen, and turn that into a live analytics pipeline. Understanding the Geyser plugin in Solana’s architecture Solana Geyser plugin is a plugin baked into Solana node software that streams blockchain data in real time. Instead of polling or parsing logs, it taps directly into validator memory and pushes updates as they happen on-chain. Solana is fast. Geyser is faster. It pushes data the moment it’s produced, and avoids the usual RPC delay entirely. This means you can subscribe to accounts, transactions, blocks, or slots, and updates show up almost immediately. How it fits in: RPC node with Geyser enabled emits structured updates for every slot, block, transaction, and account change. These updates are streamed over a gRPC interface, specifically the open-source Yellowstone gRPC implementation, which any client can connect to. Whether you want the full transaction stream or only what touches specific programs or accounts, Geyser handles both. The output is Protobuf: structured, decoded, and usable without extra parsing. Compared to Solana native WebSocket interface, which is limited to base64-encoded messages and coarse filters, Geyser offers structured payloads and fine-grained subscription logic. That makes it far better suited for real-time use cases like analytics pipelines, trading bots, dashboards, or any system that depends on sub-second visibility. Key benefits of Geyser: It streams transaction data, account state changes, slot updates, and block information in real time, all over a stable gRPC connection. Each transaction comes with full context, logs, instructions, and execution data, giving you more detail than what logsSubscribe over WebSocket typically exposes. Yellowstone gRPC streaming works across languages: Rust, TypeScript, Python, Go… anything that supports gRPC. That makes it easy to drop into most existing stacks without custom tooling. It also offers a real performance edge. In benchmarks, Geyser consistently detects on-chain events faster than RPC polling or WebSocket listeners. For example, when monitoring new token mints, Geyser-based subscribers detect events significantly earlier than other methods, often by hundreds of milliseconds (Read our article comparing WebSockets and the Geyser Plugin). If you’re tracking something time-sensitive, like a new Bonk.fun token launch or a large Raydium swap, Geyser is built to catch it first. It’s purpose-built for real-time blockchain analytics, and consistently delivers the lowest-latency data stream available on Solana. Setting up Geyser with Chainstack’s Solana nodes (Global Node configuration) Chainstack makes it easy to use the Geyser plugin without running your own validator. With managed Solana RPC nodes and a one-click Yellowstone gRPC Geyser plugin add-on, you can get set up in minutes. Deploy a Solana node on Chainstack: In the Chainstack console, create a new Solana node. For best performance, select a Global Node deployment – this gives you a geo-distributed, load-balanced RPC endpoint that automatically routes traffic to the closest region for low latency and high availability. Enable the Geyser plugin add-on: Once your Solana node is up, go to its detail page and enable the Yellowstone gRPC Geyser Plugin under the Add-ons section. Installation takes just a few moments. (Note: The Geyser plugin is available on Growth plans and above, so make sure your subscription includes it.) Obtain the Geyser endpoint and credentials: After the plugin is installed, you’ll receive a gRPC endpoint URL and API token (e.g. yellowstone-solana-mainnet.core.chainstack.com:443). You’ll use these to connect your client and start streaming real-time data. Once installed, the Geyser plugin runs automatically: no validator hardware, no plugin compilation. Chainstack handles all of it behind the scenes, giving you a production-ready Geyser endpoint by default. With Global Nodes, traffic is load-balanced across regions for low latency and built to scale under heavy load. In short, using Chainstack Solana nodes with Geyser gives you a production-ready data pipeline with minimal fuss, plus the stability of a globally distributed network (no single point of failure) and the performance of direct memory streaming. (For more details, see Chainstack documentation on enabling the Yellowstone Geyser plugin and the advantages of Global Nodes.) Streaming real-time data for Raydium and Bonk.fun tokens Once the Geyser plugin is running on your Chainstack node, you can start streaming real-time Solana data and filter it down to the programs you care about. In this case: the Raydium DEX and the Bonk.fun token launchpad. Both are on-chain programs, so their actions — swaps, liquidity pool creation, token launches — all produce transactions that touch specific program IDs. Filtering the Geyser stream by those program IDs gives you a targeted feed, only events related to Raydium and Bonk.fun come through. Raydium overview: Raydium runs one of the main AMMs on Solana, powering token swaps across the network. In 2025, it added a Launchpad for new token sales, often just called Raydium Launchpad. If you’re tracking swap activity or the creation of new liquidity pools, you’ll want to follow the AMM program ID directly. The main ID for Raydium’s v4 AMM is: LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj Raydium also uses other program IDs for components like concentrated liquidity and staking, but for now, we’ll focus on the AMM. Bonk.fun overview: Bonk.fun (previously LetsBonk.fun) is a meme-token launchpad launched on April 25, 2025 by the BONK community and Raydium. It blew up fast. Anyone can create a token, and it’s auto-listed on Raydium as part of the flow. Every time someone launches a token via Bonk.fun, a Solana transaction is executed on the Bonk.fun program (which likely creates the token mint and initial liquidity provisioning). Bonk.fun quickly overtook the earlier Pump.fun platform – recording over 10,000 token creations and grabbing ~54% of the Solana token launch market by July 2025. What this means for us is that new token events on Bonk.fun can be detected by watching the Bonk.fun program’s transactions in real time. Identifying program IDs: To stream these events, you need the program IDs. Raydium’s AMM program ID is known (as above), and let’s assume we have Bonk.fun’s program ID   FfYek5vEz23cMkWsdJwG2oa6EphsvXSHrGpdALN4g6W1 We will configure our Geyser subscription to include these IDs as filters. Example: Subscribing to program events (Python) Chainstack’s Geyser endpoint speaks gRPC, so you’ll want a client library to handle the connection. When it starts, the script reads GEYSER_ENDPOINT, GEYSER_API_TOKEN, and an optional AUTH_TYPE from the environment and opens a TLS-protected channel authenticated with either the default X-Token header or basic auth. It hard-codes the program IDs for LaunchLab and the LetsBonk platform, along with the eight-byte discriminator that identifies LaunchLab’s initialize instruction. As each transaction arrives, the code skips failed or vote transactions, scans the instructions for that discriminator, and, when found, manually unpacks the nested MintParams, CurveParams, and VestingParams structures to pull out human-readable fields such as token name, symbol, decimals, metadata URI, curve type, vesting schedule, and all relevant account addresses. Check the full code example in GitHub repo def create_subscription_request(): """Create a subscription request for LetsBonk transactions.""" request = geyser_pb2.SubscribeRequest() # Monitor transactions that include both Raydium LaunchLab and LetsBonk Platform Config request.transactions["letsbonk_filter"].account_required.append(str(RAYDIUM_LAUNCHLAB_ID)) request.transactions["letsbonk_filter"].account_required.append(str(LETSBONK_PLATFORM_CONFIG_ID)) request.transactions["letsbonk_filter"].failed = False request.transactions["letsbonk_filter"].vote = False request.commitment = geyser_pb2.CommitmentLevel.PROCESSED return request def print_token_info(token_info: Dict[str, Any], signature: str): """Print formatted token information in a compact format.""" print(f"\n🚀 NEW TOKEN: {token_info.get('name', 'N/A')} ({token_info.get('symbol', 'N/A')})") print(f" Signature: {signature}") print(f" Creator: {token_info.get('creator', 'N/A')}") print(f" Base Mint: {token_info.get('base_mint', 'N/A')}") print(f" Pool State: {token_info.get('pool_state', 'N/A')}") print(f" Metadata: {token_info.get('metadata_account', 'N/A')}") if token_info.get('uri'): print(f" Metadata URI: {token_info['uri']}") print(" " + "="*60) Here’s a step-by-step example showing how to wire up Geyser for real-time token tracking: These details are assembled into a token_info dictionary and immediately logged to stdout. The implementation avoids heavyweight Solana SDKs, depending only on the standard library plus grpc-aio, python-dotenv, base58, and the generated Geyser protobuf stubs, and it keeps secrets outside source control via a .env file. Integrating the streamed data into analytics pipelines Once you’re streaming events from Geyser, you can wire them directly into dashboards, storage layers, or bot logic. Here are few ways teams process Raydium and Bonk.fun data in real time: Real-time dashboard: You can push the incoming data to a WebSocket server or pub/sub system to update a live dashboard. For example, Track Bonk.fun token launches as they’re created, names, creators, metadata, or display swap activity on Raydium by token pair. With Geyser’s sub-second latency, updates appear nearly in real time. Database and indexing: For more permanent analysis, pipe the data into an analytics database. Write each transaction to a document store or time-series DB. For example, log every Bonk.fun launch with a timestamp, then later query how often tokens are launched or how many hit a certain volume. Raydium swap data can be indexed the same way to track things like pool-level TVL or volume over time. Alerting and bots: With real-time data, you could build alerting systems. Perhaps you want to be notified if a Bonk.fun token launch exceeds a certain initial liquidity (indicating a potentially serious project), or if a swap of an unusually large size happens on Raydium (could be someone dumping or a big buy). A small script could watch the Geyser stream and trigger alerts (send a message, email, or Telegram via a bot) when conditions are met. In fact, some trading bots use exactly this approach to snipe newly launched tokens – they subscribe to creation events and automatically buy tokens within seconds of launch, gaining an edge over slower methods. Chainstack Global Node handles the Geyser stream behind the scenes, routing traffic across regions, failing over when a node lags, and scaling under load. Since the data comes structured over gRPC, you don’t need to write custom parsers or deal with missing fields. Conclusion The Solana Geyser plugin on Chainstack gives you real-time access to on-chain events. We demonstrated conceptually how Geyser fits into Solana’s architecture as a high-speed data firehose, and we walked through enabling it on Chainstack’s platform (just a few clicks). With a simple TypeScript or Rust client, we can then filter and stream live data for Raydium’s DEX and Bonk.fun’s token launches, among other use cases. This lets you track every new meme token launch as it happens or collect swap data for trend analysis with minimal delay and no extra load on Solana’s RPC servers. Geyser runs on Chainstack Global Node setup with built-in failover and traffic distribution. It scales under load, and since the data comes through gRPC, it works with Rust, TypeScript, and other common stacks. No extra infra overhead, just stream and filter. Further reading Docs cover how to stream program updates with Geyser in Node.js, plus a pump.fun bot that shows the latency difference vs WebSockets when catching new tokens. There’s also a breakdown on Chainstack’s blog comparing WebSocket and Geyser latency, including Raydium swap tracking as a benchmark use case. All these resources will help deepen your understanding and give you more sample code to draw from. Harnessing real-time Solana data has never been easier. With Chainstack + Geyser, you’re ready to build analytics for the next wave of Raydium trades and Bonk.fun launches – and get that data as fresh as it comes. Happy coding, and happy streaming! #### Real-time Solana data: WebSocket subscriptions vs Yellowstone gRPC Geyser Building real-time dashboards or DeFi apps on Solana often starts with a simple question: How do I get fresh data as soon as it happens? For most developers, the journey begins with RPC polling using getProgramAccounts, then evolves into WebSocket subscriptions. But as projects scale, limitations surface—leading many to adopt next-generation solutions like Yellowstone gRPC Geyser. In this article, we’ll break down: What WebSocket subscriptions offer What you gain (and lose) with Yellowstone Practical use cases like tracking swaps on Raydium Which approach fits your needs Why not just use getProgramAccounts? Solana’s getProgramAccounts is a powerful RPC method, often used to fetch all accounts tied to a program like Raydium or Serum. But it’s not real-time, and using it in production has serious drawbacks: Requires constant polling Fetches large datasets repeatedly Difficult to detect small changes efficiently Adds backend complexity (diffing, filtering, deduplication) Result: High latency, unnecessary compute, and increased traffic. Option 1: Solana WebSocket Subscriptions (Built-in RPC) Solana’s JSON-RPC API supports WebSocket subscriptions to receive live updates about accounts, transactions, logs, and blocks. Supported WebSocket Methods MethodPurposeaccountSubscribeGet updates when a specific account changesprogramSubscribeGet updates for any account in a given programlogsSubscribeListen for transaction logs (events) from specific programssignatureSubscribeReceive status updates for a specific transactionslotSubscribeStream slot updates in real time Pros No need to poll Easy to set up in small apps Suitable for lightweight use cases (single wallet, DApp) Cons No parsing: Data is returned in base64, must be manually decoded No history: Subscriptions only work from the moment they start Limited filtering: You can’t say “only notify me about USDC changes” Subscription caps: Most providers limit to ~100–200 subs per connection Complex real-world logic: Requires stitching together data from logs, account states, and additional RPC calls like getTransaction or getParsedAccountInfo Option 2: Yellowstone gRPC Geyser Yellowstone is a high-performance Solana streaming service built on gRPC over HTTP/2, offering structured, low-latency updates with deep filtering. Key features gRPC binary protocol: Compact, fast, and persistent Structured data: Account diffs, token balance changes, parsed logs Custom filters: By program, account, transaction type Multiple streams: Account, transaction, and block updates separately Designed for production-scale DeFi dashboards Benefits Sub-second latency with no polling Filtered streams reduce backend load Direct frontend syncing—no spaghetti backend logic Built-in support for Raydium, Orca, wallet activity, and more FeatureWebSocketYellowstoneReal-time updates✅✅Sub-second latency⚠️ Sometimes✅ ConsistentlyAuto-parsed data❌ base64 only✅ Structured fieldsEvent filtering⚠️ Limited✅ Fine-grained filtersPerformance at scale❌ Capped✅ Horizontal scalingSDK support⚠️ Custom logic✅ Auto-generated SDKsStream history❌⚠️ Partial (depending on use) Explore how it works with real DeFi data in our pump.fun Solana token mint tutorial or explore our Ultimate Solana Developer Guide. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Real-time Solana DEX monitoring with Yellowstone gRPC Geyser Solana DEXs move fast. Whether you’re tracking liquidity on Raydium, monitoring memecoin surges on Pump.fun, or watching price shifts on Orca—speed is everything. But monitoring in real time? That’s the hard part. The problem is outdated infrastructure. Most devs still rely on polling getProgramAccounts every few seconds to detect activity. It’s slow, clunky, and expensive to scale. The problem: Polling is killing performance To track every token swap, liquidity update, or position change, you’re forced to: Fire off repetitive RPC calls Parse massive datasets for a single delta Add complex backend logic to keep up And you’re doing all of this just to stay in sync. Here’s the breakdown: Traditional ApproachYellowstone StreaminggetProgramAccounts calls every 2–5 secSingle stream, always freshParse full state to find changesReceive only changesRPC request spikes = latency spikesSub-1s latency, alwaysBackend overhead = $$$Low infra cost, high data fidelity This model breaks under pressure. It doesn’t scale with volume—and in DeFi, volume is everything. The solution: Yellowstone gRPC Geyser Yellowstone delivers real-time Solana data via a high-performance gRPC stream. Forget polling. With Yellowstone, your DEX monitoring setup stays live with instant updates to: Account states Token balances Transactions Block metadata Stream it as it happens—no delay, no guesswork. Why it matters for DEX builders With Yellowstone, you can: Detect swaps as they hit the chain Monitor liquidity pool changes in real time Trigger signals and alerts based on on-chain events Sync frontends with sub-second latency Index transactions without lag or backfill jobs Perfect for: Market-making bots Whale watchers Trading dashboards Token launch monitors Front-running defense systems If you’re dealing with real-time data flows on Solana, Yellowstone gives you the competitive edge. Need a working example? See our guide on querying and analyzing Raydium data with Python. Built for performance with gRPC Yellowstone uses gRPC over HTTP/2, optimized for high-throughput use cases: Binary format for smaller payloads Persistent connections across topics Auto-generated SDKs for easy integration True sub-second latency Plus, it’s backed by Chainstack’s enterprise-grade Solana infrastructure—so you can stream with confidence. What can you build with Yellowstone on Chainstack? Yellowstone gRPC Geyser fuels high-speed DEX monitoring with precise Solana streams. Build these systems and how: Raydium trade alerts: Detect SOL-USDT swaps instantly. Use Transactions filters for Raydium’s program ID, set up to stream trade events, sending Telegram alerts for price shifts. Pump.fun liquidity watcher: Monitor memecoin pool changes. Apply Accounts filters on Pump.fun pool addresses, configured to stream liquidity updates, flagging arbitrage opportunities. Orca whale detector: Track large Orca trades. Combine Accounts and Transactions filters, subscribed to monitor wallet balances and Orca swaps, notifying users of whale moves. DEX performance chart: Visualize Pump.fun launch latency. Stream Slots filters, enabled to track slot processing, charting DEX performance during token surges. These tools use filters for real-time insights, giving users a competitive edge in DeFi. Get started today Yellowstone is available now on Chainstack: Create account at Chainstack Create Solana node Purchase Geyser plugin Setup your streams Need help? Dive into our Raydium data analysis walkthrough or explore the Ultimate Solana Developer Guide. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### RISC-V on Ethereum: a deep dive into the EVM environment Since last year, Vitalik Buterin, co-founder of Ethereum, one of the most popular blockchains, has discussed plans to explore migrating Ethereum’s runtime environment from the current Ethereum Virtual Machine (EVM) to RISC-V. The change would mean that smart contracts on Ethereum would compile, or be transformed, into low-level bytecode that a RISC-V processor would understand instead. A presentation by Vitalik Buterin at Protocol Berg v2 2025 conference outlining replacing EVM with RISC-V The move would require a major technical overhaul of Ethereum, but would provide various scaling benefits, such as the ability to use zero-knowledge proofs to verify compiles and broader flexibility in the programming languages in which smart contracts can be written. Since then, several major zero-knowledge virtual environments (zkVMs), which create zero-knowledge proofs to verify that they executed a set of machine instructions correctly, such as RISC Zero, Succinct, and a16z’s Jolt, compile to RISC-V.  Linea, an Ethereum L2 developed by Consensys, plans to deploy RISC-V compatibility on mainnet by the end of the summer of 2026.  Outside of blockchain, nearly 15 percent of systems on a chip (SoC) or microchips that integrate computer components use RISC-V as an architecture. RISC-V provides opportunities to scale Ethereum and improve the developer experience, but requires extensive, challenging technical implementation and raises many unknowns. This article provides Ethereum developers with a perspective on how RISC-V impacts them, highlighting current EVM bottlenecks, the value and trade-offs of migrating to RISC-V, and current RISC-V implementations. What is the Ethereum Virtual Machine (EVM)? Ethereum is unique compared to other blockchains, such as Bitcoin, as the Ethereum Virtual Machine enables Ethereum developers to deploy smart contracts, or self-executing computer programs, on-chain. Other blockchains are less dynamic, allowing only transaction updates within a ledger-like system. Ethereum allows more dynamic state changes because it operates as a state machine, an architecture that updates state based on previous state values or inputs.  The “state machine” is the Ethereum Virtual Machine (EVM), an Instruction Set Architecture (ISA) and runtime environment that defines the rules for changing state from block to block and executes smart contract code when given instructions. For example, when a smart contract is deployed on Ethereum, it is first compiled into bytecode that the EVM can execute. EVM is strictly used for Ethereum, while other ISAs are more general-purpose across other hardware and software implementations. A diagram of the components of the Ethereum Virtual Machine. Source: Ethereum Foundation What is RISC-V? Another ISA is RISC-V, an open-source ISA that defines the set of instructions a processor can execute and the interface between hardware and software. It is known for its simplicity, performance, and expansive contributions to its research.  In the case of Ethereum, it would replace EVM as the “state machine” and handle the compilation and execution of smart contracts. The Ethereum Foundation ruled out other popular ISAs used in computing, such as x86, WASM, and ARM, because RISC-V is simpler, more actively developed, and, overall, better suited to Ethereum’s needs. Proposal to migrate from EVM to RISC-V In his proposal, Vitalik Buterin outlined that a migration to RISC-V would require a major technical overhaul that would take at least 18 months but would improve scalability and could enhance the developer experience.  How RISC-V addresses EVM bottlenecks Although the EVM enables developers to build more on Ethereum than on other blockchains, the current EVM architecture poses several scalability challenges that RISC-V could address. Faster zero-knowledge proving At present, each validator must individually re-execute every transaction in each block to confirm the accuracy of the proposed state changes. To improve scalability, Ethereum will need to adopt zero-knowledge proofs, enabling verification that a computation was performed correctly without rerunning it.  EVM was not designed with efficient verification in mind, leading to long prover times and computational effort required to generate these cryptographic proofs. A few examples include: EVM operates primarily on 256-bit words, whereas most computations require much smaller values, resulting in unnecessary operational overhead. On the other hand, RISC-V words are 32-64 bits. It is harder for provers to track every transition in the process in EVM than in RISC-V. EVM uses a stack-based architecture, pushing each opcode value, or code for different operations, onto and off the stack as the code runs. In comparison, RISC-V allows values to be placed in 32 general-purpose registers whenever the compiler wants. For example, storing number 5, then number 4, and 3, and adding them requires three additional steps and more number tracking in EVM than RISC-V: An example of the number of steps required to add 5 + 4 + 3 in a stack-based (i.e., EVM) vs. register-based architecture (i.e., RISC-V). Created by the author. Initial research by Succinct Labs, cited by Vitalik Buterin, indicates that using zk proofs to verify Ethereum blocks on the EVM currently incurs 100 to 800 times the overhead of RISC-V. Linea also cited the core reason for migrating to RISC-V was the register-based architecture, which enabled a much faster prover. New @VitalikButerin blog post on replacing the EVM with RISC-V in the long-term.I am a huge fan of this direction for Ethereum's execution layer.Today, RISC-V zkVMs like SP1 are the clear endgame solution for "ZK-ifying" Ethereum and quickly becoming the de-facto solution for… pic.twitter.com/yFBojIheqC— Uma Roy (@pumatheuma) April 20, 2025 An X post by Uma Roy, an applied cryptographer at Succinct Labs, citing the significant overhead that using zk proofs on EVM requires as opposed to RISC-V, was retweeted by Vitalik Buterin. Developer experience RISC-V would enhance the overall developer experience for Ethereum by expanding the programming language options for writing smart contracts and potentially making more research and tools available. Developers would benefit from more programming language options with RISC-V migration. Currently, Ethereum developers can write smart contracts in Solidity or Vyper, the only two high-level programming languages that compile to EVM. When EVM migrates to RISC-V, Solidity and Vyper will still remain as options, but virtually any programming language can run on RISC-V. Migrating to RISC-V would also enable Ethereum developers to access research and tools that are already in place, as RISC-V has seen wide adoption across industries outside blockchain.  15 percent of systems on a chip (SoC) or microchips that integrate computer components use RISC-V as an architecture. Major companies such as Google, Intel, and NVIDIA are part of the RISE collaborative effort to accelerate the development of RISC-V software. A graphic showing the members of the RISE project, a collaborative effort led by industry leaders to accelerate the development of open-source software for the RISC-V architecture. How zkVMs use RISC-V A major example of how RISC-V could scale Ethereum, one more closely tied to blockchain, is the research and development of new zero-knowledge virtual machines (zkVMs). zkVMs are runtime environments that use zero-knowledge proofs to verify smart contracts, and all of which compile to RISC-V.  The Ethereum Foundation plans to integrate zkVMs to generate proofs of Ethereum blocks and allow clients to verify them in the consensus layer as part of its 2026 roadmap. Their main expectation is for the zkVM, which they specifically state should use RISC-V or “similar” (though it is not defined what similar may entail), to consume a guest program, or computer program that the zkVM can review, that consists of the block and witness needed to verify the block. As of mid-2026, eight zkVMs are being developed and tested with these expectations in mind, including LambdaVM, OpenVM, RISC Zero, Airbender, Jolt, Pico, SP1, and Zisk. Most zkVMs are still in progress toward meeting the minimal requirements to serve as a RISC-V “target” or version that Ethereum can use. A table listing the zkVMs under development and testing to serve as a RISC-V target for Ethereum. Source: Ethereum Foundation (RISC-V ZKVM Compliance Test Monitor) However, some of them have already demonstrated the value of a RISC-V-based zkVM.  SP1 already handles “real-time proving” or can prove a mainnet block within the roughly 12-second window before the next block arrives, allowing validators to verify a proof instead of re-executing each block. Initially, when launched on mainnet in November 2025, SP1 proved 99.7% of L1 Ethereum blocks on 16 GPUs in under 12s, and 95.4% in under 10s. Since then, as of May 2026, the v6 version of SP1 generates proofs six times as fast. RISC Zero allows developers to write smart contracts in mainstream languages such as Rust and Go. To verify that their zkVM behaves exactly as the RISC-V spec dictates, the team uses open-source conformance tests and a formal specification model — a critical requirement for security. Beyond that, RISC Zero is also working on formal verification tooling to produce mathematical proofs that their ZKVM is correct with respect to the RISC-V spec. Jolt, a zkVM developed by a16z crypto, is another useful example. Jolt was designed to be simpler, easier to audit, and easier to extend than other zkVMs, reducing the likelihood of errors. Rather than hand-specifying optimized constraints for every CPU instruction, Jolt showed how it can extend the Ethereum instruction set further. It handles instructions through lookups into structured tables, which means extending the instruction set for an even more robust ISA as Ethereum expands takes only a couple of days of developer time. Why RISC-V migration is not guaranteed Despite its promise, migrating Ethereum’s execution layer to RISC-V faces real technical hurdles around performance, reproducibility, and security. Some developers and stakeholders in the Ethereum community are still debating whether to commit to a specific ISA and instead support multiple ISAs, including WASM. Why risc-v over wasm for Ethereum contracts?If the argument is that there is more risc-v zkVMs than wasm ones, then that's the wrong way to look at it.WASM actually has a lot of nice properties that EOF is trying to add, which risc-v doesn't have (e.g. it doesn't have jumps… https://t.co/hFR1LjDMcT pic.twitter.com/fzHsxjs7pe— Wei Dai (@_weidai) April 20, 2025 An X post by Wen Dai, a partner at 1kxCapital, noted that a WASM migration should also be considered.   Even assuming a perfectly correct, formally verified zkVM, the compiler that turns high-level code into RISC-V code can introduce bugs that cause the binary to differ from the original program. Currently, zkVM codebases are massive, and even a minor bug in a zkVM toolchain can have disastrous consequences. Missing constraints might allow a prover to deceive a verifier with false claims.  Until these toolchains are thoroughly verified as bug-free, projects dependent on them are arguably safer through obscurity than actual cryptography. The Jolt codebase consists of tens of thousands of lines of Rust, and SP1 and RISC Zero are even larger, making it difficult to check for all potential bugs. Conclusion Replacing the EVM with RISC-V could alleviate many of the current bottlenecks around prover time speed, expand programming language options for developers, and connect Ethereum to the broader research ecosystem that has emerged around RISC-V. SP1 Hypercube — now in production with formal verification of all 62 RISC-V opcodes — has demonstrated this is no longer research, but production reality. However, RISC-V migration introduces real challenges in compiler correctness, security, and formal verification. The L1 timeline remains uncertain — Vitalik’s proposal estimates at least 18 months — but at the L2 level, the transition is already underway: Linea will deploy RISC-V proving on mainnet by the end of summer 2026, making it the first major rollup where developers encounter RISC-V in production. For builders running production workloads on Ethereum and Linea, the next 12 months are a practical inflection point. Tracking proof finality on Linea via linea_getVerificationStatus, tracing zkVM-generated proofs with archive access, and monitoring transaction behavior across the migration all require RPC infrastructure built for production-grade workloads. Chainstack provides Ethereum and Linea RPC endpoints with archive depth, trace methods, and SOC 2 Type II and ISO 27001 compliance — the profile that lets your application track this transition without rebuilding the RPC layer mid-migration. Deploy an Ethereum or Linea RPC endpoint → FAQ What is RISC-V, and why is Ethereum considering it? RISC-V is an open-source instruction set architecture that Ethereum is exploring because its simpler, register-based architecture could significantly improve scalability and developer flexibility. Would Solidity stop working if Ethereum were to migrate to RISC-V? No, Solidity and Vyper would likely remain supported alongside many additional programming languages that can compile to RISC-V. Why is the EVM difficult to prove efficiently? The EVM’s 256-bit word size and stack-based architecture create substantial overhead for zero-knowledge proving. Why is RISC-V faster for zero-knowledge proving? RISC-V’s register-based architecture requires fewer execution steps and simpler state transitions for provers to verify. What are the biggest risks of migrating Ethereum to RISC-V? The main challenges are implementation complexity, compiler correctness, zkVM security, and the difficulty of formally verifying large codebases. Is Ethereum definitely migrating to RISC-V? No, Ethereum researchers are highly supportive of RISC-V but are still actively debating it and are open to alternative approaches, including supporting multiple instruction set architectures. Additional resources From the Ethereum and zkVM ecosystem Vitalik Buterin’s RISC-V proposal Ethereum Foundation: zkEVM Test Monitor Linea’s RISC-V migration announcement SP1 Hypercube on Ethereum mainnet RISC-V: Good and Bad by Argument Ethereum Yellow Paper Build on Ethereum and Linea with Chainstack Chainstack Ethereum RPC Chainstack Linea RPC Chainstack Linea tooling docs Chainstack security and compliance #### Robinhood Chain vs Solana: two paths to tokenized RWAs? Two chains just landed the same bet from opposite directions. Robinhood Chain went live on mainnet July 1, 2026, an L2 for finance and tokenized real world assets built on Arbitrum’s Orbit stack. Solana has spent years as the default high-throughput L1 for anything that needs speed and cheap execution, HFT-style trading and payments included. What makes the comparison worth writing is that neither chain’s early traction matched its pitch. Robinhood shipped Stock Tokens and called the chain “purpose-built for tokenized RWAs.” Within three weeks, memecoins like CASHCAT and a flood of tokens launched through the NOXA launchpad were driving most of the activity, RWA value on the chain sat at roughly $12.66 million while the chain’s total value locked crossed $430 million and cumulative DEX volume hit $9 billion, over 80% of it memecoin trading. Solana’s own history rhymes with this — its reputation as serious payments infrastructure was built on the back of BONK, WIF, and pump.fun cycles long before institutional RWA issuers showed up. Chart: DeFiLlama — Robinhood Chain TVL So the real question isn’t just architecture. It’s whether tokenized RWAs actually need a dedicated, compliance-minded chain to succeed, or whether they just need whatever chain already has the users, the liquidity, and yes, the memes to get there first. What is Robinhood Chain Robinhood Chain is an L2 for finance and tokenized real world assets, built on Arbitrum’s Orbit stack and running the same Nitro client that powers Arbitrum One. It settles to Ethereum for security while executing transactions on its own network for higher throughput and lower fees — standard rollup architecture, full EVM compatibility, and no changes needed for existing Solidity contracts or tooling. The chain moved from public testnet in February 2026 to mainnet on July 1, 2026. 📖 Learn more: What is Robinhood Chain? A full builder’s guide (2026) Stock Tokens as the flagship RWA Robinhood markets the chain as “AI-native” and purpose-built for real-world assets, anchored by Stock Tokens like NVDA, AAPL, and GOOG. Technically, each Stock Token is a standard ERC-20 contract with 18 decimals, issued as a tokenized debt security by Robinhood Assets (Jersey) Limited rather than a wrapped or synthetic equity, so holders get economic exposure to the underlying stock without legal or beneficial rights against the issuer. Because they’re plain ERC-20s, they work out of the box with existing wallets, libraries, and DeFi contracts — no custom SDK required. Corporate actions are handled onchain through a multiplier rather than by rebasing balances. Dividends and stock splits adjust the shares-per-token ratio via a uiMultiplier() function defined by ERC-8056 (the Scaled UI Amount Extension), while a holder’s raw balance stays static until redemption. Swaps aren’t affected by this, and the oracle folds the multiplier into the reported price automatically. Oracle and pricing infrastructure Chainlink is the default oracle and cross-chain layer, with CCIP, Data Streams, and Data Feeds live from day one. Every Stock Token has its own onchain Chainlink price feed, so contracts can read live prices directly rather than relying on an off-chain data source or a bridge from another network. What is Solana Solana is a monolithic Layer 1, not an L2 settling to anything else. It runs its own consensus (Proof of History combined with Proof of Stake) and its own execution environment, the Solana Virtual Machine (SVM), which parallelizes transaction processing across independent state instead of executing sequentially like the EVM. That architecture is what gives Solana its throughput and sub-second block times, but it also means SVM programs are written in Rust or C, not Solidity — so nothing about Robinhood Chain’s EVM tooling transfers over. Built for throughput, not a specific asset class Solana wasn’t designed around any single financial product. It was built as general-purpose infrastructure for high-volume, low-fee execution, and its early narrative leaned heavily on payments and HFT-style trading rather than tokenized securities. That generality is the tradeoff against Robinhood Chain’s purpose-built approach. Solana can host anything from DeFi to gaming to RWAs, but nothing about the protocol layer is opinionated about how any of it should work. There’s no equivalent to Stock Tokens or a native RWA standard baked into the protocol. Real-world assets on Solana exist as SPL tokens, the network’s general-purpose token standard, issued and managed by third parties like Ondo, Franklin Templeton (BENJI), or Backed. Each issuer handles its own compliance, custody, and price feed setup independently, using the same SPL tooling any fungible token would use — rather than working within a chain-defined framework the way Stock Tokens do on Robinhood Chain. Architecture head to head Robinhood Chain has no validator set of its own securing consensus. It inherits Ethereum’s security model by posting transaction data and state roots back to L1 as an Arbitrum Orbit rollup, so finality depends on the underlying rollup’s dispute or validity mechanism settling on Ethereum. Its security ceiling is Ethereum’s, not its own. Solana runs an independent validator set with its own Proof of History and Proof of Stake consensus, so its security is self-contained but also self-limited — it doesn’t borrow trust from any other chain, and its guarantees rise or fall with its own validator economics and client diversity. Robinhood Chain inherits Ethereum’s security through rollup settlement, which means weaker sovereignty but a stronger base layer backing it. Solana’s security is native and independent, which means stronger sovereignty but full exposure to its own validator set’s failure modes. Execution environment Execution environment Robinhood Chain runs the Nitro client, which gives it full EVM compatibility. Solidity contracts, ethers.js, Foundry, and Hardhat all work without modification, and debug_* methods behave the same way they do on any Nitro-based chain. Solana’s SVM works differently at the architecture level. It parallelizes execution across accounts with non-overlapping state instead of processing transactions sequentially, which is where its throughput advantage comes from — but it also requires an entirely separate dev stack (Rust, Anchor, a different account and rent model), with zero code portability from Ethereum. Robinhood Chain uses EVM tooling and sequential execution, which lowers the switching cost for existing Ethereum teams. Solana uses SVM tooling with parallel execution by design, which raises the learning curve but also the throughput ceiling. Trust assumptions Robinhood Chain launched with a curated infrastructure set — Chainlink for oracles and interop, Alchemy and BitGo among the named partners — which concentrates a lot of the chain’s critical dependencies around a known group of vendors. Solana’s ecosystem is more permissionless by comparison. Oracle providers, RPC infrastructure, and custody solutions are fragmented across many competing providers rather than a small named set, trading vendor concentration risk for less standardization. RWA-specific design choices Robinhood Chain treats DeFi composability as a launch feature rather than something added later. Stock Tokens are usable as collateral from day one, with liquidity and lending partners like Uniswap, Pleiades, Morpho, and Lighter integrated at mainnet launch. RWA issuance and DeFi integration were built to ship together, rather than an asset getting tokenized first and composability arriving whenever a third party gets around to it. Solana takes the opposite path, mostly by necessity. Since there’s no protocol-level RWA standard, tokenized funds and treasuries get issued through existing infrastructure — SPL tokens, third-party compliance layers, existing DEX and lending integrations — that already work for any other asset on the chain. It’s a mature approach precisely because it isn’t new. Issuers are reusing infrastructure that’s already survived multiple market cycles, but none of it was purpose-built for RWAs specifically. Infrastructure and node access Robinhood Chain node coverage Robinhood Chain on Chainstack is available as Global Nodes in both Full and Archive mode, on Mainnet and Testnet, with Debug & Trace APIs enabled across all four combinations. That’s a fairly complete access surface for a chain three weeks old — full nodes for current state and transaction submission, archive nodes for historical queries, and debug tracing on both networks rather than mainnet-only. See the Chainstack Robinhood Chain announcement for the full support scope, or jump directly to the Robinhood Chain product page. Solana node coverage Solana’s setup on Chainstack looks different because the workload it’s built for looks different. Mainnet is served through Global Nodes in Archive mode plus regional Cloud nodes in London and New York, Devnet through Global and Ashburn-based Full nodes. Beyond standard RPC, Solana access includes Warp transactions for accelerated submission and the Yellowstone gRPC Geyser plugin, which streams account and transaction updates directly rather than requiring clients to poll. See the Solana product page for the full stack. What the tooling is actually built for The practical difference comes down to what each chain’s tooling optimizes for. Robinhood Chain gives builders standard EVM debug methods — debug_traceTransaction and debug_traceBlockByNumber among them — available from day one because the Nitro client supports them natively. That’s useful for anything that needs to replay a Stock Token transfer or step through a failed contract call. Solana’s tooling optimizes for a different problem: keeping up with a chain that produces state changes far faster than typical block-based polling can track, which is what Geyser’s gRPC streaming is actually for. Developer experience Robinhood Chain’s developer experience is largely inherited rather than built from scratch. Because it runs on Arbitrum Orbit and Nitro, existing Ethereum tooling — Solidity, ethers.js, viem, Foundry, Hardhat — works without modification, so deploying to it feels closer to targeting a new network than learning a new stack. Solana asks for more upfront: programs are written in Rust, typically with Anchor, and its account model, rent mechanics, and parallel execution rules don’t map onto anything from the EVM world. That cost isn’t wasted though — it buys into tooling shaped by years of high-frequency trading and payments workloads, where infrastructure like Geyser streaming and Warp transactions is more battle-tested than anything a three-week-old chain can offer. So the real tradeoff isn’t which stack is objectively better — it’s what an RWA issuer needs most. Familiar tooling and a fast path to shipping favor Robinhood Chain, especially for teams already building on Ethereum or its L2s. Tooling built and stress-tested for raw throughput favors Solana, particularly where performance at scale matters more than onboarding speed. Which path wins for RWAs There’s no clean verdict here, and that’s arguably the more honest takeaway than picking a winner. Robinhood Chain isn’t competing on raw technical merit — it’s competing on distribution and trust. A brokerage with tens of millions of retail users already holding real capital, already KYC’d, already comfortable with the idea of owning equities, is a different kind of unlock than another performant L2 hoping developers show up. Solana’s advantage runs in the opposite direction: it already has the liquidity, the DeFi composability, and years of infrastructure maturity that Robinhood Chain is still building out in real time. Robinhood Chain optimizes for trust and product market fit, using brokerage distribution as its wedge into RWAs. Solana optimizes for scale and existing liquidity, treating RWAs as one more asset class on top of infrastructure that already works. The more interesting question isn’t which chain is “better,” it’s which force ends up mattering more for where RWA capital actually settles. One read is that regulatory comfort becomes the deciding factor: institutions and issuers gravitate toward a chain with a named, accountable operator and a curated partner set, since that looks more like the compliance posture regulators already understand. The other read is that capital is largely indifferent to who’s operating the rails, and simply flows toward whichever chain offers the deepest liquidity and the most composable DeFi ecosystem — in which case Solana’s head start matters more than Robinhood’s brand. If regulatory comfort drives adoption, Robinhood Chain’s curated, accountable structure becomes the advantage. If capital efficiency drives adoption, Solana’s existing liquidity and composability becomes the advantage. It’s also worth resisting the urge to treat this as binary. Nothing structurally prevents both models from working simultaneously for different segments — Robinhood Chain absorbing retail-adjacent, brokerage-native RWA demand, Solana continuing to host the more DeFi-native, permissionless side of tokenization. Comparison table DimensionRobinhood ChainSolanaArchitectureEthereum L2, Arbitrum Orbit/NitroMonolithic L1, own consensus (PoH + PoS)Settlement and securityInherits Ethereum’s security via rollup settlementNative, independent validator setExecution environmentEVM, Solidity, sequential executionSVM, Rust/Anchor, parallelized executionRWA designNative, Stock Tokens purpose-built with DeFi collateral support day oneBolted on, SPL tokens issued by third parties (Ondo, BENJI, etc.)Oracle/interopChainlink native (CCIP, Data Streams, Data Feeds)Fragmented, multiple competing providersTrust modelCurated partner set (Chainlink, BitGo)Permissionless, more fragmentedDeveloper toolingStandard Ethereum tooling, low switching costRust/SVM, steeper learning curveChainstack node accessGlobal Nodes, Full and Archive, Mainnet and Testnet, Debug & Trace on all fourGlobal and Cloud Nodes, Warp transactions, Yellowstone gRPC GeyserDistribution advantageTens of millions of Robinhood brokerage usersExisting DeFi liquidity and ecosystem maturityCurrent traction realityMemecoin volume outweighs RWA activity early onRWA activity mature but still a minority of total volume The chains aren’t necessarily fighting for the same capital — they might just be building for different definitions of who an RWA holder actually is. Conclusion The question worth sitting with isn’t really which chain wins. It’s whether RWA tokenization needs its own category of infrastructure at all, or whether it just becomes another workload that general-purpose chains absorb once they already have the users and liquidity. Robinhood Chain is betting on the former. Solana’s traction so far suggests the latter might be closer to the truth — and the memecoin numbers on both chains right now aren’t exactly proving either side wrong. Chainstack’s position is that builders shouldn’t have to bet on that question in advance. Both networks are production-ready on Chainstack today: Robinhood Chain with Global Nodes, Full and Archive modes, and debug and trace on Mainnet and Testnet from day one; Solana with Global and Cloud Nodes, Warp transactions, and Yellowstone gRPC Geyser streaming. Whichever thesis plays out — dedicated RWA rails or absorption into existing chains — the RPC infrastructure to prototype, ship, and scale is available now, without waiting for the market to pick a winner. The first real evidence either way arrives soon. Robinhood’s Q2 earnings on July 29 should offer the first genuine look at Stock Token adoption, separate from chain-level vanity metrics like TVL or DEX volume — and it’s worth watching that number specifically over whatever headline figure gets reported alongside it. In the meantime, deploy a Robinhood Chain endpoint or a Solana endpoint on Chainstack and start building against the reality of both chains, not the pitch. 🚀 Start building on Robinhood Chain with 50% off the Growth plan for 3 months — use ROBINHOOD50 at signup. Start building on Chainstack → FAQ Is Robinhood Chain better than Solana for tokenized RWAs? Neither has proven the RWA thesis yet. Robinhood Chain is purpose-built for tokenized real-world assets with native Stock Tokens, Chainlink oracles, and DeFi partners integrated at launch — but early activity is dominated by memecoins, with RWA value around $12.66 million against $430 million total value locked. Solana has years of mature DeFi infrastructure and hosts institutional RWA issuers like Ondo and Franklin Templeton, but treats RWAs as one asset class among many rather than a first-class design goal. The winner will be the chain that converts speculative liquidity into persistent RWA adoption faster — a question July 29’s Robinhood Q2 earnings will start to answer. Can Ethereum developers deploy on Robinhood Chain without changes? Yes. Robinhood Chain runs the Nitro client under the Arbitrum Orbit framework, which gives it full EVM compatibility. Solidity contracts, ethers.js, viem, Foundry, Hardhat, and MetaMask all work without modification — teams can point existing tooling at a Robinhood Chain RPC endpoint and deploy the same way they would on Arbitrum One. Standard debug_* methods for transaction replay and call tracing are also available natively. Why is a chain built for tokenized stocks currently dominated by memecoins? This isn’t unique to Robinhood Chain. Solana was built as high-throughput infrastructure for payments and HFT-style trading, and became memecoin capital of crypto via BONK, WIF, and pump.fun long before institutional RWA issuers arrived. Ethereum went through ICOs, NFTs, and DeFi-summer cycles before institutional capital came in. Speculative liquidity often bootstraps chains before serious workloads arrive — meme-dominance early doesn’t disprove the chain’s long-term positioning, but it does mean the “purpose-built for RWAs” pitch is still unproven in production. Does Solana have tokenized stocks or real-world assets? Yes, but not through a native standard. Real-world assets on Solana exist as SPL tokens — the network’s general-purpose token standard — issued by third-party providers like Ondo (USDY), Franklin Templeton (BENJI), Backed, and VanEck. Each issuer handles its own compliance, custody, and oracle setup independently, using the same SPL tooling any fungible token would use. On Robinhood Chain, Stock Tokens are a first-class product with Chainlink price feeds built in per token — a more opinionated framework, but a narrower one. What infrastructure does Chainstack provide for Robinhood Chain and Solana? For Robinhood Chain: Global Nodes on Mainnet and Testnet, in Full and Archive modes, with debug and trace APIs enabled across all four combinations. For Solana: Global and regional Cloud Nodes on Mainnet and Devnet, Warp transactions for accelerated submission, and the Yellowstone gRPC Geyser plugin for real-time account and transaction streaming. Both chains are production-ready today — RWA builders can prototype on either without waiting for feature parity. When will Robinhood report Stock Token adoption numbers? Robinhood’s Q2 2026 earnings release is scheduled for after market close on July 29, 2026, with a call at 2:00 PM PT / 5:00 PM ET. That report should be the first genuine signal of Stock Token adoption — separate from chain-level metrics like TVL or DEX volume, which have been dominated by memecoin activity so far. Watch specifically for Stock Token holder counts, dollar value of Stock Tokens issued, and any commentary on cross-border retail uptake in the 120+ jurisdictions where Stock Tokens are available. Additional resources Chainstack introduces Robinhood Chain support Build better with Robinhood Chain Build better with Solana Blockchain infrastructure for RWA Robinhood Chain API reference #### RPC infrastructure for RWA: EVM node requirements Introduction Real-world asset tokenization is moving fast. Real estate, government treasuries, corporate bonds, and private credit are increasingly being brought on-chain, and unlike most DeFi activity, many of these transactions carry regulatory and operational requirements. A failed RPC call does not just mean a bad user experience. It can mean a broken compliance check or a missed settlement that puts institutional participants at risk. Source: RWA.xyz This article focuses on Ethereum, BNB Chain, and Arbitrum and breaks down exactly what their RPC requirements look like for protocols operating in this space. Deep dive into RWA protocols ERC-1400 and ERC-3643 are two of the most widely used permissioned token standards for RWA issuance. ERC-1400 introduced partitioned balances and document attachments for securities. ERC-3643 uses an identity registry architecture in which transfers are checked against on-chain verification logic before execution. If the receiving address is not authorized, the transfer reverts. From the user’s perspective this is a single transaction, but for indexers it creates a tracking problem across multiple contracts. The identity registry and the token contract are separate on-chain components that both need to be monitored independently. Compliance state changes in the registry may not appear on the token contract itself, so an indexer watching only token transfers can miss registry updates that affect who can legally hold the asset. That is where the RPC complexity compounds. Tokenized treasuries, real estate funds, and private credit instruments depend on oracle networks and custodian attestation services for NAV updates, proof-of-reserve data, and yield accruals. Unlike high-frequency price feeds, NAV for private credit or real estate is typically pushed once daily or weekly. The requirement is not high frequency, it is guaranteed delivery. If an RPC connection drops during the one window a custodian attempts to push a NAV update, the fund becomes untradable until the state is corrected. Why RPC matters for RWA RWA protocols run continuous background workloads independent of user activity. Compliance checks, oracle state polling, custodian attestation monitoring, and transfer event indexing all run on schedules tied to regulatory and operational requirements, not transaction volume. A tokenized treasury fund generates the same RPC load at 2am on a Sunday as it does during peak trading hours. Public RPC endpoints fail this workload in predictable ways. Rate limits get hit during oracle update windows. Nodes under high traffic inconsistently prune event logs, meaning a ComplianceCheck event can silently drop from your indexer’s view. No data residency guarantees create jurisdictional problems when regulators like the SEC or BaFin require logs to be stored and processed in specific regions. And when a missed Transfer event corrupts your view of token ownership, re-scanning from archive fixes it, but in a regulated environment being wrong for even ten minutes is ten minutes of potential illegal transfers with no real-time recourse. Required RPC methods for RWA and limits Not all RPC methods carry the same weight in an RWA context. The methods that matter are the ones tied directly to compliance execution, event indexing, and historical state access. Each chain in this article exposes a slightly different RPC surface, and in BNB Chain’s case, actively restricts certain methods on public endpoints.  Understanding which methods your protocol depends on, and where those methods hit limits, is what determines whether your infrastructure holds up under real operating conditions. Ethereum Ethereum’s RPC surface for RWA protocols centers on three methods. eth_call handles synchronous compliance checks against ERC-1400 and ERC-3643 identity registries on every token transfer simulation. This is a read-only execution against the current state, so it runs before any transaction is broadcast, meaning your RPC endpoint absorbs this load continuously as users attempt transfers. eth_getLogs is where Ethereum RWA infrastructure tends to break down at scale. Indexing Transfer, ComplianceCheck, and OracleUpdate events across multiple RWA contracts simultaneously generates heavy log filter queries. Public endpoints throttle these aggressively, and missing a log means your compliance state is out of sync with the chain. For historical queries, two methods require archive node access: eth_getStorageAt for reading contract storage at a specific past block, used in NAV reconstruction and proof-of-reserve verification debug_traceTransaction for full execution traces, which regulators expect when auditing specific settlement transactions BNB Smart Chain eth_getLogs  is not available on many public BNB Smart Chain mainnet endpoints, so RWA protocols that rely on log indexing generally need dedicated RPC access. This is not a rate limit issue, it is a hard restriction. Any RWA protocol that relies on event indexing for compliance or settlement cannot run on a public BNB Chain endpoint at all. Dedicated RPC is a baseline requirement, not an optimization. Chainstack covers this with full and archive BNB Chain nodes and eth_getLogs access enabled. eth_call and eth_sendRawTransaction use the same JSON-RPC interface as Ethereum but operate against BNB Chain’s PoSA validator network. The consensus model affects how quickly state is finalized and therefore how soon a compliance check result can be trusted after a block is produced. BNB Smart Chain produces blocks roughly every three seconds at significantly higher throughput than Ethereum mainnet. eth_subscribe WebSocket connections need to stay live and handle burst event volume during high-traffic windows. A dropped subscription means missing multiple blocks worth of compliance and transfer events before reconnection. Arbitrum Arbitrum Nitro supports the full standard eth_* method set. The key difference from Ethereum is sequencer behavior: transactions are processed by a central sequencer before being posted to L1, which affects how latency is measured and how quickly RPC responses reflect confirmed state. Two features are specifically relevant for Arbitrum workloads: eth_getBlockByNumber with the finalized tag, which returns the most recently finalized Arbitrum block, giving protocols a reliable settlement marker for regulated transactions. The transaction receipts expose the Arbitrum-specific l1BlockNumber field, which ties each settlement back to its corresponding L1 block context Bridge-related methods are also needed when tracking asset state across L1 and L2 simultaneously, a common requirement for RWA protocols that issue on Arbitrum but settle against Ethereum mainnet. Chainstack provides full archive access for Arbitrum from genesis. Without it you cannot reconstruct asset state at an arbitrary past block, which makes historical audit trails and regulatory reporting unreliable. Chain comparison Ethereum, BNB Smart Chain, and Arbitrum each represent a different tradeoff for RWA issuers. Ethereum leads on TVL and security but carries the heaviest infrastructure requirements. BNB Chain offers high throughput and growing institutional adoption but forces dedicated RPC from day one due to public endpoint restrictions. Arbitrum runs the full EVM method set at L2 costs with L1 finality as the settlement anchor, and its RWA ecosystem has grown quickly off the back of institutional issuers like Securitize and Spiko alongside the DAO-funded STEP treasury program.  EthereumBNB ChainArbitrumRWA TVLHighest ($16.2B+ as of May ‘26)$3.5B+ (as of May ‘26)Fast growingKey issuersBlackRock, Securitize, OndoHashnote, BlackRock, VanEckSecuritize, Spiko, WisdomTreeArchive node requiredYesYesYeseth_getLogs on public RPCYesNoYesFinality modelL1 slot finalityPoSA block finalityL2 sequencer + L1 confirmationPrimary RPC bottlenecketh_getLogs at scaleDisabled on public endpointsSequencer latency + L1 finality tracking The right chain for an RWA protocol is not purely a TVL or fee decision. It is an infrastructure decision. Ethereum’s archive requirements and log indexing demands are the price of operating on the most liquid and institutionally trusted network. BNB Smart Chain’s public endpoint restrictions make managed RPC non-negotiable from the first line of production code. Arbitrum’s sequencer model adds an L1 finality tracking layer that protocols need to account for when legal settlement thresholds are involved. Each chain has a distinct operational profile and your RPC infrastructure needs to match it. Best practices for RWA RPC infrastructure Dedicated private RPC endpoints are not optional for production RWA workloads. Public endpoints offer no data residency guarantees, which creates jurisdictional problems when regulators require logs to be stored and processed in specific regions. Beyond residency, dedicated endpoints give you predictable rate limits, SLA-backed uptime, and isolated infrastructure that does not degrade when another tenant spikes their call volume. For compliance-critical event monitoring, WebSocket connections should be configured with automatic reconnection logic. A dropped eth_subscribe connection on BNB Smart Chain or Arbitrum can mean missing several blocks worth of Transfer and ComplianceCheck events before your indexer recovers, and in a regulated context that gap has legal implications. On the node side, archive access with redundancy is the baseline for any protocol that needs to reconstruct historical asset state. Running a single archive node with no failover is an audit risk as much as an uptime risk. Chain upgrades also deserve active monitoring rather than reactive patching. Ethereum’s upgrade cadence directly affects execution client behavior and available RPC methods. Arbitrum’s ArbOS releases can change sequencer behavior in ways that affect how quickly RPC responses reflect confirmed state. Staying ahead of these changes is part of operating compliant RWA infrastructure, not an afterthought. For teams building on top of these standards, Chainstack’s open-source rwa-sdk provides a unified Python interface for querying RWA tokens across EVM chains, handling blocklist checks, KYC registry lookups, ERC-1404 restrictions depending on the protocol, all via direct eth_call with no indexer dependency. from rwa_sdk import RWAChain rwa = RWAChain(rpc_url="https://ethereum-mainnet.core.chainstack.com/YOUR_KEY") # Unified compliance check — works across any supported token check = rwa.can_transfer("USDY", sender, receiver) print(check.can_transfer) # True/False print(check.method) # ComplianceMethod.BLOCKLIST print(check.restriction_message) # "sender is on the blocklist" Conclusion RWA infrastructure failures are not like typical Web3 outages. A missed compliance event or a dropped NAV update does not just affect user experience, it affects the legal integrity of the asset itself. The chain you deploy on determines which RPC methods you depend on, where those methods hit limits, and how much infrastructure you need to run reliably underneath them. Ethereum demands archive access and high-throughput log indexing. BNB Chain forces dedicated RPC from day one. Arbitrum adds L1 finality tracking on top of a full EVM method set. None of these are problems you can solve at the application layer. As RWA volumes grow and more institutional issuers bring regulated assets on-chain, the gap between protocols running on managed dedicated infrastructure and those relying on public endpoints will become increasingly visible. Getting the RPC layer right is not an infrastructure concern you revisit after launch. For regulated assets, it was always a day one requirement. Dedicated archive nodes for Ethereum, BNB Smart Chain, and Arbitrum with full eth_getLogs access and archive depth from genesis are available on Chainstack. Deploy a dedicated RWA node on Chainstack → FAQ Does eth_getLogs work on BNB Chain public endpoints? No. eth_getLogs is not available on most public BNB Chain mainnet endpoints — this is a hard restriction, not a rate limit issue. Any RWA protocol that relies on event indexing for compliance or settlement monitoring requires dedicated RPC access on BNB Chain from day one. Do RWA protocols need archive nodes? Yes, for all three chains covered here. Archive access is required for eth_getStorageAt at historical blocks (used in NAV reconstruction and proof-of-reserve verification), debug_traceTransaction for regulatory audit trails, and any query that reconstructs asset state at an arbitrary past block. Running without archive access makes historical reporting and on-chain audits unreliable. What RPC methods does ERC-3643 require? ERC-3643 depends on eth_call for synchronous identity registry checks on every transfer simulation, and eth_getLogs for indexing ComplianceCheck and Transfer events across both the token contract and the identity registry. Because these are separate on-chain components, an indexer watching only the token contract can miss registry updates that affect transfer eligibility. Why do RWA protocols need dedicated RPC endpoints? Public endpoints fail RWA workloads in three predictable ways: rate limits get hit during oracle update windows, nodes under shared load inconsistently prune event logs causing silent ComplianceCheck drops, and there are no data residency guarantees — which creates jurisdictional problems when regulators like the SEC or BaFin require logs to be stored and processed in specific regions. What is the difference between Ethereum and Arbitrum for RWA settlement? Ethereum settles via L1 slot finality — once an Ethereum block is finalized, reversal requires a catastrophic validator failure. Arbitrum adds a sequencer layer: transactions are processed by a central sequencer before being batched to L1, so the effective settlement threshold for RWA protocols is L1 confirmation of the batch, not sequencer inclusion. Protocols that treat legal settlement as tied to on-chain finality need to track arb_getL1Confirmations alongside standard block tags. How often do RWA oracle updates happen, and why does that matter for RPC? NAV updates for tokenized treasuries, real estate funds, and private credit instruments are typically pushed once daily or weekly — not continuously. The requirement is not high frequency, it is guaranteed delivery during a narrow window. If an RPC connection drops during the one window a custodian attempts to push a NAV update, the fund becomes untradable until the state is corrected. This is why connection reliability matters more than raw throughput for RWA oracle infrastructure. Can RWA protocols run on a single archive node without failover? Technically yes, but it is an audit risk as much as an uptime risk. A single archive node with no redundancy means any downtime during a compliance event, NAV update, or regulatory reporting window creates a gap in your on-chain record. For regulated assets, infrastructure availability is part of the compliance posture, not a separate operational concern. Additional resources EVM nodes: full nodes vs. archive nodes Archive nodes: Ethereum, BNB Chain, Arbitrum and more How to get a BNB Smart Chain RPC endpoint Getting logs and events of EVM smart contracts chainstacklabs/rwa-sdk #### RPC poisoning: How the Kelp DAO $290M exploit happened In April 2026, Kelp DAO experienced an exploit, due to an RPC attack, that resulted in the loss of 116.5k rsETH (worth $290 million at the time).  rsETH is a liquid-staking token pegged 1:1 to Ethereum and deployed across more than 20 networks, including Base, Arbitrum, Linea, Mantle, and Scroll. Crypto holders can deposit ETH to Kelp DAO smart contracts across 20+ chains and then receive an equivalent amount of rsETH. Unlike commonly perceived attacks, the exploit was not due to a vulnerability in Kelp DAO or other protocol smart contracts. Instead, it was a direct attack on the infrastructure that orchestrated cross-chain rsETH transactions. Kelp DAO used LayerZero, a cross-chain messaging protocol, to manage rsETH across several chains. Attackers exploited this system by “poisoning” and manipulating the RPC API responses LayerZero relied on for deposit verification, leading the APIs to provide data suggesting the attacker had 116.5k rsETH on Unichain. The attacker requested a transfer of 116.5k rsETH from Unichain to Ethereum. Since the system trusted this manipulated data, it mistakenly believed the attacker had sufficient rsETH to proceed, causing Kelp DAO to transfer rsETH to the attacker’s Ethereum wallet. Earlier today we identified suspicious cross-chain activity involving rsETH. We have paused rsETH contracts across mainnet and several L2s while we investigate.We are working with @LayerZero_Core, @unichain, our auditors and top security experts on RCA. We will keep you…— Kelp (@KelpDAO) April 18, 2026 The exploit exposed multiple risks that are not commonly discussed in the web3 space, including RPC “poisoning.”  RPC attacks are an underappreciated but growing attack vector in Web3. As DeFi protocols increasingly rely on cross-chain infrastructure, the security of RPC nodes — the communication layer between applications and blockchains — has become a critical but often overlooked concern. This article explains crypto RPC attacks, how they work, including examples, and how to prevent them. The Kelp DAO rsETH attack On April 18, 2026, Kelp DAO, a major Ethereum liquid restaking protocol, was drained of 116,500 rsETH, valued at around $290 million at that time, in a single transaction exploiting the bridge infrastructure. A snippet of the transaction details of the Kelp DAO rsETH exploit on Ethereum on Etherscan The attacker, preliminarily attributed to the Lazarus Group based in North Korea, targeted the LayerZero Decentralized Verifier Network (DVN), which verified cross-chain messages for Kelp DAO rsETH. They compromised two of the RPC nodes the DVN relied on, leading them to return data suggesting the attacker had 116.5k rsETH on Unichain, when it did not. It also made denial-of-service attacks on the other nodes offline to ensure that no other nodes could reference the actual blockchain state that the attack did not have rsETH. After the attack, the attacker distributed the funds across several wallets, deposited all rsETH into Aave V3 as collateral, and borrowed ETH at roughly 99% effective Loan-to-Value. They chose this route because there was insufficient DEX liquidity to swap 116,500 rsETH for ETH without the price collapsing, and redeeming rsETH directly through Kelp DAO’s smart contracts was no longer an option once the team froze the protocol. Borrowing against rsETH allowed the attacker to obtain real ETH while leaving unpegged rsETH as collateral on Aave.  As a result, Aave is left holding bad debt worth 116,500 ETH. A graphic explaining the rsETH exploit. Credit: Suhail Kakar of Polymarket What is an RPC? How are RPCs used in crypto? Remote Procedure Call is a widely used, lightweight communication protocol that allows a program (client) to communicate with a remote program (server). In blockchain, specifically, an RPC node is a server that connects to a blockchain, listens for blockchain activity, and serves requests so that software applications can query blockchain data and submit new transactions. An example of an Ethereum node that I deployed via the Chainstack Console An RPC URL is the network endpoint or API URL for this interface, so software applications know where to send requests. Here’s a format example of an RPC URL for accessing the node that I deployed on Chainstack Console: https://ethereum-mainnet.core.chainstack.com/xxxxxxx-xxxxxx-xxxxx Kelp DAO used LayerZero, a cross-chain protocol, to monitor ETH deposits, verify them, and send a signed attestation before Kelp DAO smart contracts trigger a release of rsETH. In turn, LayerZero uses RPCs to listen for message requests sent to its smart contracts and to send messages across various blockchains. In the case of the Kelp DAO rsETH attack, attackers identified the list of RPCs LayerZero was using and attempted to “poison” them. Generally, an RPC provider list isn’t considered sensitive information. Knowing the RPC providers used is not enough to attack them, but in this case, there were vulnerabilities in the RPCs that LayerZero relied on that led to the exploits. In the upcoming sections, we’ll discuss how to better secure RPCs and protect against RPC attacks, rather than merely “hiding” a list of RPC providers you use. What is an RPC Attack? Many applications treat RPC responses as the “truth” to blockchain data. An RPC attack targets this trust assumption and interferes with the data returned by the RPC that applications rely on. RPC Poisoning  Attackers proceeded to “poison” the RPCs that LayerZero relied on, and ultimately used to manage rsETH.  RPC poisoning involves alternating the data returned by an RPC endpoint so that applications read an incorrect view of the blockchain state. The attackers were able to access two independent, unconnected nodes and swap out the binaries, effectively running a different version of the blockchain than the current state, one where the attacker had 116.5k rsETH on Unichain.  Rate-limiting and denial-of-service (DDoS) attacks  Rather than returning false data, an attacker can overwhelm an RPC endpoint, rendering it unavailable. For applications that rely on a single RPC, downtime can stall transaction processing, block liquidations, or create time-sensitive failures that attackers exploit through other means.  In the Kelp DAO attack, the attackers DDoSed the fallback (backup) RPCs, leaving the two poisoned nodes as the only source of truth. Other types of RPC attacks Malicious or compromised RPC endpoints Attackers can control the RPC itself, for example, by redirecting users to an endpoint that mimics the real service. Front-running and transaction censorship by RPC operators A compromised or malicious RPC provider can review submitted transactions and act on them before they reach the mempool. This allows for front-running, censorship, or sharing transaction data with third parties capable of front-running.  Such attacks are especially harmful for MEV-sensitive transactions like DEX swaps, liquidations, and arbitrage, as the RPC operator gains visibility of the transaction earlier than the public mempool. Man-in-the-middle (MITM) attacks on RPC connections Even when the RPC endpoint itself is legitimate, an attacker positioned between the application and the RPC can intercept and modify responses in transit. RPC connections made over plain HTTP rather than HTTPS are especially exposed to this attack vector, because the traffic is not encrypted and can be rewritten before it reaches the application. How to Prevent RPC Attacks Not every RPC attack is fully preventable, but several methods can help mitigate them. Some suggested that the Kelp DAO’s LayerZero setup could have had more redundancy, though LayerZero has not made it clear if it would have. KelpDAO used LayerZero’s Decentralized Verifier Network (DVN) set to the default option that uses a single validator to verify messages. A single validator that uses false RPC data is a clear point of failure. Using multiple validators could reduce this risk if they rely on independent RPC sources, since conflicting data would expose inconsistencies. However, it does not seem that different DVNs use distinct RPCs, so the failure points remain. Despite this limitation, many are advocating for teams using DVN to use more than one validator to validate cross-chain messages. A Dune analysis showed that 47% of OApp contracts (those that serve as the basis for using LayerZero DVN) use one-validator DVNs, 45% use two, and 5% use three or more. Following the KelpDAO hack, we built an open analysis of DVN security configurations across every active OApp on LayerZero over the last 90 days.Of ~2,665 unique OApp contracts: 47% run a 1-of-1 DVN security floor, 45% run 2-of-2, and ~5% run 3-of-3 or higher.As we know,…— Dune | We Are Hiring! (@Dune) April 20, 2026 Use multiple RPC providers Using multiple RPC providers, ideally from different operators running on different infrastructure, reduces the likelihood that a single compromise can corrupt the data an application sees. Chainstack operates its own managed infrastructure and gives you distinct types: A Global Node is a highly scalable public network node infrastructure accessed through your exclusive endpoint. With an elastic node, you pay for JSON-RPC requests to the node and do not pay for the compute and storage resources used by the node. A Dedicated Node is a public network node deployed exclusively for you. With a dedicated node, you pay for the compute and storage resources it uses, but not for JSON-RPC requests to it. A Self-Hosted Node lets you run the node in your own environment while still using Chainstack’s control plane to deploy, manage, and monitor it. Quorum agreement across RPCs Quorum agreement is the practice of querying multiple RPCs for the same data, such as a wallet balance or a transaction receipt, and proceeding only when a majority of providers return matching results. In practice, this means querying at least three independent providers and requiring two of three to agree before proceeding. If one provider returns a conflicting result, the application should either halt and alert or fall back to manual verification. This approach would have directly mitigated the Kelp DAO attack: even with two poisoned nodes, a third clean node would have exposed the discrepancy. Access Control Applying access controls, such as authentication tokens, IP allowlists, and network-level restrictions, limits who can query the RPC and, more importantly, who can reach the underlying node for administrative purposes.  In the KelpDAO exploit, the attacker swapped out the binaries running the op-geth nodes, indicating that the RPCs were reachable at a level that allowed binary replacement. All nodes deployed on Chainstack include password-protected access endpoints.  All nodes can be configured with additional access rules, including allowing traffic from only trusted HTTP Origin header values or specific IP addresses. Learn more about access rules. 💡 Also recommended: How to secure your RPC endpoints with access rules Aftermath The Ethereum community moved quickly to mitigate the risk of the exploit. rsETH transactions were frozen across multiple exchanges and lending platforms, including on Aave.  Update on rsETH incident:rsETH reserves have been paused across Ethereum Core, Arbitrum, Base, Mantle, and Linea.This was done with the objective of recovering additional funds as the recovery plans progress.We will keep the community updated on the next steps as the…— Aave (@aave) April 23, 2026 The Arbitrum Security Council approved a vote to freeze 30,766 ETH held in an attacker-controlled address on Arbitrum, which moved the funds to a frozen wallet that the attacker can no longer access pending further governance action. Several foundations and teams are loaning or donating ETH to Aave to help cover the bad debt created when the attacker borrowed ETH against rsETH collateral that no longer holds its peg, including: Mantle (to loan Aave 30,000 ETH at LIDO +1% APR) Etherfi (5,000 ETH) Golem (1,000 ETH) Lido (2,500 stETH. stETH is a liquid staking token pegged 1:1 to Ethereum, issued by the Lido protocol in exchange for ETH that users stake through it) Conclusion The Kelp DAO exploit demonstrated that smart contracts are only as secure as the infrastructure they depend on. Although the smart contracts themselves were not vulnerable, the infrastructure used to verify cross-chain messages was exploited, resulting in a $290 million attack. Preventing this type of attack requires removing the single points of failure at every layer of the trust chain. Using multiple RPC providers with quorum agreement across them, running multiple independent DVNs with distinct RPC sources, and applying strict access controls to RPC nodes are no longer optional engineering choices for protocols managing hundreds of millions in cross-chain TVL. To add Chainstack as an additional RPC provider and strengthen redundancy in your infrastructure, go to Chainstack to get started. Add Chainstack as your RPC provider → FAQ What is RPC poisoning in crypto? RPC poisoning is an attack where malicious actors manipulate the data returned by an RPC node, causing applications to read an incorrect view of the blockchain state. Instead of seeing real on-chain data, the application acts on fabricated information supplied by a compromised node. How did the Kelp DAO $290M exploit happen? Attackers compromised two RPC nodes used by LayerZero’s DVN to verify cross-chain messages for Kelp DAO. The poisoned nodes returned false data suggesting the attacker held 116,500 rsETH on Unichain. The DVN trusted this data, attested the message, and Kelp DAO released the funds to the attacker’s Ethereum wallet. What is a DVN in LayerZero? A Decentralized Verifier Network (DVN) is a set of validators that verify cross-chain messages for protocols built on LayerZero. DVNs rely on RPC nodes to check the blockchain state before attesting a message. If those RPC nodes are compromised, the DVN can be tricked into validating fraudulent transactions. What is quorum agreement for RPC nodes? Quorum agreement means querying multiple independent RPC providers for the same data and only proceeding when a majority return matching results. For example, with three providers, at least two must agree before the application acts. This prevents a single compromised node from corrupting the data an application relies on. What types of RPC attacks exist in Web3? The main types are: RPC poisoning (returning false blockchain data), DDoS attacks (overwhelming nodes to make them unavailable), man-in-the-middle attacks (intercepting unencrypted HTTP traffic), front-running by malicious RPC operators, and endpoint spoofing (redirecting users to fake RPC services). How can DeFi protocols protect against RPC attacks? Key mitigations include using multiple RPC providers from independent operators, implementing quorum agreement across providers, applying strict access controls such as IP allowlists and authentication tokens, running multiple independent DVNs with distinct RPC sources, and ensuring all RPC connections use HTTPS rather than plain HTTP. Related Reading How to secure your RPC endpoints with access rules on Chainstack  Chainstack Access Rules Demo 5 essential factors for setting up RPC node endpoints Resources LayerZero Incident Statement on Kelp DAO Kelp DAO Incident Response Further Context QuillAudits Hack Analysis – Kelp DAO rsETH $292 Bridge Exploit Explained LayerZero OApp DVN Configuration – Dune Dashboard #### Run blockchain nodes you actually own — now on Vultr We’re partnering with Vultr — one of the world’s largest independent cloud providers, operating 33 cloud data center regions across six continents and reaching 90% of the world’s population within 40ms. Chainstack Self-Hosted is now live on the Vultr Marketplace as Chainstack Blockchain Management — a one-click application that installs our Kubernetes-native control panel for deploying and managing blockchain nodes on infrastructure you control. Spin up a Vultr instance, install the app, and you’re deploying nodes minutes later. The Free Community tier is unlocked by default — unlimited nodes with basic monitoring at no extra cost on top of your Vultr bill. What you’re getting Chainstack Self-Hosted on Vultr gives you: Self-healing and auto-updates — nodes recover from failures automatically, with built-in high-availability options. Ethereum mainnet, Sepolia, and Hoodi testnets — pick the network and node type, snapshots speed up the initial sync. More networks rolling out. Monitoring and observability — built-in health tracking, configurable alerts, observability-ready metrics. Right-sized configurations — protocol-specific recommendations that improve stability and cut waste. Global footprint — deploy in any of Vultr’s 33 regions, from Tokyo to São Paulo to Frankfurt. Put nodes next to your users, not in someone else’s default region. Built for DeFi infrastructure, Layer 2 solutions, AI agents on-chain, and any production app that needs reliable RPC access without DIY node management — at the latency profile your users actually care about. Unlimited RPC setup for less than $100/month Chainstack Self-Hosted on Vultr is one-click via the Marketplace. For testnet workloads (Hoodi), the smallest Vultr instance that fits the Chainstack control plane and a node starts at $96/month ($0.132/hour) — pick any of Vultr’s 33 regions and you’re up. The Chainstack control plane on top runs on the Free Community edition — unlimited nodes, basic monitoring, no Chainstack license fee. You only pay Vultr for the box you pick. New Vultr accounts can also grab credits from Vultr’s coupon page toward the bill. No credit commitment. No enterprise sales call. No request-a-demo form. Just provision, install, deploy. For Ethereum mainnet, size up to a Storage Optimized or Bare Metal plan with 2 TB+ NVMe — see the full Chainstack Self-Hosted requirements for sizing. Same control plane, same workflow, just a bigger box. Try Chainstack Self-Hosted on Vultr → About Vultr Vultr is an independent cloud computing company offering on-demand cloud compute, bare metal, GPU, Kubernetes, and storage across 33 data center regions on six continents. Founded in 2014, Vultr is built as a flexible, no-lock-in alternative to hyperscaler clouds — transparent pricing, standardized infrastructure across every region, and pay-as-you-go billing. Connect with us Join our Discord, Telegram, and follow us on X Sign up for a free Developer account or explore our plans here Learn more about Chainstack Self-Hosted Want to run production-grade blockchain nodes on your own infrastructure? Explore Chainstack Self-Hosted → #### Running your own Base node: stablecoins and AI agents Running a Base node yourself has historically been a commitment. The client stack itself wasn’t the exotic part — Base is EVM, and until recently it was standard OP Stack: op-node for consensus, op-geth or op-reth for execution, both well-understood. The commitment was everything around them: hardware provisioning at OP Stack sizing, a synced Ethereum L1 endpoint feeding derivation, days of initial sync, monitoring, updates every time OP Stack or Base shipped a hard fork. Teams running USDC settlement, Coinbase-adjacent wallet infrastructure, DeFi on Aerodrome or Morpho, or the wave of AI-agent platforms building on Base did this because they had to — the value of full control over broadcast, mempool visibility, and independent read-side latency outweighed the DevOps cost. Teams without those requirements didn’t. Two things have changed since. First, Base itself is now moving off the distributed OP Stack layout onto a unified base/base client stack — base-consensus and base-reth-node, shipped as one release channel from one repo — which collapses the coordination overhead that used to sit between Base engineers and OP Labs / Flashbots / Paradigm on every upgrade. Second, Chainstack Self-Hosted now supports Base Mainnet on that same base/base stack, which means the operational layer around the node — deployment, monitoring, self-healing — becomes software you consume rather than a stack you build. This piece is about who actually benefits from a Base node on their own infrastructure, what running one looks like day-to-day, and how the newer answer compares to the older one. Why running a Base node used to be a project Base is Coinbase‘s Ethereum L2 and, by mid-2026, the largest chain in the OP Superchain by TVL (~$4.5B). It settles the majority of onchain USDC transfer volume, hosts the majority of x402 agentic-payment traffic, and processes roughly 12–13 million daily transactions. When you run your own Base node, you get the same feature set every serious operator in that flow does: Full JSON-RPC and WebSocket surface — HTTP RPC on port 8545, WS on port 8546. All standard Ethereum methods work unchanged, plus the optimism_* namespace for rollup-specific queries like optimism_syncStatus. Rollup RPC access — the consensus client (base-node / base-consensus) exposes rollup HTTP RPC on port 9545 for derivation state and sync introspection that shared providers rarely expose. Flashblocks preconfirmations — Base ships 200 ms sub-block ordering via Flashblocks. Applications reading eth_getBlockByNumber with the "pending" tag get inclusion signals ~10× faster than waiting for a sealed 2-second block. Latency-sensitive workloads (liquidations, arbitrage, agent payments) care about which endpoint surfaces this and how quickly. Direct transaction broadcasting with propagation control — your eth_sendRawTransaction calls hit the sequencer from your own peer set rather than queueing behind an unknown shared-endpoint tenant. Independent read finality — for an app that resolves settlement against Base state, “we ran the query against our own node” is a materially different answer to auditors and to internal risk than “we called someone’s RPC.” Unlocking that on your own infrastructure historically meant assembling the ops layer around the client stack yourself: provisioning ~3.5 TB of NVMe, wiring in an Ethereum L1 RPC and a Beacon API endpoint for derivation, waiting for the sync, setting up monitoring, tracking OP Stack releases, and — as of 2026 — planning the migration from op-node + op-geth to base-consensus + base-reth-node before Base V1 activates on mainnet. Legacy op-node + op-geth and Nethermind configurations stop syncing with the canonical chain after that boundary. The teams that took all that on did so for very specific reasons — worth naming, because that’s where the case for a self-hosted Base node actually lives. Who actually runs their own Base node, and why Stablecoin payment processors and Base Pay merchants. USDC on Base is native (issued directly by Circle, no bridge assumption), and Base has become the highest-velocity chain for USDC by a wide margin. USDC’s annualized velocity now sits at 741x, ten times USDT’s 74x, according to Coin Metrics’ State of the Network Issue 376 (Aug 2026). As of August 2026, USDC has settled $32T in transfer volume in 2026 alone — 77% of total stablecoin market volume. On Base specifically, more than 90% of USDC transfer volume traces to just three contracts: DEX liquidity provision on Aerodrome (69%) and flashloan activity through Morpho (23%), with a single day in June seeing flashloan volume exceed $500B. Base Pay’s Shopify integration runs on USDC. Circle launched native EURC on Base in July 2026, adding a MiCA-compliant euro rail alongside the USDC one. When your business is confirming and settling stablecoin payments in seconds, watching the mempool from your own node isn’t a nice-to-have — it’s how you actually know whether a payment landed before you release goods. AI agent platforms and x402 operators. Coinbase and Cloudflare’s x402 protocol turns HTTP status code 402 into an actual payment negotiation layer — an agent hits a paid endpoint, gets back a payment challenge, pays in USDC, gets the resource. As of April 2026, x402 had settled over 167 million transactions with 85% on Base, per Base team data (the mix has shifted since — Solana emerged as a large share of x402 volume by mid-2026, when the x402 Foundation moved under Linux Foundation governance — but Base remains a primary settlement layer). Foundation members now include Coinbase, Cloudflare, Google, Visa, AWS, Anthropic, Circle, Stripe, Shopify, and Mastercard. Platforms like Virtuals Protocol (Base-native, launched in October 2024) run AI agents that hold their own wallets, transact autonomously, and settle in USDC on Base in ~2 seconds. Agent workloads are bursty and highly parallel — see Chainstack’s guide on blockchain RPC for AI agents — and they break shared-RPC rate-limit envelopes fast. Teams operating agent fleets at any scale run their own nodes. Consumer wallets and smart-wallet infrastructure. Coinbase Smart Wallet — rebranded as the Base App in July 2025 as Coinbase’s “everything” app for onchain — passed 1 million Smart Wallet accounts by August 2025, with roughly 270K accounts created in a single day at peak. That’s a lot of ERC-4337 UserOperation traffic, eth_estimateGas calls, and paymaster interactions — none of it cheap on a shared endpoint. Wallet infrastructure teams that used to run one Ethereum node now typically also run their own Base node to keep smart-wallet UX responsive. DeFi protocols on Base. Aerodrome Finance — Base’s dominant DEX, historically the majority of the chain’s DeFi TVL — plus Morpho lending on Base, Aave v3 on Base, and dozens of perp and options protocols. Coin Metrics’ Issue 351 found that roughly half of the January 2026 USDC transfer surge on Base traced to DeFi infrastructure activity — LP rebalancing on Aerodrome, Morpho flows, flash-loan arbitrage — rather than end-user payments. Either way, that’s DeFi infrastructure generating stablecoin traffic in its own right. Application logic that depends on chain state can’t tolerate a shared provider’s latency envelope, and any Base DeFi protocol at scale — see Chainstack’s guide on Base RPC for DeFi — needs eth_getLogs, WebSocket subscriptions, and debug_traceTransaction access that shared tiers rate-limit hard. Coinbase-adjacent custody and institutional operations. Base is Coinbase’s own L2. Coinbase Custody via Coinbase Prime, the Coinbase International Exchange, and every institutional integration that touches Base assets runs the associated infrastructure at Coinbase-internal scale. Beyond Coinbase itself, prime brokers and custodians serving clients with Base-native positions (BitGo, Fireblocks integrations) do the same — auditors don’t accept “we trust a third-party RPC” as a control for customer asset movement. Analytics, compliance, and indexing platforms. Chainalysis, Elliptic, and specialist Base indexers all run their own Base nodes at scale for transaction tracing, compliance monitoring, and pre-built analytics. Any platform in the business of serving Base data as a product needs full and direct access to the chain, typically across multiple nodes for redundancy plus indexed databases on top. At a glance: AudienceUse caseWhat running your own unlocksExamplesStablecoin payment processorsAccept USDC on Base at scale, run merchant checkoutControllable broadcast, real-time confirmation, mempool-accurate gas estimationBase Pay, Shopify integration, merchant processorsAI agent platforms and x402 operatorsAutonomous agents transacting in USDC via x402Direct RPC for burst workloads, no shared rate-limit envelope, Flashblocks preconfirmationsVirtuals Protocol, Coinbase AgentKit apps, x402 servicesConsumer wallets and smart-wallet infraServe Coinbase Smart Wallet / ERC-4337 trafficDedicated bandwidth for UserOp / paymaster / bundler workloads, low-latency eth_estimateGasCoinbase Smart Wallet, Base App, wallet SDKsDeFi protocols on BaseDEX, lending, perps, optionsFull log subscriptions, debug_traceTransaction, WebSocket event streamsAerodrome, Morpho, Aave, Uniswap on BaseCoinbase-adjacent custody & institutionsInstitutional custody of Base assetsAudit-defensible chain of trust, rate limits that hold at institutional scaleCoinbase Custody, BitGo, Fireblocks integrationsAnalytics, compliance, indexersServe Base data as a productMulti-node redundancy, archive access, custom indexer feedsChainalysis, Elliptic, specialist Base indexers The pattern across all of these: when Base data is load-bearing for your business — stablecoin settlement, agentic payments, wallet UX, DeFi state, custody — you don’t rent it. What running your own actually costs The operational reality of a Base node is more pragmatic than the “sovereign L2” version. It’s heavier than a Bitcoin node, comparable to Optimism, and lighter than a Polygon PoS full node. Costs are predictable enough to plan around, but there are a few Base-specific twists. The OP Stack twist: you need an L1 endpoint. This is the fact of life that separates Base from a standalone L1 like Bitcoin or TRON. base-consensus derives Base state from Ethereum by reading batches posted to L1 — so you need an Ethereum Mainnet RPC endpoint and a Beacon API endpoint feeding the node continuously. Either you run your own Ethereum L1 alongside your Base node (in which case you’re now operating two chains’ worth of infrastructure), or you point Base at a managed Ethereum RPC. Chainstack’s Self-Hosted Ethereum Mainnet or a managed Ethereum endpoint both work — the point is it’s not optional and it’s not free. Initial sync. Base processes roughly 12–13 million transactions per day and has been running since August 2023. A clean sync from genesis takes days on good hardware — the execution client replays every transaction and rebuilds state as it goes. Unlike Chainstack Self-Hosted Ethereum Mainnet and Optimism Mainnet, which bootstrap from pre-built snapshots, Base currently syncs without a snapshot preset, so plan for a multi-day initial sync window. That’s the honest read as of mid-2026; snapshot bootstrap for Base is the kind of thing that could land in a future Self-Hosted release, but it’s not there today. Storage growth. ~3.5 TB steady-state for a Base full node, growing steadily as the chain processes ~12M tx/day. Plan for 5+ TB of storage headroom if you want to avoid resizing within the first year. NVMe strongly preferred over SATA SSD — Base’s 2-second block cadence (200 ms with Flashblocks) generates enough write pressure that slower disks become a bottleneck. Updates and the base/base migration. Base historically shipped ~3 hard forks per year on the OP Stack schedule. Under the new base/base architecture it’s targeting 6 upgrades per year in smaller batches. That’s a faster cadence, and the immediate operational implication is real: Base V1 is the hard migration boundary. After V1 activates on mainnet, legacy op-node + op-geth and Nethermind configurations no longer sync with the canonical chain. Sepolia already activated V1 on 2026-04-20 at 18:00 UTC; Base V1 / Azul activated on mainnet May 13, 2026, and Beryl followed. The base/base stack is what all production nodes run today. If you’re running a Base node yourself, this is the migration you’re planning right now — or the reason you’re reading this piece. Monitoring and reliability. Sync drift happens. Peer connections degrade. The L1 endpoint you’re depending on for derivation can throttle or fall behind, which quietly stalls your Base node’s rollup sync without anything obvious in the execution client logs. Disk fills up. Without monitoring, you find out something is wrong because a USDC transfer failed to confirm or a wallet timed out on eth_estimateGas. With monitoring, you find out because an alert fires before customers notice. The “run it and forget it” myth. Plenty of Base nodes do run for weeks without intervention. They also drift out of sync silently, fall behind on hard forks, and become slowly less useful without anyone noticing — and now, with the base/base migration underway, they can silently fork off the canonical chain. For personal use, that’s fine. For production stablecoin settlement or agent traffic, it’s a quiet path to a broken Saturday. What changed: Chainstack Self-Hosted now supports Base The historical reason teams reached for shared RPC over self-hosting wasn’t that they wanted shared RPC — it was that the operational overhead of self-hosting a Base node, including the L1 dependency, was too high to justify unless you were already operating multiple chains’ worth of infrastructure. And even then, tracking the OP Stack release cadence across three upstream teams was its own tax. Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Base Mainnet on Base-Reth v1.1.0 + Base-Node v1.1.0 — the post-migration base/base stack — with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy. Control Panel install is one command (cpctl install) that finishes in 5–10 minutes on a fresh Ubuntu host — the operational layer that used to take a quarter to build lands in an afternoon. The Base node itself still needs its multi-day genesis sync, since Base doesn’t ship a snapshot preset yet. See the supported clients and protocols page for the current sizing matrix. A Base full node fits on 12 vCPU, 48 GiB RAM, and ~3.5 TB of NVMe storage. Same sizing as Optimism, Unichain, and Zora on the platform — that’s the OP Stack family baseline. See system requirements for the full matrix. The exposed endpoints are base-reth‘s HTTP JSON-RPC on port 8545, WebSocket on 8546, and base-node‘s rollup HTTP RPC on 9545. That’s the standard Ethereum JSON-RPC every SDK speaks, plus the rollup RPC for consensus/derivation introspection. Because Base is an OP Stack chain, the deployment requires you to supply an Ethereum L1 RPC endpoint and a Beacon API endpoint — the node uses them to derive Base state from L1. If you’re already running Ethereum Mainnet on Chainstack Self-Hosted, that’s the natural pairing. If not, a managed Chainstack Ethereum endpoint works. This isn’t a Chainstack quirk — it’s an OP Stack architectural fact — but it’s worth flagging upfront so you don’t spec out a Base deployment and discover the L1 dependency at deploy time. A few Base-specific caveats worth naming honestly, in the same spirit as the TRON write-up: Base doesn’t currently ship with a snapshot-bootstrap preset on Chainstack Self-Hosted. Only Ethereum L1 (Mainnet, Sepolia, Hoodi) and Optimism Mainnet in the OP Stack family have snapshot bootstrap out of the box. Base, Unichain, and Zora sync conventionally. Multi-day initial sync applies here. Check the supported deployments page for the current snapshot availability list. What you do get is Kubernetes-level self-healing: if a node pod crashes, the deployment automatically restarts it and resumes from the last state on the persistent volume. Client version updates through Base’s hard fork cycle currently require you to redeploy the node on the new base/base version yourself — Self-Hosted doesn’t auto-update client versions. Multi-endpoint failover to a Chainstack-managed Base node is on the roadmap but not yet shipped. You still own the node. The data never leaves your perimeter. You can SSH into the box and run standard eth_* calls, optimism_* calls, or curl against the rollup RPC exactly like any other base/base install. The difference is you didn’t build the deployment stack around it yourself. For managed Base endpoints — with Flashblocks-aware routing and geo-balanced global nodes — the counterpart is Chainstack’s managed Base offering, and the two coexist naturally: managed for the failover / bursty read path, Self-Hosted for the load-bearing hot path. When to self-host Base, and when not to The decision isn’t religious. It’s a workload question. Run your own Base node if: You’re settling USDC payments in production. Broadcast reliability, mempool visibility, and confirmation-timing arguments compound until they’re decisive. You operate an AI agent platform, x402 service provider, or agent fleet at any meaningful scale. Bursty, parallel agent workloads break shared-RPC assumptions faster than any human-driven traffic. You run wallet infrastructure serving Coinbase Smart Wallet / ERC-4337 traffic, a smart-wallet SDK, or an Account Abstraction bundler at scale. Your application makes more than a few hundred thousand RPC calls per day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput. You need Flashblocks preconfirmations, full log subscriptions, debug_traceTransaction, or archive-node-like historical access. Compliance, audit, or regulatory frameworks require infrastructure control over customer asset movements. Reach for a managed Chainstack Base endpoint if: You’re learning, prototyping, or running a low-volume side project. Chainstack Base nodes with a free Developer tier cover most of that scale without the setup. The Chainstack Base faucet covers testnet ETH for the dev loop. You only need occasional historical lookups or read-only analytics on Base data. You’re integrating a wallet or app that needs basic ERC-20 balance queries and transaction submission, without the burst profile of an agent fleet. You want Flashblocks-aware routing and geo-balanced endpoints without operating the node yourself The middle ground — production workloads that wanted their own Base node without committing to the full DIY stack including the L1 dependency — used to have no clean answer. DIY worked, but the setup and monitoring layer around base-reth and base-consensus was itself a quarter of DevOps work, and the OP Stack → base/base migration adds one more scheduled interruption on top. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon. And if you’re still weighing managed vs self-hosted more broadly, the Best Base RPC providers 2026 comparison covers the managed landscape across Chainstack, Alchemy, QuickNode, dRPC, and Ankr — including the same three workload profiles (stablecoins, DeFi, AI agents) this piece opened with. If your Base workload is heading toward “load-bearing for the business” — and given Base is now the largest OP Superchain member by TVL, the #1 chain by daily stablecoin transfer volume, and the settlement layer for the majority of x402 agent traffic, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t have to take a quarter anymore. Explore Chainstack Self-Hosted → FAQ How long does the initial Base node sync take? From genesis, several days on good hardware — the execution client has to replay every transaction Base has processed since August 2023 and rebuild state as it goes. Unlike Ethereum Mainnet and Optimism Mainnet on Chainstack Self-Hosted, Base doesn’t currently ship with a snapshot-bootstrap preset, so the multi-day sync from genesis is what to plan for today. Check the supported clients and protocols page for the current list of snapshot-enabled networks. How much storage does a Base full node need? ~3.5 TB steady-state, growing as the network processes ~12–13 million transactions per day. Plan for 5+ TB if you want to avoid resizing within the first year. NVMe is strongly preferred — Base’s 2-second block cadence (200 ms with Flashblocks) generates enough write pressure that SATA SSDs become a bottleneck, and rotational drives simply won’t keep up. Does the Base node on Chainstack Self-Hosted need an Ethereum L1 endpoint? Yes. Base is an OP Stack chain, and base-consensus derives Base state from Ethereum L1 by reading batches posted there. The deployment requires you to supply both an Ethereum L1 RPC endpoint and a Beacon API endpoint. Either point at your own Ethereum Mainnet node (Self-Hosted Ethereum Mainnet is a natural pairing), or use a managed Chainstack Ethereum endpoint. This is an OP Stack architectural requirement, not a Chainstack quirk. Does Chainstack Self-Hosted ship the post-migration base/base stack, or legacy op-node + op-geth? The post-migration stack — Base-Reth v1.1.0 + Base-Node v1.1.0, sourced from github.com/base/base. No op-node + op-geth legacy configuration; you’re on the client stack Base will require after V1 mainnet activation. See the Base migration guide for the full context on the OP Stack → base/base transition. Does Base V1’s proof system change (TEE + ZK) affect self-hosted nodes? Not directly — the proof-system change is an L1 verification concern, not a node-operator one. But it does change the risk math for any application that touches Base ↔ Ethereum withdrawals. Today, withdrawing assets from Base to L1 requires a 7-day challenge period during which fraud proofs can invalidate the state. Base V1 introduces TEE and ZK proofs alongside the optimistic proof, compressing that window substantially — exact finality times will be published by the Base engineering team closer to mainnet activation. If you’re building a bridge, a cross-chain settlement layer, or a treasury flow that assumes 7-day finality, that’s the assumption to revisit. Your self-hosted node itself doesn’t need any configuration change for this. See the Base migration guide for the full proof-system context. Does the Base node support Flashblocks? Yes. Flashblocks is part of the Base protocol, not a Chainstack feature — the node ships with it enabled. Applications get 200 ms sub-block inclusion signals by reading eth_getBlockByNumber with the "pending" tag. For a deeper walkthrough of Flashblocks and how it changes latency-sensitive workflows on Base, see the Flashblocks explainer. What endpoints does the Base node expose? The deployment exposes base-reth‘s HTTP JSON-RPC on port 8545 and WebSocket on port 8546 — the standard Ethereum interface every SDK speaks, including the optimism_* namespace methods like optimism_syncStatus. The base-node rollup HTTP RPC is exposed on port 9545 for derivation and sync introspection. The execution client’s auth RPC port (8551) is used internally between clients and is not exposed. See the supported clients and protocols page for the current port matrix. Is Base Sepolia supported on Self-Hosted? Currently Base Mainnet only on Chainstack Self-Hosted. For testnet development, the Chainstack Base faucet and managed Base Sepolia endpoints cover the dev loop. Additional networks may be added — check the supported clients and protocols page for the current list. What happens if my self-hosted Base node fails? Chainstack Self-Hosted ships with Kubernetes-level self-healing: if a node pod crashes, the deployment automatically restarts it and resumes from the last state on the persistent volume. Multi-endpoint failover to a Chainstack-managed Base endpoint is on the roadmap but isn’t available yet, so for now you’re on your own for diagnosing anything beyond a simple pod restart. Read more Chainstack Self-Hosted documentation: Introduction to Chainstack Self-Hosted Supported clients and protocols System requirements Quick start Installation Deploying nodes Managing nodes Monitoring Self-Hosted FAQ Chainstack Base products and guides: Base tooling docs Base chain migration: from OP Stack to base/base Best Base RPC providers for onchain applications in 2026 Flashblocks on Base: 200 ms preconfirmations How to get a Base RPC endpoint (2026 guide) Chainstack Base faucet Related reading: Running your own Bitcoin node: who needs one, when it pays off Running your own TRON node: infrastructure for the USDT rails Blockchain RPC for AI agents: infrastructure guide (2026) Self-hosted blockchain node: challenges and solutions #### Running your own Bitcoin node: who needs one, when it pays off Running a Bitcoin node yourself has historically been a commitment. You provision the hardware, install Bitcoin Core, configure txindex, wait days for the initial block download, set up monitoring, and then run the same cycle every time Bitcoin Core ships a new release. Teams with production Bitcoin workloads did this because they had to — the value of full control over broadcast, mempool visibility, and independent verification justified the DevOps cost. Teams without those requirements didn’t. The operational math has shifted. What made running a Bitcoin node hard was rarely Bitcoin itself — Bitcoin Core is stable, well-documented, and famously easier to operate than most Ethereum execution clients. The hard part was everything around the node: deployment, monitoring, self-healing, updates, failover. Chainstack Self-Hosted now supports Bitcoin Mainnet, which means that operational layer becomes software you consume rather than a stack you build. This piece is about who actually benefits from a Bitcoin node on their own infrastructure, what running one looks like day-to-day, and how the newer answer compares to the older one. Why running a Bitcoin node used to be a project Bitcoin Core is the reference implementation of the Bitcoin protocol. It’s what mining pools, exchanges, custodians, block explorers, and Lightning nodes all run under the hood. When you run your own node, you get the same feature set they do: ZMQ subscriptions for real-time mempool and block push notifications — no polling, no lag on new state. Direct transaction broadcasting with full propagation control. Your transaction enters the gossip network from your own peer set; you can watch propagation, rebroadcast, react to network conditions. Full mempool access. Every unconfirmed transaction, every fee bucket, every RBF replacement. estimatesmartfee runs against the same live data. Historical lookups via txindex. Any transaction, any block, indexed and queryable without depending on a third-party archive. Unlocking that feature set on your own infrastructure meant building the ops layer around Bitcoin Core yourself: procure hardware, install and configure the node, wait for the initial block download, stand up monitoring, hook up alerts, plan for updates, plan for failover. That’s the setup burden the article is really about. The teams that took it on did so for very specific reasons — worth naming, because they’re where the case for a self-hosted Bitcoin node actually lives. Who actually runs their own Bitcoin node, and why Payment processors. BitPay, Strike, OpenNode, NOWPayments — every meaningful BTC payment company runs its own nodes. The reasons compound. Broadcasting from your own node means you control transaction propagation and can re-broadcast aggressively if needed. Watching the mempool from your own node means double-spend detection works in seconds, not minutes. Fee estimation from your own mempool is more accurate than any third-party fee oracle because you’re seeing the same data Bitcoin Core’s estimatesmartfee is seeing locally. When the entire business is “we accept BTC payments and confirm them reliably,” none of this can be outsourced. Exchanges and custodians. Coinbase, Kraken, BitGo, Anchorage — every regulated entity holding customer Bitcoin runs its own nodes. Two reasons. First, regulatory: BitLicense, MiCA, and similar frameworks treat infrastructure control as part of operational risk management. An auditor asking “how do you independently verify your customer balances?” doesn’t accept “we trust BlockCypher’s API.” Second, scale: an exchange generating fresh deposit addresses for millions of users needs to derive addresses, watch them, and reconcile against the chain at a volume that breaks shared-RPC rate limits. Lightning Network operators. This one isn’t optional. A Lightning node — whether it’s LND, Core Lightning, or Eclair — requires a Bitcoin full node underneath. The LN client needs direct, low-latency access to a Bitcoin Core RPC, ZMQ feed, and (for many configurations) txindex enabled. There’s no “Lightning-as-a-service” that lets you skip the Bitcoin node; routing nodes, channel managers, and LSPs all run Bitcoin Core locally. Block explorers and analytics platforms. Mempool.space, blockstream.info, blockchain.com — these companies are in the business of serving Bitcoin data, which means they need full and direct access to it. They typically run multiple nodes for redundancy, plus indexed databases (Electrum servers, Esplora, custom indexers) on top. Same model applies to compliance analytics like Chainalysis and Elliptic. OTC desks and high-frequency trading firms. Latency on mempool data and transaction broadcast directly affects PnL. Watching a large transfer hit the mempool 200ms before competitors is enough edge to justify dedicated infrastructure. Corporate treasury and ETF custodians. The 2024–2025 wave of Bitcoin ETFs — IBIT, FBTC, ARKB — collectively custody hundreds of thousands of BTC. The custodians (Coinbase Custody, Fidelity Digital Assets, BitGo) verify balances against their own nodes. Same for corporate treasury holders: when you’re sitting on a billion dollars of BTC, “trust the block explorer” stops being a strategy. At a glance: AudienceUse caseWhat your own node unlocksExamplesPayment processorsAccept BTC payments reliably at scaleControllable broadcast, real-time double-spend detection, mempool-accurate fee estimationBitPay, Strike, OpenNode, NOWPaymentsExchanges & custodiansCustody customer BTC, generate fresh addresses at scaleAudit-grade infrastructure control, rate limits that hold at exchange scaleCoinbase, Kraken, BitGo, AnchorageLightning Network operatorsRun production LN routing or channel nodesDirect Bitcoin Core RPC, ZMQ feed, txindex enabled (required, not optional)LND, Core Lightning, EclairBlock explorers & analyticsServe Bitcoin data as a productMulti-node redundancy, custom indexer feeds, full historical accessMempool.space, blockstream.info, ChainalysisOTC desks & HFTLatency-sensitive arbitrage and broadcastSub-100ms mempool propagation, controllable broadcast pathOTC desks, market makers, prop trading firmsTreasury & ETF custodiansIndependent verification of large BTC holdingsAudit-defensible chain of trust without a third-party intermediaryCoinbase Custody, Fidelity Digital Assets, BitGo The pattern across all of these: when Bitcoin data is load-bearing for your business — payments, custody, settlement, trading — you don’t rent it. What running your own actually costs The operational reality is more pragmatic than the Bitcoin maximalist version. A Bitcoin full node is genuinely lighter than an Ethereum node in most ways. But it’s not free, and the costs are predictable enough to plan around. Initial sync. Bitcoin’s chain is around 750 GB as of mid-2026 and growing roughly 70–90 GB per year (about 6–7 GB per month). A clean initial block download from genesis takes several days even on good hardware — Bitcoin’s IBD is single-threaded for validation in important phases, and you can’t parallelize your way past the bottleneck. The mitigation is assumeUTXO snapshots: the loadtxoutset RPC was added in Bitcoin Core 26.0 and became usable on mainnet in 28.0, when AssumeUTXO mainnet parameters were added for height 840,000. You bootstrap from a recent verified state and sync the rest in hours instead of days. Most professional setups use snapshots now. Storage growth. Predictable, roughly linear at ~70–90 GB per year. Plan for 1 TB if you’re comfortable resizing within a few months; 2 TB if you want to stop thinking about disk for several years. Pruned nodes (which discard old blocks) cut this dramatically, but pruning kills txindex, which kills support for several use cases including most LN setups and any historical lookup workload. Updates. Bitcoin Core moves slower than Ethereum clients — major releases land roughly twice a year, security patches more often. But “slower” doesn’t mean “ignorable.” Soft forks (Taproot, the next round of consensus changes), wallet format migrations, mempool policy updates, BIPs that affect address types — all require eventually running newer versions. The schedule is gentler than Ethereum’s twice-yearly hard forks, but the operational discipline is the same. Monitoring and reliability. Sync drift happens. So do reorgs (rare on Bitcoin, mostly 1–2 block depth, occasionally deeper). Disk fills up. Connections to peers degrade. Without monitoring, you find out something is wrong because an application breaks. With monitoring, you find out because an alert fires. The difference between those two modes is what separates a hobby setup from infrastructure you’re willing to put a business on. The “set it and forget it” myth. Plenty of Bitcoin Core nodes do run for years without intervention. They also drift out of sync silently, miss security patches, fall behind on mempool policy, and become slowly less useful without anyone noticing. The “set it and forget it” version of self-hosting is real for personal nodes; for production it’s a quiet path to a broken Saturday. What changed: Chainstack Self-Hosted now supports Bitcoin Historically, running your own Bitcoin node meant building the full operational stack yourself. That’s what Chainstack Self-Hosted changes. Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Bitcoin Mainnet on Bitcoin Core 31, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy. You get the node running on hardware you own, with the control plane — deployment, snapshots that significantly reduce initial sync time, self-healing, auto-updates, monitoring through bundled Grafana and VictoriaMetrics — handled by Chainstack. The Bitcoin deployment is the lightest of any chain on the platform. A Bitcoin full node fits comfortably on 4 vCPU and 8 GiB of RAM — Bitcoin Core’s resource appetite is genuinely modest compared to Ethereum execution clients. Plus a fast disk: NVMe is strongly preferred over SATA SSD, and rotational drives won’t keep up with IBD or mempool throughput. Plan for 1 TB+ of storage with growth headroom. See the system requirements page for the full sizing matrix. The node ships with txindex enabled by default — so historical transaction lookups, Lightning Network compatibility, and indexer integrations work out of the box without needing to reconfigure and resync. The exposed endpoint is Bitcoin Core’s HTTP JSON-RPC on port 8332. See the supported clients and protocols page for the current configuration. Snapshot-assisted deployment significantly reduces the initial sync window — Chainstack’s Bolt is the patented snapshot tech behind the platform’s managed Bitcoin nodes, and the same operational thinking informs how Self-Hosted deployments come online quickly without genesis-up resyncs. The self-healing and auto-update layers handle the operational discipline most self-hosted setups quietly skip. Failover lets you route to a Chainstack-managed Bitcoin endpoint if your own node has issues, so you’re not choosing between “own infrastructure” and “production reliability” — you get both. You still own the node. The data never leaves your perimeter. You can SSH into the box and run bitcoin-cli against it like any other Bitcoin Core install. The difference is you didn’t build the deployment and operational stack around it yourself. When to self-host Bitcoin, and when not to The decision isn’t religious. It’s a workload question. Run your own Bitcoin node if: You’re accepting BTC payments in production. The fee estimation, double-spend detection, and broadcast reliability arguments compound until they’re decisive. You hold customer Bitcoin or BTC at corporate-treasury scale. You run a Lightning Network node of any meaningful size. (Required, not optional.) Your application makes more than a few hundred thousand RPC calls per day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput. You need ZMQ subscriptions, full mempool access, or txindex-dependent features. Compliance, audit, or regulatory frameworks require infrastructure control. Reach for managed Chainstack Bitcoin instead if: You’re learning, prototyping, or running a low-volume side project. Chainstack Global Nodes with a free Developer tier covers most of that scale without the setup. You only need historical lookups (a single block explorer API call now and then). Pay-per-call access through Chainstack’s Bitcoin tier is cheaper than running a full node for that pattern. You’re doing read-only analytics and the data is non-critical. The middle ground — production workloads that wanted their own Bitcoin node without committing to a full DIY setup — used to have no clean answer. DIY self-hosting worked, but the setup and monitoring stack around Bitcoin Core was itself a quarter of DevOps work. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon. If your Bitcoin workload is heading toward “load-bearing for the business,” running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t have to take a quarter anymore. Explore Chainstack Self-Hosted → FAQ How long does the initial Bitcoin node sync take? From scratch — several days, even on good hardware. Bitcoin Core’s initial block download has single-threaded phases that you can’t parallelize past. With assumeUTXO snapshots (supported since Bitcoin Core 27), you bootstrap from a recent verified state and bring the node fully current in hours instead. Chainstack Self-Hosted uses snapshot-based sync by default. Can I run a pruned Bitcoin node to save disk? Yes — Bitcoin Core supports pruning natively, and a pruned node keeps full validation while discarding old block data. The catch: pruning disables txindex, which kills several use cases. Lightning Network nodes need txindex on most configurations. Most analytics and historical lookups need it. Block explorers definitely need it. If you can live without those, pruning cuts storage to a few hundred GB. If you can’t, plan on a full node. Does this work for Lightning Network? Yes, with a caveat. A Bitcoin Core full node is exactly what every Lightning implementation (LND, Core Lightning, Eclair) needs underneath it. You’d deploy your Bitcoin node through Chainstack Self-Hosted with txindex enabled, then run your LN daemon of choice on top of it as a separate service. Chainstack Self-Hosted handles the Bitcoin layer; the LN layer is yours. For interacting with the Bitcoin node from your application code, see the Bitcoin tooling docs. Is Bitcoin testnet or signet supported? Currently Bitcoin Mainnet only. Additional networks may be added in future releases — check the supported clients and protocols page for the current list. What happens if my self-hosted Bitcoin node fails? Chainstack Self-Hosted ships with self-healing — most failures (sync drift, container restarts, transient peer issues) recover automatically. For harder failures, you can configure failover to a Chainstack-managed Bitcoin endpoint, so your application stays online while you investigate the box. You’re not choosing between “own infrastructure” and “production reliability.” What protocols are coming next to Chainstack Self-Hosted? The current Self-Hosted lineup beyond Bitcoin spans Ethereum (Mainnet, Sepolia, Hoodi), the OP Stack family (Optimism, Base, Unichain, Zora), Starknet, and TRON. Solana Mainnet and Devnet with the Agave client are explicitly listed as coming soon on the supported clients and protocols page. The page is the canonical place to check what ships next. What endpoints does the Bitcoin node expose? The deployment exposes Bitcoin Core’s standard HTTP JSON-RPC on port 8332. That’s the same interface bitcoin-cli and every Bitcoin Core SDK speaks, and it covers the bulk of integration patterns — transaction broadcasting, mempool queries, fee estimation, block and transaction lookups (with txindex enabled by default). For workloads that depend on push-based notifications via ZMQ — typically lower-latency LN setups, mempool watchers, MEV-style monitoring — check the current exposure options against the supported clients and protocols page and reach out if your use case needs more than HTTP JSON-RPC. Additional resources Chainstack Self-Hosted documentation: Introduction to Chainstack Self-Hosted Supported clients and protocols System requirements Quick start Installation Deploying nodes Managing nodes Monitoring Self-Hosted FAQ Chainstack Bitcoin products: Build better with Bitcoin Bitcoin protocol overview Bitcoin tooling docs Background reading: Self-hosted blockchain node: challenges and solutions Deploy blockchain nodes on your own infra: introducing Chainstack Self-Hosted External: Bitcoin Core project #### Running your own Polygon node: infrastructure for prediction markets Running a Polygon node yourself has historically been a commitment. Polygon PoS doesn’t run a single client the way Bitcoin, TRON, or Solana do — it runs two, paired together. Bor handles execution (it’s a modified go-ethereum client that produces and executes blocks), and Heimdall handles consensus — a Cosmos-SDK-based layer that manages the validator set, produces checkpoints, and commits them to Ethereum for finality. You don’t run one binary and size one box; you run two services that have to stay in version lockstep, plus a dependency neither Bitcoin, TRON, nor Solana has: Heimdall needs its own Ethereum L1 RPC endpoint to track checkpoints, so “run a Polygon node” has always secretly meant “run a Polygon node and keep an Ethereum endpoint pointed at it.“ Teams that needed direct, verifiable access to Polygon state took on that two-client, cross-chain-dependency stack because the alternative — trusting a third party’s view of state you were settling real value against — wasn’t acceptable. Teams without that requirement rented an RPC endpoint and moved on. The operational math has shifted. What made self-hosting Polygon a project was rarely Bor or Heimdall individually — both are mature, actively maintained clients with years of mainnet hardening. The hard part was everything around them: sizing hardware for two coordinated services, keeping both on compatible versions through Polygon’s active hard fork cadence, wiring up and maintaining the external Ethereum dependency, and monitoring checkpoint health rather than just block height. Chainstack Self-Hosted now supports Polygon PoS, which means that operational layer becomes software you consume rather than a stack you assemble yourself. This piece is about who actually benefits from running their own Polygon node, what that looks like day-to-day, and how the newer, Self-Hosted answer compares to building it yourself. Why running a Polygon node used to be a project Bor and Heimdall aren’t two independent options — they’re a pair. Bor is the execution layer: it produces blocks, executes transactions, and exposes the standard Ethereum-style JSON-RPC surface every EVM tool already speaks. Heimdall is the consensus layer: a separate Cosmos-SDK/Tendermint-family process that tracks the PoS validator set, aggregates Bor block spans into checkpoints, and periodically commits those checkpoints to a contract on Ethereum — which is where Polygon’s real finality actually comes from. Run Bor without Heimdall and you have an execution client with no consensus input. Run them on mismatched versions during a hard fork window and you risk a node that silently disagrees with the network. When you run your own node, you get the same feature set Polygon’s own infrastructure operators do: The full Bor JSON-RPC surface against your own state — balances, contract state, transaction and block history, logs and events — with no rate-limit ceiling beyond your own hardware. WebSocket subscriptions for real-time new-block and log/event feeds, which matters anywhere your application reacts to on-chain events rather than polling for them. Direct transaction submission with full control over gas pricing, instead of routing through a shared provider’s mempool policy during congestion. Independent verification of balances and contract state. For anyone settling value or custody-adjacent logic against Polygon state, the answer to “how do you verify this?” is “we query our own node” — not “we trust a third party’s explorer.” Unlocking that on your own infrastructure meant building the ops layer around the Bor/Heimdall pair yourself: sizing hardware for two coordinated services rather than one, bootstrapping Heimdall’s own chain state alongside Bor’s, standing up and maintaining an Ethereum L1 endpoint purely so Heimdall could track checkpoints, and staying current through a hard fork cadence that has shipped several major upgrades in the past 18 months. That’s the setup burden this article is really about — and the teams that took it on did so for specific, nameable reasons. Who actually runs their own Polygon node, and why Prediction markets and high-frequency on-chain settlement. Polymarket is why Polygon data needs to be load-bearing infrastructure, not a rented API call: the platform has processed activity across 214,735+ markets for 2.4 million traders, with roughly $62 billion in cumulative volume, all settling on-chain through the CTF Exchange contract’s OrderFilled event. A market-making bot there is watching OrderFilled events, holding a live WebSocket order-book feed, and submitting transactions — all at once, and public endpoints throttle exactly that combination: rate limits and shared-tier latency show up as missed fills and stale order books. That’s a real cost on a chain processing about 110 TPS at $0.002 per transaction, with Bor blocks every 2 seconds and L1 finality roughly every 30 minutes. (See Chainstack’s guide to the Polymarket API and how to build a Polymarket trading bot.) Stablecoin and payments platforms. Polygon overtook BNB Chain in Q1 2026 to lead USD-stablecoin transaction volume with roughly a 34.5% share, and payment volumes on the network grew over 400% year-over-year. Stripe settles stablecoin payments to USDC on Polygon (alongside Ethereum and Solana), and Meta began routing creator payouts in USDC on Polygon and Solana through Stripe in April 2026. Visa named Polygon in its expanded stablecoin settlement pilot, which hit a $7 billion annualized run rate in the same period. Platforms moving that kind of volume verify balances against their own infrastructure — the same reason a TRON or Solana stablecoin processor does. DeFi protocols. Aave, the largest lending protocol on Polygon by TVL, is representative of the pattern: on-chain lending and swap logic that reprices or liquidates based on real-time state can’t tolerate a shared provider’s rate limits or latency during volatility — a delayed price update or a throttled liquidation call is a direct loss, not an inconvenience. Compliance and analytics platforms. Chainalysis and Elliptic run infrastructure against Polygon the same way they do for every major chain they cover — serving chain data as a compliance product means full, direct, redundant access, not depending on someone else’s node. At a glance: AudienceUse caseWhat running your own unlocksExamplesPrediction markets & on-chain settlementHigh-frequency order settlement, event monitoring, executionReliable OrderFilled event streams, WebSocket feeds, and tx submission without shared rate limitsPolymarketStablecoin & payments platformsSettle USDC/stablecoin transfers and payouts at volumeIndependent verification of balances and confirmationsStripe, Meta creator payouts, Visa stablecoin settlement pilotDeFi protocolsLending, swaps, and on-chain logic tied to real-time stateReal-time account/contract state without shared-tier latencyAaveCompliance & analyticsTransaction tracing and monitoringFull, direct, redundant chain accessChainalysis, Elliptic The pattern across all of these: when Polygon data is load-bearing for your business — order settlement, payment confirmation, on-chain lending logic, compliance monitoring — you don’t rent it. What running your own actually costs Initial sync. Polygon Mainnet doesn’t ship with a snapshot preset on Chainstack Self-Hosted — it syncs the conventional way, from genesis. In the wider ecosystem, a from-scratch sync (even using torrent-distributed snapshots) commonly takes anywhere from a few days to several weeks depending on client and hardware, against three to four days when pulling a recent third-party snapshot. Plan the initial sync window accordingly rather than assuming it behaves like Amoy. Storage growth. A Polygon Mainnet full node runs into multiple terabytes of state — Chainstack’s own Mainnet deployment provisions around 5.5 TB. Polygon’s Rio upgrade introduced witness-based stateless validation specifically to reduce the growth rate of that footprint going forward, but the existing state is already large and only grows from here. Updates. Polygon PoS ships hard forks on an active cadence, not a rare one: Bhilai (July 2025, raised the block gas limit and pushed throughput past 1,000 TPS), Heimdall v2 (mid-2025, replaced Heimdall’s consensus internals with CometBFT and Cosmos SDK v0.50, cutting finality from 1–2 minutes to roughly 5 seconds and adding EIP-7702 account abstraction), Rio (October 8, 2025, targeting 5,000 TPS via a validator-elected block producer model and stateless validation, effectively eliminating reorgs), Lisovo (March 4, 2026, introduced Dynamic Gas Target, followed by a 120M gas limit increase on March 23), and Giugliano (April 8, 2026, faster block-availability signaling and EIP-1559-style fee data in block headers). That’s four major upgrades inside roughly nine months, and because Bor and Heimdall version together, an upgrade means redeploying both clients in sync, not just bumping one binary. Monitoring and reliability. A Polygon node has two things to watch, not one: Bor’s block production and sync state, and Heimdall’s checkpoint submission health. A Bor node that looks perfectly synced can still be sitting behind a Heimdall instance that’s stopped submitting checkpoints to Ethereum — and because Heimdall’s checkpoint flow depends on your supplied Ethereum L1 endpoint, an outage or rate limit on that upstream endpoint becomes a Polygon finality problem, not just an Ethereum one. The “set it and forget it” myth. Plenty of Bor/Heimdall pairs run for stretches without intervention. They also drift the moment one client falls out of version lockstep with the other during a fork window, or the external Ethereum endpoint Heimdall depends on degrades quietly. For evaluation, that’s tolerable. For anything settlement- or payout-adjacent, it’s a two-client, two-dependency failure surface that’s easy to underestimate going in. What changed: Chainstack Self-Hosted now supports Polygon The historical reason teams reached for managed RPC over self-hosting Polygon wasn’t a preference for managed RPC — it was that sizing and running a paired execution/consensus stack, wiring up an external Ethereum dependency, and staying current through Polygon’s fork cadence was overhead most teams couldn’t justify unless the workload demanded it. Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Polygon PoS on Mainnet and the Amoy testnet, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy (Supported deployments). Mainnet runs Bor v2.8.3 paired with Heimdall v0.9.0, on 12 vCPU, 64 GiB RAM — split across the two clients — and roughly 5.5 TB of storage. Amoy testnet runs Bor v2.10.0 with Heimdall v0.11.0, on a lighter 6 vCPU, 24 GiB RAM, and 170 GB of storage. Here’s the asymmetry worth being upfront about: Amoy bootstraps from a pre-built snapshot — provision roughly 2× the steady-state storage during deploy, since the compressed archive and the extracted state briefly coexist on disk — but Mainnet does not. Mainnet syncs the conventional way, from genesis. If you’re deploying Mainnet, plan your initial sync window as a real sync, not a snapshot restore. Polygon PoS also requires an Ethereum Layer 1 RPC endpoint that you supply. Heimdall uses it to track and validate checkpoints committed to Ethereum — without it, Heimdall has no way to follow Polygon’s actual finality layer. This is the same category of prerequisite that OP Stack chains on this platform carry: it’s not optional, it’s not provided for you, and an unreliable or rate-limited L1 endpoint becomes a Polygon problem, not just an Ethereum one. Have that endpoint ready before you deploy. One Polygon node, two clients: Bor and Heimdall, plus a required Ethereum L1 endpoint. The exposed surface is Bor’s standard HTTP JSON-RPC on port 8545 and WebSocket JSON-RPC on port 8546, plus Heimdall’s REST API (Cosmos LCD) on port 1317. Bor’s P2P port (30303) and Heimdall’s CometBFT RPC (26657) and P2P (26656) ports are internal only and not exposed. Mainnet syncs without a snapshot; Amoy bootstraps from one. Size your deploy timeline for whichever network you’re actually running, not the other one. What you get is Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from its last state on the persistent volume. Bor and Heimdall version upgrades still require you to redeploy the node yourself — Self-Hosted doesn’t currently auto-update client versions for you, which matters more on Polygon than on slower-moving chains given the fork cadence above. Multi-endpoint failover to a Chainstack-managed Polygon endpoint is planned but not yet shipped, the same status it has across the rest of Self-Hosted (Self-Hosted FAQ). You still own the node. The data never leaves your perimeter. You can point any Bor-compatible RPC client at it and query it like any other Polygon JSON-RPC endpoint — you just didn’t build the deployment and monitoring stack around it yourself. When to self-host Polygon, and when not to The decision isn’t religious. It’s a workload question. Run your own Polygon node if: Your application makes more than a few hundred thousand RPC calls a day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput. You’re settling trades, orders, or payments where event delivery and confirmation latency directly affect outcomes. You process stablecoin or payment volume at scale and need independently verifiable balances and confirmations. You’re building a DeFi protocol, indexer, or analytics platform whose logic depends on real-time on-chain state. Compliance, audit, or regulatory frameworks require infrastructure control over how you access and verify chain data. Reach for managed Chainstack Polygon instead if: You want to avoid the hardware cost and upfront commitment of Polygon’s paired-client infrastructure. 12+ vCPU, 64+ GiB RAM, and ~5.5 TB of storage split across two clients is real capital before you’ve served a single request; Chainstack Polygon nodes skip that entirely. You’re running at low-to-moderate volume in general — a production workload that doesn’t yet justify owning dedicated hardware, or you’re still learning and prototyping. You’d rather not maintain an Ethereum L1 endpoint as a standing prerequisite just to keep Heimdall’s checkpoint tracking healthy. The middle ground — production workloads that wanted their own Polygon node without committing to sourcing and babysitting a two-client, cross-chain-dependent stack themselves — used to have no clean answer. DIY self-hosting worked, but the hardware research, the Bor/Heimdall version coordination, and the standing Ethereum endpoint dependency was itself a quarter of DevOps work. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon. If your Polygon workload is heading toward “load-bearing for the business” — and on a chain settling billions of dollars in prediction-market trades and a growing share of the industry’s stablecoin payment volume, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t require becoming a Bor/Heimdall specialist first. Deploy your own Polygon node on Chainstack Self-Hosted → FAQ How long does the initial Polygon node sync take? It depends on which network. Amoy testnet on Chainstack Self-Hosted bootstraps from a pre-built snapshot, typically completing in a few hours. Polygon Mainnet does not ship with a snapshot preset — it syncs the conventional way from genesis, which in the wider ecosystem commonly takes anywhere from several days to a few weeks depending on client and hardware. Don’t plan a Mainnet deploy on Amoy’s timeline; they’re genuinely different. How much storage does a Polygon node need? Roughly 5.5 TB for Mainnet and 170 GB for Amoy testnet on Chainstack Self-Hosted. For Amoy, provision about 2× that during the initial deploy, since the compressed snapshot archive and the extracted state briefly coexist on disk. Mainnet’s footprint will keep growing over time; Polygon’s Rio upgrade introduced stateless validation specifically to slow that growth going forward, but it doesn’t shrink the state that already exists. Why does Polygon need two clients — Bor and Heimdall? Bor is the execution client: it produces and executes blocks and exposes the standard Ethereum-style JSON-RPC surface. Heimdall is the consensus client: a separate Cosmos-SDK-based process that tracks the validator set, assembles checkpoints from Bor’s block history, and commits them to Ethereum, which is where Polygon’s actual finality comes from. They run as a paired stack, split resources across the two, and need to stay on compatible versions — you can’t meaningfully run one without the other. Does Polygon require an Ethereum endpoint to run? Yes. Heimdall needs an Ethereum Layer 1 RPC endpoint — which you supply, it isn’t provided for you — to track and validate the checkpoints Polygon commits to Ethereum. An unreliable or rate-limited L1 endpoint becomes a Polygon finality problem, not just an Ethereum one, so this is worth treating as a hard prerequisite rather than an afterthought. How often does Polygon PoS upgrade, and what does that mean operationally? Actively. In roughly the past 18 months Polygon has shipped Bhilai (mid-2025, block gas limit increase), Heimdall v2 (mid-2025, faster ~5-second finality), Rio (October 2025, targeting 5,000 TPS via stateless validation), Lisovo (March 2026, Dynamic Gas Target), and Giugliano (April 2026, faster block-availability signaling and on-chain fee data). Because Bor and Heimdall version together, each of these means redeploying both clients in sync. Chainstack Self-Hosted doesn’t currently auto-update client versions for you, so this is a recurring, active maintenance item rather than a rare one. Is Polygon Amoy testnet supported, in addition to Mainnet? Yes. Chainstack Self-Hosted supports both Polygon Mainnet and the Amoy testnet, with different resource presets and bootstrap behavior for each — see the sync and storage answers above for the specific asymmetry between them. What happens if my self-hosted Polygon node fails? Chainstack Self-Hosted ships with Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from the last state on the persistent volume. Multi-endpoint failover to a Chainstack-managed Polygon endpoint is planned but not yet shipped, so for now you’re on your own for diagnosing anything beyond a simple pod restart. Does Chainstack Self-Hosted support Polygon zkEVM or Polygon CDK app-chains too? No — this covers Polygon PoS specifically (the Bor/Heimdall chain, Mainnet and Amoy). Polygon zkEVM and Polygon CDK-based app-chains are architecturally distinct systems with different client stacks and aren’t part of this Self-Hosted deployment. What protocols are coming next to Chainstack Self-Hosted? Polygon brought the Self-Hosted catalog to 29 protocols, spanning Ethereum, the OP Stack family, opBNB, Arbitrum, Robinhood Chain, Starknet, TRON, Bitcoin, Sui, Tempo, Plasma, Avalanche, Arc, Sonic, Stable, Berachain, Cronos, BNB Smart Chain, Kaia, Ronin, Hyperliquid, Solana, and now Polygon PoS. Check the supported clients and protocols page — it’s the canonical place to see what ships next. Additional resources Chainstack Self-Hosted documentation: Introduction to Chainstack Self-Hosted Supported clients and protocols System requirements Quick start Self-Hosted FAQ External: Bor GitHub repository (Polygon Labs) Heimdall v2 GitHub repository (Polygon Labs) Giugliano upgrade overview (Polygon) Related reading — Running your own node: Running your own Solana node Running your own Bitcoin node Running your own TRON node Running your own Base node #### Running your own Solana node: infrastructure for MEV and trading Running a Solana node yourself has historically been a commitment. Agave (the Anza-maintained successor to the original Solana Labs validator client) isn’t exotic software, but it is demanding software. Official hardware guidance calls for 256–512 GB of ECC RAM depending on whether account indexing is enabled, accounts and ledger split across separate high-endurance NVMe drives because their I/O patterns are incompatible — ledger writes are sequential and append-only, account access is heavy random I/O — and a CPU chosen for clock speed over core count. Get any of that wrong and Solana doesn’t degrade gracefully: a node that falls behind the network’s ~400ms slot cadence falls behind and stays behind, since there’s no cheap way to catch up on a chain that never stops producing blocks. Teams handling trade execution, custody, or settlement on Solana took on that hardware and operations burden because they had to — the value of direct, low-latency access to chain state outweighed the DevOps cost. Teams without those requirements didn’t. The operational math has shifted. What made running a Solana node hard was rarely Agave itself — it’s a mature, actively developed client with years of mainnet hardening behind it. The hard part was everything around the node: hardware sizing, snapshot bootstrap, monitoring, upgrades, failover. Chainstack Self-Hosted now supports Solana Mainnet and Devnet, which means that operational layer becomes software you consume rather than a stack you build. This piece is about who actually benefits from a Solana node on their own infrastructure, what running one looks like day-to-day, and how the newer answer compares to the older one. Why running a Solana node used to be a project Agave is the reference implementation validators and RPC operators run to serve the network. It’s what exchanges, market makers, and DeFi protocols on Solana all run under the hood in some form. When you run your own node, you get the same feature set they do: The full Agave JSON-RPC surface against your own state — account data, program state, transaction and block history, slot and epoch info — with no rate-limit ceiling beyond your own hardware. WebSocket subscriptions for real-time account, program, signature, and slot updates. No polling loop guessing when state changed. Direct transaction submission with full control over compute unit pricing and priority fees. Solana doesn’t have a persistent, chain-wide mempool the way Bitcoin or Ethereum do — transactions are forwarded straight into the current slot leader’s incoming queue — so submitting from your own node means you control that forwarding path instead of depending on someone else’s. Independent verification of balances and program state. For anyone holding customer SOL or SPL tokens, or settling against on-chain state, the answer to “how do you verify this?” is “we query our own node.” Everything else is trust in a third party. Unlocking that feature set on your own infrastructure meant building the ops layer around Agave yourself: sourcing hardware sized for hundreds of gigabytes of RAM and multiple NVMe drives, bootstrapping from a snapshot (attempting a genesis replay is not something anyone does in practice — the ledger is too large and the replay too slow to be worth it), standing up monitoring tight enough to catch drift within a slot or two, and planning for Agave’s frequent version cadence. That’s the setup burden this article is really about. The teams that took it on did so for very specific reasons — worth naming, because they’re where the case for a self-hosted Solana node actually lives. Who actually runs their own Solana node, and why Market makers and MEV/priority-execution infrastructure. Jito Labs built the dominant MEV and priority-fee infrastructure layer on Solana. Its Block Assembly Marketplace (BAM) reached roughly a third of Solana’s stake-weighted network share by Q2 2026, per Solana Foundation data. Firms competing on transaction ordering and inclusion at that layer need direct, low-latency access to leader schedules and priority-fee markets — routing that through a shared, rate-limited RPC tier defeats the point. Exchanges and custodians. Coinbase runs its own Solana validator infrastructure at real scale: 23 validators across two independent bare-metal providers, staking 41.63 million SOL — about 9.72% of all staked SOL — on a multi-client setup spanning Firedancer, Jito, JitoBAM, and Harmonic, as of its Q2 2026 validator performance report. Exchanges processing SOL and SPL-token deposits and withdrawals at that volume need independent balance verification and rate limits that don’t buckle during a busy window — an auditor doesn’t accept “we trust a third-party explorer” as an answer. DeFi protocols and DEX aggregators. Jupiter, Solana’s dominant swap aggregator, handles over 90% of aggregator volume and roughly half of all Solana DEX trading volume, several billion dollars a day in 2026. Raydium and Orca sit underneath that flow as the AMMs doing the actual settlement. At that scale, application logic that depends on real-time account and program state can’t tolerate a shared provider’s latency or rate-limit envelope — a stale price feed or a delayed confirmation is a direct PnL problem. Stablecoin and payments platforms. Circle minted over $64 billion of USDC on Solana during 2026 alone (gross issuance, not standing circulating supply). Platforms settling USDC and other SPL-token transfers at that volume verify balances against their own node rather than a third-party balance API, for the same reasons a TRON or Ethereum stablecoin processor does. Compliance and analytics platforms. Chainalysis and Elliptic run Solana infrastructure for transaction tracing and monitoring, the same way they do for every major chain they cover. Serving chain data as a compliance product means needing full, direct, and redundant access to it. At a glance: AudienceUse caseWhat running your own unlocksExamplesMarket makers & MEV infraPriority transaction execution and inclusionLow-latency leader access, priority-fee control, no shared rate limitsJito LabsExchanges & custodiansCustody SOL/SPL, process deposits & withdrawalsIndependent balance verification, audit-grade infrastructure controlCoinbaseDeFi protocols & DEX aggregatorsHigh-volume swap routing and on-chain logicReal-time account/program state without shared-tier latencyJupiter, Raydium, OrcaStablecoin & payments platformsSettle USDC and SPL-token transfersIndependent verification of balances and transfersCircle-issued USDC on SolanaCompliance & analyticsTransaction tracing and monitoringFull, direct, redundant chain accessChainalysis, Elliptic The pattern across all of these: when Solana data is load-bearing for your business — trade execution, custody, settlement, compliance — you don’t rent it. What running your own actually costs The operational reality is heavier than most chains on this platform, and the costs are specific enough to plan around rather than guess at. Initial sync. Syncing a Solana node from genesis isn’t something operators attempt in practice — replaying the full transaction history and rebuilding state from block zero is untenable given how large and fast-growing the ledger is. Snapshot-based bootstrap is close to mandatory: you download a recent verified state and catch up to the chain head from there, typically in minutes to a few hours depending on snapshot size and network conditions, rather than the days a genesis replay would take. Storage growth. An unpruned Solana ledger has passed 400 TB and grows on the order of 80–95 TB a year — nobody runs that. Production nodes run pruned, keeping a rolling window of recent state and history, which is why a properly sized Mainnet RPC deployment lands around 3–4 TB rather than in the hundreds. NVMe is not optional here: Solana’s write pressure will bottleneck SATA SSDs and make rotational storage unusable. Updates. Agave ships on an aggressive cadence — roughly a six-week major release rhythm from Anza, with the gap between minor versions now under three months. New protocol behavior activates through feature gates that require a supermajority (roughly two-thirds) of stake to adopt before turning on; for minor-version floors specifically, the network raises the required version two epochs after 95% of stake has moved to it. Fall behind that curve and you risk running an incompatible client right as an activation crosses the line, not a slow drift you can fix at leisure. Monitoring and reliability. Solana’s slot cadence runs at roughly 400ms today, with a feature-gated path to 200ms shipped in Agave 4.2 once the network activates it. A node that’s a few slots behind on a chain moving that fast isn’t in a mild degraded state — it’s on its way to being functionally useless for anything latency-sensitive, and it stays that way without a snapshot re-bootstrap. Solana is less forgiving of undersized infrastructure than most chains: undersize the hardware and a node doesn’t slow down gracefully, it falls behind and stays behind. The “set it and forget it” myth. Plenty of Agave nodes do run for stretches without intervention. They also fall off the pace the moment a peer connection degrades, a disk fills up, or a mandatory version bump passes, and unlike a chain with a multi-minute block time, there’s very little slack to notice and recover before the gap compounds. For evaluation or low-stakes use, that’s tolerable. For anything trade- or settlement-adjacent, it’s a quiet path to a broken Saturday. What changed: Chainstack Self-Hosted now supports Solana The historical reason teams reached for managed RPC over self-hosting Solana wasn’t that they preferred managed RPC — it was that sourcing and correctly sizing Solana-grade hardware, then building the snapshot, monitoring, and upgrade discipline around it, was too much operational overhead to justify unless the workload demanded it. Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Solana on Agave v4.2.0, running non-voting RPC nodes on both Mainnet and Devnet, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy (Supported deployments). Full rollout details are in the announcement. Hardware sizing reflects Solana’s real appetite. Mainnet takes 16 vCPU, 256 GiB of RAM, and roughly 3.5 TB of storage; Devnet takes 8 vCPU, 64 GiB of RAM, and roughly 2.2 TB (System requirements). Both networks bootstrap from a pre-built snapshot rather than syncing from genesis — unlike TRON and Bitcoin on this platform, there’s no multi-day genesis sync to plan for on Solana. Provision for roughly 2× the steady-state storage figure during the deploy itself, since the compressed snapshot archive and the extracted state briefly coexist on disk before cleanup. The exposed endpoint is Agave’s standard HTTP JSON-RPC on port 8899, plus WebSocket JSON-RPC on port 8900 — the same interface every Solana SDK and RPC client speaks (Supported deployments). Snapshot-based bootstrap ships for both Mainnet and Devnet out of the box — you’re not doing a genesis sync on either network, which is a meaningfully better starting position than TRON or Bitcoin get on this platform today. What you get is Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from its last state on the persistent volume. Agave version upgrades still require you to redeploy the node on the new client version yourself — Self-Hosted doesn’t currently auto-update client versions for you, and given Agave’s release cadence, that’s a more frequent chore on Solana than on most other protocols here. Multi-endpoint failover to a Chainstack-managed Solana endpoint is planned but not yet shipped, the same status it has across the rest of Self-Hosted (Self-Hosted FAQ). Only non-voting RPC nodes ship today. Validator support is explicitly on the roadmap but not expected before late 2026, pending Chainstack’s approach to uptime guarantees, slashing protection, and key management (Self-Hosted FAQ). You still own the node. The data never leaves your perimeter. You can point any Agave-compatible RPC client at it and query it like any other Solana JSON-RPC endpoint. The difference is you didn’t build the snapshot, deployment, and monitoring stack around it yourself. When to self-host Solana, and when not to The decision isn’t religious. It’s a workload question. Run your own Solana node if: Your application makes more than a few hundred thousand RPC calls a day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput. You’re executing trades, routing swaps, or running MEV-adjacent infrastructure where latency to the current leader directly affects outcomes. You custody SOL or SPL-token assets at exchange or institutional scale and need independently verifiable balances. You’re building a DeFi protocol, indexer, or analytics platform whose logic depends on real-time account or program state. Compliance, audit, or regulatory frameworks require infrastructure control over how you access and verify chain data. Reach for managed Chainstack Solana instead if: You want to avoid the hardware cost and upfront commitment of Solana-grade infrastructure. 256+ GB of RAM and multi-NVMe storage is real capital and lead time before you’ve served a single request; Chainstack Solana nodes skip that entirely. You’re running at low-to-moderate volume in general — a production workload that doesn’t yet justify owning dedicated hardware, or you’re still learning and prototyping. You need Geyser/Yellowstone gRPC streaming for program-account monitoring without building it yourself. That ships built-in through Chainstack’s managed Solana nodes; on Self-Hosted you’d need to run the Yellowstone plugin yourself on top of your own Agave node. When to self-host Solana, and when managed Chainstack infrastructure makes more sense. The middle ground — production workloads that wanted their own Solana node without committing to sourcing and babysitting 256 GB-RAM, multi-NVMe hardware themselves — used to have no clean answer. DIY self-hosting worked, but the hardware research, snapshot tooling, and upgrade discipline around Agave was itself a quarter of DevOps work, arguably more given how punishing Solana is of getting the sizing wrong. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon. If your Solana workload is heading toward “load-bearing for the business” — and on a chain where a single aggregator routes several billion dollars a day, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t require becoming a Solana hardware specialist first. Deploy your own Solana node on Chainstack Self-Hosted → FAQ How long does the initial Solana node sync take? Both Mainnet and Devnet on Chainstack Self-Hosted bootstrap from a pre-built snapshot, typically completing in minutes to a few hours depending on network conditions, with the node catching up to the chain head in the background afterward. Syncing purely from genesis isn’t something operators attempt in practice — the ledger is too large and the replay too slow to be worth it on Solana specifically. How much storage does a Solana node need? Roughly 3.5 TB steady-state for Mainnet and 2.2 TB for Devnet on Chainstack Self-Hosted. Provision for about 2× that during the initial deploy, since the compressed snapshot archive and the extracted chain state briefly coexist on disk. An unpruned Solana ledger is a different animal entirely — it has passed 400 TB and grows roughly 80–95 TB a year — which is why production nodes run pruned rather than retaining full history locally. What API and endpoints does Chainstack Self-Hosted expose for Solana? The current deployment exposes Agave’s standard HTTP JSON-RPC on port 8899 and WebSocket JSON-RPC on port 8900 — the same interface every Solana SDK speaks. Geyser/Yellowstone gRPC streaming, which some high-throughput indexers and trading integrations use for program-account subscriptions, isn’t exposed on the current Self-Hosted Solana deployment. It’s available today through Chainstack’s managed Solana nodes; check the supported clients and protocols page for current exposure options on Self-Hosted and reach out if your workload needs more than standard JSON-RPC. What happens with Agave version upgrades? Agave ships on roughly a six-week major release cadence, with minor versions landing under three months apart. New protocol behavior activates through feature gates once a supermajority of stake adopts it, and minor-version floors get raised two epochs after 95% of stake has moved to a version. Chainstack Self-Hosted doesn’t currently auto-update client versions for you — you’ll need to redeploy the node on the new Agave version yourself ahead of an activation, the same way you would on a fully self-managed setup. Is Solana testnet supported, in addition to Mainnet and Devnet? Currently Mainnet and Devnet only. Additional networks may be added — check the supported clients and protocols page for the current list. What happens if my self-hosted Solana node fails? Chainstack Self-Hosted ships with Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from the last state on the persistent volume. Multi-endpoint failover to a Chainstack-managed Solana endpoint is planned but not yet shipped, so for now you’re on your own for diagnosing anything beyond a simple pod restart. Does Chainstack Self-Hosted support running a Solana validator, not just an RPC node? Not yet. Only non-voting RPC nodes ship today. Validator support is explicitly on the roadmap but not expected before late 2026, pending how Chainstack addresses uptime guarantees, slashing protection, and key management for a voting node. If you need validator support sooner, reach out through Chainstack’s feedback channel. What protocols are coming next to Chainstack Self-Hosted? Solana brought the Self-Hosted catalog to 29 protocols across 48 network deployments, spanning Ethereum, the OP Stack family, Arbitrum, Robinhood Chain, Polygon PoS, Starknet, TRON, Bitcoin, Sui, Tempo, Plasma, Avalanche, Arc, Sonic, Stable, Berachain, Cronos, BNB Smart Chain, Kaia, Ronin, Hyperliquid, and now Solana. Check the supported clients and protocols page — it’s the canonical place to see what ships next. Additional resources Chainstack Self-Hosted documentation: Introduction to Chainstack Self-Hosted Supported clients and protocols System requirements Quick start Solana developer tooling docs External: Agave GitHub repository (Anza) Agave 4.2 release overview (Solana Foundation) Coinbase Q2 2026 Solana Validator Performance Report Related reading — Running your own node: Running your own Polygon node Running your own Bitcoin node Running your own TRON node Running your own Base node #### Running your own TRON node: infrastructure for the USDT rails Running a TRON node yourself has historically been a commitment. Java-Tron isn’t especially exotic — a JVM-based full node with well-understood mechanics — but the operational layer around it required real DevOps investment. You provision the hardware, install Java-Tron with the right JDK version, wait days for the initial sync, set up monitoring, and then run the cycle again every time TRON ships a mandatory network upgrade. Teams handling USDT settlement, exchange flow, or high-volume payment rails did this because they had to — the value of full control over broadcast, throughput, and independent verification of settlement outweighed the DevOps cost. Teams without those requirements didn’t. The operational math has shifted. What made running a TRON node hard was rarely TRON itself — Java-Tron is stable and production-hardened by years of running the world’s largest stablecoin settlement network. The hard part was everything around the node: deployment, monitoring, self-healing, updates, failover. Chainstack Self-Hosted now supports TRON Mainnet, which means that operational layer becomes software you consume rather than a stack you build. This piece is about who actually benefits from a TRON node on their own infrastructure, what running one looks like day-to-day, and how the newer answer compares to the older one. Why running a TRON node used to be a project Java-Tron is the reference implementation of the TRON protocol. It’s what exchanges, custodians, payment processors, and DeFi protocols on TRON all run under the hood. When you run your own node, you get the same feature set they do: Dual API surface — HTTP JSON-RPC on port 8090 for standard integrations, plus a full gRPC API for high-throughput or streaming workloads. The gRPC layer is what most production TRON operators reach for at scale. Full mempool visibility — every unconfirmed TRC-20 transfer, every pending TRX transaction, every energy/bandwidth resource change. Payment processors watching for incoming USDT get push notifications the moment a transaction enters the network. Direct transaction broadcasting with propagation control. Your transaction enters TRON’s gossip network from your own Super Representative peer set; you can watch propagation, retry if needed, and react to network conditions. Independent verification of settlement. For an entity holding customer USDT or reconciling stablecoin flows, the answer to “how do you verify balances?” is “we run our own node.” Everything else is trust in a third party. Unlocking that feature set on your own infrastructure meant building the ops layer around Java-Tron yourself: procure hardware sized for ~3 TB and growing, install Java-Tron with the correct JDK version, wait for the initial block download (TRON’s chain has processed over 13 billion transactions since mainnet launch), stand up monitoring, hook up alerts, plan for mandatory network upgrades, plan for failover. That’s the setup burden the article is really about. The teams that took it on did so for very specific reasons — worth naming, because they’re where the case for a self-hosted TRON node actually lives. Who actually runs their own TRON node, and why Stablecoin payment processors. Kolo, NEXUS, WalletConnect Pay — every serious USDT payment company on TRON runs its own nodes. The economics are decisive. TRON processed $1.96 trillion in stablecoin settlements in Q1 2026, driven almost entirely by TRC-20 USDT. A payment processor sitting in that flow can’t afford to poll a shared RPC endpoint for confirmations, wait on someone else’s mempool refresh cycle, or hit a rate limit during a high-volume window. Broadcasting from your own node means you control transaction propagation and can rebroadcast aggressively. Fee estimation from your own resource-model calculation is more accurate than any third-party oracle. When the entire business is “we settle USDT at low fees, fast,” none of this can be outsourced. Centralized exchanges. Binance, OKX, HTX, Gemini, Bitstamp — every exchange running TRC-20 USDT deposits and withdrawals runs its own TRON nodes. Two reasons. First, scale: Binance alone captures 30–50% of labeled stablecoin inflows on TRON. At that volume, shared RPC providers become both a rate-limit ceiling and a single point of failure. Second, compliance: exchanges holding customer TRX and TRC-20 assets must independently verify balances against the chain — regulators and auditors don’t accept “we trust a third party’s API.” Remittance and regional payment operators. TRON has become the dominant stablecoin rail in emerging markets. Regional Commerce data shows TRON captured over 40% of crypto shopping volume in Africa and LATAM in Q1 2026. Remittance corridors, neobanks, and merchant processors serving these markets run their own TRON nodes for the same reasons payment processors do: broadcast reliability, mempool accuracy, and settlement independence. When your customer is paying rent in USDT and expects it to confirm in under a minute, the RPC layer isn’t a place to save money. Institutional custodians and prime brokers. Anchorage Digital added TRON support in 2026. Custodians holding institutional USDT on TRON — including balance sheets that increasingly include stablecoin treasury positions — verify against their own nodes. The 2024–2026 wave of stablecoin adoption by fintechs and neobanks (Mastercard Crypto Partner Program, MetaMask native TRON support) all pushes more institutional value onto TRON, and all of those integrations sit on top of self-hosted infrastructure. DeFi protocols on TRON. SunSwap (TRON’s largest DEX by USDT volume), JustLend, and USDD’s ecosystem all run their own nodes for the same reason DeFi on Ethereum does: application logic that depends on chain state can’t tolerate a shared provider’s latency or rate-limit envelope. SunSwap’s USDT–WTRX pool processed billions of dollars in swaps in Q1 2026 alone. Analytics and compliance platforms. Chainalysis, Elliptic, and the T3 Financial Crime Unit all run TRON nodes at scale for transaction tracing and compliance monitoring. Any platform in the business of serving TRON data as a product needs full and direct access to the chain, typically across multiple nodes for redundancy plus indexed databases on top. At a glance: AudienceUse caseWhat running your own unlocksExamplesStablecoin payment processorsAccept USDT payments at scaleControllable broadcast, real-time confirmation detection, accurate resource-model fee estimationKolo, NEXUS, WalletConnect PayCentralized exchangesCustody TRC-20 assets, process deposits/withdrawalsRate limits that hold at exchange scale, audit-grade infrastructure controlBinance, OKX, HTX, Gemini, BitstampRemittance operatorsServe emerging-market USDT flowsBroadcast reliability, low-latency mempool accessRegional processors across Africa, LATAMInstitutional custodiansHold and verify institutional USDTIndependent balance verification, compliance-ready infrastructureAnchorage, Mastercard partnersDeFi protocols on TRONRun production DEX / lending / stablecoin logicDirect gRPC access, full mempool, historical query depthSunSwap, JustLend, USDDAnalytics & complianceServe TRON data as a productMulti-node redundancy, custom indexer feeds, full historical accessChainalysis, Elliptic, T3 FCU The pattern across all of these: when TRON data is load-bearing for your business — USDT settlement, custody, compliance, application state — you don’t rent it. What running your own actually costs The operational reality is more pragmatic than the “sovereign infrastructure” version. A TRON full node is heavier than Bitcoin but lighter than an Ethereum archive node. Costs are predictable enough to plan around. Initial sync. TRON’s chain has processed over 13 billion transactions since mainnet launched in May 2018, and it produces a new block every 3 seconds. A clean sync from genesis takes days on good hardware — Java-Tron replays every block, validates every signature, and rebuilds state as it goes. Most professional setups bootstrap from a snapshot to bring a node current in hours instead of days. Storage growth. ~3 TB steady-state and growing steadily. TRON blocks are small individually (3-second cadence, mostly USDT transfers and TRX transactions), but they add up: the network processes 8–10 million transactions per day on average. Plan for 4–5 TB of storage headroom if you want to avoid resizing within the first year. NVMe strongly preferred — SATA SSDs will bottleneck IBD, and rotational drives simply won’t keep up. Updates. TRON ships mandatory network upgrades several times a year. The GreatVoyage series is the current upgrade branch — v4.8.1 ‘Democritus’ shipped in February 2026, with a mandatory upgrade deadline of March 9, adding ARM64 architecture support, JDK 17 compatibility, and SELFDESTRUCT opcode alignment with Ethereum. Missing a mandatory upgrade means your node forks off the network at the activation block. The schedule is more forgiving than Ethereum’s twice-yearly hard forks, but the operational discipline is the same. Monitoring and reliability. Sync drift happens. Peer connections degrade. Disk fills up. The GreatVoyage upgrade cycle occasionally introduces breaking changes that require configuration adjustments. Without monitoring, you find out something is wrong because a USDT transfer failed to confirm. With monitoring, you find out because an alert fires before customers notice. The “run it and forget it” myth. Plenty of Java-Tron nodes do run for months without intervention. They also drift out of sync silently, miss mandatory upgrades, and become slowly less useful without anyone noticing. For personal or evaluation use, that’s fine. For production USDT settlement, it’s a quiet path to a broken Saturday. What changed: Chainstack Self-Hosted now supports TRON The historical reason teams reached for shared RPC over self-hosting wasn’t that they wanted shared RPC — it was that the operational overhead of self-hosting a TRON node was too high to justify for a single chain, and they’d rather pay a provider’s premium than build a TRON DevOps function in-house. Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports TRON Mainnet on Java-Tron GreatVoyage-v4.8.1.1, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy (Supported deployments). You get the node running on hardware you own, with the control plane — deployment, self-healing at the Kubernetes level, and monitoring through the bundled Grafana and VictoriaMetrics stack — handled by Chainstack (Monitoring). A TRON full node fits on 8 vCPU, 32 GiB of RAM, and ~3 TB of NVMe storage (System requirements; Supported deployments). The exposed endpoint is Java-Tron’s HTTP JSON-RPC on port 8090 — the same interface every TRON SDK speaks. The gRPC API (port 50051) is used internally and isn’t exposed by default (Supported deployments). Unlike Ethereum and Optimism Mainnet on the platform, TRON doesn’t currently ship with a snapshot-bootstrap preset — it syncs conventionally from genesis, so the multi-day initial sync described earlier still applies. See the system requirements page for the current snapshot-availability breakdown by network. What you do get is Kubernetes-level self-healing: if a node pod crashes, the deployment automatically restarts it and resumes from its last state on the persistent volume. Mandatory GreatVoyage upgrades still require you to redeploy the node on the new Java-Tron version yourself — Self-Hosted doesn’t currently auto-update client versions for you. Multi-endpoint failover to a Chainstack-managed TRON node is on the roadmap but not yet shipped. You still own the node. The data never leaves your perimeter. You can SSH into the box and hit wallet/getnowblock against it like any other Java-Tron install. The difference is you didn’t build the deployment stack around it yourself — though today that means bring-your-own snapshot and bring-your-own upgrade discipline for TRON specifically, unlike Ethereum and Optimism Mainnet, which get snapshot bootstrap out of the box. When to self-host TRON, and when not to The decision isn’t religious. It’s a workload question. Run your own TRON node if: You’re accepting USDT payments in production. The broadcast reliability, mempool visibility, and confirmation-timing arguments compound until they’re decisive. You operate an exchange, custody service, or fintech touching TRC-20 assets at meaningful volume. You run a remittance corridor, merchant processor, or payment gateway serving stablecoin flows. Your application makes more than a few hundred thousand RPC calls per day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput. You need gRPC access, full mempool subscriptions, or high-frequency event streaming that shared RPC tiers don’t offer. Compliance, audit, or regulatory frameworks require infrastructure control over customer asset movements. Reach for managed Chainstack TRON instead if: You’re learning, prototyping, or running a low-volume side project. Chainstack TRON nodes with a free Developer tier covers most of that scale without the setup. You only need occasional historical lookups or read-only analytics on TRON data. You’re integrating a wallet or app that only needs basic TRC-20 balance queries and transaction submission. The middle ground — production workloads that wanted their own TRON node without committing to a full DIY setup — used to have no clean answer. DIY self-hosting worked, but the setup and monitoring stack around Java-Tron was itself a quarter of DevOps work. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon. If your TRON workload is heading toward “load-bearing for the business” — and given TRON settles nearly $2 trillion in USDT quarterly, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t have to take a quarter anymore. Explore Chainstack Self-Hosted → FAQ How long does the initial TRON node sync take? From genesis, several days on good hardware — Java-Tron has to replay 13+ billion transactions and rebuild state as it goes. Unlike Ethereum and Optimism Mainnet on Chainstack Self-Hosted, TRON doesn’t currently ship with a snapshot-bootstrap preset, so the multi-day sync from genesis is what to plan for today. Check the system requirements page for the current list of snapshot-enabled networks. How much storage does a TRON full node need? ~3 TB steady-state, growing steadily as the network processes 8–10 million transactions per day. Plan for 4–5 TB if you want to avoid resizing within the first year. NVMe is strongly preferred over SATA SSD — TRON’s 3-second block cadence generates enough write pressure that slower disks become a bottleneck. Does Chainstack Self-Hosted support the gRPC API? The current Self-Hosted TRON deployment exposes Java-Tron’s HTTP JSON-RPC on port 8090. gRPC (typically port 50051) is used internally between the node’s components and is not exposed by default. If your workload depends on gRPC — typically high-throughput indexers, streaming subscribers, or advanced trading integrations — check the supported clients and protocols page for current exposure options and reach out if your use case needs more than HTTP. What happens with TRON mandatory network upgrades? TRON’s GreatVoyage upgrade series requires all nodes to be running compatible versions by the activation block, or they fork off the network. Chainstack Self-Hosted doesn’t currently auto-update client versions for you — you’ll need to redeploy the node on the new Java-Tron version yourself ahead of the activation block, the same way you would on a fully self-managed setup. Is TRON testnet (Nile, Shasta) supported? Currently TRON Mainnet only. Additional networks may be added — check the supported clients and protocols page for the current list. What happens if my self-hosted TRON node fails? Chainstack Self-Hosted ships with Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from the last state on the persistent volume. Multi-endpoint failover to a Chainstack-managed TRON endpoint is on the roadmap but isn’t available yet, so for now you’re on your own for diagnosing anything beyond a simple pod restart. What protocols are coming next to Chainstack Self-Hosted? The current Self-Hosted lineup beyond TRON spans Ethereum (Mainnet, Sepolia, Hoodi), the OP Stack family (Optimism, Base, Unichain, Zora), Starknet, Polygon PoS, and Bitcoin. Solana Mainnet and Devnet with the Agave client are explicitly listed as coming soon on the supported clients and protocols page. Does this work for USDC on TRON, not just USDT? Yes, in the sense that a standard Java-Tron full node serves any TRC-20 token — USDT, USDD, and any USDC contract deployed on TRON — the same way, through JSON-RPC. Worth noting: Circle discontinued native minting of USDC on TRON back in February 2024, so USDC on TRON today isn’t Circle-issued the way it is on Ethereum or other CCTP-supported chains. USDT dominates TRON volume by a wide margin regardless. Read more Chainstack Self-Hosted documentation: Introduction to Chainstack Self-Hosted Supported clients and protocols System requirements Quick start Deploying nodes Managing nodes Monitoring Chainstack TRON products: Build better with TRON TRON developer tooling docs External: Java-Tron GitHub repository TRON Q1 2026 network report (TRON DAO) TRON stablecoin ecosystem report (Arkham) #### Saakuru Labs: Accelerating the transition from Web2 to Web3 with Chainstack Bridging Web2 and Web3 with seamless integration for a frictionless landscape. Working with Chainstack has yielded significant cost savings for Saakuru Labs, directly impacting our bottom line for a 4x in infrastructure ROI. Nick Leong, VP of Engineering, Saakuru Labs As innovators in the transitional period from Web2 to Web3-based applications, we at Chainstack are proud to facilitate and support the growth of forward-thinking companies as they navigate this new digital frontier. One of these progressive collaborators is Saakuru Labs, a company striving to bridge the gap between traditional web applications and decentralized ones by eliminating user friction. Our partnership with Saakuru Labs epitomizes our mission at Chainstack. We strive to provide robust, scalable, and efficient blockchain infrastructure to progressive companies like Saakuru Labs, aiding them in unveiling the full potential of the thriving world of Web3. Together, we’re making it easier than ever for businesses and individuals alike to adopt and benefit from decentralization. Let’s explore our journey with Saakuru Labs in detail. How Saakuru Labs started with Chainstack Saakuru Labs were facing challenges in their ecosystem, and turned to us, motivated by a desire to strengthen their wallet SDK engine. Their expectations were simple yet demanding: a solution that offers stability, efficiency, and a reasonable pricing model. Like any company thriving in the Web3 domain, Saakuru Labs had distinct needs. They required a robust solution capable of overseeing the protocols they were looking to capture with the potential for future additions. Furthermore, they needed assistance in maintaining different RPCs while skillfully navigating the intricate maze of indexing, caching, and rate limiting. Overcoming these hurdles was no small task. But what truly mattered to Saakuru Labs was how we stood out from the countless other solutions available. They appreciated our support for specific blockchain protocols like Avalanche, our competitive pricing model that catered to their unique requirements, and most of all, our proactive and efficient customer service. Our capability to handle most of their node requirements boosted their confidence in our platform. The reception from Saakuru Labs was fantastic, and the realization that we were the right fit for them came largely from the expanse of our advantages—a combination of performance, pricing, accessibility, and direct support making us stand out. Once onboard, Saakuru Labs made full use of our platform. We became a significant contributor, fulfilling most of their network’s requirements, providing a solution catered explicitly to their needs. As we provided the best pricing model and supported the chains they were looking to capture, our robust Web3 infrastructure won their trust, complimented by the unwavering stability that we offered. Saakuru Labs on Chainstack in numbers Over the course of our partnership, Saakuru Labs has proudly maintained 10 active elastic nodes, harnessing a range of protocols including Arbitrum, Avalanche, Bitcoin, Ethereum, Harmony, and Solana. Their operations delve deeper into the world of blockchain with an expansive array of node requests; 299.3M archive node requests and 180.1M full node requests. The geographical diversity of Saakuru Labs’ usage is notable. Records indicate a significant volume of requests across various regions: 178M requests from France, 116M from London, 74M from EU3, 38M from Ashburn, 32M from the Asia-Pacific South East region, 26M from Dallas, 14M from Asia South East, and 2M from Amsterdam. Beyond geographic parameters, Saakuru Labs spread their operations across various protocols, including 227M requests on Avalanche, 200M on Polygon, 43M on BNB Smart Chain, 36M on Arbitrum, 17M on Ethereum, 10M on Harmony, 4.5M on Optimism, and 2.5M on Bitcoin. Over the recent period, we have seamlessly managed 384M eth_call and 179M eth_getTransactionReceipt requests, along with 38M eth_getBlockByNumber and 24M eth_blockNumber requests on full nodes. Furthermore, our archive nodes have adeptly handled 193M eth_call, 155M eth_getTransactionReceipt, 37M eth_blockNumber, and 35M debug_traceCall requests. This substantial activity underscores our capability to support Saakuru Labs’ operational needs effectively, ensuring they derive maximum value from our platform with each processed request. Figure 1: Saakuru Labs full and archive node RU allocation Saakuru Labs gained 412%+ in Web3 infrastructure ROI with Chainstack At Chainstack, we’re not only committed to delivering unparalleled value to our clients but also ensuring they achieve significant returns on their Web3 infrastructure investments. By partnering with us, Saakuru Labs has realized a remarkable cost-saving advantage over considerably higher-priced alternatives. Compared to Alchemy’s Scale plan at $21,615 and QuickNode’s Business plan at $30,125 monthly, including extra usage, our offering stands out not only for its affordability but also for the impactful ROI it delivers. Specifically, Saakuru Labs enjoys an impressive Web3 infrastructure ROI of 412%+ when comparing the significant cost savings of 86%+ against the next best alternative. Figure 2: Saakuru Labs Enterprise Debug & Trace profile price comparison; Source: Chainstack This exceptional ROI underscores our dedication to providing high-quality, efficient services at scale, ensuring our clients receive the best possible value and a significant return on their investment. These numbers are a testament to the success of our partnership with Saakuru Labs, reflecting our combined commitment to fuel innovation and growth across the Web3 landscape. What is Saakuru Labs? Saakuru Labs plays a key role in paving the way for digital innovation, particularly in the realm of blockchain technology and Web3 infrastructure. Their focus? Making the shift from traditional web applications (Web2) to decentralized ones (Web3) as seamless as possible. And now that friction is the last thing users want when adopting new technologies, they’ve devoted much of their efforts to eliminating complications such as gas fees, a common barrier to blockchain interaction. At the heart of Saakuru Labs’ offerings is a comprehensive Web3 development package. This package aims to provide companies with the tools needed to bring about a smooth, gas-less, and seedless user experience on the blockchain. Their strategies and solutions are multifaceted, including a wallet SDK compatible with multiple mobile platforms for convenient integration, to blockchain data aggregation services for efficient smart contract interaction. Figure 3: Saakuru Labs mobile SDK; Source: Saakuru Labs Leveraging the Oasys blockchain, Saakuru Labs also operates an L2 chain of their own—Saakuru, eliminating cost-related barriers for Web3 developers and enabling unprecedented levels of on-chain activities. The result? Unleashing the full power of blockchain without the crippling constraints of high gas fees. Saakuru Labs’ crown jewel, however, has to be the Saakuru App. A one-stop-shop for all your Web3 needs—a combination of a secure non-custodial multichain wallet, automated asset management, as well as a DApp store and browser. It offers users a streamlined, easy-to-use UI to manage their NFTs and crypto, thereby reducing barriers to entry into the crypto world. Supporting Saakuru Labs in their Web3 journey has been incredibly rewarding. Their innovative approach to simplifying the transition of Web2 businesses to Web3 is exactly what the industry needs, and we’re proud to provide the infrastructure that helps them achieve their goals. Eugene Aseev, CTO & Co-Founder, Chainstack. Bringing it all together As we reflect on our journey with Saakuru Labs, it becomes apparent that a shared goal is the heart of our partnership: to make Web3 accessible, secure, and profitable for businesses around the globe. Saakuru Labs has pioneered a Web3 development package that eliminates common barriers to entry for Web2 companies, making their transition to decentralization a one-day endeavor. Implementing this package involves embracing innovative solutions: a gas-less blockchain for real-time transaction validation, a wallet SDK for easy mobile app integration, an aggregated blockchain data service for efficient asset and contract management, and comprehensive gamification tooling for seamless decentralized game development. At the core resides the Saakuru chain, solving a wide range of use cases across industries, without gas fees acting as a deterrent. Sound infrastructure is the backbone of any Web3 advancement, and with Chainstack supporting Saakuru Labs, we’ve shown that we meet the unique challenges of this dynamic landscape head-on. Our comprehensive protocol support, stability, effective pricing model, and quality support have not just solved problems but propelled a vision. Together, we’ve successfully strived to make the Web3 landscape more accessible and secure for users, paving the way forward for further adoption. Working with Saakuru Labs has been revelatory. As they continue to use Chainstack to navigate this fast-paced digital landscape, we look forward to seeing how far we can go together—breaking barriers, solving problems, and harnessing the full potential of Web3. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Scaling Hyperliquid together: Chainstack at HLH hackathon Join us at HLH in Seoul, September 21–22! Ship with Chainstack — the most complete stack for Hyperliquid builders. Shipping doesn’t stop on Hyperliquid. Trader bots are rolling out, orderbook trading keeps picking up, and more teams are putting HyperEVM through its paces. The next milestone is HLH, the first Hyperliquid hackathon in Seoul, bringing hundreds of builders under one roof. Chainstack is in the mix with the full stack for builders: low-latency RPC, a Hyperliquid testnet faucet, archive nodes, WebSockets, and a live API reference — everything you need to get live on Hyperliquid fast. About HLH: Hyperliquid’s first in-person hackathon HLH runs September 21–22 in Seoul, bringing 300 builders together to ship on HyperEVM and HyperCore. The space will stay open around the clock so teams can keep building. Throughout the weekend, there will be technical workshops, 1:1 guidance, and talks from Hyperliquid contributors and ecosystem partners. Panels and keynotes add more context on where Hyperliquid is heading and how to build on it today. On the final day, projects are demoed in front of judges and ecosystem partners. The strongest builds get recognition on stage and support to keep pushing after the hackathon. If you want to hack, you can apply for a builder spot. You can also join as a general attendee to take part in the talks and sessions. Head to hlh.builders for both. What’s on the agenda The hackathon tracks are tied to Hyperliquid’s “House All Finance” vision. Projects will explore: Programmable trading — building on HyperEVM and Corewriter HIP-3 markets — deploying new perpetuals at the builder level Builder codes & integrations — turning code into monetizable tools Developer tools & public goods — infra and open-source that push the ecosystem forward Catch us at HLH, too! Don’t miss Chainstack Director of Developer Experience, Ake, walking through the fastest way to get onboarded to Hyperliquid and start shipping. Building on Hyperliquid with Chainstack Building on Hyperliquid takes reliable infra. That’s what we’re bringing to HLH. The full stack, ready to go: Hyperliquid faucet — grab testnet HYPE and start testing right away. Deploy Hyperliquid RPC — choose between Global Node (low-latency access to HyperEVM on mainnet/testnet), Dedicated Node (managed, cost-efficient setup), or Archive + WebSockets (full history and real-time streams). API method availability table — 100+ Hyperliquid methods tracked with live support status per endpoint, so you know exactly what works where. Trading bot on GitHub — an open-source starter bot wired for Hyperliquid that you can fork and ship. This stack is live today and keeps growing. New endpoints, more dev tools, and constant updates so Hyperliquid builders can focus on shipping. Create Hyperliquid Node Next stop: Seoul (Sep 21–22) If you’re building on HyperEVM or HyperCore, it’s the weekend to get questions answered and move a project from idea to running code. We’ll be there with the full stack for Hyperliquid builders — faucet, managed RPC (Global and Dedicated), archive nodes, WebSockets — and Ake’s session on getting developers live fast. See you there! #### Scroll Faucet – Claim Free Scroll ETH Introducing the Scroll ETH Testnet Faucet: Your Gateway to Testnet ETH. In the world of Web3 development, you will always need testnet tokens. Whether you’re experimenting with smart contracts, building decentralized applications, or refining your blockchain solutions, access to testnet tokens is necessary. We understand the challenges and frustrations that developers face when building DApps. That’s why we created the Scroll ETH Testnet Faucet, designed with Web3 developers like you in mind. Get Scroll ETH How to use the Scroll faucet Once you’re registered ↗ and have an API key ↗ set up on the Chainstack platform, you can get up to 0.5 Scroll ETH every 24 hours. This ETH can be used to send transactions on the Scroll testnet, deploy your smart contracts, and test their different functions before pushing them to mainnet, which involves real funds. For a step-by-step tutorial on how to request ETH from our Scroll faucet, watch the video demo below: Why do I need Mainnet ETH in order to request funds from the faucet? Our faucet requires you to hold 0.002 ETH in your wallet on the Ethereum Mainnet, in order to use it. This measure helps ensure a fair usage and prevents exploitation of the faucet. Why does it take so much time for my tokens to arrive? Usually, the process of receiving your tokens should be fast, but sometimes the network may be congested and you might need to wait a little while. If you do not get your tokens within 15 minutes, please contact us on Telegram or Discord. I get an error saying “The user can only receive funds every 24 hours.” In order to ensure an even distribution across the Ethereum developer community, we have capped the maximum amount of Scroll ETH that you can request to a maximum of 0.5 per day. I get an error saying “Something went wrong. Check credentials and try again.” You might’ve entered an incorrect API key or wallet address. Please check them again, refresh the page, and try one more time. In order to generate your API key, you will need to sign-up via the Chainstack console first. Check out the video above to see how to generate your own API key and request Scroll ETH from the faucet. If you are sure that the API key is valid, your wallet address is correct, and you still can not claim tokens, you can contact us on Telegram or Discord so we can assist you. Do you need help when using the faucet? You can contact us via Telegram or Discord and one of our team members will help you to get testnet tokens. Now that I have my funds, what shall I do next? Tell us about the DApp that you are building and tag our @ChainstackHQ X (Twitter) account in your post. We would like to learn more about your DApp. I want the best Scroll nodes If you are looking for fast and reliable Scroll nodes, you can sign-up on the Chainstack console and deploy one for free. We support over 20 different blockchains, and we also provide additional developer tooling. What is Chainstack? Chainstack is the limitless Web3 development stack for blockchain developers. Every protocol, every API, every tool that you’ll ever need to build any DApp at scale. Get Scroll ETH Where can I learn to build DApps? Our Web3 documentation is the perfect place to get you started. You will find everything you need in there from smart contract tutorials to APIs, and recipes. Let’s get you started with this quick glossary: What is a faucet? A faucet is a developer tool that gives you testnet tokens to use when testing your smart contracts or interacting with DApps on test networks. The Chainstack faucet gives you Scroll Sepolia testnet ETH to test your smart contracts before deploying them to production. What is the Scroll testnet? According to the Scroll team “The Sepolia Testnet consists of Ethereum’s Sepolia Testnet and the Scroll Sepolia test network. Sepolia is an Ethereum test network, while Scroll Sepolia is a zero knowledge rollup testnet deployed on top of the former.” Think of the Scroll Sepolia testnet like a playground for developers. You can deploy your smart contracts and test your DApps’ functions, before pushing them to production. What is the meaning of drip? When it comes to Web3 faucets, the drip refers to the amount of testnet tokens that you can get from a faucet each day. In your case, this would be 0.5 Scroll testnet ETH daily. What are Scroll testnet Ethereum tokens? A Scroll testnet token is the gas fee token for the Scroll testnet. Testnet tokens do not have real monetary value (these tokens are not like the “real” Ethereum), but they play an important role in covering gas costs. You will need them in order to deploy your smart contracts on the Scroll testnet, and interact with those contracts through transactions. Do you want to ask us something else? Join our Telegram or Discord communities, so you can talk directly to our team members there. Power-boost your project with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Securing the infrastructure for decentralized tokenized markets with AllianceBlock and Chainstack Empowering decentralized tokenized markets with seamless cross-chain communication Working with Chainstack has been a game-changer for AllianceBlock. Their team has consistently demonstrated their ability to support our technology and help us stay focused on accelerating adoption of the decentralized tokenized markets. Matthijs de Vries, Founder and CTO, AllianceBlock AllianceBlock is a well-known DeFi technology provider, with a mission of accelerating the adoption of decentralized tokenized markets by financial institutions, Web2 startups, and Web3 developers. With their end-to-end infrastructure, they offer a comprehensive solution that challenges traditional financial systems and capital market infrastructure.  With a track record of successful product launches and a strong ecosystem of partners, AllianceBlock has established itself as a leader in the field of decentralized finance (DeFi). They specialize in providing tokenization infrastructure, offering a complete framework for managing tokens throughout their lifecycle, and driving the adoption of decentralized technologies. With each new partner, or project using its solutions, AllianceBlock is paving the way for the future of finance by enabling businesses to thrive in the decentralized tokenized market. In this transformative journey for the adoption of decentralized tokenized markets, Chainstack had the opportunity to lend its expertise. Our team rapidly addressed a technical challenge AllianceBlock faced, demonstrating our dedication to helping clients maintain system stability and focus on their core innovation efforts. This collaboration stands as a testament to Chainstack’s commitment to encouraging growth and innovation in the ever-evolving world of DeFi. So, without further ado let’s dig further: Complete lifecycle infrastructure for decentralized tokenized markets  AllianceBlock is a leading infrastructure provider in the decentralized tokenized market, offering businesses a comprehensive solution to navigate and leverage this ecosystem. They provide a tokenization engine, compliance solutions, data management tools, project financing capabilities, and decentralized exchange for trading, among other tools.  Their technology covers the entire lifecycle of tokens in the decentralized tokenized markets, ensuring businesses have the necessary tools to succeed. Building the next generation of NFTs  The Nexera Protocol, developed by AllianceBlock, introduces a new era for NFTs by enabling the creation of MetaNFTs. These third-generation NFTs have mutable data and metadata, allowing them to evolve dynamically with new properties and restrictions over time.  MetaNFTs serve as on-chain mutable storage entities that can interact with both on-chain and off-chain data. By supporting existing and emerging NFT standards, MetaNFTs overcome the limitations of current standards and provide developers with the flexibility to adapt and integrate future standards.  This versatility opens up a wide range of applications for NFTs, including art pieces, games, digital collectibles, and financial solutions. A single MetaNFT can represent multiple use cases simultaneously and adapt to future needs. Universal cross-chain messaging  The Cross-Messaging Protocol is a chain- and data-agnostic protocol that allows transmitting any type of data or metadata across the networks it is deployed on. The protocol acts as a cross-chain messaging base layer on which a DApp can build to support multiple networks in their applications.  The Cross-Messaging Protocol managed the transmission and sending of messages across networks. The protocol works with the Hedera Consensus Service for the validators to ensure that the data and metadata sent between different blockchain networks are validated and signed. Crowd-sourcing decentralized innovation   AllianceBlock Fundrs is a decentralized capital-raising protocol where Seekers, such as startups or high-net-worth individuals, raise capital and resources from the AllianceBlock community of industry experts, institutions, and capital providers, known as Funders. The platform offers a reputation system powered by rALBT, allowing anyone to get involved by providing feedback, sharing expertise, and shaping the project’s future direction.  Fundrs offers a more open and inclusive way to source insight, expertise, and participation from a wider audience of investors. It also introduces multiple methods for raising capital, including private sales and presales, milestone-based financing, and a decentralized lottery mechanism. The platform’s participatory capitalism model aims to cultivate a sustainable capital-raising environment for both Seekers and Funders. Assembling a versatile Web3 toolkit   The DeFi Terminal by AllianceBlock is a comprehensive platform that provides a one-stop-shop for DeFi protocols and solutions, with distinct areas for retail users, developers, and project leaders, offering no-code solutions and ready-to-use solutions such as liquidity mining and staking, allowing for easier participation and faster scaling. NexeraID is a self-sovereign identity issuance & verification platform that empowers companies to seamlessly onboard users to Web3 using self-custodial or custodial wallets and streamline complex compliance workflows while safeguarding users’ identity and assets. https://www.youtube.com/watch?v=JNrANboacMg The AllianceBlock Data Tunnel is a next-generation data marketplace platform that offers a decentralized and distributed ownership and control of data. It allows data contributors to monetize and benefit from their published data while also giving them the right to influence what happens with their data. The Data Tunnel is designed to function under a DAO governance model, where community or user-governed datasets will become the norm in the Web3 ecosystem. Fueling adoption, governance, and growth in the AllianceBlock ecosystem with the NXRA token The utility of NXRA starts at the protocol level, with the Nexera Protocol and Cross-Messaging Protocol incorporating NXRA in various ways. Any use case or product utilizing these protocols will use NXRA for payments, reputation mechanisms, rewards, and other purposes. NXRA’s utility extends to different areas in the AB ecosystem, including the Nexera Protocol, AllianceBlock DeFi Infrastructure, AllianceBlock Nodes, and AllianceBlock DAO. Holding NXRA is crucial for participating in governance, influencing decision-making, and shaping the future of AllianceBlock. The NXRA utility is intricately woven into the Nexera Protocol, ensuring its usefulness and effectiveness in  the ecosystem. It facilitates interoperability, security, scalability, integration, and decentralized governance at different layers of the protocol. NXRA also plays a role in encouraging participation, securing the network through staking, and providing access to exclusive features and benefits. Powering the AllianceBlock ecosystem with NXRA  In the ecosystem, NXRA is used for cross-chain payments, rewarding active participation, facilitating adoption, and integrating with various DeFi products and platforms. It improves the utility and value of AllianceBlock’s offerings, such as the DeFi Terminal, Data Tunnel, and AllianceBlock DEX. The introduction of AllianceBlock Nodes further strengthens the role of NXRA by securing the network and distributing rewards. NXRA serves as a means of reputation, identity, and governance in the ecosystem. It allows users to stake and earn rALBT, participate in decentralized marketplaces, and actively engage in dApp governance. The AllianceBlock DAO empowers token holders to participate in decision-making and shape the future of the ecosystem. The utility of NXRA is designed to scale in the ecosystem, providing benefits to institutions, builders, developers, and the community. It ensures the smooth functioning, adoption, and growth of AllianceBlock’s technology and solutions. AllianceBlock’s extensive ecosystem unites the best in the industry and beyond The AllianceBlock ecosystem stands strong with its extensive partnerships and long-term collaborations, forging connections with some of the most active networks in the industry. It has established strong ties with prominent networks such as Quant, Avalanche, and BNB Chain, ensuring interoperability and expanding its reach across multiple blockchain ecosystems.  AllianceBlock has also joined forces with traditional financial giants like the Swiss Blockchain Federation, GBG, and Open Wealth, showcasing its commitment to bridging the gap between decentralized finance and traditional finance.  The ecosystem has also actively engaged with vibrant startup ecosystems, such as Plug and Play’s Digital Asset vertical, encouraging innovation and driving forward the growth of the decentralized tokenized markets. Through these strategic partnerships and collaborations, AllianceBlock continues to strengthen its position as a leading infrastructure provider, encouraging an inclusive and interconnected ecosystem for businesses and individuals alike. Resolving Polygon node woes together When AllianceBlock encountered an issue with their Polygon node, they reached out to us for assistance. The node responded but failed to attain the latest block. Understanding the urgency of the situation, we expedited our efforts to address AllianceBlock’s concerns. We immediately launched an investigation and pledged to deliver a custom dashboard tailored to AllianceBlock’s needs. This dashboard would enable them to easily isolate and measure their requests and quotas. Chainstack engineering also proactively sought to provide the most cost-effective infrastructure profile suitable for high-request use cases like Polygon. Our support team ensured that the node was up-to-date and even surpassed the latest block recorded by the block explorer. We delivered on our word to stay proactive and engaged, readily providing updates and solutions as needed. Throughout the process, our commitment to delivering exceptional support to AllianceBlock remained unwavering. We continue to monitor their nodes, ensuring stability and optimal performance for their unique financial ecosystem. Resolution summary Prompt issue resolution: As soon as AllianceBlock reported issues with their Polygon node, we launched an immediate investigation to address their concerns. Custom dashboard creation: We delivered a custom dashboard for AllianceBlock that enabled them to effectively manage their requests and quotas. Cost-effective profile application: Our engineering team applied an infrastructure profile that best suited high-request use cases like Polygon, optimizing cost-effectiveness. Adequate node synchronization: We ensured that AllianceBlock’s node was not only up-to-date but surpassed the latest block recorded by the block explorer. Continued infrastructure monitoring: Our team continues to monitor AllianceBlock nodes, ensuring stability and peak performance, as well as timely support should the need arise. Bringing it all together AllianceBlock is a vital player in the decentralized tokenized markets, providing an extensive ecosystem of comprehensive solutions for businesses across sectors. Their revolutionary products, from MetaNFTs to cross-messaging protocols and decentralized capital-raising platforms, are reshaping the possibilities within DeFi and beyond. Working together with their team exemplified our dedication to support and encourage innovative ventures in the rapidly evolving DeFi landscape. By promptly addressing their technical challenge and assisting them with their Polygon node, we emphasized our commitment to facilitating seamless integration and system stability, enabling AllianceBlock to concentrate on their core innovation. Our team continues to ensure the operational excellence of AllianceBlock’s unique financial ecosystem, guaranteeing performance and stability. Our collaborative journey with AllianceBlock not only highlights our role as a reliable DeFi infrastructure partner but also underlines our shared vision of a more integrated and accessible future for finance. We’re proud to contribute to the ambitious mission of AllianceBlock’s team, and we look forward to fostering continued growth and innovation in the ever-evolving world of decentralized finance. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### See how Chainstack uses Chainstack for Chainstack Chainstack Self-Hosted is not just something we built for customers who want to run blockchain nodes on infrastructure they control. We use the same operational thinking inside Chainstack to run, supervise, and improve the Dedicated Nodes we provide to customers. That matters because Dedicated Nodes are not a nice marketing wrapper around a server. A Dedicated Node is isolated infrastructure, tuned for a specific workload, across a specific protocol, network, client, cloud, region, and node mode. Ethereum full node in London is one shape. Solana with heavy data access is another. BNB Smart Chain archive workloads are another. The easy way to run that business is to let every setup become a custom snowflake. The right way is to turn the repeatable parts into a control plane. That is where Chainstack Self-Hosted comes in. The short version Dedicated NodesSelf-HostedChainstack-run node infrastructure for teams that need isolated resources, high throughput, and custom configuration.The Chainstack node operations layer, packaged for teams that want to run nodes on their own infrastructure. Internally, that combination changes Dedicated Node operations from “build another custom setup” to “deploy a tested, observable, repeatable node stack, then tune what actually needs tuning.” It also gives us a brutal feedback loop. New protocols, clients, pre-configured setups, monitoring signals, and recovery workflows first meet Chainstack-owned traffic and production-like load before they become public Self-Hosted features. If a feature cannot survive our own internal workloads, it is not ready for someone else’s production environment. A Dedicated Node is not just a node The word “node” is dangerously small. It makes the work sound like this: Pick a client. Start a process. Wait for sync. Hand over an endpoint. That is the tutorial version. Production is less polite. A real Dedicated Node setup has to answer questions like: Which client and version should run this protocol today? What resource profile is safe for this network, this mode, and this workload? How do we know the node is healthy beyond “the process is running”? What happens when a chain upgrade lands on Friday? How do we detect sync drift before the customer notices? How do we keep deployment logic consistent across Ethereum, BNB Smart Chain, Base, Optimism, Polygon, Solana, and the next protocol that arrives with a different personality? This is why Chainstack Dedicated Nodes exist as a managed product. Customers get isolated infrastructure, choice of cloud and location, predictable billing, high performance, and Chainstack handling the operational work behind it. But inside Chainstack, we still have to run that operational work well. At scale, “expert humans with scripts” is not a platform. It is a calendar full of future incidents. Why Self-Hosted became useful internally Chainstack Self-Hosted was built for teams that want to own their infrastructure without building the whole node operations layer themselves. That is exactly the same problem we solve internally, only with a sharper edge. We run nodes for customers who expect reliability, performance, and fast support. We cannot afford mystery deployments, undocumented tweaks, or monitoring that only works when the person who built it is online. So the Self-Hosted model gives us a cleaner internal operating pattern: Deployment through right-sized, pre-configured setups instead of one-off setup notes. Client configuration captured in the product, not scattered across private scripts. Monitoring and alerts included in the operating model, not added after the node is already live. Recovery behavior designed into the system. Upgrade workflows that can be tested, reviewed, and repeated. Protocol additions that move through the same path from internal validation to customer-ready operations. For Dedicated Nodes, this means the under-the-hood work becomes more like running a factory and less like building every machine from loose parts. The customer still gets the bespoke outcome: the right chain, mode, location, resources, and configuration for the workload. We get a repeatable way to build and operate it. The boring magic: right-sized setups The most underrated part of blockchain infrastructure is not latency. It is defaults. Bad defaults create work forever. Good defaults quietly erase work before it exists. Chainstack Self-Hosted currently supports production deployments of Ethereum Mainnet, Sepolia, and Hoodi full nodes with Reth and Prysm. Publicly, that looks like a deployment wizard and supported setup options. Internally, the same idea is much more important: a pre-configured setup is a decision we do not want every operator to remake from scratch. For Ethereum, that means known client pairing, resource sizing, storage expectations, and snapshot-based bootstrapping. That is not just convenience. It is operational memory turned into product behavior. When we run Dedicated Nodes, this matters because every repeated manual decision is a chance for drift: One node gets a slightly different resource profile. One deployment uses an older client combination. One runbook forgets a monitoring check. One region-specific setup carries a workaround nobody remembers. Right-sized setups reduce that surface area. They give our teams a known starting point and let them spend attention on the parts that actually vary by customer workload. The punchline is simple: if you want customization at scale, standardize everything around it. Monitoring that starts before the incident Anyone can check whether a service is up. Blockchain nodes need better questions: Is the node synced? Is it catching up or falling behind? Are peer counts healthy? Is disk growth normal? Are execution and consensus clients disagreeing? Is Kubernetes fine while the blockchain client is quietly having a bad day? Chainstack Self-Hosted ships with an integrated observability stack: Grafana, VictoriaMetrics, alerting, Kubernetes metrics, host-level metrics, and the Chainstack blockchain-node-exporter for chain-specific health signals. chainstack.com/self-hosted page screenshot This is exactly the kind of visibility Dedicated Node operations need. A node can look alive and still be operationally wrong. The process is running, the endpoint responds, but the data is stale, the node is behind, or the next storage threshold is closer than anyone wants. The useful thing about building this into Self-Hosted is that monitoring stops being a side project. It becomes part of the node product. Chainstack Self-Hosted dashboard When we improve a dashboard, add a health signal, or discover that an alert is too noisy during a real internal rollout, that learning can feed back into Self-Hosted. The public product gets better because the internal environment is unforgiving. Internal traffic comes first A new protocol does not become easy because it has an RPC spec. It becomes easy after the annoying parts are understood: What does initial sync actually look like? Which client versions are safe? What does normal resource usage look like under load? What failure modes are common? What should the first dashboard show? Which alerts are useful, and which ones wake people up for no reason? What should the default deployment look like for production? That is why the validation path starts inside Chainstack, not on customer Dedicated Nodes. By the time a customer-facing Dedicated Node setup is live, the point is not to learn whether the setup works. The point is to run a known, supervised, production-grade configuration for that customer’s workload. When Chainstack adds or improves protocol support, we can route Chainstack-owned workloads through internal dedicated-node environments first. That can mean internal services, monitoring probes, benchmark jobs, traffic replays, and synthetic load shaped around patterns we already see on production nodes. The goal is not to copy one customer’s traffic. The goal is to recreate the pressure that real nodes face: request bursts, long-running reads, sync behavior, storage growth, client upgrades, and protocol-specific edge cases. That is where the setup earns trust. We can watch how it behaves when the chain is busy, when a client update lands, when storage grows faster than expected, or when a workload pattern makes a node uncomfortable. We can tune resources, adjust alerts, improve runbooks, and remove sharp edges before the setup becomes part of customer-facing Dedicated Node operations. Only after that does it make sense to turn the lessons into public Self-Hosted setup options. That is the path we want: Build the internal setup. Route Chainstack-owned traffic through it. Stress it with production-like load. Move it into Dedicated Node operations only when it is boring. Package the stable workflow for Chainstack Self-Hosted customers. Today, the public Self-Hosted release supports Ethereum full nodes. The roadmap is much bigger: by the end of 2026, we want Chainstack Self-Hosted to support every chain, starting with additional EVM-compatible chains and layer 2 networks, then expanding across the rest of the protocol lineup. The goal is not to dump every chain into the product as fast as possible. The goal is to make each chain boring enough to operate. That is harder. It is also much more useful. My mission is to make blockchains boring.If blockchains are ever going to support millions of people and businesses, they cannot feel like constant science experiments. pic.twitter.com/GtXlVNNh9L— Ξugene Aseev (@easeev) March 26, 2026 What this means for customers There are three customer-facing benefits to Chainstack using Chainstack this way. First, Dedicated Nodes become faster and more consistent to deliver. Standardized deployment logic reduces manual variation, while still leaving room for workload-specific tuning. Second, Self-Hosted gets better from real operations. Features are validated against the kind of node work Chainstack already does every day: deployment, sync, monitoring, updates, recovery, and protocol expansion. Third, the distance between managed and self-hosted infrastructure gets smaller. Customers who use Dedicated Nodes get Chainstack-managed infrastructure. Customers who use Chainstack Self-Hosted get the Chainstack operational layer on their own infrastructure. Different ownership model, same direction: less custom ops work, more reliable node operations. This is especially useful for teams that move between models. The products do not compete as much as they meet customers at different levels of infrastructure control. What we learned by using it ourselves The biggest lesson is that blockchain infrastructure does not become scalable when you add more servers. It becomes scalable when the decisions stop living in individual people’s heads. Self-Hosted forces the operational model into the product: What should deployment look like? What should health mean? What should recovery do? What should an upgrade show before it runs? What should a new protocol setup include before anyone trusts it? Those questions help us run Dedicated Nodes better. Running Dedicated Nodes helps us answer those questions better. That is the loop. And it is why “Chainstack uses Chainstack for Chainstack” is more than a funny headline. It is a useful product discipline. We use Chainstack Self-Hosted to make Dedicated Node operations more repeatable. We use Dedicated Node operations to make Chainstack Self-Hosted more real. Then we ship the parts that survive. Try Chainstack Self-Hosted Want the same node operations layer on infrastructure you control? Get started with Chainstack Self-Hosted and deploy your first node with monitoring, updates, and self-healing. Deploy a self-hosted node → FAQ What is Chainstack Self-Hosted? Chainstack Self-Hosted is a control plane for deploying, managing, and monitoring blockchain nodes on infrastructure you control. It brings Chainstack node operations workflows to your own hardware, private cloud, or dedicated servers. How is Chainstack Self-Hosted different from Chainstack Dedicated Nodes? With Dedicated Nodes, Chainstack runs isolated node infrastructure for you. With Chainstack Self-Hosted, your team runs the infrastructure while using Chainstack’s control plane for deployment, monitoring, updates, and node operations. How does Chainstack use Chainstack Self-Hosted internally? We use the same operational model behind Chainstack Self-Hosted to standardize how node setups are deployed, monitored, updated, and recovered internally. Before new setup logic becomes customer-facing, we validate it with Chainstack-owned workloads and production-like load. Why does internal dogfooding matter for customers? It turns operational lessons into better defaults: clearer deployment states, more useful monitoring signals, safer upgrades, and more repeatable recovery workflows. Customers get node setups shaped by the same operational work Chainstack uses to run blockchain infrastructure at scale. Does Chainstack test new node setups on customer Dedicated Nodes? No. Customer Dedicated Nodes are production infrastructure. New setup logic is validated first with Chainstack-owned traffic, benchmark jobs, traffic replays, and synthetic load shaped around production patterns. Customer-facing Dedicated Nodes run known, supervised configurations. #### Self-Hosted blockchain node: challenges and solutions Running a self-hosted blockchain node, which validates transactions and provides blockchain data to dapps, wallets, and exchanges, is a key way to participate in and help secure a decentralized network. But self-hosted blockchain node challenges often emerge after deployment, not during setup. Jameson Lopp, Co-Founder of Casa, a leading Bitcoin self-custody solution, highlights that he runs his own Bitcoin node to help ensure Bitcoin remains online: “I run my own Bitcoin node. You can strike down my machines, but others will rise to take their place.” I don't play games that end in tyranny of the majority.I run my own Bitcoin node.I run my own lightning node.I run my own nostr relay.I run my own Mastodon instance.My nodes project my will. You can strike down my machines, but others will rise to take their place.— Jameson Lopp (@lopp) August 10, 2024 While more individuals and organizations operating their own nodes enhances decentralization and network security, managing nodes remains challenging. The true difficulty arises after deployment, as nodes need to stay synchronized with the network, store increasing amounts of blockchain data, and remain compatible with protocol upgrades. Most teams choose between running nodes themselves, which creates significant operational burdens, or using a third-party provider, which reduces control over data and infrastructure. Chainstack Self-Hosted offers the best third option. It provides an easy-to-use control panel for deploying and managing full blockchain nodes, currently supporting Ethereum and the testnets Sepolia and Hoodi, on your own infrastructure, whether a private cloud, dedicated servers, or on-premises systems, without needing to develop custom management tools. With Chainstack Self-Hosted, node deployment takes minutes to hours instead of days or weeks. This article outlines the operational challenges of running a fully self-managed, self-hosted blockchain node and explains how solutions like Chainstack Self-Hosted can address them. Why self-host a blockchain node Many organizations prefer to set up and run blockchain nodes on infrastructure they control. Institutions such as exchanges, wallets, infrastructure providers, and financial organizations rely on direct access to blockchain data as part of their core systems. Operating nodes within their own environments enables these teams to interact directly with the network, independently verify transactions and blocks, and avoid reliance on third-party APIs. Many institutions operate their own nodes, including: Coinbase Kraken Consensys Circle Despite wide adoption, self-hosted blockchain node challenges remain significant for most teams. Setting up a self-hosted node is relatively straightforward, but organizations often underestimate the operational challenges of running fully self-managed, do-it-yourself (DIY) nodes in production environments. Ethereum founder Vitalik Buterin acknowledged that managing a node has become a complex DevOps task that is handled by professionals, despite this not being the original intention. “I feel like at every level we’ve implicitly made this decision that running a node is this oh so scary devops task that it is okay to leave to professionals.” I feel like at every level we've implicitly made this decision that running a node is this oh so scary devops task that it is ok to leave to professionals.IT IS NOT.We need to reverse this. Running your own Ethereum infrastructure should be the basic right of every individual…— vitalik.eth (@VitalikButerin) March 15, 2026 Here are what teams should expect when self-hosting a node, and the solutions to handle them: Challenges of running a self-hosted blockchain node Here are the key self-hosted blockchain node challenges teams should expect, and the solutions to handle them: Challenge 1: Time to sync nodes Even after deployment, a node is not immediately ready to use. Before it can serve applications, it must download the blockchain data and synchronize with the latest block and global state. Teams already spend significant time securing and setting up the initial required hardware and software. Then, they must wait days to weeks for the node to fully run by downloading blockchain data and syncing their node to the latest Ethereum block and the current global state. For example, according to Besu, a popular software for Ethereum nodes, a fast sync, which downloads block headers and transaction receipts and verifies blocks from the genesis (first) block, takes 1.5 days, while a full sync, which downloads the entire blockchain state, takes weeks. Teams can greatly reduce sync time by using node snapshots or starting from a recent, verified state instead of all historical data when setting up Chainstack Self-Hosted. While teams can still always choose a full sync, many protocols, including Polygon, Celestia, Base, and Optimism, now recommend snap sync to bring nodes online more quickly. Challenge 2: Using enterprise-grade architecture Institutional teams require enterprise-grade node infrastructure that is reliable and scalable from setup through maintenance. Under the hood, Chainstack Self-Hosted runs on enterprise-grade Kubernetes, delivering reliability, scalability, and operational ease without requiring operators to build or maintain the underlying architecture. Node runs in secure environments with encryption and strict access control. When any self-hosted node fails, operations can choose to fallback to Chainstack’s production-level RPCs, with 99.99% uptime, 24/7 SLA-backed operations, and low-latency global endpoints, trusted by more than 1,000 customers. Currently, Self-Hosted supports Ethereum and the testnets Sepolia and Hoodi, with plans to expand to support over 70 other protocols via Chainstack’s RPCs. Chainstack Self-Hosted collaborates with top industry infrastructure, using two of the most well-established and popular clients for its Ethereum nodes: Reth as the execution client and Prysm as the consensus client. It features predefined configurations that coordinate components and reduce the risk of misconfiguration. The Chainstack Self-Hosted control plane interface to set up a new node Challenge 3: Node monitoring Even once the setup is complete, fully self-hosted node operations face much overhead in maintaining nodes. Fully self-hosted node operators are fully responsible for monitoring their status, tracking synchronization, and diagnosing failures when nodes become unresponsive or fall behind the network. Without a centralized management system, operators frequently spend considerable time developing and maintaining custom monitoring tools and scripts to track node infrastructure, or they might not even realize when their nodes fall out of sync. Nodes falling out of sync are common for various reasons, making reliable monitoring and visibility essential. As of March 24, 2026, Ethernodes estimates that 29 percent of nodes are out of sync at the execution layer, and 6.2 percent at the consensus layer. Chainstack Self-Hosted gives teams full visibility through an initiative UI control panel, with access to deployed nodes, their status, and configuration details, while still allowing teams to retain full control of their nodes. The Chainstack Self-Hosted control plane that shows the status, settings, and access and credentials to a specific node Chainstack Self-Hosted includes built-in integrations with popular third-party tools, such as Prometheus (Monitoring and Observability), Grafana (Observability), VictoriaMetrics (Monitoring and Observability), Keycloak (Identity Management), and Temporal (Workflow maintenance). In addition to monitoring, Chainstack Self-Hosted will offer options for handling failed nodes. It can automatically recover them through self-healing, eliminating the need for manual intervention or custom recovery tools. Configurable failover enables operators to define where traffic is routed when a node is unavailable, using a secondary node, a production-grade, Chainstack high-performance RPC endpoint, or an endpoint you specify. Challenge 4: Updating nodes Node operators must consistently update their software to remain compatible with the network, as blockchain networks regularly update their protocols and client software, making it challenging to stay current. Ethereum currently follows a twice-yearly hard fork schedule that requires nodes to update before each hard fork or risk incompatibility with the chain.  While node operators do not need to upgrade each time a new client version is released, they are encouraged to update periodically. As of 2026, Reth, the execution layer client, has released 8 updates, and Prysm, the consensus layer client, has released 2. In 2025, Reth published 33 releases, and Prysm published 18. Client release frequency ClientLayer2025 Releases2026 Releases (YTD, as of March)RethExecution338PrysmConsensus182Total5110 Following and managing updates across multiple nodes requires built-in processes, time, and risks of inconsistencies and misconfigurations. Instead of following community-run channels or client release logs, self-hosted node operators save time and operational hassle by using Chainstack Self-Hosted to manage updates and configure node upgrades. Operators can update multiple nodes simultaneously through the centralized orchestration system, rather than updating them one by one. It also includes self-healing and high-availability features, notifying operators when updates are available, and allows them to control when to apply updates. The Chainstack Self-Hosted control plane that shows multiple self-hosted nodes  Fully self-managed (DIY) vs Chainstack Self-Hosted CapabilityFully Self-Managed (DIY)Chainstack Self-HostedNode deployment timeDays to weeksMinutes to hoursSync methodFull sync only (manual)Fully sync, Snap sync supportedClient configurationManual, error-pronePre-configured Reth + PrysmMonitoringCustom scripts requiredBuilt-in UI control panelObservability integrationsBuild yourselfPrometheus, Grafana, Temporal, KeyCloak, VictoriaMetrics (planned)Software updatesNode-by-node, manualCentralized orchestrationFailed node recoveryManual interventionSelf-healing (planned)Failover routingCustom setup requiredConfigurableArchive node supportBuild yourselfPlanned Q2 2026Multi-endpoint load balancingBuild yourselfPlannedInfrastructure controlFullFull (your infrastructure) 📖 Learn more about DIY vs Chainstack Self-Hosted. Future of self-hosted blockchain node infrastructure Chainstack Self-Hosted is currently in beta, with a roadmap extending through 2026.  Future releases include solving the following operational challenges: Connecting multiple applications to a single node: Teams running multiple services against the same node currently manage endpoint routing themselves. Chainstack Self-Hosted plans to introduce support for multiple RPC endpoints per node and load balancing across nodes, allowing operators to manage this directly through the control plane. Running archive nodes: Applications that require access to the full historical chain state, such as analytics platforms, block explorers, and compliance tools, depend on archive nodes that store the entire network history and require 15 TB or more of storage on Ethereum. Chainstack Self-Hosted plans to introduce archive node support in Q2 2026, deployable through the same control plane as full nodes. Conclusion Running a self-hosted blockchain node is essential for decentralized networks and valuable for institutions and developers who want full control over their infrastructure. Deploying a node is relatively straightforward, but operating it reliably over time introduces significant operational complexity. Nodes must stay synchronized with the network, remain compatible with client updates, provide clear monitoring and diagnostics, and recover from failures without disrupting applications. DIY self-hosting gives teams full control over their infrastructure, but maintaining node reliability often requires significant operational effort. Chainstack Self-Hosted directly addresses the most common self-hosted blockchain node challenges — deployment time, monitoring, updates, and recovery — letting teams fully own their infrastructure while using an enterprise-grade platform to manage it faster and easier than a DIY setup. It offers a control plane for deploying and managing blockchain nodes within an organization’s own infrastructure. It standardizes deployment and management workflows, allowing teams to self-host confidently while maintaining full control over their infrastructure and significantly reducing operational complexity. To learn how to join the beta, contact the Chainstack Team. For more resources, review the Chainstack Self-Hosted docs and tutorial guide to set up a self-hosted node on Ethereum Hoodi testnet. Deploy Chainstack Self-Hosted → FAQ What is a self-hosted blockchain node? A self-hosted blockchain node is a server that validates transactions, verifies blocks, and provides blockchain data directly to applications, running on infrastructure under the operator’s control.Chainstack Self-Hosted currently supports full nodes that provide blockchain data and validator nodes that validate transactions and blocks are on the roadmap for late 2026. Why do organizations run their own nodes? Organizations run their own nodes to directly verify blockchain data, maintain control over their infrastructure, and avoid relying on third-party APIs for critical systems. What are the main self-hosted blockchain node challenges? Running a self-hosted node requires managing synchronization, monitoring node health, synchronizing client software, and keeping client software up to date with protocol changes. What is Chainstack Self-Hosted? Chainstack Self-Hosted brings the power of Chainstack’s blockchain infrastructure platform to your own infrastructure. Deploy, manage, and monitor blockchain nodes on your own hardware or cloud environment while maintaining complete control over your data and infrastructure. How does Chainstack Self-Hosted simply operations of running a self-hosted blockchain node? Chainstack Self-Hosted simplifies node operations by providing preconfigured clients, orchestration for updates, and built-in visibility into node status, while maintaining full infrastructure control. Related Reading DIY vs Chainstack Self-Hosted How to run a self-hosted blockchain node on HOSTKEY Guide to set up a Chainstack Self-Hosted node Chainstack Self-Hosted Docs Ethereum nodes and clients #### Self-hosted blockchain node: DIY vs Chainstack Self-Hosted Getting a blockchain node running isn’t the hard part. The hard part is everything that comes after — keeping it synchronized, updated, monitored, and available, day after day. Most teams underestimate this. Deployment goes smoothly. Then a node falls out of sync at 2am. A protocol hard fork requires coordinated updates across every node you run. A client crashes and nobody gets alerted. This is where DIY self-hosting gets expensive — not in servers, but in engineering time. Running a self-hosted blockchain node gives full infrastructure control, but maintaining it reliably is where most teams struggle. The good news: you don’t have to choose between control and operational sanity. But you do need to be deliberate about which path you take. Why organizations run a self-hosted blockchain node Organizations choose a self-hosted blockchain node for compliance, control over data, and predictable infrastructure costs at scale. For many teams, self-hosting isn’t optional — it’s a requirement: Compliance: Certain industries mandate on-premises or jurisdiction-specific infrastructure. Third-party RPC providers aren’t on the table. Control: Direct access to blockchain data without rate limits or dependency on external APIs is critical for exchanges, wallets, and high-volume applications. Cost: At scale, self-hosting is significantly more cost-effective than paying for managed node services. The question isn’t whether to self-host. It’s how much of your team’s time you want to spend on infrastructure versus building your actual product. Two paths: build it yourself or use a control plane Teams that self-host typically choose one of two approaches: Build it yourself (DIY): Assemble open-source components, write your own deployment configs, set up monitoring, and maintain everything in-house. Chainstack Self-Hosted: Deploy a control plane on your own infrastructure that handles the complexity — while you retain full ownership of the underlying servers and data. Both give you full infrastructure control. The difference is how much of your engineering time goes into building and maintaining the plumbing versus building your product. The reality of running a self-hosted blockchain node yourself Setup and installation A production blockchain setup requires multiple systems working together: container orchestration, storage provisioning, networking configuration, and monitoring — each with its own dependencies. Storage provisioning alone involves several components that need to coordinate correctly; a misconfiguration at any layer can prevent nodes from starting or corrupt existing data. For a single Ethereum node, this is manageable for someone with the right expertise. The challenge compounds when you add more nodes or additional protocols. Each new protocol means rebuilding the deployment system from scratch. Expect 2+ weeks to get a production-ready setup running for the first time. Node deployment An Ethereum node requires two separate clients — an execution client and a consensus client — that must communicate continuously. Configure them incorrectly and they won’t connect. Choose the wrong sync mode or miscalculate storage requirements and you’re troubleshooting days later. 2 Docker containers for Consensus client and Execution client. Source: dev.to Every deployment decision — resource allocation, storage sizing, sync strategy — requires deep familiarity with both Kubernetes and the specific blockchain clients you’re running. And every decision becomes a configuration artifact that someone on your team needs to maintain. Ongoing operations Running nodes is an ongoing job. Client updates, security patches, sync issues, and failed nodes all need attention. Without a centralized management layer, this knowledge lives in runbooks and whoever originally built the system. The Node Runner blueprint comes with a monitoring dashboard: Source: dev.to Expect roughly 4 hours per week per engineer to keep a DIY setup healthy — more when something breaks or a protocol hard fork requires a coordinated upgrade across all your nodes. Chainstack Self-Hosted: the same control, less overhead Chainstack Self-Hosted runs on your infrastructure — your servers, your cloud, your data. The difference is that deployment, configuration, monitoring, and updates are managed through a control plane rather than custom scripts and runbooks. Setup in minutes, not weeks Installation runs in 5–10 minutes. The platform bundles production-ready configurations for authentication, workflow orchestration, state management, and the control panel itself. The components are tested together — you’re not assembling them from scratch. Deploy nodes through a web interface Select your protocol and click deploy. Chainstack Self-Hosted provisions Reth and Prysm with configurations that have been tested in production. Resource allocation, storage sizing, and sync modes are predetermined based on real-world requirements — not your best guess. The Chainstack Self-Hosted control plane interface to set up a new node As the platform adds protocols, they deploy through the same interface with the same tested approach. One node or twenty, the process is the same. Centralized operations Updates, monitoring, and recovery all happen through the control panel. When nodes fail, self-healing kicks in automatically (planned). Failover routing lets you define where traffic goes — a secondary node, a Chainstack RPC endpoint, or one you specify. You’re not maintaining separate tooling for each blockchain you support. The trade-off: you’re working within supported configurations rather than customizing every component. For the vast majority of teams, the tested defaults are faster and more reliable than custom setups. If you have genuinely specialized requirements, DIY may still be the right call. Learn more about Chainstack Self-Hosted → The real cost: engineering time Snapshot downloads, storage sizing, and failed restarts: Source: dev.to Infrastructure hardware costs are easy to calculate. Engineering time is less visible but often larger. Building a production-ready DIY setup requires approximately two weeks from someone experienced with Kubernetes and blockchain infrastructure. Ongoing maintenance runs around 4 hours per week. At typical senior engineer rates, that’s roughly $6,000 upfront and $15,000+ annually — for a single protocol. The math gets worse at scale. Three protocols don’t cost three times as much in engineering time; they cost more, because you’re coordinating updates and troubleshooting interactions across multiple systems. Chainstack Self-Hosted has a licensing cost. But the infrastructure maintenance burden drops significantly, and the compounding value increases as you scale. More importantly, engineering hours spent on infrastructure are hours not spent on the product that differentiates your business. For teams with 1–2 nodes and in-house expertise, DIY can work fine. For teams running 10+ nodes across multiple protocols, or teams that need to move fast, the calculation shifts quickly. DIY vs Chainstack Self-Hosted comparison AspectBuild It YourselfChainstack Self-HostedSetup time2+ weeks of config and testing5–10 minutes with automated installerRequired expertiseDeep K8s and blockchain client knowledgeBasic Linux and command-line familiarityNode deploymentCustom config per protocolWeb UI with pre-configured clientsClient configurationManual, error-pronePre-configured Reth + Prysm (more clients coming)MonitoringBuild your own scripts and dashboardsBuilt-in UI control panelObservability integrationsBuild yourselfPrometheus, Grafana, VictoriaMetrics (planned)Software updatesNode-by-node, manualCentralized orchestrationFailed node recoveryManual interventionSelf-healing (planned)Failover routingCustom setup requiredConfigurableMulti-protocol supportRebuild everything per protocolExpanding roadmap (Ethereum now, more coming)Infrastructure controlFullFull (your infrastructure) Which path is right for you? Choose DIY if: Your team has deep Kubernetes and blockchain infrastructure expertise You have highly specialized requirements that go beyond standard configurations You’re running 1–2 nodes on a single protocol with no plans to expand Choose Chainstack Self-Hosted if: Getting to production quickly matters more than maximum customization Your roadmap includes multiple protocols — complexity multiplies with every new one You want enterprise features (auth, monitoring, orchestration) without building them Your team’s time is better spent on your product than on infrastructure maintenance Conclusion Both paths give you the same thing: blockchain nodes running on infrastructure you own and control. The difference is what it costs to get there and keep them running. Building from scratch means your team is in the infrastructure business. You own every component, which gives you maximum flexibility — and maximum maintenance responsibility. Chainstack Self-Hosted provides production-ready infrastructure in minutes. The control plane, authentication, monitoring, and orchestration are included and tested. As the platform adds protocols and clients, your infrastructure scales without additional engineering work. If your value is in your application or protocol, not in custom infrastructure tooling, Chainstack Self-Hosted is the faster path to production — and keeps staying faster as you scale. Deploy Chainstack Self-Hosted → FAQ Is Chainstack Self-Hosted really self-hosted if Chainstack manages it? Yes. Your infrastructure, your servers, your data. Chainstack provides the control plane software — the actual nodes run on hardware you own and control. What do I need to run Chainstack Self-Hosted? A Linux server with basic command-line familiarity. No Kubernetes expertise required — the installer handles the underlying infrastructure automatically. Can I switch execution or consensus clients? Currently Chainstack Self-Hosted runs Reth as the execution client and Prysm as the consensus client. Support for additional clients is on the roadmap. What happens if Chainstack goes down? Your nodes keep running — they’re on your infrastructure. You can also configure failover to route traffic to a secondary node or a Chainstack RPC endpoint if your self-hosted node becomes unavailable. How is Chainstack Self-Hosted different from Chainstack’s managed RPC? With managed RPC, your nodes run on Chainstack’s infrastructure. With Self-Hosted, the nodes run on yours — you get the same control plane but retain full ownership of the underlying servers and data. Build with Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. Related Reading Guide to set up a Chainstack Self-Hosted node Challenges: Self-hosted blockchain node How to run a self-hosted blockchain node on HOSTKEY Chainstack Self-Hosted Docs Ethereum nodes and clients #### Self-hosted blockchain nodes: 5 myths engineers believe in 2026 There’s a recurring argument in the RPC-provider space that goes roughly: self-hosted blockchain nodes are a maintenance trap, the ops burden is only getting worse, and the sensible move is to hand the nodes off to a managed provider. It’s an argument with real teeth, because the failure modes it points at are real: nodes silently falling behind the chain tip, client upgrades landing across dozens of ecosystems every week, archive storage that grows faster than the ops calendar can absorb. Anyone who has been paged at 3 a.m. for stale reads on a “healthy” Geth node has felt the truth of it. The problem is that the conclusion doesn’t follow from the evidence. It assumes self-hosting means what it meant in 2021 — bash scripts in a Git repo, a Grafana dashboard someone forked from a gist, and a compatibility matrix maintained mostly in Slack. That version of self-hosting is genuinely painful, and if that’s what a team is running, moving to managed infrastructure is reasonable. But it’s not what modern self-hosting looks like, and the industry moved on more than most operators realize. This article walks through five myths that keep engineers stuck on the old picture, compares dedicated infrastructure against modern self-hosted honestly, and marks the cases where each actually wins. Self-hosting in 2021 versus 2026: what changed isn’t the concept, it’s how much of it you still have to build yourself. The pain is real Before the pushback, the concession. The three failure modes cited most often against self-hosting are real, and on legacy self-hosted stacks they are the reasons teams give up: Silent desync. A node that loses tip and keeps serving requests is the worst kind of failure — invisible from health checks, visible to users. It’s also more common than most operators assume: Ethernodes’ live sync tracker has consistently shown roughly a quarter of Ethereum execution-layer nodes out of sync at any given time — 29% execution / 6.2% consensus as of early 2026. Upgrade fatigue across chains. Ethereum’s Fusaka upgrade landed on mainnet December 3, 2025, with coordinated changes operators had to stage across execution and consensus clients — see the Chainstack breakdown for what it actually shipped. Zoom out from a single fork and the pace is relentless: Reth shipped 33 releases in 2025, Prysm 18. Multiply that across L1s, L2s, and app-chains, and calendar management becomes a job. Storage growth. A full Ethereum archive node needs 18–20 TB of fast NVMe as of early 2026 and grows another ~1–2 TB per month. Capacity planning stops being a one-time exercise. None of these are strawmen. The question is whether the answer is “give up the perimeter” or “operate the perimeter properly.” Most of the migration-off narratives assume the first. That’s a category error, not an operational one. Where the industry actually changed Four things shifted between the pain that drove the current self-hosting narrative and the tooling available today. Clients matured. Reth shipped its production-ready 1.0 in June 2024 after two years of development and a Sigma Prime audit; Prysm and Lighthouse settled into predictable release cadences; and post-merge Ethereum operations are dramatically calmer than pre-merge. Client crashes and pruning surprises still happen, but they are no longer a weekly event. No-tweak clients emerged. Reth ships production-tuned by default. Launchers like Sedge (Nethermind) turned “run an Ethereum node” from a systemd-and-shell-script project into a single command — under five minutes to a running validator on your own hardware. Community efforts like BuidlGuidl’s client and dev-focused packages like ethereum-package (ethPandaOps, for devnets and testing) fill out the ecosystem. Kubernetes-based platforms like Chainstack Self-Hosted then wrap those clients in orchestration, monitoring, and self-healing — but the underlying clients stopped requiring babysitting years ago. GitOps ate deployment. Config drift — the primary cause of “why does prod behave differently from staging” — is a solved problem when every change is a pull request against a repo that Argo or Flux reconciles. Observability got real. Prometheus, Grafana, and purpose-built exporters (including Chainstack’s blockchain-node-exporter) surface the signals that health-check endpoints miss — chain-tip lag, peer count, storage pressure, sync state. The problem was never that self-hosting is hard. The problem was that most teams were self-hosting with 2021-era tooling in 2024. Myth 1: Self-hosting is prohibitively expensive The instinctive comparison — “managed RPC costs $X per million requests, a server costs $Y per month” — is the wrong one. The real comparison is total cost of ownership, and TCO is dominated by engineering time, not hardware. The Chainstack team put the DIY number at roughly two weeks of senior engineer time to stand up a production-grade Ethereum node, plus ~4 hours per week ongoing — around $6,000 upfront and $15,000+ annually per protocol at typical senior engineer rates. That’s the honest DIY figure, and it’s higher than most teams admit. But this cost isn’t intrinsic to self-hosting. It’s intrinsic to unautomated self-hosting. Once the operational layer is a product rather than a repo of shell scripts, the 4 hours/week collapses into notification-driven upgrades and dashboard reviews. That’s the entire premise of Chainstack Self-Hosted: the control plane, the observability stack, the upgrade tooling, and the recovery behavior come pre-assembled and tested, so the engineering hours previously spent on plumbing get returned to product work. At scale, the math tips further in favor of self-hosting. Three protocols on managed RPC aren’t 3x the cost of one — they’re linear-plus-egress. Three self-hosted nodes on a shared control plane aren’t 3x the operational load — they’re closer to 1.2x, because the control plane amortizes. Myth 2: Node upgrades constantly break infrastructure This was true. It’s substantially less true now, for two independent reasons. First, client release quality improved dramatically. Reth’s release notes and Prysm’s upgrade playbooks are now detailed enough that most hard forks land with a version bump and a restart. Emergency patches still happen — they will keep happening — but the “every release is an adventure” phase is over. Second, rolling upgrades became standard. A Kubernetes-native deployment can run two replicas of a node, drain traffic from one, upgrade it, verify sync, and rotate. The blast radius of a bad upgrade shrinks from “your app is down” to “one pod restarted.” Chainstack Self-Hosted formalizes this: when a new client version is available, operators are notified and control when it’s applied, rather than being surprised by an automated push or forgetting a manual one. The upgrade calendar becomes a queue in a control panel instead of a Google Doc. Myth 3: You need a large DevOps team The DevOps team you used to need was the one writing the tooling. The tooling exists now. Modern self-hosting is not “build a platform.” It’s “adopt a platform.” A single infrastructure engineer familiar with Kubernetes can operate a fleet of blockchain nodes if the control plane, monitoring, and upgrade workflows are already in place. Chainstack Self-Hosted’s stated position on this is unambiguous: no Kubernetes expertise required for basic deployment — the installer handles the underlying infrastructure, and the system requirements documentation is specific enough that hardware sizing is no longer guesswork. The team you actually need is smaller than the DevOps org described in most “why not self-host” posts. It looks like one platform engineer, part-time, plus whoever is already responsible for cloud infrastructure. A concrete data point. On a fresh Ubuntu box, cpctl install takes the machine from empty to a full production Control Panel stack — k3s, TopoLVM storage, Postgres-HA, Temporal, Keycloak, the UI, the deployments API, and the Grafana/VictoriaMetrics observability stack, 20/20 resources ready — in about 10 minutes of net execution time. That’s not marketing shorthand; the official quick-start documentation puts the typical install at 5–10 minutes, and a recent end-to-end run measured cpctl install itself at 3m 52s with the rest going to Kubernetes readiness waits. One command, one operator, no Kubernetes expertise required upfront. Myth 4: Dedicated infrastructure is always more reliable Not exactly. Dedicated infrastructure is more reliable than DIY self-hosting done badly. Compared to self-hosting done well, the comparison is more nuanced. DimensionDedicated (managed)Modern self-hosted (Chainstack Self-Hosted)Control over hardwareProvider-provisioned to your workloadFully yours: bare metal, cloud VPS, or hybridCustom clients / tracersSupported by most dedicated tiersFully supported; you own the runtimeData residency & complianceVendor’s regions and auditsYour perimeter; your SOC 2 / ISO scopeCost predictabilityProvisioned monthly commitmentCapEx or cloud spend you already controlFailoverVendor’s shared fleetConfigurable failover to Chainstack Cloud when neededObservability accessVendor’s GrafanaYour Grafana, your metrics, your retentionUpgrade timingVendor’s scheduleYours, per-nodeVendor lock-inEndpoint swap works both ways, but pricing power sits upstreamPortable — the underlying clients (Reth, Prysm) are standard The honest read: dedicated infrastructure is genuinely simpler if the provider’s constraints line up with yours. When they don’t — regulated data, custom execution logic, a jurisdiction the vendor doesn’t serve, or workloads that make provisioned capacity uneconomical — self-hosted wins. Myth 5: Self-hosting means constant firefighting Firefighting is what happens when signals arrive too late to act on. Modern self-hosted stacks catch problems earlier because they instrument the right things. Chainstack Self-Hosted ships with an integrated observability stack — Grafana, VictoriaMetrics, and the blockchain-node-exporter — that watches chain-specific signals (sync lag, peer count, finalization gap), not just process liveness. That’s the difference between “the node is up” and “the node is right.” The June 2026 release added built-in scrapers for the Control Panel, PostgreSQL, Temporal, and the node containers, plus direct log surfacing in the node overview — so wiring diagnostics into an existing observability stack no longer means assembling exporters by hand. Combined with self-healing behavior and configurable failover to Chainstack Cloud RPC when a self-hosted node needs to be taken offline, the on-call profile looks less like “always on” and more like “scheduled review.” When dedicated infrastructure is the right call Self-hosting is not the answer for every team. Dedicated or managed infrastructure is the better choice when: The team is under five engineers and blockchain infra is not a core competency. The workload is a prototype, a hackathon project, or a temporary campaign. Traffic is bursty in ways that provisioned capacity would waste. There’s no in-house Kubernetes familiarity and no appetite to acquire it. The application is genuinely stateless with respect to node control — no custom tracers, no exotic RPC extensions, no data residency requirements. In those cases, Chainstack’s managed Global Nodes and Dedicated Nodes exist for exactly that reason — and are worth evaluating on latency and price rather than ideology. When self-hosted is the better long-term investment Self-hosted wins when the operational maturity has caught up with the workload: Regulated environments where data residency, SOC 2, and ISO 27001 scope are non-negotiable. High-volume trading, wallet, or exchange workloads where per-request pricing at scale exceeds a fixed hardware bill. Applications with custom execution logic — tracers, forensic tooling, MEV pipelines. Multi-region deployments where the vendor’s regions don’t line up with your users. Teams with existing Kubernetes competence, for whom “one more StatefulSet” is a Tuesday. Conclusion Most of the current “move off self-hosted” argument treats self-hosting as an operating model that hasn’t changed. It has. Between mature clients, Kubernetes-native orchestration, GitOps, purpose-built observability, and integrated control planes like Chainstack Self-Hosted, running your own nodes in 2026 has more in common with running a well-instrumented microservice than with the pager-driven ops of five years ago. The interesting question isn’t “self-hosted or managed.” It’s “which of my workloads have outgrown managed, and which never should have left.” Answer that honestly, and the infrastructure choice follows. Try it Chainstack Self-Hosted runs on infrastructure you control — bare metal, cloud VPS, hybrid. The quick start guide takes an Ubuntu box to a running Control Panel with cpctl install — a single command, typically 5–10 minutes end to end. The system requirements page has the exact CPU, RAM, and storage figures for each supported chain. Supported protocols currently include Ethereum, Bitcoin, TRON, Starknet, the OP Stack (Optimism, Base, Unichain, Zora), and Robinhood Chain — see the supported deployments catalog for the current list. Three steps between you and a production Ethereum node. This is the last one. Migrating from DIY to Chainstack Self-Hosted is not a rebuild either: you keep your infrastructure, your clients (Reth, Prysm), and your endpoints — what changes is the operational layer sitting above them. If you’d rather not source hardware yourself, Chainstack Self-Hosted ships pre-installed or one-click with Velia, Vultr, HOSTKEY, Serverside.com, and BreezeHost — each with its own promo, region mix, and hardware profile. Explore Chainstack Self-Hosted → FAQ Is self-hosting blockchain nodes still worth it? For teams with sustained volume, custom execution needs, or compliance requirements, yes — provided the operational layer is a product, not a pile of scripts. See the DIY vs Chainstack Self-Hosted comparison. Are dedicated nodes cheaper than self-hosted? At low volume, often yes. At sustained high volume, self-hosted usually wins on TCO, because managed pricing scales with requests while hardware cost is fixed. How difficult is maintaining Ethereum nodes today? With mature clients like Reth and Prysm on a Kubernetes control plane, materially easier than in 2021. Chainstack Self-Hosted reports roughly 4 hours/week for a DIY setup versus notification-driven review with a control plane. Do blockchain node upgrades still cause downtime? Only if you upgrade in place. Rolling upgrades on Kubernetes plus staged rollouts eliminate the downtime pattern; see how the June 2026 release surfaces upgrade coordination in the Control Panel. Can Kubernetes automate blockchain infrastructure? Yes — StatefulSets, PVCs, and readiness probes cover the essentials. Chainstack Self-Hosted uses enterprise-grade Kubernetes under the hood. Does self-hosting require a full DevOps team? Not with modern tooling. The Chainstack Self-Hosted installer handles Kubernetes setup automatically; one platform engineer can operate a fleet. What’s the difference between dedicated and self-hosted infrastructure? Dedicated means the provider runs single-tenant hardware for you. Self-hosted means you own the hardware and the runtime. Is self-hosted more reliable than managed infrastructure? Neither is universally more reliable. Self-hosted done well matches or exceeds managed on the metrics that matter most (chain-tip freshness, data control), while managed wins on operational simplicity for smaller teams. How does self-healing work for blockchain nodes? Chainstack Self-Hosted monitors nodes continuously and recovers from failures automatically, with configurable failover to Chainstack Cloud RPC as a backstop when needed. When should companies migrate away from self-hosting? When the workload no longer justifies the operational commitment — small teams, prototypes, bursty traffic, or organizations without infra expertise. See “When dedicated infrastructure is the right call” above. Can I run a hybrid setup? Yes. Chainstack documents a hybrid pattern using eRPC that routes hot-path traffic to a self-hosted node and archive queries to Chainstack Cloud. Which clients does Chainstack Self-Hosted run? Currently Reth for execution and Prysm for consensus on Ethereum, with additional protocols — Bitcoin, TRON, Starknet, OP Stack (Optimism, Base, Unichain, Zora), and Robinhood Chain — per the supported deployments catalog. Related reading Introducing Chainstack Self-Hosted Chainstack Self-Hosted documentation Self-Hosted Blockchain Node: DIY vs Managed Self-Hosted Blockchain Node: Challenges and Solutions Blockchain Node Hosting: How to Choose the Right Setup (2026) How Chainstack uses Chainstack for Chainstack Cut RPC costs with a hybrid setup Self-Hosted on Velia and HOSTKEY #### Sepolia Faucet – Claim Free Sepolia ETH Introducing the Sepolia ETH Testnet Faucet: Your Gateway to Testnet ETH. In the world of Web3 development, you will always need testnet tokens. Whether you’re experimenting with smart contracts, building decentralized applications, or refining your blockchain solutions, access to testnet tokens is necessary. We understand the challenges and frustrations that developers face when building DApps. That’s why we created the Sepolia ETH Testnet Faucet, designed with Web3 developers like you in mind. When you’re ready to move to mainnet, get a dedicated Ethereum RPC endpoint on Chainstack. Get Sepolia ETH How to use the Sepolia faucet Once you’re registered and have an API key set up on the Chainstack platform, you can get up to 0.5 Sepolia ETH every 24 hours. Testnet ETH can be used to send transactions on the Sepolia testnet, deploy your smart contracts, and test their different functions before deploying them on a mainnet, that involves real funds. For a step-by-step tutorial on how to request funds from our Sepolia faucet, watch the video demo below. Why do I need ETH on Mainnet in order to request funds from the faucet? This measure helps ensure fair usage and prevents exploitation of the service. Our faucet requires you to hold 0.002 ETH in your Ethereum Mainnet wallet, in order to use it. If you feel like you have been flagged erroneously, contact us on Telegram or Discord. Why does it take so much time for my tokens to arrive? Usually, the process of receiving your tokens should be fast, but sometimes the network may be congested and you might need to wait a little while. If you do not get your tokens after 15 minutes, please contact us on Telegram or Discord. I get an error saying “The user can only receive funds every 24 hours” In order to ensure an even distribution across the Ethereum developer community, we restricted the maximum amount of Sepolia testnet tokens you can request to up to 0.5 ETH a day. I get an error saying “Something went wrong. Check credentials and try again.” You might’ve entered an incorrect API key or wallet address. Please check them again, refresh the page, and try one more time. In order to generate your API key, you will need to sign-up via the Chainstack console first. Check out the video above to see how to generate your own API key and request testnet tokens from the faucet. If you are sure that the API key is valid, your wallet address is correct, and you still can not claim tokens, you can contact us on Telegram or Discord so we can assist you. Do you need help when using the faucet? You can contact us via Telegram or Discord and one of our team members will help you to get testnet tokens. Now that I have my funds, what shall I do next? If you enjoyed using our Sepolia testnet faucet, feel free to share it on X (Twitter) with your friends, and tag our official @ChainstackHQ account in your post. I want the best Ethereum nodes If you are looking for fast and reliable Ethereum nodes, you can sign-up on Chainstack and deploy one for free. We support over 20 different blockchains, and we also provide additional developer tooling. What is Chainstack? Chainstack is the limitless Web3 development stack for Web3 developers. Every blockchain, Every API, every tool that you need to build applications for any scale. Get Sepolia ETH Where can I learn to build DApps? Our Web3 documentation is the perfect place to get you started. You will find everything you need in there from smart contract tutorials to APIs, and recipes. Let’s get you started with this quick glossary: What is a faucet? A faucet is a developer tool that gives you testnet tokens to use when testing your smart contracts or interacting with DApps on test networks. The Chainstack faucet gives you Sepolia testnet ETH to test your smart contracts before deploying them to production. What is the Sepolia testnet? Sepolia is one of the two public Ethereum testnets, the other one being Goerli. Sepolia is the default recommended testnet for Ethereum DApp developers. It’s perfect for contract and application developers to test their applications before deploying them live. What is the meaning of drip? When it comes to Web3 faucets, the drip refers to the amount of testnet tokens that you can get from a faucet each day. In your case, this would be 0.5 Sepolia Testnet ETH daily. What are Sepolia testnet Ethereum token? A Sepolia testnet Ethereum token is the gas fee token for the Sepolia testnet. Testnet tokens do not have real monetary value (these tokens are not like the “real” Ethereum), but they play an important role in covering gas costs. You will need them in order to deploy your smart contracts on the Sepolia testnet, and interact with those contracts through transactions. Do you want to ask us something else? Join our Telegram or Discord communities, so you can talk directly to our team members there. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. Power-boost your project with Chainstack Get Ethereum mainnet access → #### Simplifying Web3 infrastructure costs Web3 relies on RPC nodes, which are the backbone of the system. But, using it is complex, even for experienced developers. More specifically, there are nuances in the node or client implementation. Different implementations may have uniquely different methods. For example, debug_traceTransaction requires an archive node because the method retrieves a historical state to be able to replay previous transactions. Moreover, new methods are constantly being introduced and existing implementations are being updated. For instance, failing to update the client implementation can lead to the risk of users ending up on the hard-forked chain. There is an ever-changing list of nuances and these dynamic variables make it challenging for developers to stay on top of changes.  The unpredictability of Web3 node pricing units To make matters worse, providers rely on unclear pricing strategies or utilize different units to describe the price of one API call. Some providers employ terms like “Compute Units” while others use “API Credits”. The main difference lies in the calculation. A single method request does not equal one API call. Instead, the number of compute units and credits deducted are determined by the resources consumed on the backend. The pricing model creates challenges for engineering teams in predicting costs and budgeting, causing financial uncertainty, and making it difficult to anticipate the size of the next bill. Sometimes it is 8 credits; other times it can be 32 credits. It depends on the type of method and whether the request is for the most recent state or a historical state. Here’s a quick comparison for example: With Chainstack, every API call is always billed as 1 request Things get even more complicated for non-Web3 natives. For one, they may struggle to figure out the function of each request. On top of that, they must scan through an exhaustive list of methods to match each request with its associated pricing. Even Web3 natives find this complicated, so needless to say, many do not delve into this level of granularity. This makes predicting infrastructure costs difficult Most developers may not know which requests or methods are required at the start and only discover what is necessary later. When a developer makes hundreds of millions of eth_getLogs requests, it can become overwhelming to realize the cost after the bills have accumulated. For example, the chart below indicates the cost of making 100 million requests for each method. See for yourself Many end up spending more than intended when they are not aware of the costs associated with each method. Budgeting is simple when one API call is always 1 request With Chainstack, every API call to an RPC node is always billed as 1 request irrespective of the type of request or the required computation resources. This even applies to methods which call historical states. This is what it means for the top 10 methods compared to other vendors. Here is the comparison of the pricing for 30 million API calls for each of the top 10 methods for retrieving both the latest and historical state. As can be seen, Chainstack is 86% more affordable compared to the other providers. Hundreds of projects have migrated to Chainstack One Chainstack request equals one API call, whether it’s a full or archive request. There are also no rate limits or throttling. This has led to hundreds of businesses and projects migrating to Chainstack from other vendors, citing cost transparency and unbeatable pricing as key reasons. Chainstack’s competitive and transparent pricing strategy is highly appealing to those considering a switch. Doubtful? Here are actual workloads from clients who quickly switched to Chainstack after noticing the cost difference. To compare vendors, we: Obtained official documentation of the number of compute units or API credits for each request. Extracted workloads from multiple migrated projects to Chainstack. Averaged the load profile across the same verticals. Adjusted for the optimal plan based on the number of requests. Gathered pricing information from each vendor’s page which includes prices for additional requests. Conducted comprehensive research and data collection from prospects and clients for non-public data. Here is the average workload of top DEX aggregators using Chainstack. And here is the average workload of top data providers using Chainstack. Transparent pricing for all In the Web3 industry, affordable infrastructure is crucial. Chainstack has developed a transparent pricing comparison tool, enabling developers and business executives to input requests across the top 10 methods or select between archive and full requests.This tool helps projects and developers predict costs accurately and demonstrates our dedication to providing transparent and unbeatable pricing in the industry. Final words Cost transparency and unbeatable pricing are vital for Web3 development. Especially when funds become scarce during market turbulence. Projects and organizations need to budget and allocate resources more efficiently to build a financial buffer. Aligning with the core principle of transparency, using a one-to-one API request approach simplifies onboarding and helps developers predict workload costs. This approach also avoids budgeting issues that may arise from needing to learn each method’s function when new developers join a project. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Smart contract framework – The Brownie tutorial series–Part 1 Before we begin, I would like to extend my sincere apologies to any and all epicures who may have stumbled upon this tutorial series. I am afraid you have been tricked by a wicked tradition that names smart contract development frameworks and tools after delicious desserts. This tutorial series does not talk about food. It talks about a development framework. You are more than welcome to check it out though. This is the first of four articles that gives you a thorough walk-through of the smart contract development framework, Brownie.  Part 1 – Introduction. <– You are here.Part 2 – Scripts, tests, and testnets.Part 3 – Brownie deep dive.Part 4 – Move forward with Brownie. These articles will show you how to use the Brownie framework for building, testing, and deploying Solidity smart contracts.  The Pythonista problem  A development framework is a developer’s best friend. A framework helps accelerate the application development process by providing things like a base structure for the project, reusable code, useful libraries, testing and debugging functionalities, and, of course, easy shipping (deployment) methodologies. The more intricate a technology, the more useful a framework becomes. So, when we are dealing with a paradigm-shifting idea like Web3, it is imperative that there be some good frameworks out there that help ease the pain of Web3 application development. To be fair, there are a lot of amazing JavaScript/Typescript-based frameworks that do the job, and that is precisely the problem. When we scan the whole Web3 framework scene, we can see there is strong leniency towards JavaScript/Typescript. I love JavaScript, it is an amazing language. But I am a Pythonista, meaning I love Python more. When others like me try to start their Web3 development journey, how can we escape the async/await entanglement and use simple readable code for developing Web3 applications? What frameworks can we use? Well, let me introduce you to Brownie. The Brownie solution  Brownie is a Python-based smart contract development and testing framework. We can use Brownie to develop smart contracts that are compatible with Ethereum and other EVM-based networks. Why the leniency towards Ethereum, you may ask. Well, Brownie is built on top of the web3.py library. Now, for those who are new, web3.py is the Python library that we use in order to interact with Ethereum. Brownie supports both Solidity and Vyper (a Pythonic programming language) contracts.  Note: If you are new, I highly recommend that you check out the web3.py library and familiarize yourself with the web3.py-based smart contract deployment and interaction. This will help you gain a better understanding of the overall process. Brownie uses the pytest framework for unit testing. This enables the developers to leverage the potential of this feature-rich testing framework and write elaborate and powerful test cases for smart contracts. Brownie also comes with transaction debugging features that provide detailed insights into transaction failures or reversions.   Note: The transaction debugging feature uses the debug_traceTransaction RPC method and the availability of this feature relies on your node provider. As of now, only a select few platforms like Chainstack support this RPC method.  That’s it for an overview, now let us dive right in and develop some contracts using Brownie.  How to install Brownie? Before we start working with Brownie, we need to install certain dependencies. Since Brownie is a Python-based framework, the most obvious dependency would be a Python interpreter. So, here’s what I want you to do:  Make sure you have Python (version ^3.6) installed on your system. Install the corresponding version of the python package manager (pip v21.3.1) . Great, now that you have python3, you can install Brownie using the following command: pip3 install eth-brownie   To check if everything is installed, open the terminal and type brownie. If everything went well, it will display all the Brownie commands:  $ brownie Brownie v1.19.0 - Python development framework for Ethereum Usage: brownie <command> [<args>...] [options <args>] Commands: init Initialize a new brownie project bake Initialize from a brownie-mix template pm Install and manage external packages compile Compile the contract source files console Load the console test Run test cases in the tests/ folder run Run a script in the scripts/ folder accounts Manage local accounts networks Manage network settings gui Load the GUI to view opcodes and test coverage analyze Find security vulnerabilities using the MythX API Options: --help -h Display this message --version Show version and exit Type 'brownie <command> --help' for specific options and more information about each command. Note: According to the official Brownie doc, a cleaner way of installing Brownie would be to use pipx. It helps install Brownie into a virtual environment. You can check the official doc for the pipx-based installation guide.  Now, we need one more thing before we can use Brownie. We need Node.js support! (yes, the irony is not lost on me). So, make sure you have Node.js and npm installed on your system. Once you have that installed, use the following command to install something called Ganache CLI:  $ npm install -g ganache-cli  Ganache helps you set up a local (Ethereum) blockchain network on which you can deploy and test smart contracts. It has both a GUI version and a CLI version. Brownie, by default, uses Ganache CLI as the local development environment. The Ganache CLI also provides you with 10 test accounts with 100 test ethers each. We can use these accounts for contract deployment and testing. To check the Ganache CLI installation, use the following command: $ ganache-cli --version  #returns the Ganache version  Now that we have everything, let us set up a project.  How to set up a Brownie project? To set up a new Brownie project,  create a new project folder and initialize the project using the following command: brownie init  This will set up an empty project structure in your folder: ├── build │ ├── contracts │ ├── deployments │ └── interfaces ├── contracts ├── interfaces ├── reports ├── scripts └── tests Each of these directories is named according to the type of data that they will hold:  DirectoryContent/build Stores the compilation outputs and deployment information(we will discuss this later)./contracts Stores the contract files./interfaces Stores the interface files./reports Stores test coverage data and contract analysis reports./scripts Stores contract deployment and interaction scripts./tests Contains testing scripts. This project structure helps us easily organize and manage our files while working with smart contracts.  Now that we have set up a Brownie project, we can try and run a simple smart contract. For that, let us create a basic Solidity contract  // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract BasicContract { //a variable for storing numbers uint256 number; //function for storing a number function storeNumber(uint256 _number) public { number = _number; } //function for reading the number function readNumber() public view returns (uint256) { return number; } } Here is the link to the GitHub repository for code reference. This contract stores a number and retrieves it upon user invocation.  You can create a new file, basic-contract.sol, in the /contracts directory and copy and save the above code in that file.  Once you have the contract file, you can compile the code by opening a terminal in the root directory of the project and typing the following command: brownie compile  This command will automatically pick up the smart contracts from the /contracts folder and compile them. The compilation outputs (or artifacts) like the contract ABI, bytecode, etc are stored in a JSON file (<contract-name>.json) inside the /build/contracts directory. You can check out the complete compiler artifacts file structure here.  If you have multiple smart contracts in the /contracts directory, you can specify the contract that you want to compile using the following command: brownie compile <contract-file-name.sol>  Note: Brownie is smart. It uses the contract source hash (sha1 field in the compiler artifact file) to check for changes in the smart contract and only recompiles a contract if it detects any changes in the source file. So, even if you do not specify the contract files, Brownie will only compile the new files or the ones that are modified.  How to deploy a smart contract with Brownie? Now that we have created and compiled a contract, all that is left is to deploy the contract onto a network and test its functionality. In Brownie, there are two ways in which we can deploy and interact with a contract: We can create Python scripts that automate the whole contract deployment and interaction.We can use the Brownie console for quick testing and debugging. As developers, learning to create powerful Python scripts that handle smart contract deployment and interaction is our end goal, but since we are just starting out, I think it would be much more helpful if we can understand the Brownie functionalities better before we jump into the scripts. To do that, we can try and interact with our smart contracts using the Brownie console.  To spin up the Brownie console, open the terminal and type: brownie console  The output will look something like this: Brownie v1.19.0 - Python development framework for Ethereum Project is the active project. Launching 'ganache-cli --port 8545 --gasLimit 12000000 --accounts 10 --hardfork istanbul --mnemonic brownie'... Brownie environment is ready. >>> The console command will: Compile all the contracts (only if they are not already compiled).Launch a local blockchain network using ganache-cli.Provide us with a command prompt, using which we can deploy and interact with the contract. Now, to deploy a contract, we need,  Contract ABI Contract bytecode An Ethereum account address  The ABI and the bytecode are already there in the compiler artifact file (inside build/contracts) and as I mentioned previously, Ganache CLI provides 10 test accounts. So how do we access all these and deploy the contract?  Well, in Brownie, when smart contracts are compiled, it creates a contractContainer object for each of the deployable contracts. The object can be accessed using the name of the contract (BasicContract, in our case). This object encapsulates all the necessary information like the contract ABI and bytecode. The object also comes with a deploy function that we can use in order to deploy the contract. Here’s a quick look at how we can view the contract ABI details in the Brownie console using the <contract-name>.abi command: >>> BasicContract.abi [ { 'inputs': [], 'name': "readNumber", 'outputs': [ { 'internalType': "uint256", 'name': "", 'type': "uint256" } ], 'stateMutability': "view", 'type': "function" }, { 'inputs': [ { 'internalType': "uint256", 'name': "_number", 'type': "uint256" } ], 'name': "storeNumber", 'outputs': [], 'stateMutability': "nonpayable", 'type': "function" } ] To deploy the contract, we also need to provide an account. In Brownie, we can use the accounts object for accessing the local accounts. Here, we will use the object to access one of the accounts provided by the Ganache CLI.  Note: We can add our own accounts in Brownie using the accounts object and our account private key. We will discuss this in later articles. You can see the details of all the accessible accounts using the accounts command: >>> accounts [<Account '0x66aB6D9362d4F35596279692F0251Db635165871'>, <Account '0x33A4622B82D4c04a53e170c638B944ce27cffce3'>, <Account '0x0063046686E46Dc6F15918b61AE2B121458534a5'>, <Account '0x21b42413bA931038f35e7A5224FaDb065d297Ba3'>, <Account '0x46C0a5326E643E4f71D3149d50B48216e174Ae84'>, <Account '0x807c47A89F720fe4Ee9b8343c286Fc886f43191b'>, <Account '0x844ec86426F076647A5362706a04570A5965473B'>, <Account '0x23BB2Bb6c340D4C91cAa478EdF6593fC5c4a6d4B'>, <Account '0xA868bC7c1AF08B8831795FAC946025557369F69C'>, <Account '0x1CEE82EEd89Bd5Be5bf2507a92a755dcF1D8e8dc'>] Now that we know how to access these details, let us try and deploy a smart contract using the Brownie console. To do that: Get an account using the accounts object.Use the contractContainer object of our smart contract.Call the deploy function.Pass the account as a parameter. # get the account at index 0 account = accounts[0] # use the BasicContract.deploy function to deploy the contract # pass the account as the parameter deployed_contract = BasicContract.deploy({"from":account}) Transaction sent: 0xfd8dfcecaacd20740a0f00a7f6e5ce8890e5dfc62c53d9f48ae8fd84694d6371 Gas price: 0.0 gwei Gas limit: 12000000 Nonce: 0 BasicContract.constructor confirmed Block: 1 Gas used: 90551 (0.75%) BasicContract deployed at: 0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87 # display the contract address deployed_contract <BasicContract Contract '0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87'> The deploy function returns a ProjectContract object. This object helps us call or send transactions to the contract. In the above sample, we returned the ProjectContract object to the deployed_contract variable. Now we can use that variable in order to invoke the contract functions: >>> deployed_contract.readNumber() 0 >>> deployed_contract.storeNumber(10,{"from":account}) Transaction sent: 0x1e2fca512bcddd5efc47d4620874632d2a7a0c185f09e2dc0140c7a04bdecd2a Gas price: 0.0 gwei Gas limit: 12000000 Nonce: 1 BasicContract.storeNumber confirmed Block: 2 Gas used: 41394 (0.34%) <Transaction '0x1e2fca512bcddd5efc47d4620874632d2a7a0c185f09e2dc0140c7a04bdecd2a'> >>> deployed_contract.readNumber() 10 The Brownie console provides a quick and easy way to test and debug your contract. You can create more complex contracts and deploy them using the Brownie console in order to test their functionality. Once you are done with the testing, you can use CTRL-D to close the Brownie console. Do understand that once we close the console, Brownie will automatically teardown our local Ganache network, meaning that all the data we created during that session will be gone.  Wrap up  Tinkering with the Brownie console will help you better understand the Brownie functionalities.  To learn more elaborate development and testing features of Brownie, we need to create more complex smart contracts, build powerful Python scripts and work with actual testnets. This might seem like a lot of work, but Brownie got you covered.  In the coming articles, we will see how we can use Python scripts to deploy and interact with a smart contract, we will create some testing scripts, and we will also see if we can deploy our contract onto an Ethereum testnet. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Smart contract Frameworks – Foundry vs Hardhat: Differences in performance and developer experience I’ve been using Hardhat since my first Solidity project. Back when I started learning Solidity, I wasn’t sold on the idea of working with an online IDE like Remix, and Hardhat was the most recommended option (although Truffle was close behind). After some months using it for almost all my Solidity projects, I’m pretty used to it—how the different networks and project folders can be configured, how to write tests, and I’ve even come up with an almost perfect (at least for me) project structure that I always use when I want to create a Web3 app. A few weeks ago, one of my teammates talked to me about Foundry and performance was the main selling point. It really piqued my curiosity so I decided to install it and created a quick project to compare the differences between Foundry and Hardhat building the same project. We published an article a few months ago, where we explained how to install Foundry and gave a quick overview, so make sure to check it out first!By the way, if you get the error Library not loaded: /usr/local/opt/libusb/lib/libusb-1.0.0.dylib when creating your first project, just run brew install libusb to fix it (detailed here) 😉 Project structure and configuration After creating the project, Foundry generates a foundry.toml file. It’s based on key-value pairs and serves as a configuration file similar to Hardhat’s hardhat.config.js . In it, you can define the contracts source folder, where to output the compiled artifacts, etc. Here are the default folders with both: FilesFoundryHardhatContract files/src/contractsTest files/src/test/testOutput/out/artifactsDependencies/lib/node_modules One of the main differences in the configuration file is that in Hardhat you can add multiple networks, which can be used later on to deploy our contracts. In Foundry, that’s currently not possible. Most of the additional parameters that you can add to the foundry.toml file are related to the tests (verbosity, account, balance, gas price, etc). You can find more info about the advanced config parameters here. The remappings option is one of the most important parameters and Foundry’s config file, and it’s used to manage dependency imports. You can use remappings to create shortcuts and make imports less verbose in the contracts. You have to define a key-value pair in the remappings section of the foundry.toml file, where the value is the path to the contract folder you want to import. For example, you could create the following remapping: remappings = ['ds-test/=lib/ds-test/src/', # Shortcut to OpenZeppelin ERC20 token folder 'openzeppelin-erc20/=lib/openzeppelin-contracts/contracts/token/ERC20/' ] And then import the ERC20 token contract like this: // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.4; // Default import // import {ERC20} from "openzeppelin-contracts/contracts/token/ERC20/ERC20.sol"; // With remapping shortcut import {ERC20} from "openzeppelin-erc20/ERC20.sol"; contract MyToken is ERC20 { // Contract code } You can see the difference with the default import commented two lines above. Dependencies Hardhat uses npm to manage dependencies, so if you’re familiar with Node.js or JavaScript projects, you’ll know how it works. To install OpenZeppelin contracts, you’d run npm install @openzeppelin/contracts, and you’re good to go. In Foundry, dependencies are installed with the forge CLI tool and are saved in the lib/ folder. Foundry uses Git submodules to handle dependencies, which means you can install as a dependency any repository that has smart contracts, and they’ll be included in a .gitmodules file instead of the package.json used in npm projects. To install a dependency, you’ll have to run forge install GitHub-Organization-name/repository-name. For example, if you want to install OpenZeppelin smart contracts, you’ll run forge install OpenZeppelin/openzeppelin-contracts. You can also install a specific branch or tag appending @tag-name to the dependency name. After installing a dependency, you can run forge remappings and it’ll print the remappings that Foundry will use by default. For example, after installing OpenZeppelin contracts, this is what forge remappings return: $ forge remappings openzeppelin-contracts/=/Users/antonio/Chainstack/foundry-tutorial/foundry-demo/lib/openzeppelin-contracts/ ds-test/=/Users/antonio/Chainstack/foundry-tutorial/foundry-demo/lib/ds-test/src/ As mentioned earlier, you can create shortcuts by adding different remappings in the foundry.toml file or in a specific remappings.txt file. Logging One of the things that improve the developer experience in Hardhat is using console.log(). Using console.log() is a very quick and popular way to debug and track errors in JavaScript, and Hardhat provides a similar method out of the box, which is super useful. They even mention it as one of its selling points on their landing page! Why use Hardhat? Obviously, if you try to compile a contract that uses Hardhat’s console.log with Foundry, you’ll get an error as the dependency is not there. You could install it manually (via forge install NomicFoundation/hardhat) and import it (from /hardhat-core/console.sol) but the recommended option is to copy this contract into your project, and import it wherever you want to use console.log. It’s not ideal, but I’m sure they’ll come up with a better option soon. But if you just need to write logs in your test files, you don’t need any dependencies at all. The included-by-default DSTest contract comes with assertions and logging events, so you just need to emit any of the available events, like emit log_string() or emit log_int(), emit log_address() etc. Writing tests Testing is probably on the most different aspects between Hardhat and Foundry. To compare them, I created the same contract and tests with both Hardhat and Foundry. The MiniBank.sol contract I created allows users to open accounts, deposit and withdraw ether, close the account, and return the number of active accounts. You can find the code of both projects in the repository. Test files in Hardhat In Hardhat, you write your tests in JavaScript using the describe and it keywords to define all different scenarios, and use Mocha as the default assertion library. Using Hardhat, this would be part of the testing file for the MiniBank contract: const { expect } = require('chai') const { ethers } = require('hardhat') let miniBankFactory, miniBankContract, owner, user1, user2, user3 describe('MinBank contract', function () { beforeEach(async function () { miniBankFactory = await ethers.getContractFactory('MiniBank') ;[owner, user1, user2, user3] = await ethers.getSigners() miniBankContract = await miniBankFactory.deploy() await miniBankContract.deployed() }) it('Should return the number of opened accounts', async function () { expect(await miniBankContract.accountsOpened()).to.equal(0) }) it('Should allow multiple users to open accounts', async function () { await miniBankContract.connect(user1).openAccount() await miniBankContract.connect(user2).openAccount() await miniBankContract.connect(user3).openAccount() expect(await miniBankContract.accountsOpened()).to.equal(3) }) it('Should prevent users to open a second account', async function () { await miniBankContract.connect(user1).openAccount() await expect( miniBankContract.connect(user1).openAccount() ).to.be.revertedWith('MiniBank: User has an account already!') }) it('Should allow users to deposit ETH', async () => { await miniBankContract.connect(user1).openAccount() await miniBankContract.connect(user1).deposit({ value: 1 }) expect(await miniBankContract.connect(user1).checkBalance()).to.equal(1) }) }) If you’re a JavaScript developer, this is probably familiar. You can separate blocks of tests with describe() and define each test with a very descriptive name with it(). In addition, if you’re just starting your journey into Web3, Solidity, and smart contracts, you just need to learn how to handle a few new assertions, like revertedWith, but smart contract tests are very similar to any other JavaScript tests. Test files in Foundry In Foundry, tests are smart contracts written in Solidity that inherit from the DSTest contract. Each test is a function named testSomeScenarioToTest and all available assertions are inherited from the DSTest contract as well, which you can find here. Following the recommended convention, for the MiniBank.sol contract, the test file will be named /src/test/MiniBank.t.sol and it would look like this: // SPDX-License-Identifier: UNLICENSED pragma solidity 0.8.10; import "ds-test/test.sol"; import "../MiniBank.sol"; // required for expect revert and other cheats interface Vm { // to assert returned contract errors function expectRevert(bytes calldata) external; // to change user interacting with the contract function prank(address) external; } contract MiniBankTest is DSTest { MiniBank minibank; // required for expect revert and other cheats // HEVM_ADDRESS is 0x7109709ECfa91a80626fF3989D68f67F5b1DD12D); Vm vm = Vm(HEVM_ADDRESS); function setUp() public { minibank = new MiniBank(); } function testReturnsOpenedAccounts() public { assertEq(0, minibank.accountsOpened()); } function testUserOpensAcount() public { minibank.openAccount(); assertEq(1, minibank.accountsOpened()); } function testMultipleUsersOpenAccount() public { minibank.openAccount(); // injects change of user vm.prank(address(1)); minibank.openAccount(); vm.prank(address(2)); minibank.openAccount(); assertEq(3, minibank.accountsOpened()); } function testAllowUsersDepositEth() public { minibank.openAccount(); minibank.deposit{value: 1 ether}(); assertEq(1 ether, minibank.checkBalance()); } } There’s a lot going on here, so let’s review the basics: The test contract inherits from DSTest. We have to import the contract we want to test and instantiate it inside the setUp() method, which is similar to the beforeEach method in JavaScript tests. Each test is a public function whose name starts with test or testFail. Inside each test, we can call the contract methods using the contract instance created in setUp(). To send ETH to a contract method, you have to use contract.methodName{value: 1 ether}(); You’re probably wondering what is that Vm interface? Well, that’s used for Foundry’s cheats, and it requires its own section in this article 😉 Understanding Foundry cheats for testing Cheatcodes are an important part of Foundry’s testing tools and are used for things like changing the date or number of the current block, forcing the next contract call to be made from a different account, or asserting specific reverts or events. You can find all the available cheat methods in their GitHub repo. Coming from Hardhat, understanding cheats was a little complex but once you get your head around them, you realize how useful they are. To use these cheat codes, first, we need to create an interface and define all the cheat methods we want to use. In the example above, it was this part: // required for expect revert and other cheats interface Vm { // to assert returned contract errors function expectRevert(bytes calldata) external; // to change user interacting with the contract function prank(address) external; } After that, we need to create a state variable that uses that interface as its type like this: // HEVM_ADDRESS is 0x7109709ECfa91a80626fF3989D68f67F5b1DD12D); Vm vm = Vm(HEVM_ADDRESS); But what is that HEVM_ADDRESS? It’s a pre-defined contract address that contains all the cheat methods. Here’s how they explain it in the docs: cheats are invoked by calling specific functions on a specially designated address: 0x7109709ECfa91a80626fF3989D68f67F5b1DD12D. If you are using ds-test, then this address is assigned in a constant named HEVM_ADDRESS. Once we have declared an instance of the cheats contract, we can use it in our tests like this: function testMultipleUsersOpenAccount() public { minibank.openAccount(); // injects change of user vm.prank(address(1)); minibank.openAccount(); // injects change of user vm.prank(address(2)); minibank.openAccount(); assertEq(3, minibank.accountsOpened()); } function testCannotOpenTwoAccountsSameUser() public { minibank.openAccount(); // injects assertion vm.expectRevert("MiniBank: User has an account already!"); minibank.openAccount(); } Changing the user with vm.prank() or the current block with vm.roll() before calling a contract method is easy to understand as you’re changing the user or the status of the blockchain right before actually calling the contract method itself, but vm.expectRevert() is weird. It’s like doing the assertion before actually calling the method 😵‍💫 But once you get your head around that, cheats are pretty cool and easy to use. On the other hand, writing tests in Solidity means not having to deal with so many async/await methods, which means writing less code. vm.expectRevert() is weird. It’s like doing the assertion before actually calling the method 😵‍💫 Running tests: performance difference When it comes to running the tests, the first thing I noticed was how fast Foundry was. I’ve used the same contract with the same number of tests and same scenarios, the only difference was that I wrote the tests for the Hardhat project in JavaScript while I wrote them in Solidity for Foundry. I removed the cache folders in both projects before measuring how long it took to compile the contract and run the project, and the difference was huge: Foundry took 1.44 seconds to compile the contract and run all the tests, while Hardhat took 5.17 seconds. Keeping the cache folders, the difference is huge as well: Foundry took 0.45 seconds (almost instant), while Hardhat took 3.98 seconds. In a small project like this, the difference may not be that important but in bigger projects, it can make a difference. I also wanted to try compiling a larger project, so I cloned GEB, which has 26 smart contracts. I had to reorganize the project files and install all the dependencies but I was able to time how long it took to compile all the contracts in both cases. With Hardhat, it took 14.56 seconds and with Foundry, it took 8.53 seconds 💨 Test Foundry framework: pros and cons Here is a list of what I consider the pros and cons of writing tests with Foundry vs Hardhat: ProsConsNeitherNo async/awaitTest names are not as descriptive as in JavaScript testsTests are written in SolidityTests require less codeCheats are difficult to understand at firstTests run super fastexpectRevert assertion is weirdAuto-generated gas reporttestFail only tests if the test fails, not if the error is what we expectPros and cons of writing tests with Foundry Deploying contracts One of the aspects I like about Hardhat is that you can write deployment scripts in JavaScript and target different networks, or use the dotenv package to load the RPC endpoints and private keys from environment variables. It makes deployments easy to write and share. In Foundry, deployments are run from the CLI like this: forge create --rpc-url <your_rpc_url> --private-key <your_private_key> src/MyContract.sol:MyContract which is not ideal. And if you need to pass some arguments to the contract’s constructor, this gets completly out of hand: forge create --rpc-url <your_rpc_url> --constructor-args "MyToken" "MTKN" 18 1000000000000000000000 --private-key <your_private_key> src/MyToken.sol:MyToken. I asked about a more convenient approach to this in the Foundry Telegram channel and they recommended creating a bash script. I even found a GitHub repo (credits to Patrick Collins) with some step-by-step scripts to make the deployment a little bit easier. In addition, the team is working on new ways to deploy contracts and even make deployments available in the tests in order to, for example, run some tests against a contract after it’s deployed. It sounds great and I’m sure the team will have something more convenient really soon. Cast CLI tool Foundry includes the cast CLI tool which allows you to interact with the blockchain or a smart contract. You’d need an RPC endpoint to run most commands, so make sure to sign up in Chainstack and get your RPC endpoint for free. In summary, you can query the blockchain by block, get information about wallets and call any smart contract methods. For example, if you wanted to call the balanceOf(address) method of the USDC ERC20 token contract ( which address address is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48), you’ll run: cast call "balanceOf(address)(uint256)" "0x123456...." --rpc-url https://my-rpc-endpoint/abcdef. It’s a useful tool and pretty fast as well but, similar to deploying contracts, it requires creating bash scripts to avoid writing super long commands. You can find all the available methods here. Final thoughts Foundry is not 100% complete but it’s evolving and it looks promising. Performance is awesome, there is a great and very active community around the project and their Telegram channel is filled with discussions about new features and how to make it a better development tool. I’ve seen some people mention that they use Foundry to develop the contracts and write the tests, and at the same time use Hardhat for scripting and deployments. This can be a good option while the team releases a new way to deploy contracts. If you’re want to give it a try, make sure to join the Foundry Telegram channel, the support channel, read the Foundry book to learn how to start using it, and keep an eye on the public GitHub repository. Summary of differences  FoundryHardhatInstallationVia CLI curl commandNot required with npx, or via npmCLI toolsforge to manage the project (build/compile) & cast to interact with smart contractshardhat manage the project (build/compile/run scripts)Build & test performance💨💨💨💨💨🐢🐢Configuration filefoundry.tomlhardhat.config.jsAllows project folder configurationYes, in foundry.toml fileYes, in hardhat.config.js fileDependency managementGitHub submodules (any repository)npm packagesDependencies file.gitmodulespackage.jsonFiles included in sample projectEmpty smart contract and basic testGreeter smart contract (with set/get methods), test files, and script to run locallyTest file formatSolidity contractsJavaScript test filesTest assertion library (default)ds-testMochaAllows altering blockchain status (time, block) in testsYes, via cheat codesLimited, via mainnet forkingAllows running specific tests?Yes via –match-test –match-contractYes via “only” or “skip” in test filesContract deploymentsVia forge CLI or bash scripts (new solutions in progress)Via JavaScript scriptsBlockchain / contracts interactionvia Cast CLI toolN/A Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### Smart contracts framework Ape by ApeWorX—What is it and how to use it Ape is a smart contract development and testing framework by ApeWorX and new addition to the Chainstack marketplace. It is inspired by Brownie and has essentially the same syntax, but Ape focuses on a more modular approach, allowing us to build and use external plugins to add functionality. This can appeal to developers because it allows us to deploy and test smart contracts in one environment. The ApeWorX team developed a collection of tools and frameworks to aid in testing and deploying tokens, markets, and oracles that integrate smart contracts with Web3. The Ape framework requires Linux or macOS and Python 3.7.2 or later, so you will need to install the Windows Subsystem Linux (WSL) if you plan to use it on Windows. Make sure to check the ApeWorX docs to find the updated requirements. By the way, you can find all the scripts shown in this guide in the ApeWorX Ape Chainstack tutorial repo on GitHub. Table of contents  Install Ape— how to and common errorsInstall the Chainstack pluginThe Ape consoleSet up the endpoint URLCreate and import accountsMake transfers between accountsCreate a project with ApeDeploy a smart contract from the Ape consoleUse the Ape console to interact with your smart contractDeploy a smart contract from a scriptInteract with an already deployed contractInteract from the consoleInteract from a scriptConclusion Install Ape— how to and common errors Sometimes it can be frustrating to install frameworks and libraries, and often the installation process is the most challenging part; this is why I decided to spend some time showing you how to do it, as well as giving you the solutions for the most common errors. As we already mentioned, you will need to meet these requirements first: Linux or macOSPython 3.7.2 or later, this guide explains how to install it in every OS.Windows Subsystem Linux (WSL) if you are operating on windows. For this tutorial, I am installing and using Ape on Ubuntu 22.04 LTS. To install Python in Ubuntu: Update your local system’s repository list. sudo apt update Install Python. sudo apt install python3 Once Python is installed, you can check if it was installed correctly by typing this command. python3 --version It will return something like this if it was installed correctly. Python 3.10.4 We need one more preparatory step before starting the actual installation. It is good practice to work in a virtual environment as all the dependencies will be installed there; and will not create conflict with other projects. To do so in Ubuntu, follow these instructions: Install PIP and virtual environments. sudo apt install python3-pip sudo pip install virtualenv Create a virtual environment.  python3 -m venv /path/to/new/environment Keep in mind that you can place the virtual environment where you prefer. Then activate it. source /bin/activate If it all works correctly, you will see the name of your environment in between parentheses before your account name, like this: (chainstack) name@name:~/Documents/Coding/python/chainstack $ Now we are finally ready to install Ape. We can use PIP, and we can start by updating it. pip install -U pip Then, install Ape.  pip install eth-ape This is where you might encounter errors; I got this error, for example. error: Setup script exited with error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 I solved it by installing python-dev and build-essential. sudo apt-get install python3-dev sudo apt-get install build-essential Now you can try again with pip, and it should install Ape correctly. Install the Chainstack plugin One of the main concepts differentiating Ape from other frameworks is its modular approach that allows creating and installing plugins, which is suitable for customizing your development environment. Here at Chainstack, we are all for helping developers to develop and make your life easier; that’s why we created a plugin that allows you to use your Chainstack endpoint directly into the Ape console. Currently, the Chainstack plugin is only compatible with the Ethereum network, but support for the other EVM-based chains and StarkNet will be released soon. You can find the Chainstack plugin in its GitHub repository. To install the Chainstack’s plugin run. pip install ape-chainstack Or clone the repository and run setup.py. git clone https://github.com/ApeWorX/ape-chainstack.git cd ape-chainstack python3 setup.py install Once the installation is completed, you can verify that it was installed correctly by using the ape plugins list command, which will show you all the plugins installed in your system. ape plugins list It will show a result like this. Installed Plugins: chainstack 0.4.0a1 This means that now you are ready to use your Chainstack endpoints. The Ape console The Ape framework comes with an interactive console that allows you to interact with the blockchain and your project; you can, for example, connect to a network with a custom endpoint, create and import accounts, query data from the blockchain, and more. In this section, I will show you how to activate and use the console to create an account and query its balance, but the ApeWorX academy has a full tutorial about the console.  Set up the endpoint URL Now that we installed the Chainstack plugin, we can use our endpoint to connect to a network and start getting our hands dirty; first of all, make sure you have a Chainstack endpoint, follow these steps to sign up on Chainstack, deploy a node, and find your endpoint credentials:  Sign up with Chainstack.Deploy a node.View node access and credentials. The next step will be to define the endpoint by creating an environment variable. Open the terminal, and set the environment variable (I will be using a virtual environment and the Goerli testnet). export CHAINSTACK_GOERLI_URL=YOUR_CHAINSTACK_ENDPOINT_URL You can verify that it was set up correctly by displaying it in the console. echo $CHAINSTACK_GOERLI_URL And it will return your endpoint URL if it is set up correctly. Create and import accounts  Now before opening the console using the endpoint we set up, let’s create an account, which is one of the features available in Ape. First, we’ll use the ape accounts to generate “ACCOUNT_NAME” command. ape accounts generate "chainstack" This command will prompt a few questions where you will add an “entropy” value (which can be anything you want) to add some extra randomness to the process and a passphrase. Make sure to keep your passphrase accessible since you will need it to sign the transactions later on, and for the purpose of this tutorial, I recommend only using it for testing purposes without real funds. Add extra entropy for key generation...: Create Passphrase: Repeat for confirmation: SUCCESS: A new account '0xB6a6b3096e2E90780b745c676b842b9D2F657540' has been added with the id 'chainstack' Congratulations, you just created a new account using Ape; you can now fund this account and use it on any EVM-compatible network. For example, you can use this Goerli faucet to get some testnet funds.  Create another account, so we can play a bit with them before jumping into deploying smart contracts with the ApeWorX— Ape framework. Once you have created some accounts, use the ape accounts list command. ape accounts list Which will return a list with the addresses and aliases. Found 2 accounts: 0xB6a6b3096e2E90780b745c676b842b9D2F657540 (alias: 'chainstack') 0x82D78356b4D18e0f24D56bE752454728d80C9897 (alias: 'test') Ape allows us to also import accounts, so this is useful in case you already have accounts with funds and want to use them for your development. To import an account, use the ape accounts import <ACCOUNT_NAME> command; you just need the account’s private key. The console will then prompt you to input a passphrase for you to use to sign transactions. ape accounts import my_ape_account Enter Private Key: Now we can activate the console, query the balance and make transfers. But, first, start the console by adding the -- network flag to use our Chainstack endpoint to connect to Goerli. ape console --network ethereum:goerli:chainstack This will activate the console, where we can load and query our account. Remember that Ape is based on Python, so you will see many similarities; once in the console, we first create a variable for the account to query by using the accounts.load method, then we can query the balance. In [1]: chainstack_account = accounts.load('chainstack') In [2]: chainstack_account.balance / 1e18 Out[2]: 0.25 Make transfers between accounts  We can use the console to transfer tokens between accounts as well.In the console, initialize your second account and check its balance: In [4]: test_account = accounts.load("test") In [5]: test_account.balance /1e18 Out[5]: 0.05 Then input the transfer command— SENDER_ACCOUNT.transfer(RECEIVER_ACCOUNT, WEI_AMOUNT). You can use a wei converter to convert the value you want to send, or you can create a variable and use the converter function offered by Ape. In [14]: value = convert("0.1 ETH", int) In [15]: value Out[15]: 100000000000000000 We are transferring 0.1 Goerli ETH between chainstack_account and test_account in this example. The console will ask you to sign using your passphrase. In [6]: chainstack_account.transfer(test_account, 100000000000000000) DynamicFeeTransaction: chainId: 5 to: 0x82D78356b4D18e0f24D56bE752454728d80C9897 from: 0xB6a6b3096e2E90780b745c676b842b9D2F657540 gas: 21000 nonce: 0 value: 100000000000000000 data: 0x type: 0x02 maxFeePerGas: 1009999997 maxPriorityFeePerGas: 1009999988 accessList: [] Sign: [y/N]: y Enter passphrase to unlock 'chainstack' []: As you can see, Ape automatically builds the transaction for us, and once the transaction is confirmed, we can verify if it worked. INFO: Submitted 0x49da1da7e0368f35302a80791e8b965de26fa06e92a8919662a8bd8c1375b047 Confirmations (2/2): 100%|███████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:29<00:00, 14.75s/it] INFO: Confirmed 0x49da1da7e0368f35302a80791e8b965de26fa06e92a8919662a8bd8c1375b047 (total fees paid = 21209999937000) Out[6]: <Receipt 0x49da1da7e0368f35302a80791e8b965de26fa06e92a8919662a8bd8c1375b047> In [7]: test_account.balance /1e18 Out[7]: 0.15 In [8]: chainstack_account.balance / 1e18 Out[8]: 0.149978790000063 Ape also comes with a set of pre-defined accounts in case you want to develop locally instead of on a testnet. Close the console by typing exit and restart it without the --network flag this time to get into the local environment. This is also an excellent time to talk about the --verbosity flag, which allows us to set up the level of feedback that we want from the console; we will start the console with the DEBUG setting, which is the option that will communicate the most and shows what is happening behind the scenes. You can check out the different verbosity options available in the ApeWorX docs.  Restart the console in local mode. How the Ape console look when started in DEBUG verbosity mode. You can already see how the DEBUG setting gives us more information, and we can see that we have 10 test accounts available. In [1]: len(accounts.test_accounts) Out[1]: 10 We can associate these accounts to a variable and use them for our development and testing. In [2]: account_1 = accounts.test_accounts[0] In [3]: account_1.balance / 1e18 DEBUG: Making request. Method: eth_getBalance Out[3]: 1000000.0 Notice how the DEBUG verbosity shows you what happens and what method is called to request the balance.   Create a project with Ape  Now that we are familiar with the console let’s see how to create a project, deploy a contract and interact with it. We’ll work with a simple, smart contract written in Solidity for this tutorial. Keep in mind that you will have to initialize the environment variables with the endpoints again every time you close the terminal unless you store the environment variable in the local file ~/.bashrc (Linux) or ~/.zshrc (macOS).  The first step is to install the Solidity plugin. pip install ape-solidity Then we can initialize the project, create a directory where you want your project to live, then you can input the init command. ape init Your project will have this structure  Project root # The root project directory. ├── contracts/ # Smart contracts directory. └── smart_contract_example.sol # Sample of a smart contract, ".sol" or ".vy". ├── tests/ # Project tests, run using 'ape test'. └── test_sample.py # Sample of a test script. ├── scripts/ # Project scripts; run with 'ape run <name>'. └── deploy.py # Sample script to deploy a contract. └── ape-config.yaml # The ape project configuration file Let’s use this simple smart contract, which allows you to save a string on chain (on Goerli in this example) and create a SimpleStorage.sol in the contracts folder of the project. // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract SimpleStorage { string storedWord; function setWord(string memory _word) public { storedWord = _word; } function getWord() public view returns (string memory) { return storedWord; } } Deploy a smart contract from the Ape console  Now that we have a smart contract in the correct folder, we need to compile it. ape compile If everything goes well, there will be a __local__.json file in the .build directory containing the ABI, bytecode, and other information about the contract. Then we can deploy it directly from the Ape console.Start the console with the Goerli endpoint that we set up earlier. ape console --network ethereum:goerli:chainstack Initialize the address you want to use to deploy (you need to re-initialize it every time you exit the Ape console), in our case, the address that we created earlier, and deploy from the project manager. Note that we create an instance called “contract” so that we can interact with the contract we deploy. In [1]: dev_account = accounts.load("chainstack") In [2]: contract = dev_account.deploy(project.SimpleStorage) Once we confirm the transaction, the smart contract will be deployed, and the console will show us the address. INFO: Confirmed 0x899009c30ee0ade521bb97cda00ff5b2a157d5fcb3dfcd14ac26755ef7d64237 (total fees paid = 255956003071472) SUCCESS: Contract 'SimpleStorage' deployed to: 0xC88bfF0F5e264F4652327010E8eB3ab9c9Cf0372 Use the Ape console to interact with your smart contract   At this point, we have already learned a lot about this framework, and we deployed a smart contract on Goerli; it’s time to interact with it. The contract we just deployed allows us to save a string on chain and retrieve its value. Then, we can interact with it from the console quickly.We can, for example, retrieve the contract address like the following. In [4]: contract.address Out[4]: '0xC88bfF0F5e264F4652327010E8eB3ab9c9Cf0372' Now, let’s save a string on chain by calling the setWord() function; we have to specify which account sends the transaction and pays for gas, and the console will also return the receipt. In [5]: contract.setWord("Web3 is cool",sender=dev_account) Out[5]: <Receipt 0x217cdd40fdfb6d9f47ccbab66bc62f00b3edf094608b3bdf622a36161e7067bd> And at this point, calling the getWord() function should come easy to you. In [6]: contract.getWord() Out[6]: 'Web3 is cool' Extra tip: the Ape console is a Python interactive environment, so you can create functions to better interact with the smart contract. For example, a function to retrieve and print the string saved In the smart contract directly. In [15]: def word(): ...: savedWord = contract.getWord() ...: return savedWord ...: In [16]: print(word()) Web3 is cool Obviously, because this smart contract is so simple, it seems superfluous, but it can come in handy with more complex applications. You can find how to deploy and interact with smart contracts in the ApeWorX docs.  Deploy a smart contract from a script  Like in more traditional frameworks such as Brownie, we can deploy contracts and interact with them through a script.Follow the previous steps to: Initialize a new project and place the smart contract file in the contracts folder again; I will use the same contract.Set the terminal in the project root folder and run ape compile. Now we can create a new file in the scripts folder inside our project and call it deploy.pyWe first import the ape modules: accounts and project. Now, we have two options to pick the account we want to use to deploy and sign the transaction. The first is to hardcode it into the script. For example, the following code shows a deploy script with a hardcoded account. from ape import accounts, project def main(): from ape import accounts, project def main(): # Initialize deployer account and print balance dev_account = accounts.load("chainstack") print(f'The account balance is: {dev_account.balance / 1e18} Goerli ETH') # Deploy the smart contract and print a message dev_account.deploy(project.SimpleStorage) print("Contract deployed!") Note that we also added a few extra print statements to provide additional information. Furthermore, the script must be structured, with a main() function to work. The dev_account.deploy(project.SimpleStorage) line deploys the smart contract; note that the name SimpleStorage, in this case, must be the name of the smart contract, not the .sol file. Now go back to the terminal (always in the project root folder) and run the following: ape run deploy --network ethereum:goerli:chainstack This will prompt you to sign the transaction. The account balance is: 0.3986564444825816 Goerli ETH DynamicFeeTransaction: chainId: 5 from: 0xB6a6b3096e2E90780b745c676b842b9D2F657540 gas: 255956 nonce: 9 value: 0 data: 0x608060...0f0033 type: 0x02 maxFeePerGas: 1000000016 maxPriorityFeePerGas: 1000000001 accessList: [] Sign: [y/N]: Once the steps are completed, it will give you a success message and show the contract address.  Confirmations (2/2): 100%|████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:29<00:00, 14.77s/it] INFO: Confirmed 0xa88e5b15cbad7ce1c8466baff0c21e9ea2e8be606b9a08fb14d30c528ee1e71d (total fees paid = 255956003839340) SUCCESS: Contract 'SimpleStorage' deployed to: 0xa15fddEE05b12804797B16345F8d8DeaF7d285A1 Contract deployed! And here you go, you just deployed a smart contract using the Ape framework from a script. The following script does the same thing, but it gives the option to pick which account you want to use to deploy when you run it. This is suitable if you have multiple accounts and don’t want to hardcode a specific one in the script. from ape import project from ape.cli import get_user_selected_account def main(): # The CLI will ask which account to use dev_account = get_user_selected_account() print(f'The account balance is: {dev_account.balance / 1e18} Goerli ETH') # Deploy the smart contract and print a message dev_account.deploy(project.SimpleStorage) print("Contract deployed!") Then you run it the same way with ape run deploy --network ethereum:goerli:chainstack The only difference is that it will prompt you to pick an account to use. 0. chainstack 1. test Select an account: 0 The account balance is: 0.39861173848186626 Goerli ETH DynamicFeeTransaction: chainId: 5 from: 0xB6a6b3096e2E90780b745c676b842b9D2F657540 gas: 255956 nonce: 10 value: 0 data: 0x608060...0f0033 type: 0x02 maxFeePerGas: 1000000021 maxPriorityFeePerGas: 1000000001 accessList: [] Sign: [y/N]: y Interact with an already deployed contract  Interact from the console Once we deploy the smart contract, we can interact with it directly from the console or from a script.From the console, we can recall a deployed smart contact from its address. So let’s start the console with the usual command. ape console --network ethereum:goerli:chainstack And create a contract instance by recalling its address. In [1]: contract = Contract(“0xa15fddEE05b12804797B16345F8d8DeaF7d285A1”) Now we can interact with the contract precisely as we did earlier when we deployed the contract directly from the console. Interact from a script  We can also make scripts to interact with our contracts; we can place them in the scripts folder and run them with the ape run command if we create a function and call it in the command. The following code is a simple script to interact with the SimpleStorage contract. Remember that this is a Python-based framework, so we can leverage the Python code. The script’s logic is the following: Prompt the user to pick which account to use.Displays the address of the latest SimpleContract contract deployed.Prompt the user to input a string to save in the smart contract and calls the saveWord() function.After the transaction is confirmed, it calls the getWord() function and displays the string we saved. from ape import project from ape.cli import get_user_selected_account def simpleStorage_interact(): # The CLI will ask which account to use dev_account = get_user_selected_account() print(f'The account balance is: {dev_account.balance / 1e18} Goerli ETH') # Initialize latest deployed contract simple_storage= project.SimpleStorage.deployments[-1] print(f'The latest SimpleStorage contract is deployed at: {simple_storage.address}') # Prompt the user to input a string to save string_to_save = input("Type the string to save: ") print("Saving the string, please sign the transaction when prompted.") simple_storage.setWord(string_to_save, sender=dev_account) # Retrive and display the saved string print(f'The saved string is: {simple_storage.getWord()}') def main(): simpleStorage_interact() Once saved in the scripts folder, run the following command in the terminal from the project root. ape run simpleStorage_interact --network ethereum:goerli:chainstack We call the function simpleStorage_interact() directly from the terminal, which will look like this. 0. chainstack 1. test Select an account: 0 The account balance is: 0.648355782477259 Goerli ETH The latest SimpleStorage contract is deployed at: 0x5c5799e815a2686Cbe47003D83188E22E0493964 Type the string to save: Chainstack is cool Saving the string, please sign the transaction when prompted. DynamicFeeTransaction: chainId: 5 to: 0x5c5799e815a2686Cbe47003D83188E22E0493964 from: 0xB6a6b3096e2E90780b745c676b842b9D2F657540 gas: 44706 nonce: 11 value: 0 data: 0xcd048d...000000 type: 0x02 maxFeePerGas: 1000000014 maxPriorityFeePerGas: 1000000000 accessList: [] Sign: [y/N]: y Enter passphrase to unlock 'chainstack' []: Leave 'chainstack' unlocked? [y/N]: y INFO: Submitted 0x58eed7f8bdd2a2f098ca6bdffe9a5ed66f5c366931e78eaf2f5bebc8d4fa3a6c Confirmations (2/2): 100%|████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:29<00:00, 14.72s/it] INFO: Confirmed 0x58eed7f8bdd2a2f098ca6bdffe9a5ed66f5c366931e78eaf2f5bebc8d4fa3a6c (total fees paid = 44706000625884) The saved string is: Chainstack is cool Conclusion  The Ape framework is gaining traction and will become more popular as more people learn how easy it makes to develop smart contracts once it’s set up. This guide should get you up and running to create projects using Ape and gives you a few different options to deploy and interact with your smart contracts. I would say the most straightforward way is through the console directly, but creating and running scripts can be a fun way to do it as well. Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### SMARTy Pay on Chainstack: Delivering accessible historical data to optimize blockchain payment solution Blockchain payment solutions SMARTy Pay provides consumers of decentralized assets and services with a holistic platform for accepting and processing blockchain payment simultaneously across various networks. This makes it easier for all market participants to start accepting any available digital currencies as a means of payment. The platform ensures full confidentiality for the turnover of connected stores and provides support for modern DeFi exchange protocols. In doing so, it facilitates the transfer of funds and allows its users to take advantage of a palette of decentralized financial instruments in improving service quality and gaining additional income. Merchants can effectively accept payments on their websites in a seamless and convenient manner by using SMARTy Pay technology. In doing so, they gain access to a huge audience of potential customers, as well as funds already in circulation within the Web 3.0 ecosystem. SMARTy Pay provides support to a wide range of blockchain networks with its multi-chain operability but their main focus lies in BNB Smart Chain, Polygon, and other EVM-based options. It acts as both an on-ramp and an off-ramp for funds from numerous blockchains by integrating with their partners like MoonPay. What does SMARTy Pay do? SMARTy Pay’s main advantage for its users is the complete non-custodial and decentralized approach to all processes on the platform. This ensures the transparent and user-friendly functionality of the ecosystem. To make it all work, SMARTy Pay needed a robust API for the BNB Smart Chain network that could handle node deployment across multiple regions with archive support. After all, there is little room for error in production, with merchant balances and sensitive transaction data hanging in the balance. The gravity of the situation led SMARTy Pay towards Chainstack as a dependable provider that could manage the significant throughput, expected of their implementation. SMARTy Pay successfully deployed Chainstack’s stable infrastructure to perform critical tests, essential for the long-term reliability of its solution. How does the Chainstack offer match SMARTy Pay needs? The SMARTy platform is built upon a technologically complex system that leverages innovative contemporary implementations from the Web3 industry. But at the same time, this also comes with rigorous requirements to operate effectively. Even so, Chainstack offers scalable deployment that can fully respond to such demanding use-case. SMARTy Pay primed their integral functionalities using Chainstack’s flexible out-of-the-box solution in a cost-effective manner that fit their budget. Working side-by-side together with our support team, SMARTy Pay applied the necessary changes to adapt Chainstack’s infrastructure to their needs and ironed out the kinks that arose during the process. In the end, SMARTy Pay received the technological means they sought in the first place and responded with complete satisfaction to all aspects of our service. Outcome SMARTy Pay can now automate infrastructure network operations with databases and the blockchain application on a single platform, thanks to the Chainstack platform and managed services. SMARTy Pay takes advantage of trouble-free node maintenance and updates since it has uncompromised connection, security, and speed. Chainstack’s reasonable and predictable pricing structure allows SMARTy Pay to correctly allocate resources to strengthen its core services. In doing so, the company can focus on building critical product improvements and products that will improve their overall operations and user experience. The collaboration with Chainstack allowed access to a broader range of customisation options that enable the streamlining of both operational processes and business operations. SMARTy Pay can create and perform tests on an array of protocols with ease, while integrating blockchain distribution applications, with the help of Chainstack’s responsive support and do that at scale in a moment’s notice. What does SMARTy Pay like about Chainstack? Chainstack was a match made in heaven for the BNB Smart Chain network API and the relevant features we were looking for. Their solution was easy to deploy and work with while adapting its functionality to our desired business case. We put great emphasis on testing all aspects of our core offering, so having access to the Chainstack archive nodes was incredibly useful in simulating various use-cases using main net historical data. Vasily Lukoyanov, VP Engineering, SMARTy Pay What does Chainstack like about SMARTy Pay? For merchant-oriented projects, such as the case of SMARTy Pay, it is essential to be able to run effective tests against actual network data. This allows them to validate the output of their services prior to main net deployment and in doing so save themselves significant liabilities should something fail in production. We are thrilled to provide projects looking to create better opportunities for merchant blockchain adoption with the testing ground they need to try their applications pre-production. Eugene Aseev CTO & Founder, Chainstack What is the most interesting engineering challenge in working together? SMARTy Pay’s primary challenge was being able to perform cross-protocol critical structure tests against historical data at scale. Such tests are essential for identifying potential pitfalls that can cause significant loss of funds for their users in production and thus damage the project’s reputation. Chainstack supported SMARTy Pay throughout the deployment process of the BNB Smart Chain nodes they needed to begin testing their solution. Despite the gravity of the potential threats they faced, our team was there to deliver reliable infrastructure that was up to par with the strict standards, outlined in their requirements. After rigorous collaboration in adapting the implementation to their use-case, SMARTy Pay successfully obtained the means to perform adequate tests against historical data. This created new opportunities for improvement within the SMARTy Pay core, and in doing so, the way towards product excellence was finally opened. Power-boost your project on Chainstack Connect to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, Solana, Harmony, and Tezos mainnet or testnets through the interface designed to help you get the job done. Get access to the Ethereum, Polygon, Binance Smart Chain, Avalanche, Fantom, and Tezos archive nodes to query the entire history of the mainnet—starting at just $49 per month. Choose where you want to deploy, and we will provide you with the dedicated managed infrastructure that can handle high-volume, high-velocity read/write access to the network. To learn more about Chainstack, visit our Knowledge Center or join our Discord server and Telegram group.  Have you already explored what you can achieve with Chainstack? Get started for free today. #### SOC 2 Type 1: Our commitment to secure Web3 infrastructure We are excited to announce a significant milestone in our ongoing commitment to security and privacy: Chainstack is now SOC 2 Type 1 certified! This certification marks an important step forward in our mission to provide industry-leading security and reliability for all of our customers’ blockchain infrastructure needs. Our commitment goes beyond compliance—it’s about safeguarding our customers’ data and ensuring the reliability and scalability of our platform in an ever-evolving security landscape. Let’s explore the details of key security policies we have implemented at Chainstack. Secure access and role-based controls Chainstack employs a layered approach to access security, starting with a strict role-based access control (RBAC) model that limits each employee’s access to only what is essential for their role. This least-privilege approach minimizes the risk of insider threats and unnecessary exposure to sensitive data, enhancing accountability across the platform. To bolster this further, we mandate multi-factor authentication (MFA) for all service personnel, integrating both software-based and hardware security keys to add a robust, physical layer of protection against phishing attacks. For our customers, optional two-factor authentication (2FA) adds an additional security layer, allowing them to proactively safeguard their accounts. Through this multi-tiered security framework, Chainstack provides a secure environment for team members and customers alike, significantly reducing the risk of unauthorized access and ensuring data integrity and confidentiality across our platform. Resilient network security Data security is foundational to our platform, particularly in the fast-paced world of Web3 development. We employ Transport Layer Security (TLS) encryption for all data transfers, ensuring that data in transit is protected from unauthorized access or tampering. This secure communication channel helps maintain data integrity and privacy at every stage. Our platform also includes advanced defenses against network-based threats, such as Distributed Denial of Service (DDoS) attacks, which can disrupt operations. Real-time monitoring and traffic filtering allow us to block malicious activity while ensuring seamless access for legitimate users, providing resilience and continuity for developers. In addition, Chainstack’s cloud-native security model dynamically adapts to network conditions, enabling rapid responses to evolving Web3 threats. Our globally distributed, redundant infrastructure supports high availability, minimizing downtime risk and optimizing performance for users. Through robust encryption, advanced protections, and a resilient architecture, we offer developers a secure environment to focus on innovation with confidence. Proactive vulnerability management Proactive vulnerability management is essential for maintaining a secure and resilient infrastructure. We’ve implemented a two-pronged approach that combines external and internal strategies to detect and address vulnerabilities swiftly, ensuring comprehensive protection. This dual system allows us to stay ahead of emerging threats in today’s dynamic security landscape. Our bug bounty program invites ethical hackers to identify potential security gaps, adding an external layer of scrutiny. By working with these “white-hat” hackers, we gain valuable insights that help us address vulnerabilities promptly, ensuring our defenses stay aligned with the latest attack vectors. Internally, our vulnerability management system continuously scans and monitors our infrastructure, providing real-time detection and rapid remediation. Integrated into our workflows, this system reduces exposure to threats and ensures our platform remains secure. Together, these efforts reinforce Chainstack’s commitment to providing Web3 developers and enterprises with a trustworthy environment built on robust, adaptive security. Encrypted and backed up data storage At Chainstack, customer data security is paramount, and we implement multiple protective layers to ensure confidentiality and resilience. All customer data is securely stored with industry-leading encryption standards, rendering it unreadable without decryption keys, protecting data both at rest and in transit. This encryption-first approach underscores our commitment to safeguarding sensitive information against unauthorized access. To support rapid data recovery, we perform daily backups across multiple, geographically distributed locations, ensuring redundancy and resilience. This strategy enables swift restoration in case of data loss or unexpected events, minimizing downtime and allowing seamless continuity for customer operations. Our disaster recovery plan includes infrastructure designed for high availability, with rapid failover capabilities that keep services accessible even if one region experiences disruption. Combined with strict role-based access controls and multi-factor authentication (MFA) for internal data access, our approach ensures that customer data remains secure and available, empowering Web3 developers to innovate confidently on Chainstack’s platform. High availability for global access Chainstack’s globally distributed infrastructure provides Web3 developers with rapid, low-latency access to services, regardless of location. By positioning resources closer to users, we enable fast, seamless connections that support efficient blockchain development, ensuring consistent performance and scalability. This distributed setup also enhances fault tolerance, automatically rerouting traffic to alternative locations in case of regional disruptions, which minimizes downtime. Such resilience is essential for Web3 projects that demand continuous availability and reliability. Hosted in secure, certified data centers compliant with SOC 2 Type 1, ISO 27001, and GDPR standards, Chainstack’s infrastructure ensures both physical and information security. With this combination of global reach, redundancy, and strict certifications, we provide a secure, scalable foundation for blockchain projects worldwide. Comprehensive monitoring Real-time monitoring is crucial for providing reliable, high-performance infrastructure to Web3 developers and enterprises. Our proactive monitoring approach covers all platform components, allowing us to quickly identify and address any anomalies. By continuously analyzing critical security and performance metrics, we ensure high availability, integrity, and responsiveness for developers building on our platform. Our monitoring policies capture a broad range of metrics, from system health to security events, giving us a holistic view of platform performance. This enables us to optimize load times, reduce latency, and detect potential threats early, allowing us to maintain a seamless and secure experience for users worldwide. Scalability is built into our monitoring system, enabling us to support growing customer needs and increasingly complex applications. The insights gained through monitoring also guide our long-term strategy, helping us refine security and performance measures proactively. Chainstack’s real-time monitoring empowers developers to innovate confidently, knowing their projects are supported by a robust, reliable infrastructure. Secure development lifecycle Our dedication to security and reliability is integral to every stage of development. We recognize that Web3 developers and enterprises rely on a stable infrastructure, so every platform update undergoes a multi-stage testing and validation process in a controlled, production-identical environment. This approach ensures that each update is secure, functional, and high-performing, providing our customers with a dependable foundation for innovation. Our rigorous testing strategy covers functional, security, and load testing to address every dimension of performance. Functional testing verifies that new features operate as intended, while security testing, both automated and manual, identifies potential vulnerabilities. Load testing simulates high-traffic conditions, enabling us to optimize performance and resource allocation for scalability. In addition, we conduct thorough code reviews to catch issues early, ensuring quality and adherence to best practices. By embedding these practices into our workflow, we maintain a resilient infrastructure that allows Web3 developers to build and scale confidently, knowing Chainstack supports their projects with secure and reliable technology. Compliance and certifications At Chainstack, achieving and maintaining industry certifications like SOC 2 Type 1 underscores our commitment to providing a secure and reliable platform. These certifications validate our dedication to the highest standards in data security, confidentiality, integrity, and availability, enabling Web3 developers and enterprises to operate with confidence. Through rigorous audits, SOC 2 Type 1 confirms that our safeguards and risk management practices meet stringent Trust Services Criteria, securing customer data and ensuring operational integrity. Our security framework is supported by comprehensive internal policies. Our Information Security Policy governs data handling and access controls, while our Business Continuity and Disaster Recovery Policy prepares us to maintain service even in unexpected situations through redundancy and rapid failover. Additionally, our Patch Management Policy ensures all systems are regularly updated to defend against emerging threats, balancing timely security improvements with platform stability. Together, our certifications and policies reflect a proactive, evolving approach to security. By prioritizing compliance and continuous improvement, Chainstack offers Web3 developers a resilient, trustworthy platform built to support their projects securely and reliably, empowering them to innovate without compromise. Bringing it all together Achieving SOC 2 Type 1 certification is a milestone for Chainstack, underscoring our commitment to rigorous security standards in confidentiality, availability, and integrity. However, security is an ongoing journey, especially in the evolving Web3 ecosystem, where new opportunities bring new security challenges. We approach security as a continuous process, adapting and enhancing our protocols to stay ahead of emerging risks and keep our users safe. As blockchain technology expands into sectors like DeFi, NFTs, and beyond, the threat landscape grows. Chainstack remains proactive, consistently refining our security measures—including access controls, encryption standards, and threat detection—to maintain a resilient platform. This vigilance enables developers to focus on innovation, confident that their projects are supported by a robust, secure infrastructure. At Chainstack, we aim to empower the Web3 community by offering a platform that combines security with scalability. We invite developers and enterprises to explore our Security page or connect with our team to learn how Chainstack can support and secure their blockchain initiatives. Our mission is to provide trusted infrastructure for Web3 growth, ensuring projects are built on a foundation that’s secure, reliable, and ready for innovation. Power-boost your project on Chainstack Discover how you can save thousands in infra costs every month with our unbeatable pricing on the most complete Web3 development platform. Input your workload and see how affordable Chainstack is compared to other RPC providers. Connect to Ethereum, Solana, BNB Smart Chain, Polygon, Arbitrum, Base, Hyperliquid, Robinhood Chain, Arc, Tempo, MegaETH, Monad, Plasma, Avalanche, Optimism, Aptos, Cronos, Gnosis Chain, Moonbeam, Celo, Aurora, TON, Ronin, and Bitcoin mainnet or testnets through an interface designed to help you get the job done. Fast access to blockchain archive data and gRPC streaming on Solana. To learn more about Chainstack, visit our Developer Portal or join our Telegram group.  Connect your AI agent to Chainstack in seconds using Chainstack MCP — give Claude, Cursor, Codex, Gemini, and Windsurf live access to blockchain data, node management, and docs. Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Base Sepolia faucet, Solana devnet faucet, Hoodi faucet, BNB faucet, zkSync faucet, Robinhood Chain faucet, Hyperliquid faucet, Monad faucet, Amoy faucet, Plasma faucet, TON faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. #### SOC 2 Type II and ISO 27001 for blockchain infrastructure Introduction  Most blockchain infrastructure providers can’t clear a standard enterprise vendor review. ISO 27001 and SOC 2 Type II certification are the two frameworks that change that — and for regulated institutions, missing either one ends the conversation before it starts. Where most security frameworks operate in isolation, these two are complementary by design. ISO 27001 establishes the governance blueprint, covering the policies, risk management processes, and controls that define how an organization systematically protects its information assets. SOC 2 Type II then provides the audited evidence that those controls actually work, measured continuously over a 3 to 12 month observation period rather than a single point-in-time assessment. Together, they answer the due diligence requirements of Web3 enterprises, stablecoin issuers, and custodians who need bank-grade security assurances before routing transactions through L1 and L2 node infrastructure. The anatomy of Web3 audits: what it takes to certify node infrastructure Earning a security certification for blockchain node infrastructure is not the same as earning one for a typical SaaS product. The attack surface is different, the uptime requirements are more unforgiving, and the assets being protected, validator keys, RPC endpoints, consensus data, carry consequences that extend to protocol-level penalties and network instability. The frameworks that have emerged as the enterprise benchmark reflect that complexity. ISO 27001SOC 2 Type IIWhat it establishesA formal security management framework covering risk identification, treatment, and governanceAudited proof that the controls within that framework are operationally effectiveHow it is assessedTwo-stage audit: readiness assessment followed by full implementation reviewContinuous auditor observation over a 3 to 12 month periodThe question it answersDoes a comprehensive security framework exist?Does it hold up under real operating conditions?Certified byAccredited third-party certification bodyIndependent SOC auditor (CPA firm) ISO 27001 starts at the governance layer. Organizations pursuing certification must build a formal Information Security Management System that covers how risks are identified, treated, and monitored across the entire business, not just the engineering team. An accredited third party then verifies this in two stages: first a readiness assessment of the ISMS design, then a full implementation audit to confirm the framework is genuinely embedded in day-to-day operations. SOC 2 Type II then stress-tests that framework against real operations, with an independent auditor verifying the controls hold up over time rather than on a single review date. Who actually asks for this, and why  The push for certified blockchain infrastructure is not coming from the crypto-native side of the market. It is coming from institutions that have spent decades operating under regulatory frameworks that treat vendor risk as their own risk, and they are bringing that same scrutiny to Web3. For regulated financial institutions and custodians, third-party infrastructure providers sit inside the same vendor due diligence process as any cloud provider or payment processor. Before a contract clears internal security review, the provider typically needs to demonstrate recognized certifications. In practice, the two that come up most consistently are SOC 2 Type II and ISO 27001, since they map directly onto the control categories these institutions already audit internally across access management, incident response, availability, and data integrity. The regulatory dimension sharpens this for specific categories of buyer: Stablecoin issuers and tokenized asset platforms operating under MiCA or state money transmitter licenses need auditable proof that their node infrastructure meets the same security bar their own compliance teams are held to. Banks, asset managers, and payment processors moving on-chain apply the same third-party risk management process they use for any vendor. Guidance from regulators like the OCC and SEC explicitly requires institutions to assess the security posture of third-party providers before onboarding them, and infrastructure without recognized certifications rarely makes it past that initial screen. The result is that certification has become a baseline requirement in enterprise procurement, not a differentiator. Providers without it are not evaluated on their merits, they are filtered out before that conversation starts. Mapping compliance to the blockchain infrastructure stack Applying these control requirements to a stack that includes validator nodes, RPC endpoints, and distributed consensus mechanisms means getting specific about what they actually look like in practice. Access control starts with multi-factor authentication and role-based access controls restricting who can interact with critical systems, but validator key protection goes a step further. Hardware security modules handle the cryptographic operations directly, keeping private key material from ever being exposed in software memory where it could be extracted or copied. Availability is a protocol-level concern here, not just a service quality one. Nodes need to maintain continuous participation in network consensus, so geo-distributed clusters remove single points of failure across regions while automated self-healing scripts handle node recovery without waiting for manual intervention. Change management is where blockchain infrastructure diverges most from conventional software. Protocol client updates to Geth, Erigon, or Reth carry real risk because a faulty update can cause a node to fall out of consensus entirely. Testing in isolated environments before deployment, combined with multi-signature code approvals requiring sign-off from multiple engineers, creates an auditable trail that gives SOC 2 auditors something concrete to evaluate. Mitigating Web3-specific risks under attack conditions Certified controls cover the baseline. What they do not automatically address are the attack vectors specific to blockchain infrastructure, where the consequences of a security failure extend beyond data exposure to protocol-level penalties and network disruption. Double-signing is one of the more severe risks for validator operators. During a network split, a misconfigured validator can end up signing blocks on two competing forks at once, an infraction most proof-of-stake protocols punish automatically through slashing, cutting into staked assets without any manual intervention required. Real-time consensus monitoring is what prevents it, flagging duplicate key activity the moment it appears and shutting down the secondary node before it gets the chance to sign. At the RPC layer, Layer-7 exploits and mempool-clogging attacks are handled through a combination of: Tier 3 data center infrastructure Rate-limiting policies that cut off abusive request patterns Automated traffic scrubbing that filters malicious payloads before they reach the node Data protection covers the full lifecycle. RPC history and blockchain data move over TLS-encrypted channels, with AES-256 encryption applied at rest, ensuring that whether data is in transit or stored, it is not accessible in plaintext at any point in the stack. Conclusion There is a broader shift visible in what enterprises are asking for when they request ISO 27001 and SOC 2 Type II from blockchain infrastructure providers. It is not really about the certifications themselves. It is about whether the infrastructure layer can absorb the compliance burden that regulated institutions carry, so they do not have to reconstruct it themselves every time they want to connect to a new network. Traditional finance moving on-chain has a structural problem: the due diligence frameworks it operates under were built for a world where infrastructure providers are large, audited, and predictable. Blockchain infrastructure has historically been none of those things. Certification does not solve every part of that gap, but it does establish a common language between the two worlds, one that compliance teams, risk committees, and regulators already know how to evaluate. The deeper implication is that security compliance is becoming load-bearing infrastructure for Web3 adoption at the institutional level. Protocols can be technically sound, teams can be competent, and products can work exactly as advertised, but without an auditable security foundation underneath, the institutional capital that would actually move markets stays on the sideline. That is the problem certification solves, and why it has shifted from a sales asset to a structural requirement. That is the gap dual certification closes. Chainstack, now holding both SOC 2 Type II and ISO 27001 certification, is one of the few infrastructure providers that can hand a compliance team both audit reports on the first ask. Review Chainstack’s security posture and certifications → Read the ISO 27001 certification announcement → FAQ What is SOC 2 Type II certification for blockchain infrastructure? SOC 2 Type II is an independent audit that verifies a service provider’s security controls are operationally effective over a sustained observation period — typically 3 to 12 months. For blockchain infrastructure providers, it covers controls across availability, access management, incident response, and data integrity. Unlike a point-in-time assessment, it confirms the controls hold up under real operating conditions, not just on the day of review. How does ISO 27001 differ from SOC 2 Type II? ISO 27001 establishes the governance framework — the policies, risk processes, and controls an organization uses to manage information security. SOC 2 Type II then provides audited evidence that those controls actually work in practice. ISO 27001 answers “does a security management system exist?”; SOC 2 Type II answers “does it hold up over time?” Most enterprise procurement processes require both. Do blockchain RPC providers need to be SOC 2 certified? Not legally, but practically yes for institutional clients. Regulated financial institutions — banks, asset managers, custodians — apply the same third-party vendor risk process to RPC providers as they do to cloud providers and payment processors. A provider without SOC 2 Type II or ISO 27001 typically doesn’t make it past the initial security screening, regardless of technical capability. What does SOC 2 Type II and ISO 27001 cover in a validator node environment? In a validator node context, SOC 2 Type II and ISO 27001 auditors evaluate controls specific to that environment: hardware security module usage for key protection, geo-distributed availability architecture, change management procedures for protocol client updates, and real-time monitoring for consensus anomalies like duplicate signing. The audit scope goes beyond generic SaaS controls because the assets being protected — validator keys, RPC endpoints, consensus data — carry protocol-level consequences if compromised. How long does a SOC 2 Type II audit observation period last? The observation period runs between 3 and 12 months, during which an independent auditor continuously monitors whether the provider’s controls are functioning as documented. A longer observation period generally carries more weight with enterprise buyers because it demonstrates consistency across different operating conditions, not just a clean snapshot at one point in time. Additional resources Chainstack Security Chainstack SOC 2 Type II announcement SOC 2 Type II and ISO 27001 at the AICPA ISO/IEC 27001:2022 standard MiCA Regulation full text — EUR-Lex Chainstack blog: Blockchain security and smart contract audits Chainstack achieved ISO/IEC 27001 certification #### Solana Alpenglow: how Votor replaces TowerBFT The problem with “fast enough” Solana processes more transactions per second than any other live blockchain, with 400ms slot times and fees that are effectively negligible. But throughput and finality are different things, and Solana has always had a gap between them. A transaction can land in a block in under a second and still take 12.8 seconds to reach deterministic finality. That window comes from TowerBFT, the consensus mechanism Solana has run since launch. To finalize a block, validators must vote on it across 32 successive slots, each vote adding an exponential lockout that makes reorganizing the chain increasingly expensive. It works, but it means every app on Solana is building around a finality delay that its raw throughput numbers never implied. Proof of History compounded this by acting as a cryptographic clock baked into consensus itself, tying ordering and timing together in a way that made sense when the network needed to prove it could run at all. That tradeoff is now the ceiling. Alpenglow is the attempt to remove it. What Alpenglow actually is (and isn’t) Alpenglow is the name for a full redesign of how Solana reaches consensus. It has two parts, and only one of them is actually shipping right now. Votor is the voting and finalization engine that replaces TowerBFT. It is the core of Alpenglow, the part that governance approved as SIMD-0326 with 98.27% of participating validator votes in favor, and the part that is currently running on the dedicated community test cluster. Rotor, the block propagation layer that will eventually replace Turbine entirely, is explicitly deferred to its own separate SIMD process. At activation, Turbine stays in place, which means the breaking changes on day one are confined entirely to the consensus layer. The 98.27% approval figure is worth pausing on. Validator governance on Solana rarely produces that kind of unanimity. It signals that the economic and technical case for Alpenglow was not seriously contested among active validators, which matters for how confidently infrastructure teams can plan around it. Where Alpenglow stands right now The upgrade has moved faster than most Solana protocol changes, but it is not on mainnet yet. Here is where things stand: September 2025: SIMD-0326 passed validator governance with 98.27% approval December 2025: Alpenglow demonstrated publicly at Breakpoint May 11, 2026: went live on the dedicated Anza community test cluster, including a live “Alpenswitch” migration from TowerBFT H2 2026: mainnet target via the Agave 4.1 client release, with community testing expected to run through Q3 and into Q4, gated on public testnet activation and security audits The most concrete near-term signal to watch is SIMD-0387, the BLS key management prerequisite, landing on public testnet. That is the clearest indicator the upgrade has moved from a private cluster to a public network. Firedancer has endorsed the design but has no production Votor implementation on any cluster yet, making multi-client parity the other key variable before mainnet activation. Teams behind Alpenglow Alpenglow is the work of Anza’s research division, led by Professor Roger Wattenhofer of ETH Zurich, one of the world’s top-ranked institutions for distributed systems research. Wattenhofer is joined at Anza by his former PhD students, Kobi Sliwinski and Quentin Kniep. The academic roots matter here: Wattenhofer previously co-authored the 2024 paper “Halting the Solana Blockchain with Epsilon Stake,” which uncovered liveness vulnerabilities in Solana’s existing consensus protocol. The team that found the holes in TowerBFT is the same team that designed its replacement. Anza itself was spun out from Solana Labs and comprises the entire core protocol development team. They are best known for building the Agave client, the software that powers the vast majority of Solana’s network. On the client diversity side, Jump Crypto’s Firedancer team is collaborating on multi-client compatibility. Their involvement is significant for network resilience, though as covered in the conclusion, a production Votor implementation from Firedancer is still pending. How Votor works Under TowerBFT, validators cast their votes as on-chain transactions. Every vote was a real transaction, processed and stored like any other, which is why validator votes make up roughly 75% of all Solana transactions today. Votor removes that entirely. Instead, validators broadcast lightweight vote messages directly to each other. Any node can collect those messages and aggregate them into a BLS12-381 certificate once enough stake weight has been signed. That certificate, roughly 1,000 bytes, is the only thing that touches the chain. The individual votes never do. Two finalization paths run at the same time. The fast path finalizes a block in a single round when at least 80% of stake has voted. The slow path finalizes after two rounds, requiring a notarization certificate at 60% stake followed by a finalization certificate at 60% stake. Whichever path crosses its threshold first finalizes the block. Running both concurrently means the protocol does not have to choose between speed and resilience upfront. It takes whichever outcome arrives first. Before vs. after comparison Before (TowerBFT + PoH)After (Alpenglow + Votor)Finality time~ 12.8 seconds~ 100–150msVoting mechanismOn-chain vote transactionsOff-chain BLS messagesWhat touches the chainEvery individual voteOne ~1,000-byte certificateProof of HistoryCore part of consensusRemoved from consensusVote transaction volume~75% of all Solana transactionsEliminatedValidator vote cost~1 SOL per day in feesVAT: ~0.8 SOL per day, burnedByzantine fault tolerance33%20% adversarial + 20% crashBlock propagationTurbineTurbine (unchanged for now) Vote transactions: 75% of Solana, gone When vote transactions disappear, two things happen at once. Block space opens up dramatically, with roughly 75% of all Solana transactions gone overnight, leaving room for user transactions that were previously competing with validator housekeeping. But that same disappearance creates a problem: vote transactions were generating fees, and those fees were being burned. Remove them and you remove a significant share of the deflationary pressure that SOL’s tokenomics depend on. The Validator Admission Ticket is how Solana solves that. Rather than paying per-vote transaction fees, validators pay a flat admission ticket — initially 1.6 SOL per epoch, roughly 0.8 SOL per day — to be admitted into the active set for that epoch. That fee is burned, preserving the burn mechanic that vote transactions were inadvertently providing. It is not a discount on validator operating costs so much as a structural replacement for the fee flow that disappears when votes go off-chain. Why Alpenglow bets on a tighter safety margin Classic Byzantine fault tolerant protocols tolerate up to 33% of stake acting maliciously before safety breaks. Alpenglow drops that to 20%, which on the surface looks like a regression. In practice it is a deliberate trade: by tightening the Byzantine threshold, Votor can finalize blocks in a single round rather than two, which is what makes the 100-150ms finality target possible. The protocol also separately tolerates up to an additional 20% of stake being offline or crashed, so the total non-responsive stake it can handle sits around 40%. The more significant change is not the number itself but how it is justified. TowerBFT was never formally proven safe. Its correctness was established the way most early blockchain consensus mechanisms were: through simulation, game-theoretic reasoning, and years of running on a live network with real economic stakes. That is a legitimate form of validation, but it is not the same as a mathematical proof. Alpenglow ships with formal safety proofs. The protocol’s behavior under adversarial conditions is not argued by analogy or stress-tested into confidence; it is derived. For a network handling the transaction volume Solana does, that is a meaningful maturity leap, and it changes the conversation around Solana from a network that has survived to one that can be reasoned about. What this means for builders and infrastructure Commitment levels and streaming pipelines Solana currently exposes three commitment levels: processed, confirmed, and finalized. A lot of application code is built around the gap between confirmed and finalized, either defaulting to confirmed for speed while accepting some rollback risk, or polling for finalized as the slow but safe option. Under Alpenglow that gap effectively disappears. Both levels converge into a single deterministic certificate that arrives in roughly 100-150ms, which means the trade-off your code was making no longer exists in the same form. The shift this forces is straightforward: Replace polling loops with signatureSubscribe for push-based finality detection Shorten cache TTLs to under 250ms or add certificate-aware invalidation Audit any code that treats confirmed and finalized as meaningfully different states For Geyser and Yellowstone gRPC consumers, the change is more structural. Vote transactions make up roughly 75% of current Solana transaction volume and they vanish at activation. Pipelines that are sized, filtered, or instrumented around that volume need to be reworked before mainnet, not after. Specifically: Transaction volume drops ~75% overnight, so any consumer sized around current throughput will be over-provisioned Slot-status logic that treats finalized as a slow trailing event needs review against the new certificate-based model Validator prerequisites Before Alpenglow activates on any public network, validators must register a BLS public key on their vote account per SIMD-0387. A vote account without a registered BLS key will behave as unstaked once Alpenglow is live. Tracking SIMD-0387 landing on public testnet is the clearest signal that the upgrade is moving from a private cluster to a public network. Chainstack Solana RPC endpoints are the right place to test your integration as those testnet builds become available. What could delay mainnet The most concrete gate is SIMD-0387, the BLS key registration prerequisite, landing on public testnet with enough runway for validators to register before activation. If that slips, everything downstream slips with it. Security audits are a separate formal requirement, and any findings that require meaningful changes to the implementation reset that process entirely. The harder variable to predict is multi-client parity. Activating Alpenglow with Firedancer holding no production Votor implementation means the vast majority of stake runs on a single client through the transition. That is a risk the community will need to weigh, and waiting for Firedancer to catch up could push activation into 2027. The 100-150ms finality figures are also still simulation-derived, and public testnet at full validator scale may surface edge cases the community cluster did not. Conclusion Alpenglow passed governance under SIMD-0326 with 98.27% validator approval and went live on the community test cluster on May 11, 2026. Anza and Anatoly Yakovenko have confirmed a late Q3 or early Q4 2026 mainnet target via the Agave 4.1 client release. The variable most teams are underweighting is client diversity. Firedancer has engaged seriously with the roadmap, proposing SIMD-0370 to lift block compute limits on the basis that Alpenglow makes higher hardware scaling safe. But without a production Votor implementation on any live cluster, multi-client parity remains an open question that could affect the mainnet timeline. Start building with Chainstack → FAQ When will Alpenglow activate on Solana mainnet? Anza and Anatoly Yakovenko have indicated a late Q3 or early Q4 2026 mainnet target via the Agave 4.1 client release. That target is gated on three things: SIMD-0387 (BLS key registration) landing on public testnet, security audits clearing without major findings, and the Agave 4.1 release reaching stable. Any of those can slip the date. Do I need to change my application code before Alpenglow activates? Yes, in three places. Any code that polls signature status should move to signatureSubscribe for push-based finality detection. Any cache with a TTL above ~250ms needs certificate-aware invalidation. Any logic that treats confirmed and finalized as meaningfully different states should be audited, because both commitment levels effectively converge into one deterministic certificate at ~100-150ms. Will my Geyser or Yellowstone gRPC pipeline break after Alpenglow? It will not break, but it will be over-provisioned. Vote transactions disappear at activation, which removes roughly 75% of current transaction volume from the stream. Pipelines sized around that volume should be resized before mainnet, not after. Slot-status logic that treats finalized as a slow trailing event also needs review against the new certificate-based finality model. When can I start testing my integration with Alpenglow? The clearest signal is SIMD-0387 landing on public testnet, which marks the move from the private community cluster to a public network. Once testnet builds are available, Chainstack Solana RPC endpoints are the right place to validate your integration against the new finality model before mainnet activation. Does Alpenglow remove Proof of History from Solana? Yes, from consensus. Alpenglow removes PoH as a consensus primitive and replaces it with a fixed ~400ms block time plus local timeout timers on each validator. PoH no longer governs ordering or finality. The ~400ms slot cadence itself does not change in this upgrade. What happens to validators that do not register a BLS key in time? A vote account without a registered BLS public key per SIMD-0387 will behave as unstaked once Alpenglow activates. The validator will still be online, but their stake will not count toward consensus and they will not earn rewards. SIMD-0387 is the most concrete prerequisite for any validator operator to track ahead of activation. Additional resources SIMD-0326: Alpenglow — the governance proposal that defines Votor, the VAT, and the 20+20 security model. The first place to go for any technical question about what is actually shipping. SIMD-0387: BLS Pubkey Management in Vote Account — the validator prerequisite. Landing on public testnet is the concrete signal that Alpenglow is moving toward mainnet. Alpenglow Whitepaper v1.1 — the full academic paper from Kniep, Sliwinski, and Wattenhofer, including the formal safety proofs and the Rotor design that ships separately. Anza Research: A New Chapter for Solana’s Protocol — Anza’s own introduction to the research team and the protocol’s academic lineage. Chainstack Solana RPC — the place to test your integration against testnet builds as SIMD-0387 reaches public testnet. Chainstack docs: Solana Alpenglow consensus explained — the operator-facing companion to this post, with the readiness checklist for RPC and node teams. #### Solana Anchor Accounts: Seeds, Bumps and PDAs How Solana Anchor Accounts and Constraints Work In this post, we’ll walk through a minimal Solana Anchor program that creates, updates, and closes a user-owned PDA, and then call it end-to-end from a TypeScript script. Along the way, you’ll learn how Anchor derives accounts, when you need to pass them manually, why storing the bump matters, and how the client auto-fills everything based on your constraints. This post walks through building a small Anchor program that creates, initializes, and reads a user-owned PDA derived from predictable seeds. You’ll see how Anchor enforces account constraints, allocates on-chain space with InitSpace, and stores the bump for safe future validation. Anchor is the most popular framework for Solana programs. Think of it as: a Rust DSL for accounts & constraints (declarative checks instead of manual AccountInfo plumbing), a toolchain (build, deploy, test, IDL generation), and a TypeScript client that auto-types your program interface from the IDL. In practice, Anchor gives you: #[account] Rust structs that map 1:1 to on-chain data accounts, #[derive(Accounts)] contexts with constraints like init, seeds, bump, has_one, close (Will be covered soon) auto-generated IDL + a TypeScript client (@coral-xyz/anchor) to call your instructions safely. More about the Anchor directory layout can be found in the Anchor documentation. We will cover only the interesting part: How the program behaves on-chain. Rust code use anchor_lang::prelude::*;declare_id!("<YOUR-PROGRAM-ID>");#[program]pub mod solana_accounts { use super::*; /// Create a PDA for the user and store their name + creation time. pub fn create_user(ctx: Context<CreateUser>, name: String) -> Result<()> { // Enforce max length in BYTES (UTF-8). Emojis count as multiple bytes. require!( name.as_bytes().len() <= UserAccount::MAX_NAME, ErrorCode::NameTooLong ); let user = &mut ctx.accounts.user_account; user.owner = ctx.accounts.authority.key(); user.name = name.clone(); // fits because we sized with MAX_NAME user.created_at = Clock::get()?.unix_timestamp; user.bump = ctx.bumps.user_account; Ok(()) }}#[account]#[derive(InitSpace)]pub struct UserAccount { pub owner: Pubkey, // 32 #[max_len(32)] pub name: String, // 4 + up to 32 bytes pub created_at: i64, // 8 pub bump: u8, // 1}impl UserAccount { pub const MAX_NAME: usize = 32; // Total space to allocate at init time: // 8 (discriminator) + INIT_SPACE computed by Anchor from the struct pub const SPACE: usize = 8 + Self::INIT_SPACE;}#[derive(Accounts)]pub struct CreateUser<'info> { #[account(mut)] pub authority: Signer<'info>, /// PDA: seeds = ["user", authority] #[account( init, payer = authority, space = UserAccount::SPACE, seeds = [b"user", authority.key().as_ref()], bump )] pub user_account: Account<'info, UserAccount>, pub system_program: Program<'info, System>,}#[error_code]pub enum ErrorCode { #[msg("Name too long (max 32 bytes).")] NameTooLong,} Overview What it stores: A per-wallet UserAccount at a PDA derived from [“user”, authority]. Instructions (will be covered in next blog post) create_user(name): creates and initializes the PDA with owner, name, created_at, bump. Program Id (why it matters) declare_id!("<YOUR-PROGRAM-ID>"); Anchor bakes this value into the binary. At runtime, it must equal the on-chain program account you’re invoking, or you’ll get DeclaredProgramIdMismatch. Make sure declare_id!, Anchor.toml, and your client all use the same pubkey before you build/deploy. The account: layout & size #[account]#[derive(InitSpace)]pub struct UserAccount { pub owner: Pubkey, // 32 #[max_len(32)] pub name: String, // 4 + up to 32 bytes pub created_at: i64, // 8 pub bump: u8, // 1} Anchor will compute UserAccount::INIT_SPACE. When initializing, allocate 8 + UserAccount::INIT_SPACE (the extra 8 is the discriminator). Enforce the length at runtime (require!(name.as_bytes().len() <= 32, …)). This avoids “serialize to unexpected length” failures. PDAs, seeds, and bump PDA derivation: PDA = find_program_address(["user", authority_pubkey], program_id) Why bump exists: it’s the one-byte nonce that forces the derived address off the ed25519 curve so it can be program-owned. Store bump on the account so you can reference it in constraints: seeds = [b"user", authority.key().as_ref()], bump = user_account.bump Instruction: create_user object overview #[derive(Accounts)]pub struct CreateUser<'info> { #[account(mut)] pub authority: Signer<'info>, /// PDA: seeds = ["user", authority] #[account( init, payer = authority, space = UserAccount::SPACE, seeds = [b"user", authority.key().as_ref()], bump )] pub user_account: Account<'info, UserAccount>, pub system_program: Program<'info, System>,} pub authority: Signer<'info> : This field represents the caller of the instruction, and the Signer represents that this account must sign the transaction, it have #[account(mut)] because this signer will pay for the account creation fee, so their balance will change. pub user_account: Account<'info, UserAccount> : This is the PDA account that we are creating. It is the on-chain data structure it will store what was declared in UserAccount object. Notes init: creates the PDA and zero-inits data. payer: authority funds rent. space: uses 8 + INIT_SPACE (as declared in impl UserAccount). seeds: uses “user” constant string and authority address. bump: anchor know how to autofill it (used to find address off curve). pub system_program: Program<'info, System> : Any init must call the system program under the hood which allocate new account, assign ownership, transfer lamports from payer. This field is required for account creation, lamport transfers, PDA initialization Handler overview pub fn create_user(ctx: Context<CreateUser>, name: String) -> Result<()> { // Enforce max length in BYTES (UTF-8). Emojis count as multiple bytes. require!( name.as_bytes().len() <= UserAccount::MAX_NAME, ErrorCode::NameTooLong ); let user = &mut ctx.accounts.user_account; // Stores the wallet that created this profile user.owner = ctx.accounts.authority.key(); // This assigns into the fixed allocated space Anchor reserved via #[max_len] user.name = name.clone(); // fits because we sized with MAX_NAME // Clock sysvar contains the current cluster time user.created_at = Clock::get()?.unix_timestamp; // Why store the bump: // we used: PDA = find_program_address(["user", authority], bump) // We don't want to recompute bump manually later // update_name and close_user enforce (We will see it later) user.bump = ctx.bumps.user_account; Ok(())} Context<CreateUser>: Gives you validated access to all accounts declared in the CreateUser struct. Anchor has already validated all constraints and created/allocated required accounts Client side (Ts) Save this file in scripts/solana_accounts.ts Note: For this code to run we need to export 2 env variables: export ANCHOR_PROVIDER_URL=”http://127.0.0.1:8899” export ANCHOR_WALLET=”$HOME/.config/solana/id.json” import * as anchor from "@coral-xyz/anchor";import type { Program } from "@coral-xyz/anchor";import { LAMPORTS_PER_SOL, PublicKey } from "@solana/web3.js";import { SolanaAccounts } from "../target/types/solana_accounts";(async () => { const provider = anchor.AnchorProvider.env(); anchor.setProvider(provider); // Use Anchor workspace (uses generated IDL/types under target/) const program = anchor.workspace.solanaAccounts as Program<SolanaAccounts>; const wallet = provider.wallet as anchor.Wallet; // PDA: seeds = ["user", authority] // Seeds must match the program's #[account(seeds = [b"user", authority])]. From Rust! const [userPda] = PublicKey.findProgramAddressSync([Buffer.from("user"), wallet.publicKey.toBuffer()], program.programId); console.log("Wallet:", wallet.publicKey.toBase58()); console.log("Program:", program.programId.toBase58()); console.log("User PDA:", userPda.toBase58()); // 1) createUser // Derivable accounts (PDAs) are autofilled by Anchor // No need to pass programId or PDA here! it knows from the context. const sig1 = await program.methods .createUser("ByteBeetle") .accounts({ authority: wallet.publicKey }) // derivable accounts are autofilled .rpc(); console.log("createUser tx:", sig1); // Fethch and log the created account const acct1 = await program.account.userAccount.fetch(userPda); const createdAtBn = (acct1 as any).createdAt ?? (acct1 as any).created_at; const createdAt = new Date(createdAtBn.toNumber() * 1000).toISOString(); console.log("After create:", { owner: acct1.owner.toBase58(), name: acct1.name, created_at: createdAt, bump: acct1.bump, }); console.log("Done ✅");})().catch((e) => { console.error(e); process.exit(1);}); Run it all together # In separate terminalsolana-test-validator -r# New tab or new terminalsolana config set --url http://127.0.0.1:8899solana config set --keypair ~/.config/solana/id.json # Run this in project rootsolana-keygen new -o target/deploy/solana_accounts-keypair.json --no-bip39-passphrasesolana-keygen pubkey target/deploy/solana_accounts-keypair.json# Paste this pubkey into:# - programs/solana_accounts/src/lib.rs: declare_id!("...")# - Anchor.toml: [programs.localnet].solana_accounts = "..."anchor cleananchor buildanchor deploy# Reminder: you need to run this before:# export ANCHOR_PROVIDER_URL="http://127.0.0.1:8899"# export ANCHOR_WALLET="$HOME/.config/solana/id.json"pnpm ts-node scripts/solana_accounts.ts You should see something like this after deployment: You should see something like this after running the client: Summary In this post, we built a minimal Anchor program that creates a per-user PDA and interacted with it end-to-end using the TypeScript client.You learned how Anchor: Derives PDAs deterministically using seeds and bump, and why storing the bump simplifies future validations. Uses #[account] and #[derive(Accounts)] to define data layouts and constraints declaratively. Allocates account space safely with #[max_len] and InitSpace, avoiding serialization errors. Auto-generates a TypeScript client from the IDL that pre-fills PDAs and program IDs automatically. Relies on consistent configuration between declare_id!, Anchor.toml, and your deployed program ID. By understanding how Anchor resolves accounts and constraints behind the scenes, you can reason better about what actually happens on-chain and debug or extend your Solana programs with confidence. Learn more about Solana architecture from our articles Architecture & Parallel Transactions Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution SPL Token Program Architecture Reliable Solana RPC infrastructure Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers. #### Solana confidential transfers: how Token-2022 privacy works Historically, solving the privacy problem has meant abandoning the Layer-1 execution environment. Developers have been forced to spin up complex Layer-2 Zero-Knowledge (ZK) rollups, manage off-chain provers, or fragment their liquidity into isolated privacy pools. Solana’s Token-2022 standard changes this by bringing the cryptography directly to the base layer. With the introduction of the Solana Confidential Transfers extension, Token-2022 embeds native Zero-Knowledge proofs and Twisted ElGamal encryption directly into the SPL token standard. Instead of moving assets to a separate network to obfuscate them, the tokens themselves carry encrypted state. The runtime mathematically proves to the network that a transfer is valid, ensuring no tokens were secretly minted or burned without ever revealing the actual transfer amount or the underlying account balances. Just like the Interest-Bearing extension shifted yield from state mutation to pure computation, the Confidential Transfer extension shifts privacy from off-chain infrastructure to native, on-chain cryptography. However, encrypting and decrypting state natively on the BPF runtime requires a radical shift in how we handle token routing. A standard transfer no longer just subtracts from Account A and adds to Account B. Instead, it introduces complex cryptographic states like “pending balances” and requires explicit ZK-proof verification instructions. In this deep dive, we are going to unpack the architecture of the ConfidentialTransfer extension. We will break down the encrypted state layout and inspect the raw ciphertexts using the Solana CLI. What are Solana confidential transfers When developers first hear “Confidential Transfers,” they often assume it is a privacy coin mixer like Tornado Cash. It is not. Token-2022 Solana Confidential Transfers do not obfuscate the transaction graph. If Alice sends a confidential transfer to Bob, the network (and anyone looking at a block explorer) can still see: The Sender: Alice’s wallet address. The Receiver: Bob’s wallet address. The Token: The specific Mint address being transferred. What the network cannot see is the amount of tokens transferred and the underlying balances of Alice and Bob’s accounts. To achieve this, Token-2022 introduces a dual-state architecture. A single token account now holds two entirely separate balances: The Public Balance: The standard u64 integer representing public tokens (fully transparent). The Confidential Balance: Cryptographic ciphertexts representing encrypted tokens. These two balances exist side-by-side. Tokens enter the encrypted ecosystem via a Deposit instruction, where a user converts their public tokens into an encrypted ciphertext. However, once those tokens are shielded, they can circulate privately forever. If you receive a confidential transfer from a friend or an employer, you never have to touch the public balance, you can simply hold, transfer, or spend those encrypted tokens using Zero-Knowledge proofs (will be explained shortly). If you ever want to exit the shielded ecosystem, you execute a Withdraw instruction, decrypting the ciphertext and moving the funds back to your public balance. A high-level overview of the cryptography of encrypted state To understand the architecture, let’s understand the core problem. Imagine Alice wants to send Bob 10 tokens. On a standard SPL token, the runtime simply checks if Alice has >= 10 tokens and if so subtracts 10 from her balance, and adds 10 to Bob’s balance. If we want to make this confidential, the most obvious solution is to encrypt the token balances before writing them to the account data. But this introduces an immediate architectural roadblock: if the Token-2022 program cannot read the raw numbers because they are encrypted, how can it execute the transfer? It cannot natively subtract 10 from Alice’s account if it doesn’t know what her balance is. Linear homomorphism To solve this, Token-2022 relies on a class of encryption called Linear Homomorphism. A linearly homomorphic encryption scheme allows mathematical operations, like addition and subtraction to be performed directly on encrypted ciphertexts, yielding a result that perfectly matches the encrypted sum or difference of the underlying plaintexts. When Alice initiates a confidential transfer, she doesn’t pass the raw number 10 to the program. Instead, she generates an encrypted ciphertext of the transfer amount. The Token-2022 program simply takes Alice’s encrypted account balance, subtracts the encrypted transfer amount, and saves the new ciphertext back to her state. It then takes Bob’s encrypted balance, adds the encrypted transfer amount, and saves it. Encrypted(50) – Encrypted(10) = Encrypted(40) Because the math is homomorphic, the Solana runtime successfully processes the transfer without ever knowing that the underlying numbers were 50, 10, and 40. Zero-Knowledge Proofs – trust but verify If the program never decrypts the underlying numbers, what stops a malicious user with an encrypted balance of 50 from sending an encrypted transfer of 70? Or what stops them from sending a negative amount to mathematically inflate their own balance? Because the token program cannot natively see the hidden inputs, every confidential transfer must be accompanied by Zero-Knowledge (ZK) Proofs generated locally by the sender’s wallet: Range Proofs: The sender must prove that the transfer amount is a positive 64-bit integer, and that subtracting this amount from their current balance will leave a value >= 0. Equality Proofs: The transfer amount is encrypted twice, once under the sender’s public key to deduct it and once under the receiver’s public key to add it. The sender must mathematically prove that both ciphertexts encrypt the exact same underlying value. Token-2022 passes these proofs to Solana’s native ZK Token Proof program. Once the ZK program verifies the math is sound, Token-2022 executes the homomorphic addition and subtraction. 📖 More detailed reference can be found here. Initializing the cryptographic state via CLI To truly understand how this dual-state architecture works, we need to look at it on-chain. Let’s use the Solana CLI to create a confidential token, fund a user’s account, and watch the state transition from public to encrypted. Creating the mint First, we initialize a Token-2022 mint and explicitly tell the program to allocate the ConfidentialTransfer extension. spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-confidential-transfers auto Note: The auto keyword means that any token user can permissionlessly configure their account to perform confidential transfers. Configuring the user’s Token Account Next, we create a standard token account for our wallet. However, a standard token account can only hold a public u64 balance. We must explicitly configure the account to allocate the extra bytes required to hold the ElGamal ciphertexts. # Create the base token account spl-token create-account <YOUR_MINT_ADDRESS> # Allocate the cryptographic extension and generate the ElGamal keypair spl-token configure-confidential-transfer-account <YOUR_MINT_ADDRESS> Under the hood, this second command does something important, it generates a Twisted ElGamal keypair (will be explained shortly) locally on your machine and stores the public key directly on the token account. This is the key the Token-2022 program will use to encrypt your incoming transfers. The public-to-confidential deposit Now that our account is configured for cryptography, let’s give ourselves 100 public tokens. spl-token mint <YOUR_MINT_ADDRESS> 100 lets take a look at the token account state spl-token display <TOKEN_ACCOUNT_ACCRESS> We can see that the public balance is 100 and still not encrypted. To enter the shielded state, we must deposit these public tokens into the encrypted balance. spl-token deposit-confidential-tokens <YOUR_MINT_ADDRESS> 100 and run the display again spl-token display <TOKEN_ACCOUNT_ACCRESS> This is where the magic happens. The Token-2022 program deducts the 100 from your public amount, encrypts the number 100 using your account’s ElGamal public key, and writes the resulting ciphertext to the ConfidentialTransferAccount TLV extension. right now, your public balance will show 0, but your funds are not gone, they are locked inside the cryptographic state, ready to be transferred with Zero-Knowledge proofs. Note: Even though your CLI wallet holds the ElGamal private key locally, the standard spl-token CLI currently lacks a --decrypt flag. Instead of a clean integer, you will be staring at raw, encrypted bytes, the actual Pedersen commitments and ciphertexts living on the BPF runtime. To see the human-readable number 100, you must write a custom client-side script to manually fetch the state and decrypt the ciphertext locally. 📖 Open Github issue: https://github.com/solana-program/token-2022/issues/145 Preventing cryptographic griefing with the split state architecture Encrypting state and using ZK proofs creates a unique new attack vector that doesn’t exist in standard transparent tokens: Cryptographic Front-Running. To submit a valid transfer, Alice must generate her ZK proofs locally on her machine. This proof is mathematically tied to her current encrypted account balance on-chain. Generating this proof takes computational time (often a few seconds on a standard client). Imagine Alice generates a proof based on her encrypted balance of 50 tokens and submits the transaction to the network. However, milliseconds before her transaction lands, a malicious actor (or just a busy protocol) transfers 1 token to Alice. Because of the homomorphic math, that incoming 1 token mutates Alice’s encrypted state on-chain. When Alice’s transaction finally hits the Token-2022 program a fraction of a second later, the ZK proof she generated is instantly rejected because it was built against the old ciphertext. If an attacker continuously flooded Alice’s account with micro-transfers (dusting), they could constantly mutate her state, making it mathematically impossible for her to ever generate a valid ZK proof fast enough to send an outgoing transfer. Her account would be permanently bricked. The solution: splitting the balance To solve this, Token-2022 fundamentally alters the Token Account layout. The ConfidentialTransferAccount TLV extension splits the encrypted balance into two entirely separate ciphertexts: available_balance pending_balance When Alice sends tokens out, the Token-2022 program subtracts the ciphertext strictly from her available_balance. When someone sends tokens to Alice, the program adds the ciphertext strictly to her pending_balance. This strict separation guarantees that nobody but Alice can mutate her available_balance. Because her ZK proofs are generated exclusively against her available_balance, incoming transfers can no longer invalidate her outgoing proofs. The attack vector is completely neutralized. However, this architecture introduces an integration trap. The mechanics of the pending balance The split-state architecture solves the cryptographic front-running problem. Because incoming transfers only hit your pending_balance, your available_balance remains completely static. This ensures that the ZK proofs your client is busy generating locally will never be invalidated by unexpected network traffic. However, this architectural safeguard introduces a necessary friction point in the token lifecycle: Incoming funds are not immediately spendable. If Alice sends you 50 encrypted tokens, the Token-2022 program homomorphically adds the transfer ciphertext to your pending_balance ciphertext. Your available_balance remains untouched. Because outgoing transfers can only deduct from the available_balance, those 50 tokens are effectively parked in a cryptographic waiting room. The state sweep – apply pending balance To actually spend received funds, the account owner must explicitly instruct the Token-2022 program to merge the two ciphertexts. This is done via the ApplyPendingBalance instruction. spl-token apply-pending-balance <MINT_ACCOUNT> When this instruction is fired, it triggers a deterministic state transition on-chain. The Token-2022 processor: Takes the current pending_balance ciphertext. Homomorphically adds it to the available_balance ciphertext. Overwrites the available_balance with the new combined ciphertext. Resets the pending_balance ciphertext to a zero-value encryption. Note: This is done manually because by forcing the account owner to explicitly call ApplyPendingBalance, the protocol guarantees that the available_balance only ever mutates exactly when the user wants it to. You control your own state updates, ensuring your local ZK proof generation environment remains perfectly stable. The transfer trap: failing vs succeeding hands-on Let’s prove that the 100 tokens we just deposited are unspendable in their current state. We will try to send 50 confidential tokens to a friend. Prerequisite: The Receiver Opt-In Handshake If you try to send confidential tokens to a standard public wallet, the transfer will instantly fail because to send an encrypted transfer, your local client must encrypt the transfer amount using the receiver’s ElGamal public key. If Bob hasn’t explicitly opted into the shielded ecosystem, he doesn’t have an ElGamal keypair attached to his account. You cannot force-send privacy tokens, it is a two-way handshake. Before we can route tokens to Bob, he must create an account and configure his cryptography: # Bob creates his token account spl-token create-account <YOUR_MINT_ADDRESS> --owner bob.json # Bob generates his ElGamal keypair and appends it to his account spl-token configure-confidential-transfer-account <YOUR_MINT_ADDRESS> --owner bob.json The fail case Now that Bob is mathematically ready to receive encrypted funds, let’s execute the transfer. We must pass the --confidential flag, otherwise the CLI will attempt a standard public routing. spl-token transfer <MINT_ACCOUNT> 50 <BOB_TOKEN_ACCOUNT> --confidential Output The program fails because it specifically attempts to deduct 50 tokens from your Available Balance, which is mathematically zero. Your 100 tokens are still stuck in the Pending Balance ciphertext. The success case To actually spend these received funds, you must explicitly instruct the Token-2022 program to mathematically merge the two ciphertexts. This is done via the ApplyPendingBalance instruction. Note: If you pass your Token Account address directly to this command, the CLI will hallucinate a fake Associated Token Account and throw an Account not found error. You must either pass the Mint address spl-token apply-pending-balance <MINT_ADDRESS> The Token-2022 takes the current pending_balance ciphertext, homomorphically adds it to the available_balance ciphertext, overwrites the state, and resets the pending balance to zero. Now that the sweep is complete, our 100 tokens have safely moved into our Available Balance. If we run the exact same transfer command again spl-token transfer <MINT_ACCOUNT> 50 <BOB_TOKEN_ACCOUNT> --confidential Output The withdrawal instruction – exiting the shielded state Finally, what happens when a user wants to exit the shielded ecosystem? Perhaps you want to view your raw balance on a standard block explorer, or you need to interact with legacy Solana infrastructure that doesn’t support the ConfidentialTransfer extension. You must transition the state from encrypted back to public using the Withdraw instruction. spl-token withdraw-confidential-tokens <MINT_ADDRESS> 100 Output after running the display command This instruction is the exact inverse of the Deposit we ran in preiously. When you deposit, you are just encrypting a public number. But when you withdraw, you are asking the public network to subtract a specific amount from an encrypted balance. To execute this, your local client must do the heavy lifting: It uses your local ElGamal private key to decrypt your current available_balance. It verifies you actually have >= 100 tokens. It generates a ZK proof mathematically verifying that subtracting 100 from the ciphertext is valid and will not result in a negative number. It sends this proof to the network. The Token-2022 program verifies the proof via the ZK Token Proof program, homomorphically subtracts the ciphertext of 100 from your available_balance, and explicitly adds the raw integer 100 back to your public amount field. Your funds are now public again. Smart contract integration If you are writing a smart contract, say, a payment router or an automated market maker, and it receives a confidential transfer, the contract cannot immediately route those tokens in the next instruction. The funds will be stuck in the contract’s pending_balance. Your program must execute a Cross-Program Invocation to trigger ApplyPendingBalance to merge the ciphertexts before attempting any outgoing transfers. Forgetting this single CPI will cause every incoming transaction to your protocol to hard-fail. Conclusion The Token-2022 Confidential Transfer extension is a masterclass in natively integrating zero-knowledge cryptography into a high-performance runtime. By pushing the encryption directly to the L1 standard: Liquidity Remains Unified: Developers no longer have to bridge assets to isolated Layer-2 ZK-rollups to achieve privacy. State is Protected: The pending vs. available balance split brilliantly neutralizes the cryptographic griefing vectors that plague other privacy networks. Math Replaces Trust: Linear homomorphism ensures the base layer can blindly but flawlessly execute accounting without ever compromising user data. Reliable Solana RPC infrastructure Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers. Deploy Solana Node now → FAQ What is a confidential transfer on Solana? It is a Token-2022 transfer that hides the token amount and confidential balances while keeping the account addresses and mint public. What is the difference between public and confidential balances? Public balances are standard visible token amounts. Confidential balances are encrypted values that can be transferred and validated with zero-knowledge proofs. Does Solana confidential transfer hide wallet addresses? No. The sender, receiver, and token mint remain visible. Only the transferred amount and confidential balances are hidden. Why does Token-2022 use pending balances? Pending balances prevent invalid state transitions and help the protocol handle confidential transfers safely before balances become available. How do tokens move into confidential state? Tokens are first deposited from the public balance into the confidential pending balance, then applied into the confidential available balance. Can confidential balances be withdrawn back to public balances? Yes. The withdraw instruction decrypts and moves tokens from confidential available balance back into the public balance. What cryptography powers Solana confidential transfers? The extension uses Twisted ElGamal encryption and zero-knowledge proofs to validate transfers without revealing token amounts. Learn more about Solana architecture from our articles Solana Token-2022 Metadata Where Token Metadata Lives on Solana SPL Token Program Architecture Architecture & Parallel Transactions Solana Interest-Bearing Tokens: Inside the Mint Extension Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution #### Solana deserialization AccountLoader & repr(C) In the evolution of a Solana developer, there is a distinct turning point: the moment you move from building simple CRUD applications to architecting high-throughput, professional-grade protocols. When you reach this stage, you quickly realize that the “default” ways of handling data. While convenient, are often the primary bottlenecks holding back your program’s performance and scalability. Most developers begin by relying on Borsh serialization. It’s the standard for the Anchor framework, providing a clean, Rust-idiomatic way to manage account state. However, as your state grows from simple counters to complex order books or massive gaming registries, Borsh reveals its physical limits. You start hitting the dreaded Stack offset exceeded errors, your Compute Unit (CU) consumption spikes into the hundreds of thousands, and you find yourself trapped by the runtime’s 10KB CPI limit and 4KB stack constraints. To build serious protocols, you must change how your program “thinks” about memory. This is where Zero-Copy deserialization becomes mandatory. Instead of wasting precious cycles copying bytes from the account buffer into the program’s stack or heap, Zero-Copy allows you to map your data structures directly onto the raw account data. It’s the difference between moving a library’s worth of books every time you want to read one, and simply walking into the library and reading them where they sit. In this deep dive, we are going to look under the hood of the Solana memory model. We’ll explore why Borsh fails at scale, how to implement AccountLoader with repr(C) layouts, and how to architect your programs to handle accounts up to 10MB without breaking the bank on Compute Units. The runtime constraints: why borsh is a liability In a standard execution environment, copying a few kilobytes of data is negligible. But the Solana High-Performance Runtime (Sealevel) isn’t a standard environment. It is a highly constrained eBPF-based VM where every byte moved and every instruction executed has a literal cost in Compute Units (CUs). The stack problem Solana programs have a notoriously small stack: 4KB. When you use standard Borsh deserialization via Account<'info, T>, the program takes the raw account data and attempts to “reconstruct” it into a new instance of your struct on the stack. If your struct is large, say a 2KB state file and you have a few nested function calls, you will hit the Stack offset exceeded error almost immediately. The heap problem Even if you move the data to the heap, you aren’t safe. The heap is limited to 32KB. While this sounds like enough for simple logic, try deserializing an order book with 100 entries. Borsh will attempt to allocate memory for every single element, leading to massive CU consumption and eventual heap exhaustion. The borsh tax Every time you call instruction.accounts.account_name(), you are paying the “Borsh Tax.” This tax is composed of: CPU Cycles: Iterating through the byte buffer. Memory pressure: Creating duplicate copies of data that already exists in the input buffer. CU Waste: For a 10KB account, Borsh a lot of CUs just to make the data “readable” to your Rust code. Zero-Copy effectively reduces this tax to nearly zero. By treating the account’s data buffer as the struct itself, we bypass the stack and heap limits entirely. We aren’t moving the library; we are just pointing to the shelf. Memory layout & repr(C),the predictability of bytes To achieve zero-copy, your program must be able to “overlay” a Rust struct directly onto a raw slice of bytes. However, Rust’s compiler (rustc) is flexible with how it organizes memory. By default, it uses repr(Rust), which allows the compiler to reorder fields to minimize padding or optimize for size. While this is great for standard apps, it’s a disaster for blockchain state. If the compiler reorders fields differently between your program’s versions, or if the layout on-chain doesn’t match your local struct, you’ll read garbage data or crash. The role of #[repr(C)] The #[repr(C)] attribute tells the Rust compiler to use the C ABI (Application Binary Interface) layout. This ensures that the fields are laid out in memory in the exact order you define them in your code. #[repr(C)] pub struct MarketState { pub version: u8, // Offset 0 pub bump: u8, // Offset 1 pub authority: [u8; 32], // Offset 2 } With repr(C), we can guarantee that if we look at the 2nd byte of the account data, it will always be the bump. This predictability is the foundation of zero-copy. Enter bytemuck: Pod and Zeroable To safely cast bytes to a struct, Anchor (under the hood) relies on the bytemuck crate. Two traits are critical here: Pod (Plain Old Data): This signals that the type is “simple”, it has no pointers, no String or Vec, and every bit pattern is valid. This allows us to safely interpret a slice of bytes as this type. Zeroable: This ensures that the type can safely be initialized as all zeros. This is vital when you create a new account and need to ensure the memory is clean. Why No Vec or String? In Zero-Copy, we are mapping a fixed-size window onto a fixed-size account buffer. A Vec in Rust is actually a pointer to a location on the heap, a length, and a capacity. If you tried to use zero-copy with a Vec, you’d just be reading a “dead” pointer that points to some memory address on the machine that originally created the account—not the actual data. Rule of Thumb: If the size isn’t known at compile-time, it cannot be in a zero_copy struct. You must use fixed-size arrays: [u8; 32] instead of Pubkey (if not using the Anchor wrapper), or [Order; 1000] instead of Vec<Order>. Example: use anchor_lang::prelude::*; use bytemuck::{Pod, Zeroable}; use std::mem::{size_of, align_of}; #[repr(C)] #[derive(Default, Debug, Clone, Copy, Pod, Zeroable)] pub struct MarketState { pub version: u8, pub _padding1: [u8; 7], pub volume: u64, pub is_active: u8, // Use u8 instead of bool: 0 = false, 1 = true pub _padding2: [u8; 7], } #[cfg(test)] mod tests { use super::*; #[test] fn test_memory_layout() { let state = MarketState { version: 1, volume: 100, is_active: 1, ..Default::default() }; println!("\n--- Memory Analysis ---"); println!("Total Size: {} bytes", size_of::<MarketState>()); println!("Alignment: {} bytes", align_of::<MarketState>()); println!("-----------------------"); let bytes = bytemuck::bytes_of(&state); println!("Byte Map (Hex):"); for (i, chunk) in bytes.chunks(8).enumerate() { println!("Row {}: {:02X?}", i, chunk); } println!("-----------------------\n"); } } Output: The safety guards: Pod and Zeroable By deriving Pod and Zeroable, we are making a contractual promise to the compiler: Zeroable: “It is safe to fill this account with zeros.” This is crucial because when a new account is created on Solana, it starts as a blank slate of zeros. Pod (Plain Old Data): “This struct is just a bag of bytes.” No pointers, no strings, no hidden metadata. This allows bytemuck to safely “cast” the raw account buffer directly into this struct. The alignment strategy (repr(C)) Without #[repr(C)], the Rust compiler might decide to put is_active right after version to save space. While that sounds efficient, it would break 64-bit alignment for the volume field. By using repr(C), we force the fields to stay in the exact order we wrote them, matching the C standard used by the Solana eBPF VM. This is the part that often confuses developers. Why do we need _padding1 and _padding2? Manual padding: solving the hidden gap _padding1: Because volume is a u64, the CPU requires it to start at an 8-byte boundary. Since version only takes 1 byte, there is a 7-byte “hole” before the next 8-byte boundary. By defining _padding1, we turn that hole into a real field, satisfying the NoUninit requirement. _padding2: A struct’s total size must be a multiple of its alignment (in this case, 8). Our data totals 17 bytes (1+7+8+1). To reach the next multiple of 8 (24 bytes), we add 7 more bytes of padding at the end. Note: In repr(C), the alignment of the entire struct is determined by the largest alignment requirement of any of its individual fields, u64 = 8bytes. Why use u8 instead of bool? You’ll notice we used pub is_active: u8. In Rust, a bool is strictly 1 byte, but it cannot be just any value, it must be 0 or 1. If the account data somehow had a 2 in that spot, the program would crash. Since Pod requires that any bit pattern be valid, we use u8 and treat 0 as false and 1 (or any non-zero) as true. The AccountLoader pattern, direct buffer access In a standard Anchor program, when you use Account<'info, MyData>, the framework performs the deserialization before your instruction logic even starts. With Zero-Copy, we shift that responsibility to the developer. We use AccountLoader, which acts as a lazy, safe wrapper around the account’s data. The Mechanics of load() and load_mut() When you use AccountLoader, the data isn’t mapped until you explicitly ask for it. This is handled through two primary methods: load(): Returns a Ref<T>. This is for read-only access. Because it uses Rust’s internal RefCell mechanics, you can have multiple immutable loads of the same account in the same scope. load_mut(): Returns a RefMut<T>. This is for write access. Crucially, if you try to call load_mut() twice on the same account in the same instruction, your program will panic. This is Solana’s way of enforcing Rust’s “one mutable reference” rule at runtime. Example Notice how we no longer access fields via ctx.accounts.market.field. Instead, we “load” the account into a local variable that acts as a pointer. pub fn process_trade(ctx: Context<Trade>, amount: u64) -> Result<()> { // map the account data to the 'market' variable let mut market = ctx.accounts.market.load_mut()?; // market now behaves like a standard Rust struct market.total_volume += amount; // No need to call 'exit' or 'save'—the changes are // written directly to the account buffer in real-time. Ok(()) } Why Ref<T> and RefMut<T>? Why load() doesn’t just return &T? Under the hood, the account data is owned by the Solana runtime. Anchor uses these “smart pointers” to ensure that: The memory stays locked while you’re using it. You don’t accidentally create data races. The account is correctly marked as “dirty” so the runtime knows to persist the changes back to the ledger when the transaction finishes. The “borrow” pitfall A common senior-level mistake is trying to pass a Ref or RefMut into a helper function while still holding a reference in the main instruction. // AVOID THIS let market = ctx.accounts.market.load_mut()?; calculate_fees(market); // Passing ownership of the RefMut market.volume += 10; // ERROR: market was moved Instead, you should pass a reference to the data inside the loader, or scope your loads carefully. This keeps your Compute Unit usage low because you aren’t re-loading or re-mapping the buffer multiple times. Scaling beyond 10KB, the two-step initialization One of the most frustrating moments for a Solana developer is hitting the 10KB “Wall.” You’ve designed your zero-copy struct, you’ve set the space to 50KB, and you call anchor test, only to see your transaction fail with a cryptic CPI error. The 10KB CPI constraint The issue isn’t Zero-Copy, it’s the init constraint. When you use #[account(init, ...)], Anchor performs a Cross-Program Invocation (CPI) to the System Program to create the account. The Solana runtime restricts the amount of data that can be allocated via CPI to 10,240 bytes. If you want to build a 1MB order book or a 5MB game state, the init constraint is physically incapable of creating it. To scale to the 10MB architectural limit, you must use the Two-Step Initialization pattern. The pattern: external creation + zero constraint Instead of letting the program create the account, you (the client) create it before you call the program. Step 1 (Client-side): Use the System Program to create a “naked” account with the full 1MB of space and transfer its ownership to your program. Step 2 (On-chain): Use the zero constraint in Anchor. This tells Anchor: “This account already exists, it is owned by this program, and it is currently filled with zeros. Do not try to create it, just verify it’s empty and let me initialize it.” On-chain implementation In your instruction context, swap init for zero. Note that zero implies mut because you are about to write the discriminator. use anchor_lang::prelude::*; use bytemuck::{Pod, Zeroable}; declare_id!("Bo8J1of9EuuGw3DvSgTdV7Fug65oD7cERLsf5rzF6PG4"); #[program] pub mod zero_copy_deep_dive { use super::*; // Initialize the account on-chain pub fn initialize(ctx: Context<Initialize>) -> Result<()> { // load_init() sets the 8-byte Anchor discriminator and maps the buffer let mut market = ctx.accounts.market.load_init()?; market.version = 1; market.total_volume = 0; market.is_active = 1; msg!("Market initialized!"); Ok(()) } // Update the data using Zero-Copy pub fn update_volume(ctx: Context<UpdateMarket>, amount: u64) -> Result<()> { // load_mut() maps the existing account buffer for writing let mut market = ctx.accounts.market.load_mut()?; market.total_volume = market.total_volume.checked_add(amount).unwrap(); msg!("Volume updated directly in memory to: {}", market.total_volume); Ok(()) } } #[account(zero_copy)] #[derive(Default, Debug)] pub struct MarketState { pub version: u8, // 1 byte pub _padding1: [u8; 7], // 7 bytes padding for 8-byte alignment pub total_volume: u64, // 8 bytes pub is_active: u8, // 1 byte (using u8 instead of bool for Pod safety) pub _padding2: [u8; 7], // 7 bytes padding to make total size multiple of 8 (24 bytes) } #[derive(Accounts)] pub struct Initialize<'info> { #[account( init, payer = authority, space = 8 + std::mem::size_of::<MarketState>() // 8 (disc) + 24 (data) = 32 bytes )] pub market: AccountLoader<'info, MarketState>, #[account(mut)] pub authority: Signer<'info>, pub system_program: Program<'info, System>, } #[derive(Accounts)] pub struct UpdateMarket<'info> { #[account(mut)] pub market: AccountLoader<'info, MarketState>, pub authority: Signer<'info>, } Client-side implementation (TypeScript) You must bundle the account creation and the program call into the same transaction (or sequential ones) to ensure security. import * as anchor from "@coral-xyz/anchor"; import { Program } from "@coral-xyz/anchor"; import { ZeroCopyDeepDive } from "../target/types/zero_copy_deep_dive"; import { expect } from "chai"; describe("zero_copy_deep_dive", () => { const provider = anchor.AnchorProvider.env(); anchor.setProvider(provider); const program = anchor.workspace.ZeroCopyDeepDive as Program<ZeroCopyDeepDive>; it("Initializes and Updates the volume!", async () => { const marketKeypair = anchor.web3.Keypair.generate(); console.log("Available methods:", Object.keys(program.methods)); // Initialize the account // This creates the account and changes owner from SystemProgram to our Program await program.methods .initialize() .accounts({ market: marketKeypair.publicKey, authority: provider.wallet.publicKey, }) .signers([marketKeypair]) .rpc(); console.log("Account initialized."); // Update the volume // This will now pass because the account is owned by the program const updateAmount = new anchor.BN(500); await program.methods .updateVolume(updateAmount) .accounts({ market: marketKeypair.publicKey, authority: provider.wallet.publicKey, }) .rpc(); // Verify const account = await program.account.marketState.fetch(marketKeypair.publicKey); console.log("On-chain Volume:", account.totalVolume.toString()); expect(account.totalVolume.toNumber()).to.equal(500); expect(account.isActive).to.equal(1); }); }); Output By shifting the allocation to the client-side, you bypass the CPI limit entirely. This architecture allows your program to manage vast amounts of data up to 10MB, while maintaining the same low Compute Unit costs we discussed in previously. You are essentially using the blockchain as a high-speed, direct-mapped disk. Summary Zero-Copy architecture transforms Solana state management from a copy-heavy process into a direct memory-mapping operation. By eliminating the Borsh serialization tax, you achieve $O(1)$ efficiency and massive CU savings, though this requires taking direct responsibility for your data’s physical layout. Ensuring strict 8-byte alignment through manual padding and swapping bool for u8 flags are essential steps to satisfy the hardware and safety constraints of the SBF VM. Ultimately, by mastering the ownership handshake and leveraging AccountLoader, you can architect professional-grade protocols that scale to 10MB without hitting runtime bottlenecks. Architect for the buffer, not the copy. Reliable Solana RPC infrastructure Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required.  Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions.  Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers. Deploy Solana Node now → FAQ What is zero-copy deserialization in Solana and why does it matter? Instead of copying account data into a new struct on the stack or heap, zero-copy maps your struct directly onto the raw account buffer. You read the data where it already lives. The compute cost becomes constant regardless of account size — critical once your state grows past a few kilobytes. When should I use AccountLoader instead of Account? When your struct exceeds ~1–2 KB, or when you need accounts larger than 10 KB (which require the two-step init pattern). For simple counters or small config accounts, Account is fine — the ergonomics outweigh the CU savings at that scale. Why do I need #[repr(C)] on zero-copy structs? Without it, the Rust compiler can reorder your fields for optimization. On-chain, that means a program upgrade could silently change the byte layout, causing reads to return garbage. repr(C) locks field order to exactly what you wrote, matching the C ABI that the Solana eBPF VM expects. Why can’t I use Vec or String in zero-copy structs? A Vec is a heap pointer plus length and capacity — not actual data. When stored in an account buffer and read back later, that pointer points nowhere. Use fixed-size arrays instead: [Order; 1000] not Vec<Order>, [u8; 64] not String. What’s the difference between load(), load_mut(), and load_init()? load() is read-only, callable multiple times in the same scope. load_mut() is write access — calling it twice on the same account panics. load_init() is for new accounts only: it skips the discriminator check, writes it, then returns a muta