# Chainstack > Managed services for blockchain > Contact: admin@chainstack.com ### Posts #### 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 #### 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. https://www.youtube.com/watch?v=Xa_hcVBgiIE 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 #### 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 #### 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 #### 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. https://youtu.be/TwOEeZcMAu4 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 #### 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 😉 #### 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 #### 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. #### 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 #### 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 #### 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.   #### 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. #### 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. #### 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. #### 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. #### 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. #### 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. https://twitter.com/WilsonCusack/status/2024169537625575635 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 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 rules2Alchemy30M 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 support3QuickNodeNo 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 setup4Ankr200M 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 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 uptimeBasic dashboard, regional choice, easy 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 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 & QuickNode both hold SOC 2 Type II certification, reflecting rigorous audits of security, availability, and confidentiality practices Chainstack achieved SOC 2 Type II 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: Not all popular RPC services have completed SOC 2; Alchemy lacks Type 1 or 2 certification as of 2025 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 and WebSocket 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, Gemini, or Windsurf 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. Alchemy Alchemy offers Aptos 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 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 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 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. 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 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 Aptos 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 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. Top 5 Aptos RPC providers 2026 🥇 1. Chainstack Best all-around provider for production Aptos workloads, with a strong focus on reliability, security, and predictable scaling. Designed for teams running latency-sensitive and high-throughput Aptos applications. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Transparent request-based pricing, crypto payments Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. QuickNode Strong focus on low-latency performance via region-routed endpoints, well suited for globally distributed Aptos applications. Highlights: 500+ RPS, 99.99% uptime SLA, 200B+ monthly calls​ SOC 2 Type II + ISO 27001 certified Advanced APIs, Webhooks, NFT/token data Credit-based pricing requires usage monitoring 🥉 3. Alchemy Popular among developers for its tooling layer and analytics, extending beyond basic RPC access. Strengths: 30M CU free tier (~1.2M requests), $0.45/M basic calls 40+ chain support ~99.9% uptime, no SOC 2 certification 🏅 4. GetBlock Entry-level option for testing and smaller workloads. Suitable for early-stage projects, with scaling typically requiring plan upgrades. Advantages: Daily free tier with rollover unused requests Regional endpoint selection for latency optimization Fast setup, simple monthly quotas, dedicated nodes available Great for testing/hackathons; strict RPS limits on shared plans 🏅 5. Ankr Broad multi-chain infrastructure provider focused on flexibility and wide network coverage. Highlights: 40+ supported networks Flat pricing model, unlimited plans available Dedicated and public endpoints Tools for gaming, DeFi, and staking platforms No SOC 2 certification, fewer enterprise features than top picks 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 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. 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 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 or WebSocket 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, Subnets2Alchemy30M 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 support3QuickNodeNo 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 setup4Ankr200M 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 available5Dwellir-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 snapshots 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 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 & QuickNode both hold SOC 2 Type II certification, reflecting rigorous audits of security, availability, and confidentiality practices Chainstack achieved SOC 2 Type II 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: Not all popular RPC services have completed SOC 2; Alchemy lacks Type 1 or 2 certification as of 2025 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, Gemini, or Windsurf 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. 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. 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. Top 5 Avalanche RPC providers 2026 🥇 1. Chainstack Best all-around provider for production Avalanche workloads, with a strong focus on reliability, security, and predictable scaling. Designed for teams running latency-sensitive and high-throughput Avalanche applications. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Avalanche Subnets & on-chain gaming support Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. QuickNode Strong focus on low-latency performance via region-routed endpoints, well suited for globally distributed Avalanche applications. Highlights: 500+ RPS, 99.99% uptime SLA, enterprise-scale volumes​ SOC 2 Type II + ISO 27001 certified Advanced APIs, Webhooks, NFT/token data Credit-based pricing requires usage monitoring 🥉 3. Alchemy Popular among developers for its tooling layer and analytics, extending beyond basic RPC access. Strengths: 30M CU free tier (~1.2M requests), $0.45/M basic calls 40+ chain support ~99.9% uptime, no SOC 2 certification 🏅 4. Ankr Broad multi-chain infrastructure provider focused on flexibility and wide network coverage. Highlights: 40+ supported networks Flat pricing model, unlimited plans available Dedicated and public endpoints Tools for gaming, DeFi, and staking platforms 🏅 5. Dwellir Entry-level option for testing and smaller workloads. Suitable for early-stage projects, with scaling typically requiring plan upgrades. Advantages: Shared and dedicated Avalanche RPC endpoints Isolated dedicated nodes (no pooled bandwidth on dedicated setups) Fast setup, simple monthly quotas, dedicated nodes available 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 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. Reliable Avalanche RPC infrastructure Getting started with Avalanche 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 Avalanche? Deploy your Avalanche node 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 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. #### 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 ExperienceSOC 21Chainstack3M 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 DashboardType II2Alchemy30M 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 supportType II3QuickNodeTrial 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 dashboardsType II + ISO 270014dRPC210M 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 25Ankr200M 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, archiveType I (Type II in progress) 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 & 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. 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, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. 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 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 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, 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. 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. 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 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 not yet confirmed (verify current status); advanced analytics/support gated to paid; performance can vary across distributed nodes; no flat-rate unlimited option. 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. Top 5 Base RPC providers 2026 No single provider is universally optimal for every Base workload. The right choice depends on your method mix, latency sensitivity, compliance requirements, and cost predictability needs. The ranking below reflects production-readiness for stablecoin, DeFi, and AI agents environments specifically — not general developer experimentation or trial usage. 🥇 1. Chainstack — For teams prioritizing predictable request-based billing, Dedicated infrastructure, Flashblocks support, full archive + debug/trace access, MCP support for AI agents, and managed upgrades. The most complete infrastructure for stablecoin platforms, DeFi protocols, and AI agent backends that can't afford surprise billing or unplanned downtime. 🥈 2. Alchemy — Best for DeFi developer tooling. Notify, Transact, and Mempool APIs are purpose-built for event-driven DeFi architecture. Flashblocks quickstart lowers integration friction. SOC 2 Type II covers enterprise compliance needs. 🥉 3. QuickNode — Best for high-throughput OP Stack-aware applications. The most comprehensive Flashblocks and OP-Node API documentation, 99.99% formal SLA, SOC 2 Type II + ISO 27001. Strong choice for trading bots, keeper networks, and Streams-based architectures. 🏅 4. dRPC — Best for cost-optimized high-volume workloads. Flat-rate pricing ($6/1M requests, 20 CU regardless of method) removes cost uncertainty from heavy eth_getLogs and trace workloads. Most generous free tier. Multi-provider routing improves upstream resilience. 🏅 5. Ankr — Best multi-chain entry point for Base. Publicly stated 56ms average response time and 99.99% uptime, 200M free credits, and consistent API surface across 40+ chains. Right for teams adding Base to an existing multi-chain stack. 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, 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. Building on Base? Deploy your Base node 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 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 rules2Alchemy30M 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 support3QuickNodeNo 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 setup4Ankr200M 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 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 uptimeBasic dashboard, regional choice, easy setup6Infura3M credits/day (~depends on method), ~500 credits/sec$50–$225/month for higher limitsMulti-region network, ~99.9% uptimeBNB Chain-first with MetaMask integration, archive, debug/trace on paid tiers 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 certification​ QuickNode leads in performance with maximum RPS and globally distributed infrastructure Alchemy provides the richest developer tooling including Notify and Transact APIs Infura remains reliable for BNB Smart Chain-first projects with deep MetaMask integration GetBlock is ideal for small projects and developers needing simple setup 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 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 & QuickNode both hold SOC 2 Type II certification, reflecting rigorous audits of security, availability, and confidentiality practices Chainstack achieved SOC 2 Type II 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: Not all popular RPC services have completed SOC 2; Alchemy lacks Type 2 certification as of 2026 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, Gemini, or Windsurf 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, 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 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. 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. 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 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. Top 5 BNB Smart Chain RPC providers 2026 🥇 1. Chainstack Best all-around provider excelling across performance, reliability, security, and cost. Supports 70+ networks with BNB Chain-first focus. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Transparent request-based pricing, crypto payments Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. QuickNode Global speed optimization with region-routed endpoints delivering consistently low-latency responses. Highlights: 500+ RPS, 99.99% uptime SLA, 200B+ monthly calls​ SOC 2 Type II + ISO 27001 certified Advanced APIs, Webhooks, NFT/token data Credit-based pricing requires usage monitoring 🥉 3. Alchemy Developer favorite with rich tooling beyond raw RPC. Strengths: Notify, Transact APIs, analytics dashboards 30M CU free tier (~1.2M requests), $0.45/M basic calls 40+ chain support, MEV protection ~99.9% uptime, no SOC 2 certification 🏅 4. GetBlock Entry-level option for developers testing apps or running smaller workloads. Works well for early-stage projects, but may require upgrades as demand grows. Advantages: Daily free tier with rollover unused requests Regional endpoint selection for latency optimization Fast setup, simple monthly quotas, dedicated nodes available Great for testing/hackathons; strict RPS limits on shared plans 🏅 5. Ankr Multi-chain enabler with broad support and flexible infrastructure. Highlights: 40+ supported networks, EVM + non-EVM Flat pricing model, unlimited plans available Dedicated and public endpoints Tools for gaming, DeFi, and staking platforms No SOC 2 certification, fewer enterprise features than top picks 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 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. Start building with 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 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. 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 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. 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. Building on BNB Smart Chain? Deploy your BNB Smart Chain node on Chainstack → #### 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. This guide covers five of the best crypto data APIs for developers in 2026 — CoinStats API, The Graph, 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 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. The Graph The Graph is a decentralized indexing protocol for blockchain data. Instead of querying a centralized API, developers query subgraphs — open, community-built indexes that define exactly what on-chain data to expose and how to structure it. The interface is GraphQL, which means queries are flexible and precise. Rather than fetching entire blocks and filtering client-side, developers request only the fields they need. Major DeFi protocols — Uniswap, Aave, Compound, Curve — already have published subgraphs, so querying their historical state requires no custom indexing work. For products that need custom data structures, The Graph Studio lets developers define and deploy their own subgraphs against any supported chain. Supported networks include Ethereum, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and others. Strengths Flexible GraphQL querying against indexed on-chain data Large library of community subgraphs for major DeFi protocols Decentralized architecture with no single point of failure Free to query existing subgraphs during development Tradeoffs Indexed data, not real-time — slight lag compared to direct RPC calls Custom data requires writing and deploying a subgraph GraphQL learning curve for teams used to REST APIs Best for DeFi apps that need flexible historical on-chain queries, protocol analytics dashboards, and developers who want to query specific smart contract events without building a custom indexer. 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 CoinStatsThe GraphBirdeyeGlassnodeCovalentMarket data✅❌✅LimitedLimitedWallet data✅❌✅❌✅DeFi positions✅✅Limited❌LimitedPortfolio analytics✅❌Limited❌❌Real-time streams✅❌✅❌LimitedOn-chain analyticsLimited✅Limited✅✅Chain coverage120+30+Solana-firstBTC/ETH focus200+MCP support✅❌❌✅❌Best forAll-in-oneDeFi indexingSolana/DEXInstitutionalMulti-chain analytics 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 The Graph if your product queries specific DeFi protocol data and you want flexible, structured access to indexed on-chain history via GraphQL. 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 is the best crypto API for developers in 2026? For most crypto products, CoinStats is one of the strongest all-in-one APIs in 2026 because it combines market data, wallet tracking, DeFi positions, and portfolio analytics in a single integration. Specialized providers like The Graph, Birdeye, Glassnode, and Covalent are better suited for specific use cases such as DeFi indexing, Solana trading data, institutional analytics, or multi-chain pipelines. 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 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 rules2Alchemy30M 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 support3QuickNodeNo 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 setup4Ankr200M 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 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 uptimeBasic dashboard, regional choice, easy setup6Infura3M 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 tiers 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 certification​ QuickNode leads in performance with maximum RPS and globally distributed infrastructure Alchemy provides the richest developer tooling including Notify and Transact APIs Infura remains reliable for Ethereum-first projects with deep MetaMask integration GetBlock is ideal for small projects and developers needing simple setup 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 → 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 & QuickNode both hold SOC 2 Type II certification, reflecting rigorous audits of security, availability, and confidentiality practices Chainstack achieved SOC 2 Type II 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: Not all popular RPC services have completed SOC 2; Alchemy lacks Type 1 or 2 certification as of 2025 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 2, 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. 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. 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. Top 5 Ethereum RPC providers 2026 🥇 1. Chainstack Best all-around provider excelling across performance, reliability, security, and cost. Supports 70+ networks with Ethereum-first focus. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Transparent request-based pricing, crypto payments Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. QuickNode Global speed optimization with region-routed endpoints delivering consistently low-latency responses. Highlights: 500+ RPS, 99.99% uptime SLA, 200B+ monthly calls​ SOC 2 Type II + ISO 27001 certified Advanced APIs, Webhooks, NFT/token data Credit-based pricing requires usage monitoring 🥉 3. Alchemy Developer favorite with rich tooling beyond raw RPC. Strengths: Notify, Transact APIs, analytics dashboards 30M CU free tier (~1.2M requests), $0.45/M basic calls 40+ chain support, MEV protection ~99.9% uptime, no SOC 2 certification 🏅 4. GetBlock Entry-level option for developers testing apps or running smaller workloads. Works well for early-stage projects, but may require upgrades as demand grows. Advantages: Daily free tier with rollover unused requests Regional endpoint selection for latency optimization Fast setup, simple monthly quotas, dedicated nodes available Great for testing/hackathons; strict RPS limits on shared plans 🏅 5. Ankr Multi-chain enabler with broad support and flexible infrastructure. Highlights: 40+ supported networks, EVM + non-EVM Flat pricing model, unlimited plans available Dedicated and public endpoints Tools for gaming, DeFi, and staking platforms No SOC 2 certification, fewer enterprise features than top picks 🏅 6. Infura Ethereum veteran with deep MetaMask integration. Key features: ~100k daily free requests, credit-based system Multi-region Ethereum API + IPFS support Enterprise SLAs via ConsenSys Proven stability for wallet/dApp integrations Availability of key features across different RPC providers 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 compliance. It perfectly serves stablecoin payments, and enterprise dApps include 70+ chain support.​ 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). Infura remains Ethereum's trusted veteran with MetaMask integration. GetBlock suits budget-conscious devs with simple regional endpoints.​ Developers now have mission-critical infrastructure options that deliver unprecedented reliability and performance.​ 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 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.​ 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. Start building with Chainstack → #### 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 WebSockets2QuicknodeNo free tier; 10M credits trial only50–500 RPS; credit-based monthly plansLow latency, global routing with 99.99% uptime on paid plansStreams, Webhooks, analytics dashboard3Alchemy300M 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 dashboards4dRPCAvailable, ~40–250 RPSUp to 5,000 RPS; flat $6 per 1 M requestsLatency-aware routing, uptime on paid plansAnalytics dashboard, unlimited API keys5HypeRPC10k requests/mo, 5 RPS50–300 RPS; tiered monthly plans, custom on requestLow, region-based, 99.99% uptimeReal-time metrics, trader-focused console6DwellirN/AUp to 2,000 RPS on plans; custom on enterpriseIsolated on dedicated; rate-limited on shared; public status page availableHyperEVM JSON-RPC/WebSockets + Hyperliquid L1 gRPC 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 placeOrder — Submit orders cancelOrder — 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) 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.9% 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.9%+ 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, making it the strongest choice for anyone building on Hyperliquid. 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. 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. 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. 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? With HypeRPC you get plans that are focused on performance over high quotas and sit at the premium end of the market: 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 does not offer a recurring free tier, its 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? With Dwellir, there’s no free monthly tier, though you can start on shared 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 availableNo free or test tierUsage/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 there’s no free monthly tier, and RPS limits at the lower plan tiers are lower than what some competitors offer at the same price point. 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. For more details, you can check our How to get a Hyperliquid RPC endpoint guide Deploy a Hyperliquid node Choosing the right Hyperliquid RPC provider 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. 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 Start building with Chainstack → 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 Dashboard2Alchemy30M 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 support3QuickNodeTrial 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 dashboards4dRPC210M 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 protection5Dwellir100K 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 monitoring 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, Gemini, or Windsurf 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 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, 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. 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. 3. 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; 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. 4. 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. 5. 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. 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. 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. Start building with Chainstack → 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 Monad RPC providers for 2025 🆕 This guide covers 2025 providers. For the most up-to-date comparison, see Best Monad RPC Providers 2026 → Explore the best Monad RPC providers in 2025 and see which one delivers the speed, consistency, and throughput your app needs—whether you're running trading bots, indexing the chain, or powering real-time on-chain systems. Monad is attracting builders for one simple reason: it’s fast—and not just “L1 fast.” Its parallel execution engine and JIT-optimized EVM give developers a chain where contracts execute quickly, state updates feel immediate, and block production stays steady even under pressure. This creates the perfect environment for latency-sensitive systems like arbitrage bots, automated strategies, and high-frequency analytics. Most teams start with the public Monad RPC, and it’s perfectly fine for early testing. But public endpoints aren’t built for sustained load. They cap throughput, spike under traffic, and return stale state more often than you'd think. Once your code needs predictable timing—milliseconds matter, not seconds—you’ll want a private RPC provider that keeps up with Monad’s execution model. To help you choose the right one, we benchmarked the top Monad RPC providers and compared how they differ in speed, throughput, reliability, rate limits, and overall developer experience. Whether you're optimizing a trading system or scaling a production dApp, this guide shows exactly what to expect from each provider. Comparison matrix of Monad RPC providers ProviderFree planPaid pricingLatency & UptimeDeveloper ExperienceChainstackFree Developer plan: 3M requests/month, ~25 RPSGrowth ($49/mo, 20M req, ~250 RPS), Pro ($199/mo, 80M req ~400 RPS, Business ($499/mo, 200M req, ~600 RPS), Unlimited Nodes (flat monthly fee for unmetered requests), Dedicated Nodes ($0.50/hr + storage)Sub-100ms global routing in most regions, consistent low latency under load, 99.99%+ uptime on paid plans, multi-cloud redundancyPolished console and docs, archive data, WebSockets, debug/trace APIs, team access controls, SOC2-grade security, unified metrics dashboard, easy migration from other EVM providersQuickNodeNo permanent free tier; 10M-credit trial at ~15 RPSStarter $10/mo (25M req, ~40 RPS), Growth $39/mo (~75M req, ~125 RPS), Business $199/mo (300M req, ~400 RPS), overages billed per million requestsGlobal routing with typically 100–200ms latency worldwide, high-tier plans sustain up to ~400 RPS, 99.9% uptime on paid plans, multi-region failoverUser-friendly dashboard with analytics, Streams Webhooks, multi-chain tooling, Functions for serverless tasks; API keys capped on standard plans; credit usage requires monitoringdRPCFree usage with dynamic throughput (~40–250 RPS depending on traffic)Premium: ~$6 per 1M requests, supports up to ~5000 RPS burst, no subscription requiredIntelligent routing across distributed clusters, often <100ms regionally, handles high volume without central bottlenecks, strong uptime through decentralized redundancy (no formal SLA)Simple endpoint-based API, unlimited API keys, supports many chains, analytics dashboard, debug/trace availability, MEV protection features; platform still evolving with newer toolingAlchemyFree tier: 300M compute units/month (~100–250M simple calls), ~300 RPS soft capPay-as-you-go for CU overages, Growth tier for additional CU blocks, Scale tier for 1.5B+ CU/month, enterprise options for large workloadsLow-latency multi-region network, typically <100ms local-region responses, global failover, strong real-world reliability with ~99.9% uptimeRich developer experience: analytics dashboards, request inspector, Notify APIs, transaction simulation, enhanced APIs; supports fewer chains than competitors but strong EVM supportAnkrFreemium public RPC (~30 RPS) with no monthly feePremium pay-as-you-go ($10 per 100M credits), up to ~1,500 RPS on private endpoints; enterprise tiers availableGlobal DePIN network with 30+ regions, good regional latency on private RPC, public RPC may vary under load; generally strong real-world uptime with formal SLAs on paid tiersBroad multi-chain coverage, Advanced APIs for pre-indexed data, WebSockets and debug/trace on Premium, usage-credit system requires monitoring; console is simple but less feature-rich than others This table sets up the analytical framework used in the deep-dive sections below. 1. Chainstack Chainstack is a multi-chain infrastructure platform and one of the first providers to bring full Monad RPC support to production. With Chainstack Monad endpoints, you get private access to the network over HTTP and WebSocket with a guaranteed high uptime SLA and infrastructure tuned for high-throughput EVM workloads. On top of raw RPC, Chainstack gives you a set of tools that makes building on Monad easier from the same platform, including: Testnet support and one-click node deployment for both mainnet and testnet. Archive mode for historical reads, plus WebSockets for live contract events and real-time app state. High-performance archive nodes for heavy analytics and indexing workloads. Clear method reference for Monad JSON-RPC, example code, and ready-to-clone boilerplates for bots, dashboards, and dApps. Access rules to enforce limits per key, IP, or origin directly from the dashboard so you can protect endpoints without extra middleware. Backed by a globally distributed, multi-cloud network, Chainstack delivers predictable performance for teams moving from local testing to production. Provisioning a Monad endpoint takes just a few minutes in the console. How much does Chainstack cost? Chainstack offers cost-effective plans so infra costs are easy to plan and forecast: 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.50 per extra million. Business — $499/month, 200M requests (~600 RPS), $10 per extra million. Unlimited Node Add-on — flat monthly fee for unmetered requests starting from $149, priced by RPS tier. Dedicated — $0.50/hour + storage for exclusive ultra-high performance Monad nodes. This gives you a rare combination: start free, then move into predictable tiers or unlimited usage as traffic grows. Performance on Monad with Chainstack Chainstack’s stack is engineered to give you an edge on Monad: Global routing: Traffic is served through Chainstack’s distributed multi-cloud network. Requests are routed to the nearest available infrastructure point for consistent latency. Uptime guarantee: 99.99%+ uptime on Monad nodes, with self-healing infrastructure behind the scenes. Throughput: Low latency on standard EVM calls; upper tiers comfortably support ~400–600 RPS for sustained heavy use. Monitoring: Built-in metrics and comparisons so you can validate endpoint latency, error rates, and load patterns over time. Pros & cons of Chainstack ProsConsOne provider for Monad plus 70+ other chainsFree plan (3M calls, 25 RPS) may be too small for serious bots or indexersPredictable pricing with flat monthly plans, high included quotas, and an unlimited optionFixed RPS caps per plan; very latency-sensitive apps will likely want Unlimited or Dedicated99.99%+ uptime, SOC 2–grade security posture, globally distributed nodesDedicated nodes require moving beyond the entry-level planSupports both global nodes and dedicated nodes; can handle heavy load (hundreds of RPS) with an unlimited add-on for nonstop throughputClear docs, unified dashboard, access rules, and monitoring in the same console For Monad, Chainstack gives you everything you need: private RPC endpoints, archive and WebSockets, security controls, and monitoring under one roof. Pricing is clear, regions are well covered, and the free tier makes it easy to try before you commit—making Chainstack a leading choice for serious builders on Monad. Deploy Monad node Now 2. Quicknode QuickNode recently added Monad to its lineup of supported networks. The platform runs on a globally distributed, auto-scaling network of RPC nodes, routing traffic to the closest region to keep latency low. Monad support covers standard JSON-RPC methods, with private endpoints over HTTP and WebSocket. Instead of bundling chain-specific extras, QuickNode keeps its Monad offer focused on reliable RPC delivery. The additional tooling available—Streams, Webhooks, analytics, and logs—works across its multi-chain stack, so you can integrate Monad into the same observability and data flows you use for other networks. 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: Free Trial (1 month) — $0/month, 10M credits, ~15 RPC 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 Monad with QuickNode QuickNode focuses on speed and uptime for all chains it supports, including Monad. Request-per-second limits are enforced per plan, so scaling heavy workloads usually means upgrading or distributing load across endpoints. Uptime: 99.99% uptime on paid plans, with SLA-backed billing. Latency: Low response times through global routing and regional caching. Throughput: Per-endpoint caps (50–500 RPS) mean high-frequency workloads will need higher tiers or multiple endpoints. Scale: Network processes hundreds of billions of requests monthly across supported chains. Monad-specific tooling: The stack is generic RPC; there’s no Monad-specific faucet or specialized dashboards yet. Pros & cons of Quicknode ProsConsGlobal low-latency network with auto-routing to the nearest regionCredit-based pricing is more complex; some RPC methods consume more credits than others99.99% uptime on paid plans with 24/7 supportNo permanent free tier; after the trial, you must move to a paid planHandles traffic spikes with auto-scaling, up to ~400–500 RPS per endpoint on higher tiersRPS limits per plan can throttle high-frequency bots unless you upgrade or spread across endpoints QuickNode delivers fast, globally routed Monad RPC with a production-ready SLA, backed by a mature platform and solid tooling. It’s a good choice if you want strong multi-chain integrations and don’t mind credit accounting. For chain-specific extras or very fine-grained latency control, other providers can complement it. 3. Alchemy Alchemy recently rolled out Monad support via EVM-compatible RPC endpoints, making it straightforward for teams already using its Ethereum tooling to plug in. You can continue using the same libraries—ethers.js, web3.py—and the overall workflow feels familiar. Alchemy carries over much of what it’s known for: APIs like Transact and Notify, granular analytics dashboards, and debugging utilities such as transaction simulation. On Monad, this means full RPC access to chain data with the option to build on top of their higher-level tooling for monitoring, alerting, and app-level logic. How much does Alchemy cost? One thing to note is that Alchemy measures usage in Compute Units (CUs) rather than raw requests. For Monad 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: Free - $0, 30M CUs per month, ~25 RPS Pay-as-you-go — $5 per 11M CUs (~$0.45/M), ~300 RPS Enterprise — custom pricing, with lower per-unit costs at very high volumes Performance on Monad with Alchemy Alchemy runs a hardened global setup that’s proven on other EVM networks and extends that footprint to Monad: Uptime: ~99.9% historical uptime, with SLAs on paid tiers. Latency: Regional routing for consistent response times; caching and “supernode” architecture keep hot paths fast. Throughput: Free tier handles moderate loads, with higher RPS and CU ceilings on paid plans. Architecture: Multi-layer caching, load balancing, and internal redundancy to sustain parallel requests. Pros & cons of Alchemy ProsConsGenerous free tier with 300M monthly CUs and good throughputThe CU system can be confusing, especially for workloads consisting mostly of very simple callsCompetitive per-unit price once you scale beyond freePricing and limits are CU-based, making it harder to reason in “requests per month” termsExcellent developer experience: dashboards, Notify/Transact APIs, debugging toolsMonad-specific extras (like dedicated dashboards or order-flow views) are limited; tooling is more general EVM-focusedSmooth scaling from small projects to enterprise workloadsRegional placement and routing are abstracted; less granular control over where nodes live Alchemy doesn’t offer Monad-specific “extras,” but if your team already lives in the Alchemy ecosystem or values debugging and analytics tooling as much as raw RPC, it’s one of the easiest ways to go live on Monad. 4. dRPC dRPC is a newer provider built around a decentralized routing model and was early to support Monad. Instead of relying on a single backend, dRPC forwards traffic through a network of independent node operators, with a smart balancer deciding which node handles each request. The goal is to combine redundancy, high throughput, and low latency without forcing you to manage your own node fleet. For Monad, dRPC exposes standard JSON-RPC, archive access (depending on upstream nodes), and WebSocket endpoints where available. How much does dRPC cost? dRPC pricing is pretty simple, as you just pay for what you use. Free plan — $0/month, free 210M CU per month. Growth plan — $6 per 1M requests, flat rate across all chains and methods. Personalized pricing — From 300 million requests per month. 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 Monad with dRPC dRPC runs seven regional clusters and uses latency-aware routing to send each request to the most suitable node. In practice, that yields: Throughput: Up to ~5,000 RPS per endpoint on the premium plan. Latency: Requests are routed to the fastest available node; performance degrades gracefully during spikes. Uptime: Strong real-world uptime due to diversity of backends, though SLAs are still evolving. Scalability: No fixed plan quotas on premium; unlimited API keys allow you to segment traffic however you like. Redundancy: If one upstream node falls behind or stalls, others take over automatically. Pros & cons of dRPC ProsConsFlat $6-per-million pricing makes billing predictablePlatform is still young; long-term reliability data is limitedHandles heavy loads (up to ~5K RPS) without static ceilingsFewer “platform” features like webhooks, indexing services, or chain-specific toolingDecentralized routing provides built-in failover and resilienceSLAs and enterprise-grade guarantees are not as formalized as some incumbentsUnlimited API keys and straightforward endpoint modelDocumentation for Monad-specific patterns may be thinner than for older chains For Monad, dRPC is a flexible option if you care about throughput and failover more than platform bells and whistles, and are comfortable adopting a newer provider. 5. Ankr Ankr is a long-running Web3 infrastructure provider that offers RPC access via a distributed network of nodes across many regions and chains. For Monad, Ankr exposes both public and private RPC endpoints, giving you a simple path from experimentation to production. Public endpoints are aimed at quick integration and light traffic, while private endpoints provide higher RPS, WebSockets, and better reliability. Because Ankr is multi-chain by design, it’s convenient if your stack touches several networks alongside Monad. How much does Ankr cost? Freemium — free account tier with a small credit pool; still rate-limited similar to Public. Premium — from $10 per 100M credits, up to 1,500 RPS on private endpoints. Enterprise — custom pricing for higher RPS, regional routing, and SLAs. Performance on Monad with Ankr Ankr’s footprint includes many regions, and Monad traffic benefits from that distribution: Latency: Good regional latency on private endpoints; public endpoints are more variable. Throughput: Paid plans support high sustained RPS; public endpoints are tuned for low to moderate loads. Reliability: Mature network, with strong real-world uptime; SLAs available on enterprise. Multi-chain: You can run your Monad and other chain endpoints from the same console. Pros & cons of Ankr ProsConsVery cost-effective for moderate Monad workloadsPublic endpoints are not suitable for production; you’ll need Premium for serious useSimple on-ramp from free testing to pay-as-you-goCredit model means costs can ramp up quickly for heavy analytics or indexingBroad multi-chain coverage; good if your stack spans many networksPlatform UX and metrics are less polished than some DX-focused providersGood geographic spread and performance on private endpointsPricing varies per method type; optimizing costs may require tuning call patterns If you want a flexible, budget-friendly way to get Monad into an existing multi-chain stack, Ankr is a strong candidate. Public RPC is great for quick tests, and Premium private endpoints give you the performance you need once your app moves into production. Deployment guide Create a Chainstack account Deploy a Monad node (mainnet or testnet) Choose global, dedicated or unlimited configuration Copy RPC & WSS URLs Use in ethers.js / web3.py Monitor usage via dashboard Deployment takes under a minute - no infra overhead. Create Monad 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, Plasma, Hyperliquid, Scroll, Aptos, Fantom, Cronos, Gnosis Chain, Klaytn, Moonbeam, Celo, Aurora, Oasis Sapphire, Polygon zkEVM, 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.  Are you in need of testnet tokens? Request some from our faucets. Sepolia faucet, Hoodi faucet, BNB faucet, zkSync faucet, Scroll faucet, Hyperliquid faucet. Have you already explored what you can achieve with Chainstack? Get started for free today. FAQ What is a Monad RPC provider? A Monad RPC provider lets your application interact with the Monad network without running your own node. It handles requests like sending transactions, reading contract state, fetching block data, subscribing to events, and accessing historical information over standard interfaces such as HTTP, WebSocket, or gRPC. A reliable RPC layer ensures your app stays in sync with the chain’s fast execution environment. Why does Monad need specialized RPC infrastructure? Monad is designed for parallel execution and high throughput. Generic or underpowered RPC setups often can’t keep pace with rapid block production and heavy state-access patterns. The network benefits from optimized routing, low-latency infrastructure, and high RPS capacity — otherwise, apps experience stale reads, missed event updates, or inconsistent performance during traffic spikes. A production-grade RPC provider fills this gap. How do I choose the best Monad RPC provider? Focus on measurable performance: latency stability, uptime guarantees, and throughput under load. Developer tooling and pricing transparency matter as well, especially if you’re building bots, analytics systems, or real-time applications. Chainstack simplifies this with predictable plans, dedicated and unlimited nodes, global routing, and detailed metrics to help you evaluate performance. Can I use Monad RPC for free? Yes. Several providers, including Chainstack, offer a free tier suitable for testing and small workloads. Once you move into production, private RPC endpoints provide higher RPS ceilings, better latency stability, SLAs, and features like archive access and WebSockets optimized for real-time usage. Does Chainstack support real-time data streaming on Monad? Yes. Chainstack supports WebSockets for real-time event streaming, block subscriptions, and contract updates. These capabilities help builders run trading bots, monitoring systems, and dashboards that require immediate reaction to on-chain changes. #### 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, recently moving past the 10M transactions-per-day range, 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. .chart-wrapper { position: relative; width: 100%; height: 800px; overflow: hidden; } .chart-wrapper iframe { width: 100%; height: 100%; border: 0; } 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 five 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 five 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 IIAlchemyCompute-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 IIQuickNodeCredit-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 27001AnkrAPI-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 found 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-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 dedicated Polygon infrastructure 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 Best for: High-throughput apps, bots, payment systems, and teams that expect to graduate into dedicated Polygon infrastructure. 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 compliance. 🤖 You can also access Chainstack Polygon RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf 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, 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 Alchemy Best for: Teams already using Alchemy across EVM networks and wanting Polygon support inside the same platform. Pricing & throughput: Free tier includes 30M CUs/month. Paid tiers start with PAYG at around $1.50/1M CUs. 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 Best for: Bots, DeFi backends, analytics pipelines, and enterprise teams that want a deep Polygon method surface with dedicated options. 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 Ankr Best for: Cost-sensitive production applications, payments, and teams that want a broad Polygon feature set without immediately committing to enterprise infrastructure. 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 Best for: Cost-sensitive multi-chain apps, dashboards, and teams that want a simple Polygon endpoint inside a broader routing layer. 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, which is the highest shared RPS ceiling in this set. 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 five 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. 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. Top 5 Polygon RPC providers 2026 — overall ranking Top 5 Polygon RPC providers 2026 body { margin: 0; padding: 2rem; font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif; background: #fff; color: #111; } .chart-title { font-size: 20px; font-weight: 600; margin: 0 0 4px; color: #111; } .chart-sub { font-size: 13px; color: #666; margin: 0 0 1.5rem; } .chart-wrap { position: relative; width: 100%; height: 280px; } .chart-footer { font-size: 12px; color: #999; margin-top: 1rem; } Chainstack leads with 95/100, 10 points ahead of runner-up Ranking based on five production-readiness criteria: pricing transparency, dedicated infrastructure availability, archive/debug/trace depth, security and SLA posture, and fit for high-throughput Polygon workloads. const labels = ['Chainstack', 'QuickNode', 'Alchemy', 'Ankr', 'dRPC']; const scores = [95, 85, 82, 76, 72]; const colors = ['#E8A800', '#2DB8B0', '#B07040', '#2A7AB8', '#4A7A6A']; new Chart(document.getElementById('polygonChart'), { type: 'bar', data: { labels, datasets: [{ data: scores, backgroundColor: colors, borderRadius: 4, borderSkipped: false, barThickness: 28 }] }, options: { indexAxis: 'y', responsive: true, maintainAspectRatio: false, plugins: { legend: { display: false }, tooltip: { enabled: false } }, layout: { padding: { right: 48 } }, scales: { x: { min: 0, max: 100, grid: { color: 'rgba(0,0,0,0.07)' }, ticks: { color: 'rgba(0,0,0,0.5)', font: { size: 12 }, stepSize: 20 }, border: { display: false }, title: { display: true, text: 'Overall score', color: 'rgba(0,0,0,0.5)', font: { size: 12 } } }, y: { grid: { display: false }, ticks: { color: 'rgba(0,0,0,0.75)', font: { size: 13 } }, border: { display: false } } }, animation: { onComplete(ctx) { const chart = ctx.chart; const meta = chart.getDatasetMeta(0); const c = chart.ctx; c.save(); c.font = '600 13px -apple-system, BlinkMacSystemFont, sans-serif'; c.fillStyle = 'rgba(0,0,0,0.65)'; c.textAlign = 'left'; c.textBaseline = 'middle'; meta.data.forEach((bar, i) => { c.fillText(scores[i], bar.x + 6, bar.y); }); c.restore(); } } } }); No single provider is universally optimal for every Polygon workload. The right choice depends on your method mix, latency sensitivity, compliance requirements, and cost predictability needs. The ranking below reflects production-readiness for stablecoin, high-throughput bot, and enterprise environments specifically, not general developer experimentation or trial usage. 1. Chainstack — 95/100 For teams prioritizing predictable request-based billing, dedicated Polygon infrastructure, full archive and debug/trace access, and SOC 2 Type II-backed uptime. The most complete infrastructure for payment platforms, trading bots, and analytics pipelines that cannot afford surprise billing or unplanned downtime. 2. QuickNode — 85/100 Best for high-throughput and enterprise-grade Polygon workloads. The most comprehensive Polygon method documentation in this set, Flat Rate RPS for predictable throughput, and the strongest public compliance posture (SOC 1/2 Type 2, ISO 27001). Strong choice for DeFi backends, keeper networks, and analytics pipelines. 3. Alchemy — 82/100 Best for teams already standardized on the Alchemy platform. Debug and Trace APIs, full archive access, webhooks, and a familiar SDK environment make it a strong fit for product teams where Alchemy is already the stack. SOC 2 Type II covers enterprise compliance needs. 4. Ankr — 76/100 Best multi-chain entry point with solid Polygon coverage. Publicly stated 99.99% uptime, 200M free credits, Premium private endpoints, and a clear service-tier separation. Right for cost-sensitive payment apps and teams adding Polygon to an existing multi-chain stack. 5. dRPC — 72/100 Best for cost-optimized standard Polygon workloads. Flat-rate request pricing removes cost uncertainty from high-volume standard calls. Most generous free public access. Multi-provider routing improves upstream resilience. Weaker for dedicated infrastructure, heavy archive/trace, or regulated environments. 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, 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. Building on Polygon? Deploy your Polygon node 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 support2Helius1M 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 SDKs3Alchemy30M 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 SDKs4QuickNodeNo 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 access5dRPC~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 routing6Ankr200M 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 tiersHTTPS and WebSocket access, allowlists, multi chain setup with archive queries Key takeaways from the comparison: Chainstack offers the best balance of features, transparent pricing, 99.99%+ uptime, and full SOC 2 Type II compliance. QuickNode leads on raw performance and global RPS scaling for production apps. Helius provides Solana-native APIs for NFTs, metadata, and real-time tracking. Alchemy delivers strong tooling, but lacks SOC 2 certification. Ankr is simple to start with, but lacks advanced enterprise features. dRPC focuses on low-latency and free access, with limited observability. 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 2, 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. 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. 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. 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. Ankr Ankr runs Solana on a decentralized network of independent node operators, routing requests through Anycast to the nearest healthy endpoint. You get quick access to Solana RPC without managing your own servers, plus reach across multiple regions by default. Performance is generally fast enough for most dApps because traffic is sent to a geographically close node, and paid tiers can burst into high RPS ranges, but behavior can vary because you’re effectively talking to different operators over time. WebSocket access, higher throughput, and SLA-style guarantees sit behind paid plans, while the free tier is HTTP only. So Ankr tends to fit teams that want inexpensive access to Solana (and a bunch of other chains) with minimal ceremony, and are comfortable trading some consistency for reach and price. How much does it cost?Freemium — $0/month. Includes a monthly free quota, ~30 requests/sec on the standard Node API, ~30 requests/min on the Advanced API.Pay-as-you-go — Starts at $10 per 100M API credits (≈500K requests). Up to 1,500 requests/sec on the Node API and 1,000 requests/min on the Advanced API.Deal — Monthly subscription starting around $500 for 6B API credits (≈30M requests).Enterprise — Custom termsPerformanceAvailability: Global routing that shifts traffic automatically when one operator slows down.Latency: Usually under 200 ms when the route is clear, though times vary by operator.Scalability: Up to ~1,500 RPS on paid tiers with higher concurrency at the top end.Stability: Handles Solana surges well thanks to distributed routing, though regional results differ slightly.Controls: Paid plans include HTTPS / WSS, allowlists, usage stats, and support; the free tier stays minimal for testing.Pros- Freemium with 200M credits/month- Supports HTTP, WebSocket, and archive queries- Multi-chain supportCons- Advanced visibility/support gated to paid- No fixed monthly plan- 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. 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. Top 5 Solana RPC providers 2026 🥇 1. Chainstack Best all-around provider excelling across performance, reliability, security, and cost. Supports 70+ networks with Solana-first focus. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Transparent request-based pricing, crypto payments Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. Helius Solana-specialized speed & data leader. Advantages: Staked validator routing (~140 ms latency) Native APIs for NFT/token data, webhooks, Geyser streaming Solana-only focus (no multi-chain) Credit-based pricing, no public 99.99% SLA on basic tierswith rollover unused requests 🥉 3. Alchemy Developer favorite with rich tooling beyond raw RPC. Strengths: Global routing, ~170 ms response times, 99.99% uptime targets Notify/Transact APIs, analytics dashboards 30M CU free tier (~1.2M requests), $0.45/M basic calls No SOC 2 certification 🏅 4. QuickNode Performance leader with globally distributed network. Highlights: Multi-region load balancing, 99.99% uptime on paid plans Streams API, MEV protection, transaction relays Trial credits (~10M calls), credit-based pricing RPS caps (~50-500 RPS per tier) 🏅 5. dRPC Decentralized high-throughput RPC aggregator. Key features: AI-driven routing across 50+ node operators ~100-250 RPS free, up to 5,000 RPS pay-as-you-go $6 per 1M requests, unlimited API keys, MEV-safe Variable performance across operator 🏅 6. Ankr Accessible multi-chain network with a generous free tier. Highlights: Anycast routing to nearest nodes (~30 RPS free) ~200M credits/month free, bursts to 1,500 RPS WebSocket, allowlisting, 99.99% enterprise SLA Performance varies by community operators Ranking chart of the top 6 Solana RPC providers based on overall performance, reliability, security, and cost Conclusion The 2026 Solana RPC landscape has matured into a competitive space with infrastructure options tailored to production-scale demands. Chainstack offers the most balanced solution overall, combining global and dedicated nodes, gRPC Geyser support, and 99.99% uptime — making it a strong fit for stablecoin payments, analytics, and enterprise deployments.​ QuickNode leads in low-latency performance and traffic routing, with built-in access rules for tighter security controls. Helius focuses on Solana-native tooling, offering advanced APIs and enhanced Geyser indexing ideal for high-throughput data needs. Alchemy provides a developer-friendly platform with stable performance and a generous free tier, while Ankr and dRPC offer reliable regional coverage for teams looking to scale affordably.​ With these providers, Solana developers have access to high-availability infrastructure built to support mission-critical applications across diverse use cases.​ 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 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. Ankr and Alchemy also offer limited free plans, but with tighter usage caps or fewer production-ready features.​ 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. 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 via Access rules and gRPC streaming support for real-time Solana data — everything needed to launch production-ready apps from day one. Reliable Solana RPC infrastructure Getting started with Solana 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. Start building with Chainstack → #### 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 5 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 rules2Alchemy30M 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 support3QuickNodeNo 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 setup4Conduit400M CUs/month, 1 API keyPro: $50/month, 1B CUs, 10 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 support5dRPC~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 routing 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 certification​ QuickNode leads in performance with maximum RPS and globally distributed infrastructure Alchemy provides the richest developer tooling including monitoring APIs dRPC is ideal for small projects and developers needing simple setup 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 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 & QuickNode both hold SOC 2 Type II certification, reflecting rigorous audits of security, availability, and confidentiality practices Chainstack achieved SOC 2 Type II 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 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, Gemini, or Windsurf 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. 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- No SOC 2 certification Type 2 as of 2026 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. 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 — 400M CUs/month, 1 API key- Pro — $50/month, 1B CUs/month, 10 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. Top 5 Tempo RPC providers 🥇 1. Chainstack Best all-around provider for production Tempo workloads, with a strong focus on reliability, security, and predictable scaling. Designed for teams running latency-sensitive and high-throughput Tempo applications. Key strengths: Custom RPS on enterprise plans (400M+ requests/month), 99.99% uptime​ SOC 2 Type II certified with 99.99%+ SLA Predictable request-based pricing with Unlimited Node add-on for flat-rate billing Global Nodes for low-latency dApps. Dedicated Nodes for isolated workloads and enterprise-grade reliability. 🥈 2. QuickNode Strong focus on low-latency performance via region-routed endpoints, well suited for globally distributed Tempo applications. Highlights: 500+ RPS, 99.99% uptime SLA, enterprise-scale volumes​ SOC 2 Type II + ISO 27001 certified Advanced APIs, Webhooks, NFT/token data Credit-based pricing requires usage monitoring 🥉 3. Alchemy Popular among developers for its tooling layer and analytics, extending beyond basic RPC access. Strengths: 30M CU free tier (~1.2M requests), $0.45/M basic calls 40+ chain support ~99.9% uptime, no SOC 2 certification Early Tempo ecosystem participant (Day 1 support) 🏅 4. Conduit Simple, developer-friendly RPC access for Tempo development. Highlights: Free tier for testnet development Quick setup through Conduit app Tempo RPC Quickstart guide Ideal for early-stage testing and prototyping 🏅 5. dRPC Decentralized high-throughput RPC aggregator. Key features: AI-driven routing across 50+ node operators ~100-250 RPS free, up to 5,000 RPS pay-as-you-go $6 per 1M requests, unlimited API keys, MEV-safe Variable performance across operator 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 ($0.25-$2.50/M with unlimited options), and full SOC 2 Type II 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. 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. Overall, developers now have a wide range of Tempo RPC options—from enterprise-ready infrastructure to flexible, budget-friendly platforms—making it easier to match providers to specific performance, compliance, and cost requirements. Reliable Tempo RPC infrastructure Getting started with Tempo 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. Start building with Chainstack → 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 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. #### 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 reduces serialization overhead by 30–50% compared to JSON 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 penalties3QuickNodeMulti-chain teams needing formal SLA + complianceTrial onlyVaries by method mixMedium — requires method-mix modeling4AnkrMulti-chain development, archive access on free tier200M credits/mo, ~30 RPS~$20 (at 200 credits/call)Medium — per-method weighting inflates costs5dRPCCost-optimized high-volume workloads, failover endpointFree tier (public nodes)$6 flatHigh — 20 CU per call regardless of method 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)3QuickNodeNo public TRON gRPCAvailable on paid plans99.99% formal SLAType II + ISO 27001Not supported (TRON limitation)4AnkrListed in docsFull and archive on Premium99.99% claimedType I (Type II in progress)Not supported (TRON limitation)5dRPCNo public TRON gRPCDepends on upstream providersMulti-provider routing; no formal SLANo public SOC 2Not 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. https://twitter.com/ChainstackHQ/status/2015839209882353804 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, Gemini, or Windsurf 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. IP and origin access rules for endpoint protection. For enterprise teams: SOC 2 Type II 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, 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 Pro 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 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. 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 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. 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 + 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 penaltiesQuickNodeVaries by method mixMedium — requires method-mix modelingAnkr~$20 (at 200 credits/call)Medium — per-method weighting inflates costsdRPC$6 flatHigh — 20 CU per call regardless of method Enterprise TRON infrastructure Compliance posture SOC 2 Type II is the baseline for enterprise blockchain infrastructure procurement. The current landscape: Chainstack — SOC 2 Type II (achieved late 2025). Access controls include IP whitelisting and origin restrictions. QuickNode — SOC 2 Type II + ISO 27001. Dedicated clusters with SLA-backed support. Ankr — SOC 2 Type I (Type II in progress). TronGrid, dRPC — no public SOC 2 certification. 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). 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, 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, reducing payload sizes by 30–50% with 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 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 #### 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 #### 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  #### 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 #### 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. #### 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. https://youtu.be/0aJfCug1zTM 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 #### 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 #### 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!  #### 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: https://www.youtube.com/watch?v=oAEY6Ygrl7M 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 #### 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 #### 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 https://www.youtube.com/watch?v=Sc9O42Wwj18 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 #### 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 #### 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: https://chainstack.com/procedurally-generated-nfts/ 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 #### 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. https://youtu.be/EqwWyZ1HhfM 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 #### 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 #### 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 #### 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 https://www.youtube.com/watch?v=5JjwtXtskws 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 #### 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. https://www.youtube.com/watch?v=2wQn_nvAQp8 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 #### 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 #### 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 #### 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! #### 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. #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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! #### 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 #### 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. #### 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 #### 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. #### 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 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 #### 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 #### 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. https://www.youtube.com/watch?v=QuExIWULoAs 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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. #### 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 #### 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 #### 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 #### 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 https://youtu.be/DUs99wk2ueE https://youtu.be/inhLe06Z6wM 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 #### 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 #### 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 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 #### 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 #### 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 #### 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 #### 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 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.  #### 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 #### 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: Get started 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: Get started 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: Get started 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: Get started 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 #### 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. #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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. #### 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 #### 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 #### 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! #### 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. #### 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 #### 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 #### 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 #### 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 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 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 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 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 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, 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 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 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 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 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 certificationSOC 2 Type II–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) https://twitter.com/coinbureau/status/1999185517108429104 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 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 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. https://twitter.com/Filecoin/status/2022444513273200934 In a recent post, Ethereum further detailed the five new ways in which ERC-8004 improves the current AI agent ecosystem and experience: https://twitter.com/ethereum/status/2021292399012741219 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.” https://twitter.com/VitalikButerin/status/2020963864175657102 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 🤙 #### 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. #### 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 :P 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 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. https://twitter.com/ethereumfndn/status/1998781751468941746 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 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.” https://twitter.com/fbwoolf/status/2027776391035404613 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.” https://twitter.com/VitalikButerin/status/2032469755614179700 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 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. https://twitter.com/drakefjustin/status/2026755969540108659 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 #### 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 #### 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 #### 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.  #### 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 #### 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 #### 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 #### 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 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 #### 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. https://youtu.be/fB_1IK3A294 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 #### 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. https://twitter.com/ConsenSys/status/1503748090720833548 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. #### 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. #### 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 #### 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. https://www.youtube.com/watch?v=CIRXpb07TdY 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 #### 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 #### 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 #### 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 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 #### 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. https://youtu.be/BCGqfXjHDac 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 #### 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 #### 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. #### 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 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 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 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, 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.”  #### 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. https://twitter.com/hypedexer/status/2050483661091348782 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 https://twitter.com/BSCNews/status/2051203423270519197 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: https://twitter.com/Outcomexyz/status/2053890344362668121 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. https://www.youtube.com/watch?v=2nNHTmoq7Pc 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 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. https://www.youtube.com/watch?v=WLli_5iI0BM 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/user/login 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 #### 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 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 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 #### 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! #### 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/user/account/create. 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 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 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. #### 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 350x350, 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 350x350, 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 #### 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 #### 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 #### 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: https://www.youtube.com/watch?v=nvK9V2Jh2Dk 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 managed 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. 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 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 #### 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 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 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: https://www.youtube.com/watch?v=_XEmou4Y0N0 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 #### 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 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 #### 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 #### 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 #### 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 Solana RPC node: setup guide 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 one 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 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. 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 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. #### 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 #### 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! #### 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. Enable Yellowstone gRPC 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. https://www.youtube.com/watch?v=ICBF1wdD-sM&t=1s 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 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 Power-boost your project on Chainstack 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. #### 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/user/account/create. 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. https://youtu.be/mrLAhlHExjk 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. https://twitter.com/BlvckParis/status/1724789429657837910 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. https://youtu.be/eD2UvOWVBG4 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 #### 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. https://twitter.com/HyperFND/status/1891730068151599464 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. https://www.youtube.com/watch?v=v9oACcJ7I2U 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. https://www.youtube.com/watch?v=5WVmh0RaUpQ everis NTT Data's ongoing IoT+ Blockchain project https://www.youtube.com/watch?v=a3ASiNterc8 Latest blockchain developments in blockchain adoption in APAC Panel with Hitachi https://www.youtube.com/watch?v=I_5dEK4q5T0 Blockchain for smart cities session with Hitachi https://www.youtube.com/watch?v=UQGm61enUIA 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. https://youtu.be/tUcv9jkBZdQ 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 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. https://twitter.com/HyperliquidX/status/1590795586357571584?s=20 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-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. https://twitter.com/HyperliquidX/status/2018327360723202167 📖 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 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. https://twitter.com/HyperliquidX/status/1773531180815507473 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. https://twitter.com/HyperliquidX/status/2018227446320173431 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. https://twitter.com/HyperliquidX/status/2018327360723202167 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. https://twitter.com/smartestmoney/status/2037022122892300397 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 #### 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 #### 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 #### 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 #### 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. https://youtu.be/aPGc5c7Tn8g 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 #### 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 #### 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. https://www.youtube.com/watch?v=s_uP802NVTE 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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! #### 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 #### 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 #### 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 #### 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 #### 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! #### 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 #### 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 #### 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 #### 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. #### 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.  #### 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! #### 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. #### 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 #### Most cost-effective Hyperliquid RPC providers in 2026 Hyperliquid has become one of the fastest-growing trading and execution environments in 2026. Its high throughput, native order book design, and HyperEVM compatibility make it attractive for trading bots, on-chain funds, and real-time applications. But performance alone does not determine your infrastructure choice. As request volume grows, RPC costs can quickly become a material part of your operating budget. Credit-based pricing, overage fees, RPS caps, and archive access all impact your total cost of ownership. The public Hyperliquid RPC works for testing, but rate limits and method restrictions make it unsuitable for sustained production workloads. Moving to a private provider improves reliability and performance, yet pricing models vary significantly—and small differences compound at scale. This guide compares the most cost-effective Hyperliquid RPC providers in 2026. Instead of focusing only on speed and uptime, we analyze pricing structures, included quotas, scaling economics, and overage models to help you choose the right provider for your budget and workload. What “Hyperliquid RPC” includes: HyperEVM vs HyperCore In practice, Hyperliquid access involves two distinct layers that get conflated frequently: HyperEVM The EVM layer exposed through standard JSON-RPC (eth_* methods), with mainnet chain ID 999 and the official public endpoint at https://rpc.hyperliquid.xyz/evm. This is what most teams mean when they say "Hyperliquid RPC." HyperCore The trading and market data layer, exposed through HTTP endpoints like /info for market state and /exchange for signed trading actions. The distinction matters because some providers support only HyperEVM while others expose both. It also creates a common pattern where teams end up with a dual setup: one provider for HyperEVM RPC and a separate path — either the official Hyperliquid API or a specialized provider — for HyperCore trading endpoints. ⚠️ Worth noting: while Chainstack supports both HyperEVM and HyperCore, a small number of trading actions — such as Place order — still require the official Hyperliquid API directly. For the full list of supported methods, see Chainstack's Hyperliquid documentation. Why is private Hyperliquid RPC required for production The public Hyperliquid infrastructure is adequate for development and testing. For production, it has hard limits that quickly become blockers: WebSocket connection and subscription limits Message rate limits 100 requests/minute on the HyperEVM JSON-RPC endpoint No WebSocket JSON-RPC support on rpc.hyperliquid.xyz/evm Production bots, indexers, and anything latency-sensitive will need private infrastructure. The relevant questions then become: how much does private RPC cost at the volumes you actually need, which pricing models are predictable under load, and where do add-ons change the total cost of ownership significantly. Hyperliquid RPC provider comparison ProviderBest fitPricing modelMain pricing riskChainstackPredictable high-throughput workloads with HyperEVM + HyperCore supportRU bundles + overage; optional flat-fee RPSArchive requests cost more; high-RPS tiers can be expensiveQuickNodeUnified HyperEVM + HyperCore stackCredits modelAdvanced APIs and large calls multiply cost quicklyAlchemyModerate-volume teams using broader toolingCompute UnitsHeavy methods like logs and trace increase CU burndRPCSimple PAYG or backup routingFlat $/1M requestsFree tier uses public nodes onlyHypeRPCHyperliquid-specific niche workloadsCompute UnitsWebSocket billed by byte; regional price surcharges Hyperliquid RPC specs and pricing overview ProviderFree tierOverage / PAYGThroughputProtocolsUptime SLAComplianceChainstackYes — 3M RUFrom $20/M RU (free tier); lower on paid plans25–600 RPS by plan; Unlimited Node 25–500 RPSHTTP, WS, full + archive≥99.99% formal SLA; 99.99%+ claimed for dedicated HyperliquidSOC 2 Type IIQuickNodeTrial onlyOverage by credits~50–500 RPS by planHyperEVM + HyperCore; HTTP/WS/gRPC99.99% claimedSOC 1 Type 2, SOC 2 Type 2, ISO/IEC 27001AlchemyYes — 30M CU$0.45/M CU to 300M, then $0.40/MThroughput in CU/sHTTP, WS99.99% referencedSOC 2 Type IIdRPCYes — 210M CU on public nodes$6 per 1M requestsFree 100 RPS; Growth 5K RPSHTTP, WSS99.99% claimed on GrowthNot prominently publishedHypeRPCYes — 2M CU$0.50/M CU (EU); $0.75/M CU (JP)100–6000 CU/s by planWebSocket + archive99%–99.99% by planNot prominently published Cost per 1M requests: 100K vs 5M vs 200M workloads The table below normalizes each provider to a comparable effective cost using each provider's public documentation and consistent assumptions. Provider100k req/month5M req/month200M req/monthChainstack$0 / $0.00 per 1M$49 / $9.80 per 1M$990 / $4.95 per 1MQuickNode$49 / $490.00 per 1M$61.25 / $12.25 per 1M$1,999 / $10.00 per 1MAlchemy$0 / $0.00 per 1M$56.25 / $11.25 per 1M$2,015 / $10.08 per 1MdRPC$0 / $0.00 per 1M$0 / $0.00 per 1M$1,200 / $6.00 per 1MHypeRPC$0.25 / $2.50 per 1M$61.50 / $12.30 per 1M$2,449 / $12.25 per 1M How to read these numbers A $0 result means the workload fits inside a free tier — not that it is production-ready. Free tiers typically come with public nodes, no SLA, and no operational guarantees. They are appropriate for development, not for live trading infrastructure. For CU/credit-based models, actual cost depends heavily on your method mix. The figures above assume average workloads. A logs-heavy or trace-heavy pipeline will cost materially more with CU-weighted providers. At high volume, flat-fee and simple-billing models become meaningfully easier to forecast and budget. ❓ Compare plans and providers using Chainstack's interactive pricing calculator: chainstack.com/pricing Visual cost comparison QuickNode requires a paid plan even at minimal volume — $490/1M effective cost vs $0 for everyone else. At 5M requests/month, Chainstack at $9.80/1M is the only production-grade option with a formal SLA. dRPC's $0 uses public nodes — no uptime guarantees. Chainstack at $4.95/1M is the clear cost leader. HypeRPC at $12.25/1M is the most expensive option. Provider breakdown Chainstack Chainstack supports both HyperEVM and HyperCore. It is one of the strongest options for teams that need predictable pricing under sustained load. Billing uses request units (RUs): 1 RU per full-node request, 2 RU per archive. The plan ladder runs from Developer (free, 3M RU) through Growth ($49/mo, 20M RU), Pro ($199/mo, 80M RU), and Business ($499/mo, 200M RU) up to Enterprise ($990/mo, 400M RU). Overage rates drop as you scale — from $20/M RU on Developer down to $5/M RU on Enterprise. For 200M requests/month, Enterprise at $990 flat is the best-value option — 400M RU included, no overage needed, and the $4.95/1M effective rate is confirmed by Chainstack's own pricing calculator. The SLA is formal and documented — 99.99% baseline, with 99.99%+ claimed for dedicated Hyperliquid nodes. SOC 2 Type II compliance is published, which matters for teams with procurement requirements. ⚠️ Worth knowing: Chainstack supports both HyperEVM and HyperCore. A small number of trading actions — such as Place order — still require the official Hyperliquid API directly. For the complete list of supported methods and endpoints, see Chainstack's Hyperliquid documentation. Best fit: production workloads that need stable throughput, predictable invoices, and a formal compliance posture. QuickNode QuickNode's strength is breadth. It has strong coverage across both layers HyperEVM and HyperCore, with HTTP, WebSocket, and gRPC protocols supported and Hyperliquid-specific streaming endpoints available. The cost trade-off is real, though. Standard Hyperliquid requests count at 20 credits each, which means the effective request capacity of each plan is lower than it looks. Advanced APIs and large call responses apply 2x to 4x multipliers on top. At scale, QuickNode is noticeably more expensive per 1M requests than Chainstack. Best fit: teams that want a single vendor for the full Hyperliquid stack and where that consolidation genuinely offsets the higher per-request cost. Alchemy Alchemy is the familiar choice for teams that already use it for other EVM chains. Its tooling is mature and its plan tiers are clearly structured. The pricing risk is method weighting. Alchemy explicitly states that one API request averages around 25 CUs, but specific methods vary considerably — eth_blockNumber costs 10 CU while eth_getLogs costs 60 CU. A workload heavy on log queries or debug/trace methods can burn through CUs much faster than headline pricing suggests. Best fit: teams already embedded in the Alchemy ecosystem at moderate scale where the broader platform (enhanced APIs, webhooks, NFT tools) provides additional value. ⚠️ Understanding credit-based pricing Some providers, including Alchemy and QuickNode, charge per credit or compute unit (CU) rather than per request. A single JSON-RPC call may consume multiple credits depending on complexity. Archive reads, tracing, and WebSocket usage typically consume more than simple calls. As a result, cost per million requests is variable and depends on method mix and workload profile. Flat per-request pricing models are generally more predictable for high-volume systems. dRPC dRPC offers the simplest pricing model in this comparison: a flat $6 per 1M requests. There is no CU math, no method multipliers, and no credit translation required. The caveat at the free tier is meaningful — it routes through public nodes, which is unsuitable for production. The Growth tier offers up to 5,000 RPS, which covers most scaling scenarios. Compliance documentation is not prominently published on the pricing page, so it requires direct validation if that matters for your procurement process. Best fit: PAYG use cases, backup provider setups, and teams that prioritize billing simplicity over the absolute lowest unit cost. HypeRPC HypeRPC is positioned as a Hyperliquid-specialist provider. That specialization has a cost premium under published pricing — it is the most expensive option in this comparison at the 200M request/month tier. Two pricing complications set it apart from other CU-based models. First, the Japan region carries a 50% pricing surcharge relative to EU. Second, WebSocket traffic is billed at 0.02 CU per byte, which can be material for real-time systems handling frequent snapshots or large order book updates. Best fit: teams for whom Hyperliquid-specific expertise or geographic positioning is worth a higher per-request cost. Not recommended as a primary cost-optimization path. Hidden cost factors in Hyperliquid RPC pricing The headline pricing table is a starting point. These factors frequently change the real number in production. Method weighting — Logs, trace, debug, and large response calls can increase effective cost by 2–6× compared to a reads-only workload at the same raw request count. This is the biggest wildcard for CU-based models. Archive multipliers — Some providers charge more for historical state requests. At Chainstack, archive requests cost 2 RU instead of 1 RU — predictable, but worth factoring in for archive-heavy pipelines. Throughput ceilings — A provider that looks cheap at your request volume may push you into a significantly more expensive tier once your required RPS is factored in. WebSocket billing — Most providers bundle WebSocket usage inside broader plans. HypeRPC bills by byte — 0.02 CU/byte — which can create significant variability for streaming-intensive systems. HyperCore add-ons — Order book data, trading endpoints, and streaming market data are separate products at several providers and should be evaluated as explicit line items. Free-tier realism — Free tiers usually come with public nodes, no SLA, and throughput limits that make them unsuitable for live systems. Best Hyperliquid RPC provider by use case Predictable high-throughput pricing → Chainstack. The Enterprise plan at $990/mo covers 400M RU with no overage risk — the most predictable cost structure at scale. The formal SLA and SOC 2 compliance also make it the most defensible choice for teams with compliance requirements. Simple PAYG → dRPC. No CU math, flat rate, high advertised throughput on paid tiers. The cleanest option for teams that want straightforward invoicing. Unified HyperEVM + HyperCore platform → Chainstack or QuickNode. Chainstack supports both layers with a formal SLA and SOC 2 compliance. QuickNode is also a strong option if you need gRPC or Hyperliquid-specific streaming endpoints and are willing to pay a higher per-request cost. Ecosystem tooling at moderate scale → Alchemy. Best for teams already using Alchemy across other chains where the broader platform value is real. Hyperliquid specialization → HypeRPC. Niche choice for teams where that focus is the priority. Not a cost-optimization path. Decision framework A practical way to narrow your choice: Determine which layers you need. HyperEVM only, HyperCore only, or both? The answer immediately filters several providers. If you need HyperCore, validate the exact endpoint coverage for each provider before committing. Some trading actions require the official Hyperliquid API regardless of your primary RPC provider. Estimate your request volume and method mix. CU-weighted pricing can be 2–6x more expensive for logs-heavy workloads than for simple reads. Always model your actual method distribution. Check your required RPS. A provider that looks cheap at your request count may push you into a significantly more expensive plan tier once throughput constraints are applied. At 100M+ requests/month, prioritize providers with flat-fee RPS models, low overage rates, or simple per-request billing. Compute-based models become harder to forecast and more expensive at scale. Validate compliance requirements early. Not all providers publish SOC 2 or ISO certifications prominently. If this matters for procurement, confirm it directly and do not rely on marketing pages. Conclusion At high volume with predictable billing and a formal compliance posture, Chainstack is the strongest option — the Enterprise plan at $4.95/1M locks in predictable costs without overage exposure. For simple pay-as-you-go economics without compute math, dRPC is the cleanest option. For teams that need the full Hyperliquid stack in a single platform, QuickNode can justify higher per-request cost. Alchemy remains viable for teams already using it across other chains, while HypeRPC is best treated as a specialist option rather than a cost leader. One point holds across all scenarios: the public Hyperliquid RPC is a development tool, not a production one. Once volume, latency sensitivity, or operational requirements increase, provider economics matter fast — and the differences between these options at scale are large enough to be worth modeling before you commit. 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 Start building with Chainstack → FAQ Which Hyperliquid RPC provider is cheapest at high volume? Under published self-service pricing, Chainstack has the lowest effective cost per 1M requests at 200M/month. What is the best Hyperliquid RPC for production trading bots? Chainstack, or dRPC, are the strongest options depending on whether you prioritize a formal SLA and compliance posture, lowest-cost scale, or simple PAYG billing. All both offer private infrastructure with documented throughput guarantees. Is the public Hyperliquid RPC usable for production? Not for most production workloads. The official HyperEVM endpoint is limited to 100 requests/minute and does not expose WebSocket JSON-RPC, making it unsuitable for bots, indexers, or any latency-sensitive application. How do I compare request-based and compute-based pricing fairly? Normalize to effective cost per 1M requests, then adjust for your actual method distribution. For workloads that rely on logs, trace, or debug methods, CU-based pricing can be 3–5x more expensive than simple read workloads at the same raw request count. Which providers support both HyperEVM and HyperCore? Chainstack and QuickNode all support both layers. Chainstack explicitly documents HyperCore and HyperEVM support. QuickNode adds gRPC and streaming-specific endpoints. In all cases, validate exact endpoint coverage against current documentation — some trading actions, such as Place order, may still require the official Hyperliquid API. 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 Best Hyperliquid RPC providers — general comparison RPC providers by use cases #### 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 #### 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 #### 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.  #### 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. #### 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. #### 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! #### 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 #### 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 #### 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 #### 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 #### 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 #### 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  #### 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 https://gist.github.com/akegaviar/511b5122d5bd03b603ac915b057b1ea5 State https://gist.github.com/akegaviar/2a1bf6ff4cba4d6e9c1ed5f249e62326 Flow https://gist.github.com/akegaviar/d88664b67ece9933d29381da5e1f6351 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 https://gist.github.com/akegaviar/bfc6b5a05a010d169a117439479f5714 State https://gist.github.com/akegaviar/0e690ecf59486e639260ff150106ebbb Flow Flow https://gist.github.com/akegaviar/f040c0f5434ecf127a1ec859f331d438 Flow responder https://gist.github.com/akegaviar/40784486b65b5d73f111504932b59d5c 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 https://gist.github.com/akegaviar/272adbbd98f6ab217d46e580a8493911 Source on GitHub. Hyperledger Fabric “Hello, Block!” in Java Chaincode https://gist.github.com/akegaviar/6296d6fbb3bfb0363679ef23e17668fc Source on GitHub. Hyperledger Fabric “Hello, Block!” in JavaScript Chaincode https://gist.github.com/akegaviar/e0281bab96335962361954c23ab61f45 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 https://gist.github.com/akegaviar/d98bfd5b55d5883a4b5b7470a4a52aed Source on GitHub. Quorum “Hello, Block!” in Solidity programming language Contract https://gist.github.com/akegaviar/7ae72e1d359349960efa067a141f5bfc 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 #### 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 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 #### 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 #### 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. https://twitter.com/Polymarket/status/1931029892369391898 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. https://twitter.com/x/status/1931001329129844987 In October 2025, Intercontinental Exchange, the parent company of the NYSE, invested $2 billion in Polymarket, valuing the platform at $9 billion. https://twitter.com/Polymarket/status/1975528768039985449 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. https://twitter.com/Polymarket/status/2034084729146716520?s=20 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: https://twitter.com/hal2001/status/1854160052535644656 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 #### 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 #### 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 #### 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. https://twitter.com/ShaulKfir/status/2034950244849320187 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 Layer 1 vs Layer 2: Ethereum Infrastructure, RPC, and scaling 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, 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. #### 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! #### 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. #### 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. #### 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. #### 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 #### 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. Geyser gRPC interface 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: https://www.youtube.com/watch?v=ICBF1wdD-sM 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 #### 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. https://twitter.com/KelpDAO/status/2045595819035046148 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. https://twitter.com/Dune/status/2046257791321670098 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.  https://twitter.com/aave/status/2047334669906034708 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 #### 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 #### 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: https://www.youtube.com/watch?v=c2QI0ZMMMzQ 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 #### 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. https://youtu.be/t3ggsOLhbQk 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 #### 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." https://twitter.com/lopp/status/1822289187581706726 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.” https://twitter.com/VitalikButerin/status/2033027706707915186?s=20 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 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 #### 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. https://www.youtube.com/watch?v=B5b5UbCBODY 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. 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 #### 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. #### 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 #### 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. #### 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 #### 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 mutable reference. How do I create accounts larger than 10 KB? The init constraint uses CPI under the hood, capping allocation at 10,240 bytes. Split it into two steps: your client calls the System Program directly to create and fund the account, transferring ownership to your program. Then your on-chain instruction uses the zero constraint instead of init — it skips CPI, verifies the account is blank, and writes the discriminator. Maximum account size is 10 MB. 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 faucet now available on Chainstack Solana faucets and dev airdrops have always been scattered, rate-limited, or throttled when you need them most. So we built one that just works: fast, reliable, and native to the Chainstack console. Access to free Solana is a critical part of building on Solana, whether you're testing programs, simulating mainnet behavior, or deploying new features. Most public options, however, are overloaded, Discord-gated, or offline just when you need them. With Chainstack, developers can request test SOL on Devnet using a built-in Solana faucet, directly from the dashboard. We’ll cover how the Chainstack Solana faucet works, how to access it, what the daily limits are, and how it fits into early-stage program development on Solana. What is Solana Devnet Faucet? A Solana devnet faucet gives developers on-demand access to test SOL when building in Solana’s Devnet environment. Devnet replicates mainnet conditions — including transaction cost, compute limits, and runtime behavior — but uses disposable tokens instead of real SOL. Test SOL is required to deploy programs, execute transactions, and validate changes in environments that behave like production but carry no financial risk. A faucet exists to remove the funding bottleneck. Without it, provisioning a new dev wallet becomes a blocker. The faucet now integrated into Chainstack eliminates common failure points seen in public alternatives: unstable endpoints, inconsistent limits, and Discord-gated access. It's available directly in the platform UI, with no dependencies on third-party infrastructure. How to use the Solana Devnet Faucet on Chainstack If you're wondering how to get free Solana for development, it takes less than a minute. Here’s how: Sign up for a free Chainstack account and verify your email Go to Settings → API Keys Click Create API Key, give it a name, and copy the key Head to faucet.chainstack.com Paste your Solana Devnet wallet address and your API key Click Claim tokens You’ll receive 1 test SOL instantly, and can come back every 24 hours to request again. 🔒 Note: To prevent abuse, your wallet must hold a small amount of SOL on Mainnet. This helps ensure the faucet is used by real developers. Prefer to see it in action? Watch the video tutorial for a step-by-step walk-through: https://www.youtube.com/watch?v=Z52zJTDHwUw Get your Solana RPC endpoint → Why use a Solana Faucet (Dev use cases) A faucet gives developers a direct way to fund test wallets, which powers everything from basic transaction flows to full end-to-end integration tests. It also enables: Deploying and upgrading programs without real capital at risk Testing failure cases (reverts, compute budget overruns, signature mismatches) Validating token mechanics before launch Reproducing bugs found in production environments Running local simulations at scale, synced to Devnet It’s the same idea behind a Solana airdrop - a way to bootstrap development without real funds. But while Solana airdrops tend to be sporadic or tied to marketing events, a faucet is always available and predictable. Mainnet vs Devnet vs Testnet — Which One Do You Need? Solana runs on multiple networks, each serving its role. If you're writing and deploying programs, testing validator behavior, or preparing a production rollout, the environment you choose will directly affect how you test, what breaks, and what it costs. Chainstack’s faucet supports Devnet, which is where most teams start. If you need test tokens for Testnet, you’ll need to grab them from a public Solana testnet faucet. And if you're on Mainnet, funding is on you.  NetworkWhat it’s forFaucet SupportDevnetFast iteration, program testing, CI flows, and integration debugging. Devnet resets regularly and uses disposable tokens.✅ Yes (supported via Chainstack faucet)TestnetSolana Labs’ validator testing ground. Used for upgrades and protocol-level simulations.🚫 No (use a public Solana testnet faucet)MainnetReal value. Final deployment. Live users. Every transaction is permanent and costs real SOL.🚫 No faucet (use funded wallets only) For most projects, Devnet is the starting point: fast, resettable, and frictionless. Testnet is better suited for low-level protocol testing or validator experimentation. Mainnet is where users and assets are real and where mistakes carry cost. Daily Limits & Request Frequency Each wallet can request tokens once every 24 hours. If a request is made before the window resets, the system will return an error showing how much time remains. The faucet uses a top-up model, not a fixed drop. If your Devnet wallet already holds close to the daily allocation cap, the faucet may send a reduced amount, or none at all.  Requests must be authenticated with a valid Chainstack API key, which you can generate from your dashboard under Settings > API keys. Summary Solana development depends on fast, reliable access to test SOL. Without it, deploying, debugging, or simulating production logic becomes slower than it needs to be. That’s why we built the faucet directly into Chainstack — giving developers a stable way to fund Devnet and Mainnet beta wallets from the same platform where you already manage nodes, keys, and infrastructure. Need a Solana mainnet RPC? Deploy a Solana node on Chainstack in under 5 minutes. Get your Solana RPC endpoint → Further reading Need testnet tokens beyond Solana? Chainstack also supports multi-chain faucets for Sepolia, Holesky, BNB Smart Chain, zkSync, Scroll, TON, and more. How to get a Solana RPC endpoint: Learn how to deploy and configure high‑performance Solana RPC nodes across regions. Solana developer guide: Dive into Solana account structure, program deployment, Web3.js usage, and best practices. FAQ Are Solana faucets legit? Yes, faucets are the standard way to get test SOL for development. Chainstack’s faucet is built directly into the platform, so there’s no need to rely on Discord bots or unreliable third-party links. How often can I claim free SOL? You can request test SOL once every 24 hours per wallet. The limit resets automatically, and top-ups are only sent if your wallet holds less than the allowed max. #### Solana interest-bearing tokens: Inside the mint extension In the traditional DeFi stack, engineering a yield-bearing asset has always been a battle against state bloat and compute costs. If you saw systems around EVM rebasing tokens, think of stETH as example, you know the architectural headaches they introduce. To reflect accrued interest, an EVM protocol must either continuously update storage slots across thousands of user accounts (which is expensive) or rely on a complex “shares-to-balances” mathematical abstraction under the hood, forcing every integrating smart contract to implement custom logic just to read a user’s true balance. Solana’s Token-2022 standard completely flips this paradigm. Instead of fighting state mutations, it eliminates them entirely. With the introduction of the Interest-Bearing Tokens Mint Extension, Solana introduces the concept of “Cosmetic Yield.” At the state level, the raw token amount residing in a user’s Token Account never changes. There are no rebasing events, no automated yield-harvesting cranks, and no state bloat. Instead, the accrued interest is calculated mathematically and continuously at the UI and RPC layer based on the network’s clock. The protocol simply applies a continuous compounding formula: A=PertA = P e^{rt} to the static principal. Just as Transfer Hooks modularized transfer logic by pushing it to external programs, the Interest-Bearing extension modularizes yield by separating the configuration of the interest rate from the execution of the math. It relies heavily on a strict separation between execution logic in processor.rs and pure mathematical interfaces mod.rs. In this post, we are going to get under the hood of the InterestBearingConfig. We will break down the Rust implementation, explore the continuous compounding math, and look at the architecture. The architecture of Cosmetic Yield vs. State Mutation To truly appreciate the engineering behind Solana’s Interest-Bearing extension, we first have to look at the problem it solves. In blockchain architecture, state is expensive, and mutating state across thousands of accounts simultaneously is almost impossible. The EVM bottleneck: rebasing and shares If you look at the successful yield-bearing assets on the EVM for example Lido’s stETH Token it rely on state mutation. Because an ERC-20 balanceOf function needs to return a constantly growing number to reflect yield, EVM developers had to get creative. They introduced the “shares” model. Under the hood, your wallet doesn’t actually hold stETH, it holds a static number of shares of the total pool. When you call balanceOf(user), the smart contract executes a calculation: https://lido.fi/how-lido-works/rewards-and-penalties Here is where the architectural bottleneck occurs. While UserShares and TotalShares remain relatively static, the actual amount of ETH backing the protocol on the Beacon Chain is constantly growing. However, the Ethereum execution layer smart contract is entirely isolated from this growth. The variable TotalPooledEther is just a static number sitting in contract storage. It cannot update itself. For users to actually see their stETH balances increase, an external Oracle (a bot) must explicitly broadcast a transaction to the smart contract every period of time. This transaction calls a function that overwrites the global TotalPooledEther state variable to reflect the new yield. Because that global variable was changed, the math equation now outputs a higher number for every single user. But getting that higher number required an active transaction, gas fees, and a global state write. Solana’s Token-2022 approach: computation over state Solana’s architecture prioritizes parallel execution and isolated account state. Forcing a global state update to reflect yield across all token holders would create massive write-locks, crippling network throughput. Token-2022 solves this by shifting the burden entirely from state storage to computation. This introduces the concept of Cosmetic Yield. When an interest-bearing mint is initialized, the raw amount is stored in a user’s Token Account (a simple u64 integer) represents only the principal: the exact original baseline number of tokens the user received. This raw principal amount never changes, even as the tokens earn yield. Instead of mutating the state to add the newly accumulated profit, the yield is calculated dynamically. No automated cranks, no oracle updates, and no global state mutations are required to generate this yield. The state remains static, while the math handles the growth. The uiAmount abstraction (where the yield lives) If the raw balance doesn’t change, and no oracle is updating a global variable, how does the user actually see their money growing? This is where the uiAmount comes in. In the Token-2022 standard, the interface makes a strict distinction between the raw amount (the state) and the uiAmount (the human-readable representation). Instead of relying on an external party to push updates, the Solana Token-2022 program pulls its truth from the Network Clock. The Mint account holds an InterestBearingConfig, which stores the initialization timestamp and the current interest rate in basis points. Because the network clock (Clock::get()?.unix_timestamp) inherently advances with every single block, the input to the continuous compounding formula: A=PertA = P e^{rt} is always growing automatically. When a dApp, wallet, or RPC node queries a user’s balance, it doesn’t just read the static integer. Instead, it calls the program’s amount_to_ui_amount instruction (will be explained shortly). This routes the query directly through the extension’s math engine. The program fetches the current network timestamp, calculates the accrued interest purely in memory, and returns the combined total as a formatted string (the uiAmount). The protocol completely bypasses the need for state-mutating transactions; the state remains static, while the math handles the growth. The math: continuous compounding on-chain Now that we understand the yield is calculated dynamically rather than stored in state, we have to ask: how is the math actually executed? If you have written smart contracts before, you know that floating-point math and exponential calculations are generally the enemy of blockchain development. They consume massive amounts of compute units and introduce rounding errors that can easily be exploited. Yet, the Token-2022 program handles this seamlessly using continuous compounding. The formula The core mathematical engine of the Interest-Bearing extension relies on the standard continuous compound interest formula: A=PertA = P e^{rt} Here is exactly how these variables map to the Solana Token-2022 architecture: A (Final Amount): The final ui_amount that includes the accrued yield. P (Principal): The raw amount of tokens stored in the user’s Token Account (which never mutates). e (Euler’s Number): The mathematical constant ~2.71828. r (Rate): The annualized interest rate. On-chain, this is configured in basis points (where 10,000 bps = 100%) and converted to a decimal during the calculation. t (Time): The time elapsed in years. Solana tracks this natively using the Unix timestamp in seconds, which the math engine divides by 31,556,736 (the number of seconds in a 365.24-day year). reference can be found here. The state variables: handling rate changes without state mutations A major architectural challenge arises when the rate_authority decides to change the interest rate. If a token yielded 5% for the first six months, and the authority updates it to 10%, the protocol cannot retroactively apply 10% to the entire lifespan of the token. If this were an EVM rebasing token, changing the rate would require a massive, O(N) state-mutating “checkpoint” transaction to lock in every individual user’s balance at the 5% rate before starting the 10% epoch. Token-2022 solves this elegantly within the InterestBearingConfig Type-Length-Value (TLV) layout stored directly on the Mint account. It tracks three crucial variables (will be explained more in the next section): current_rate: The active interest rate in basis points. last_update_timestamp: The exact Unix timestamp of the last rate change. pre_update_average_rate: The time-weighted average rate of all compounding periods prior to the last update. fn process_update_rate( program_id: &Pubkey, accounts: &[AccountInfo], new_rate: &BasisPoints, ) -> ProgramResult { // ... Authority validation checks omitted for brevity let clock = Clock::get()?; // Calculate the historical average up to this exact second let new_average_rate = extension .time_weighted_average_rate(clock.unix_timestamp) .ok_or(TokenError::Overflow)?; // Lock in the historical average extension.pre_update_average_rate = new_average_rate.into(); // Move the checkpoint timestamp forward to the current block extension.last_update_timestamp = clock.unix_timestamp.into(); // Set the new active rate extension.current_rate = *new_rate; Ok(()) } Notice what is completely absent from this function: there is no iteration over token accounts. Zero user balances are touched. The protocol simply calculates the new pre_update_average_rate up to the current block time, moves the last_update_timestamp forward, and sets the new current_rate inside the Mint’s TLV extension. When a user’s balance is calculated tomorrow, the math engine simply uses the locked historical average for the past, and the new active rate for the present. Full code can be found here. How checkpointing works in practice Now that we have seen the raw Rust logic, let’s watch the Token-2022 program execute this checkpointing in real-time. To see exactly how the state mutates without touching user accounts, we are going to use the Solana CLI to create a token, inspect its abstracted state, and trigger an interest rate change. Creating the mint First, we initialize a Token-2022 mint and tell the program to allocate space for the InterestBearingConfig TLV extension. We are going to set the initial rate to 5% (which is 500 basis points). spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --interest-rate 500 Output: Creating token Dmcd... (your new mint address) Signature: 4j... Inspecting the abstracted state Now that the mint is live, we can look at the exact bytes stored in the account data using the display command. spl-token display <YOUR_MINT_ADDRESS> If you look closely at the output, the CLI decodes the Interest-bearing extension block. It will look like this: Extensions Interest-bearing: Current rate: 500bps Average rate: 500bps Rate authority: <YOUR_WALLET> Because the token was just created, the Average rate and Current rate are identical (500 bps). However, the CLI is actually hiding some crucial data here for the sake of a clean UI. Under the hood, the raw Rust struct is also storing the initialization and update timestamps. The math engine knows that, as of this exact moment, the token earns 5%. Triggering the checkpoint (updating the rate) Let’s say six months pass. We want to update the rate to 10% (1000 basis points). As the Rate Authority, we fire the set-interest-rate command: spl-token set-interest-rate <YOUR_MINT_ADDRESS> 1000 If we immediately run spl-token display <YOUR_MINT_ADDRESS> again, we will see the Token-2022 math engine has safely mutated the Mint’s state: Extensions Interest-bearing: Current rate: 1000bps Average rate: 500bps Rate authority: L6h2ugreR3oNmKtBCpcsMPSLg3BwLR31fSPB1iU76mp Look at what just happened: Zero user accounts were touched. Instead, the Mint locked its own history. Behind the scenes, the program updated its hidden last_update_timestamp to the current network clock. When a frontend UI or an RPC node calculates a user’s yield tomorrow, it simply breaks the continuous compounding formula into two distinct chunks: The Past: It looks at the time between the creation and the hidden update timestamp, applying the Average rate (1 year 5%). The Present: It looks at the time since the last update up to the current block time, applying the new Current rate (0.5 years 10%). Peeking under the hood: Finding the hidden timestamps While the CLI conveniently formats the output for a clean terminal experience, as developers, we need to know what the math engine is actually reading. If you take that same Mint address, plug it into a Solana block explorer, and look at the raw on-chain data, the UI abstraction falls away. You will see the complete JSON representation of the interestBearingConfig extension exactly as it lives on the network: Here, the hidden architecture is fully exposed. You can clearly see the initializationTimestamp and the lastUpdateTimestamp that the continuous compounding formula inherently relies on to slice the yield curve into the “Past” and the “Present” without touching a single user’s token account. The abstraction layer and the BPF math engine Raw amount vs uiAmount The entire architecture of the Interest-Bearing extension hinges on a strict separation between state storage and presentation. In the Token-2022 standard, there is a hard boundary between the amount (the raw u64 integer stored in the database) and the uiAmount (the mathematically yielded float presented to the user). If a developer or indexer bypasses this abstraction layer and attempts to read the raw state directly, the architecture breaks down visually. Look at this screenshot from a popular Solana block explorer attempting to render the exact Mint we just updated: The raw data trap When we used the CLI to update the rate, we passed the integer 1000. In the Rust engine, this strictly represents 1000 basis points (bps), which equates to exactly 10%. Because the block explorer bypassed the program’s native math engine and directly deserialized the raw currentRate bytes from the Mint’s TLV extension and appended a % sign to the raw integer. The result is a frontend mistakenly advertising a 1,000% APY. This highlights a critical architectural constraint: You cannot natively trust the raw state of an Interest-Bearing token. To safely bridge the gap between the static state and the continuous compounding math, the Solana developers introduced two specific, native instructions to the Token-2022 program: AmountToUiAmount UiAmountToAmount Instead of forcing RPC nodes or other programs to import a math library and attempt to recreate the formula locally, these instructions allow you to query the program directly. You pass the raw u64 amount into the instruction, and the Token-2022 program executes the exponential math using the Mint’s exact timestamps, returning the formatted string. Querying the math engine To safely bridge the gap between the static state and the continuous compounding math, the Solana developers built the yield conversion directly into the RPC layer. Before we can query a balance, we actually need a token account with some principal in it. Let’s use the CLI to create an account for our Mint and give ourselves 100 tokens. spl-token create-account <YOUR_MINT_ADDRESS> spl-token mint <YOUR_MINT_ADDRESS> 100 Now, let’s imagine a few hours pass. To see the yield in action, we can query that specific token account using a standard curl request to the getTokenAccountBalance RPC method: curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "id": 1, "method": "getTokenAccountBalance", "params": [ "<YOUR_TOKEN_ACCOUNT_ADDRESS>" ] }' When the RPC node receives this request, it detects the Interest-Bearing extension, runs the exponential math using the Mint’s hidden timestamps, and returns both numbers simultaneously: { "jsonrpc": "2.0", "result": { "context": { "apiVersion": "3.1.10", "slot": 448286815 }, "value": { "amount": "100000000000", <-- The raw principal (100 tokens with 9 decimals) "decimals": 9, "uiAmount": 100.009224922, <-- The mathematically yielded balance! "uiAmountString": "100.009224922" } }, "id": 1 } Notice what is completely absent from this JSON response? The interest rate itself. You don’t have to fetch the 1000 basis points from the Mint, and you don’t have to manually calculate whether that means 10% or 1,000%. The RPC node handled the basis-point conversion, fetched the network clock, and ran the A=PertA = P e^{rt} formula entirely under the hood. The uiAmount already contains the correct yield. By relying on the RPC (or the native on-chain CPI) to execute the math, your protocol becomes completely immune to the kind of frontend parsing bugs we saw on the block explorer. The hard boundary is perfectly clear: the amount stays static, but the uiAmount safely delivers the continuously compounding truth. Conclusion To wrap up, the Token-2022 Interest-Bearing extension represents a fundamental architectural shift from state storage to computation: No State Bloat: Unlike EVM rebasing tokens that require constant Oracle transactions to mutate global state, Solana calculates yield dynamically using continuous compounding driven by the network clock. A=PertA = P e^{rt} Checkpointing the Mint: Interest rate changes lock historical averages directly into the Mint’s TLV configuration. This completely bypasses the need to iterate over or mutate individual user accounts. The Abstraction Layer: A user’s raw amount is strictly static principal. To get the true yielded balance, developers cannot just read the raw state, they must query the program’s math engine directly via RPC or on-chain CPI. Ultimately, it is an elegant, compute-heavy solution to EVM state bloat, paving the way for highly scalable, natively yielding assets. 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 Solana interest-bearing token? It is a Token-2022 token that accrues yield mathematically without changing the raw token amount stored in each account. What is the Interest-Bearing Mint Extension? It is a Token-2022 extension that stores interest-rate configuration at the mint level and lets clients derive the interest-adjusted balance over time. Does the token account balance change as interest accrues? No. The raw on-chain amount stays the same. The yield-adjusted value is exposed through UI- and RPC-level calculations. What is the difference between amount and uiAmount? amount is the raw stored principal. uiAmount is the interest-adjusted value shown to users after applying the extension logic. Why is this different from rebasing tokens? Rebasing tokens rely on balance updates or shares-based abstractions. Solana’s model avoids per-account state mutation and computes yield dynamically. Why does this matter for developers? Integrations must read balances correctly, understand RPC abstractions, and avoid treating raw account data as the final user-visible balance. 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 Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution #### Solana node types: validator, RPC, and trader nodes Running Solana infrastructure in 2026 means choosing between three operationally distinct node types — each built for a different job. Whether you're securing the network as a validator, serving application traffic as an RPC node, or competing for block inclusion as a trader node, the wrong infrastructure choice produces performance problems that look like software bugs. This guide breaks down how each Solana node type works, what it costs to run, and which workloads it's built for. TL;DR Solana has two protocol-level node roles — voting validators and non-voting RPC nodes — plus a trader-optimized deployment pattern for latency-sensitive workloads. Each serves a different function with a different hardware and operational footprint. Validators participate in consensus, produce blocks, and earn staking rewards. RPC nodes expose a JSON-RPC interface to dApps, wallets, and indexers. Trader nodes are latency-optimized infrastructure for MEV, arbitrage, and liquidation strategies. Latency directly affects transaction inclusion on Solana. With ~400ms block times, even tens of milliseconds of avoidable latency can determine whether a liquidation or arbitrage transaction lands. Self-hosting is viable for teams with dedicated DevOps resources. Managed infrastructure is often the better tradeoff for early-stage teams that don't want to absorb snapshot management, hardware lifecycle, and failover complexity. What are Solana nodes? The Solana network is composed of independent computers i.e. nodes that collectively maintain the blockchain's state. Each node runs software that participates in one or more roles: validating transactions and producing blocks, serving data queries from applications, or submitting transactions on behalf of programs that require low latency. Unlike some blockchains, where every node performs every role, Solana's architecture distinguishes these responsibilities clearly. Understanding which node does what is the foundation for making correct infrastructure decisions. Types of Solana nodes There are two protocol-level node roles and one common low-latency operating pattern, each with different setup requirements: Solana Validator node (protocol role): participates in consensus (votes) Solana RPC node (protocol role): serves JSON-RPC + WebSocket APIs Solana Trader setup (operational pattern): low-latency transaction routing/submission 📖 Voting vs non-voting: An RPC node is technically a non-voting validator. It runs the same software and maintains the same ledger state, but it does not have a funded vote account and does not participate in consensus. A trader node is similar: it is validator software configured purely for transaction forwarding and submission, not for voting. Let’s go through each of them in detail. Solana Validator Node A validator is a full participant in Solana's Tower BFT consensus. It maintains the ledger state required for validation; full historical retention is optional and requires additional storage configuration, verifies and processes every transaction, votes on every block produced by the current leader, and periodically takes its own turn as leader, producing and broadcasting new blocks. Every validator has a publicly registered identity keypair and a vote account on-chain to which stake can be delegated. Voting is not free. Each vote is a transaction broadcast to the network, costing historically around 1.1 SOL per day in vote transaction fees, though this varies with network conditions. This is why a validator with little or no delegated stake operates at a net loss, the staking rewards earned must exceed the vote costs to break even. Validator Pipeline ➡️ If you are already familiar with the Solana Validator Architecture, you can skip to “Validator Setup” section below. The best way to understand a validator's internals is to follow a single transaction from the moment it leaves a client's wallet all the way to the point where the block it belongs to is finalized by the network. Two pipelines handle this: the TPU (Transaction Processing Unit) runs on the leader that produces the block, and the TVU (Transaction Validation Unit) runs on every other validator that validates it. Source: anza.xyz Gossip and Gulf Stream Before a transaction can be processed, every validator in the network needs to know two things: who the other validators are and who the current leader is. This is the job of the Gossip Service, which runs continuously on every validator, independent of whether it is currently a leader or not. Each validator broadcasts its ContactInfo, its public key plus the socket addresses of all its ports (TPU port, TVU port, repair port, etc.) into the gossip network. This data is stored in a shared structure called the CRDS (Cluster Replicated Data Store). Every validator continuously exchanges CRDS entries with its gossip peers, so within a few seconds every node has a complete picture of the cluster. The Gossip Service also propagates the leader schedule: a deterministic rotation of which validator will produce blocks in each upcoming slot, computed from stake weights two epochs in advance. This leader schedule is what makes Gulf Stream possible. Solana has no global mempool where transactions wait. Instead, because every node knows who the next leader will be, directly from gossip data, RPC nodes and validators forward incoming transactions straight to that leader's TPU port over QUIC. Transactions skip the network-wide broadcast step entirely and arrive at the leader before its slot even begins. This is how Solana achieves sub-second pre-confirmation times. Source: Solana Beach TPU When a validator's slot arrives it becomes the leader and switches into TPU mode. Its job for that ~400ms slot is to receive the incoming transactions forwarded to it, verify them, execute them, and package the results into a block for the rest of the network. This happens across four sequential stages. Source: anza.xyz Fetch Stage: The leader’s TPU receives packets through three QUIC sockets: tpu (transactions), tpu_vote (votes), and tpu_forwards (forwarded packets). Packets are grouped into batches of ~128 before moving forward. Stake-weighted QoS prioritizes connections from staked validators, helping protect the network from spam. SigVerify Stage: Transactions are deduplicated and their ed25519 signatures are verified. Invalid ones are flagged (discard=true) rather than immediately dropped so batches can move efficiently through the pipeline. When available, GPUs verify signatures in parallel for higher throughput. Banking Stage: Transactions are sorted by priority fee and grouped into non-conflicting batches based on account access. The batch is recorded into the PoH hash chain, then executed by the SVM where transactions touching different accounts run in parallel. Successful state changes update the in-memory bank for the current slot. Forwarding Stage: While this is happening, the banking stage also runs a Forwarding Stage in a side path: if the validator knows it is not the current leader, it forwards the incoming transactions (sorted by priority fee) to whoever will be leader, ensuring transactions are not dropped when the local buffer is full. Broadcast Stage: Processed entries are split into small network packets called shreds. The leader signs them, applies erasure coding, and distributes them through the Turbine protocol. This stake-weighted tree rapidly propagates the block across the validator network. TVU While the leader's TPU is building the block, every other validator is running its TVU. The TVU's job is to receive the shreds broadcast by the leader, verify them, persist them to disk, retransmit them to the next layer of the Turbine tree, reconstruct the full block, re-execute every transaction independently, and then cast a vote. This is how consensus is formed. Source: anza.xyz Shred Fetch: Shreds arrive from the Turbine network over the TVU UDP port and are distributed across parallel sockets. The Window Service tracks which shreds for each slot have arrived and detects gaps. If shreds are missing, the Repair Service requests them from peer validators. Shred Verify & Retransmit: Each shred’s signature is verified against the expected slot leader. Valid shreds are written to the Blockstore (the validator’s on-disk ledger) while being immediately retransmitted to neighbours in the Turbine tree. Fast retransmission helps propagate blocks quickly across the network. Replay Stage: Once enough shreds are collected to reconstruct a block, the validator verifies the PoH hash chain and re-executes all transactions using the SVM. It then compares the resulting state hash with the leader’s and uses Tower BFT to determine the canonical fork. Vote Transaction: If the block is valid, the validator submits a vote transaction for the slot hash via gossip. When votes from more than two-thirds of stake accumulate, the slot becomes confirmed and eventually finalized. Validator Clients Multiple teams maintain independent implementations of the Solana protocol: ClientMaintainerDescriptionAgaveAnzaReference implementation, forked from original Solana Labs client in 2024Jito-SolanaJito FoundationAdds block engine for MEV bundle submission, tip payment infrastructureFiredancerJump CryptoIndependent implementation; Frankendancer hybrid (C networking + Agave runtime) on mainnet; demonstrated 1M+ TPS in controlled testnet benchmarksSigSyndicaNew independent implementation; gossip, TVU, and SVM components in active development ℹ️ The Solana Foundation and major stakeholders actively encourage running multiple validator clients to reduce the risk of a single client bug causing a network-wide outage. The Solana HCL (Hardware Compatibility List) community tracks optimal hardware configurations across all clients. Validator Setup This guide covers testnet setup, which is the recommended starting point. The same steps apply to mainnet with different cluster URLs and the need for real SOL. Before getting started, make sure that you have all the requirements listed below: Solana Validator Node Hardware Requirements ComponentMinimumRecommendedCPU12 cores / 24 threads, 2.8 GHz baseAMD EPYC 7543 or Intel Xeon Gold (32 cores, 3.0+ GHz)RAM256 GB DDR4 ECC512 GB DDR4 ECCAccounts NVMePCIe Gen3 x4, 1 TB+, high TBWSamsung 970/980 Pro 2 TBLedger NVMe1 TB+, separate from accounts disk2 TB enterprise NVMe (separate drive)Snapshots500 GB+ NVMe or SATA SSDCan share with OS diskNetwork1 Gbps symmetric10 Gbps unmeteredOSUbuntu 24.04 LTSUbuntu 24.04 LTS (bare metal; no Docker/VMs)IPStatic public IPDedicated public IP, no NAT Step-by-step validator setup Configure system limits Solana validators open a very large number of file descriptors. The OS default limit must be raised before the validator will function correctly. # Raise file descriptor and memory lock limits sudo bash -c "cat > /etc/security/limits.d/90-solana-nofiles.conf <<EOF * - nofile 1000000 * - memlock 2000000 EOF" # Tune kernel networking for UDP throughput sudo bash -c "cat >> /etc/sysctl.d/20-solana-udp-buffers.conf <<EOF net.core.rmem_default = 134217728 net.core.rmem_max = 134217728 net.core.wmem_default = 134217728 net.core.wmem_max = 134217728 EOF" sudo sysctl -p /etc/sysctl.d/20-solana-udp-buffers.conf Log out and back in for the file descriptor limits to take effect. Install Agave CLI The official installer fetches the latest stable release. Check github.com/anza-xyz/agave/releases for the current stable version before running. # Install the Agave release sh -c "$(curl -sSfL <https://release.anza.xyz/stable/install>)" # Add to PATH (add this to ~/.bashrc for persistence) export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH" # Verify install solana --version agave-validator --version Generate keypairs A validator requires three keypairs: an identity keypair (your validator's public ID), a vote account keypair, and an authorized withdrawer keypair. The withdrawer keypair should be generated on an air-gapped machine and stored offline, if you lose it, you permanently lose control of your vote account. # 1. Validator identity : used for gossip, TPU, and TVU identification solana-keygen new -o ~/validator-keypair.json # 2. Vote account : tracks your validator's votes on-chain solana-keygen new -o ~/vote-account-keypair.json # 3. Authorized withdrawer : GENERATE ON AIR-GAPPED MACHINE, STORE OFFLINE solana-keygen new -o ~/authorized-withdrawer-keypair.json # Set default CLI keypair and cluster solana config set --keypair ~/validator-keypair.json solana config set --url <https://api.testnet.solana.com> Create the vote account on-chain The vote account is an on-chain account that records your validator's votes and accumulates staking rewards. Creating it requires a small SOL deposit for rent-exemption (0.02685864 SOL). On testnet you can airdrop SOL; on mainnet you must acquire and transfer SOL. # Airdrop SOL for testnet solana airdrop 1 # Create the vote account (-ut flag = use testnet cluster) solana create-vote-account -ut \\\\ --fee-payer ~/validator-keypair.json \\\\ ~/vote-account-keypair.json \\\\ ~/validator-keypair.json \\\\ ~/authorized-withdrawer-keypair.json # CRITICAL : Store authorized-withdrawer-keypair.json securely NOW # Move or encrypt it. Never leave it on the server unprotected Mount and prepare storage It is recommended to separate NVMe drives for the accounts database, ledger, and snapshots combining them degrades performance under Solana's write intensity. # Create mount points (adjust to your actual device names) sudo mkdir -p /mnt/ledger /mnt/accounts /mnt/snapshots # Format (one-time, destroys data on device) sudo mkfs.ext4 /dev/nvme1n1 # ledger disk sudo mkfs.ext4 /dev/nvme2n1 # accounts disk # Add to /etc/fstab for persistent mount on reboot # UUID=$(blkid -s UUID -o value /dev/nvme1n1) # Set permissions sudo chown -R solana:solana /mnt/ledger /mnt/accounts /mnt/snapshots Start the validator The startup command passes all configuration as flags. For a production system, wrap this in a systemd service file. agave-validator \\\\ --identity ~/validator-keypair.json \\\\ --vote-account ~/vote-account-keypair.json \\\\ --ledger /mnt/ledger \\\\ --accounts /mnt/accounts \\\\ --snapshots /mnt/snapshots \\\\ # Cluster entry points : bootstrap peers for gossip --entrypoint entrypoint.testnet.solana.com:8001 \\\\ --entrypoint entrypoint2.testnet.solana.com:8001 \\\\ --entrypoint entrypoint3.testnet.solana.com:8001 \\\\ # Known validators : only trust snapshots from these nodes at startup --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \\\\ --known-validator dDzy5SR3AXdYWVqbDEkVFdvSPCtS9ihF5kJkHCtXoFs \\\\ --only-known-rpc \\\\ # Dynamic port range for gossip, turbine, repair, TPU --dynamic-port-range 8000-8020 \\\\ # Bind RPC locally only (don't expose public RPC on a voting validator) --rpc-port 8899 \\\\ --rpc-bind-address 127.0.0.1 \\\\ # Snapshot intervals (in slots; 1 slot ≈ 400ms) --full-snapshot-interval-slots 25000 \\\\ --incremental-snapshot-interval-slots 100 \\\\ --maximum-full-snapshots-to-retain 2 \\\\ --maximum-incremental-snapshots-to-retain 4 \\\\ # Log output : pipe to logrotate in production --log ~/validator.log \\\\ # Expected genesis hash for testnet : prevents connecting to wrong cluster --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY Verify the validator is connected Check that your validator has registered with the gossip network. # Get your validator's pubkey solana-keygen pubkey ~/validator-keypair.json # Confirm it appears in the gossip network solana gossip | grep <YOUR_PUBKEY> # Check current sync status solana catchup <YOUR_PUBKEY> --url <https://api.testnet.solana.com> # Monitor vote account and skip rate solana vote-account ~/vote-account-keypair.json Monitor your validator's health on community dashboards solanabeach.io: skip rates, uptime, vote distances solanahcl.org: hardware compatibility benchmarks Solana RPC Node An RPC node is a non-voting validator. It runs the same Agave software as a validator, maintains a full or partial copy of the ledger, and tracks the live cluster state but it does not hold a funded vote account and therefore does not participate in consensus. It is the interface layer between your application and the Solana network. It exposes the JSON-RPC API that dApps, wallets, indexers, and bots use to read chain state, submit transactions, and subscribe to real-time events. The JSON-RPC surface covers everything an application needs: account reads (getAccountInfo,  getBalance, getMultipleAccounts), program account scans (getProgramAccounts), transaction history (getTransaction, getSignaturesForAddress), block and slot data, and transaction submission via sendTransactionwhich does not execute the transaction locally but forwards it toward the current leader via Gulf Stream. WebSocket subscriptions (accountSubscribe,  logsSubscribe) open a persistent connection and push state changes as they happen, without polling and the notoriously resource intensive getProgramAccounts. Commitment levels: Every Solana RPC call accepts an optional commitment parameter processed : the highest slot the node has seen, possibly not yet confirmed. confirmed : has a supermajority of validator votes. finalized : rooted, will never be rolled back. Applications that display balances typically use confirmed Applications that write state should prefer finalized Unlike a validator, an RPC node has to serve external traffic, potentially thousands of concurrent requests while simultaneously keeping pace with the network. That combination drives hardware requirements significantly higher than a standard validator. ComponentMinimumRecommendedCPU12 cores / 24 threads16–24 cores (AMD EPYC 7xx3)RAM256 GB DDR4512 GB DDR4 ECCAccounts NVMe1 TB+ PCIe Gen32 TB+ enterprise NVMeLedger NVMe1 TB+10 TB+ for archival historyNetwork1 Gbps5–10 Gbps (high outbound)OSUbuntu 24.04 LTSUbuntu 24.04 LTS bare metal 📖 The official Agave docs specify 512 GB RAM for RPC nodes with all account indexes enabled, compared to 256 GB for a standard validator. This is because accounts and index structures must remain memory-resident for fast getAccountInfo responses. Beyond hardware, operating an RPC node means managing snapshot syncing from genesis (a multi-hour process), coordinating Agave version upgrades before each network restart, monitoring disk growth on the ledger volume, and tuning OS-level parameters for UDP and file descriptor limits. For a team whose core competency is building products, this is substantial ongoing operational cost before a single API call is served. Chainstack's managed RPC infrastructure removes that operational layer entirely. Instead of provisioning bare-metal servers, syncing from snapshots, and maintaining uptime, you get a production-ready endpoint immediately with the performance characteristics of dedicated infrastructure. Pricing is based on Request Units (RU) a standardised measure of compute cost per RPC method. This means you pay for actual compute consumed rather than a flat request count. See current pricing at chainstack.com/pricing. To get an endpoint, sign up at Chainstack, create a project, deploy a Solana mainnet node, and copy the HTTPS and WSS endpoint URLs from the dashboard. The example below uses those endpoints directly. No other configuration needed. Using the RPC API with Chainstack import { createSolanaRpc, createSolanaRpcSubscriptions, address } from "@solana/web3.js"; // Get your endpoint at <https://chainstack.com/build-better-with-solana> const rpc = createSolanaRpc("<https://solana-mainnet.core.chainstack.com/YOUR_KEY>"); const ws = createSolanaRpcSubscriptions("wss://solana-mainnet.core.chainstack.com/YOUR_KEY"); // Read : account balance at confirmed commitment // Use "confirmed" for display const { value: lamports } = await rpc .getBalance(address("YourPubkey"), { commitment: "confirmed" }) .send(); console.log(`Balance: ${lamports / 1e9} SOL`); // Read: full transaction history const sigs = await rpc .getSignaturesForAddress(address("YourPubkey"), { limit: 10 }) .send(); // Subscribe : real-time account changes via WebSocket // Fires on every lamport or data change. No polling required const sub = await ws.accountNotifications(address("ProgramStateAccount")); for await (const update of sub) { console.log("Account changed", update.value.lamports); } // Submit : sendTransaction forwards to the current leader // Use "finalized" commitment when you need to confirm the tx is irreversible const sig = await rpc.sendTransaction(signedTx, { encoding: "base64" }).send(); Geyser plugin system JSON-RPC works well for request-response patterns: query an account, fetch a transaction. But some applications need to react to every state change as it happens: a DEX bot tracking every tick of a price feed, a liquidation engine watching collateral ratios, a block explorer indexing every transaction. Polling JSON-RPC at high frequency to approximate this is inefficient and puts heavy load on the RPC node itself. getProgramAccounts scans gigabytes of account data on every call. The solution is the Geyser plugin interface, a Rust plugin system built into the Agave validator. Instead of polling, Geyser pushes every state change directly to an external data store the moment it happens inside the validator process. The plugin implements four callbacks: CallbackWhen it firesWhat it enablesupdate_accountEvery account lamport, data, or owner changeReal-time price feeds, position monitors, liquidation triggersnotify_transactionEvery processed transactionTransaction indexing, analytics pipelines, audit trailsupdate_slot_statusEvery Processed → Confirmed → Finalized transitionCommitment tracking, confirmed-state event systemsnotify_block_metadataEach new blockBlock-level indexing, explorer backends The most widely deployed Geyser plugin is Yellowstone gRPC, which exposes all four event streams over a gRPC connection with Protobuf schemas. Clients subscribe to exactly the data they need, a specific account, all transactions matching a program, all slot status changes and receive a filtered stream with far lower overhead than polling. Chainstack's Yellowstone gRPC Geyser Plugin runs this as a managed service, with Jito ShredStream integration so blocks arrive at the plugin before they are fully propagated to the rest of the network for ultra-low block latency. For teams who need raw Geyser access without provisioning and operating their own Geyser-enabled RPC node, this is the direct path. Solana Trader Node A trader node is validator software, Agave or Jito-Solana, configured and deployed specifically to minimize the time between deciding to submit a transaction and that transaction landing in a confirmed block. It does not vote, does not serve RPC queries, and typically does not maintain full ledger history. Its entire purpose is transaction submission latency. This matters in environments where multiple competing actors want to land the same transaction in the same block: liquidations, arbitrage, NFT mints, and any strategy where being one block ahead of a competitor is worth money. Solana Trader Node Hardware Requirements ComponentMinimumRecommendedCPU8 cores, high single-thread clockAMD Ryzen 9 7950X or Intel Core i9-14900KRAM128 GB DDR4256 GB+ ECCNVMe Storage1 TB enterprise NVMe2 TB Samsung PM9A3 or Micron 7450 ProNetwork1 Gbps10 Gbps+ with direct IX peeringClock syncStandard NTPPTP or GPS-disciplined NTPColocationRegional datacenterEquinix DA11, AM3, or TY2 Self-hosting gives you full control over software versions, configuration, and hardware selection. This matters if you are running custom validator software (e.g., Jito-Solana), need specific kernel or network stack tuning, or have regulatory requirements around data residency. Managed infrastructure reduces time-to-deployment significantly. For teams whose core competency is not infrastructure operations, the DevOps overhead of self-hosting a validator or RPC node on mainnet-beta is substantial. Snapshot management alone, which involves downloading large state snapshots during node restarts, a process that can take hours, is a frequently underestimated operational burden. Running a trader node requires an extensive setup and consistent service, making sure that your setup is resistant to outages caused by electricity, flooding, theft etc in addition to performance considerations. An easier solution is to run a trader node using Chainstack. Chainstack's Solana Trader Node service combines direct TPU submission with Warp transactions, a propagation layer powered by bloXroute, a specialist in high-speed blockchain transaction propagation. Warp transactions bypass standard gossip propagation and reach validator nodes through bloXroute's private relay network, achieving up to 99% landing rates and confirming 40% of transactions within 2 blocks at normal priority fees, based on internal benchmark conditions. Switching from a standard RPC endpoint to a Chainstack Trader Node endpoint requires changing one URL in your configuration. No code changes, no custom infrastructure. Try Solana Trader Node → Choosing the right Solana node for your workload Different Solana workloads require different RPC capabilities. Below are common application types and the infrastructure setup that fits them best. MVP / Startup Early-stage projects can start with Chainstack’s free Solana RPC endpoint. It provides a geo-balanced endpoint with no credit card required. The managed infrastructure handles rate limits, geographic routing, and uptime so teams can focus on building their product instead of running nodes. const { Connection } = require("@solana/web3.js"); const connection = new Connection( "YOUR_CHAINSTACK_ENDPOINT", { commitment: "confirmed" } ); const slot = await connection.getSlot(); console.log("Current slot:", slot); Wallet Backend Wallet backends (similar to apps like Phantom Wallet or Backpack Wallet) require fast balance reads, token account lookups, and transaction history queries. Using a dedicated Solana RPC endpoint with WebSocket support ensures reliable performance for high-frequency requests and real-time updates. For individual account queries, use the getAccountInfo RPC method. Fetch all SPL token accounts for a wallet owner in a single call: async function fetchSingleAccount() { const connection = new Connection('YOUR_CHAINSTACK_ENDPOINT'); const publicKey = new PublicKey('Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz'); const accountInfo = await connection.getAccountInfo(publicKey, 'jsonParsed'); console.log(accountInfo); } fetchSingleAccount().catch(console.error); When your backend needs data from multiple accounts at once, for e.g., wallet dashboards, leaderboards, or batch processinggetMultipleAccounts is more efficient. It reduces network overhead by fetching multiple accounts in a single request: async function fetchMultipleAccounts() { const connection = new Connection('YOUR_CHAINSTACK_ENDPOINT'); const publicKeys = [ new PublicKey('Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz'), new PublicKey('EAaijviraKWCWsVZtiZ5thhXoyoB5RP3HH1ZiLeLDcuv') ]; const accountsInfo = await connection.getMultipleAccountsInfo(publicKeys, 'jsonParsed'); console.log(accountsInfo); } fetchMultipleAccounts().catch(console.error); To learn more: https://docs.chainstack.com/docs/solana-getaccountinfo-getmultipleaccounts NFT Marketplace NFT marketplaces such as Magic Eden or Tensor run heavy ownership queries and real-time mint monitoring. Dedicated Solana nodes can be provisioned quickly using Chainstack’s infrastructure, allowing applications to handle high traffic without shared-resource rate limits. Transfer an SPL token (or NFT) with automatic ATA creation for the recipient: import { Connection, Keypair, PublicKey } from "@solana/web3.js"; import { getOrCreateAssociatedTokenAccount, transfer } from "@solana/spl-token"; const connection = new Connection(process.env.SOLANA_RPC!); const sender = Keypair.fromSecretKey(/* your key */); const mint = new PublicKey("MINT_ADDRESS"); const dest = new PublicKey("RECIPIENT_WALLET"); // Creates the ATA if it doesn't exist yet const destATA = await getOrCreateAssociatedTokenAccount( connection, sender, mint, dest ); await transfer( connection, sender, senderATA.address, destATA.address, sender, 1 // amount in smallest unit (1 for NFTs) ); Step-by-step guide for sending SPL tokens: SPL token transfers Best practices for making transfers more robust and fault-tolerant: Enhancing SPL transfers with retry logic DeFi Protocol Protocols like Jupiter Exchange and Orca require high-availability state queries and reliable transaction relay. Deploying RPC nodes across multiple regions reduces latency for global users. Chainstack’s infrastructure spans 12 data centers across North America, Europe, and Asia-Pacific, enabling region-optimized deployments. Fetch recent priority fees scoped to your program accounts and apply a multiplier for a competitive bid: import requests, statistics RPC = "YOUR_CHAINSTACK_ENDPOINT" JUPITER_PROGRAM = "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4" # Fetch priority fee data from the last 150 blocks response = requests.post(RPC, json={ "jsonrpc": "2.0", "id": 1, "method": "getRecentPrioritizationFees", "params": [[JUPITER_PROGRAM]] }) fees = [f["prioritizationFee"] for f in response.json()["result"]] # Multiply median by 1.25 to stay ahead in the block queue multiplier = 1.25 priority_fee = int(statistics.median(fees) * multiplier) print(f"Priority fee: {priority_fee} micro-lamports") For maximum throughput, separate read and write connections: const writeConn = new Connection("YOUR_CHAINSTACK_TRADER_ENDPOINT"); const readConn = new Connection("YOUR_CHAINSTACK_RPC_ENDPOINT"); // Reads const balance = await readConn.getBalance(wallet.publicKey); // Writes const sig = await writeConn.sendRawTransaction(tx.serialize()); DeFi protocols often interact with DEXs like Raydium. Using their SDKs, you can perform token swaps programmatically while leveraging your optimized RPC setup for reliability. See Raydium SDK token swaps for detailed guidance. Real-Time Data Pipeline Applications that depend on live blockchain data, such as trading systems, analytics platforms, and monitoring tools benefit from streaming data directly from validator events instead of polling JSON-RPC endpoints. With the Yellowstone gRPC Geyser Plugin, account updates, transactions, and slot status changes are streamed to your infrastructure in real time using gRPC with Protobuf schemas. This allows systems to react to on-chain activity the moment it occurs inside the validator. When combined with Jito ShredStream, block data can arrive before full network propagation, giving latency-sensitive applications an additional edge. const { default: Client } = require("@triton-one/yellowstone-grpc"); const ENDPOINT = "CHAINSTACK_GEYSER_URL"; const TOKEN = "CHAINSTACK_GEYSER_TOKEN"; const DEX_PROGRAMS = [ "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P", "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8", "whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc", ]; async function main() { const client = new Client(ENDPOINT, TOKEN); const stream = await client.subscribe(); stream.write({ transactions: { dexFilter: { accountInclude: DEX_PROGRAMS, vote: false, failed: false, } }, commitment: 1 // CONFIRMED }); stream.on("data", (update) => { if (update.transaction) handleTx(update.transaction); }); } main(); This setup allows you to monitor programs in real time. For a complete guide to implementing this in Node.js, see Program listener via Geyser + Yellowstone gRPC Liquidation Bot Liquidation bots prioritize ultra-low latency. Typical setups include: A trader node located in the validator leader’s region Bundle submission through Jito Labs for atomic execution Dynamic priority fees calculated from adjacent block data Leader-schedule-aware routing so transactions reach the correct TPU port before the slot begins This configuration maximizes the chance of winning liquidation opportunities. Calculate competitive priority fees by analysing transactions in the same block slot: const connection = new Connection("YOUR_CHAINSTACK_ENDPOINT"); const slot = await connection.getSlot("confirmed"); const block = await connection.getBlock(slot, { maxSupportedTransactionVersion: 0, rewards: false, }); const fees = block.transactions .map(tx => { const cu = tx.meta?.computeUnitsConsumed ?? 0; const fee = tx.meta?.fee ?? 0; return cu > 0 ? Math.floor((fee * 1_000_000) / cu) : 0; }) .filter(f => f > 0) .sort((a, b) => a - b); // Use the 75th percentile as your bid const p75 = fees[Math.floor(fees.length * 0.75)]; console.log("Competitive priority fee:", p75, "micro-lamports/CU"); For more details on this methodology, see Analyzing adjacent transactions for priority fees and Priority fees for faster transactions Arbitrage / MEV Arbitrage strategies on Solana typically involve multi-leg atomic execution — if one leg fails, the entire bundle reverts. This requires Jito's block engine for sealed-bid bundle submission, combined with leader-schedule-aware routing so transactions arrive at the correct TPU port before the slot begins. Chainstack Solana Trader Node with Jito bundle support. Switch with a single URL change. No custom integration required. Archive to Genesis included for backtesting strategies. Eg: Detect new Pump.fun token mints via Geyser, the fastest path to new token discovery: PUMP_PROGRAM = "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P" CREATE_DISCRIMINATOR = b"\\x18\\xad\\x99\\x4e\\xa1\\x07\\x00\\x00" # first 8 bytes subscribe_request = { "transactions": { "pump": { "accountInclude": [PUMP_PROGRAM], "vote": False, "failed": False, } }, "commitment": "CONFIRMED", } async for update in stub.Subscribe([subscribe_request]): tx = update.transaction for ix in tx.transaction.message.instructions: if ix.data[:8] == CREATE_DISCRIMINATOR: token_info = decode_token_info(ix.data[8:]) print("New mint:", token_info.mint, token_info.symbol) Geyser streaming: for fastest detection, eliminating polling lag. Trader Node access: for direct TPU submission, bypassing the gossip network. Archive access to Genesis: for backtesting strategies on historical token activity. For full guide, see Creating a Pump.fun trading bot and Pump.fun mint listener via Geyser to implement a real-time arbitrage/MEV pipeline. Agentic Micro-payments Autonomous agents can pay for API access per request using on-chain micro transactions. With Solana’s low fees and fast finality, an agent can attach a payment to each call instead of relying on API keys or subscriptions. RPC latency and reliability directly affect the request → payment → retry cycle. Using a dedicated Chainstack endpoint ensures consistent settlement for automated clients such as trading bots, schedulers, or data collectors. Using the x402 Express middleware with a Chainstack Solana RPC endpoint allows servers to accept on-chain payments seamlessly and AI agents can automatically pay per request using the x402-fetch helper: const wallet = Keypair.fromSecretKey( Buffer.from(process.env.AGENT_PRIVATE_KEY, "base64") ); const fetchWithPayment = wrapFetchWithPayment(fetch, wallet, { network: "solana-devnet", rpcUrl: "YOUR_CHAINSTACK_ENDPOINT" }); const res = await fetchWithPayment("https://api.example.com/paid-endpoint"); const data = await res.json(); console.log("Agent received:", data); Combine x402 with a Telegram bot or scheduled tasks to fetch premium data automatically. Each payment step is settled through Chainstack’s RPC endpoint, so the reliability and low latency of the node directly impacts how fast the agent receives data. For full guidance and implementation: Read the x402 on Solana developer guide for step-by-step setup Learn about the x402 protocol architecture and payment flow for AI agents to understand the underlying design Migrating from Another Provider Switching RPC providers only takes minutes. Chainstack endpoints are fully compatible with standard Solana JSON-RPC and WebSocket interfaces, meaning most migrations require only a URL change. For example, teams moving from Helius getTokenAccounts can switch to the standard getProgramAccounts method. import requests url = "YOUR_CHAINSTACK_RPC" TOKEN_PROGRAM = "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" MINT_ADDRESS = "ATLASXmbPQxBUYbxPsV97usA3fPQYEqzQBUHgiFCUsXx" # Standard replacement for Helius getTokenAccounts response = requests.post(url, json={ "jsonrpc": "2.0", "id": 1, "method": "getProgramAccounts", "params": [ TOKEN_PROGRAM, { "dataSlice": { "offset": 0, "length": 0 }, "filters": [ { "dataSize": 165 }, { "memcmp": { "offset": 0, "bytes": MINT_ADDRESS } } ] } ] }) holders = response.json()["result"] print(f"Total holders: {len(holders)}") For teams migrating from Syndica, the swap is a single line: // Before Syndica const connection = new Connection("<https://solana-api.syndica.io/>..."); // After Chainstack no other changes required const connection = new Connection("YOUR_CHAINSTACK_ENDPOINT"); Refer to the step-by-step guides for smooth transitions with minimal disruption: Syndica → Chainstack: Migrating from Syndica to Chainstack Helius → Chainstack: Migrating from Helius getTokenAccounts to standard RPC Staking Provider Staking platforms such as Sol Blaze and Marinade Finance operate validators as core infrastructure. Many validators run enhanced clients such as the Jito-modified Solana client to capture additional MEV tip revenue alongside staking rewards. See the validator setup guide above and the hardware requirements section. Enterprise / Institutional Institutional integrations typically require: Service-level agreements (SLAs) Dedicated infrastructure Enterprise support Chainstack’s enterprise plans provide dedicated nodes, global deployments, and uptime commitments above 99.99%. Learn more: Chainstack Enterprise. ❓ Not sure which tier you need? Start on the free Global Node. It covers most development and early-production workloads. When you hit rate limits or need dedicated capacity, Bolt provisions a dedicated node the same day. No migration required, same endpoint format. Developer tools for Solana node infrastructure If you're building on Solana, these are the core infrastructure tools you'll likely need to run and scale your application. SDKs & Frameworks @solana/web3.js v2: The canonical TypeScript library with a fully tree-shakeable, functional API. Start here for all RPC interactions, transaction building, and keypair management. Anchor: The dominant Solana smart contract framework. Generates IDL files that power type-safe TypeScript clients. Used by Serum, Mango, MarginFi, and most major DeFi protocols. solana-client (Rust): Lower overhead than JavaScript for high-frequency applications. Essential for bots running hundreds of RPC calls per second. Solders (Python): Python bindings for the Solana Rust SDK. Widely used for data pipelines, analytics scripts, and research-oriented bot development. MEV & Transaction Infrastructure Jito Block Engine: Atomic bundle submission. ~40–45% of stake runs Jito validators. Endpoints in NY, Amsterdam, Tokyo, Frankfurt, Salt Lake City. The standard for competitive MEV on Solana. Yellowstone gRPC: High-performance Solana account and transaction streaming. 10× lower overhead vs WebSocket JSON-RPC at scale. Built by Triton One. Lite-RPC: A lightweight transaction routing proxy by Blockworks Foundation. Routes transactions directly to the upcoming leader's TPU port. Managed RPC Providers Chainstack: Global deployment, dedicated nodes, and trader node infrastructure. Helius: High-performance Solana RPC with enhanced APIs and webhooks. QuickNode: Scalable multi-chain RPC infrastructure with low-latency endpoints. Monitoring & Observability Solscan: Transaction debugging, account inspection, program analytics, and network-wide TPS dashboards. Solana Compass: Validator distribution maps by datacenter and ASN, stake concentration metrics, epoch-level reward data. Jito MEV Explorer: Bundle submission history, tip distributions, and block-level MEV data. Solana Beach: Network overview, validator performance statistics, and cluster health monitoring. Conclusion Solana's performance model creates genuine infrastructure differentiation that has direct business consequences. The two protocol roles (validator and RPC) plus the trader-optimized deployment pattern are purpose-built for different workload needs. Running the wrong node type for your workload produces results that look like software problems but are actually infrastructure mismatches. Validators secure the network and earn staking rewards, but they require significant hardware, uptime, and operational discipline. RPC nodes act as the application serving layer, handling high query throughput and keeping account state memory-resident for fast responses. For latency-sensitive use cases, trader nodes focus on the fastest possible transaction submission to the current leader. The ecosystem around these node types is now mature and production-ready. Tools like Firedancer improve client diversity and performance, while Jito enables programmable MEV workflows. Managed infrastructure providers such as Chainstack also reduce deployment complexity, allowing teams to select the right node architecture based on workload requirements and scale reliably. 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. Deploy Solana node now → FAQ What Solana node roles should I know? Solana has two protocol-level roles: voting validators and non-voting RPC nodes. “Trader node” is a common low-latency deployment pattern built for faster transaction routing and submission. Validators secure the network and produce blocks, RPC nodes serve blockchain data to applications, and trader nodes optimize transaction submission for ultra-low latency. What does a Solana validator node do? A Solana validator node participates in consensus by validating transactions, producing blocks, and voting on the state of the network. Validators maintain a full ledger, run Agave or compatible clients, and earn staking rewards from delegated SOL. What is a Solana RPC node? A Solana RPC node provides an interface between applications and the Solana network. It exposes the JSON-RPC API used by wallets, dApps, and analytics systems to read blockchain data, submit transactions, and subscribe to real-time events. What is a Solana trader node? A trader node is a Solana node optimized for the fastest possible transaction submission. It is typically used by trading bots, arbitrage systems, and liquidation engines that require minimal latency to land transactions in the current block. Do I need to run my own Solana node? Most developers do not need to run their own infrastructure. Managed RPC providers offer production-ready endpoints that remove the operational overhead of maintaining hardware, syncing the ledger, and handling network upgrades. How much hardware does a Solana node require? Hardware requirements depend on the node type. Validators typically require high-performance CPUs, large NVMe storage, and hundreds of gigabytes of RAM. RPC nodes often require even more memory to keep account indexes in RAM for fast queries. Learn more about Solana from our articles x402 on Solana: Developer Guide to Micro-Payments Best Solana RPC providers for fast and reliable production in 2026 How to get a Solana RPC endpoint in 2026 How to build a Solana trading bot How to improve Solana RPC latency with ShredStream Real-time Solana data: WebSocket subscriptions vs Yellowstone gRPC Geyser #### Solana Python tutorial: Querying and analyzing data for STEPN mints This blog is for people who: Want to learn how to retrieve data from Solana. Want to learn about Metaplex NFTs. Interest in STEPN. To elaborate on that, this article shows you how to query data from a Solana node endpoint for newly minted STEPN shoes, and visualize the retrieved data using Python. The key takeaways: How to query data from Solana using Solana.py. How to identify transactions for NFT minting. Retrieving and decoding metadata for Metaplex NFTs. Retrieving shoe attributes from STEPN server. Data visualization with Python. Prerequisites You can use any Solana node endpoint for this tutorial. However, some endpoints may give you errors for rate restriction or authentication. The sample code is developed and tested with a Chainstack Solana node endpoint—it is highly recommended for the following reasons: No limits on the request rate. Free Solana node endpoint with 3 million free requests. Fast node deployment. Simply follow these steps to deploy a Solana node: Sign up with Chainstack. Deploy a Solana node. Get the deployed node’s endpoint. In this article, an HTTPS endpoint is used. What is STEPN? In case you have never heard about it, STEPN is a popular Web3 game launched in December 2021. The game is developed around the concept of move-to-earn—users earn their native token GST by walking, jogging, or running. GST can be used to purchase power-ups or repair shoes in-game, or simply can be exchanged for other tokens. STEPN was first launched on Solana and quickly became the most anticipated game on the chain. To use STEPN, users must own at least one sneaker. Currently, there are 4 types of shoes available on market: common, uncommon, rare, and epic. The rarer a shoe is, the better its stats are. More details can be found on STEPN’s official website. TL;DR Check the source code for this blog post. You may use a Jupyter notebook to open it locally. You can also simply click the link below to use an online notebook: https://colab.research.google.com/drive/1QeUgfT5tZS-LowamR2i0gfRHQsCmISUK?usp=sharing The first thing to do is fill in the HTTPS endpoint in Fill in your Chainstack Solana endpoint here. Then click Runtime > Run all: Or press this run button to go cell-by-cell. That’s all that's needed. The script takes about 5 minutes to complete. It retrieves data for the past 30 minutes from Solana and plots the data on graphs. When it is done, you should get a list of newly minted shoes: Distribution of shoe types. For example, only 1.82% of the total mints are trainers. Distribution of rarity. Most shoes are common, only 1.82% of them are rare. No epic was minted. More than half of the shoes have been minted for 2 times. Most shoes are between level 5 and level 10.   This is the attribute distribution. Efficiency is probably the most important attribute among the four. However, there is one shoe with 160 lucks, what a lucky shoe. The ultimate developers’ guide Below is a high-level schema of the program. You will be guided step-by-step through this. About Solana.py Solana.py is a python SDK for Solana. It can be installed by running: pip install solana Load an RPC endpoint: from solana.rpc.api import Client http_client = Client("https://api.devnet.solana.com") It does not have official documentation, the developers may use Solana’s official RPC API doc as a reference. Querying STEPN transactions A snippet of the code The first step you need to do is get all transactions related to STEPN. This can be done via with getSignaturesForAddress method. getSignaturesForAddress returns all transaction signatures related to a designated account. For STEPN, the account is STEPNq2UGeGSzCyGVr2nMQAzf8xuejwqebd84wcksCK. The Python code: http_client.get_signatures_for_address("STEPNq2UGeGSzCyGVr2nMQAzf8xuejwqebd84wcksCK",limit=200,before=lastSignature) Which is equivalent to getting all transaction history in Solana explorer: The sample script queries for 200 transactions signatures at a time and pauses for 3 seconds before starting the next round. time.sleep(3) Identify the transactions for shoe minting Not all the transactions associated with address STEPNq2UGeGSzCyGVr2nMQAzf8xuejwqebd84wcksCK are for shoe minting. This account is the main address for STEPN, transactions that go through it include: Receiving SOLs from users for shoe purchasing. Receiving GMT from users for shoe upgrading. Shoe minting. Selling shoes or GST. So the next step, is to filter out the non-relevant transactions. For STEPN, shoes are minted as Metaplex NFT, Metaplex is an NFT standard for Solana. This is a typical transaction for minting shoes. It usually involves the following accounts. And token as output. A minting transaction usually has the following instructions in order: Therefore, to find out which transactions are for NFT minting, all we need to do is identify transactions with the above mentioned information. def getTxDetail(txSignature): Gets the job done. It compares the main accounts and transaction schema and makes sure only minting transactions are passed to next stage. Getting metadata for new shoes Open the Solana explorer and search for any STEPN NFT: example. The metadata and attributes can be found on the page. Most Metaplex NFTs come with these two pieces of information. Metadata is usually standardized and is defined during minting. Attribute varies from token to token, and usually is not defined during minting. For STEPN shoes, the attribute for shoes is retrieved from their API endpoint. The endpoint address is defined in the metadata information. For example for this shoe, its attributes information is hosted on https://api.stepn.com/run/nftjson/103/174075743963. To get the metadata information, we need to find its metadata account. The metadata account is created during the minting transaction, which is always the first transaction in mint account history. Open the minting transaction page. The instruction to define and store metadata is always the third instruction executed. With this piece of knowledge in mind, in the Python code, we use: metadataIdx = txDetail["result"]["transaction"]["message"]["instructions"][2]["accounts"][0] metaDataAddr = txDetail["result"]["transaction"]["message"]["accountKeys"][metadataIdx] To retrieve metadata address. Gets metadata information with: data = http_client.get_account_info(mintObj["metaAddress"]) Then finally decode the information with: unpack_metadata_account(rawdata) If you are wondering how decoding is done, the detailed methodology can be found in The mystery of Solana Metaplex NFT metadata encoding. Give it a read to understand why and how. At this stage, your data should be ready for consumption. You can easily load it into a dataframe and process it. Tips, warnings, errors, and solutions Anyone who wants to customize or reuse the code, here is some advice that may help you along the way. Transaction count Solana network has a very high transaction throughput. There are usually 2-3 thousand transactions per hour that are related to STEPN. This program sends 1 request for every transaction to retrieve its information. The overall request count can be quite significant. For example, to analyze 24 hours' worth of data, 50k requests will be consumed. And it takes about 30 mins to run. Please be mindful of overhead charges. About archive data Solana nodes discard older transaction data to maintain scalability. The older transactions may not be retrievable on a regular Solana node. Transaction rate Many Solana node providers limit the number of requests that they can receive from a user. STEPN server does that too. If an error happens during data querying, pausing between each request may solve the issue. In the Python code, you can define this parameter to fix the duration. The predefined duration is 1.5 seconds, you can gradually increase or decrease it if needed. Other mints One thing to take note of is this sample code is developed based on the current version of STEPN. Since the app is going through continuous development, this program may need modification in the future to make it compatible with a newer version of STEPN. If that happens, feel free to ping me on Twitter/Telegram/Discord. Conclusion This is the end of this tutorial. Hope you will find it useful. Thanks for reading. Happy coding. Cheers. #### Solana Python tutorial: Querying and analyzing data from Raydium This is the second Solana Python tutorial article. You can also have a look at the first one: Solana Python tutorial: Querying and analyzing data for STEPN mints. In this tutorial, we will look into Raydium—one of the most popular decentralized exchanges on Solana. DeFi or decentralized finance is usually regarded as an indispensable part of any blockchain. It allows users to exchange tokens not only within its own ecosystem, but also with tokens on other blockchains, even real fiat currencies. This is the fundamental building block of successful blockchains. But a compromised DeFi system may hurt the ecosystem too. DeFi-related incidents usually cause a loss of millions of US dollars from users. This article equips you with essential knowledge of Solana's DeFi system with one of the most used decentralized exchanges (DEX)– Raydium. By completing this tutorial, you will: Have a good understanding of how automated market maker (AMM) like Raydium works on Solana. Learn about token swap transactions. Become a Python magician 🔮 and a visualization wizard 🧙. Starting from downloading data from a Solana endpoint, to detecting suspicious transactions, you will be guided step-by-step to become a DEX detective. Prerequisites Any Solana node can be used for this tutorial. However, some endpoints may give you errors for rate restriction or authentication. The sample code is developed and tested with a Chainstack Solana node endpoint—it is highly recommended for the following reasons: No limits on the request rate. Free Solana node endpoint with 3 million free requests. Fast node deployment. Simply follow these steps to deploy a Solana node: Sign up with Chainstack. Deploy a Solana node. Get the deployed node’s endpoint. In this tutorial, an HTTPS endpoint is used. About Raydium Raydium is an Automated Market Maker (AMM) exchange. In case you are not familiar with this concept: AMM automates the process of token exchange so users can swap their tokens and NFTs solely on-chain, without relying on a real-world clearing house. Compared with a centralized crypto exchange, an AMM DEX wins in both transparency and performance. Raydium is one of the largest AMM on Solana. According to DefiLlama, it has $218 M TVL at the time of writing (August 2022). TL;DR Here is an online Python script hosted on Google Colab. It is a notebook script—you can either run it in your browser or download the file and run it with a local Jupyter notebook. The first thing you need to do is to install Solana.py and Plotly.py. Also fill in your HTTPS endpoint. To install the package, you need to uncomment the text and press the run button. You can either run the script cell by cell or just simply run all the code at once: The script takes approximately 15 mins to complete. It downloads the most recent 10K transactions on Raydium, filters the failing transactions or the transactions that invoke 0 token exchange, and keeps only the successful ones. Which is about 14% of the total transactions. (This is not a constant number, it changes all the time). The analysis part shows some basic descriptive analysis. For example the most transacted tokens: It is USDC, of course. The top 5 tokens’ transaction volume. And the most active address on Raydium. 20% of transactions are sent from CXT9Kvn6VdhrmzviNfE5dForbA6PGMQK4HtF3NTGaozT? Isn’t that suspicious? Take a closer look at the numbers, even though this address sent the most transactions, it actually has never exchanged any token for itself. It is probably a DEX integrator, or another market maker leveraging on Raydium’s transaction pool. Do a quick search on GitHub, it seems to be an address from sol-farm. You can also list all transactions from suspicious senders: Or identify if suspicious attacks are happening. Have fun with it. That is everything about the Python script. If you are keen to learn how it works or wants to take a step further: To learn how Raydium works. Customizing the script and analyze further with it. Reusing the code in other projects. Keep reading. The ultimate developer’s guide So how does Raydium work (or AMM in general)? Market makers are essentially liquidity providers. Liquidity is a measurement of how fast and easy an asset can be bought or sold. If you find that difficult to understand, just replace the word liquidity with money. Even though liquidity and money are totally different, somehow, they can substitute for each other in many contexts. 🤷‍♀️ An especially important part of AMM is the liquidity pool. Raydium used several liquidity pools since the start. Right now, Raydium uses Liquidity Pool V4 for token swaps: Take a look into that account: You can easily see that a liquidity pool is essential for an account that holds multiple tokens. When a user swap tokens on Raydium, the original tokens are actually deposited into the liquidity pool, and the counter token is withdrawn from the liquidity pool. An illustration on how tokens are exchanged An AMM automatically fixes the exchange rate after each transaction, the exchange rate is calculated based on the number of tokens, and it is always measured in pairs. About a swap transaction Several types of transactions happen around AMM. Includes but is not limited to: Token swap. Liquidity deposit. Yield distribution. In this tutorial, we focus only on token swap transactions. A successful transaction usually involves a token swap between multiple accounts. In Solana, even the same user’s tokens are kept in different accounts. For example, picking a random transaction, the tokens are exchanged between the following accounts: It may seem complicated, but the transaction actually happens between only two parties. Using solana.fm to look at the same transaction: All token swap happens between only Raydium and the user. The user is basically swapping ATLAS from their own account to USDT. The transaction happened in two steps: changing from ATLAS to USDC and then from USDC to USDT. A high-level schema on the code The script takes 6 steps to process data. After step 6, two arrays are obtained. One of them contains simplified transaction—processedTxArr; the other is a normalized array—normalisedTxArr. Their differences will be explained in a later part. Steps 1 and 2 First of all, fill in your RPC endpoint address and import the libraries. Step 3 Step 3 downloads the Raydium data from a Solana node. The sample script downloads 10k transactions, the process takes about 8 mins to complete. A few things to take note of here: The script pulls data from the Raydium AMM program address, not the liquidity pool. The script filters out invalid transactions, and keeps only valid transactions, meaning the transactions with actual token change. Any transactions that fail or with no token exchange are discarded. It is decided by comparing: tx["result"]["meta"]["preTokenBalances"] and tx["result"]["meta"]["postTokenBalances"]. This program sends requests in parallel. To avoid congesting the endpoint, it sleeps for 3 seconds for every 200 requests. You may need to modify these numbers if you want to get more transaction data. One request is consumed for every transaction—valid or invalid. So please keep that in mind to avoid going over the limit.However, with a Chainstack free account, you get 3 million requests. Which shall be sufficient in most cases. It takes 40 hours to use up all 3 million free requests. Step 4 Step 4 is the data “massaging” phase—stripping the unnecessary information, keeping only the essential information. Step 5 Before stage 5, the tokens are labeled as their mint addresses, making them impossible to interpret. Therefore in this step, the tokens are translated from their mint address to the actual token name. The information is pulled from solscan.com. A transaction entry after step 5 Step 6 In step 6, we normalize the transaction data. The data format in processedTxArr keeps every token swap. It is useful for some analysis, for example detecting suspicious transactions; but it is not efficient in some cases. To leverage Python’s powerful data analysis toolkits, the data needs to be normalized. This means every entry contains only one token swap pair, instead of multiple. Some other tips Solana network has a very high transaction throughput. The overall request count can be quite significant. Please be mindful of overhead charges. Solana nodes discard older transaction data to maintain scalability. The older transactions may not be retrievable on a regular Solana node. This sample code is developed based on the current version of Raydium. Since the app is going through continuous development, this program may need modification in the future to make it compatible with a newer version of Raydium. If you need help during the process, feel free to ping me on Twitter/Telegram/Discord. Conclusion This is the end of this tutorial. Hope you will find it useful. Thanks for reading. Happy coding. #### Solana reloaded: Next gen RPCs unleashed Chainstack has always been at the forefront of providing cutting-edge Web3 infrastructure. Today, we're going a step further by enhancing our managed blockchain services. We're thrilled to announce the latest updates to our Solana Global Nodes. As a global hub for Web3 developers, we understand how vital it is to minimize latency, maximize the utilization of historical data, and modernize infrastructure for optimal node performance. Web3 developers, we've heard your needs, and we're ready to deliver. Let’s explore the details! Leading Solana performance with global latency optimization In our pursuit to deliver an unmatched blockchain experience, we have optimized our Solana Global Nodes to ensure top-class global latency performance. As we seize the challenges of a globalized digital era, making sure that you have smooth, fast, and reliable access to our infrastructure, no matter where you are in the world, is a top priority for us. Particularly, we've noticed more demand in Asia. We heard you, and we acted. Today, we're proud to announce that our nodes' performance in Asia is nothing short of exceptional, alleviating prior pains and opening up an era of seamless development and deployment. Whether you're building decentralized applications, issuing new tokens, or maintaining your full node, our enhancements promise to make your journey smoother and more efficient. Global latency optimization is not just a perk for your current operations but a necessity that sets you right for the future, ready to take on more substantial projects and handle bigger data with ease. Benefits of Solana infrastructure modernization Modern times demand modern infrastructure, and at Chainstack, we are perpetually committed to staying ahead of the curve. We’re thrilled to announce that we have completely modernized our Solana infrastructure, outfitted with the latest CPUs, and significantly increased the node capacity. What does this mean for you, the developers and innovators at the frontier of the Web3 world? This infrastructural upgrade ushers in a new era of speed with up to 10x faster getProgramAccounts and getBlock methods. As you navigate the peak traffic times that often come with popular blockchain projects, our upgraded infrastructure ensures that your operations run efficiently and uninterrupted. No more bottlenecking data or slow project execution; instead, you'll experience lightning-fast operations that make for smoother project management and execution. Epochs of waiting are over; with Chainstack and Solana, you have the speed and capacity to shift your focus from managing operations to truly innovating on the blockchain. Exceptional Solana coverage in the USA, Europe, and Singapore As part of our ongoing commitment to deliver unparalleled blockchain services, we've expanded our Solana Global Nodes to offer complete coverage across the USA, Europe, and Singapore. Geography should not be a barrier for brilliant minds looking to shape the future, and at Chainstack, we are making sure it isn't. Whether you're based in the heartbeat of Silicon Valley, the fintech hub of London, or the hyper-connected city-state of Singapore, rest assured that our expanded node coverage will boost your operational performance and reduce latency. This leap echoes our dedication to extending support and creating an inclusive platform for innovators everywhere. No matter where you are, you always have the best of Solana technology within your reach, ready to power your next big idea. Seamless operations with high uptime and reliability on Solana As developers and Web3 pioneers, you understand the unmatched importance of high uptime—every moment your application or platform stalls, you risk losing valuable progress and, even more crucially, user trust. We understand these stakes at Chainstack, and our commitment is reflected in our stringently maintained 99.99% uptime guarantee. This nearly perfect uptime brings an essential layer of confidence and reliability to your operations. Whether you're coding your novel DeFi protocol, launching your NFT project, or maintaining your company's smart contracts, our Solana infrastructure ensures your operations continue without any disruption. What's more, our dynamic and transparent real-time status report keeps you informed about system health at all times. Chainstack's relentless focus on uptime and reliability underscores our goal of creating an infrastructure framework that works for you as hard as you do. With this commitment in hand, you can shift your attention to realize your blockchain goals and bring innovation to a swiftly changing digital world. Introducing Archive node support for Solana historical data A cornerstone of successful project development and decision-making is the ability to understand and analyze previous data patterns. Knowing this, we have incorporated support for historical data into our platform, now readily accessible to all Chainstack Global Nodes users. Using this feature, you can explore key metrics across time, understand past blockchain behaviors, and draw informed conclusions that affect your project's future positively. The use cases are ample: tracking the activity status of your project's wallets, making informed trading decisions based on transaction history, or predicting future trends—all are now within your reach. The accessibility of this historical data entrusts you with the power to make data-driven decisions and foster your project's growth. We're not just providing you with information; we're giving you the knowledge to shape your future in Web3. Exploring the Trader nodes and bloXroute integration on Solana In our mission to enhance your capabilities and give you an edge in the competitive blockchain landscape, we have integrated our new Trader nodes services with bloXroute. This powerful combination promises a significant speed boost, improving your trading average by an impressive 382ms. But what does this mean for you as a developer in the Web3 world? It translates to noticeably faster transactions, reducing the window of price fluctuations during a transaction's execution time. To put it simply, when you execute a trade, you're getting the best price available, providing you with the competitive edge you need in this fast-paced digital economy. The integration also introduces our Marinade mTransaction client, offering superior latency and priority service through stake-weighted QoS (Quality of Service)—ensuring your transactions are faster and more reliable than ever. Transactions submitted through our Solana Trader API utilize the bloXroute Solana BDN (Blockchain Distribution Network), which optimizes transaction speed by reducing latency in shred propagation and routing transactions through the leader via BDN. This setup gives you a 30-50ms reaction time advantage and a 5-30ms speed boost in transaction routing. So, whether you're a DeFi hustler, flash loan arbitrager, or DApp developer, our improved Trader node capabilities, powered by Marinade’s staked node priority and bloXroute’s optimized network, transform your Solana experience. Gain the critical edge needed to succeed in the fast-paced and highly competitive world of Web3. Stay informed with real-time updates using blockSubscribe In a world where real-time data is the key to informed decisions and timely actions, we're proud to introduce support for the blockSubscribe method, one of Solana's most powerful tools. As Web3 developers, we know that keeping your finger on the pulse of the blockchain's heart is vital to the success and efficiency of your programs. With the blockSubscribe method, you can now subscribe to real-time block updates, ensuring you are always in sync with the latest changes in the blockchain's state, allowing you to adapt quickly and make necessary adjustments to your applications. Understanding the importance of blockSubscribe, we have put extra effort into ensuring it is extremely resilient and stable in production environments. This commitment ensures that your applications stay reliable even in the most demanding conditions. This new method promises to add another layer of responsiveness to your apps, making them more efficient and user-friendly. Whether you're monitoring real-time market trends for your DeFi project, tracking the status of your transactions, or ensuring the timely execution of smart contracts, the blockSubscribe method is your trusted ally. At Chainstack, together with Solana, we are dedicated to keeping you updated, efficient, and ready to thrive in the fast-evolving landscapes of the Web3 world. Bringing it all together At Chainstack, we believe that the developers and innovators who engage with decentralized technology are the architects shaping our global digital future. That belief motivates us to continually enhance our Solana services and build an infrastructure framework that empowers you to build, test, and scale. The substantial updates we've introduced, from optimized global latency and historical data support to enhanced node coverage and trading capabilities, cater to the diverse needs of Web3 developers around the globe. They embody our commitment to ensuring that you, irrespective of where you are located, have the powerful tools and dependable platform necessary to excel. Our high-uptime guarantee and the new blockSubscribe method support are both designed to position your applications advantageously in the marketplace and assure their seamless operation. With Chainstack and Solana, you have the edge you need to step into the spotlight on your way to superstardom. Power-boost your project on Chainstack #### Solana Token-2022 metadata: from conventions to state Token-2022 did not introduce new token features. It introduced a new way for tokens to describe themselves. For most of Solana’s history, SPL Token mints were structurally simple and intentionally rigid. Their layouts were fixed, their semantics minimal, and any additional meaning, metadata, rules, or auxiliary state had to live somewhere else. Metadata was one of the first things to be pushed out, formalized through conventions and external programs such as Metaplex. That approach solved coordination, but not discoverability. Nothing in a classic SPL Token mint indicates where its metadata lives. The runtime does not enforce a relationship between a mint and any metadata account. The link exists only because clients, wallets, and programs already know how to derive it. Token-2022 changes this at the data-model level. By introducing extensible mint layouts and Type-Length-Value encoded extensions, Token-2022 allows tokens to declare optional semantics directly inside their own accounts. One of the most important of these extensions is the Metadata Pointer: a field stored in the mint itself that explicitly identifies where the token’s metadata can be found. With this shift, metadata discovery no longer depends on hardcoded derivation rules or mandatory external programs. The mint becomes self-describing, and the relationship between a token and its metadata becomes explicit, inspectable, and forward-compatible. This post explores why the Metadata Pointer exists, what architectural problems it solves compared to convention-based metadata systems, and how Token-2022 moves Solana tokens from implicit assumptions toward explicit on-chain state. What is Token-2022 The original SPL Token program was intentionally minimal. A mint defined supply, decimals, and authorities. Token accounts held balances. The layout of both was fixed, and once an account was created, its structure could not evolve. That simplicity was a strength early on, but it also imposed a hard limit: any new behavior had to live outside the token itself. As Solana matured, tokens were expected to do more than represent balances. They needed fees, hooks, compliance rules, pausing, interest, metadata, grouping, and custom transfer logic. Since the mint layout could not change, each of these features had to be implemented through separate programs, additional accounts, and ecosystem-level conventions. Token-2022 was developed to address this structural limitation. Instead of redefining what a token is, Token-2022 extends how token state can be expressed. It introduces a model where mints and token accounts can include optional, well-scoped extensions alongside their base state. Extensions as Explicit, Optional State At the core of Token-2022 is the idea that token behavior should be declared, not inferred. A token mint or token account still has a base layout, the same fundamental fields that existed before. What changes is that this base state can now be followed by a structured region that holds extension data. Each extension contributes a specific piece of state: transfer rules, fee configuration, metadata references, group membership, or other optional behavior. These extensions are: Explicit: their presence is encoded directly in the account data Optional: only the features you enable are stored Composable: multiple extensions can coexist when compatible Forward-compatible: unknown extensions can be safely ignored Existing Extensions TransferFeeConfig: Includes transfer fee rate info and accompanying authorities to withdraw and set the fee TransferFeeAmount: Stores transfer fees that have been withheld from token transfers and are pending withdrawal. MintCloseAuthority: Adds an optional authority that can permanently close the mint account. ConfidentialTransferMint: Configures a mint for confidential transfers, enabling privacy-preserving token movements. ConfidentialTransferAccount: Holds per-account state required to participate in confidential transfers. DefaultAccountState: Specifies the default state (initialized or frozen) for newly created token accounts. ImmutableOwner: Prevents the token account owner authority from ever being changed. MemoTransfer: Requires all inbound transfers to include a transaction memo. NonTransferable: Marks the mint as non-transferable, preventing tokens from being transferred between accounts. InterestBearingConfig: Enables tokens to accrue interest over time based on a configured rate. CpiGuard: Restricts privileged token operations from being invoked through cross-program invocations (CPI). PermanentDelegate: Assigns a permanent delegate with authority over token operations. NonTransferableAccount: Indicates that a token account belongs to a non-transferable mint. TransferHook: Requires token transfers to invoke an external program that implements a transfer hook interface. TransferHookAccount: Marks a token account as belonging to a mint that enforces transfer hooks. ConfidentialTransferFeeConfig: Configures encrypted transfer fees and the public key used for encryption. ConfidentialTransferFeeAmount: Stores encrypted transfer fees that have been withheld. MetadataPointer: Stores a pointer to another account (or the mint itself) that holds token metadata. TokenMetadata: Stores token metadata directly inside the mint account. GroupPointer: Stores a pointer to another account that holds token group configuration. TokenGroup: Defines group-level configuration for a set of related tokens. GroupMemberPointer: Stores a pointer to another account that holds group membership configuration. TokenGroupMember: Defines group membership information for a specific token. ConfidentialMintBurn: Enables confidential minting and burning of tokens. ScaledUiAmount: Applies a scaling factor to the token’s UI amount representation. Pausable: Allows minting, burning, and transferring of tokens to be paused. PausableAccount: Indicates that a token account belongs to a pausable mint. Note: In this blog we will talk about MetadataPointer and TokenMetadata Why Token-2022 Exists Token-2022 exists because convention does not scale indefinitely. Under the original model, advanced token behavior relied on shared knowledge:which extra accounts to look for, which programs to trust, which derivation rules to apply, and which assumptions held in practice. None of this was visible from the mint itself. Token-2022 shifts that burden into explicit state. Instead of asking clients and programs to know how a token behaves, the mint can now declare its behavior. Tools can inspect the account, see which extensions are present, and reason about the token without relying on ecosystem-wide conventions or hardcoded assumptions. Example: The Metadata Pointer extension that we will learn about in this post is one concrete example of this shift. It doesn’t invent metadata. It changes how metadata is located from convention-based discovery to explicit declaration inside the mint itself. To understand why that matters, it’s important to first understand Token-2022 as an extensibility framework, not as a collection of features. With that foundation in place, we can now examine how metadata fits into this model, and why Solana moved from implicit relationships toward explicit, inspectable state. Example of token creation without metadata attached: spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --decimals 9 Note: the TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb address the program address of token-2022 Metadata Pointer Extension: Making Metadata Location Explicit The Metadata Pointer extension is the simplest possible application of Token-2022’s extensibility model. It does not define metadata, It does not interpret metadata, It only answers one question: Where should metadata for this token be found? Under the original SPL Token model, the mint does not reference its metadata in any way. Clients are expected to derive the metadata account using well-known seeds and a known program ID. This works only because every participant already knows the rules. The Metadata Pointer extension removes that assumption. When enabled, the mint stores a single piece of information: a public key pointing to the account that holds the token’s metadata. That account may be owned by any program, follow any schema, or even be the mint itself. From an architectural perspective, this is a shift from convention-based discovery to explicit declaration. Programs and tools no longer need to guess where metadata lives. They can read the mint account, inspect its extensions, and discover the metadata location directly from on-chain state. Importantly, the Metadata Pointer does not enforce correctness. The runtime does not verify that the pointed account actually contains metadata, nor that it conforms to any standard. The pointer only makes the relationship visible and inspectable. Why it was added The Metadata Pointer solves a structural problem rather than a functional one. It removes hardcoded derivation rules from clients It reduces the number of assumptions required to interpret a token It allows metadata systems to evolve independently It enables metadata to be stored wherever it makes sense for a given use case Crucially, this does not replace existing metadata programs. A pointer can reference a Metaplex metadata account, a custom metadata account, or any future standard. Example: Lets create a new token-2022 and assign it a metadata pointer. You can see how we created a metadata address in the previous blog. spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --decimals 9 \ --metadata-address <METADATA-ADDRESS> And with this command we can see that the newly created token supports the metadata pointer: spl-token display <MINT-ADDRESS> \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb The output should look like that: TokenMetadata Extension: When the Mint Carries the Meaning Metadata Pointer solves discovery by introducing indirection: the mint declares where metadata lives. TokenMetadata is the opposite approach. Instead of pointing somewhere else, the mint can store metadata directly inside its own account data as an extension. There is no separate metadata account to derive, no pointer to resolve, and no external program that must be consulted to retrieve a token’s human-facing fields. From an architectural perspective, TokenMetadata turns metadata from an ecosystem convention into explicit mint state. A Token-2022 mint with the TokenMetadata extension can include fields such as: name symbol URI These are not “runtime fields”. They are still program-defined bytes inside an account. The Solana runtime does not interpret them. But unlike the Metaplex model, the relationship between the token and its metadata is no longer implicit or derived. The metadata is literally part of the mint’s declared state. What This Enables and What It Trades Off TokenMetadata optimizes for simplicity and locality: One account read to fetch both mint parameters and metadata No extra accounts to manage No dependency on external derivation rules But the tradeoff is equally structural: Metadata now shares the mint’s lifecycle and authority model Schemas must remain conservative because they live inside the mint Tooling still needs Token-2022 awareness to decode it This is not a replacement for richer metadata systems. It’s a native baseline: a minimal on-chain description that can be resolved without conventions. TokenMetadata vs Metadata Pointer These two extensions are not redundant. They are complementary primitives: MetadataPointer makes metadata discoverable without assuming where it lives. TokenMetadata makes metadata local by embedding it directly into the mint. Token-2022 doesn’t force a single standard. It provides the ability to express both models explicitly. In practice, you’ll see combinations like: Pointer → Metaplex metadata that will provide compatibility with existing ecosystem Pointer → custom metadata account application-specific semantics Inline TokenMetadata small, native, self-contained metadata Example with this next lines it is possible to create a new token-2022 token and enable the TokenMetadata extension: spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --decimals 9 \ --enable-metadata After that the attachment of the small native metadata looks like that: spl-token initialize-metadata <MINT-ADDRESS> \ "Example Token" \ "EXMPL" \ "https://example.com/metadata.json" \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb and the output is: spl-token display <MINT-ADDRESS> \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb Note: When a Token-2022 mint uses inline metadata via the TokenMetadata extension, it will often also include a MetadataPointer extension that points back to the mint itself. This is intentional. Tooling Reality: Explicit State vs Ecosystem Support Token-2022 makes token semantics explicit on-chain, but explicit state does not automatically imply universal tooling support. At the protocol level, MetadataPointer and TokenMetadata are just bytes in an account owned by the Token-2022 program. The runtime enforces ownership and access, but it does not interpret extensions, nor does it require clients to understand them. As a result, much of today’s tooling still treats Token-2022 mints as generic SPL tokens. Explorers may show the correct owning program while omitting extension data entirely. CLI tools can initialize metadata, but often cannot decode or display it back to the user. This is not a contradiction in the design. It is an expected phase of adoption. Token-2022 intentionally prioritizes backward compatibility. Programs and clients that do not understand extensions must be able to safely ignore them. Full visibility requires extension-aware tooling that explicitly opts into parsing Token-2022’s extensible layouts. In practice, this means that inspecting metadata pointers or inline metadata often requires programmatic clients rather than generic interfaces. The important distinction is this:the data exists, the relationship is explicit, and the semantics are declared on-chain even if the surrounding ecosystem has not yet caught up. Summary Token-2022 represents a shift in how token meaning is expressed on Solana. The original SPL Token model relied heavily on convention. Relationships between a mint and its metadata were not encoded on-chain, but reconstructed by clients that already knew where to look and how to derive it. This worked, but only as long as those assumptions were shared universally. Token-2022 moves those assumptions into explicit state. By introducing extensible mint layouts, tokens can now declare optional semantics directly inside their own accounts. Extensions such as MetadataPointer and TokenMetadata do not change what metadata is, but they change how it is discovered and interpreted. MetadataPointer makes metadata location explicit, replacing convention-based discovery with on-chain declaration. TokenMetadata allows small, native metadata to live directly inside the mint, removing indirection entirely. The pointer and is created is simply resolves to the mint itself, unifying discovery regardless of where metadata is stored. The Solana runtime still does not understand metadata. Nothing is enforced globally. Meaning remains program-defined. What has changed is where that meaning is declared. Token-2022 does not eliminate ecosystem standards like Metaplex. It makes them optional, inspectable, and composable. Tokens no longer depend on shared off-chain knowledge to describe themselves. They can state their semantics explicitly, in their own on-chain data. 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 Where token metadata lives on Solana 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 Token-2022 utility extensions Historically, the SPL token standard was incredibly simple. It did exactly one thing: manage a generic u64 integer. If a protocol needed anything more complex like royalties, KYC whitelists, vesting schedules, or privacy, developers had to write custom wrapper smart contracts. They had to spin up external PDAs, force users to route transactions through proprietary programs, and execute Cross-Program Invocations (CPIs) just to mutate basic state. This fragmented liquidity, broke composability across DeFi, and multiplied smart contract attack vectors. Solana Token-2022 flips this architecture on its head. By pushing custom logic directly into the Mint and the Token Account via Type-Length-Value (TLV) extensions, the asset itself becomes smart. The L1 runtime handles the complexity natively, allowing decentralized exchanges, lending markets, and automated market makers to interact with heavily customized tokens without needing to trust or audit a third-party wrapper contract. But Token-2022 is not just about massive, complex upgrades like Zero-Knowledge proofs. The standard also ships with a suite of lightweight, “utility” primitives designed to solve everyday enterprise, compliance, and UX issues. In this final installment of our Solana Token-2022 series, we are going to close out the toolkit. We will break down the smaller, highly effective extensions that every Solana developer needs in their arsenal: Permanent Delegates, Non-Transferable tokens, Default Account States, and Required Memos. Token-2022 Permanent Delegate Extension In the legacy SPL standard, there is a strict cryptographic boundary: Only the Token Account Owner can transfer or burn the tokens inside their wallet. The Mint Authority only has the power to create new tokens. Once those tokens land in a user’s wallet, the protocol loses all control over them. If you are building a stablecoin and need to comply with OFAC sanctions by clawing back funds from a hacked wallet, you are out of luck. If you are building an automated subscription service and need to deduct tokens every month, you have to force the user to sign a pre-approved delegation transaction which is a massive UX friction point. Token-2022 solves this by introducing the Permanent Delegate extension. This extension allows the token creator to designate a specific public key at the Mint level that has unrestricted, permanent transfer and burn rights over every single token account holding that asset. Hands-on: Permanent Delegate in practice To truly understand how powerful this is, let’s test it live on Devnet. We are going to create a token with a Permanent Delegate, mint it to a user, and then watch the delegate reach in and burn the user’s tokens without their signature. Create Token You enable this extension and specify the delegate address during the initial Mint creation. Once set, the permanent delegate has “God Mode” over the token supply. spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-permanent-delegate https://solscan.io/token/33iQokS7SC7XQ8NgoayfVo3KqU19mYjpW8dHJbgHUfj2?cluster=devnet#extensions We can see the created PermanentDelegate extension for our token. Mint Token To Someone Create token account for someone’s wallet and mint 100 tokens to him. # create token account for someone spl-token create-account <MINT_ADDRESS> --owner <SOME_WALLET> --fee-payer ~/.config/solana/id.json # mint 100 tokens to someone's Token Account spl-token mint <MINT_ADDRESS> 100 <SOME_WALLET_TOKEN_ACCOUNT> https://solscan.io/tx/QNNz9XJk1ccKNTtS96mJsxtbo8766tLsPnX1GWYa5mfx6iXbn2ffBsumcXWVwoztfrWAKjZrSWCMTgSSq9WnMSw?cluster=devnet Burning Tokens With the delegate address Right now, someone holds 100 tokens. In legacy SPL, only this address could touch them. But because we established a Permanent Delegate on our address, we can reach directly into this wallet’s account and burn 50 tokens. spl-token burn <SOMEONE_TOKEN_ACCOUNT> 50 https://solscan.io/tx/6r2iYDVTGdbMGNnCm3jNexeN22nkSUxRXY6vMnRfPC1re7NX11X7KUxM3mhRX18kZRrc8ChLrJ6cdhXtGNrYue8?cluster=devnet The transaction succeeds. The Token-2022 program checks the Mint, sees that We are the Permanent Delegate, bypasses Someone’s wallet ownership authority entirely, and burns the tokens. This primitive is incredibly powerful on its own, but it unlocks a massive architectural design pattern when paired with next extension. Token-2022 Non-Transferable Tokens Extension Sometimes, you need a guarantee that a user cannot sell, trade, or transfer an asset once it lands in their wallet. Historically, developers achieved this using a standard NFT mint to a user and immediately issue a Freeze instruction to lock the token account. This worked, but it was fragile. It required the issuer to maintain freeze authority, pay external protocol fees, and if they ever accidentally unfroze the account, the user could immediately dump the “identity” token on a secondary marketplace. Solana Token-2022 completely replaces this legacy NFT use-case with the Non-Transferable extension. It makes immobility a fundamental law of the Mint itself. The L1 base layer will permanently reject any Transfer instruction involving this token. Hands-on: Non-Transferable tokens in practice To create a Non-Transferable token, you must apply the flag during the initial Mint creation. Once the Mint is initialized, this extension is permanently baked into the asset and cannot be disabled. spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-non-transferable Note: You can mint this token to your users exactly like a normal SPL token. The restriction only applies when they try to send it somewhere else Let’s say some address holds 100 of these tokens and tries to transfer it to another wallet. spl-token transfer 7b7FYYVpa5xgTS3PCHAU6ZBDjD1NbwZcKCqYcMmArj4n 50 L6h2ugreR3oNmKtBCpcsMPSLg3BwLR31fSPB1iU76mp Output The Result: Hard Fail. The transaction will instantly revert at the protocol level with a Transfer is disabled for this mint custom program error. Architecture 1: Native L1 Soulbound Badges When developers hear “Non-Transferable,” they almost exclusively think of 1-of-1 NFTs. For example, issuing an on-chain graduation certificate for a developer bootcamp or a KYC verification badge. By combining the Metadata extension (which we covered here) with 0 Decimals and the Non-Transferable extension, you can mint native, beautifully rendered L1 “Soulbound Badges” without ever touching a third-party standard. Architecture 2: On-Chain Consumables But the real magic happens when you apply the Non-Transferable extension to a Fungible token (for example with 9 decimals) and combine it with the Permanent Delegate we just built previously. This creates the perfect architecture for On-Chain Consumables or Prepaid Credits. Imagine an RPC node provider, a decentralized AI compute network, or an in-game economy. A user buys 1,000 API credits. Because the tokens are Non-Transferable, you guarantee the user cannot create an AMM liquidity pool to dump their unused credits and crash your internal economy. They can only hold them. Because your protocol backend holds the Permanent Delegate key, your server can automatically execute a Burn instruction to destroy tokens directly from the user’s wallet every time they make an API call. The user gets transparent, on-chain accounting of their prepaid credits, and the protocol gets absolute economic security without sacrificing UX. Example spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-permanent-delegate --enable-non-transferable https://solscan.io/token/6k4XgpoJx4WuvPTpfpn4VrHrmtHMdqYSsDY2WZA3QZrf?cluster=devnet#extensions What about manual burning? A common developer assumption is that “non-transferable” means the token is permanently stuck in the user’s wallet forever. This is a massive UX risk what if a user receives a malicious or spam soulbound token and wants to clean up their wallet? Non-transferable does not mean non-burnable. Even though the base layer blocks the Transfer instruction, the Solana Token-2022 program still allows the account owner to execute a standard Burn instruction. Users always retain the ultimate authority to destroy assets in their own wallets to prevent permanent spam. Token-2022 Default Account State Extension If you are building a regulated protocol like an enterprise stablecoin, a real estate RWA (Real World Asset), or a strict KYC ecosystem, you need absolute control over who can hold and move your token. By configuring this extension at the Mint level, you can force the L1 runtime to automatically initialize every single new Token Account in a Frozen state. Users can create their accounts to receive the asset, but they cannot send or receive tokens until your backend server verifies their KYC status and explicitly unfreezes their specific account. Hands-on: Default account state in practice To use this, you must apply the --default-account-state frozen flag during Mint creation. Because you will eventually need to unfreeze compliant accounts, you must also stack the --enable-freeze flag so your protocol retains the Freeze Authority. # Create a compliance-gated Mint spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --default-account-state frozen --enable-freeze Output https://solscan.io/token/CgAAhZTKoeaAPBtXpJ5cfe3XnmgGGVH78Lq8JhFV627F?cluster=devnet#extensions If someone creates an account for this token, it is frozen the millisecond it is initialized. Any incoming or outgoing transfers will revert until your protocol explicitly thaws their account. Lets say that now someone creates his own token account and did not submit all the required data to our backend server, and our automated system accidentally tries to mint to this token account spl-token mint <MINT_ADDRESS> 100 <SOME_TOKEN_ACCOUNT> Output It will fail with “account is frozen“ error. The transaction reverts perfectly at the runtime level. The Token-2022 program recognizes that this account is completely locked. It cannot receive incoming mints or transfers, and it cannot send tokens out. Now lets say that this user submitted all the required data. Our backend verifies the identity and executes a Thaw instruction to unlock her specific Token Account. spl-token thaw <SOME_TOKEN_ACCOUNT> Output https://solscan.io/tx/WpW47gmduBEUkHK78To57NLds7vMzmtCHZqRAFU1KuUYzKAN4SZXkH9bBcqqeXWPU4vYh5w8b2oHjQypRjnWGkN?cluster=devnet Now that this user is legally verified and the account is thawed, Our backend tries the exact same mint command again. spl-token mint <MINT_ADDRESS> 100 <SOME_TOKEN_ACCOUNT> Output The Result: Success. This user receives the 100 tokens, fully compliant with the protocol’s L1 rules. Token-2022 Memo Transfer Extension If you have ever deposited tokens into a centralized exchange (CEX - centralized exchange), you know the panic of forgetting the “Deposit Memo.” Because exchanges use massive, shared omnibus wallets to collect user deposits, they rely on attached text memos to map an incoming L1 transfer to a specific user’s database ID. The Required Memo on Transfer extension solves this at the protocol level. Unlike the previous extensions we discussed, this is an Account Extension, not a Mint extension. It is applied by the owner of the Token Account, not the creator of the token. Hands-on: Memo transfer in practice Let’s say your protocol’s treasury wallet (Alice) wants to ensure that no one can blindly dump tokens into her account without explaining what the transfer is for. Alice simply enables the extension on her specific Token Account. # Alice enforces memos on her own Token Account spl-token enable-required-transfer-memos <ALICE_TOKEN_ACCOUNT_ADDRESS> Output On Explorer https://solscan.io/account/EpBnH3MaJsSRVi7WBGHw9mXCtYTvwWY1NL789fBQXaKK?cluster=devnet Now we see that the Memo is Required, if someone tries to run a standard transfer command to Alice’s account: spl-token transfer <MINT_ADDRESS> 50 <ALICE_TOKEN_ACCOUNT_ADDRESS> Output The Result: Hard Fail. The transaction reverts at the runtime level because the destination account requires a memo, and none was provided. To successfully send tokens to Alice, the sender is now mathematically forced to attach a memo string to the transaction instruction: # The sender must explicitly attach the memo for the transaction to succeed spl-token transfer <MINT_ADDRESS> 50 <ALICE_TOKEN_ACCOUNT_ADDRESS> --with-memo "Invoice payment for Q3 RPC node hosting" Output https://solscan.io/tx/3VGqCo88izrsDm1mYQFTbvi4c5V5CSgSgAhQ5YnDD4RysVBF3yXiFp1qm7kax8Fs46hKhL6LbrMMRAZtyLmbXNP8?cluster=devnet Summary Over the course of this series, we have covered Metadata, Transfer Hooks, Interest-Bearing Mints, Confidential Transfers, and finally, the core Utility Primitives. View all Token-2022 articles → If there is one major takeaway for developers, it is that the this blog’s architecture is no longer just a theory it is the standard. Solana Token-2022 shifts complex, vulnerable logic out of custom smart contracts and pushes it natively into the L1 asset itself. By stacking these extensions, you can build a stablecoin that natively yields interest, shields transfer amounts with Zero-Knowledge proofs, automatically freezes non-compliant accounts, and blocks unknown deposits, all without writing or deploying a single line of Rust. The standard is here. It is time to start building. 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. Start building on Solana → FAQ What are Solana Token-2022 utility extensions? Token-2022 utility extensions are built-in token primitives that add practical controls to SPL tokens, such as permanent delegation, non-transferability, default frozen accounts, and required transfer memos. What is the Permanent Delegate extension in Token-2022? The Permanent Delegate extension lets a designated address permanently transfer or burn tokens from any account holding that mint. It is useful for compliance workflows, clawbacks, and protocol-controlled burn mechanics. What does the Default Account State extension do? The Default Account State extension lets a mint create new token accounts in a predefined state, such as frozen. This is useful for compliance-gated assets where accounts must be approved before they can receive or send tokens. How does the Memo Transfer extension work? The Memo Transfer extension requires incoming transfers to include a memo. It is applied at the token account level and helps protocols or treasury accounts enforce transfer metadata at the runtime level. When should developers use Token-2022 utility extensions? Developers should use them when they need built-in compliance, account controls, or operational safeguards without building custom wrapper contracts. They are especially useful for enterprise assets, gated access, treasury controls, and regulated token flows. Why do Token-2022 utility extensions matter for Solana developers? They move common token logic into the base token standard, which improves composability, reduces custom smart contract risk, and makes advanced token behavior easier to integrate across wallets, DeFi apps, and infrastructure. 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 Token-2022: transfer hooks and fee-on-transfer Solana Token-2022 adds extensibility to SPL tokens, but not all extensibility lives at the same layer. Two features are often discussed together: the fee-on-transfer extension and transfer hooks. Both are triggered during a token transfer, and both influence what happens when value moves between accounts. This similarity is misleading. These features exist at different layers of the system, solve different classes of problems, and are subject to very different execution constraints. Treating them as interchangeable leads to designs that work in theory, pass simulation, and then fail at runtime. In this post, we’ll start with the fee-on-transfer extension, how it works and why it exists. Then move to transfer hooks, and finally compare what is and is not possible with each. Fee-on-transfer extension: Defining token economics When people hear “fee on transfer,” they usually imagine a separate program that runs during a transfer and skims a percentage to a treasury. Token-2022 does it differently. The Fee-on-Transfer extension makes the fee part of the token program’s native transfer logic. In other words, it changes what a “transfer” means for that mint, at the protocol level. What it is A Token-2022 mint can be configured with: a fee rate (basis points), and a maximum fee cap (so big transfers don’t create absurd fees). Once enabled, every transfer of that mint automatically applies the fee inside the Token-2022 program. What actually happens during a transfer Suppose Alice sends Bob 100 tokens and the mint charges a fee. At execution time, Token-2022: calculates the fee from the mint’s fee config, deducts it from the transferred amount, and withholds the fee rather than immediately paying it out to an arbitrary address. That “withheld” detail matters a lot. Where the fees go With transfer fees enabled, the fee amount is tracked in Solana Token-2022 extension state (commonly recorded on the recipient token account via the transfer-fee amount extension). The recipient can’t spend those withheld tokens as part of their normal balance. Later, a withdraw authority (configured on the mint) can withdraw accumulated withheld fees. There’s also a practical mechanism to harvest withheld fees from many token accounts into the mint before withdrawing, which matters when a token has lots of holders. Why this extension exists This extension exists because “transfer tax” is not just extra logic it is token economics: It changes how much value moves in the transfer. It must be deterministic (same inputs → same result). It must be enforced atomically by the token program, without relying on external programs, CPIs, wallets, or simulation quirks. So you can think of it like this: Fee-on-transfer is not a hook.It’s a rule baked into the token program’s definition of a transfer. Example lets set the environment solana config set --url devnet Create two wallets (sender + recipient) and fund them solana-keygen new --no-bip39-passphrase -o ./alice.json solana-keygen new --no-bip39-passphrase -o ./bob.json solana airdrop 1 -k ./alice.json solana airdrop 1 -k ./bob.json Create a Solana Token-2022 mint with transfer fees: Important: spl-token flag names can vary by version. First, confirm what your CLI supports: spl-token create-token --help | grep -i fee Most recent CLIs support enabling fees at mint creation using the flags for: --transfer-fee-basis-points --transfer-fee-maximum-fee set the primary private key solana config set --keypair ./alice.json Example: 1% fee, max fee 5 tokens, 0 decimals (so it’s easy to see): MINT=$(spl-token create-token \ --program-2022 \ --decimals 0 \ --transfer-fee-basis-points 100 \ --transfer-fee-maximum-fee 5 \ | awk '/Creating token/ {print $3}') echo "MINT=$MINT" # Output: # MINT=9ncw8asA7P79w7vJ3XbUFWW4EKy7cSYRVdhp9xjXb9cf On explorer it will look like this: Note: Max fee is set to 5 means that the fee will never take more than 5 tokens create Alice’s token account: ALICE_ATA=$(spl-token create-account $MINT --program-2022 | awk '/Creating account/ {print $3}') echo "ALICE_ATA=$ALICE_ATA" # Output: # ALICE_ATA=J9V83VXc4H1LcCHu6DjxKLn6tkem5Se4ZYiybLnqoG35 On explorer it will look like this: create Bob’s token account # switch to bob solana config set --keypair ./bob.json BOB_ATA=$(spl-token create-account $MINT --program-2022 | awk '/Creating account/ {print $3}') echo "BOB_ATA=$BOB_ATA" # Output: # BOB_ATA=G5DjAMaTSrTajDK3Y9EW1dwSsXz6SUWQdvpu9Ft3CNif # Then switch back to Alice for minting/transferring: solana config set --keypair ./alice.json On explorer it will look like this: After you have both ATAs lets mint and transfer: # Alice mints to herself spl-token mint $MINT 1000 $ALICE_ATA --program-2022 # Alice transfers to Bob spl-token transfer $MINT 100 $BOB_PUBKEY \ --from $ALICE_ATA \ --fund-recipient \ --program-2022 lets check the balance of Bob to see how much he got spl-token balance $MINT \ --owner $BOB_PUBKEY \ --program-2022 # Output: # 99 On explorer it will look like this: Transfer hooks If Fee-on-Transfer is a built-in “tax law” of the token program, a Transfer Hook is a “custom security checkpoint.” It allows a token creator to mandate that an external, custom program must approve every single transfer before it can finalize. What it is The Transfer Hook extension allows a Mint to specify a Program ID that must be called during any transfer. This essentially turns a standard token into a programmable asset. When a transfer is initiated: Solana Token-2022 sees the hook extension on the Mint. It pauses the transfer logic and sends a Cross-Program Invocation (CPI) to your custom program. Your hook program runs its logic and returns either a “Success” or an “Error”. Why this is a game-changer Before Token-2022, if you wanted to enforce custom logic you had to “wrap” the token in a custom contract or “freeze” it and only “unfreeze” it via a proxy program. This destroyed composability, wallets and DEXs didn’t know how to talk to your proxy. Hooks fix this by putting the logic directly into the standard transfer flow. Execution-Time Side Effects A Transfer Hook is Solana Token-2022’s way to run your program during a token transfer. But the key detail is who initiates it: The user does not call your hook program. The Token-2022 program calls it as part of processing a transfer. So instead of “a token transfer plus my callback”, the mental model is: A token transfer is a pipeline, and one stage of that pipeline can invoke your program. What “hooked” actually means When a mint has the transfer-hook extension enabled, Token-2022 stores: the hook program id and a configuration describing extra accounts the hook will need Then, whenever someone transfers that mint, Token-2022 will: validate the transfer perform its internal extension logic invoke the hook program (CPI) with the transfer context This invocation is automatic and deterministic. If the hook fails, the transfer fails. Why hooks exist Transfer hooks are not meant to redefine the economics of the token (that’s what fee-on-transfer is for). Hooks exist for things that are inherently conditional and policy-driven, like: Gating / compliance: allowlist / blocklist KYC / region gating “only transfers to approved destinations” “only transfers above/below a threshold” Runtime enforcement pause transfers based on some on-chain flag rate-limit transfers require “membership” / “badge” / “NFT ownership” to receive The common theme: Note: Hooks let you add policy and stateful side effects to transfers. The most important constraint When your hook runs, it’s not a top-level instruction. It’s running inside the Token-2022 transfer instruction. That means two consequences that matter a lot: 1) No privilege escalation Accounts passed into your hook have fixed privileges (read-only / writable, signer / non-signer). Your program cannot “upgrade” an account’s permissions mid-flight.If Solana Token-2022 passed an account as read-only, your hook cannot treat it as writable. 2) The hook cannot change what the transfer is A hook can: validate reject record perform side effects on explicitly provided accounts But it cannot retroactively redefine the transfer semantics the way a token-program-level extension can. This is exactly why “take a fee in the same token inside the hook” fails in practice. Why hooks cannot implement token-level fees After setting up a hook, the first instinct for many developers is to add a “tax” or “royalty” logic. However, if you try to make your hook move tokens to a treasury during a transfer, you will hit two fundamental architectural walls. 1. The “Read-Only” Wall When the Token-2022 program invokes your hook, it provides the source and destination token accounts. However, for security reasons, these accounts are passed to your hook as read-only. The Constraint: You cannot modify the data or the balance of a read-only account. The Result: Since your hook cannot “write” to the balances, it cannot deduct a fee. 2. The Re-entrancy Lock You might think: “I’ll just issue a CPI (Cross-Program Invocation) from my hook back to Token-2022 to move the 1% fee.” The Constraint: Solana prohibits “re-entrancy.” You cannot call the Token-2022 program to move a token while that same Token-2022 program is currently suspended, waiting for your hook to finish. The Result: The transaction will fail immediately. Note: In next blog post we will write code and see this in practice What is possible with each mechanism The core difference lies in state mutation (writing) versus state validation (reading). Modifying the transfer amount Fee-on-Transfer: Yes. Because this logic lives inside the Token-2022 program, it has the authority to split the transfer amount. If Alice sends 100, the program physically writes 99 to Bob and 1 to a withheld bucket. Transfer Hooks: No. Your hook program is a guest. The accounts it receives are restricted by the caller (Token-2022). To prevent a hook from “stealing” tokens, the runtime passes the source and destination accounts as Read-Only. You can see the 100 tokens, but you cannot change that number to 99. Gating by identity or metadata Fee-on-Transfer: No. This extension is “blind.” It applies the same math to every transfer regardless of who is involved. You cannot say “charge 1% except for these five wallets” using only this extension. Transfer Hooks: Yes. This is the hook’s superpower. Because the hook is a custom program, it can look at a MemberAccount PDA or an external Registry to see if Alice or Bob are authorized. If they aren’t, it returns an error and the whole transfer is aborted. Side-effects in external programs Fee-on-Transfer: No. It does one thing: math. It cannot ping a different program to update a “Points” balance or log a trade on an external leaderboard. Transfer Hooks: Yes. Your hook can be passed writable extra accounts. For example, you could pass a UserStats PDA. Every time a user transfers tokens, your hook could increment a “Total Volume” counter on that PDA. Choosing the correct layer The decision tree is simple: Does it change the math of the transfer? Use Fee-on-Transfer. It is the only way to ensure the fee is deducted atomically and safely at the protocol level. Does it change the permission of the transfer? Use Transfer Hooks. It is the only way to check external state (like a denylist PDA or an NFT) to decide if a transfer should be allowed to happen at all. Summary Solana Token-2022 isn’t just about “more features”, it’s about putting those features at the correct layer of the stack. Fee-on-Transfer handles the the math. It ensures your token economics are immutable, deterministic, and enforced natively. Transfer Hooks handle the the policy. They turn your token into a programmable asset that can react to the world around it. Coming up next: In the next blog post, we’re going to get our hands dirty. We’ll write a real Transfer Hook in Anchor, deploy it, and see exactly how to pair it with a Fee-on-Transfer mint to build a fully regulated token economy. 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 Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution 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 → #### Solana trading infrastructure 2026: MEV, nodes, latency Introduction: why Solana trading infrastructure matters in 2026 In high-frequency trading, the difference between profit and loss is rarely the strategy alone. It is the execution stack the strategy runs on. In 2026, Solana trading infrastructure is increasingly shaped by faster client implementations, lower-latency data propagation, and the path toward much faster finality. That shifts competitive advantage away from generic RPC access and toward the layers below it: packet handling, stake-weighted quality of service, real-time data delivery, and how close your infrastructure is to the next scheduled leader. 🤖 You can also access Chainstack RPC directly from Claude, Cursor, or any MCP-compatible AI agent — no config needed. Learn more. Validator clients in 2026: Agave vs Firedancer For most of Solana's history, the network ran on a single validator client written in Rust. That changed with the arrival of Firedancer, Jump Trading's ground-up C++ reimplementation. The two clients, Agave (the evolved Rust client) and Firedancer, now run in parallel across the validator set, and the implications go well beyond raw throughput numbers. Firedancer is built to remove many of the software bottlenecks that constrained earlier Solana clients. Its architecture separates networking, transaction processing, and block propagation into highly optimized parallel paths, which is why it is widely viewed as a major performance step for the network. Public demonstrations have shown Firedancer exceeding 1M TPS in testing, which is best understood as a signal of where validator performance is heading rather than the throughput every production validator delivers today. More importantly for anyone running production infrastructure, client diversity means a bug or edge case that takes down one client won't halt the network. Validators running Agave keep producing blocks while Firedancer is patched, and vice versa. For institutional liquidity providers where uptime is a hard requirement, this is a structural improvement to the network's reliability guarantees. The hardware requirements that validators operate under, NVMe storage, 10Gbps+ networking, substantial RAM, flow directly into the quality of the nodes traders connect to. A validator running on underpowered hardware struggles to keep up with block production, and that lag shows up as slot lag on your end. The specs aren't abstract infrastructure trivia. They set the floor for what reliable connectivity actually looks like in practice. Breaking the speed barrier: Alpenglow & sub-150ms finality Alpenglow is the consensus upgrade that fundamentally changed what Solana feels like to build on. Previous consensus mechanisms required multiple rounds of vote propagation before a slot could be considered final. Validators would cast votes, wait for those votes to propagate across the network, then wait for confirmation that a supermajority had been reached. Alpenglow collapses that process by optimizing how votes are aggregated and processed, reducing time-to-confidence to under 150ms end-to-end. The practical effect is significant. On-chain central limit order books can now compete meaningfully with centralized exchanges on latency. Liquidation engines and arbitrage strategies that previously required probabilistic assumptions about finality can now operate with near-certainty before acting on the result. Underneath the consensus layer, XDP (eXpress Data Path) has become a standard tool in the competitive validator stack. Most networking code runs in userspace, which means packets travel through the kernel's full network stack before your application ever sees them. XDP short-circuits that.  It runs eBPF programs directly on the network driver, so packets can be inspected and dropped before they go anywhere near the validator process. Under spam conditions, this matters a lot. The validator isn't wasting cycles rejecting garbage. It never receives it in the first place. Solana MEV in 2026: Jito, PBS, and execution control Maximal extractable value (MEV) on Solana has matured considerably. The early landscape was largely about raw speed. Whoever got their transaction to the scheduled leader first won. That dynamic still exists, but the ecosystem has developed more sophisticated mechanisms layered on top of it. Jito's block engine introduced a more structured marketplace for block space, allowing searchers to submit bundles with attached SOL tips to validators. That moved Solana MEV beyond a pure speed race and toward a more explicit market for transaction ordering. In 2026, the better framing is not Ethereum-style PBS alone, but Solana's own evolving execution stack: Jito's block engine, emerging blockspace auction mechanisms (BAM), and application-controlled execution. Together, these systems aim to make block building more programmable, more transparent, and less dependent on brute-force network proximity alone. Application-controlled execution (ACE) addresses the user-protection side of the equation. Rather than leaving users exposed to sandwich attacks, ACE lets dApps define execution constraints at the application level, controlling transaction ordering, slippage bounds, and which actors can interact with specific instruction sequences. Healthy arbitrage still flows through. Predatory MEV that harms end users is structurally harder to execute. Real-time data pipelines: ShredStream and Yellowstone gRPC For bot operators and searchers, three components matter most in the low-latency Solana data and execution path: ShredStream, Yellowstone gRPC, and Warp Transactions. They are related, but they solve different problems. ComponentPrimary roleImprovesDoes not directly improveBest forShredStreamLow-latency block data propagationHow quickly your infrastructure sees new block data as shreds are producedTransaction submission or landing on its ownSearchers, market makers, latency-sensitive monitoringYellowstone gRPCPush-based chain data streamingReal-time delivery of transactions, account updates, slots, and blocks without pollingTransaction routing to the leaderBots, indexers, event-driven trading systemsWarp TransactionsOptimized transaction delivery pathHow quickly sendTransaction reaches the current leaderRead latency, block visibility, or account streamingTrading bots, liquidation systems, multi-step DeFi executionStandard RPC pollingGeneral-purpose node accessBasic read access and compatibilityLow-latency streaming or optimized send pathWallets, dashboards, non-latency-sensitive apps ShredStream gives earlier access to block data than RPC polling by streaming shreds between validators. Yellowstone gRPC delivers real-time chain data without polling, directly from validator memory. Warp Transactions optimize the send path by routing transactions more directly to the leader. 🤔 In practical terms: ShredStream helps you see new information sooner, Yellowstone gRPC helps you process that information more efficiently, and Warp helps you act on it faster. Chainstack trading stack: Trader Nodes and Warp Transactions Solana Trader Nodes Trader Nodes are regionally deployed endpoints tightly bound to a specific location and fine-tuned for low-latency, high-availability trading workloads. The regional deployment matters because Solana's leader schedule is deterministic. Chainstack places nodes close to where block production is concentrated, so your RPC reads and transaction sends don't travel further than they need to. Trader Nodes ship with ShredStream enabled by default, reducing block data propagation delay without requiring additional setup. In practice, the exact latency improvement depends on region, network conditions, and how close your Solana trading infrastructure is to the current or upcoming leader . Yellowstone gRPC is available as an add-on, replacing polling with push-based streaming for transaction and account monitoring. Here's what a minimal subscription looks like against a Chainstack node endpoint: import grpc from generated import geyser_pb2, geyser_pb2_grpc # Proto files are generated by running grpc_tools.protoc against # https://github.com/rpcpool/yellowstone-grpc/tree/master/yellowstone-grpc-proto/proto # Establish authenticated channel to your Chainstack node channel = grpc.secure_channel(     "your-trader-node.chainstack.com:1443",     grpc.ssl_channel_credentials() ) stub = geyser_pb2_grpc.GeyserStub(channel) # Subscribe to transactions touching a specific program request = geyser_pb2.SubscribeRequest(     transactions={         "my_filter": geyser_pb2.SubscribeRequestFilterTransactions(             account_include=["YOUR_PROGRAM_ID"]         )     } ) # Push-based -- your handler fires on every matching transaction for update in stub.Subscribe(request):     process_transaction(update) Built-in geo-redundancy and automatic failover keep bots operational during network spikes rather than dropping connections at exactly the wrong moment. Archive access back to Solana genesis is also included, meaning backtesting runs against the same infrastructure as your live trading setup rather than a separate, potentially inconsistent environment. Warp Transactions Warp Transactions handles the send side of the equation. The standard sendTransaction path gossip your transaction across the network toward the scheduled leader. Warp bypasses that entirely, routing sends directly through bloXroute's relay network to the current leader. The implementation requires nothing from you beyond switching your RPC endpoint. No changes to transaction construction, no tip instructions, no memo fields. Every call routes normally through the Trader Node except sendTransaction, which bloXroute picks up and delivers directly.  The practical result is landing rates of up to 99%, which is most meaningful for multi-program DeFi sequences where a missed transaction doesn't just mean a lost opportunity but a broken execution chain. from solana.rpc.async_api import AsyncClient # Before: standard public RPC, gossip propagation client = AsyncClient("https://api.mainnet-beta.solana.com") # After: Trader Node with Warp enabled # All calls route normally except sendTransaction, # which goes directly to the current leader via bloXroute client = AsyncClient("https://your-trader-node.chainstack.com") # Your existing transaction logic is completely unchanged result = await client.send_transaction(tx, signer) Reads go through a node that's already positioned close to the leader. Sends bypass gossip and arrive directly. The two halves of the execution problem get solved at the same endpoint, without stitching together multiple providers or maintaining relay infrastructure on top of your trading logic. 📖 Learn more about Solana Trader Node and Warp transactions in Chainstack documentation. Try Solana Trader Node → How to build a production trading stack on Solana The simplest way to frame a production setup is three components working together. A regional Trader Node handling your RPC reads, Warp Transactions handling your sends, and your bot co-located in the same region. That combination gets you production-grade execution without writing or maintaining custom propagation infrastructure. What's worth measuring once you're live is slightly different from what most people track. Raw RPC response time is the obvious metric but it's not the one that tells you whether your stack is actually performing. The numbers that matter are landing rate, where anything below 95% should prompt investigation, slot lag between your node and the tip of the chain, and time-to-leader for your sendTransaction calls. Those three together give you a real picture of execution quality rather than just connection speed. Conclusion: Solana is the decentralized Nasdaq Solana in 2026 isn't just fast. It's structurally different from what it was even two years ago. Localized fee markets mean a high-activity event on one program no longer ripples out and spikes costs on your core trading pairs. The infrastructure layer has matured to the point where professional-grade execution is accessible without building and maintaining custom relay infrastructure from scratch. For most teams, the lowest-friction path to that execution environment is pairing Chainstack Trader Nodes with Warp Transactions. You get regional proximity to scheduled leaders, push-based streaming via ShredStream and Yellowstone gRPC, and direct-to-leader transaction delivery through bloXroute, all through a single endpoint with no custom setup required. The full stack looks like this. Firedancer or Agave at the validator layer, Alpenglow bringing finality under 150ms, Jito and PBS creating a transparent and structured block space market, a Chainstack Trader Node handling reads and streaming, and Warp Transaction delivery ensuring your sends actually land. Each component addresses a specific weakness in the naive setup. Together, they define what production-grade Solana trading infrastructure looks like in 2026. 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. Building on Solana? Deploy your Solana node on Chainstack → FAQ What are Solana Trader Nodes? Trader Nodes are low-latency Solana endpoints optimized for trading workloads, typically with regional placement, fast data propagation, and better transaction delivery paths. How is ShredStream different from Yellowstone gRPC? ShredStream improves how quickly block data reaches your node, while Yellowstone gRPC streams transactions, slots, and account updates directly from validator memory in a push-based format. Does ShredStream improve transaction landing? Not directly. ShredStream improves data freshness. Transaction landing depends more on the send path, relay path, SWQoS access, priority fees, and leader proximity. What do Warp Transactions change? Warp changes the sendTransaction path by routing transactions more directly toward the leader, reducing dependence on standard gossip propagation. Is Firedancer already the default Solana validator client? No. Firedancer is an important client-diversity milestone and performance path, but Agave remains a major validator client in production. Learn more about Solana from our articles x402 on Solana: Developer Guide to Micro-Payments Solana Node Types: Validator, RPC, and Trader nodes Best Solana RPC providers for fast and reliable production in 2026 How to get a Solana RPC endpoint in 2026 How to build a Solana trading bot How to improve Solana RPC latency with ShredStream Real-time Solana data: WebSocket subscriptions vs Yellowstone gRPC Geyser #### Solana transfer hooks: anchor 0.31 and Token-2022 Solana Transfer Hooks in the Token-2022 standard let you run custom on-chain logic every time a token transfer happens. In this guide, you will build a production-ready Transfer Hook with Anchor 0.31, configure ExtraAccountMetaList for account resolution, avoid common CPI pitfalls, and validate behavior on Solana Devnet with real transactions. Implementing Solana Transfer Hooks within the modern Solana toolchain requires a precise understanding of cross-program invocations (CPIs) and account resolution. In this comprehensive guide, we will architect a production-ready Transfer Hook that enforces a maximum transfer limit constraint. We will cover environment configuration, the mechanics of the ExtraAccountMetaList, the optimal Rust implementation bypassing common CPI pitfalls, and a robust TypeScript integration test suite. In this blog post we will understand the hands-on side of the hooks extension and how to use it. What are Solana Transfer Hooks in Token-2022? The Solana Token-2022 standard and the Transfer Hook Interface introduce the ability to create Mint Accounts that execute custom instruction logic on every token transfer. This architectural shift unlocks a massive design space for token transfers, enabling use cases such as: Enforcing NFT royalties. Building black or white lists for wallets authorized to receive tokens. Implementing dynamic, custom fees on token transfers. Creating custom token transfer events. Tracking on-chain statistics over your token transfers. To achieve this, developers must build a program that implements the Transfer Hook Interface and initialize a Mint Account with the Solana Transfer Hook extension enabled. For every token transfer involving tokens from the Mint Account, the Token Extensions program makes a Cross Program Invocation (CPI) to execute an instruction on the Transfer Hook program. Crucially, when the Token Extensions program CPIs to a Transfer Hook program, all accounts from the initial transfer are converted to read-only accounts. This means the signer privileges of the sender do not extend to the Transfer Hook program a deliberate design decision implemented at the runtime level to prevent the malicious use of Transfer Hook programs. Solana Transfer Hook Interface: Execute and Account Meta Instructions The Transfer Hook Interface provides a standardized method for developers to implement custom instruction logic that is executed on every token transfer for a specific Mint Account. The interface specifies the following core instructions: Execute: The primary instruction that the Token Extension program invokes on every token transfer. InitializeExtraAccountMetaList (optional): Creates an account that stores a list of additional accounts required by the custom Execute instruction. UpdateExtraAccountMetaList (optional): Updates the list of additional accounts by overwriting the existing list. While it is technically not required to implement the InitializeExtraAccountMetaList instruction directly through the interface (the account can be created by any custom instruction), the Program Derived Address (PDA) for the account must be derived deterministically using specific seeds: The hardcoded string "extra-account-metas" The Mint Account address The Transfer Hook program ID By storing the extra accounts required by the Execute instruction in this predefined PDA, these accounts can be automatically resolved and added to a token transfer instruction from the client. Environment setup for Anchor 0.31 + Token-2022 Required CLI and Crate Versions Recent updates to the Solana ecosystem require strict version alignment between the Anchor framework, the Agave toolchain, and the SPL interface crates. To establish a stable build environment for Token-2022 development, In this blog we will use: Agave CLI: v3.1.9. Anchor CLI: 0.31.1. SPL Interface Crates: 0.10.0 Cargo.toml dependencies you need Cargo.toml example: ... [dependencies] anchor-lang = "0.31.1" anchor-spl = { version = "0.31.1", features = ["token_2022", "token_2022_extensions"] } spl-transfer-hook-interface = "0.10.0" spl-tlv-account-resolution = "0.10.0" How ExtraAccountMetaList solves Account Resolution To truly master Solana Transfer Hooks, developers must first understand the fundamental limitation of Solana’s execution model: A program cannot read from or write to an account that was not explicitly passed to it in the transaction. In a standard token transfer, the client (or wallet) only passes four core accounts: the Source, the Mint, the Destination, and the Owner. However, custom Transfer Hook will likely need access to other accounts, such as a global configuration state, a whitelist directory or any other use-case. Since the client initiating the transfer has no knowledge of your protocol’s internal architecture, how does the Token-2022 program know which additional accounts to fetch and pass to your Hook? The answer lies in On-Chain Account Resolution via the ExtraAccountMetaList. The ExtraAccountMetaList PDA Seeds and Derivation The ExtraAccountMetaList is a stateless, on-chain roadmap. It is a Program Derived Address (PDA) deterministically generated using three seeds: The hardcoded byte string b"extra-account-metas" The SPL Token Mint address Your Transfer Hook Program ID Before executing the cross-program invocation (CPI) to your Hook, the Token-2022 program queries this specific PDA. If the PDA exists, Token-2022 reads its data, unpacks the roadmap, and automatically appends the requested accounts to the transfer transaction. Defining extra Accounts in Anchor To set this up safely, we first define the validation constraints for the initialization context. #[derive(Accounts)] pub struct InitializeExtraAccountMetaList<'info> { #[account( init, seeds = [b"extra-account-metas", mint.key().as_ref()], bump, payer = payer, // 8 bytes for the Anchor discriminator + 64 bytes for the TLV data space = 8 + 64 )] /// CHECK: PDA storing the metadata roadmap for the Token-2022 program pub extra_metas_account: AccountInfo<'info>, /// CHECK: The SPL Token Mint pub mint: AccountInfo<'info>, #[account(mut)] pub payer: Signer<'info>, pub system_program: Program<'info, System>, } Note: Notice how the PDA is derived using the exact seeds required by the Token-2022 specification that was defined above. How Anchor fulfills the specification If you look at the seeds = [...] array in the code above, you only see two items explicitly written: b"extra-account-metas" (The hardcoded byte string). mint.key().as_ref() (The Mint’s Public Key). So, where is the third seed (the Program ID)? This is where the Anchor framework steps in. Whenever you use theseeds = [...] macro in an Anchor #[account(...)] constraint, Anchor automatically appends the currently executing Program ID as the final seed during compilation. Full docs here. // Under the hood, Anchor translates that macro into the raw Solana runtime function: Pubkey::find_program_address(&[b"extra-account-metas", mint.key().as_ref()], program_id) The initialize_extra_account_meta_list Function With the account structure validated, developers must implement the initialize_extra_account_meta_list instruction. This function’s sole responsibility is to pack the ExtraAccountMeta configurations into the PDA. Instead of hardcoding static addresses (which breaks composability), professional implementations use Seed-Based Resolution. pub fn initialize_extra_account_meta_list(ctx: Context<InitializeExtraAccountMetaList>) -> Result<()> { let account_metas = vec![ // Instructs Token-2022 to derive the required PDA using dynamic seeds spl_tlv_account_resolution::account::ExtraAccountMeta::new_with_seeds( &[ spl_tlv_account_resolution::seeds::Seed::Literal { bytes: b"extra-account-metas".to_vec() }, spl_tlv_account_resolution::seeds::Seed::AccountKey { index: 1 }, // Resolves using the Mint (Index 1) ], false, // is_signer false, // is_writable )? ]; let mut data = ctx.accounts.extra_metas_account.try_borrow_mut_data()?; // Formats the data as a Type-Length-Value (TLV) structure for the Execute instruction spl_tlv_account_resolution::state::ExtraAccountMetaList::init::< spl_transfer_hook_interface::instruction::ExecuteInstruction >(&mut data, &account_metas)?; msg!("Extra Account Meta List Initialized"); Ok(()) } By utilizing ExtraAccountMeta::new_with_seeds(), you instruct the Token-2022 program to dynamically derive the required accounts at the exact moment of transfer. For example, by specifying Seed::AccountKey { index: 1 }, you are telling the Token-2022 runtime: “To find the extra account my Hook needs, derive a PDA using the Public Key of the account currently sitting at Index 1 of this transaction (the Mint field in the InitializeExtraAccountMetaList struct ).” This dynamic resolution mechanism ensures that your Solana Transfer Hook remains entirely deterministic, allowing the Token-2022 program to bridge the gap between standard wallet transfers and complex, multi-account protocol logic. The line: let mut data = ctx.accounts.extra_metas_account.try_borrow_mut_data()?; In Solana, an account's data payload is protected behind a RefCell. By calling try_borrow_mut_data()?, we bypass standard Anchor struct serialization to safely borrow a mutable reference to the PDA's underlying raw byte slice (&mut [u8]). We need this raw access because Token-2022 expects a very specific memory layout that we are about to construct manually. spl_tlv_account_resolution::state::ExtraAccountMetaList::init::< spl_transfer_hook_interface::instruction::ExecuteInstruction >(&mut data, &account_metas)?; Once we have our raw byte slice (&mut data), we invoke the init function from the spl_tlv_account_resolution crate. This function formats your account_metas vector and writes it into the PDA using a Type-Length-Value (TLV) encoding scheme. TLV is the backbone of Token-2022, allowing multiple extensions and state variables to be packed sequentially into a single account without data collisions. Implementing the Transfer Hook Program With the account resolution architecture defined, we can move on to the core logic. Writing a Transfer Hook requires stepping slightly outside the standard Anchor boundaries. Below is the complete implementation for our Transfer Hook. This program initializes the metadata roadmap and enforces a strict volume constraint on transfers. use anchor_lang::prelude::*; use spl_transfer_hook_interface::instruction::TransferHookInstruction; declare_id!("<YourGeneratedAddress>"); #[program] pub mod transfer_hook_project { use super::*; /// Initializes the PDA that Token-2022 reads to resolve extra accounts. pub fn initialize_extra_account_meta_list(ctx: Context<InitializeExtraAccountMetaList>) -> Result<()> { let account_metas = vec![ // Instructs Token-2022 to derive the required PDA using dynamic seeds spl_tlv_account_resolution::account::ExtraAccountMeta::new_with_seeds( &[ spl_tlv_account_resolution::seeds::Seed::Literal { bytes: b"extra-account-metas".to_vec() }, spl_tlv_account_resolution::seeds::Seed::AccountKey { index: 1 }, // Resolves using the Mint (Index 1) ], false, // is_signer false, // is_writable )? ]; let mut data = ctx.accounts.extra_metas_account.try_borrow_mut_data()?; spl_tlv_account_resolution::state::ExtraAccountMetaList::init::< spl_transfer_hook_interface::instruction::ExecuteInstruction >(&mut data, &account_metas)?; msg!("Extra Account Meta List Initialized"); Ok(()) } pub fn transfer_hook(_ctx: Context<TransferHook>, amount: u64) -> Result<()> { msg!("Hook executed for transfer amount: {}", amount); if amount > 1_000_000_000_000 { return err!(ErrorCode::TransferVolumeExceeded); } Ok(()) } pub fn fallback<'info>(program_id: &Pubkey, accounts: &'info [AccountInfo<'info>], data: &[u8]) -> Result<()> { let instruction = TransferHookInstruction::unpack(data)?; match instruction { TransferHookInstruction::Execute { amount } => { let amount_bytes = amount.to_le_bytes(); // Routes execution to the Anchor instruction without requiring a standard CPI __private::__global::transfer_hook(program_id, accounts, &amount_bytes) } _ => return Err(ProgramError::InvalidInstructionData.into()), } } } #[derive(Accounts)] pub struct InitializeExtraAccountMetaList<'info> { #[account( init, seeds = [b"extra-account-metas", mint.key().as_ref()], bump, payer = payer, space = 8 + 64 )] pub extra_metas_account: AccountInfo<'info>, pub mint: AccountInfo<'info>, #[account(mut)] pub payer: Signer<'info>, pub system_program: Program<'info, System>, } #[derive(Accounts)] pub struct TransferHook<'info> { /// CHECK: Source Token Account pub source: AccountInfo<'info>, /// CHECK: The SPL Token Mint pub mint: AccountInfo<'info>, /// CHECK: Destination Token Account pub destination: AccountInfo<'info>, /// CHECK: Owner of the Source Account pub owner: AccountInfo<'info>, /// CHECK: The resolved ExtraAccountMetaList PDA #[account( seeds = [b"extra-account-metas", mint.key().as_ref()], bump )] pub extra_metas_account: UncheckedAccount<'info>, } #[error_code] pub enum ErrorCode { #[msg("Transfer amount exceeds the maximum protocol limit.")] TransferVolumeExceeded, } Handling the CPI Discriminator mismatch If you look closely at the code above, a glaring architectural question arises: If our core logic lives inside an Anchor function, why doesn’t the Token-2022 program call it directly? Why do we need a fallback function to intercept the call? Furthermore, why not just name our function execute to match the Token-2022 standard? The answer lies in how the Solana Virtual Machine (SVM) and the Anchor framework handle instruction routing via Instruction Discriminators. When the Anchor framework compiles your Rust code, it automatically generates an 8-byte discriminator for every function to route incoming transactions. To prevent naming collisions between different programs, Anchor automatically injects a namespace prefix before hashing the string. For a standard instruction, it uses the prefix global:. If you were to name your function pub fn execute(...), Anchor would generate the discriminator by taking the SHA-256 hash of exactly this string: "global:execute". However, the Token-2022 program has no knowledge of your Anchor program’s internal namespaces. When a token transfer fires, Token-2022 blindly issues a CPI using the standardized SPL interface discriminator, which is generated by hashing this specific string: "spl_transfer_hook_interface:execute". Because the input strings are different, the resulting 8-byte hashes are entirely different. If the Token-2022 program hits your standard Anchor instruction, Anchor will immediately reject the transaction as an “Invalid Instruction,” even if the human-readable function names are identical. Fallback Router and Context Isolation To bridge this gap, we must implement the fallback function. In Anchor, the fallback acts as a catch-all safety net. If an incoming instruction does not match any known Anchor discriminator, the framework passes the raw transaction data directly to the fallback. Inside this fallback, we manually assume control of the routing logic: We unpack the raw SPL instruction data. We cryptographically verify it is the standard Execute command. We dynamically route the execution to our actual transfer_hook function. The Context Routing Trick: Notice the __private::__global::transfer_hook call inside the fallback. A common critical mistake developers make here is attempting to use a standard Solana invoke (a self-CPI) to jump from the fallback to the target function. This will cause an immediate crash (Account missing error) because the Token-2022 runtime actively strips out non-essential accounts (like the System Program or your Program ID) from the transfer payload to maintain strict security boundaries. By utilizing __private::__global, we tap into an internal Anchor dispatcher. It takes the raw accounts passed by Token-2022 and feeds them directly into our Anchor instruction within the exact same call stack. This completely bypasses the SVM’s CPI limitations, allowing your program to retain all of Anchor’s robust security constraints without the overhead or limitations of a cross-program invocation. Deploying and Testing on Solana Devnet Deploying a Solana Token-2022 Transfer Hook to Devnet requires a few specific configuration shifts to ensure both the Anchor framework and the SPL CLI are targeting the correct RPC cluster. Deploy the Anchor Program First, open your Anchor.toml file at the root of your project. You need to switch the provider cluster from Localnet to Devnet and explicitly declare your program ID for the new network. [provider] cluster = "Devnet" wallet = "~/.config/solana/id.json" # Ensure this points to your active deployment keypair [programs.devnet] transfer_hook_project = "<YOUR_NEW_PROGRAM_ID>" Once configured and funded with Devnet SOL, run a clean build and deploy the program to the live network: anchor clean anchor build anchor deploy you should see something like: on Explorer: https://solscan.io/tx/UEEbnRtutGDkkhKddQfKL2MaDevqvgmHbs3xMPx4RF97uiDnKFmAuf5K3BjwL4YK9EXUv7zDEXjVBwwmw1mZvBM?cluster=devnet Create a Token-2022 Mint with Transfer Hook Once the Anchor program is successfully deployed, we can leverage the spl-token CLI to create the actual Token-2022 Mint, attach the hook, and prepare our test accounts. # Create the Token-2022 Mint and attach the newly deployed Hook spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --transfer-hook <YOUR_PROGRAM_ID> --url devnet # output: # Creating token 71H52RsWiLbMXQuBtH5a1hLSzUnbTgiDjFhktuJrJT1m under program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb # Address: 71H52RsWiLbMXQuBtH5a1hLSzUnbTgiDjFhktuJrJT1m # Decimals: 9 # Signature: 2rtXMX3TaXZoWMJqcYj7vwhtWng3eLUBfDHbG4N45QxnQnuwrNReKZgPoLPNfHKBXofuoH1daFAP73FoWJAFRWJV on Explorer: https://solscan.io/token/71H52RsWiLbMXQuBtH5a1hLSzUnbTgiDjFhktuJrJT1m?cluster=devnet # Create your Devnet Associated Token Account (ATA) spl-token create-account <TOKEN_MINT_ADDRESS> --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --url devnet # Mint the initial test supply to your wallet spl-token mint <TOKEN_MINT_ADDRESS> 2000 --url devnet Note: Now your account should have 2000 of the minted token Initialize the ExtraAccountMetaList PDA At this point, the Token-2022 program is aware of your Hook, but any token transfer will still fail because the ExtraAccountMetaList PDA has not been instantiated on Devnet. You must invoke your initialize_extra_account_meta_list instruction to write the resolution map to the blockchain. Since this logic lives entirely inside your custom Anchor program, the standard SPL CLI cannot do this for you. We bridge this gap with a standalone TypeScript script: import * as anchor from "@coral-xyz/anchor"; import { Program } from "@coral-xyz/anchor"; import { TransferHookProject } from "../target/types/transfer_hook_project"; async function main() { // 1. Force the provider to use Devnet process.env.ANCHOR_PROVIDER_URL = "https://api.devnet.solana.com"; const provider = anchor.AnchorProvider.env(); anchor.setProvider(provider); // 2. Define your specific Devnet addresses const programId = new anchor.web3.PublicKey("<ProgramID>"); const mintAddress = new anchor.web3.PublicKey("<MintID>"); console.log("Connecting to Devnet as:", provider.wallet.publicKey.toBase58()); // 3. Load the workspace program const program = anchor.workspace.TransferHookProject as Program<TransferHookProject>; // 4. Deterministically derive the PDA using the exact Token-2022 seeds // Only for the print, not needed for the program its done automatically. const [extraMetasPDA] = anchor.web3.PublicKey.findProgramAddressSync( [Buffer.from("extra-account-metas"), mintAddress.toBuffer()], programId ); console.log("Target Mint:", mintAddress.toBase58()); console.log("Derived Metadata PDA:", extraMetasPDA.toBase58()); console.log("Broadcasting initialization transaction..."); // 5. Execute the Anchor instruction try { const tx = await program.methods .initializeExtraAccountMetaList() .accounts({ mint: mintAddress, }) .rpc(); console.log("\nSuccess! The ExtraAccountMetaList roadmap is live on Devnet."); console.log(`View on Explorer: https://explorer.solana.com/tx/${tx}?cluster=devnet`); } catch (error) { console.error("Transaction failed:", error); } } main(); The output should look like: On Explorer: https://solscan.io/account/FnchjEr1FuknaNoEpTEvKkH96mcBu8L1VGYig3oCc2WW?cluster=devnet Validate Transfers on Devnet (Fail/Pass Cases) With the PDA roadmap live on Devnet, your token is now 100% locked into the Transfer Hook. The modern spl-token CLI natively supports Solana Transfer Hooks and Account Resolution. Let’s trigger a transfer that violates our 1,000-token limit: spl-token transfer <TOKEN_MINT_ADDRESS> 1500 <DESTINATION_WALLET> --fund-recipient --url devnet The Error: Error: Client(Error { request: Some(SendTransaction), kind: RpcError(RpcResponseError { code: -32002, message: "Transaction simulation failed: Error processing Instruction 1: custom program error: 0x1770", data: SendTransactionPreflightFailure(RpcSimulateTransactionResult { err: Some(UiTransactionError(InstructionError(1, Custom(6000)))), logs: Some([ ... "Program log: Instruction: TransferHook", "Program log: Hook triggered for amount: 1500000000000", "Program log: AnchorError thrown in programs/transfer-hook-project/src/lib.rs:36. Error Code: AmountTooBig. Error Number: 6000. Error Message: Transfer amount exceeds the blog's demo limit.", "Program AgfLd9BmQcLZj9h13gYTsAgWdEnXKAArnRypuPd9hCub failed: custom program error: 0x1770" ]) The Hook perfectly intercepted the transfer and threw our custom Anchor error! Now, let’s drop the volume to 500 tokens to satisfy the protocol constraint: spl-token transfer <TOKEN_MINT_ADDRESS> 500 <DESTINATION_WALLET> --fund-recipient --url devnet The output On Explorer: Summary If you followed along and executed the final Devnet transactions, you successfully intercepted a native token transfer and injected custom business logic directly into the execution flow using Solana Transfer Hooks. Token-2022 has expanded what developers can build on Solana. By mastering Solana Transfer Hooks, Account Resolution through ExtraAccountMetaList, and Anchor context isolation to avoid CPI discriminator mismatches, you can implement secure, synchronous state updates with minimal compute overhead. Learn more about Solana architecture from our articles: Solana Token-2022 Metadata Solana Token-2022 Transfer Hooks and Fee-on-Transfer Where token metadata lives on Solana SPL Token Program Architecture Architecture & Parallel Transactions Account Model and Transactions Anchor Accounts: Seeds, Bumps, PDAs Instructions and Messages Transaction, Serialization, Signatures, Fees, and Runtime Execution 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 → #### Solana-web3.js Tutorial - Learn In Just 7 minutes In this tutorial, we'll go through some examples of basic utilization of solana-web3.js. This tutorial is derived from a previous episode of Byte-Size BUIDLing. Solana-web3js is among the most popular methods of connecting to the Solana blockchain and building applications. Because of this, it's really important to know what the library is capable of as well as how to actually use it. In an effort to make this topic a little bit easier to digest, we will go through three key examples of solana-web3.js utilization. What we will cover in this tutorial 1. Minting an SPL token 2. Sending a normal SOL transaction 3. Delegate SOL natively through solana-web3.js. We will be covering a lot of ground here, so we will go through things very quickly, but if you'd like to dive more into the specific concepts, we do already have tutorials on both minting SPL tokens & sending a transaction with solana-web3.js. So, let's jump right into it. Import key libraries to get started const solanaWeb3 = require('@solana/web3.js'); const splToken = require('@solana/spl-token'); consta bs58 = require('bs58'); Ok, so now we've imported solana-web3.js, spl-token, and base58. We'll be using solana-web3 for most of this, as a base layer connection and interactivity layer with the Solana blockchain. We'll be using spl-token for the minting and tokenAccount process, and we'll be using base58 for the private key decoding. Write the code for our main asynchronous function. async function main() {} Define connection variable This will be the variable that we will use our RPC endpoint to connect to the Solana blockchain itself. If you do not have access to a node, you can deploy a high-performance node for free using Chainstack. After you sign up, you will need to create a project, join a network, and then you will have access to your own HTTPS and WSS endpoints. Here's a tutorial that we've made for Scroll network, but the steps are the same for any protocol that we support. Just select Solana in the "Join network" stage instead of Scroll. https://twitter.com/ChainstackHQ/status/1693653770859659613?s=20 const connection = solanaWeb3.Connection("https://nd-729-020-604.p2pify.com/89254f3e5bf61205d9558141245b8a80", {wsEndpoint:"wss://ws-nd-729-020-604.p2pify.com/89254f3e5bf61205d9558141245b8a80"}); Define the main account const walletKeyPair = solanaWeb3.Keypair.fromSecretKey(new Uint8Array(bs58.decode(process.env.PRIVATE_KEY))); Now we have our main wallet, let's go and quickly run a balance call on it, just so we know how much SOL we're working with. let balance = await connection.getBalance(walletKeypair.publicKey); console.log(balance / solanaWeb3.LAMPORTS_PER_SOL); Before we continue we can run this code and make sure that it works. After calling the main() function you should see how much SOL you have in your wallet. We have about 0.3 SOL in our wallet right now. main() solana-web3.js utilization - minting an SPL token Defining a mint variable. const mint = await splToken.createMint( connection, walletKeyPair, walletKeyPair.publicKey, null, // this is the freeze authority 9, //decimals undefined, {}, splToken.TOKEN_PROGRAM_ID, ); Create a token account const tokenAccount = await splToken.getOrCreateAssociatedTokenAccount( connection, walletKeyPair, mint, walletKeyPair.publicKey, ); Mint the token itself await splToken.mintTo( connection, walletKeyPair, mint, tokenAccount.address, walletKeyPair.publicKey, 1000000000000, ) Alright, so, we've created our mint object which runs the createMint() method on the SPL token library that we imported, then we created a tokenAccount, and we minted the tokens to our wallet. Before we continue, let's run the code and make sure that it works by calling the main() function again. You should receive 1000 tokens of the SPL token that we've just created or a different amount if you input a different value in the mint function. Sending a SOL transaction from one address to another using solana-web3.js Generate a second address to send SOL to Let's generate a 2nd wallet const secondWalletKeyPair = solanaWeb3.Keypair.generate(); Define a transaction object const transaction = new solanaWeb3.Transaction().add( solanaWeb3.SystemProgram.transfer({ fromPubkey: walletKeyPair.publicKey, toPubkey: secondWalletKeyPair.publicKey, lamports: solanaWeb3.LAMPORTS_PER_SOL * 0.001, }), ); Send the transaction and save the signature const signature = await solanaWeb3.sendAndConfirmTransaction( connection, transaction, [walletKeyPair], ); Sweet, at this point, if you run the script it should create a new SPL token, mint 1000 of these tokens to your wallet, and it will also send 0.001 SOL to a fresh wallet that you generate in secondWalletKeyPair. Feel free to give it a try and run the code by calling the main() function. Delegate SOL natively through solana-web3.js. This will be a little more complex than what we've done so far. In order to do it right, we will need 4 key components. Create a stake account. Initialize the transaction for the stake account creation. Delegate our stake. Initialize the transaction for delegation. Create a stake account const stakeAccount = solanaWeb3.Keypair.generate(); let createStakeAccountInstruction = solanaWeb3.StakeProgram.createAccount({ fromPubkey: walletKeyPair.publicKey, stakePubkey: stakeAccount.publicKey, authorized: new solanaWeb3.Authorized(walletKeyPair.publicKey, walletKeyPair.publicKey), lamports: solanaWeb3.LAMPORTS_PER_SOL * 0.02, }); Initialize the transaction for the stake account creation let createStakeAccountTransaction = new solanaWeb3.Transaciton().add(createStakeAccountInstruction); createStakeAccountTransaction.recentBlockhash = (await connection.getRecentBlockhash()).blockhash; createStakeAccountTransaction.feePayer = walletKeyPair.publicKey; createStakeAccountTransaction.partialSign(stakeAccount); createStakeAccountTransaction = await solanaWeb3.sendAndConfirmTransaction( connection, createStakeAccountTransaction, [walletKeyPair, stakeAccount], ); Build and send the delegation transaction We'll first need to define the public key of the validator that we're delegating to. const votePubkey = new solanaWeb3.PublicKey('{input the public key here and remove curly brackets}') let delegateInstruction = solanaWeb3.StakeProgram.delegate({ stakePubkey: stakeAccount.publicKey, authorizedPubkey: walletKeyPair.publicKey, votePubkey, }); Initialize the transaction for delegation let delegateTransaction = new solanaWeb3.Transaction().add(delegateInstruction); delegateTransaction.recentBlockhash = (await connection.getRecentBlockhash()).blockhash; delegateTransaction.feePayer = walletKeyPair.publicKey; delegateTransaction.sign(walletKeyPair); delegateTransaction = await solanaWeb3.sendAndConfirmTransaction( connection, delegateTransaction, [walletKeyPair], ); Recap of what you did Imported the base libraries. Established a connection to the Solana blockchain through a Chainstack RPC endpoint. Imported a wallet. Read the balance of that wallet. Minted an SPL token. Sent a SOL transaction. Staked 0.02 SOL. Now, you can bring it all together and give it a try by calling main(). If you've got until this point, congratulations, you are on your way to becoming a better Solana developer. If you'd like to take a deeper dive into the core concepts covered within this tutorial, you can find all three tasks here (minting SPL tokens, sending a transaction, and delegating SOL) covered in-depth on our developer portal. Minting SPL tokens with solana-web3.js Send Solana transaction using solana-web3.js Delegating SOL with solana-web3.js Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Power-boost your project on Chainstack #### Solana-web3.js tutorial - Send a Solana transaction in 3 Minutes A few weeks ago, we published another article about how to mint an SPL token on Solana, which is a foundational component of Solana development. So, following this trend of covering foundational tutorials in order to support you as a Solana developer, in this tutorial you will learn how to send a Solana transaction using solana-web3.js. Install solana-web3.js library To get started you'll first have to install the solana-web3.js library, with node package manager. You can do that with npm install. npm install @solana/web3.js We will also need to install a base58 library. You don't have to do this if you plan on using an array type private key, but in this case, we plan on using a standard string private key base58, the type of private key you get from a Phantom wallet for example. So we will need this base58 library in order to do some conversions. npm install bs58 Define variables Alright, so now that you have solana-web3.js and bs58 installed, we can go ahead and define your variables in the index file. const web3 = require("@solana/web3.js"); const bs58 = require("bs58"); Connect to the Solana blockchain Now you need to connect to the Solana blockchain itself through a connection variable. Deploy your own Solana node with Chainstack for free 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. Define the connection variable. const connection = new web3.Connection("copy paste your https endpoint here") Great, now we can move on to creating the Solana account that is going to send this transaction. Define the private key variable const privateKey = new Uint8Array(bs58.decode(process.env['PRIVATE_KEY'])); The code above defines a new variable, called privateKey, and is setting it up to be of type Uint8Array, which calls a base58 object. The code then calls the decode method on the object. Derive the account from the private key Now we can go ahead and derive the account from the private key that we've just defined. const account = web3.Keypair.fromSecretKey(privateKey); Define the account that we are sending to We will create a fresh account to send funds to. const account2 = web3.Keypair.generate(); The second account has both a private, and a public key, but in order to send funds to the account, we only need the public key, which is what we will be using here. Define & push the transaction (async () => { const transaction = new web3.Transaction().add( web3.SystemProgram.transfer({ fromPubKey: account.publicKey, toPubKey: account2.publicKey, lamports: web3.LAMPORTS_PER_SOL * 0.001, }), ); const signature = await web3.sendAndConfirmTransaction( connection, transaction, [account], ); })(); We defined a transaction object and our signature, which will push the transaction on the Solana blockchain. Recap of what you did in this tutorial Imported the packages. Defined a connection variable using a Chainstack node. Defined your private key and derived an account from it. Created a 2nd account to send the Solana to. Created a transaction object using from, to, and value. Sent that transaction and stored it in a variable called signature. Let's put it to the test. Go over to the console and run the code. Now, if you check your Phantom wallet, you should see the transaction in there. If you are looking for another Solana tutorial, check out our solana-web3.js tutorial. Power-boost your project on Chainstack #### Solana: Architecture & Parallel Transactions We’re starting a new series of articles by Andrey Obruchkov, an experienced blockchain engineer who has spent years exploring how high-performance blockchains like Solana work under the hood - with a particular focus on Solana parallel transactions and execution at scale. In this series, he explains Solana’s technical foundations in simple, practical terms — from its core architecture and account model to how Solana parallel transactions are processed at scale. TL;DR: The Solana blockchain achieves high throughput and low latency via three key innovations: a cryptographic timestamping mechanism (Proof of History) that records the order of events without relying on external clocks, a consensus layer (Tower BFT) built on that timestamping to finalize blocks quickly, and a parallel runtime (Sealevel) that allows many transactions to execute concurrently if they don’t touch the same accounts. These architectural layers enable Solana to scale far more than traditional blockchains.  The Solana blockchain is built for high performance, emphasizing speed, scalability, and low latency. To achieve this, it introduces several architectural innovations that set it apart from traditional blockchains like Ethereum. In this first part, we’ll focus on Solana’s core architecture — namely, its use of Proof of History (PoH), Tower BFT, and parallel transaction processing. Core Architecture One of Solana’s foundational pieces is Proof of History (PoH). This concept was introduced by Solana’s founder, Anatoly Yakovenko, and is centered on the idea that in a distributed system, it’s not just the events that matter, but their precise order in time. Proof of History (PoH) uses a special cryptographic function called a Verifiable Delay Function (VDF). It takes a certain amount of time to calculate, but once it’s done, anyone can easily check that the result is correct. Validators keep hashing the previous result together with new data, creating a continuous chain of hashes that works as a built-in timestamp for all network events. Because this chain already includes the order of events, Solana doesn’t need external clocks or fixed block times like Bitcoin or Ethereum. Each transaction points to a specific place in the PoH sequence, which lets validators quickly see when it happened compared to others. This makes transaction confirmation much faster. On top of PoH, Solana runs a consensus system called Tower BFT, based on an older model known as PBFT (Practical Byzantine Fault Tolerance) but adapted for PoH’s internal clock. In normal PBFT, validators must send many messages to agree on transaction order, which slows things down as the network grows. Solana improves this by allowing each validator to verify the timestamped sequence independently, reducing the communication required. Validators also stake SOL tokens and vote on which version of the ledger they support. The longer their vote remains on a block, the more difficult it becomes to change it later. This system allows Solana to reach final, unchangeable confirmations quickly and efficiently. Putting it together: A cryptographic timestamp (PoH) gives a reliable order of events. A consensus layer (Tower BFT) uses that order to finalize blocks.This enables Solana to process thousands of transactions per second while maintaining security and decentralization. Parallel Transaction Processing A major hurdle for many blockchains is that transactions are processed sequentially: one after another. This is because many transactions touch shared state (for example, accounts or contract storage), so to avoid conflicts, you must serialize them. That severely limits throughput. Solana addresses this via its runtime named Sealevel. Before executing, each transaction declares two sets of accounts: which it will read, and which it will write to. If two transactions do not overlap on writable accounts (i.e., they touch different state), they can execute in parallel across multiple cores or even GPUs. For example: Transaction A writes to Account X; Transaction B reads from Account Y;  Since X and Y are disjoint, both can proceed at once. This transforms block validation from a single-threaded bottleneck into a highly parallel task, massively boosting throughput. When combined with PoH (for ordering) and Tower BFT (for consensus), parallel execution allows Solana to scale transaction processing without compromising determinism or consistency. Why these innovations matter PoH’s VDF embeds a cryptographic sense of time, so the network doesn’t have to coordinate timestamps externally. This enhances efficiency and scalability. Tower BFT leverages the timestamping to make consensus faster and leaner, because validators need less communication. Sealevel’s parallel processing enables the network to execute many transactions concurrently, making high throughput feasible, not just theoretical. Together, these architectural choices explain how Solana aims to achieve sub-second finality, tens of thousands of transactions per second, and the ability to scale to large numbers of active users and applications. Read the full article on Medium What’s next In the next part of the series, the article will shift focus to Solana’s account model — how programs, state, and data are organized in accounts, how it differs from the contract-centric model in Ethereum, and what implications that has for developers. 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: Architecture, Account Model and Transactions The Solana account model is the foundation of how data, balances, and program state are stored and modified across the network. In Solana, everything comes down to accounts.Every token balance, user record, and piece of program data lives inside one. The programs themselves are stateless — they only read and modify the information that accounts provide. Once you see this, the whole design of Solana becomes much clearer. You’ll learn how Program-Derived Addresses (PDAs) let programs securely control deterministic accounts without private keys, how ownership and access flags prevent unauthorized modifications, and why rent and rent exemption keep the network’s storage model sustainable. This article takes a closer look at what an account really is. We’ll break down its structure, ownership, and how Program-Derived Addresses (PDAs) help create secure, predictable account addresses without private keys. You’ll also see how the different types of accounts — from system to program state — fit together in Solana’s architecture. What makes an account the basic unit of state on Solana The most important thing to understand about Solana is that unlike most blockchains where “contracts” hold their own state internally, Solana separates code and data completely.Programs (smart contracts) are pure logic, they don’t own persistent storage.Instead, all persistent data lives in accounts, which are on-chain data containers managed by the runtime. Scheme from https://solana.com/docs/core/accounts#account-address Every instruction that runs on Solana explicitly lists which accounts it wants to read or write.The runtime enforces access rules: Only the account’s owner program can modify its data. Only the account’s signer (or a PDA acting as signer, PDA will be explained in next section) can authorize transfers or ownership changes. This strict separation achieves two things: Parallelism: since programs operate only on the accounts listed in the transaction, Solana can execute unrelated transactions concurrently. Security and clarity: a program cannot accidentally modify global state; it must be given explicit permission to touch each account. In short, accounts are the atomic unit of state on Solana.If Ethereum’s equivalent is a contract with internal storage slots, Solana’s model externalizes that: each “slot” becomes its own addressable account on-chain. Everything you interact with: users, tokens, pools, NFTs, even the Solana runtime itself is built on top of these accounts. What is Program derived address (PDA) Solana doesn’t allow programs to hold private keys.Yet, sometimes your program needs an address it can own and control deterministically, for example, a vault to store user deposits, or a metadata account tied to a specific mint.That’s exactly what Program-Derived Addresses (PDAs) provide. A PDA is a special kind of account address that is: Deterministically derived from a set of seeds and a program ID Guaranteed not to collide with any address that has a valid Ed25519 private key. Because PDAs don’t correspond to real keypairs, they cannot be signed using a private key.Instead, the Solana runtime lets the owning program “sign” on behalf of that PDA during an instruction but only if the PDA was derived with the program’s own ID. How PDAs are generated A PDA is derived like that with the help of solana-sdk on Rust: Pubkey::find_program_address(seeds: &[&[u8]], program_id: &Pubkey) This function tries different “bump” values: It iterates bump values by starting at 255 and decrementing by 1 until a valid PDA is found that is not on the Ed25519 curve (i.e., cannot have a private key).This results a unique PDA is created for the combination of: program_id and the seeds array. Example: let (vault_pda, bump) = Pubkey::find_program_address(&[b"my_vault", user.key().as_ref()], &program_id); Now vault_pda will always be the same for this user and program no need to store it anywhere. Scheme from https://solana.com/docs/core/pda How PDAs “sign” When your program makes a cross-program invocation (CPI) (Don’t worry, it will be covered in later chapters; now we only want to understand the sign effect) that needs the PDA to act as a signer, for example, to transfer tokens from a PDA’s account, you use the function invoke_signed() and pass the same seeds and bump used to derive the PDA. Why PDAs matter PDAs are at the heart of how complex Solana programs structure state.They let you: Create per-user or per-pool state accounts deterministically (like ["profile", user] or ["pool", token_a, token_b]). Build vaults or treasuries controlled solely by your program. Prevent arbitrary users from hijacking your storage addresses. Avoid having to store mapping data on-chain (you can recompute addresses instead). They are what make Solana’s stateless programs practical, safe, and composable. Account Types On Solana, every account falls into one of two main categories: Program accounts: contain executable code. Data accounts: hold information but do not execute code. This structure means that a program’s logic (the code) and its state (the data) live in separate accounts. Program accounts A program account holds the compiled bytecode that defines what a Solana program does. Key properties: Executable: true Owner: always the BPF Loader Data: contains the actual program code Program accounts don’t store any user data or variables.When a transaction calls a program, Solana loads this executable account into memory and runs its code. Data accounts Data accounts store all persistent data your program uses, such as user profiles, vaults, liquidity pools, and token mints.They are owned by a specific program, and only that program can modify them. Common subtypes: Program state accounts Custom accounts that keep your program’s on-chain data, such as: a liquidity pool a user’s staking position configuration or settings data Main properties: Address: often a Program-Derived Address (PDA) to ensure secure, deterministic ownership Owner: your program’s public key Executable: false Rent: must hold enough lamports to stay rent-exempt (explained later) System accounts These are accounts controlled by the System Program.They include: Wallet accounts holding SOL and able to sign transactions. Temporary or uninitialized accounts before assignment to a program. Upgrade or admin accounts, usually simple keypairs with control privileges. System accounts form the foundation of Solana’s runtime.They can send SOL, pay rent, and be reassigned to different program owners. Sysvar accounts Sysvar accounts are read-only accounts provided by Solana itself.They give programs access to internal blockchain data — for example, block times, slot numbers, or rent rates. Instead of adding this data to every transaction, Solana offers it through predefined Sysvar accounts.More information can be found in the official Solana documentation. How Solana enforces ownership, rent, and access Now that we’ve seen the different types of accounts, it’s important to understand how Solana controls who can read, write, or move lamports and how it ensures the network stays economically stable through rent. Ownership Every account has an owner field a public key that identifies the program authorized to modify its data. Only the owning program can change an account’s data bytes. The System Program can change an account’s owner (using assign) or Lamport balance (using transfer). User wallets are just system accounts whose owner is the System Program. When your custom program creates an account, it sets itself as the owner, making it the only program that can write to that account’s data. Example: account.owner = <your program id> means that only your program can modify this account’s internal data field no other program can. This strict owner–writer rule prevents accidental or malicious modification of another program’s state. Access Control (Signers and Writable Flags) On Solana, every transaction must clearly list all the accounts it will use before execution.For each account, two important flags are defined: Writable: whether the program can change the account’s data or lamports (SOL balance). Signer: whether the account must sign the transaction to authorize it. This system ensures strong access control.Only accounts marked as writable can be modified during execution — for example, updating a user’s balance or changing program state. Accounts marked as read-only can be viewed but not altered. Similarly, signer accounts are those that prove permission to perform an action. In most cases, this means a user’s wallet or a Program Derived Address (PDA) that signs through invoke_signed. Without the correct signature, the transaction will fail. A key rule is that programs cannot read or modify any account that wasn’t explicitly included in the instruction’s context. This prevents unauthorized access and ensures predictable behavior. Because Solana knows in advance which accounts each instruction will touch, it can safely execute many transactions at the same time — as long as they do not try to write to the same accounts.This explicit access model is what enables Solana’s high parallel performance and throughput. Rent and Rent Exemption Every account must pay rent, which is a small cost to occupy on-chain storage. However, most programs make accounts rent-exempt by depositing enough lamports upfront. The rent-exempt minimum depends on: the account’s data size (number of bytes), and the current rent rate (available via the SysvarRent account). Key points: If an account’s lamports drop below the rent-exempt threshold, the runtime can reclaim it. Rent-exempt accounts never lose lamports or get purged. Programs typically calculate rent like this: let rent = Rent::get()?;let lamports = rent.minimum_balance(space); This one-time deposit covers storage costs permanently, keeping the account active without future rent deductions. Read the full article from Andrey Obruchkov on Substack 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: How to calculate transaction fees programmatically? Stepping into the realm of Web3, the role of transaction fees is undeniable. These small costs incurred during operations like token transfers, interactions with smart contracts, or executing complex decentralized applications are what keep the system running smoothly. Solana is no different in requiring these fees, yet it stands out with its uniquely designed fee mechanism. Renowned for its predictability and efficiency, Solana's transaction fee model sets it apart from familiar gas systems like the one Ethereum utilizes. This comprehensive guide aims to elucidate how transaction fees work on Solana, providing key insights for developers and users alike. By investigating this crucial aspect, you can better navigate the blockchain and optimize your interactions. Let’s get things started! What is Solana’s transaction fee model? When it comes to transaction fees, Solana takes a path less traveled. Its deterministic transaction fee model distinguishes it from its peers. While many chains, including Ethereum, allow users to willingly boost their gas fee to gain transaction priority, Solana employs a more predictable structure. Each transaction fee on Solana is primarily determined by the computational resources required, including the number of signatures to be verified and the complexity of the transaction. Although Solana's fees can vary based on network demand, the structure tends to be more predictable compared to other blockchains. This deterministic approach simplifies the fee mechanism, offering the benefits of predictability and efficiency to its users. Understanding this system is fundamental for anyone looking to actively interact with applications on the Solana blockchain. For those seeking faster transactions on Solana, it's worth exploring how to use priority fees. By applying priority fees, users can unlock quicker transaction processing times. Learn more about this feature and how to leverage it effectively in our guide on how to use Priority Fees to unlock faster transactions. What are the components of Solana transaction fees? Peeling back the layers of Solana's transaction fees, three main components emerge: Signatures, Lamports per Signature, and Transaction Size. Signatures: Playing the lead role in governing transaction fees on Solana is the count of signatures. Transaction can house multiple signatures, and each of these incurs a fee. Lamports per signature: Fees on Solana are quantified in terms of "lamports," tiny fractions of the native SOL token (1 SOL = 1 billion lamports). Each signature in your transaction costs you a certain number of these lamports. Transaction size: Though not directly influencing the fee, the transaction size plays an indirect yet crucial part. There exists a cap on the transaction size, which, in turn, limits the number of signatures that can be appended. This interplay can impact your transaction fee indirectly. Understanding these components can help you make sense of the transaction fee you're charged, and allow you to fine-tune your operations for efficiency. Next, let's get to know how to calculate these fees using Solana CLI commands. How to calculate transaction fees on Solana? Understanding the theory of transaction fees is only half the battle won. It's equally crucial to know how to actually calculate these fees during your blockchain operations. Solana provides a user-friendly interface to accomplish this—its CLI or command line interface. Here's how you fetch the current fee rate using this tool: Install the Solana CLI: First, you'll need to install the Solana CLI. You can do this by running the following command in your terminal: sh -c "$(curl -sSfL <https://release.solana.com/stable/install>)" Follow the on-screen instructions to complete the installation, where you will need to update your PATH environment. Verify installation: To ensure the CLI is installed correctly, run: solana --version Set the cluster:Set the Solana cluster to use by specifying the URL of your chosen RPC node provider:solana config set --url <your-chainstack-rpc-url> Replace <your-chainstack-rpc-url> with the actual endpoint URLs. Fetch the current fee rate: Once set up, you can fetch the current fee rate by running: solana fees This command will provide you with the latest transaction fee information from the RPC node you are connected to, helping you to calculate and understand the costs associated with your transactions on the Solana blockchain. By setting the appropriate cluster URL, you ensure that your CLI commands are directed to the correct network endpoint, reflecting the specific RPC node provider's infrastructure you are using. Running the solana fees command divulges the current fee rate, along with other blockchain-related information. As of our last update, the fee rate stood at 5,000 lamports per signature. Let's explore a practical instance: Suppose a transaction you execute includes 3 signatures, and the current fee rate is 5,000 lamports per signature. The total cost for this transaction is simply: Total Fee = Number of Signatures × Lamports per Signature Total Fee = 3 × 5,000 = 15,000 lamports How to use getFeeForMessage to calculate transaction fees on Solana? For developers who require granular control over fee estimation in specific transactions, Solana equips you with a powerful method—getFeeForMessage. This feature facilitates precise transaction fee calculation by accepting the serialized form of the transaction as input. Here's how it works: getFeeForMessage(message, commitment) In the method above, message is the serialized transaction, and commitment denotes the level of network confirmation (for instance, "confirmed" or "finalized"). With this knowledge, developers can make precise transactions and potentially save on costs by accurately estimating fees associated. This means your applications can be more cost-effective and aligned with Solana's high-throughput, low-latency design principles. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Bringing it all together Solana's unique transaction fee model has institutionalized predictability and efficiency in its blockchain operations. By foreseeing the cost associated with different actions, developers and users can optimize their blockchain activities. Grasping Solana's deterministic fee model opens up pathways to efficiently operate applications and perform cost-effective transactions. From simple token transfers to building complex decentralized applications, understanding transactions fees can significantly enhance your Solana experience. Overall, this tutorial enables you as a developer to comfortably navigate Solana and make the most of this efficient, high-performance network. Happy building! Power-boost your project on Chainstack #### Solana: How to overcome the 1000 transaction limit using getSignaturesForAddress? Handling large transaction lists can be a daunting task. This is especially true for Solana, as the protocol is only able to fetch up to 1000 transactions at a time. Because of this, fetching the history of transactions for a given wallet address becomes rather problematic. But don't worry, there's a way to overcome this limitation using JavaScript and the Solana Web3.js library. This guide will provide you with an in-depth look at how to handle large transaction lists in Solana using the getSignaturesForAddress function. Let's get started! What is the getSignaturesForAddress method? The getSignaturesForAddress method is a part of the Solana Web3.js library, a JavaScript library that allows you to interact with the Solana blockchain. This method retrieves an array of transaction signatures for transactions involving the specified account. The transactions are sorted by block height in descending order, providing a chronological view of the account's transaction history. Here's a basic example of how to use getSignaturesForAddress: Sign up with Chainstack. Deploy a node. View node access and credentials. Process dependencies and create the function: const solanaweb3 = require('@solana/web3.js'); const connection = new solanaweb3.Connection(solanaweb3.clusterApiUrl('mainnet-beta')); async function fetchTransactions(address) { const pubkey = new solanaweb3.PublicKey(address); const signatures = await connection.getSignaturesForAddress(pubkey); console.log(signatures); } fetchTransactions('YourWalletAddressHere'); In this example, you first import the Solana Web3.js library and establish a connection to the Solana blockchain. You then define an asynchronous function fetchTransactions that takes a wallet address as an argument. Inside this function, you convert the address into a public key and use getSignaturesForAddress to fetch the transaction signatures. Finally, you log the signatures to the console. getSignaturesForAddress pagination how to The getSignaturesForAddress method in Solana's Web3.js library comes with a built-in limitation: it can only fetch up to 1000 transactions per request. This is where pagination comes into play. Pagination is a technique that allows you to fetch data in smaller, manageable chunks, rather than retrieving all the data at once. In the context of Solana, pagination is supported via the before and until parameters in the getSignaturesForAddress method. These parameters allow you to specify a range of signatures, effectively controlling the number of transactions fetched in each request. For instance, if you want to fetch transactions that occurred before a certain transaction, you can use before and provide the signature of the transaction as its value. Similarly, until allows you to fetch transactions that occurred up until a certain transaction. By using these options, you can fetch more than 1000 transactions by making multiple requests, each fetching a different range of transactions. This is a crucial technique for handling large transaction lists in Solana. How to use a loop to automate data retrieval To automate the process of fetching all transactions for addresses with extensive histories, you can use a recursive function or a loop. This approach continuously fetches transactions until all data has been retrieved. Here's a step-by-step breakdown of how to implement this using a loop: Initial fetch: Start by fetching the first 1000 transactions using getSignaturesForAddress. Review and continue: After each fetch, check if the number of transactions is less than 1000. If it is, you've reached the end of the transaction history. If not, you need to continue fetching. Recursive fetch: Use the signature of the last transaction from the fetched list as the before parameter in the next getSignaturesForAddress request. This will fetch the next batch of transactions. Repeat this step until all transactions are retrieved. Here's a complete code example that implements this approach: const solanaweb3 = require('@solana/web3.js'); const connection = new solanaweb3.Connection(solanaweb3.clusterApiUrl('mainnet-beta')); async function getAllTransactions(address) { const pubkey = new solanaweb3.PublicKey(address); let allTransactions = []; let fetchedTransactions; let lastSignature = null; do { fetchedTransactions = await connection.getSignaturesForAddress(pubkey, { before: lastSignature, limit: 1000 }); allTransactions.push(...fetchedTransactions); lastSignature = fetchedTransactions.length > 0 ? fetchedTransactions[fetchedTransactions.length - 1].signature : null; } while (fetchedTransactions.length === 1000); return allTransactions; } getAllTransactions('YourWalletAddressHere').then(transactions => { console.log('Total transactions fetched:', transactions.length); }); In this example, you define an asynchronous function getAllTransactions that fetches all transactions for a given address. Inside the function, you use a do-while loop to continuously fetch transactions until all have been retrieved. After each fetch, you check if the number of fetched transactions is less than 1000. If it is, you’ve reached the end of the transaction history. If not, you use the signature of the last transaction as before in the next getSignaturesForAddress request. This ensures that you fetch the next batch of transactions in the next request. Finally, you log the total number of fetched transactions to the console. Large transaction list handling best practices Retrieving a large number of transactions can be resource-intensive and time-consuming. Therefore, it's important to consider performance when implementing a solution for handling large transaction lists in Solana. Here are some tips to handle large data efficiently: Rate limiting: Solana's public and provider RPC servers impose rate limits to prevent abuse (find ours here). If you're making a large number of requests in a short period of time, you might hit these limits. To avoid this, consider using a Chainstack node or adding delays between requests to spread out the load. Concurrency: If you're processing transactions in parallel, it's important to implement concurrency control. This can prevent your system and your RPC node from being overloaded with too many simultaneous requests. You can do this by limiting the number of concurrent requests or using a queue to manage requests. Logging: Adding logging at critical steps can help you monitor the progress of your transaction fetching process. It can also help you troubleshoot any issues that might arise during the process. For instance, you can log the number of fetched transactions after each request, the total number of transactions fetched so far, and any errors that occur during the process. By considering these performance aspects, you can ensure that your solution for handling large transaction lists in Solana is not only effective but also efficient and reliable. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Bringing it all together Handling large transaction lists in Solana can be a challenging task due to the 1000 transaction limit of the getSignaturesForAddress function. However, with the right approach, you can overcome this limitation and fetch all transactions for a given address. By using a loop to paginate through results from getSignaturesForAddress, you can effectively manage and retrieve extensive transaction histories on the Solana blockchain. This approach is invaluable for developers working on applications that require access to complete transaction data. It provides a robust foundation for building reliable and efficient Solana programs. Remember, while this guide focuses on JavaScript and the Solana Web3.js library, the principles and techniques discussed can be applied to other languages and chains as well. So, whether you're developing a high-frequency trading platform or a popular Solana DApp, don't let large transaction lists slow you down. With the right tools and techniques, you can handle any amount of transaction data with ease. Happy coding! Power-boost your project on Chainstack #### Solana: How to retrieve historical data effectively? One crucial aspect to grasp when dealing with Solana is the understanding of its account model. Accounts in Solana are where things get interesting as they serve as an interactive hub between data, tokens, and programs. But how does it function exactly? And what hindrances are posed by Solana's native method of handling historical data? Let’s find out! What is Solana’s Account Model? In Web3, account models can vary across platforms, and understanding these differences can be crucial to efficient navigation and utilization of the blockchain. Unlike your traditional account setup, Solana adopts a more interactive and multifunctional model. On the Solana platform, accounts play a dual role: as holding pots for data and SOL, Solana's native token, and as engines facilitating interaction with programs or smart contracts. Every transaction made on Solana modifies the state of one or more accounts, designated by their corresponding public keys. This dynamic nature of Solana's accounts allows for a wide range of possibilities, from holding mutable data to complex programmable interactions. How to fetch historical data on Solana? Although versatile and powerful, Solana's account model presents a unique challenge for developers and users alike: retrieving historical account information. Unlike some blockchains that keep an immutable record of all past states, Solana's ledger is focused on the present. When a transaction occurs on Solana, the state (or balance) of the related account(s) is modified. Standard operations entail that any previous state of the account gets overwritten by the new one unless explicit archiving steps were implemented beforehand. This characteristic creates a hurdle for those wishing to study or review the historical account states at particular timestamps. Retrieving historical account information on Solana is by no means straightforward, but it is feasible. The key lies in understanding the various methods at your disposal and selecting one that best aligns with your specific needs and available resources. Method 1: Replay transactions The first approach to source historical account states in Solana involves a method known as transaction replay. Think of it as tracing your steps back in time. By replaying transactions in reverse from a known state, you can reconstruct historical account states. Follow these steps: Identify the accounts of interest. Retrieve the current state and all previous transactions involving the identified accounts. Reverse the transaction sequence to find the account states at earlier times. This process can be labor-intensive and intricate as it calls for precise reversal of transactions, a task that could depend heavily on the context given by other account states and global blockchain parameters at the time. Moving on to the next method. Method 2: Use Geyser plugins for data storage Another approach to glean historical data involves the use of Geyser plugin within Solana. These plugins enable developers to tap into the life cycle events of the blockchain, such as confirming and adding blocks. Here are the essential steps: Set up a Solana RPC node. Incorporate a Geyser plugin to capture and stash away account states at specific conditions or intervals. Store this data within a readily searchable database, like MongoDB or PostgreSQL. This strategy simplifies querying of historical states but also demands considerable storage space and maintenance of infrastructure. Method 3: Use third-party data services When in-house data retrieval processes look daunting, turning to third-party services can be a viable option. Many of these platforms offer extensive historical blockchain data that can be accessed via RESTful APIs or client libraries, significantly easing the process. Here are some examples: Solana Explorer SolanaFM BigQuery datasets for Solana Each of these services provides a unique set of data and tools, and one should select based on their specific needs and resources. How to construct Solana transaction graphs? Having access to and comprehending historical account data is a start, but visualizing it can offer another layer of understanding. Creating transaction graphs permits users to trace the activity flow between accounts over time or track the interactions between different accounts and smart contracts. Here are some useful tools and libraries: NetworkX: This versatile Python tool is immensely helpful for constructing intricate network graphs. D3.js: A very intuitive JavaScript library for creating dynamic and interactive data visualizations right in web browsers. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Solana transaction commitment level: What is the right transaction commitment level for your use case? Bringing it all together Accessing historical AccountInfos on Solana is undeniably intricate but not impossible. With three diverse approaches available: replaying transactions for precision, using Geyser plugin to continuously seize data, or deploying third-party tools for convenience, you enjoy the freedom to select based on your specific requirements and resource capabilities. Each method, though, bears its unique complexities, costs, and data completeness factor. For research purposes, weigh in all these aspects judiciously in making an informed decision. Happy building! Power-boost your project on Chainstack #### Solana: How to use Program Derived Addresses for state management Stepping into Solana blockchain development introduces a host of unique concepts, one of which is the enigmatic Program Derived Address, or PDA. For developers keen on harnessing the full might of Solana, especially when working on decentralized applications that demand intricate interaction and state management, understanding PDAs is non-negotiable. In this comprehensive guide, we'll shed light on what PDAs are, what sets them apart from regular blockchain addresses, and why they're essential in the Solana ecosystem. Furthermore, we'll explore their various use cases, how they're created, and the numerous benefits they offer to developers in their projects. Let’s kick thing off! What are Program Derived Addresses in Solana? Think of a PDA as not just an address, but a new breed of blockchain address complete with properties that make it stand out from the crowd of generic blockchain addresses. While your typical blockchain address boasts a linked private key enabling its owner to sign transactions, a PDA takes a different approach—it doesn't have a corresponding private key. Instead, a PDA is the offspring of your program's ID and some additional seed data, deterministically created to serve specific functions. A PDA might bear a striking resemblance to an average public key, but its charm lies in its creation and utilization—a freshness we'll explore in this guide. Effectively, PDAs are breaking the mold, redefining what a blockchain address can be, and in the silhouette of Solana development, they offer a broadened horizon of possibilities. As you navigate further into the world of PDAs, come prepared to be wowed by their unique capabilities and extensive application range. Why use Program Derived Addresses in Solana development? So far, we've understood that a PDA isn't just another address on the Solana blockchain, but a different breed with remarkable attributes. The natural question then becomes, why use one? The answer is multifaceted and hinges on two primary uses: storing program state and signing for cross-program invocations. A core utilization of the PDA is to store the state of a program. In the landscape of blockchain, "state" refers to stored information imperative for a program to function aptly. This information could be as varied as user balances, game scores, or contractual terms—the possibilities are infinite. If you're dealing with an application that requires complex state management, the PDA proves to be a trusted ally in your development journey. Additionally, PDAs flex their muscles in authorizing actions in other programs within the Solana ecosystem independently, without the need for a private key. This capability becomes integral when dealing with cross-program invocations, where one program has to trigger actions in another program safely and effectively. As you're building and managing intricate decentralized applications, the PDA becomes a staunch partner, helping you navigate the complex web of program interactions with ease and efficiency. In the broader canvas of Solana development, engaging with PDAs provides developers a new capability in state management and complex program interaction, making them a great choice when developing complex decentralized apps. Stick with us as we delve deeper into the comprehensive benefits and various use cases of PDAs. What are the use cases of Program Derived Adressess in Solana? At this point, you might be wondering about the detailed strengths and applications of PDAs. The advantages of using PDAs are far-reaching and revolutionize how developers address and manage data. One such benefit is the creation of a hashmap-like interface. PDAs give developers the liberty to index accounts in an efficient manner. This translates to a more orderly and accessible way of storing and retrieving data associated with different accounts. To generate a PDA, the seeds used can be quite varied, from public keys to strings to arrays of numbers, bestowing developers with the flexibility to manage data. PDAs also help avoid manual address management. Without PDAs, developers would have to remember and manage all addresses where data is stored manually. This can clog up the program, making it less efficient, and can be especially cumbersome as the scale of data and interactions grows. Furthermore, PDAs, acting as an intermediary between various related programs, ensure secure and efficient communication. They sign for cross-program invocations, allowing one program to trigger another without needing the regular signature from private keys. It adds an added layer of security and convenience to Solana applications development. Imagine a superhero figure in the Solana blockchain universe that can manage state data, authorize actions in cross-program invocations, create a hashmap-like interface, and avoid manual address management. You now have an understanding of the power and potential of PDAs. Let's now look into how these superheroes are created. How are Program Derived Addresses created in Solana? Now that we've built a solid understanding of PDAs and their benefits, it's time to peel back the curtain and explore how they come into being. The creation process is as unique as the PDAs themselves and involves specific steps: The first step is deciding on a Program ID, which essentially is the identifier of the smart contract or program that will interact with or claim ownership of the PDA. Secondly, you provide seed data. These seeds, which can be any piece of data ranging from public keys to strings, work together with the program ID to make the PDA truly unique. The interplay of the program ID and seed data is what gives life to the PDA. Finally, you employ the Solana development kit or SDK. It houses the tools needed to deterministically generate PDAs based on the input data. With the right combination of program ID and seed data and the magic of the Solana SDK, your PDA is ready for action. It's important to bear in mind that even though creating PDAs unlocks new possibilities in managing program states and interactions, it also brings its own set of considerations. As we venture further, we will touch on the practical aspects that one needs to consider when working with PDAs. Program Derived Addresses in Solana: Practical considerations Embracing the use of Program Derived Addresses does not come without its due diligence. Understanding a few practical aspects will ensure that developers enjoy the benefits of PDAs while avoiding any potential pitfalls. The key points to consider include: Deterministic generation: A crucial aspect to take into account is that the PDA should be reproducible at any time using the same seed and program ID. This consistency is fundamental to the functioning of a PDA, ensuring that the application can retrieve the same address whenever required. Collision resistance: Another critical consideration is the potential collision of generated PDA with existing addresses. Such an overlap could lead to data corruption or loss—a scenario any developer would want to avoid. When crafting the combination of seed data and program ID, it’s important to ensure it produces a unique address eliminating the chances of any collision. Program permissions: Since PDAs are capable of authorizing actions on behalf of the program for cross-program invocations, defining and managing the permissions associated with them becomes paramount. These permissions will prevent unanticipated and unauthorized actions, providing a safeguard against potential security issues. Observance of these considerations will ensure a smooth sailing experience on your journey with PDAs. From here, we step back to see the bigger picture, looking at PDAs in the grand scheme of Solana blockchain development. The exploration into this fascinating topic continues as we elucidate how PDAs are changing Solana blockchain development for the better. The bigger picture of Program Derived Addresses in Solana Now that we've dug deep into the nuts and bolts of Program Derived Addresses, let's step back and assess what they bring to the table in the landscape of Solana blockchain development. Program Derived Addresses are not just a novel concept; they are a powerful resource for developers. By understanding and utilizing PDAs, developers can greatly enhance the security, efficiency, and scalability of their applications on the Solana blockchain. They simplify complexities, minimize manual labor, and securely connect different blockchain programs, creating a streamlined developer experience. In essence, PDAs extend the reach of a program beyond its boundaries. They can store program state and enable cross-program invocations, opening gates to more intricate app interactions. The deterministic generation protocol also makes them collision-resistant, reducing the risk of data corruption and promoting secure, efficient data storage. They not only make state management easier in decentralized apps but also breathe life into the concept of hashmap-like interfaces, transforming how developers interact with and manage data in blockchain. The magic of PDAs is that they amplify the power of the Solana blockchain ecosystem, making it more accessible and powerful for developers. By mastering the use of PDAs, developers can scale new heights in Solana blockchain development, creating decentralized applications that are robust, scalable, and efficient. Bringing it all together If you're captivated by Program Derived Addresses and their potential for revolutionizing Solana blockchain development, then the learning journey isn't over yet. Here are a few resources that delve deeper into PDAs and their usage. These will provide not only a theoretical understanding but also equip you with practical knowledge: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Each resource offers unique insights and practical examples that can help developers of all levels master the use of Program Derived Addresses in their development journey in Solana-based projects. With these tools at your disposal, you are well-equipped to make the most of PDAs in your next development project. Thank you for joining us on this fascinating exploration of Program Derived Addresses. We hope this guide was enlightening and possibly transformative for your development endeavors on the Solana blockchain. Let's build the future, one PDA at a time! #### Solana: Instructions and Messages Solana applications run through a clean and deterministic model: programs expose instructions, and every transaction bundles those instructions into a signed message that validators can verify and execute in parallel. This article walks through instructions, messages, legacy formats, and the newer versioned messages powered by Address Lookup Tables, giving you a clear mental model of how Solana defines “what should happen” in every transaction. Solana executes transactions through a simple structure: instructions define what to run, messages define everything needed to run it, and signatures prove who approved it. Legacy messages list all accounts inline, while v0 messages use Address Lookup Tables so complex DeFi transactions can reference many more accounts without hitting Solana’s strict size limits. Instructions Instructions are the core unit of execution on Solana. Think of each instruction as a function call exposed by an on-chain program. Every program defines its own instruction set, the specific actions it can perform. When you interact with the network, you don’t call programs directly, you package one or more of their instructions into a transaction, sign it, and submit it for execution. Instruction consists of ProgramId Accounts Instruction-specific data ProgramId The on-chain Id of the program (address) that contains the logic of the instruction Accounts Each instruction includes an array of AccountMeta entries, metadata describing every account it will read from or write to. By explicitly listing these accounts, Solana’s runtime can determine which instructions are independent and safely execute them in parallel, as long as they don’t modify the same account. is_signer: Set to true if the account must sign the transaction is_writable: Set to true if the instruction modifies the account’s data pubkey: The account’s public key address Data The instruction’s data field is a sequence of bytes that tells the program which specific function to execute and includes the parameters needed for that call. Example (Simple 0.01SOL Transfer) { “program_id”: “11111111111111111111111111111111”, “accounts”: [ { “pubkey”: “6uR7N6oDgE3vJXvM6Eh4xVHw2g7o7YhA7FJxC4pXcZtT”, “is_signer”: true, “is_writable”: true }, { “pubkey”: “3Nq8yVbGz7KpYw9sT6rF2LmHc4Qz5XvA1uJd8BvCzRy”, “is_signer”: false, “is_writable”: true } ], “data”: [2, 0, 0, 0, 128, 150, 152, 0, 0, 0, 0, 0] } program_id That’s the System Program Solana’s built-in program for managing native SOL transfers, creating accounts, and assigning ownership. Every validator includes this program by default. This tells the runtime Call the System Program to execute one of its functions accounts: 6uR7…ZtT: Sender, must sign and can be modified (lamports will be deducted). 3Nq8…zRy: Recipient, writable because lamports will be added, but no signature required. data: Each data variant encoded as [variant_index:u32][variant_payload]in our case: pub enum SystemInstruction { CreateAccount { ... }, Assign { ... }, Transfer { lamports: u64 }, ... } Transfer variant is at index 2 and its payload is u64 (8-bytes) [2, 0, 0, 0, 128, 150, 152, 0, 0, 0, 0, 0] which is: [02 00 00 00 | 80 96 98 00 00 00 00 00] // 4 + 8 = 12 [0:4) bytes Type: u32 Value: 2 :  in this program source code we can see that Transfer is at index 2 in the SystemInstruction enum [4:12) bytes Type: u64 Value: 10000000 lamports [2, 0, 0, 0] → discriminant = 2 [128, 150, 152, 0, 0, 0, 0, 0] → bytes to hex [80 96 98 00 00 00 00 00] → hex representation [0x00000000989680] → 0x00989680 = 10_000_000 lamports (0.01 SOL) Messages A transaction on Solana is more than just a list of instructions it’s a message signed by one or more accounts. The message defines exactly what will run, which accounts are involved, and which recent blockhash anchors it to the chain’s current state. Solana signs the message, not each instruction individually. That design makes transactions compact and verifiable: a validator only needs to check that the signers authorized the same message bytes the network received. Once signatures are verified, the runtime executes the instructions in order and commits all changes atomically either everything succeeds or the whole transaction reverts. In other words: The message is the canonical record of “what should happen” The signature just proves “who approved it” Legacy and Versioned Messages Originally, all Solana transactions used a single message format, now referred to as the legacy message. It worked well for simple transfers and small programs, but every transaction must list all accounts it will read or write (For the purpose of parallel execution). Since each account address is 32 bytes, the total message size grows quickly, and Solana enforces a strict upper bound (≈ 1232 bytes for serialized transactions) to fit inside the network’s MTU. That limited legacy transactions to about 35 accounts, which became a problem for complex, composable DeFi protocols that interact with many programs at once. To solve this, Solana introduced versioned transactions, starting with v0 messages, along with a new on-chain program called the Address Lookup Table (ALT) program. Lookup tables let developers store groups of addresses on-chain and reference them later by small 1-byte indexes instead of full 32-byte keys. The transaction can then “look up” additional accounts during execution without exceeding the size limit. Legacy Messages pub struct Message { pub header: MessageHeader, pub account_keys: Vec<Address>, pub recent_blockhash: Hash, pub instructions: Vec<CompiledInstruction>, } pub struct MessageHeader { pub num_required_signatures: u8, pub num_readonly_signed_accounts: u8, pub num_readonly_unsigned_accounts: u8, } // As learned previously pub struct CompiledInstruction { pub program_id_index: u8, pub accounts: Vec<u8>, pub data: Vec<u8>, } Note: the #[serde(with = “short_vec”)] is important and we will see later why can hold about 35 accounts (35 * 32(address size) = 1120bytes out of 1232) we can see that it is holds a fixed header, accounts, blockhash, instructions and can be used for simple or medium transactions. Versioned Messages pub enum VersionedMessage { Legacy(LegacyMessage), V0(v0::Message), } pub struct Message { pub header: MessageHeader, pub account_keys: Vec<Pubkey>, pub recent_blockhash: Hash, pub instructions: Vec<CompiledInstruction>, /// List of address table lookups used to load additional accounts /// for this transaction. #[serde(with = “short_vec”)] pub address_table_lookups: Vec<MessageAddressTableLookup>, } pub struct MessageAddressTableLookup { pub account_key: Pubkey, #[serde(with = “short_vec”)] pub writable_indexes: Vec<u8>, #[serde(with = “short_vec”)] pub readonly_indexes: Vec<u8>, } Transactions must fit in ~1232 bytes of packet payload. Listing every account inline (32 bytes each) caps legacy messages at ~35 accounts after signatures/overhead. V0 introduces Address Lookup Tables (ALTs) so a message can reference many accounts by 1-byte indexes instead of inlining 32-byte pubkeys. How address lookup works At runtime, the validator constructs a single resolved account list that instructions index into: resolved_keys = [ message.account_keys , looked_up_writable_keys (from all ALTs, in order) , looked_up_readonly_keys (from all ALTs, in order) ] Each MessageAddressTableLookup points to a specific on-chain ALT (account_key). writable_indexes and readonly_indexes are u8 indexes into that ALT’s stored addresses. The runtime fetches those pubkeys and appends them to resolved_keys in two groups: all writable lookups (preserves order across tables) all readonly lookups (preserves order across tables). program_id and accounts still point into this combined list exactly like legacy messages. how v0 is identified Versioned transactions use a leading version bit in the message encoding: If the top bit of the first byte is set, the remaining bits encode a version number (v0 = 0). If not set, it’s treated as a legacy message. You won’t usually touch this directly, SDKs handle it but it’s why v0 and legacy can coexist. Size implications v0 adds small overhead but dramatically reduces inline key bytes when many accounts are needed Added overhead per transaction (approx) this is at least sizes: +1 byte: version tag +1 byte: address_table_lookups length +34 bytes per lookup table (32 for table pubkey + 1 + 1 for lengths of writable/readonly index arrays) +1 byte per looked-up index (each index into the ALT) Saved space: each looked-up address replaces a 32-byte inline pubkey with a 1-byte index in the message. When you reference dozens/hundreds of accounts, this tradeoff wins easily Limits and rules to remember 256 max entries per ALT. Indexes are u8. Up to 256 unique accounts can be loaded overall (since compiled instruction account indexes are u8 as well). Signers cannot come from ALTs. All signer keys must appear in account_keys so their signatures can be verified efficiently. No duplicates. The same account may not be loaded more than once across account_keys and ALT lookups. ALT availability: Newly appended ALT entries become usable after one slot (warm-up). ALT lifecycle: Tables must be rent-exempt, are append-only, can be deactivated, and only closed after a cooldown to avoid censorship/race issues Lets make sense of the numbers and why those are the limits Lets look at the confusing statements from before 256 max entries per ALT. Indexes are u8:Each Address Lookup Table (ALT) can store up to 256 addresses because the indexes used to reference them are u8 (1 byte). pub writable_indexes: Vec<u8>, pub readonly_indexes: Vec<u8>, Each element in those vectors is a single byte → range 0–255.So when we say: writable_indexes = [0, 2, 4, 6] the runtime loads the 0th, 2nd, 4th, and 6th addresses from that table’s on-chain storage. Hence Max 256 because u8 can encode 0–255 possible values, means 256 unique entries per lookup table(this is impossible: writable_indexes = [0, 2, 310]). 1 byte: address_table_lookups lengthThe first question that can come up to mind is, why only the lenght only 1 byte if it is a vector which might be unlimited. the magic is in#[serde(with = “short_vec”)] which meansThis Vec<…> in Solana’s serialized structs uses a short_vec format.That’s how Bincode (via the short_vec module) serializes variable-length arrays efficiently[length (1-9 bytes)][elements...]For small vectors (length < 128), the length fits in a single byteIf you have 3 lookup tables, that length byte would literally contain 0x03.It means there’s one byte added to encode how many lookup tables are attached, before serializing their contents. 34 bytes per lookup table (32 + 1 + 1)This is the same the prev statement, take a look that pub struct MessageAddressTableLookup { pub account_key: Pubkey, #[serde(with = “short_vec”)] pub writable_indexes: Vec<u8>, #[serde(with = “short_vec”)] pub readonly_indexes: Vec<u8>, } serialized with #[serde(with = “short_vec”)] means that every MessageAddressTableLookup needs at least 34 bytes + N-bytes for each entry. MessageHeader The header tells the runtime how many accounts must sign, and which accounts are read-only. It’s the preamble the runtime uses to understand how to interpret the account_keys slice. num_required_signatures (u8) How many of the first account_keys must provide signatures. If this is 1, the first key in account_keys is the signer. If this is 2, the first two keys are signers, etc. These signatures come from the transaction’s signature array. Every signer must match with its position in the account_keys. num_readonly_signed_accounts (u8) Among the signer accounts (the first num_required_signatures), how many of them are read-only. They can be read, but the program cannot modify their account data or lamports. This prevents accidental or malicious modification of signer accounts when they don’t need to be writable. Example: A user signs a transaction using their wallet (signer), But that wallet account is never written to so it should remain read-only. num_readonly_unsigned_accounts (u8) Among the non-signers (the remaining accounts), how many of them are read-only. Why this matters:Some accounts are passed to a program as read-only e.g., system program, token program, metadata program. Marking them read-only improves security and performance. recent_blockhash This field prevents replay attacks and sets a liveness requirement. Solana does not use nonces. Instead, every transaction must include a recent blockhash from the last ~150 blocks (≈ 2 minutes). Why it’s required Anti-replayIf someone copies your signed transaction and tries to submit it again, it will be rejected because the blockhash is too old. Transaction expirationSolana requires transactions to be “fresh.”If the blockhash is too old, the validator won’t accept the transaction. Fork commitmentValidators agree that transactions built on a recent blockhash belong to the current fork, reducing ambiguity. Summary You should now understand how Solana structures the logic behind every transaction. An instruction defines what to run, the program, accounts, and data, while a message bundles those instructions together into an atomic unit that can be signed and verified. Legacy messages work for most cases, but v0 messages extend the format with Address Lookup Tables, allowing many more accounts to be referenced through compact 1-byte indexes.In short, you now know how Solana encodes what happens in a transaction. 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: Master guide to troubleshooting common development errors Solana is a powerful blockchain ecosystem that enables developers to build high-performance DApps. However, like any development platform, it comes with its challenges. This master guide will help you troubleshoot common errors encountered during Solana development, including Rust version conflicts, Borsh serialization issues, blockstore errors, and module parse errors. By understanding these problems and following our step-by-step solutions, you can ensure a smoother development experience and focus on creating robust applications. Let’s get started! What are Rust version conflicts in Solana? When working with Solana development tools, like Anchor, you might occasionally encounter versions clashing between your locally installed Rust compiler (rustc) and the versions demanded by your Solana dependencies. The error messages can be cryptic, and the solutions not always straightforward. The conflict arises mainly due to a mismatch between the rustc version that a Solana package expects and the version that is currently running on your system. It's perplexing, indeed, when your local rustc version is newer than the one required and still, errors pop up. Consider this scenario—you received an error message that reads: *error: package solana-program v1.16.3 cannot be built because it requires rustc 1.68.0 or newer, while the currently active rustc version is 1.62.0-dev.* To add to the confusion, your local Rust version shows as rustc 1.75.0. This clearly indicates that the environment in which anchor is running might not be using the global rustc version. Until now, this might've seemed like a perplexing puzzle to you, but in the following sections, we will help you piece this mystery together one step at a time. What causes Rust version conflicts in Solana? Version conflicts in Solana often trace back to a few common causes. Identifying these can be a critical first step on the path to resolution. The first culprit often lies in having multiple Rust versions. You might install both a stable and a nightly or development version of Rust which can lead to conflicts. Issues can also arise when the system prioritizes one version of rustc over another in the PATH environment variable, causing an Environment Path Priorities issue. Moreover, sometimes the Rust version conflict roots back to your project configuration itself. The Toolchain Configuration in cargo.toml might specify a different Rust version through a rust-toolchain file or similar settings. By pinpointing the source of the conflict, you can tackle the issue head-on. But diagnosis is just the first part. In the following sections, we will guide you step-by-step through the resolution process. How to resolve Rust version conflicts in Solana? Once you've identified the possible causes, it's time to take action. Let's tackle each issue, one step at a time. Step 1: Verify the Rust version Start by confirming the version of Rust installed globally. Execute the command rustc --version to check the active Rust version. If it matches the latest version you believe you installed, move on to the next step. Step 2: Check for multiple Rust installations Detect additional Rust installations that might cause conflict by using the command which -a rustc. This command lists all occurrences of rustc in the order they appear in your PATH. A list with more than one version indicates potential trouble. Step 3: Adjust the PATH environment variable With multiple Rust installations, it's crucial to ensure the path to the desired Rust version appears first in your PATH environment variable. Consider modifying your .bashrc, .zshrc, or equivalent shell configuration file to adjust the PATH order. The command export PATH="/path/to/desired/rust/bin:$PATH" helps achieve this. Step 4: Specify your Rust version in cargo.toml Your project depends on a specific Rust version? Mention that in the cargo.toml file using a rust-toolchain file: [toolchain] channel = "1.68.0" This step ensures Cargo uses the correct Rust version for your project. Step 5: Use the rustupoverride if needed For project-specific Rust versions, apply rustup to set an override. The command rustup override set 1.68.0 designates the Rust compiler version for the current project directory only. Alternative solution: Downgrading the Solana package In some situations, despite your efforts, version conflicts might continue to occur. If you find yourself unable to resolve the Rust version conflict, consider downgrading your Solana package to mitigate the issue. As a last resort, to bypass the conflict, adapt your Solana tool suite to a version that aligns with your Rust environment. You can do this using the command solana-install init 1.16.3. This command installs the specified version of the Solana tool suite. Though it might seem like a step back, aligning your tools can often lead to a smoother development experience. Remember, the key to a successful development environment is harmony among the tools. What are Borsh serialization errors in Solana? Let's get down to basics, shall we? When you encounter the message error[E0277]: the trait bound Pubkey: BorshSerialize is not satisfied, it's the Rust compiler waving a red flag at you. But, what for? It's because it simply cannot find an implementation of the BorshSerialize trait for the Pubkey type within your project's serialization framework. Let's break that down a bit. You see, in Solana programs, the Pubkey type is frequently used to represent public keys of accounts. Seeing this error indicates that the implementation of the BorshSerialize trait for the Pubkey type is missing in your project, or it's not properly visible. But fret not, understanding this error is the first step towards solving it. Let's move on to the next section, where we decipher what causes this error. What causes Borsh serialization errors in Solana? Troubleshooting an error often involves a journey of discovery back to its roots. Similarly, understanding the situations that commonly birth this error can save you a lot of time and headaches. Typically, the the trait BorshSerialize is not implemented for Pubkey error emerges from one of these scenarios: Mismatched Borsh versions: It's a chaotic world out there with mutable versions of Borsh library in the various crates of your cargo.toml. This version variance can bring about incompatibilities, giving rise to our error in question. Incorrect or missing Borsh traits: In certain instances, your project configuration might have the required Borsh traits absent or incorrectly implemented. These traits might also go amiss due to updates in dependent crates. Now that we have the potential culprits identified, let's proceed further to diagnose these causes in detail. Ready to turn that error into a solution? On we move! How to diagnose Borsh serialization errors in Solana? Diagnosing this error is similar to a detective following clues to solve a mysterious case. The first clue is to confirm that all dependencies are correctly mentioned and compatible. You can start this investigation by inspecting your Cargo.toml and Cargo.lock files. These files contain information about the versions of borsh utilized by your dependencies. For example, if a crate demands borsh@0.9.3 while another requires borsh@0.10.3, you must ensure these versions do not compete or result in unsatisfied traits. By verifying the compatibility of Borsh versions, you can pinpoint where the issue originates. Sharpen your detective skills and follow these clues. With the right diagnosis, you're one step closer to resolving this error. The solution is almost within your grasp! How to solve Borsh serialization errors in Solana? As promised, here is a systematic approach to remedying the Borsh serialization error. Hold on tight, we’re off to a troubleshooting adventure! Verify project dependencies: Start at your project's root—the cargo.toml file. Run a thorough check for any direct or indirect dependencies on Borsh and ensure they are on compatible terms. [dependencies] anchor-lang = "0.28.0" anchor-spl = "0.28.0" solana-program = "1.14.19" mpl-token-metadata = "1.12.0" Clean and update the Cargo environment: Next, clear the path by running anchor clean to get rid of any build artifacts causing obstacles. Then, refresh the environment by executing cargo update. This helps update the dependencies as specified in cargo.toml. Manage dependencies explicitly: If the trouble persists, it's time to don the hat of a debugger. Start considering manually adjusting the versions of conflicting crates, which might require pinning certain dependencies to specific versions known for their compatibility. cargo update -p solana-zk-token-sdk --precise 1.14.19 cargo update -p borsh@0.10.3 --precise 0.9.3 These commands compel cargo to use specific versions that could resolve conflicts. Compile and test: Now that the changes are in place, it's time to see if the problem is solved. Compile your updated project using anchor build. It's always a best practice to run your tests too, ensuring no other parts of your program are affected by these changes. Advanced tips to resolve Borsh serialization errors in Solana Now that you know how to resolve the Borsh serialization error, let's take a small detour to arm you with more knowledge for smoother expedition in the Solana development landscape. Understanding Borsh: Learning how Borsh serialization functions can be an enormous asset. A thorough understanding of how it serializes and deserializes data will enable you to debug and resolve serialization-related errors more effectively. Community and documentation: Don't forget the power of community and documentation. Engage with the Solana and Rust communities for shared experiences, as there are likely many developers who encountered similar issues and can provide prompt solutions or workarounds. Additionally, the official documentation can be your best friend—it's always a great place to refer to when you're using certain dependencies. What are blockstore errors when using Solana test validators? While working with the Solana test validator, one common issue you might encounter is the blockstore error. Easy to recognize but sometimes challenging to understand, it often arises due to the compatibility nuances between macOS and Solana's required configurations. In the pursuit of compatibility, Solana has integrated a set of tools and dependencies that ensure its smooth operation. However, occasionally this integration presents challenges, particularly for macOS users. The manifestation of this challenge is often a blockstore error, an indication that something is not running harmoniously. Why does this happen? The macOS operating system uses BSD tar by default, a variant that differs from GNU tar which Solana is compatible with. These differences in tar's version lead to the blockstore error. Now that we’ve outlined the problem, let’s explore how to resolve it. How to resolve blockstore errors in Solana test validators? When encountering a blockstore error, fear not. We have a step-by-step guide to lead you from confusion to clarity and from problem to resolution. Step 1: Install Homebrew To begin the process, we must first install Homebrew, a package manager making software package management on macOS easy. If you haven't installed it yet, merely open your terminal and execute the following commands. It will download and install Homebrew on your device: /bin/bash -c "$(curl -fsSL <https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh>)" The system will guide you through the on-screen instructions to complete the installation. Next, let's install GNU tar. Step 2: Install GNU tar With Homebrew at your disposal, installing GNU tar becomes a seamless task. Open your terminal and enter the command below: brew install gnu-tar This command will install GNU tar and incorporate it into a specific directory under Homebrew's management. You're halfway there! Now, we will take care of the PATH environment variable. Step 3: Update the PATH environment variable Updating your PATH environment variable is a vital step in resolving the blockstore error. It allows you to set the preferences so that the terminal uses the newly installed GNU version of tar instead of its default BSD variant. Run the following command to update your PATH: echo 'export PATH="/opt/homebrew/opt/gnu-tar/libexec/gnubin:$PATH"' >> ~/.zshrc source ~/.zshrc In running this command, you're adding the directory containing GNU tar to the front of your sequencing PATH, ensuring that it's the default command the terminal implements when invoking tar. Now, it's time to verify that we have successfully replaced BSD tar with GNU tar. Step 4: Verify the installation You can always ascertain whether your installation was successful by running the command: tar --version If the output correlates to GNU tar, congratulations! You have successfully replaced BSD tar with GNU tar, effectively preparing your device for an error-free Solana test validator experience. Now you just have to restart the validator. Step 5: Restart the Solana test validator With GNU tar now installed and designated as the default, you can confidently restart the Solana test validator. To start the validator without encountering the blockstore error, type: solana-test-validator There you have it! Now your validator should run smoothly without any hindrances. What is the Module parse failed build error? When building React Native projects that utilize the @solana packages, you can often encounter a specific error. This error typically looks something like this: Module parse failed: Identifier directly after number (3673:30) You may need an appropriate loader to handle this file type. | key: "isActive", | value: function isActive() { > var U64_MAX = Math.pow(2n, 64n) - 1n; | return this.state.deactivationSlot === U64_MAX; | } This error message indicates a syntax or parsing issue. It's usually triggered when the project's build system doesn't properly handle modern JavaScript features such as BigInt literals. Understanding this error is the first step towards resolving it. How to diagnose Module parse failed build error? To effectively resolve the error, it's important to diagnose the problem and understand its root cause. Here are two key aspects to consider: BigInt and Math.pow(): The core of the error lies in the use of Math.pow() with BigInt (2n, 64n). Math.pow() is designed for numbers only and cannot handle BigInt. In JavaScript, 2n ** 64n would correctly use BigInt. However, certain transformations in the build process may convert this into a format using Math.pow(), which then leads to the process failing. Compiler configuration: The JavaScript version targeted by the compiler is another aspect of this issue. The use of BigInt literals directly (2n) is supported in ES2020 and later. If the project's compiler configuration targets an earlier JavaScript version, this can also trigger build errors. By diagnosing the problem, you can better understand the error and find effective solutions to resolve it. How to resolve the Module parse failed build error? And speaking of solutions, once the problem has been diagnosed, you can take steps to resolve the error. For example: Adjust compiler settings:Upgrade ECMAScript target: One of the simplest approaches is to ensure your build process, such as Babel, targets at least ES2020. You can set this in your Babel configuration (babel.config.js or .babelrc) by specifying the target version:{ "presets": [ ["@babel/preset-env", { "targets": ">= ES2020" }] ] } Custom Babel plugin configuration: If using specific plugins like babel/plugin-transform-exponentiation-operator, ensure they are correctly configured or updated to avoid transforming BigInt operations incorrectly. Modify code directly: If you have control over the source code generating the error, consider replacing Math.pow(2n, 64n) - 1n with 2n ** 64n - 1n directly in the source or using BigInt functions explicitly, e.g., BigInt(2) ** BigInt(64) - BigInt(1). Report and collaborate: If modifying the library directly isn't feasible, consider filing an issue on the library’s GitHub page (e.g., @solana-labs/solana). This could prompt a permanent fix in the library itself that would benefit all users. Test and verify: After making these changes, ensure to thoroughly test your application to verify that the build error is resolved and that it behaves as expected with Solana functionalities. By implementing these solutions, you can effectively resolve the build error and move forward with your Solana development process. What are Rust compilation errors in Solana? Let's start by understanding the build_hasher_simple_hash_one compilation error that you as a Solana developer might encounter. It's important to first know that this issue is generally due to a discrepancy between the version requirements of certain dependencies and the forked Rust compiler version adopted by Solana. This inconsistency comes to light when you're compiling a basic Solana program. An error message echoing the following lines may arrive on your screen: error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one' --> src/random_state.rs:463:5 ... = note: see issue #86161 <https://github.com/rust-lang/rust/issues/86161> for more information = help: add `#![feature(build_hasher_simple_hash_one)]` to the crate attributes to enable The reason behind this error occurrence is related to the ahash library, a dependency in your Solana project. Essentially, this library is trying to gain access to an unstable feature (build_hasher_simple_hash_one) that was only perfected and stabilized in Rust version 1.71. However, Solana's specific version of the Rust compiler might be seated a few steps below this Rust release. Now that you've gained an adequate view of the issue, the following sections will guide you through a bread crumb trail of step-by-step solutions. How to resolve Rust compilation errors in Solana? Emerging victorious from this compilation error involves utilizing a few strategies. Here are the steps you can take: Step 1: Check Rust and Solana versions Your first order of action should be to become acquainted with the versions you're employing in your project. This verification can be achieved by executing these commands in your terminal: solana --version rustup --version rustup toolchain list cargo build-sbf --version These commands will show you the current versions of solana-cli, rustup, and the specific rustc version employed by Solana. Step 2: Pin the ahash version Solving this issue may involve anchoring the ahash library to a version that the older Rust compiler version, employed by Solana, can comprehend. You can achieve this by indicating the ahash version in your cargo.toml file: [dependencies] ahash = "=0.8.6" Alternatively, you can update ahash to a specific version using the following command: cargo update -p ahash@0.8.7 --precise 0.8.6 Step 3: Use Rust features If fiddling with the ahash version seems troublesome, another manoeuver would involve utilizing the Rust feature flag. This can help enable the unstable feature within your development environment. Insert the following line to the peak of your main library file (lib.rs or main.rs): #![feature(build_hasher_simple_hash_one)] Bear in mind, this method is like a makeshift bridge. It provides a temporary fix and should be employed with caution as it hinges on unstable Rust features. Step 4: Monitor Solana updates Since Solana operates with a distinct fork of Rust (solana-cargo-build-sbf), it’s crucial to keep track of modifications to Solana's Rust version. Keenly monitor Solana changes pertinent to their Rust version through the Solana GitHub issue tracker. Check in on issues related to this matter, like #33504. Step 5: Use an alternative dependency If ahash continues to play the villain and your project allows for a little wiggle room, think about switching over to a different hashing library. This new library should either be harmonious with older versions of Rust or not bank heavily on unstable features. Rust compilation error best practices for Solana developers Now that we've walked you through the problem and its possible solutions, here are some best practices to prevent similar hitches or to handle them efficiently if they occur in the future. Version management Timely updates and effective management of toolchain versions with rustup and solana-cli are crucial to maintaining the smooth running of Solana development. It's not just about installing these tools, but more so about making sure they're kept up-to-date and that they maintain compatibility with each other. Dependency audit Sometimes, indirect updates from your dependencies may catch you off-guard. Make it a habit to periodically review and audit your dependencies. This practice will help you keep acquaintances with the versions you're using and enable you to preempt any potential issues. Community engagement Become a participant, not just a spectator, in the Solana development community. Platforms like Chainstack, StackExchange, GitHub, or Solana's official forums, not only serve as a knowledge base but also provide tried-and-tested troubleshooting advice from experienced peers and experts in the field. Staying active in these communities can offer unexpected insight and potential solutions to issues you might face in the future. With these practices in place combined with a deeper understanding of Rust's version compatibility, you'll be on your path to becoming a seasoned Solana developer. You’ll find that issues like the build_hasher_simple_hash_one actually serve as stepping stones, building your skills in the vibrant landscape of Solana software development. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Bringing it all together Troubleshooting common Solana development errors is essential for maintaining a smooth workflow and ensuring the stability of your DApps. By understanding and resolving issues such as Rust version conflicts, Borsh serialization errors, blockstore errors, and module parse errors, you can enhance your development process and build more reliable applications. Remember to manage your dependencies, stay engaged with the community, and keep your toolchains up to date. With these practices, you'll be well-equipped to navigate the complexities of Solana development and achieve success in your projects. Power-boost your project on Chainstack #### Solana: SPL Token Program Architecture The SPL Token Program is the foundation of fungible assets on Solana. It defines how tokens are represented on-chain, how ownership is enforced, and how balances are created, transferred, and destroyed at runtime. While most developers interact with SPL tokens through high-level SDKs, those abstractions hide important architectural details. Understanding the SPL Token program at the protocol level is essential for building reliable token flows, integrating with DeFi protocols, and debugging unexpected on-chain behavior. This post provides a technical overview of the SPL Token program’s architecture. We’ll focus on how the program models state using accounts, how authority is enforced, and how common token operations are executed by the runtime. By the end of this article, you will understand: how the SPL Token program represents tokens using Mint and Token Account state how balances are derived from account data, not stored globally how authorities (mint, freeze, owner) are enforced by the program how SPL token design differs fundamentally from account-based token models on other chains This post establishes the architectural foundation. In the next blogs, we’ll build on this to explore transfers, authorities and extensions. How the SPL Token program represents Tokens are on-chain constructs used to represent ownership and transferability of assets. Tokenization allows property rights and value to be expressed and enforced programmatically on a blockchain. On Solana, tokens are implemented through the SPL (Solana Program Library) Token program. This section introduces the core concepts behind how tokens are modeled and managed on Solana. For practical examples and code walkthroughs, refer to the SPL Token Basics section. Concepts: Token programs define the instruction set and validation logic for creating, minting, transferring, and burning tokens on the network. The same program supports both fungible and non-fungible tokens. A Mint account represents a specific token type and stores global, token-wide state such as total supply, decimal precision, and mint authority (the address permitted to issue new tokens). A Token account represents ownership of tokens for a given mint and owner. It holds the balance and ownership metadata for that specific combination. An Associated Token Account (ATA) is a canonical Token account whose address is deterministically derived from the owner’s address and the mint address, ensuring a standard and predictable location for token balances. All tokens on Solana are effectively data accounts owned by a Token Program. Mint Account On Solana, a token is uniquely defined by its Mint account address, which is owned by the SPL Token program. The Mint account represents the global state of a specific token and serves as the canonical source of truth for its configuration and supply. The Mint account stores the following information: Supply: the total number of tokens that have been minted Decimals: the decimal precision used to represent fractional units Mint authority: the account permitted to mint new tokens and increase the total supply Freeze authority: the account permitted to freeze Token accounts, preventing transfers or burns The full struct representation can be found here and looks like that: pub struct Mint { pub mint_authority: COption<Pubkey>, pub supply: u64, pub decimals: u8, pub is_initialized: bool, pub freeze_authority: COption<Pubkey>, } For reference, here is a Solana Explorer link to the USDT Mint Account. Token Account To represent individual ownership, the Token program uses Token accounts. Each Token account is associated with a single Mint and is used to track the balance of that token for a specific owner. A Token account stores the following information: Mint: the token type to which the account belongs Owner: the account authorized to transfer tokens from the Token account Amount: the number of token units currently held in the account The full struct representation can be found here and looks like that: pub struct Account { pub mint: Pubkey, pub owner: Pubkey, pub amount: u64, pub delegate: COption<Pubkey>, pub state: AccountState, pub is_native: COption<u64>, pub delegated_amount: u64, pub close_authority: COption<Pubkey>, } A wallet must have a dedicated Token account for each token (Mint) it intends to hold, with the wallet’s address set as the owner of that account. While a single wallet can control multiple Token accounts for the same Mint, each Token account is restricted to a single owner and can hold units of only one Mint. Associated Token Account Associated Token Accounts (ATAs) provide a standardized way to locate a Token account for a given Mint and owner. An ATA serves as the canonical, or default, Token account for a specific combination of owner and Mint. In practice, An Associated Token Account is created at an address that is deterministically derived from the owner’s address and the Mint address. Functionally, an ATA is no different from any other Token account the distinction lies solely in how its address is derived. This mechanism relies on a fundamental Solana concept: Program Derived Addresses (PDAs) that we learned here. Cli examples Configuring the Solana CLI for devnet solana config set --url https://api.devnet.solana.com Create a new keypair or use an existing one: solana-keygen new Verify your active configuration: solana config get it should look like this: airdrop to your created account some SOL solana airdrop 1 you should see output like this: Install SPL CLI: cargo install spl-token-cli Run this to verify that it is installed successfully: spl-token --version // The output will look like: // spl-token-cli 5.4.0 Creating a new token mint spl-token create-token // To specify decimal precision explicitly: // spl-token create-token --decimals 6 output: Creating a token account spl-token create-account <MINT_ADDRESS> output: Minting tokens spl-token mint <MINT_ADDRESS> 1000 output: Check balance spl-token balance <MINT_ADDRESS> output: Transferring tokens Automatically create the recipient’s associated token account if it does not exist: spl-token transfer <MINT_ADDRESS> 100 <RECIPIENT_WALLET_ADDRESS> --fund-recipient output: Summary This article covered the foundational architecture of the SPL Token program and how tokens are represented on Solana. We examined the roles of Mint accounts, Token accounts, and Associated Token Accounts, and how they work together to model token supply and ownership on-chain. This understanding provides the basis for analyzing token transfers, authority management, and interactions with higher-level protocols. In the next part of the series, we’ll explore how the SPL Token program enforces these rules during instruction execution. 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 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 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 aSolana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – a trusted Solana RPC provider. #### Solana: Transactions, Execution, Fees, and Runtime In the previous article, we explored how Solana messages are structured, why the original format eventually became a bottleneck, and how the v0 model with Address Lookup Tables expanded the number of accounts developers can reference. We established the message as the core description of intent on Solana. Now we go deeper into what happens next. This part of the series explains Solana transaction execution, covering serialization, signature verification, account loading, fees, and runtime execution. We follow a transaction from serialization to signature checks, account loading, compute budgeting, parallel execution, and atomic state commit; explaining why blockhashes expire, where fees come from, and why simulation can diverge from real execution. Once a message is assembled, it begins a long path: serialization, signature collection, blockhash validation, fee computation, account loading, execution scheduling, and atomic state updates. Every step is designed to maximize throughput without compromising deterministic execution. This is also where many of the developer-facing questions emerge: how wallets sign, why expired blockhashes protect the network, how the runtime applies parallelism safely, and why simulations sometimes differ from live results. This article traces the full lifecycle of Solana transactions from the moment a message becomes a signed transaction to its final committed state on the ledger — end to end, step by step. What is a Solana Transaction? To interact with Solana, you submit a transaction. As we discussed in the previous post, a transaction doesn’t hold raw instructions directly; it holds a message that defines which instructions will run, which accounts they require, and which recent blockhash anchors the transaction to the current chain state. Each instruction inside that message represents a specific operation the network should perform. In the example below, the first transaction contains a message with a single instruction, while the second contains a message with three instructions that will execute sequentially: instruction 1, then instruction 2, then instruction 3. The transaction object looks like that: signatures: An array of signatures message: Transaction information, including the list of instructions to be processed pub struct Transaction { #[serde(with = “short_vec”)] pub signatures: Vec<Signature>, pub message: Message, } Transactions have a total size limit of 1232 bytes. This limit includes both the signatures array and the message struct. Signatures The transaction holds an array of 64-byte signatures. Each one is produced by signing the transaction’s Message with the private key of an account that appears as a required signer. Every signer referenced by any instruction must provide a corresponding signature in this array. The first signature always comes from the fee-payer. This is also the transaction’s primary signature the one you use to look up the transaction on explorers and RPC endpoints. The signature struct looks like that: pub struct Signature(GenericArray<u8, U64>); Transactions Are Atomic A Solana transaction is an all-or-nothing operation. Even if a message contains multiple instructions, the runtime treats the entire set as a single atomic unit. This means: All instructions succeed → state is committed Any instruction fails → nothing is committed There is no partial success. This is why Solana must know every account that will be touched before execution begins. It allows the runtime to lock those accounts, validate the message, and ensure that the entire transaction can be applied in one deterministic step. Atomicity is also what makes Solana composable. You can pack multiple program calls into a single transaction (e.g., swap → transfer → stake), and the chain guarantees the entire sequence either completes or doesn’t happen at all. Transaction Fees Every Solana transaction includes a fee paid in SOL. This fee has two components: a base fee and an optional prioritization fee. The base fee compensates validators for executing the transaction, while the prioritization fee allows a user to pay extra to increase the likelihood that the current leader will include their transaction in the block. What is the base Fee Solana charges a base fee of 5,000 lamports per signature in a transaction. The fee-payer the first signer in the message is responsible for covering this amount, and only System Program–owned accounts are eligible to pay it. The network divides the base fee into two equal parts: Half is burned, reducing the total SOL supply. Half is given to the validator that included the transaction. What is the prioritization fee A prioritization fee is an optional amount you can add to improve the likelihood that the current leader includes your transaction. The validator receives 100% of this fee. You set the prioritization fee by specifying a compute unit (CU) limit and a CU price on the transaction. The fee is computed as: Prioritization fee = CU limit × CU price Note: Solana only charges a prioritization fee when you explicitly set one using the ComputeBudgetProgram. If you do not include a compute budget instruction, then: CU price = 0 Prioritization fee = 0 Only the base fee is charged (5,000 lamports per signature) This value helps determine how your transaction ranks against others in the leader’s queue. Solana derives a transaction’s overall priority using: Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) A higher priority increases the chance your transaction is selected during contention. Compute Unit Limit By default, Solana allocates 200,000 compute units per instruction and up to 1.4 million compute units per transaction. You can override these defaults by adding a SetComputeUnitLimit instruction from the ComputeBudgetProgram. A practical way to choose an appropriate limit is: Simulate the transaction to see how many CUs it actually consumes.(coming soon in the next blogs) Add X% overhead to avoid unexpected failures. It’s important to note that the prioritization fee uses the requested CU limit, not the compute units the transaction ultimately consumes. If you set the limit too high (or rely on the large default), you may end up paying for unused compute capacity. Compute Unit Price The compute unit price is an optional amount, specified in micro-lamports, that you’re willing to pay per requested compute unit. You can think of it as a tip that incentivizes the current leader to include your transaction ahead of others. To set a CU price, include a SetComputeUnitPrice instruction from the ComputeBudgetProgram. If you do not specify a CU price, it defaults to zero, and the transaction will not pay a prioritization fee, only the base fee. Note: Compute Budget program instructions are ignored when calculating the prioritization fee. You can see this here. Example: lets take a look at this transaction We see that the Priority fee here is 0.000004 SOL, and the total fee is 0.000009 SOL lets understand how it is computed: as we said before, By default, Solana allocates 200,000 compute units per instruction. In this transaction we have here 2 instructions, but as said previously the ComputeBudget Instructions are omitted from the calculation, so we end up only with 1 instruction and a price of 20000 micro-lamports which is 0.02 lamports/CU. so the price will be: 200,000 * 0.02 = 4000 lamports, which is 0.000004 SOL. In addition we have 1 transaction signer on the transfer instruction, which is costs 0.000005 SOL. Total fee = BaseFee + PriorityFee = 0.000004 + 0.000005 = 0.000009 How the Wallet Actually Signs A common point of confusion is how a signer can sign a message when the message itself already includes that signer’s account. This feels circular at first, how can the wallet include the signer in the message before the signer has produced the signature? The key is understanding that the message contains the signer’s public key, not their signature. The signature is added after the message is finalized. Here’s how the process actually works: 1. The wallet builds the complete message first Before any signature exists, the wallet constructs the message in its final form: the message header (signer counts), all account public keys, the recent blockhash, the compiled instructions. At this stage, the message already includes the signer’s public key, because the runtime needs to know: which accounts must sign, the order of signer accounts, which signature corresponds to which key. No signatures exist yet. The message is simply a byte array describing exactly what will be executed. 2. The signer signs the message bytes Once the message is fully constructed, the wallet signs the exact serialized message bytes: signature = Ed25519_sign(private_key, message_bytes) Any change to the message, however small invalidates the signature. Because the message contains only public keys, signing it has no circular dependency. It’s like signing a legal document that lists your name: your name is part of the document, but your signature is added afterward. 3. The signature is inserted into the transaction After signing, the signature is placed into the transaction’s signature array according to the signer’s position in account_keys: signature at index 0 → first signer (fee-payer) signature at index 1 → second signer etc. The signature does not modify the message. The message is now locked, changing it would break every signature. Transaction packs all this data into its structure and sends the built transaction to the node. Overview Messages never contain signatures, only public keys. Signatures are created over the final message, not before it. Signatures live outside the message, in the transaction wrapper. This separation allows: deterministic signing, canonical verification, simple replay protection, and lightweight transactions. There is no circular dependency, signers sign the message, and the message simply identifies who the signers are. How Solana Executes a Transaction Up to this point, we’ve focused on how a transaction is constructed, how messages are formed, how signatures are produced, how fees are calculated, and how the wallet packages everything together. Once a validator receives a transaction, Solana processes it through a series of steps that ensure the transaction is valid, safe to run in parallel, and either fully succeeds or fully fails. 1. Signature Verification The validator hashes the message. Each signature is checked against its corresponding public key. Any invalid signature → the transaction is immediately rejected. 2. Account Loading All accounts listed in the message (and ALTs, if used) are fetched. The runtime checks: account existence ownership rules signer flags read/write permissions If anything is invalid → the transaction stops here. 3. Account Locking Writable accounts get a write lock. Read-only accounts get a read lock. These locks ensure no conflicting transactions execute in parallel. If required accounts are already locked → the transaction may be delayed or skipped. 4. Instruction Execution Instructions run in order, one by one. Each instruction: invokes the target program updates compute usage may perform CPIs If any instruction fails → the entire transaction fails. 5. Compute Budget Enforcement The runtime tracks consumed compute units. If the CU limit is exceeded: execution stops the transaction fails the fee-payer still pays the fee 6. Atomic Commit or Rollback If all instructions succeed: account changes are committed atomically locks are released If any instruction fails: no state changes are applied the transaction is recorded as failed the fee is still charged Summary A Solana transaction is more than a signed bundle of instructions. It’s a structured request that moves through a precise execution pipeline. The message defines what should happen, signatures authorize who approved it, and the runtime ensures everything is valid, safe to run in parallel, and fully atomic. You’ve seen how fees are calculated, how compute budgets influence prioritization, how wallets sign messages, and how validators process transactions from signature checks to final commit. Together, these pieces form the foundation of Solana’s high-throughput, parallel execution model. Understanding this flow gives you the tools to reason about transaction behavior, debug failures, and write programs that interact with the network reliably and efficiently. 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: Transactions, Messages & Address Lookup Tables In the previous post, we broke down how Solana transactions are structured: messages, signatures, serialization, and how the runtime executes them. In this final part, we’ll stop theorizing and start sending real transactions. We’ll build a small on-chain program and a client that calls it. Then we’ll send the exact same instruction two different ways: first as a versioned (v0) transaction, and then as a v0 transaction using an Address Lookup Table. We’ll look at the actual code that builds each transaction, inspect the messages that get signed, and see how accounts are passed, locked, and resolved at runtime. Along the way, we’ll make several things explicit that most tutorials hide: why some accounts live in .accounts() and others in remainingAccounts how the same instruction can be executed under completely different messages what Address Lookup Tables really do (and what they don’t) what the IDL describes, and why it has nothing to do with execution Nothing here relies on magic helpers. Every transaction is constructed deliberately, every account is passed explicitly, and every optimization is visible in the message. By the end, you’ll know how to build v0 transactions with and without ALTs, when they behave the same, and why scaling on Solana is mostly a message-level problem. This post closes the series by connecting instructions, messages, and tooling into one concrete, executable mental model. From theory to execution In the previous parts of this series, we treated Solana transactions almost like a protocol specification. We broke them down into: instructions and their serialized data messages and account lists signatures, fees, and blockhashes and how the runtime executes a message once it’s accepted by the network All of that can feel abstract when looked at in isolation. In real programs, those same concepts reappear not as definitions, but as constraints you have to work with. This post is about seeing those ideas surface in practice. How real programs experience instructions From the program’s point of view, an instruction is still just: a byte array a list of accounts and a program ID The program has no concept of: legacy vs versioned transactions address lookup tables fee payers or signatures It only sees the result of the message: a fixed set of accounts it is allowed to read or write, in a fixed order. That’s why well-designed programs: avoid hardcoding account layouts rely on passed-in accounts and stay agnostic to how the client constructs the message In other words, programs live below the transaction abstraction. How real clients experience messages Clients live at the opposite end. They don’t care about program internals. They care about: how many accounts must be passed how large the message becomes whether the transaction still fits on-chain and whether it can be signed and broadcast successfully This is where concepts like: instruction batching versioned messages and Address Lookup Tables stop being optional and start being architectural. The logic hasn’t changed. The instruction hasn’t changed. Only the message has. What we’ll do next With that context in mind, the rest of this post will walk through a small, intentionally boring program and show how: the same instruction executes under different messages nothing changes for the program and everything changes for the client That’s where theory stops and real Solana development begins. Solana Program With the execution model in mind, we can now look at a concrete on-chain program. We won’t cover environment setup, deployment, or tooling configuration here those were already covered in earlier posts in the series. Nothing in this section depends on Anchor specifics beyond basic program structure. Instead, we’ll focus entirely on the implementation and how it interacts with instructions and messages at runtime. The program itself is intentionally simple. It does not write state. It does not create accounts. It does not perform CPIs. Its only job is to read token account data passed to it and return balances. That simplicity is deliberate: it lets us isolate how accounts are passed, how instructions are executed, and how messages constrain execution, without unrelated complexity. What this program shows This program is intentionally simple. It doesn’t own state, create accounts, or perform CPIs. Its purpose is to read token balances in batches for a list of wallets and mints provided by the client. Instead of querying balances one-by-one, the instruction accepts a vector of (wallet, mints) and processes them in a single execution. This makes it suitable for aggregators, dashboards, or off-chain systems that need to fetch many balances efficiently. The instruction declares no required accounts. All token accounts are passed via ctx.remaining_accounts, which means the program only sees the accounts the message explicitly provides. For each wallet and mint, the program derives the expected associated token account addresses for both SPL Token v1 and Token-2022, checks which one was included in the message, and reads the balance if it exists. The result is returned using set_return_data, without writing anything on-chain. The key takeaway is that this batching logic is completely agnostic to transaction format. Whether the client uses a legacy transaction, a v0 transaction, or a v0 transaction with an Address Lookup Table, the instruction behaves exactly the same. Only the message changes. we will run: anchor build after the build is successfully finished, we can deploy it. anchor deploy After deploying, you can see the program on Solana Explorer (devnet) by its program-ID you can see that on devnet. Client side: Building the message the program will execute The on-chain program is simple. The complexity lives on the client side, because Solana programs can only read accounts that the message explicitly provides. So the client has two jobs: Figure out which token accounts (ATAs) might hold the balances Build a transaction message that includes those accounts and calls the instruction In this example, we'll also walk through creating an Address Lookup Table. As we've seen earlier, there's a limit to how many account addresses can be included directly in a transaction message. In real-world scenarios, especially when batching or aggregating data, you quickly hit that limit. Address Lookup Tables are the mechanism Solana provides to scale beyond it. Note on setup: For this example, I'm using two pre-created token mints and a pre-created Address Lookup Table. The details of how these tokens were created aren't important for understanding this post. What matters is how their addresses are used inside the transaction message. Step 1: Derive the Candidate Accounts (ATAs) The input to the instruction is just a list of wallets and mints. But the program doesn't receive token accounts from that. It receives accounts. So the client derives the associated token account addresses for both token programs: classic SPL Token (v1) Token-2022 That's why for every (wallet, mint) pair we compute two candidates using getAssociatedTokenAddressSync for both token program versions. This mirrors the Rust helpers that derive ATAs on-chain. The client and the program must agree on these addresses. Step 2: Only Pass Accounts That Actually Exist Deriving ATAs is cheap, but many of them might not exist on-chain. Passing non-existent accounts would just waste space or fail during account loading. So the client filters them using getMultipleAccountsInfo to check which candidate ATAs actually exist on-chain. Only existing accounts are turned into remainingAccounts. This is the crucial Solana rule in action: If it's not in the instruction's account list, the program can't read it. So the client must bring the world with it. Step 3: Remaining Accounts Are Message Wiring, Not "Program API" When we build the instruction we call: .accounts({}) — empty because the program's Anchor context is empty .remainingAccounts(remainingAccounts) — where the real work happens The remainingAccounts becomes the instruction's account metas list, which becomes part of the message, which becomes what the runtime loads and locks. This is why this program scales with batching: the instruction data stays small while the message can carry lots of accounts. Step 4: ALTs Optimize the Message, Not the Instruction With batching, the message grows quickly because it has to include many account addresses. That's where Address Lookup Tables come in. We use a helper function ensureAltHasAddresses that: Fetches the ALT Checks which addresses are already stored there Extends the table with missing ones (only if needed) Importantly: the ALT does not "send accounts to the program". It only lets the message reference account addresses more efficiently. We still pass the token accounts via remainingAccounts. The ALT only changes how the message encodes those addresses. Step 5: Send a V0 Transaction (Where ALT Actually Matters) ALTs only work with versioned (v0) messages, so the client builds a v0 message explicitly using TransactionMessage and compiles it with compileToV0Message([altAccount]). Then we sign and send a VersionedTransaction. This is the key conceptual point: The instruction is identical. The program is identical. Only the message format changes. v0 vs v0+ALT is purely a client-side message construction choice. The transaction can be viewed in the Solana Explorer, showing the Program return data and the decoded balances. Summary In this post, we took Solana’s transaction model out of theory and into practice. We built a real program, constructed real messages, and sent the same instruction using v0 transactions with and without Address Lookup Tables. Nothing changed for the program. Everything changed for the client. That’s the core lesson: scaling on Solana is a message-level problem, not a program-level one. Programs execute instructions. Clients decide how those instructions are wrapped, encoded, and optimized. In the next post, we’ll focus on the tokens used here, SPL Token vs Token-2022 and how their accounts differ, how ATAs are derived, and why those details matter when building real systems. 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: What is the right transaction commitment level for your use case? Understanding transaction commitment levels is crucial for navigating the Solana landscape, especially when it comes to building reliable high-performance DApps. These commitment levels, namely "Processed", "Confirmed", and "Finalized", serve as key indicators of transaction certainty and finality within the network. This guide is designed to provide a comprehensive overview of these levels, equipping Web3 developers like yourself with the knowledge to operate effectively. Let’s get to it! What are transaction commitment levels in Solana? The role of Solana’s transaction commitment levels in ensuring the network's reliability and security is significant. They offer a clear snapshot of a transaction's state, empowering you as developers to make informed decisions based on your specific needs. When interacting with Solana via RPC endpoint, transactions pass through three main commitment levels: "Processed", "Confirmed", and "Finalized". Each level offers a different degree of certainty about the transaction's status within the network. Whether you're a seasoned developer or just starting your Solana journey, gaining a firm grasp of these commitment levels is a critical step forward. Processed A transaction is marked as "Processed" when it has been received by the network and included in a block. However, it's important to note that at this stage, there's no guarantee that the block containing the transaction is on the majority fork of the blockchain. Here are the key characteristics of the "Processed" commitment level: The transaction is included in a received block. The block may or may not be on the majority fork. The block contains the target transaction. Confirmed The "Confirmed" commitment level is reached when a transaction is included in a block that has been voted on by a supermajority (66%+) of the network's stake. This provides a higher level of assurance that the transaction is on the majority fork and is unlikely to be reversed. Here are the key characteristics of the "Confirmed" commitment level: The transaction is included in a received block. The block is on the majority fork. The block contains the target transaction. 66%+ of the network's stake has voted on the block. Finalized The "Finalized" commitment level offers the highest level of certainty for a transaction on the Solana blockchain. A transaction is considered "Finalized" when it is included in a block that has been confirmed by a supermajority of the stake, and at least 31 additional confirmed blocks have been built on top of it. Here are the key characteristics of the "Finalized" commitment level: The transaction is included in a received block. The block is on the majority fork. The block contains the target transaction. 66%+ of the network's stake has voted on the block. At least 31 confirmed blocks have been built on top of the block. How to select the right Solana transaction commitment level? When developing applications on Solana, selecting the appropriate commitment level based on your specific use case is crucial. Along with selecting the top Solana RPC provider, such as Chainstack, here are some guidelines to help you make the right choice of commitment levels: For low-value or non-critical transactions, the "Processed" commitment level may be sufficient. This level indicates that the transaction has been received by the network and included in a block, but it doesn't guarantee that the block is on the majority fork. This level is best suited for testing purposes and is therefore not recommended for use in production environments. For transactions that require a higher level of assurance, such as financial transactions, the "Confirmed" commitment level is recommended. This level assures that the transaction is on the majority fork and is unlikely to be reversed, as it has been voted on by a supermajority of the network's stake. Typically, this commitment level is recommended for the majority of use cases, as it reduces block hash expirations and dropped transactions. For high-value or mission-critical transactions that demand the highest level of finality, the "Finalized" commitment level should be used. This level offers the highest level of certainty, as it indicates that the transaction is included in a block that has been confirmed by a supermajority of the stake, and at least 31 additional confirmed blocks have been built on top of it. As a result, the “Finalized” level runs the highest risk of dropped transactions, especially during congestion. Remember, the key to successful application development on Solana lies in understanding these commitment levels and leveraging them effectively to ensure the reliability and security of your transactions. Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. The ultimate Solana developer guide: Master Solana development all across the board with this ultimate guide, covering everything from pastable snippets to advanced integrations. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Solana historical data: How to retrieve historical data effectively? Bringing it all together Having a deep understanding of Solana's transaction commitment levels is an indispensable tool for developers working with the Solana blockchain. By choosing the appropriate commitment level for your use case, you can augment the reliability and security of your transactions. The "Processed", "Confirmed", or "Finalized" commitment levels serve as a testament to a different degree of certainty and finality. As you navigate the world of Solana development, arm yourself with this knowledge. It will guide the way as you build robust and reliable applications that can stand up to the dynamic challenges that come with blockchain technology. Power-boost your project on Chainstack #### Solving the blockchain trilemma: A look at some scaling solutions The blockchain trilemma: How to scale while ensuring security and decentralization? The number of transactions per second (TPS) that a decentralized blockchain protocol can process is limited compared to centralized non-blockchain solutions. This is of major concern because for Web3 to compete with the current financial systems, it needs to be able to serve many users at once. However, focusing too much on making a blockchain scalable can lead to a project making tradeoffs on security and decentralization. This problem is known as the blockchain trilemma. Layer 2 scaling solutions are one of the answers to these problems. However, the Layer 2 solutions vary quite a bit, and there’s a lot to unpack when trying to understand these new technologies. In this article, we will be going over a few of these solutions to understand how they work. Layer 1 blockchains Layer 1 blockchains are the ones you usually hear about. Bitcoin, Ethereum, Solana, and the like. They are the foundations for their respective ecosystems, and they all have their independent consensus mechanisms. Any project that builds on top of these chains inherits the pros and cons of these respective Layer 1s. For example, Ethereum is secure and decentralized, but it can also get slow and expensive to process transactions on the Ethereum mainnet when the network gets clogged. The additional solutions to improve the blockchain experience of the end-user are known as Layer 2 scaling solutions, and they have a lot of differences within them. Let us talk in more detail about these. Layer 2 blockchains and sidechains Layer 2 is a collective term that refers to any scaling solution that is built on top of an existing blockchain system. These Layer 2 solutions work independently of the parent chain and usually have their own consensus mechanisms. Polygon, StarkNet, Gnosis Chain, Avalanche Subnets, BNB Sidechains and so on are all good examples of Layer 2 solutions trying to increase TPS and throughput while keeping up the security standards that are core to blockchain. Let us first talk about sidechains, one of the most prominent of the many different Layer 2 solutions. Sidechains are EVM-compatible and often exchange assets with Ethereum In the context of the EVM ecosystem, a sidechain is a separate blockchain that is typically used for large batch transactions. Sidechains use their own consensus mechanisms, which optimize them for speed and scalability. They typically compromise a bit on the decentralization of the blockchain, but if a sidechain is indeed compromised, the mainnet is not affected. Sidechains are also often EVM-compatible, which means you can deploy the same smart contract to either Ethereum or the sidechain, with minimal changes. This allows DApps to scale without worrying too much about the gas fees. The most prominent example of an EVM-compatible sidechain would be Polygon. Polygon isn’t the only one though. Ethereum’s official blog mentions Polygon, Gnosis Chain, Skale, and Loom network as examples. To be clear, for a separate blockchain to be considered an Ethereum sidechain, it needs to be able to move assets between itself and Ethereum mainnet. This is powered by smart contracts deployed on either chain. The smart contracts function as bridges for the transfer of funds. With these bridges, the transfer of funds is typically accomplished through locking and releasing mechanisms, which are out of the scope of this article. If you however are interested in creating a cool EVM-compatible bridge, feel free to check out this tutorial. Our tutorial on creating an EVM-compatible bridge What are zero knowledge proof rollups (zk rollups)? Rollups are also a type of Layer 2 scaling solution. What they do is nicely hinted at in the name.Rollups roll up multiple transactions into one piece of data, and collectively present that data block to the parent chain, in our case Ethereum. This cuts down the number of transactions that Ethereum must process, and thus gives them the throughput that Ethereum just can’t match on its own. Rollups combine a set of transactions into a single piece of data There are two main types of rollups—zero-knowledge (ZK) rollups, and optimistic rollups, and they differ in the way their transactions are verified. How do we know that the transactions that the rollups are pushing to the parent chain are accurate?Currently, there exist two solutions to this problem: Fraud proof, used by Optimistic rollups. Validity proof, used by ZK rollups. ZK rollups ZK-rollups wait for hundreds, or even thousands of transactions to be bundled together, and then verify their validity by doing a bunch of mathematical operations on them, like how transactions are verified on Ethereum. Once a mathematical proof is generated, the main Ethereum chain includes that batch of transactions on the mainnet as if those transactions were processed on-chain itself. Zero knowledge Rollups Zero-knowledge proof is a complex mathematical concept where someone can prove that they are in possession of a piece of data without actually disclosing that information to anyone. I can, for example, prove that I know the password to my mobile by simply unlocking it in front of you, without showing you the password itself. In a ZK rollup, a mathematical proof is generated that proves that a whole batch of transactions is valid, without including the proof for individual transactions. This makes ZK rollups more efficient and scalable. StarkNet is a great example of ZK rollups in action. Find out more about StarkNet in our dedicated tutorial series: Checkout our dedicated Starknet Tutorials here This is a good time to mention that StarkEx and ‘StarkNet’ are two different things. While StarkNet is an EVM-compatible ZK rollup, StarkEx is basically a framework for creating ‘STARK proofs’ off-chain. STARK stands for ‘Scalable Transparent ARguments of Knowledge’. These proofs verify the authenticity of a transaction. They are computationally expensive to generate but quite easy to verify.StarkEx allows projects to generate these STARK proofs off-chain conveniently, thus only verifying them on-chain. Major protocols like ImmutableX use StarkEx as a scaling solution. As of now, ZK rollups can only process a few types of transactions and cannot process generalized smart contracts. This is where optimistic rollups come in. Optimistic rollups Optimistic rollups are a much more generalized version of ZK rollups. They run a version of the EVM called the optimistic virtual machine (OVM). An OVM runs almost exactly like an EVM, except that it processes Layer 2 transactions instead of Layer 1 transactions. The important thing to note is that the OVM does not check a batch of transactions for validity by default. The validity of such a batch is determined by what is called a fraud proof. Once a batch of transactions is processed, there is a time period where anyone can challenge the validity of the whole batch. This is known as the fraud-proof window. This window can last as long as 3 weeks but is usually 1-2 weeks long. If a fraud proof submitted by someone is found to be invalid, the entire batch of transactions is rolled back. This means for any transaction to achieve Layer 1 finality, the time taken will be equal to the length of the fraud-proof window. Optimism and Arbitrum are two prominent examples of Optimistic rollups. They are both almost identical, but with a few key differences. What mostly sets Arbitrum apart from Optimism is the fact that while Optimism uses single-round fraud proofs, Arbitrum uses multi-round fraud proofs to ensure the legitimacy of the transactions. This means that instead of processing an entire batch of transactions on-chain, Arbitrum only requires the fraud proofs for those transactions that are being challenged. This saves a considerable amount of gas since the entire batch is no longer being processed on the chain. Zk-Rollups vs Optimistic Rollups Sidechains vs rollups If you have read this far, you may be wondering what exactly is the difference between sidechains and rollups? At its core, both of them serve to increase the scalability of Ethereum, and both of them have similar interfaces for the end-user. However, these are two different technologies, and it is important to know their differences. Rollups sit on top of the existing Ethereum network and the compressed transaction data is submitted to the respective rollup contract on the Ethereum mainnet. Different kinds of rollups take different amounts of time to achieve transaction finality, but the core principle remains the same. A sidechain like Polygon however is a complete blockchain in its own right. We use the native token of a sidechain to push transactions on them. Yes, tokens like MATIC can be exchanged for Ether using a bridge, but the security of any funds you have on a sidechain is ensured by the sidechain itself, not Ethereum. Polygon’s zkEVM Let us take a step back and look at ZK rollups one more from a different perspective. ZK rollups are transactions that have been proven correct, whereas optimistic rollups are transactions that weren’t disputed within a given time frame or haven't been proven as incorrect. Many projects use optimistic rollups because they are compatible with the Ethereum Virtual Machine pretty much out of the box, unlike ZK or Validity rollups that may require their own contract language like Cairo. This is the reason so many projects like Polygon and Matter Labs (the organisation behind zkSync) have been putting in the effort to develop an EVM that will allow ZK rollups to handle smart contracts. A successful ZK rollup mainnet that can also handle smart contracts will allow Ethereum to scale massively while remaining secure and decentralized. Polygon has turned out to be one of the first companies to announce the launch of their zkEVM testnet, alongside open-sourcing the code for the whole project. Polygon just announced the launch of its zkEVM What this means in essence is that developers can deploy their smart contracts on ZK rollups without changing their code much. One of the major disadvantages of deploying smart contracts on optimistic rollups was that the withdrawal of funds could take weeks depending on the dispute period of that particular rollup. But with the progression of the ZK-SNARK technology, developers can leverage the full potential of rollups without having to wait weeks for their smart contract transactions to gain finality. Application chains The scaling solutions we discussed up until now were either singular blockchains like Polygon or rollups that facilitated cheaper transactions on Ethereum. Some blockchain projects however aim to do things a little differently. Projects like Avalanche and Polygon Supernets aim to build on the already existing consensus mechanisms to create their own blockchain ecosystems that will allow developers to leverage their toolkits to build their own customized blockchains within the respective ecosystems. Let us take a look at a few of these projects. Avalanche subnets Avalanche is a unique blockchain ecosystem that allows developers to quickly set up their own blockchains within the Avalanche ecosystem, which are powered through a subnet. A subnet is a set of validators working together to validate transactions on a particular blockchain. While making a new blockchain using the Avalanche protocol, the user can impose certain qualifying conditions for validators who want to join the blockchain’s subnet. I may want all my validators to belong to a certain geographical area, or maybe I want all my validators to be verified through KYC. Avalanche allows me to impose these conditions, thereby giving me a subnet according to my requirements. If you want to dig into avalanche subnets, feel free to check out our tutorial series starting from here: Check out our tutorials on Avalanche subnets Even the primary Avalanche network, without any derived subnets, will consist of at least 3 blockchains. X-Chain—This chain is responsible for the creation, management, and transaction of any new tokens on the network. C-Chain—The C-chain is based on the Ethereum Virtual Machine and is used to execute smart contracts. The fact that it uses the EVM allows for a fast and convenient transfer of existing solidity code onto the Avalanche Ecosystem. P-Chain—The P-chain is the blockchain that holds the metadata for all the derived blockchains that exist in the Avalanche ecosystem. This chain keeps track of all active subnets, while also allowing the creation of new ones. Architecture of Avalanche's blockchain network Polygon Supernets To understand what Polygon Supernets are, we first need to learn about Polygon Edge. Edge is a modular framework launched by Polygon that allows you to quickly launch your own EVM-compatible networks, sidechains, or generalized scaling solutions for Ethereum or any other EVM-sidechain. Polygon Edge provides developers the option to launch their own dedicated Edge chain with just a few lines of configuration code from the documentation, instead of having to fork the entire Ethereum mainnet and tweaking the codebase to fit business needs. So, what are Polygon Supernets? Supernets are basically blockchain networks that have been customized and deployed using Polygon Edge. Supernets are customized and operated for a specific use-case or project, usually having their own dedicated nodes. This combination of customization and dedicated nodes allows DApps to scale easily. As of now, nearly 20 Web3 applications are using Polygon Edge. Source: Polygon Blog One of the biggest challenges when setting up a PoS (Proof of Stake) blockchain network is to bootstrap a reliable validator network. Polygon Edge will allow Supernets to access a pre-vetted validator network, thus bypassing one of the biggest hurdles in setting up a blockchain network. Additionally, these validators will stake and be incentivized in MATIC, thus making it much easier to incentivize the validators sustainably.All Supernets built using Polygon Edge are capable of exchanging assets and information between each other, and even the Ethereum Mainnet. However, efforts are underway to develop protocols to enable cross-chain communication between all the Supernets, and even other EVM-compatible sidechains. BNB Sidechains BNB Smart Chain was launched in 2020 and is an EVM-compatible blockchain capable of executing smart contracts. BNB Sidechain is a framework for creating subchains in the BNB ecosystem that helps developers build their own customizable and flexible blockchains. We can use the tool to develop highly customized blockchains within the BNB ecosystem that can have their own gas tokens and gas fees. Theoretically, we could even set the gas fees for our blockchain to be zero, but that isn’t recommended because it will incentivize bots to spam the network. It is possible to bridge assets on all the chains within the BNB ecosystem. This means we can leverage NFTs and other tokens on all these chains to get more tokens of a particular type. If this reminds you of Polygon Supernets where you could one day swap any of your tokens with each other within the EVM ecosystem, then you are on the right track. These BNB Sidechains are basically an L2 scaling solution for the main BNB Smart Chain. As is the case with Polygon Supernets, the BNB Sidechain team provides us a default set of validators that they deem safe, but we are free to use our own validators if we don’t want to trust the BNB Sidechain team. Binance has ambitious plans in store for BAS. They plan to run BNB Sidechain networks as PoS sidechains as well as ZK rollups in the future. However the first version of BNB Sidechain and its testnet are based on POS networks. Source: BSC News Node operators do not need to worry about maintenance work if they use services provided by BNB Smart Chain partners. Klaytn Service Chains The Klaytn network is a public blockchain network developed by Ground X, that provides a service-centric blockchain platform that aims to meet enterprise-grade reliability. Klaytn launched its Mainnet called Cypress in 2019, and it had the 4000 transactions per second (TPS) speed, alongside a substantially lower gas fee when compared to Ethereum. The main Klaytn network can be broken down into three subnetworks—each with a distinct purpose. Source: Klaytn Docs Endpoint Node Network (ENN) consists of Endpoint nodes that are responsible for creating new transactions and handling RPC API requests. The Core cell Network (CCN) verifies and executes the transactions that are submitted by the ENN.CCN is the main module responsible for block generation in the blockchain Service Chain Network (SCN) is comprised of the Klaytn subnetworks that are composed of auxiliary blockchains. They are connected to the main chain via ENs.Any DApps on the Klaytn ecosystem can therefore choose to run either on the main chain through the Cypress mainnet, or can choose to run on their own custom blockchains called ‘service chains’. Klaytn’s official docs recommend using service chains if we want our DApps to have a dedicated execution environment and the highest possible TPS. Conclusion To put it all together, Layer 2 scaling solutions are turning out to be a key component in making blockchain technologies more accessible to the end-users. Only through higher transaction speeds and lower gas fees will web3 be able to compete with traditional financial systems. In this article, we learned that there are many different kinds of scaling solutions, and how these solutions differ in their respective approaches. Not all scaling solutions are the same, nor do they serve the same use cases. It is important to understand their differences and to know about the different kinds of technologies that power the whole web3 stack.Want to get a complete overview of the Web3 stack? Learn more with our guide here: Check out our detailed guide on the Web3 Tech Stack #### Space and Time secures 8x friendlier rates with Global Enterprise data profile Powering smart contracts and enterprises with trustless data processing. Chainstack’s exceptional infrastructure complements our Proof of SQL technology, allowing us to set new standards in data integrity and scalability in the Web3 ecosystem. Space and Time Team Data is now more valuable than oil, making its availability, security, and integrity crucial for businesses, governments, and institutions. Whether it's for designing smart cities, disrupting industries, or advancing the frontier of Web3 applications, information powers everything. This very belief propelled the birth of Space and Time (SxT), an ambitious project aimed at providing an all-encompassing solution for decentralized data warehousing. Engineered to meet the colossal data demands of today and tomorrow, Space and Time epitomizes the blend of art and science. Powering smart contracts and enterprises with trustless data processing, SxT is delivering enormous value using their state-of-the-art zero-knowledge (ZK) proof technology—Proof of SQL. Testament to their technology prowess is the trust laid in them by the most esteemed financial institutions and enterprises like Microsoft, NVIDIA, and AWS, as well as notable Web3 protocols, such as Chainlink, Polygon, and Avalanche. Let's shed light on SxT's journey with us and how they satisfied their particular need for blockchain data, setting off on a pioneering course across Web3. Why Space and Time chose Chainstack as its infrastructure partner When we first interacted with the visionary team at Space and Time, we had an inkling that it was the start of something special. Driven by the pursuit of decentralizing data warehousing, they were already exploring various data providers, analyzing their features and performance, with the intent of identifying the most suitable partner. They had a keen eye for detail and high expectations, fueled by their rich expertise in the field. The ultimate goal was to find a robust and reliable data provider capable of supporting the versatile blockchain needs of Space and Time, particularly those related to the DeFi and GameFi verticals. The pre-existing challenges they faced paved the way to our fruitful work together. They grappled with ensuring uptime and performance, especially during periods of high load times. There were also occasional concerns due to downtime of Avalanche nodes impacting their indexing services. That is when Chainstack stepped up to play a vital role in resolving these challenges with our robust Global infrastructure and the ability to handle high-volume archive requests across multiple chains. Recognizing the immense potential and value proposition of Space and Time, we focused on providing customizable and scalable solutions, adding another dimension to their operations. The transparency and responsiveness we provided only deepened their trust in us. As real partners, we valued their feedback and used it to optimize our own services. The result? A robust, foolproof solution that could handle high-demand scenarios without significant downtime that resonated with Space and Time's vision. This is evidenced by the active ongoing use of the solution for managing their nodes and addressing scenarios with high demand. Space and Time on Chainstack in numbers Our collaboration with Space and Time is a story, not merely of our services and their solutions, but of numbers that tell a tale of extraordinary achievement in the Web3 domain. To just throw numbers at you wouldn't do justice to this incredible journey. Instead, let's weave them into a tale that truly encapsulates the synergy between Chainstack and Space and Time. We begin with a pointer towards our ongoing work—15 active Global nodes that together form the bedrock of their operations. Across diverse protocols such as Ethereum, Polygon, Aptos, and Avalanche, we've provided secure, stable, and efficient services, firm in the knowledge that each node acts as a powerful instrument in the Space and Time decentralized continuum. Digging deeper, we see the story unfold globally. From Ashburn to Amsterdam, from France to London, we witness the marks of our collaboration. Ashburn claimed the lion's share with 10.7B requests, followed by France in second place with 1.8B. Now, if we shift the focus to protocols, some impressive figures come to light. Leading the pack was Polygon with 10.6B requests. Not far behind was Ethereum, claiming 2.5B requests. Avalanche saw the processing of a sizable 303.6M requests, underscoring the cross-chain span of our partnership. What's more, imagine the compelling amount of archive node requests successfully processed—11.9B to date, with roughly 1.9B Request Units (RUs) in just October and November alone. Over these last couple of months, Space and Time has successfully allocated archive RUs with an almost even split between the eth_getBalance and eth_getTransactionReceipt methods. Figure 1: Space and Time archive node RU allocation OCT-NOV That being said, add to that picture another 1.5B full node requests processed so far and 150M RUs during the last two months. Much like their archive counterparts, Space and Time's full node RUs were put to the eth_getBalance and eth_getTransactionReceipt methods but they claimed a much smaller share of around 14% and 17% respectively. In turn, eth_call showed greater dominance claiming the large majority of these RUs with its 64% slice of the pie. Figure 2: Space and Time full node RU allocation OCT-NOV Now, let’s do some quick math and average out the RU data from these two months, so we can get a rough usage estimate for a monthly basis. We can then use these RU forecasts with our pricing calculator to get a better understanding of just how Space and Time gets to spend less, while using more with Chainstack. When we draw the bottom line, SxT would’ve been faced with a significant final monthly bill of just over $30K, should they had opted for an equivalent service with Alchemy and a staggering $140K+ with QuickNode. In contrast, their total infrastructure spend for the full 8+ months journey they’ve had with us as Enterprise customer is on par with that of a single month’s invoice from Alchemy. Such monumental differences only serve to highlight just how cost-efficient Chainstack nodes really are and the financial resources that they liberate to be put to better use than overpaying for RPCs. If we look at the numbers, there’s a mind-blowing discrepancy of 8x to 32x, regardless in who’s favor they are rounded. Figure 3: Space and Time data profile price comparison; Source: Chainstack What is Space and Time? At its core, Space and Time (SxT) is the verifiable compute layer for Web3—an objective it accomplishes through the potent confluence of zero-knowledge proofs and a decentralized data warehouse. The foundational cornerstone of this architecture is SxT's novel ZK-proof, known as Proof of SQL. This revolutionary innovation ascertains the truthfulness of computations performed at scale, providing a solid guarantee that the resultant query hasn't been tampered with. SxT offers a large array of services that target the integral needs of Web3 developers. For instance, it provides a connection with the blockchain data indexed from notable protocols, in addition to other relevant off-chain data. Developers can use SxT's platform to transform and shape data using SQL, catering to specific business schema definitions. Moreover, they can employ SxT to create APIs and dashboards, send verifiable data to smart contracts, and facilitate seamless scaling, even when dealing with terabytes of data and thousands of simultaneous queries or requests. Figure 4: Space and Time Verifiable Compute Layer; Source: Space and Time Its solution extends beyond sheer SQL execution, however. SxT preloads blockchain data from prominent chains like Ethereum, Polygon, Sui, Avalanche, Sei, and allows developers to augment it with their off-chain datasets. This data, obtainable from any source—be it game servers, databases, data warehouses, or applications—can be queried at will. The resultant query can be published to new API endpoints, allowing developers to drive low-latency access for their DApps. Add to this the unparalleled guarantee of trust that SxT's Proof of SQL provides, the future of Web3 appears secure, optimized, and well within reach. SxT is more than a platform; it's a solution—an ecosystem that encapsulates evolutionary tools for the world of Web3. It is an embodiment of progress—one project, one query, and one proof at a time. Bringing it all together In conclusion, Space and Time's collaboration with us exemplifies the impactful results that can be obtained by leveraging Chainstack's robust Global infrastructure. This helped enable SxT to adeptly navigate the complexities of blockchain data management, ensuring high uptime and performance even under demanding scenarios. This synergy has not only met SxT's specific needs but has also set a benchmark in decentralized data warehousing. With impressive usage metrics and global reach, our partnership highlights what can really be achieved when visionary technology meets cutting-edge infrastructure, paving the way for further innovation across Web3 and beyond. Power-boost your project on Chainstack #### Stablecoins in cross-border settlements Stablecoins are becoming the rails for cross-border money movement. Here’s a look at the networks carrying the flow and the reliable infrastructure to keep it running. Stablecoins have moved into mainstream finance, linking bank systems with digital asset networks. Dollar-pegged tokens already move volumes on the scale of major payment networks, with transactions rivaling ACH, Visa, and PayPal. In mid-2025, the supply of stablecoins crossed $250B, reflecting demand for quicker, always-on payments. This growth has driven demand for purpose-built blockchain infrastructure. Networks like Tempo are optimized specifically for stablecoin workloads, offering the low latency and predictable execution that payment applications require. This rise comes from the need for faster, always-on payment rails. Regulators and institutions are paying closer attention, while banks and fintech firms roll out stablecoin strategies to modernize their transfers. Once a trading side-product, stablecoins are now part of mainstream payment infrastructure. Source: Messari 2025. How Stablecoins improve cross-border settlements In cross-border transfers, stablecoins cut time and cost. The main advantages are: Faster settlement for cross-border transactions: Transfers land in minutes instead of one to two days. There are no wire cutoffs or banking hours to wait for, so money can move between regions anytime. For businesses, that kind of speed improves cash flow and reduces settlement risk. Lower costs: By bypassing correspondent banks and reducing currency conversion steps, stablecoins cut fees. Users enjoy lower FX and transaction costs, which is especially impactful for emerging markets and high-volume remittances. Even small businesses can avoid hefty wire fees and unfavorable exchange rates by using stablecoins for international payments. Financial access: In countries with volatile currencies or limited banking, a phone wallet holding USDT or USDC works like a dollar account. Anyone with internet access can hold and send value in dollars, which opens up global commerce to people locked out of the traditional system. Companies now use stablecoins for things like moving capital between subsidiaries, and payment networks have run pilots for payouts. Real-time settlement and reduced FX friction are the main draws, with speed, cost, and accessibility improving over traditional systems. Stablecoin adoption and network data in 2025 Messari’s State of Stablecoins 2025 gives a clear picture of adoption, market size, and on-chain activity: Market size: Global stablecoin capitalization passed $250B in 2025 as regulatory clarity improved. The demand for digital dollars now extends well beyond crypto trading. USDT dominance: Tether’s USDT leads the market with about 63% share and over $155B in circulation. More than half of that supply runs on Tron, which has become a major hub for stablecoin activity. By size alone, USDT now rivals the market cap of large banks. Tron network usage: Tron has grown into one of the main settlement layers for stablecoins, especially in emerging markets. The network handles the majority of USDT supply and supports billions in daily transfers. More than half of USDT lives on Tron, which processes around $21.5 billion in USDT transfers daily. Tron’s low fees and fast transactions have attracted a huge user base – the network now accounts for roughly 26% of global active stablecoin addresses. (Ethereum remains the largest by value, but Tron and BNB Chain lead in active usage.) Transaction volumes vs. payment networks: Stablecoin usage is reaching parity with traditional payment systems. By mid-2025, monthly stablecoin transfers had overtaken PayPal and Visa and were closing in on ACH volumes. The amounts moving each month now match the scale of the largest payment processors. Stablecoins have grown fast: hundreds of millions of users transact with them, and chains like Ethereum, Tron, BNB Chain, and Solana process much of the flow. The result is a system already handling value at the level of global settlement infrastructure. USDT vs. USDC: use cases in global transactions (emerging markets focus) Tether (USDT) and Circle’s USD Coin (USDC) are the two dominant stablecoins, but they have somewhat different use case profiles – especially in emerging markets. USDT is by far the most widely used stablecoin in day-to-day trading and informal economies, while USDC plays a bigger role in regulated and institutional contexts. USDT picked up early as the base currency on exchanges, and today it counts over 400 million users around the world. Traders rely on it because of its liquidity and because almost every crypto pair is quoted in USDT. Beyond trading, it has become the go-to option for savings and everyday payments in many emerging markets. In places dealing with currency depreciation or capital controls, people often use USDT as a practical substitute for dollars. Across most of Africa and Asia, on-chain USDT accounts vastly outnumber USDC accounts. (In contrast, usage in Europe and North America is more balanced between the two stablecoins.) The Messari report finds that on average there are 5.4 times more USDT users than USDC users worldwide, with the gap being highest in regions like West Africa and the Caribbean. This reflects how deeply ingrained USDT has become in emerging market transactions. Peer-to-peer fiat markets on exchanges show the gap clearly. In most emerging economies, USDT trades at higher volume — and often at a higher price — than USDC. In places like Nigeria or Russia, it even runs at a premium to the official bank rate, since people are willing to pay extra for stable USD value. For many, these P2P desks work like informal remittance or FX channels, a way to swap local currency into USDT to hedge inflation or send money abroad. Liquidity and recognition make USDT the easier choice; holders know they can convert it back into goods or cash almost anywhere. USDC sees less use in these settings, since its base of users in developing markets is still catching up. That said, USDC has been picking up ground in more formal transactions. It’s the second-largest stablecoin and is often chosen by fintechs, banks, and corporate treasuries because of its regulatory clarity and U.S.-based reserves. Circle has pushed USDC toward enterprise use. It built a payments network for institutions and expanded liquidity across chains. The effect shows in the numbers: by early 2024, monthly transfers cleared $1 trillion, much of it in B2B flows, e-commerce, and ramps. In developed markets, and especially where banks integrate directly, USDC is a common tool for settling trades or powering financial products. But at the retail level in emerging economies, USDT still holds the lead. Liquidity follows habit. People have used USDT for years, and that history keeps it ahead of USDC. Scaling stablecoin infrastructure with Chainstack Stablecoins are moving billions across networks every day. Running them at scale requires reliable nodes, cross-chain connectivity, and 24/7 monitoring. That’s the piece Chainstack solves. With 70+ supported networks, including Ethereum, Solana, Tempo, and BNB Chain, Chainstack lets teams deploy nodes in minutes and keep them synced without the overhead of maintenance. Issuers and platforms get secure, low-latency access for minting, burning, and transferring stablecoins at scale — all backed by global infrastructure and expert management. For stablecoin-specific workloads, Chainstack also supports Tempo—a blockchain optimized for payment infrastructure with predictable gas costs and sub-second finality. Start building on Chainstack Wrapping up Stablecoins are no longer just a trading tool, they’ve become one of the main rails for cross-border money movement. USDT dominates peer-to-peer flows in emerging markets, while USDC is finding its place in regulated and institutional payments. Both rely on dependable infrastructure to keep growing. As adoption climbs past $250B in circulation, the technical backbone matters as much as the tokens themselves. The networks carrying the flows and the infrastructure that keeps them reliable will decide how far stablecoins go in global finance. Power-boost your project on Chainstack FAQ What is a stablecoin in cross-border payments? A stablecoin is a crypto asset pegged to a fiat currency, most often the US dollar. In cross-border payments it works like a digital dollar, moving value quickly and at lower cost than traditional correspondent banks. Why are stablecoins used for international settlements? Because they settle in minutes and run 24/7 on public chains. That avoids the delays and high fees of bank wires, making them efficient for sending money across borders. Which stablecoin is most used in emerging markets? USDT dominates in peer-to-peer markets across Africa, Asia, and Latin America because of its liquidity and recognition. USDC is more common in regulated or institutional contexts. What blockchains carry the most stablecoin activity? Ethereum handles the largest share of value, while Tron and BNB Chain lead in active user counts and daily transfer volumes. Solana also supports significant flows. Is stablecoin adoption regulated? Regulation varies by country. The U.S., EU, and several Asian markets are rolling out frameworks that require reserve transparency and licensing for issuers. #### Stablecoins on Solana in 2026: Growth, adoption, and usage Institutions and government policies have driven on-chain growth in the past, but nothing like the growth of stablecoins in just a few weeks. Stablecoins, blockchain tokens that are 1:1 backed by a fiat currency, have gained significant momentum since 2025 and continue to do so in 2026. Institutions and governments are using existing and issuing new stablecoins to appeal to customers interested in cryptocurrency, to tokenize real-world assets, and to incorporate the valuable characteristics of cryptocurrency (such as fast settlement) into the financial system. Solana has become the most popular blockchain for using traditional stablecoins (USDC, USDT) and issuing, managing, and using new ones. In this article, we analyze the Solana stablecoin market in 2026, including market size, adoption trends, transaction activity, and the role of USDC. Why institutions and businesses are adopting stablecoins in 2026 Institutions, such as banks and hedge funds, and governments, are adopting stablecoins due to market trends, regulatory clarity, and to enhance the user experience with the traditional financial system. Businesses are increasingly offering cryptocurrency as a payment option and providing stablecoin options for easy conversion between crypto and fiat. For example, PayPal allows customers to pay merchants in multiple cryptocurrencies. PayPal merchants can convert crypto to PYUSD on Solana and other chains, its USD-backed stablecoin, making it easy to manage and convert crypto funds into a US dollar-denominated cryptocurrency, and organize their revenue alongside other fiat currency payments like credit cards and cash. Stablecoins allow customers and users to interact with cryptocurrency while retaining the familiarity of fiat currency.  Other institutions are also capitalizing on the value-adds of cryptocurrencies, using stablecoins to modernize the financial system. WorldPay, one of the largest payment companies in the world, launched USDG on Solana to enable faster settlement, enabling companies and users to finalize transactions within seconds rather than days. Favorable government regulation has also encouraged innovation and exploration in stablecoins. A recent article explained that the GENIUS Act, passed in July 2025, established the first legal framework for issuing and managing stablecoins in the United States. The law outlined the handling of the treasuries backing each stablecoin, monthly reporting guidelines, and anti-money laundering guidelines. With such legal clarity, institutions were confident in issuing compliant stablecoins to capture the three-trillion-dollar cryptocurrency market.  Governments are also launching their own stablecoins to increase transparency, as cryptocurrency transactions can be traced by anyone. The State of Wyoming launched its own stablecoin, FRNT, on Solana and other chains, citing the ability for citizens to easily track funds compared to fiat currency. Why Solana is the leading blockchain for stablecoins Institutions are particularly choosing Solana for its advantageous blockchain characteristics, including its speed and low costs. Institutions are attracted to its rapid transaction finalization, currently 0.4 seconds and aiming to reduce it to 0.15 seconds, and cheap and predictable transaction fees of less than $0.01, according to Nick Ducoff, Head of Institutional Growth at the Solana Foundation. https://twitter.com/solana/status/1979194160612544610 Visa notes that they see the potential of Solana “become one of the networks that could help power mainstream payment flows” also due to its high availability, or number of independent participants or nodes that jointly operate the network to make it available for consumers to initiate transactions. 1,893 active validators confirm transactions and make blocks while 925 RPC nodes maintain a local record of transactions. Deploy Solana node now Solana stablecoin market growth (2023–2026) Solana has seen multiple-fold growth in stablecoin trading volume and in new stablecoin issues since the start of 2025. Solana stablecoin market cap growth Stablecoins on Solana reached a market cap of over $14 billion by the end of 2025 and have remained steady since then, reaching over $14 billion by the end of January 2026. This is up three times the volume at the end of 2024, where the market cap hovered at $5 billion.  A graph showing the growth of the total market cap of stablecoins on Solana since 2023. Source: DefiLlama Other chains also saw multiple-fold growth, but not as massive as Solana. Ethereum, which accounts for more than half of all stablecoin market cap, saw a 1.6x increase, from $60 billion in 2024 to $166 billion today. Arbitrum saw two-fold growth, ending 2024 with a stablecoin market cap of $1.99 billion and, in January 2026, reaching a market cap of $4 billion.  With such rapid growth compared to even Ethereum, the most prominent chain for stablecoins, Solana now accounts for 4% of the $306 billion stablecoin market. Solana has slowly gained market share amongst all other chains in the past three years. Year-endTotal stablecoin marketcap on all chainsTotal stablecoin marketcap on SolanaSolana market share2023$130.72B$1.83B1.40%2024$204.82B$5.01B2.45%2025$304.67B$14.45B4.74%End of January 2026$305.95B$13.794.51% This graph illustrates the stablecoin market share from 2023 to now, with Solana’s stablecoin share (bright green) being minimal in 2023 and gradually growing each month. Source: Artemis Why stablecoin adoption is growing faster on Solana Solana has gained market share over the years due to the likelihood that users will trade stablecoins on the chain, the proliferation of new stablecoins, and the growing popularity of USDC. Solana as the most active chain for stablecoin transactions While other chains, such as Ethereum and Tron, have higher stablecoin market caps, Solana boasts a much higher stablecoin transaction volume. This suggests that users have a variety of DeFi and payment options for using stablecoins, attracting new users who seek to do more than merely hold them. Despite having the third-highest stablecoin market cap among all chains, Solana was the most popular chain for stablecoin transactions over the past five years. In the past year, it ranked second. In comparison, Ethereum, despite having a stablecoin market cap 10 times that of Solana, ranked only 9th in stablecoin transactions last year. Chains ranked by the number of stablecoin transactions in the past year. Source: Artemis A majority of stablecoin transactions on Solana were made on decentralized exchanges (DeFi), via asset management tools, or by stablecoin holders optimizing their positions. On Ethereum, DeFi also dominated, with transactions on centralized exchanges a close second, and asset management the least used for stablecoin transactions. This suggests that stablecoin users on Solana are more likely to actively exchange and invest their stablecoins, creating utility that will attract more stablecoin holders to use Solana. The number of stablecoin transactions by sector or platform/tool type - left graph as Solana and right graph as Ethereum. Source: Artemis - Solana and Ethereum  Growth of new and non-traditional stablecoins on Solana Solana emphasized enabling institutions to issue their own stablecoins on the chain. Solana has a higher ratio of individual stablecoins to its overall market cap than Ethereum does, with over 57 stablecoins listed on DefiLlama.  Non-traditional stablecoins have accounted for an increasing share of stablecoin activity on Solana. The transaction volume share of non-traditional, newer stablecoins on Solana grew from 4.4 percent in January 2025 to 23.7 percent in January 2026. Source: Dune Analytics via Step Analytics Team Some new stablecoins launched on multiple chains found the most success on Solana. For example, PYUSD, PayPal’s stablecoin, was first launched on Ethereum in 2023, but since July 2025, transaction volume of PYUSD on Solana has consistently surpassed that of Ethereum.  The transaction volume of PYUSD by chain - Arbitrum (gray), Etheruem (purple), and Solana (green). Source: Artemis. Traditional stablecoins USDC and USDT account for a slightly smaller share of Solana's market cap than on Ethereum. The market caps of USDC and USDT (combined $131.2B) account for 82 percent of the stablecoin market cap on Ethereum, but less than 80 percent on Solana. Why USDC dominance gives Solana an advantage over Ethereum USDC has grown much faster than USDT, giving Solana an advantage over Ethereum, since USDC is the most popular stablecoin on Solana while USDT is the most popular on Ethereum.  USDC dominance, defined as the percentage of the total stablecoin market cap, on Solana is 55.70%. On Ethereum, USDT has a 52.00% market share, making it the most popular stablecoin. Therefore, a growth in USDC favors Solana more than Ethereum, since USDC is more popular on Solana than USDT is on Ethereum. USDT has grown from a total market cap of $91 billion across all chains in 2024 to $186.617 billion, a twofold increase. USDC has seen a threefold increase, from $24 billion in 2024 to $72.9 billion now. The total market cap of USDC across all chains. Source: DefiLlama Though USDC's market share on Solana is declining amid the entry of smaller stablecoins, the stablecoin market cap on Solana is growing alongside USDC’s popularity.  A graph illustrating the growth of stablecoin supply for major stablecoins on Solana, with USDC holding the largest share. Source: Token Terminal USDC holders are increasingly choosing Solana for their transactions. Despite having much fewer USDC on Solana ($7.03B) than on Ethereum ($47.064B), USDC transfer volume on Solana surpassed that on Ethereum on December 29, 2025, and has since continued to exceed it.  A graph showing the transfer volume of USDC by Ethereum (bright green), Solana (blue), and other chains (various colors). In late December, USDC transfer volume on Solana (blue) surpassed that on Ethereum. Source: Token Terminal What to Expect in Solana Stablecoins in 2026 In 2026, Solana is dubbed the “internet capital market,” positioning itself as a high-throughput platform for on-chain trading, stablecoin issuance, and the tokenization of real-world assets. Armani Ferrante, CEO of crypto exchange Backpack, said Solana is doubling down on the growing use of its financial infrastructure, including the issuance of new stablecoins.  With better financial infrastructure, Solana will be better positioned to manage more users on existing stablecoins and launch even more new stablecoins. Solana co-founder Anatoly Yakovenko expects the Solana stablecoin market cap to reach over $1 trillion, 8x today's amount. Solana is already gearing up for new major stablecoins. Jupiter, a leading decentralized trading platform, launched JupUSD in January 2026 with BlackRock, a top asset manager, and Ethena Labs, creators of the USDe stablecoin on Ethereum. In less than a month, it has already generated $11 million in volume. Western Union, one of the world’s largest providers of cross-border payments, is launching USDPT, a US dollar-backed stablecoin to handle faster settlements in the first half of 2026.  https://twitter.com/solana/status/1983222673841775098 How to launch a Stablecoin on Solana As more institutions and governments issue and use stablecoins, the requirements for stablecoins are becoming stricter, demanding infrastructure that meets institutional standards. Chainstack can help you issue your stablecoin on a fully audited, SOC 2 Type II-certified, compliant infrastructure with bank-grade security on day one. Major institutions spanning banking, accounting, and wallets, including Circle (the issuer of USDC), Ernst & Young, Sygnum Bank, and Anchorage Digital, are leveraging Chainstack today for their stablecoin infrastructure needs. Recently, Trust Wallet leveraged Chainstack’s production-grade multi-chain infrastructure to process transaction requests for its 60 million users across 4.5 million assets on 70 chains, streamlining technical operations and resulting in a 44% to 57% cost reduction.  Explore stablecoin-ready infrastructure → Conclusion Stablecoins, cryptocurrency tokens pegged 1:1 with a fiat currency, usually the US Dollar, are exploding in popularity, especially on Solana.  With regulatory clarity provided by the GENIUS Act and institutions recognizing the value of instant settlement, institutions and governments are seeking to issue new stablecoins and use existing ones. Solana has benefited more than other chains from this interest, with the stablecoin market cap increasing threefold since 2024. The stablecoin market cap growth on Solana is fueled by the variety and volume of trading products it offers. Solana’s strong DeFi presence makes it a strong home for new stablecoins. Solana has also benefited tremendously from the popularity of USDC, the network's most popular stablecoin.  For teams building payment infrastructure with strict latency and cost predictability requirements, purpose-built alternatives like Tempo offer blockchain architecture optimized specifically for stablecoin settlement and enterprise payment rails. 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 Where token metadata lives on Solana 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. FAQ What are stablecoins on Solana? Stablecoins on Solana are blockchain tokens pegged 1:1 to fiat currencies (usually USD) that operate on the Solana network. Popular examples include USDC, USDT, and PYUSD. Which stablecoin is most popular on Solana? USDC is the most popular stablecoin on Solana, accounting for 55.7% of the stablecoin market cap on the network. How much are Solana stablecoin transaction fees? Stablecoin transactions on Solana cost less than $0.01, significantly cheaper than Ethereum's fees. What is the total stablecoin market cap on Solana? As of January 2026, the total stablecoin market cap on Solana is approximately $14 billion, representing 4.5% of the global stablecoin market. Is Solana good for stablecoin payments? Yes, Solana's fast finality (0.4 seconds) and low fees make it ideal for stablecoin payments and real-time settlements. #### StarkNet - Overview of developer tools and zk-rollups StarkNet is a network for general purpose contracts written in Cairo, and its mainnet has been live since December 2021. It is one of the most popular L2 solutions today and the latest protocol supported by Chainstack. The enthusiasm behind this project is huge. During the past few months, I've been reading articles, tweets, and I even met some of the StarkWare team members, so I decided to do some research and try to write a contract that runs on StarkNet. However, before any of that, I knew that if I wanted to understand why Layer 2 solutions are so popular, first I needed to know the problem they solve and how they do it. That's where the StarkNet odyssey started for me 🚀 🪐 The Ethereum scalability problem Blockchains are decentralized systems. That means they do not rely on a single entity to validate transactions—they expect everyone to process every single transaction of the protocol. That's one of the reasons why currently, Ethereum is not able to match the performance in transactions per second that "old-school" systems like Visa can process. In the blockchain trilemma, Ethereum went with decentralization and security over scalability. Obviously, these "old-school" systems lack the decentralization of Ethereum. They rely on big data centers and databases that are controlled by a single entity. This difference is what Henri Lieutaud, from the StarkNet team, defined as "delegated accountability" (banks, Visa...) vs "inclusive accountability" (blockchains). Blockchains that appeared years after Ethereum, like Solana and Binance Smart Chain, targeted the scaling problem by increasing the block size, which means more transactions can be processed in each block or reducing the number of validators in the network. Both things improve the throughput of the protocols (and the TPS), but at the same time, it reduces decentralization. Ethereum Layer 2 solutions Layer 2 blockchains (or L2s) try to improve scalability in Ethereum by moving a lot of the heavy work of transactions and smart contract logic out of the Ethereum main net while keeping the same security. In addition to that, L2 solutions promise lower gas fees, which is one of the biggest problems that Ethereum users face on a daily basis. But how do they do it? With rollups. In a nutshell, rollups bundle multiple transactions together, settle them out of the main network, and send only the resulting state to Ethereum. There are two main types of rollups: optimistic and zero-knowledge. As we're focusing on StarkNet, we'll focus on zk-rollups. What are ZK-Rollups? Zero-knowledge rollups or zk-proofs are a mathematical tool that allows systems to prove that certain transactions have been correctly settled and updated the state of the blockchain without actually processing those transactions. Generating a zk-proof requires certain computation power, but the advantage is that verifying a proof requires less computation, hence the savings in fees. In addition, the computation required to generate a proof and verify it grows logarithmically with the number of transactions included in a rollup, which means when more computation is required to generate a proof, it will require more computation to verify it but it will grow more slowly. StartkNet transaction lifecycle When a transaction is submitted in StarkNet, it goes to a sequencer node. The sequencer takes batches of transactions and generates two things: A list of changes caused by all the transactions in the batch (changes in storage, balances, etc ). A proof that, if all transactions included in the batch are executed successfully against the previous state of the network, the result will be the list of changes listed before. After that, the proof and list of changes are sent to Ethereum where the rollup contract verifies them and updates the state. The last part is important because that means that all Ethereum nodes are actually StarkNet verifiers. This also means that zk-proofs can be used in other EVM compatible blockchains and that StarkNet could potentially be deployed as an L2 solution for other protocols. In StarkNet, the transactions are not recorded on-chain—only the state changes resulting from the transactions themselves are recorded on-chain in L1. Transaction fees in StarkNet StarkNet fees are paid in ETH and the team released a post about fees in which they indicate how StarkNet calculates them for each transaction. The StarkNet toolkit Using and developing projects for StarkNet requires you to know its own series of tools. Here are some of them: Explorer: Voyager Voyager is the explorer for both the mainnet and the Goerli testnet. Wallets: ArgentX and Braavos Accounts in StarkNet are pretty different from other chains like Ethereum. In StarkNet, each account is a smart contract deployed in the network that implements the IAccount interface. Actually, if you search your account in Voyager, you'll see that it's a proxy contract that implements the code of the account base contract. This allows StarkNet accounts to have a lot of features like addresses not being derived from a public key, support for multicalls (multiple transactions in a single call), or even multiple signers out of the box. As accounts are smart contracts, that means that when you create one, it takes a little bit to actually be deployed. There are two main wallets, ArgentX and Braavos. From a user's perspective, both are Chrome extensions and behave similarly to Metamask. When you submit a transaction from a DApp, you'll see a pop-up to sign the transaction. Install Braavos Install ArgentX Node clients: Pathfinder & Juno StarkNet nodes use the Pathfinder or the Juno client and they are similar to the nodes running Go Ethereum, although the exposed API at the time of this blog post only has methods to read from the blockchain as posting transactions is done via sequencers. There is a GitHub issue in the Pathfinder client repository that aims to allow transactions to be submitted to a node and then forward them to a sequencer, but it's a work in progress. Sequencers are special StarkNet nodes that receive the transactions and generate the rollups. These are currently run by StarkNet. Programming language: Cairo Cairo is not a smart contract language like Solidity, it's a general-purpose language that allows you to write programs that can be executed by a StarkNet prover and generates a proof that can be verified later on by an Ethereum node. Why use Cairo and not Solidity? It's needed to generate mathematical proofs. Cairo requires Python and although the programs are written using the Cairo language, the tests are written in Python. It's similar to smart contracts written in Solidity and tests in JavaScript. Framework: Nile You can think of Nile as the Hardhat for StarkNet. It makes managing files and command-line calls to StarkNet very simple, and you can use it to bootstrap a new project. Developing in StarkNet Setting up the development environment To install all the dependencies, we'll use Homebrew, so go ahead and install that first. To develop programs for StarkNet, we need Python 3.x Install it via homebrew with brew install python@3.7. Now I can run Python scripts using version 3.7 with python3 in the terminal. For example python3 --version Next, install pip with python3 get-pip.py after downloading the installation script from here. Pip is a package manager for Python, similar to NPM for JavaScript. With Python and Pip ready to go, create a virtual environment with: python3 -m venv ~/cairo_venv source ~/cairo_venv/bin/activate Now install dependencies required for Cairo with pip3 install ecdsa fastecdsa sympy and brew install gmp. Next, install the Cairo language itself with pip3 install cairo-lang If you have any issues, you can double-check these steps in the official guide. First steps with Nile Nile is the toolbox that facilitates bootstrapping a Cairo project. To install it, run pip install cairo-nile. To initialize a project, just run nile init Here are the main commands you can run with Nile: To compile the contract run nile compile. Compiled files will be in the /artifacts folder. To run a local node, run nile node. To run tests, use pytest -s path/to/testfile To deploy a contract run nile deploy myContract --alias contract where the first "myContract" is the contract file name and the second, the alias you want to save it with. To interact with a deployed contract use nile invoke for @external functions or nile call for @view functions. For example, nile invoke bank createAccount To deploy to the StarkNet mainnet, use nile deploy my_contract --alias my_contract --network mainnet Conclusion In this first part of this series, we've reviewed what L2 solutions are and what problems they solve. We've also analyzed what are zero-knowledge proofs and how StarkNet uses them to validate transactions. Now that we know all the different tools that we need to start developing in it and with the development environment setup, we're ready to create an app and deploy it to StarkNet test net. But that will be in part 2 of this StarkNet odyssey 🚀 🪐 #### Start and deploy your own fully synced Ethereum node in under 10 minutes Deploy Ethereum node Have you ever tried to deploy an Ethereum node? Do you feel like "does Ethereum node ever sync"? Well, it has to sync from the genesis block and this may take quite some time, but don't worry, we have a solution for you. Deploying a smart contract these days is easier than you think. By combining a popular framework called Embark with Chainstack’s capability to quickly deploy Ethereum nodes on the mainnet, smart contract deployment is as easy as sending an email. Install dependencies Before continuing, you should install these dependencies: NodeJS & NPM Geth Once we’ve installed these dependencies, we can install Embark. npm install -g embark Also you should install Metamask to simplify the interaction process later on. Smart contracts Fractional ownership of a high value asset can be made possible via smart contracts. The Lisa Mona, a piece of artwork that costs approximately $100,000,000 is up for auction to small retail investors. Since retail investors do not have the funds to purchase the Lisa Mona in its entirety, the Lisa Mona can be represented by 1000 tokens on the Ethereum virtual machine. Hence, owning 1 token is equivalent to owning 1/1000 of the Lisa Mona, worth exactly $100,000 per token. Asset tokenization also makes it easy for investors to trade tokens as they deem fit. I’ve designed a simple smart contract to tokenize the Lisa Mona, called Art.sol. Art.sol pragma solidity = 0.5.0; contract Art{ uint public supply; uint public pricePerEth; mapping( address => uint ) public balance; constructor() public { supply = 1000;// There are a total of 1000 'mini' Lisa Monas pricePerEth = 100000000000000000; // 1 token = 0.1 ether } function check() public view returns(uint) { return balance[msg.sender]; } function () external payable { balance[msg.sender] += msg.value/pricePerEth; supply -= msg.value/pricePerEth; }} We’ve set the price of one Lisa Mona token to 0.1 ether. This means that to own 1/1000 of a Lisa Mona, an investor simply has to send 0.1 ether to the smart contract. Save the code above as Art.sol. We will be using Embark to deploy the smart contract to the Ethereum testnet (Ropsten) so you can deploy and interact with it without spending real ether. Spinning up your Ethereum node When a developer wants to deploy a smart contract, the transaction is broadcast to a node. The developer has to trust that the remote node is perfectly honest, in technical parlance, non-Byzantine. A better option would be to run your own full Ethereum node, which comes with several benefits such as: 1. No throttling for high usage2. Ensuring that all transactions made to the blockchain are correct3. Lower latency if the node is located in the same geographical location Chainstack makes it easy to create a Ropsten testnet node. Normally this can take up to 12 hours, but Chainstack’s Bolt does all of this in only 10 Minutes. Since we don’t want to spend real ether, let’s deploy our smart contracts to a Ropsten node. I’m working for Chainstack and at Chainstack, we can create a new Ethereum Node in just 10 minutes :) Let’s start by signing up for a free 7-day trial . We’ll call our project Museum, choosing the ‘Public chain’ as our project type (naturally, because we are dealing with Ethereum, which is a public chain). Click ‘Create’, and you have your project ready. Let’s create our project in the Chainstack console Now click the Embark project listing to get the ‘Join network’ modal. This is where you will specify various parameters to join the Ethereum network. For this tutorial, choose the Ropsten testnet: Choosing the Ropsten testnet Hit ‘Next‘ to configure our personal Ethereum node. Let’s choose a shared node since that will be enough for this tutorial. You can choose a dedicated node if you want to :) At the summary page, hit ‘Join network’, and wait to see Chainstack’s DevOps for blockchain weave its magic! The node will be magically created How to deploy a smart contract? On our local machine, let’s create a new Embark project: embark new Artcd Art Now let’s copy the smart contract that we created earlier into the contractsfolder. cp \path\to\art.sol .\contracts We’re ready to deploy our contract. But how do we get Embark to connect to the Chainstack node that we just created? To do so, let’s create a wallet that will deploy the contract to the network. geth account new Follow the instructions to create your new account. For this tutorial, we will be using a keystore file. You can get the path to the keystore file by typing: geth account list This generates the addresses you have created along with the path to the respective keystore files. Let’s assume that the keystore file is at /PATH/TO/KEYSTORE/UTC-123.123 for the rest of the tutorial. Let’s also copy the keystore file to the project directory so we can easily import it into Metamask later on. /PATH/TO/KEYSTORE/UTC-123.123 . Lastly import the keystore file into Metamask: Importing the keystore file Copy the address of the wallet, and claim some Ropsten ethers here. Connecting to a Chainstack node Now go to the node details page in Chainstack, and get its RPC endpoint. If you forgot how to do that, simply log in to Chainstack and then navigate to your projects page. Click on your project Museum. Following that, click on your network name, and in the next page choose the node that you want to connect to. It should bring you to this page: Take note of the RPC and WS endpoints at the end. The file located /config/contracts.js contains the environment configuration. This file tells Embark the node to connect to. Let's create one for this tutorial called chainstack. Copy the code below, and append it to the end of contracts.js before the last curly brackets. Be sure to change the variables for privateKeyfile,password and host accordingly. chainstack: { deployment:{ accounts: [ { privateKeyFile:"/PATH/TO/KEYSTORE/UTC-123.123", password:"PASSWORD" } ], host:"RPC_ENDPOINT", port:false, protocol:"https", type:"rpc" }, dappConnection: [ "$WEB3", // uses pre existing web3 object if available (e.g in Mist) "ws://localhost:8546", "http://localhost:8545" ], gas: "auto", } ... We’re all set. To deploy the contract run the code below in the root of the directory. embark run chainstack The chainstack argument after run tells Embark to use the chainstackconfig in contract.js. Your terminal should display something like this: Congratulations, you’ve successfully deployed your own contract :) Interacting with the smart contract Embark conveniently creates a front-end application (called Cockpit) for us to play with our contract. Enter this into the browser of your choice: http://localhost:55555/explorer/contracts/Art You’ll be prompted for the login token. Go to your terminal and type tokenin the Embark console. This immediately generates and copies the token to your clipboard. Go back to your browser, and you can now log in. You’ll now be at the contract page of the smart contract you just deployed. Feel free to click on any of the functions and experiment. All of the functions that we specified in Art.sol is conveniently displayed here Sending some ether to the smart contract Let’s use the same Ethereum account which deployed Art.sol to send some ethers and get ‘mini’ Lisa Monas in return. First let’s check how many ‘mini’ Lisa Monas we own. Execute the check() function in Embark’s cockpit. Not suprisingly, it returns the value of 0. check() //returns 0supply() //returns 1000 Now copy the address of the smart contract and send some ethers to this address. Let’s start by sending 0.1 ether. Going back to Embark’s cockpit, let’s try calling the functions check() and supply() after approximately 30 seconds (we have to let the transaction be mined first). check() //returns 1supply() //returns 999 Voila! You’ve just purchased 1 ‘mini’ Lisa Mona. You now officially own exactly 1/1000 of Lisa Mona, a piece of art so stupendously expensive that it was beyond the reach of most mortals, until now. Also congratulations, for you’ve just deployed and interacted with your own smart contract! Conclusion I hope that this tutorial has helped you appreciate how easy it is to deploy a smart contract using a popular framework such as Embark along with Chainstack’s quick node deployment. At Chainstack, we’re always looking for ways to improve, so drop us a message anytime. 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. #### Stealth Addresses: Decrypting blockchain transaction privacy Living in the world of Web3, privacy remains an enigma. On one hand, we applaud blockchain technology for its transparency, decentralization, and immutable transactions; on the other, we despair at its inability to offer complete anonymity. This friction between the need for privacy and the openness of the blockchain is striking. The answer? Stealth Addresses. Born out of a need for better privacy in transactions, Stealth Addresses are an innovative approach, ensuring confidentiality while receiving funds, and hence are increasingly finding significance in the crypto universe. Let’s explore the details. What are Stealth Addresses? Stealth Addresses are a unique solution to the pressing issue of privacy in public blockchain records. Contrary to what we see in ordinary transactions where the recipient address is visible, Stealth Addresses aim to make these transactions as anonymous as possible. The concept of Stealth Addresses came into existence back in 2014, proposed by Peter Todd. These addresses use the elliptic-curve Diffie-Hellman protocol, which is essentially about establishing shared secrets over insecure channels, to provide privacy during transactions. When transacting parties use Stealth Addresses, it ensures that they continue to operate privately, while the recipient can check their transactions using a special "spending key." Figure 1: Elliptic-curve Diffie-Hellman key exchange; Source: Wikipedia Each Stealth Address is unique, used only once, and remarkably, even multiple transactions coming in from the same recipient don't change this fact. The best part? This upgrade from ordinary wallet addresses to Stealth Addresses does not necessitate heavy adjustments from the users—instead, the entire process remains largely similar to how transactions were made using pre-existing tech. Why are Stealth Addresses important? It's high time we understood and clarified a common misconception about cryptocurrencies—they are not intrinsically anonymous! Although it might appear as though having a wallet provides you with a digital mask, that isn't entirely true. A public blockchain network, in essence, is a shared database—minutely inspect it, and you'll find each party's addresses and transaction amounts out in the open for everyone to see. The issue arises when an address owner's identity is discovered. Suddenly, the so-called "anonymous" transaction isn't anonymous anymore. Hence, it becomes abundantly clear why Stealth Addresses are such a crucial addition to Web3, enabling users to maintain their privacy while carrying out transactions. Figure 2: Anonymity over the blockchain - 3 points of potential breakdown; Source: Delfr Issues with public blockchain records Public blockchain records are designed to be transparent and immutable, two features that contribute significantly to the trust users place in the blockchain. However, these strengths can also become weaknesses when it comes to privacy. Public blockchain records display the wallet addresses involved in a transaction and the amount transferred. This information is openly accessible to anyone via a blockchain explorer. While this transparency allows for auditing and accountability, it also means that once an individual's wallet address becomes linked to their real-world identity, their entire transaction history can potentially be traced and analyzed by any third-party observer. Consequently, this lack of privacy can expose users to numerous risks, including personal security threats or analysis of financial behavior. Reasons for generating one-time Stealth Addresses Blockchain technology might promise pseudonymity, not anonymity. When your name or any other identifiable data becomes associated with your public wallet address, your security is compromised. Situations where you must share your wallet address online expose you to potential threats. Moreover, if you transfer crypto from platforms where you have undergone KYC verification, that address becomes a point of possible privacy failure. The possibility of tracing transactions back to wallets might seem trivial at first but it can have severe implications. Stealth Addresses have been proposed and used as a potential solution to this issue. They allow you to keep your real wallet address hidden, which can act as a deterrent for would-be trackers. Stealth Addresses essentially work as your digital PO Box or a VPN network masking your computer's IP address—they keep your personal information obscured, making any incoming transactions untraceable. In Web3, where transactions are digitized and easy to trace, Stealth Addresses are a step towards maintaining the balance between security, transparency, and the much-needed privacy of users. How Stealth Addresses work In traditional blockchain transactions, a sender requires the recipient's public wallet address to transfer funds. However, this leads to a significant privacy issue: if a wallet address is connected to a real-world identity, all transactions involving it become traceable. Stealth Addresses were developed to address this concern. Figure 3: Blockchain payments workflow; Source: vitalik.eth.limo Stealth Addresses increase security and anonymity by creating a unique, one-time address for each transaction. Consequently, even if a recipient gets multiple transactions, each is linked to a different address, enhancing privacy. The spending key in Stealth Addresses Firstly, "Bob," the recipient, creates a "spending key." This key is a secret private key that Bob will use to spend the funds he receives. It plays a pivotal role in ensuring that only Bob can access and use the funds sent to him. Figure 4: Spending key role in revealing balances; Source: Medium The meta-address of Stealth Address transactions Bob uses his spending key to generate a stealth "meta-address." This meta-address is then shared with "Alice," the sender. Alice will use this meta-address in the next step to craft an ephemeral key. The ephemeral key for Stealth Addresses Creating a Stealth Address involves the sender ("Alice") generating a one-time or ephemeral key. This key is a single-use random number that Alice uses, along with Bob's public key, to create the Stealth Address as per the guidelines defined within the Elliptic-curve Diffie-Hellman protocol. Upon completing the transaction, Alice includes the ephemeral key within the transaction data on the blockchain. Once the Stealth Address has been generated, Alice can proceed to send her assets to that address. Alice also releases an additional piece of cryptographic data on-chain: the "ephemeral public key." Figure 5: Stealth Addresses payment workflow; Source: vitalik.eth.limo Though Stealth Addresses add an additional layer of privacy, the transactions between Alice and Bob remain transparent and trackable on the blockchain. Yet, the true identity of Bob's actual address is concealed, maintaining an anonymous transaction between Alice and Bob. Alice's transfer to the Stealth Address can be observed by others on the network, but it is impossible for them to connect this transaction back to Bob. This method ensures that each transaction to the same recipient appears unlinked, enhancing privacy without compromising the blockchain's inherent transparency. Through this intricate process, Stealth Addresses create a balance between privacy and transparency, allowing for secure, anonymous transactions on a public ledger. Figure 6: How Stealth Addresses work; Source: Coinjar Advantages and challenges of Stealth Addresses Stealth Addresses bring to the table a wealth of advantages over existing privacy solutions in the blockchain world. First and foremost, they provide transactional privacy on a public blockchain. Even when multiple transfers are executed from the same sender, Stealth Addresses ensure every transaction appears to be to a different and unlinked recipient. Owing to their distinctive creation procedure, Stealth Addresses allow for novel financial privacy protections. They offer a solution to the inherent risk of address reuse, making tracking more difficult. Figure 7: Stealth Addresses vs regular wallet addresses comparison; Source: Cointelegraph By creating a one-time address for each interaction, they anonymize operations and protect users' identities from being linked to their blockchain activities. This quality is critical for various use cases where privacy is of utmost concern. Stealth Addresses complexity One of the main challenges is the complexity they introduce to the transaction processes. Users without technical knowledge might find it difficult to use Stealth Addresses, possibly leaving them more vulnerable. As such, there is a need to create user-friendly interfaces and craft comprehensive educative content to allow even non-technical users to utilize Stealth Addresses effectively. Transaction costs and Stealth Addresses Another challenge is the increase in transaction costs linked to Stealth Addresses due to the requirement of publishing additional on-chain data for each transaction. For instance, the bare-bones nature of these addresses raises issues when it comes to transaction fees or 'gas' in Ethereum. As the Stealth Address contains only what the sender transferred, the recipient might not have enough Ethereum (ETH) to cover gas fees for subsequent transactions. These extra costs could hinder the widespread adoption of Stealth Addresses. One way around this could be adding ETH from another wallet but that would create a publicly visible link, thus defeating the whole purpose of a Stealth Address. Some proposed solutions to this issue include making use of an advanced type of zero-knowledge proofs (ZK-SNARKs) or specialized transaction aggregators. Both options have their advantages, efficiencies, and trade-offs, and it's crucial to consider them when integrating Stealth Addresses into an existing system. Regulatory and audit challenges for Stealth Addresses Lastly, Stealth Addresses could potentially hamper the efficiency of conventional blockchain analysis techniques used to detect illegal activities. To mitigate this, developing new, robust tools and methodologies is necessary. Regulatory bodies could potentially see Stealth Addresses as a way to bypass anti-money laundering (AML) regulations or facilitate other illegal activities. Consequently, projects deploying Stealth Addresses may face scrutiny and resistance from regulatory authorities. Use cases for Stealth Addresses Stealth Addresses significantly enhance privacy across various scenarios, from crowdfunding campaign security to transaction anonymity on blockchain networks, notably within the Monero protocol. Let’s explore these use cases for Stealth Addresses and highlight their crucial role in ensuring transaction privacy, concealing identities, and promoting a more secure digital financial landscape. Protecting identity in crowdfunding campaigns Crowdfunding campaigns often accept cryptocurrencies due to their global nature and the simplicity of supporting them via digital wallets. However, exposing the wallet address of the receiver poses security risks as it opens up possibilities for tracking. Stealth Addresses protect the privacy of receivers in such scenarios by generating unique addresses for each transaction, making it difficult for external observers to link transactions to individuals, thus preserving the identity of the campaign owner. Increased network privacy Stealth Addresses can enhance privacy features across various crypto protocols, not just limited to a single network. Given the public ledger system and pseudonymous nature of many cryptocurrencies, transaction details like the sender, receiver, and amount are typically visible to all. By implementing Stealth Addresses, users of these protocols can obscure these details, enabling more private transactions across the board. Monero: The Stealth Addresses protocol Monero, a favorite among privacy enthusiasts, employs Stealth Addresses to ensure each transaction on its blockchain remains 100% untraceable. When a user sends XMR (Monero's native cryptocurrency), the funds are directed to a Stealth Address associated with the receiver’s wallet. Here, both sender and receiver identities remain concealed, as the transaction is "disguised" amongst several others thanks to the ring confidential transaction (RingCT) mechanism. Monero gives us a practical example of Stealth Addresses in real-world usage, enabling privacy-preserving transactions on its network. Figure 8: How Monero ring signatures work; Source: Coinbureau Stealth Addresses, in essence, enhance the privacy capabilities of cryptocurrencies, allowing users to maintain anonymity in a world where the traceability of transactions is often probable, if not straightforward. As more and more industries recognize and adopt blockchain technology, timely developments like Stealth Addresses that prioritize user privacy will become increasingly essential. Stealth Addresses and their future As we stand on the brink of technological revolutions that promise to redefine the landscape of digital privacy and security, Stealth Addresses emerge as a beacon of hope and innovation. Let's examine the future of Stealth Addresses, exploring their resilience against the anticipated challenges posed by quantum computing, their potential impact on EVM-based wallets, and their evolving implementation within the blockchain ecosystem. Anticipating the advent of quantum computers The advent and proliferation of quantum computers pose a potential threat to cryptographic systems, including Stealth Addresses. Quantum computing, by virtue of its computational power, could potentially decode cryptographic systems faster and more efficiently, leading to potential privacy breaches. However, developers behind Stealth Addresses have recognized this emerging threat and are working towards creating "quantum-resistant" Stealth Addresses. These are designed to withstand attacks from quantum computers, continuing to provide a robust privacy solution for crypto transactions. Implications for EVM-based Wallets For EVM-compatible blockchains, one of the privacy concerns relates to the link between the sender and the recipient which is publicly visible on the ledger. In this respect, Stealth Addresses could have a significant impact. By generating a unique address for each transaction, Stealth Addresses could be a game-changer for EVM-based wallets, providing an added layer of privacy and security to Ethereum users. Stealth Addresses implementation The concept of Stealth Addresses got its start in the Bitcoin community, but more recently, its implementation got integrated into the Ethereum ecosystem as well. Developers are increasingly starting to experiment with implementing Stealth Addresses on Ethereum, using smart contracts. Ethereum offers an advantage over Bitcoin in this aspect, given that smart contracts allow for more complex transactions and provide the ability to generate Stealth Addresses without changing the base layer protocol. In conclusion, while Stealth Addresses may currently seem like an advanced and perhaps niche privacy feature, we believe they have the potential to become mainstream in the not-too-distant future. The ongoing evolution and development in the crypto and blockchain space will undoubtedly continue to push the boundaries of what's possible, and Stealth Addresses will undoubtedly be part of that journey. Bringing it all together Stealth Addresses, with their innovative approach to privacy, mark a significant advancement in blockchain technology. By enabling one-time, untraceable transaction addresses, they not only bolster the anonymity of blockchain interactions but also provide a promising platform for developing highly secure, privacy-preserving applications. Nevertheless, the adoption of Stealth Addresses is not without its hurdles. Limited user understanding, higher transaction costs, and resilience against quantum threats are among the challenges that need addressing to ensure their extensive implementation and acceptance. As we step forward into a future where financial privacy could become increasingly vital, comprehending the power of dynamically concealed transaction identities given by Stealth Addresses will play a crucial role in shaping the landscape of monetary transactions. In the grand scheme of things, Stealth Addresses embody a meaningful stride towards a world where the power of money management can truly belong to the people, without compromising the sanctity of their privacy. The precise nuances of this technology and its potential integrations are just beginning to ripple across the ecosystem—making it a fascinating theme to keep an eye on. Remember, this evolving techscape demands an equal measure of openness to innovation and a keen eye on privacy—and Stealth Addresses, despite their challenges, appear to be a solid step towards balancing these crucial parameters. Here's to a more private, secure transactional future! Power-boost your project on Chainstack #### Supercharge your DApp deployment with the Chainstack faucet We are thrilled to introduce the latest addition to our Chainstack ecosystem: the Chainstack faucet for Sepolia and Goerli testnets. These indispensable tools are a boon for developers in need of Sepolia and Goerli tokens to deploy smart contracts and rigorously test their DApps. Engineered to simplify your development process on the Ethereum Sepolia and Goerli testnets, the Chainstack Sepolia and Goerli faucet propel your blockchain projects forward, one transaction at a time. What is the Chainstack Sepolia and Goerli faucet? Responding to the growing demands of our developer community, we've created the Chainstack Sepolia and Goerli testnet faucet. We understand your need for a reliable source of Sepolia ETH and Goerli ETH tokens to swiftly deploy and thoroughly test your projects. Now, thanks to the Chainstack Sepolia and Goerli testnet faucet, you can focus on what truly matters: creating an exceptional Web3 experience for your users. This innovative tool is designed to automate the dispensation of Sepolia and Goerli testnet Ether. The Chainstack faucet offers a fair and efficient system that enables developers to top up their balance to 0.5 Sepolia or Goerli ETH after a 24-hour cooldown period, ensuring all developers consistently receive the necessary resources to continue their work on the Sepolia and Goerli testnets. Building with the Chainstack faucet The potential for project development with the Chainstack Sepolia and Goerli faucet is boundless, turbocharging your DApp deployment and testing endeavors like never before. The faucet's reliable top-up feature ensures a seamless developer experience, free from unnecessary disruptions. This enables you to harness the full power of your DApp, propelling your project into a new realm of efficiency and effectiveness. You can be confident that your development work can proceed without disturbance with the faucet’s 24-hour cooldown feature, ensuring a consistent supply of both Sepolia and Goerli testnet tokens for your DApp needs. Boost your DApp testing and deployment process: Deploy smart contracts without worrying about running out of Sepolia or Goerli testnet tokens, thanks to the automated top-up feature of our Sepolia and Goerli faucet. Ensure a smooth testing process with a reliable 24-hour supply of Sepolia ETH or Goerli ETH tokens, reducing the risk of interruptions and delays. Streamline the development process by leveraging the steady supply of tokens from the Chainstack Sepolia and Goerli faucet to conduct thorough testing of your applications. Don't let the shortage of Sepolia or Goerli testnet tokens hinder your DApp development journey. Utilize the full potential of the Chainstack Sepolia and Goerli testnet faucet for continuous development and testing. The time has come to BUIDL your next-gen DApp with the assurance, convenience, and continuous token supply offered by the Chainstack infrastructure. How to get Sepolia and Goerli ETH from the faucet? Entering the realm of DApp development is now simpler than ever. Follow this straightforward step-by-step guide to navigate the Chainstack ecosystem and procure your Sepolia ETH or Goerli ETH from the Chainstack Sepolia and Goerli faucet. Log into the Chainstack console. Navigate to the Chainstack faucet page. Enter your wallet address and your Chainstack API key to request testnet ETH. The faucet follows a 24-hour cooldown period, enabling you to repeat this process daily for a consistent stream of Sepolia ETH or Goerli ETH for your development and testing requirements. Feature highlights The Chainstack Sepolia and Goerli faucet offers numerous benefits for developers venturing into the world of blockchain technology. Here's a snapshot of what you can anticipate with the Sepolia ETH and Goerli ETH faucet: Versatile: The faucet supports both Sepolia and Goerli testnets, catering to a wide range of DApp testing needs. Automated top-up: The faucet tops up your wallet to 0.5ETH automatically when your balance falls below this threshold, enabling uninterrupted development work. 24-hour cooldown: The faucet ensures fair and equitable distribution with a 24-hour cooldown period between requests. Efficient DApp testing and deployment: With a consistent supply of Sepolia ETH or Goerli ETH, you can deploy smart contracts, conduct robust testing, and streamline the entire development process. Reliable: The Chainstack Sepolia and Goerli faucet, backed by Chainstack's robust infrastructure, ensure reliability, convenience, and a seamless developer experience. Harness the potential of the Chainstack Sepolia and Goerli faucet and stay ahead in the ever-evolving world of decentralized technology. Start developing high-performance DApps on the Sepolia and Goerli testnets today. Power-boost your project on Chainstack #### Supercharging BNB Smart Chain builders with high-performing and resilient node infrastructure We are thrilled to announce that starting from today the blockchain community will be able to deploy BNB Smart Chain nodes and applications in a radically simple way using Chainstack. The move to add one of the fastest-growing digital asset ecosystems to Chainstack aims to empower enterprises and developers alike to build high-performing, low-cost blockchain applications with what is being heralded as a marked improvement for decentralized finance (DeFi). As reported by the Binance community, in April 2021, Binance Smart Chain has attained a new all-time high of 5 million daily transactions, nearly 4x the daily transaction count on Ethereum, while the gas price remains nearly 100 times less than that on Ethereum. The native cryptocurrency BNB is now the third-largest cryptocurrency by market cap after Ethereum. What is BNB Smart Chain? Created to run parallel to BNB Chain, BNB Smart Chain enables the creation of smart contracts and introduces a new staking mechanism for BNB. Envisioned as an extension of BNB Chain, BNB Smart Chain is built to solve the congestion and high fees problem on Ethereum catering to decentralized applications (DApps) without congesting Binance Chain, which is optimized for ultra-fast trading. The launch of Binance Smart Chain, an Ethereum Virtual Machine (EVM) compatible blockchain, also introduces a new consensus mechanism, the Proof of Staked Authority (PoSA). The PoSA consensus is obtained through 21 validators. It is a combination of Proof of Stake (PoS) and Proof of Authority (PoA), in which you must be both a known and validated entity and have a stake in BNB that places the entity in the top 21. Welcome to the world of CeDeFi A term coined by Binance CEO Changpeng Zhao, CeDeFi describes a mixed solution between centralized (CeFi) and decentralized (DeFi) finance that allows users to perform the full range of DeFi functions with low transaction fees by trading off on the degree of decentralization of the underlying blockchain. Binance Smart Chain is a fork of Ethereum which means that applications built on Ethereum can very easily migrate to Binance Smart Chain. Thanks to the dramatically lower gas fees, developers can deploy their DApps with actual economic incentives right from the beginning rather than spending a lot of time in testing environments, something that provides a faster and more reliable path to mainnet launch. This makes the transition to CeDeFi appealing to a number of businesses, builders, and existing ecosystems, given also that Binance Smart Chain allows developers to create new tokens using the BEP-20 standards, just like the ERC-20 on Ethereum. BNB Smart Chain on Chainstack The addition of BNB Smart Chain to Chainstack makes CeDeFi more widely accessible and scalable: companies now have an additional powerful option when deciding on the best blockchain protocol for their applications supported by two of the most experienced teams in the industry. Every day Chainstack provides thousands of companies worldwide with the blockchain infrastructure that is scalable, cross-cloud, cross-region, and radically simple to use. Although the industry has made many leaps forward in its maturity and usability, running a blockchain node or network still requires overcoming a lot of core infrastructure hurdles that take the attention away from product development and go-to-market. The cost of effort and time to do the infrastructure setup and sync a node can be eye-watering as it will take days due to the complexity and the large volume of the data to download and process. Chainstack enables developers to deploy their nodes and sync them in a matter of minutes, with predictable pricing that is industry-beating thanks to a high degree of automation and top-quality engineering. Alongside node management and operations, Chainstack blockchain managed services integrate tools and services to simplify building and running a DApp, a blockchain analytics platform, or a trading bot. How to use BNB Smart Chain on Chainstack Chainstack offers a reliable and easy to use platform for fast deployment of nodes on a range of hosting options, from fully managed public clouds on AWS, Azure, and GCP, to on-premises. Companies can now deploy BNB Smart Chain nodes in the same easy and cost-effective way, without needing to invest precious time and resources in setting up enterprise-grade infrastructure. Developers can trust Chainstack with their projects and drastically reduce their time-to-market as well as enjoy high-performing and reliable 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 BNB Smart Chain for shared full nodes at $0/month on Developer plan with 3M requests included, or unlimited requests on dedicated nodes on Enterprise plan. Shared BNB Smart Chain archive nodes on Business plan will include 3M request per month for $49/month, while dedicated archive nodes with unlimited requests will be available on Enterprise 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. Find full pricing information and a handy calculator here. Working together on making Web3 faster and better Chainstack creates a bridge between Web2 and Web3, where Web3 innovation can happen incrementally and within a Web2 infrastructure thanks to enterprise-grade, easy to use infrastructure, tools and services. Binance Smart Chain empowers companies to build high speed, low-cost applications using a blockchain built by one of the most well-known brands in the industry. Thanks to the addition of BNB Smart Chain to Chainstack, businesses of any size and industry vertical can leverage the innovative power of DeFi applications with higher performance and more affordable gas fees in the same enterprise-grade infrastructure already trusted by thousands of companies every day all over the world. Power-boost your project on Chainstack Connect to Ethereum, Polygon and Binance Smart Chain mainnet or testnets through an interface designed to help you get the job done. Get access to Ethereum and Polygon 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 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.  #### Teaming up with Copperx to transform crypto payments with robust Chainstack infrastructure Making recurring multi-chain billing and payment links accessible Chainstack's services have exceeded our expectations throughout our year-long partnership. Their exceptional support, swift responsiveness, and comprehensive offerings have been truly impressive. From the very beginning, Chainstack, led by Eugene, has consistently provided us with invaluable insights into the world of crypto payments. I am truly excited about this partnership, as it will enable businesses to accept and manage crypto payments in a secure, fast, and cost-efficient manner. Tarun, Co-founder, Copperx The world is becoming more decentralized by the day, and the adoption of cryptocurrencies is on the rise. With this shift, an increasing number of businesses are leveraging the power of crypto to improve their operations, extend their reach, and ultimately enhance their bottom line. Copperx is an innovative cryptocurrency payment solution that is simplifying the complex world of crypto transactions. Copperx gives businesses ability to accept crypto payments across multiple networks like Ethereum, Polygon, BNB and Solana with powerful features like Invoicing, Recurring Billing, Payment Links and more. What is Copperx? Copperx is a leading payment solutions provider outfitting businesses with a robust, simple-to-use platform for accepting cryptocurrency. In a matter of just 5 minutes, businesses can start accepting popular cryptocurrencies such as BTC, ETH, MATIC, BNB, USDC, and SOL across multiple networks and wallets. Comprehending the diverse needs of today's businesses, Copperx extends its flexibility beyond typical payment acceptance. Whether you're running a SaaS platform, E-commerce store, marketplace, or any other form of online business, Copperx provides the flexibility and tools for you to accept crypto payments, as well as generate context-specific payment links and invoices. Figure 1: Copperx products view; Source: Copperx One of Copperx's major strengths lies in its developer-first strategy. Its powerful APIs help developers save thousands of hours spent in integrating multiple networks, tokens, and wallets. Furthermore, Copperx's built-in support for multiple chains like Ethereum, Polygon, Solana, and Binance Smart Chain, and an array of tokens, delivers a truly versatile developer experience. Copperx’s services extend beyond simple payment collection. The platform comes equipped with pre-built dashboards, reports, and integrations to tackle different operational needs, accounting solutions, and tools for AML and fraud detection, ensuring a well-rounded, comprehensive solution for any business accepting crypto payments. Figure 2: Copperx dashboard; Source: Copperx Recurring crypto payments in a SaaS world Copperx doesn’t limit itself to just payments and transactions, it opens a world of possibilities through its many advantages. It fully embraces the no-code movement, making it the perfect option for DAO memberships, newsletters, content creators, and freelancers. With Copperx, you can set up automated crypto payments, enabling you to generate sources of passive income and get paid on autopilot. https://youtu.be/cJFZH0BZV18 Figure 3: Understanding recurring payments guide; Source: Copperx YouTube Designed with Web3 and its developers in mind, Copperx allows your business to accept recurring subscription payments over crypto. And in doing so it caters to the growing number of SaaS businesses in the diverse industry landscape. Furthermore, Copperx’s one-of-a-kind customer portal allows end-users to effortlessly manage their subscriptions. It transparently provides subscription details and gives the customer the freedom to update payment methods or even cancel them, displaying the customer-centric approach of Copperx. Figure 4: Creating a recurring payment plan on Copperx; Source: Copperx With easy integrations with popular tools like Quickbooks, Xero, and Zapier, Copperx goes above and beyond to ensure a seamless user experience. Copperx leverages the power of established streaming protocol - Superfluid, offering Web3 native subscriptions, salaries, and rewards for DAOs and crypto-native businesses. Copperx truly stands as a testament that the combined strength of modern technology like blockchain and good business practices can result in revolutionary products that serve the needs of today's businesses. Revolutionizing crypto payment experiences with Copperx With Copperx, accepting crypto payments becomes as easy as generating a link and sharing it through platforms like Telegram, WhatsApp, or Email. Creating a link can be tailored to sell a product or service, event tickets, or even to receive donations. Figure 5: Copperx customer portal view; Source: Copperx Making the process all the more effortless, Copperx allows users to embed these links on their websites and even provides the option of customized branding. This means that customer information like name, email, phone number, and billing details can be collected seamlessly as a part of the payment process via the payment link. The true pinnacle of this feature is the assurance of instant settlements. Copperx users no longer have to wait for blissfully long payment clearance times; they can access their funds immediately in their self-custody wallets. With its Payment Link service, Copperx truly revolutionizes the process of accepting crypto payments. Accessible crypto payments for all using Payment Links With Copperx’s Payment Links, accepting payments in crypto becomes as simple as sharing a link via messaging platforms or email. The Payment Link allows you to accept payments in Bitcoin, Ether, USDC, and more through secure and white-labeled payment pages. This service is ideally suited for selling products or services, crowdfunding, event ticketing, or receiving donations. Figure 6: Copperx event payment links; Source: Copperx Another added benefit of these payment links is the customizable checkout page offered by Copperx. It lets you as a business carry your own branding forward into the payment process, creating a cohesive customer experience that inspires trust. Whether you’re an e-commerce business, content creator, or a solo entrepreneur, Copperx's payment links ensure you never miss out on a potential revenue opportunity. Customer portal A truly standout attribute of Copperx is the seamless user experience it offers. With an intuitive interface and a dedicated customer portal, Copperx provides a customer-centric approach. Copperx extends the control over subscriptions and payments to its users, offering visibility into subscription details, the availability of payment methods, and the convenience to manage them as per their preference. Powerful dashboard and reports Copperx goes beyond the traditional model of analytics and offers real-time monitoring and updates. Automatic reminders ensure that users are aware of their wallet balances, subscription lifecycles, and any issue that may arise – a unique feature that sets Copperx apart. Figure 7: Copperx subscription analytics view; Source: Copperx Integrations and more Moreover, Copperx enables users to leverage popular tools such as QuickBooks, Xero, and Zapier. Through these integrations, seamless emailing to clients, bookkeeping, and custom report creation become far simpler. Paying close attention to the pressing need for security, Copperx’s association with Superfluid, a leading smart contract security firm ensures that every transaction and operation subscribes to the safety and security norms, thereby enhancing customer satisfaction. Through its unique approach, Copperx reinforces the importance of a truly satisfying customer experience in choosing a payment solution. How Chainstack nurtures multi-chain payments with Copperx At Chainstack, we're all about simplifying the complex world of blockchain technology. That is why we’re always thrilled to see how our reliable infrastructure make a tangible difference in the journeys of our pioneering partners. It was certainly a pleasure to witness Copperx effortlessly navigate the treacherous waters of crypto payments and embrace multi-chain support at the same time. The end result? Chainstack nodes played an instrumental role in improving response time, reducing latency and platform downtime, so Copperx could focus on what they do best—BUIDLing seamless Web3 experiences for their customers with fewer headaches. Plus, our powerful customization options gave Copperx the means to further scale their innovative recurring crypto billing and payment link solutions. And thanks to this, Copperx moved steadily towards their mission of empowering both creators and businesses alike in accepting crypto payments for donations, ticketing, and e-commerce at the click of a button. Resolution summary In our fruitful partnership with Copperx, we worked together to overcome any challenges we faced in and achieving some significant milestones like: Expanded network support: Copperx is now able to extend its services to customers on a wider range of chains, reducing complexity, lowering costs, and improving user experiences. Improved service reliability: Our robust node infrastructure helped minimize platform downtime and effectively distribute network load geographically to the most performant nodes. Scaling novel payment solutions: We paved the way for Copperx to further develop their cutting-edge crypto payment link and recurring revenue solutions in serving a wider global user base effectively. Strengthened industry use cases: With our support, Copperx extended its services to facilitate creators and businesses in accepting crypto payments for donations, ticketing, and e-commerce applications. Our joint journey has been all about teamwork and putting customer needs first. The strength of our relationship stems from a mutual understanding, a desire to learn and grow together, and a shared vision of a future powered by blockchain technology. At Chainstack, we're eager to continue our support for Copperx as they lead the charge in bringing accessible crypto payments to the global digital citizen. Power-boost your project on Chainstack #### Tempo: Low-latency blockchain infrastructure for stablecoins TL;DR Stablecoins now function as real-world money, not just crypto-native instruments. Payments, remittances, treasury settlement, and onchain FX place strict requirements on latency, finality, reliability, and fee predictability—constraints that most general-purpose blockchains struggle to meet at scale. Tempo blockchain is built specifically for stablecoin-dominant transaction flows, prioritizing: Low and predictable latency for real-time payments Fast finality to reduce settlement risk High reliability under sustained load Fee stability for high-frequency, low-margin transfers This article explains why stablecoin infrastructure demands these properties, where traditional blockchains fall short, and how the Tempo blockchain aligns with the economic realities of stablecoin-driven systems. Why stablecoin infrastructure need low-latency When users send stablecoins, they expect behavior closer to card payments, UPI, bank transfers or FX settlement rails. Stablecoins have quietly become the most widely used blockchain application category by volume. Unlike volatile assets, stablecoins are: Storage of value Unit of account Medium of exchange For our everyday lives, we need a stable currency to fulfil these three functions of money which has low volatility. Not the probabilistic, congestion-sensitive experience historically associated with blockchains. However, achieving this stability isn’t just about pegging a token to a dollar. A critical, often overlooked requirement is latency. It is often treated as a “nice to have” metric in blockchains. For stablecoin infrastructure use cases, it is a hard constraint. Low latency directly affects: User experience: Payments that take seconds (or minutes) feel broken in real-world commerce. Settlement risk: Delayed finality increases exposure between counterparties. Capital efficiency: Longer settlement times require higher buffers and collateral. Market efficiency: FX, arbitrage, and treasury operations degrade with delayed execution. Stablecoin infrastructure that operates at scale, whether remittances, merchant payments, or liquidity routing, must process large volumes of low-value transactions quickly and consistently. This creates a non-negotiable requirement: predictable, low end-to-end latency. What is Tempo Tempo is a payments-first blockchain designed for real-world stablecoin infrastructure, built around the core principles of decentralization, neutrality, reliability, and execution predictability. Tempo is developed from Stripe’s experience operating global payment systems and Paradigm’s expertise in crypto protocol design, and is led by Matt Huang, co-founder and managing partner of Paradigm, who also serves on Stripe’s board and acts as Tempo’s CEO. Tempo’s development is shaped directly by design partners operating large-scale, real-world payment, banking, and platform infrastructure, including Anthropic, Deutsche Bank, DoorDash, Lead Bank, Nubank, OpenAI, Revolut, Shopify, Standard Chartered, and Visa with infra partners such as BitGo, Blockdaemon, Chainstack and many more. At the protocol level, Tempo introduces a payments-first execution model: Predictable Low Fees: Tempo is engineered to maintain stable, low transaction fees even under sustained high load, ensuring cost predictability for payments, payroll, and remittance flows. Stablecoin-Native Gas: Payments and gas fees can be paid in any stablecoin through an enshrined AMM. This removes the need for a separate gas token and avoids application-level abstractions that introduce friction into stablecoin payment flows. Opt-In Privacy: Tempo supports selective disclosure, allowing participants to preserve privacy while still meeting compliance and operational requirements. Payments-First UX: The protocol includes native features such as a dedicated payments lane, transaction memos, and access lists, enabling clean, expressive, and auditable payment execution. Deterministic Execution Under Load: Tempo guarantees predictable transaction behavior during peak usage, eliminating the fee spikes and execution uncertainty common on generalized blockchains. High Scalability: The network is designed to support 100,000+ transactions per second with sub-second finality, meeting the demands of global payment systems. Infrastructure-Grade Reliability: Tempo prioritizes uptime, fault tolerance, and consistency to meet the standards required by banks, fintech platforms, and global payment processors. EVM Compatibility: Tempo is fully EVM-compatible and built on Reth, preserving compatibility with existing Ethereum tooling while tuning execution for payment-centric workloads rather than generalized smart-contract computation. Tempo enables a broad range of real-world, stablecoin-driven use cases, including: Global Payouts Remittance Embedded Finance Tokenized deposits with 24/7 continuous settlement Microtransactions Agentic payments Scroll down to the ‘Use Cases’ section to learn more Tempo delivers a blockchain architecture capable of supporting global financial flows with the performance, predictability, and reliability required for real-world adoption. Tempo blockchain payments-first architecture Tempo is a blockchain designed specifically for stablecoin payments, built with the Reth SDK. Its architecture focuses on high throughput, predictable low cost, deterministic finality, and operational reliability, properties required by financial institutions, payment service providers, and fintech platforms. Tempo is fully EVM-compatible, preserving Ethereum tooling while extending the protocol with payments-first primitives. Tempo transactions Tempo extends the transaction layer to natively support modern payment workflows. Tempo introduces a payments-first typed transaction based on EIP-2718, purpose-built for real-world payment workflows and available exclusively on Tempo. By enshrining features commonly grouped under account abstraction natively into the protocol, Tempo eliminates the need for custom smart contracts or third-party middleware, reducing integration risk and operational overhead for payment applications. Tempo Transactions natively supports: Batch execution: Thousands of payments can be executed atomically in a single transaction, ensuring that large payout runs either fully succeed or fully revert, which is critical for payroll, merchant settlements, and refunds. Fee sponsorship: Transactions can be signed by a user while fees are paid by a sponsor, with gas denominated in USD stablecoins infrastructure, removing the need for users to hold volatile gas assets. Scheduled execution: Transactions can specify a valid execution window, enabling recurring payments and subscriptions without off-chain automation. Modern authentication: Native WebAuthn / P256 passkey support allows biometric authentication backed by secure enclaves, eliminating seed phrase management while preserving cryptographic security. By embedding these features into the transaction format, Tempo simplifies wallet design and improves UX for both consumer and enterprise payment flows. https://twitter.com/tempo/status/2001337959291982031 Native stablecoins infrastructure Tempo is designed around the economic constraints of stablecoin payments. Stablecoin-Native Gas: Transaction fees are paid directly in USD-backed stablecoins. Users are not required to hold volatile assets (e.g., ETH) to move stablecoins, eliminating a major operational friction present on most blockchains. Predictable, Low Fee Structure: Tempo targets a consistently low fee level, approximately $0.001 (0.1 cents) per transaction, that remains stable regardless of transaction volume. TIP-20 Token Standard: Tempo defines an enshrined stablecoin token standard optimized for payments, reconciliation, and accounting workflows. { "name": "MyToken", "symbol": "MTK", "decimals": 18, "chainId": 42429, "address": "0x...", "logoURI": "<https://esm.sh/gh/tempoxyz/tempo-apps/apps/tokenlist/data/42429/icons/><address>.svg", "extensions": { "chain": "tempo" } } Built-In Stable Asset DEX: A protocol-level decentralized exchange optimized for stablecoins and tokenized deposits enables: Paying fees in any supported USD stablecoin infrastructure Validators receiving fees in their preferred USD stablecoin Automatic conversion between stable assets using onchain liquidity All validators are listed on Tempo Explorer: Fee volatility that may be tolerable for speculative trading is unacceptable for payments infrastructure. From the user perspective, this results in “dollars in” being equivalent to “digital dollars out,” without managing separate token inventories for fees simplifying cross-stablecoin payments and routing. Fast Finality Tempo is built on the Commonware Library, a modular blockchain infrastructure stack. Tempo is a core contributor to Commonware and is leading a $25M strategic investment to advance high-performance, reliable infrastructure for payment systems. Modular primitives: Commonware provides P2P, Networking, Consensus, Execution, Storage, Runtime, and Mempool primitives that can be modified or upgraded while live, enabling continuous improvement without disrupting payment flows on Tempo. Simplex Consensus: Tempo uses Simplex, a Byzantine fault-tolerant protocol producing blocks every ~600ms, with a distributed validator set to prevent single points of censorship. Minimmit targets block times of roughly 300ms while strengthening guarantees around block finality, aiming to optimize both speed and safety rather than trading one off for the other. https://twitter.com/VitalikButerin/status/1993439679081857433 Dedicated payment lanes: Tempo routes payment transactions through a dedicated payments lane at the protocol level, ensuring they do not compete with unrelated activity such as NFT mints, liquidations, or high-frequency DeFi calls. This guarantees that payment transactions always have available blockspace, even during periods of high network congestion, with no action required from the user. Separate gas limits enforced by validators: Reliable payment execution is enforced through distinct gas constraints during block construction. Validators apply a global gas_limit, representing the total gas available per block, alongside a general_gas_limit, which caps the maximum gas that non-payment transactions can consume. Non-payment transactions in the proposer’s lane are limited to general_gas_limit, while payment transactions can consume the remaining capacity up to the total gas_limit. This design eliminates congestion-driven downtime and supports predictable, high-volume payment flows for payment processors. By building on Commonware, Tempo can focus on payment-specific execution, blockspace guarantees, and stablecoin-native economics while pursuing sub-250ms finality on a globally distributed, permissionless validator network. EVM compatibility Tempo is built on a high-performance, modular EVM execution layer powered by the Reth SDK. Built with the Reth SDK: Tempo leverages Reth’s modular architecture to tune execution for payment-heavy workloads rather than generalized smart-contract computation. Full EVM Compatibility: Existing Ethereum tooling, contracts, and developer workflows remain usable, reducing integration friction for payment applications. Tempo privacy Tempo is developing opt-in privacy features that preserve the compliance and auditability required by regulated stablecoin issuers. Rather than making privacy an all-or-nothing property, the design enables confidentiality for balances and transfers while allowing authorized parties to retain the visibility needed for reporting, monitoring, and policy enforcement. This is achieved through a native private token standard designed specifically for stablecoins. Unlike traditional blockchains where all transaction data is publicly exposed, Tempo’s approach supports private balances and confidential transfers while enabling selective disclosure. Issuers and regulators can access required information without forcing sensitive financial data to be broadcast on a public ledger. Private balances: Account balances are hidden from public view while remaining auditable by authorized parties Confidential transfers: Transaction amounts and participants can be shielded from the public ledger Selective disclosure: Issuers and regulators retain visibility for compliance without exposing sensitive data publicly Tempo use cases Tempo is built for stablecoin-driven financial workflows where reliability, latency, and fee predictability matter more than generalized smart-contract flexibility. Stablecoins are already being used in production by global platforms, fintech, and institutions. Global Payouts Managing payroll and payouts across borders is notoriously complex. Traditional transfers are slow, expensive, and prone to errors due to intermediary banks, currency conversion, and local banking rules. Tempo simplifies this by enabling direct stablecoin payments that settle in seconds, with predictable, low fees and minimal operational overhead. By moving value onchain, companies can bypass slow correspondent networks. For example, a $1,000 cross-border payout that might cost $10–$40 in wire fees and take several days now completes almost instantly with just 0.1–0.4% in fees, giving recipients full dollar value without exposure to FX volatility. Funds can be distributed globally from a central wallet or via subsidiaries in seconds, removing the need for pre-funded local accounts. DoorDash: Seamless contractor and driver payouts worldwide Shopify: Fast, predictable merchant settlements across multiple countries Klarna: Immediate merchant settlements using KlarnaUSD to optimize cash flow https://twitter.com/Klarna/status/1993303819715854549 Mastercard: Testing stablecoin settlement rails alongside traditional card infrastructure Global employers: Efficient payroll and contractor payments across regions without banking friction Remittance Tempo enables near-instant stablecoin payments at minimal cost, while reducing operational complexity for providers. Funds settle onchain in seconds, with predictable fees and full transparency, eliminating FX exposure and reliance on pre-funded liquidity. Stablecoins enable practical remittance flows: Direct Transfers: Sender onramps to stablecoins and sends funds directly to the recipient’s wallet. Recipients can hold, spend, or off-ramp to local currency. Orchestrated Payments: Transfers pass through a stablecoin orchestration layer, automatically converting funds into the recipient’s local currency while maintaining speed and low cost. Backend Settlement: Providers move liquidity between their own entities across borders, removing the need for correspondent banks or pre-funded accounts. Embedded Finance Tempo enables platforms and marketplaces to integrate stablecoin wallets directly into their products, delivering instant partner payouts, low-cost consumer payments, and programmable financial experiences. Funds settle onchain in seconds, removing delays, regional banking limitations, and high card interchange fees. Stablecoins unlock key embedded finance flows: Partner & Creator Payouts: Platforms pay collaborators instantly, globally, and with minimal fees. Consumer Payment Acceptance: Marketplaces can collect stablecoin payments with low cost and immediate settlement. Loyalty & Rewards Programs: Funds can be distributed or spent directly within embedded wallets for flexible, on-demand rewards. Mercury: Embedded stablecoin balances for startups, enabling fast transfers and programmable payouts Lead Bank: Infrastructure for platforms and SaaS companies to manage internal stablecoin flows Kalshi: Real-time settlement for platform transactions and high-frequency operations Tokenized Deposits for 24/7 Settlement Tokenized deposits and stablecoins let companies manage global funds on a single onchain infrastructure while retaining regulatory compliance. Instant intercompany transfers: Move funds between parent and subsidiary accounts without relying on slow regional banking rails. Real-time cash visibility: Onchain balances give treasuries an up-to-the-minute view of global liquidity. Programmable workflows: Approvals, sweeps, and compliance processes can be automated via smart contracts. Tokenized deposits complement stablecoins rather than replace them. Deposits are bank-issued and regulated, while stablecoins are reserve-backed and optimized for frictionless, cross-chain payments. Together, they provide treasuries with speed, visibility, and efficiency that traditional banking cannot match. Deutsche Bank & Standard Chartered: Using tokenized deposits for corporate liquidity and cross-border settlement. UBS: Real-time intercompany transfers and treasury operations. Microtransactions Digital services are increasingly moving toward usage-based models, where users pay only for what they consume. High-frequency, low-value payments require extremely low fees and predictable execution to be viable. Tempo’s payments-first design makes microtransactions practical at internet scale. Kalshi: Real-time settlement for millions of small, rapid-fire financial transactions Digital platforms: Usage-based billing for APIs and online services Consumer apps: High-volume, low-value transfers without congestion risk Agentic Payments As software and AI systems increasingly act autonomously, payment infrastructure must support programmatic and non-interactive execution. Agents can hold and spend stablecoins globally in real time, with programmable wallets enabling automatic top-ups, spending limits, and policy enforcement. Onchain settlement removes intermediaries, simplifies liquidity management, and ensures agents always have the funds they need. OpenAI: Autonomous agents initiating, scheduling, and managing payments programmatically AI platforms: Machine-driven treasury operations and recurring payment execution Automated services: Machine-to-machine payments for software-native workflows Conclusion Stablecoins are no longer an experimental crypto use case. They are quickly becoming a core financial primitive for payments, settlement, payroll, remittances, and treasury operations. As stablecoin infrastructure matures and stablecoin payments transition to real economic activity, the requirements placed on blockchain architecture change fundamentally. On a payments-first chain like Tempo, low latency is non-negotiable: Latency is user experience Finality is operational certainty An unavailable RPC endpoint is a system failure. To operate at scale, Tempo-based applications require RPC infrastructure that delivers predictable latency, consistent reads, and high availability under sustained load. Chainstack provides production-grade Tempo RPC connectivity, enabling developers to submit transactions reliably, read state consistently, and scale payment systems without unexpected failures or rate limits. Getting started with Tempo on Chainstack takes minutes. Follow the step-by-step guide on how to get a Tempo RPC endpoint, deploy a reliable Tempo node through the Chainstack Console, and connect your application to low-latency infrastructure designed for real-world stablecoin payments. Start building on Tempo #### Tendex on Chainstack: Blockchain trading infrastructure for institutional digital asset management Tendex is a Swiss-based asset manager that specializes in investment products and trading infrastructure for the digital asset space. Their team is composed of engineers and mathematicians, with the goal to provide the best possible products and services for those working in or looking to invest in the digital asset world. What does tendex do? Tendex is a digital asset hedge fund that specializes in market-neutral strategies. As a hedge fund, the project focuses on the creation of highly competitive investment products which are built on its modern and secure trading infrastructure. This trading infrastructure is at the core of tendex’s business. The events-based trade application and proprietary order management system, they develop, allows clients to trade with confidence. Tendex’s system is designed to handle large order sizes and provides its clients with the best possible execution. Additionally, tendex has developed a complete set of tools, including advanced back-testing sets, and software for active strategy and portfolio management. With tendex’s flagship product trading for over two years now, it has managed to double the number of assets under its management. How did tendex come across Chainstack? Tendex was looking for a robust infrastructure provider that could power its events-based trade application. This would allow them to successfully deploy their quantitative fund offering and leverage it to amplify their competitive edge in profiting from the inefficiencies within the digital asset market space. To do that they needed a reliable node API. Without its features, or by using a service not adhering to their performance requirements, tendex’s products would fall short of delivering the results their customers and investors are looking for. They simply could not afford interruptions to their service due to lag or dropped requests. Tendex sent out a request for assistance and the Chainstack team was quick to respond by delivering a comprehensive view of what they could take advantage of. After a brief chat to go over the basics, tendex moved forward using Chainstack’s services. How does the Chainstack offer match tendex needs? Above anything else, tendex needed a reliable infrastructure that it could deploy at will. At the same time, this infrastructure needed to provide private archive node functionality to handle sensitive data, as well as retrospective analysis, to perform tests against historical real-world scenarios. Being able to leverage these features would prove essential for the effective delivery of tendex’s services. These also needed to adhere to their budget, allowing them to pay for performance and thus be able to scale efficiently, as the needs of the projects grew with them. Chainstack’s offer was a perfect fit for all tendex’s requirements. By signing up for our service, they were able to receive a robust infrastructure, supporting both private archive nodes and retrospective analysis frameworks. They were able to leverage these powerful functionalities with an attractive cost model excluding any imposed additional services, or overpayments. Outcome Following our discussion, Chainstack provided tendex with the reliable infrastructure setup they were looking for. By taking advantage of the Chainstack private and shared archive node functionalities the tendex team effectively gained access to the comprehensive data sets such service entailed. This allowed them to perform adequate testing of their core services against real-world scenarios, which is an essential part of delivering a seamless mainnet experience for their users. Additionally, the tendex team also had an opportunity to stress-test the environment, at times requesting as many as 5 000 000 requests to Chainstack a day, across multiple contracts without any issues, or interruptions to the service. Upon completion, these tests provided tendex with tangible insights they could use to improve their offering and scale up their product’s performance moving forward. What does tendex like about Chainstack? To be successful in trading decentralized finance products and provide the best possible returns for our investors, we needed to have a reliable partner next to us. Chainstack is a notable example of a node provider that includes reliability, functionality, and cost-effectiveness. James Kilroe, Director, tendex What does Chainstack like about tendex? Tendex offers an innovative and professional approach to digital asset management, which is a welcome sight in the landscape. Having such options available will certainly bring additional institutional adoption because of the high trustworthiness rating it brings with it. Eugene Aseev, CTO, Chainstack What is the most interesting engineering challenge in working together? As mentioned previously, one of tendex’s core needs was being able to utilize the archive node’s functionalities to perform back-testing against historical real-world data. These data sets can be particularly large, which proved to be an interesting challenge for the Chainstack team. By leveraging the robust infrastructure Chainstack offered, we worked together with the tendex team in delivering these datasets, so they can perform the tests they sought. We worked together with tendex to customize the node settings in maximizing the throughput capacity of our nodes to make it all possible. This allowed the tendex team to receive the priceless datasets on time and most importantly on budget, allowing them to complete the essential testing procedures of their core services. With the tests completed successfully, tendex was able to move forward with their project plans, resting assured that they had a reliable infrastructure provider to support their efforts. Power-boost your project on Chainstack #### Terabytes in minutes: Launch Ethereum archive nodes on Chainstack at just $49/month The ability to deploy a Geth Ethereum archive node in minutes is the latest addition to Chainstack’s managed blockchain services.  What is an Ethereum archive node?  Ethereum archive nodes store the full history of the blockchain for the Ethereum mainnet. They work just like a full node but also store an archive of all historical states since the start of the network. At the time of writing, that sits close to 3.75 Terabytes of data (and growing).  With a full node, you are limited to querying the last 128 blocks to see the balance of an address and the state of a smart contract at a point in time. Furthermore, with the latest Muir Glacier hard fork, the average block time was reduced by ~25% to about 13 seconds per block. This means that full nodes, which make up most nodes on the network, are only able to query data for the last 1,664 seconds, or ~27 minutes.  Convenience at a cost  So, with an archive node you can query any block for an address balance or a smart contract state to see what they looked like at a specific point in time. This is a clear necessity for anyone hoping to provide any sort of complete analysis of the Ethereum mainnet. However, having this option to access any historical state typically comes at a high cost. Not only in the ever-increasing storage requirements, but also in time. It takes weeks to sync an Ethereum archive node and requires constant maintenance of a machine that’s consuming terabytes of storage. Even Vitalik Buterin himself  isn’t running an archive node.  A guide in how to beat cost and time  There are a lot of things you can hack through in life today. Cheating time is rarely one of them. But as of today on Chainstack, you can deploy a fully synced, dedicated Ethereum archive node in minutes. Normally this process can take months—it took about three for our first node—and is a massive deterrent for anyone who has considered taking up the task.  This substantial efficiency gain is made possible by our patent-pending fast synchronization technology called Bolt. At Chainstack, we designed Bolt to maintain up-to-date snapshots of the ledger so that you can benefit from deploying Ethereum nodes in a fraction of the time.  Additionally, Chainstack’s shared nodes create an instant, private gateway for you to read and write to an archive node. You don't have to deploy a dedicated node yourself or worry about the increasing storage concerns. These gateways provide you with unlimited access to an archive node just for $49/month—substantially lower cost than existing solutions.   Try it today  Both shared and dedicated Ethereum archive nodes are available today on Business or Enterprise subscription tiers.  Try it out today. You can sign up for a starter 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. #### Test your knowledge: Corda Chainstack stopped supporting Corda nodes. Contact our support team at support@chainstack.com if you have any questions, or visit our Help Center. Are you CordaCon ready? Would you like to test your knowledge before the biggest Corda event of the year, or widen your understanding of one of the most popular enterprise blockchains? Then this is exactly what you are looking for! If you wish to challenge yourself on your existing understanding of how Corda works, then dive right into the quiz with no peeking through the answers beforehand. Score yourself, come back to the rest of the blog to check on your answers and deepen your knowledge thanks to the additional resources that we have curated for you. Are you instead looking for a great way to help you brush up on the understanding of Corda, and learn new things to build on your existing knowledge base? Then start by reading through the answers carefully, follow the additional resources we have included for each question, and take the quiz at the end to check how far you've gone in your learning session. The best part? Take the quiz and pass with a score of 80% or above, and we will send you a certificate of completion that will show to the entire R3 ecosystem that you are indeed CordaCon ready. Ready to take the quiz? Let's go! The Knowledge Team here at Chainstack is committed to contributing to the blockchain community with high quality resources and opportunity for training. We hope you will enjoy this piece, and join us for more—including bootcamps and online seminars. Happy learning! When you are ready to view the quiz with the correct answers, the explanations and the additional resources, just expand the section below. [expand title="Show me the answers"] 1. How is information shared between nodes in Corda?  It is up to you how to use this learning material, but we can suggest two ways: [X] Peer-to-peer [ ] Through the notary service [ ] Through the network map service Explanation: The correct answer is peer-to-peer. Nodes communicate and share information point-to-point. The notary service protects the network from double-spends and timestamps the transactions. The network map service is basically a catalogue of nodes on the network. Read more at Corda docs: Network. 2. Any new node can join a Corda network if the majority of the existing nodes on the network accept the new node. [ ] True [X] False Explanation: A Corda network is permissioned. Each Corda network is run by a network operator. The network operator admits new nodes to the network. Read more at Corda docs: Admission to network. 3. How do nodes discover other nodes on a Corda network? [ ] By using Kademlia-like table [X] Through the network map [ ] By establishing communication channels with each other Explanation: The correct answer is the network map service. The network map service is basically a maintained catalogue of nodes on a Corda network. Read more at Corda docs: The network map. The Kademlia-like table is how Ethereum works; and communication channels is how Hyperledger Fabric works. 4. Each node on the Corda network keeps the exact same ledger copy. [ ] True [X] False Explanation: Each node on a Corda network only keeps the data extracted from the ledger relevant to the node. Read more at Corda docs: Ledger. 5. CorDapps can be written in the following languages: [ ] Java & JavaScript [X] Java & Kotlin [ ] JavaScript & Go Explanation: Corda—mainly targeting enterprises and finance organizations—focuses on Java & Kotlin. Corda nodes are also JVM instances. 6. Communication between Corda nodes is encrypted. [X] True [ ] False Explanation: All nodes communication on a Corda network is always TLS encrypted. Read more at Corda blog: Corda Enterprise Kubernetes Deployment. 7. A Corda node is an instance of a Java Virtual Machine. [X] True [ ] False Explanation: Embedding the Java Virtual Machine specification was one of the crucial design decisions for Corda to attract developers and to use existing toolchains. Read more on JVM at Corda docs: Deterministic JVM. 8. What is a state in Corda? [X] A fact known by one or more parties [ ] A state of the network with all the transactions at a point in time [ ] The state of finality of the ledger Explanation: A state is an on-ledger fact relevant to the node that stores the state in its vault. Read more at Corda docs: States. 9. What is a vault in Corda? [X] A table of values extracted from the ledger and relevant to the node [ ] A secure key storage [ ] A storage for file attachments (e.g. PDF invoices) Explanation: A vault is the data that is relevant to the node, extracted from the ledger, and stored as a table that can be queried. Read more at Corda docs: Vault. 10. Once deployed, a contract on a Corda network is accessible by all network participants. [ ] True [X] False Explanation: Unlike on public blockchain networks (e.g. Ethereum), a contract on Corda must be hosted only on selected nodes that have to interact with each other within this specific contract rules and confines. Read more at Corda docs: Contracts. 11. Once deployed, contracts are upgradeable on a Corda network. [X] True [ ] False Explanation: It’s pretty much a prerequisite for any enterprise blockchain platform or protocol to have upgradeable contracts. Read more at Corda docs: Upgrading contracts. 12. An oracle on a Corda network must see the entire contents of a transaction to sign it. [ ] True [X] False Explanation: Confidentiality is a must for an enterprise blockchain platform or protocol. Oracles on a Corda network only need to see the contents that relate to the oracle service, not the full transaction details. Read more at Corda docs: Transaction tear-offs. 13. A Corda network can have several notary clusters with different consensus algorithms. [X] True [ ] False Explanation: Any Corda network can have different notary clusters set up, each of the clusters can have a different consensus algorithm. Read more at Cord docs: Notaries. 14. A typical CorDapp consists of the following components: [X] Contract, State, Flow [ ] Contract, Ledger, Flow [ ] Contract, Transaction schema, Party definition Explanation: Think of a CorDapp as an app that has enforceable rules (contract), objects to work with (state), and a logic to follow (flow). Read more at Corda docs: What is a CorDapp? 15. The number of nodes that can be a part of a transaction is limited for performance reasons to: [ ] 10 [ ] 100 [X] Not limited Explanation: Corda is scalable. There is no limit to how many nodes should be a part of a transaction. On top of that, there’s additional scalability possibilities that’s good to be familiar with in the form of Corda Accounts. Read more at Corda blog: Unlocking New Opportunities with Accounts on Corda. 16. A transaction on a Corda network can be broadcast to all network participants. [ ] True [X] False Explanation: Node communication on a Corda network is always point-to-point and encrypted. Read more at Corda docs: Point-to-point vs. global broadcasts. 17. If a transaction between nodes must include a PDF invoice, the PDF will: [ ] Be sent as an attachment in the transaction [X] Be uploaded to a node and referenced in the transaction by the hash of the PDF file [ ] Be included in the network map service as a catalogued object and referenced by the transaction Explanation: Transactions only use the hash of an attachment that is uploaded on a node and can be downloaded from the node. Read more at Corda docs: Using attachments. 18. What does an oracle service do on a Corda network? [X] Provide data external to the network into a transaction and signs the transaction [ ] Establish multiple datapoints for the network that the nodes votes on [ ] Provide external cross-chain services Explanation: Oracles provide external data and put their signature on the transaction using the external data they provided. Oracles provide determinism to the network. Read more at Corda docs: Oracles. 19. A notary on a Corda network has to authorize every single transaction. [ ] True [X] False Explanation: A notary protects the network from double-spends and timestamps the transactions. When there is no input state for a transaction or a time-window in which the transaction has to be executed, there is no requirement for a notary to notarize a transaction. Read more at Corda docs: Notaries. 20. Transaction validation always includes walking back the entire chain and verifying it by the participating nodes. [ ] True [X] False Explanation: Notaries validate transactions based on the consumed and unconsumed states. Read more at Corda docs: Validation. [/expand] Connect with the community Chainstack is a sponsor of CordaCon 2020. Read more about how we are supporting the R3 ecosystem this year. 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! 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. #### The agentic payments landscape The moment payments met agents Payment infrastructure was built for humans clicking checkout buttons. That model breaks when AI agents start transacting autonomously. Traditional processors require authorization patterns that assume manual confirmation. Credit card networks expect predictable fraud profiles. Settlement systems tolerate multi-day clearing because humans accept the delay. None of this works when software makes purchasing decisions at machine speed. Three protocols emerged in 2025 with different approaches to solving this problem. Beyond authorization, the critical question is settlement infrastructure. Which blockchain networks will actually process these transactions determines whether agent commerce consolidates around shared standards or fragments across competing platforms. TL;DR Three protocols have emerged with different approaches: ACP (OpenAI/Stripe) works within existing payment rails and shipped with ChatGPT, AP2 (Google) is a platform-agnostic trust layer with 60+ partners but no live product, and x402 (Coinbase) is the only protocol with meaningful volume at 500K weekly transactions. Two ecosystems are forming. OpenAI/Stripe pair ACP with Tempo for vertical integration. Google/Coinbase built a broader coalition around AP2/x402 with multi-chain support across Base, BNB Chain, and Solana. Settlement infrastructure is contested between purpose-built chains (Tempo, GCUL) still in private testnet and established networks (Base, Ethereum, Solana) offering working solutions today. The market remains fragmented without interoperability standards. Whether infrastructure consolidates or splits into specialized implementations will be determined by transaction volume in 2026, not partnership announcements. The protocol layer Agentic Commerce Protocol (ACP) When OpenAI and Stripe unveiled ACP in September 2025, they made a pragmatic bet that agent commerce needed to work with existing payment infrastructure, not replace it. The protocol shipped alongside Instant Checkout in ChatGPT, giving users a working implementation from day one. ACP builds on established payment rails rather than creating new ones. Merchants keep their current payment processors, agents access a new channel without merchants rebuilding checkout flows, and traditional payment methods like cards and digital wallets continue working as they do today. The innovation sits in Shared Payment Tokens, which let users delegate payment credentials to AI agents without exposing raw card data. End-to-end data flow of the Agentic Commerce Protocol (OpenAI) The merchant-first approach means businesses maintain direct customer relationships throughout the purchase. No intermediary platform sits between buyer and seller. While the protocol specifications are open source under Apache 2.0, the production implementation currently runs exclusively through Stripe's infrastructure. Agent Payments Protocol (AP2) Google took the opposite approach. Rather than optimize for speed to market, AP2 attempts to solve the trust and verification problem that emerges when autonomous agents start spending money. The protocol launched in September 2025 with 60+ partners, including Mastercard, PayPal, American Express, Coinbase, and Salesforce, but no working product. AP2 treats agent payments as fundamentally different from human payments. When people check out, their presence serves as authorization. When agents act autonomously, that authorization needs to be cryptographically provable. The protocol introduces three mandate types to handle this. Cart Mandates work like traditional checkouts, where users approve specific items. Intent Mandates pre-authorize future purchases within defined parameters, such as spending limits or product categories. Payment Mandates compress this authorization data into credentials that flow through existing payment networks without requiring infrastructure changes. The architecture separates responsibilities across roles. Credential providers handle sensitive payment data. Agents execute shopping tasks. Merchants process orders. Issuers authorize based on mandate context. Everything uses W3C Verifiable Credentials for tamper resistance. On paper, it's comprehensive. In practice, it's untested. No consumer can use AP2 yet despite its impressive partner roster. x402 Coinbase released x402 four months before either ACP or AP2 appeared. The protocol revives HTTP status code 402, originally reserved for "Payment Required" but never implemented. Instead of building complex authorization flows, x402 makes payment a native HTTP operation. The mechanics are deliberately simple. Request a paid resource, receive a 402 response with payment terms, send payment, get the resource. All payments settle in stablecoins on blockchain networks. Facilitators handle the onchain complexity so neither merchants nor buyers need to run nodes or manage wallets directly.       x402 protocol flow (Coinbase) By October 2025, x402 processed 500,000 weekly transactions across Base, Solana, and BNB Chain. The protocol works standalone for pure crypto commerce and extends AP2 for projects that want Google's trust layer with onchain settlement. It's currently the only protocol with meaningful transaction volume. Complementary or competing? Two camps are forming around different architectural choices, each with distinct trade-offs for implementation. ACPAP2x402FunctionEnd-to-end commerce flowTrust/verification layerStablecoin “transport”Backed byOpenAI, StripeGoogle, Mastercard, PayPal, Amex, Coinbase, Salesforce (60+ partners)CoinbasePayment typesTraditional rails + stablecoin-readyAll types (cards, banks, crypto)Crypto-nativeIntegrationRequires StripeWorks with any processorRequires facilitator Whether these protocols interoperate or fragment the ecosystem remains unclear. An agent could theoretically use ACP for fiat transactions and x402 for crypto payments, or AP2 mandates could verify purchases across both systems. Without defined interoperability standards, merchants may need to implement multiple protocols depending on which agents and payment methods they want to support. The blockchain infrastructure layer Protocols define how agents authorize payments. Blockchains determine where those payments actually settle. The infrastructure layer has become a battleground between purpose-built chains designed specifically for payments and existing networks adapting to capture agent commerce. Tempo (Stripe + Paradigm) Tempo represents the cleanest expression of payments-first architecture. Rather than adapt existing infrastructure, Stripe and Paradigm are building a Layer 1 blockchain optimized entirely for settlement. The chain raised $500M at a $5B valuation in October 2025 and is currently in private testnet with design partners including OpenAI, Anthropic, Shopify, Visa, and Deutsche Bank. The architecture targets 100,000+ TPS, but throughput matters less than payment-specific optimization. General-purpose chains tolerate variable gas fees and probabilistic finality because DeFi users accept these trade-offs. Payments require predictable costs and instant settlement, which demands different architectural choices from the consensus layer up. Google Cloud Universal Ledger (GCUL) GCUL takes the opposite approach by positioning itself as a credibly neutral infrastructure. Rather than optimize for specific use cases, Google built an institutional L1 that uses Python smart contracts instead of Solidity. The platform is currently in private testnet with CME Group and targets a 2026 launch. GCUL eliminates these reconciliation processes by providing a shared ledger where all parties verify transactions directly. The atomic settlement capability particularly targets capital markets, where multi-day settlement cycles require working capital and complex collateral management. Google frames GCUL as infrastructure not tied to specific tokens or vendors, which addresses institutional hesitancy to build on platforms controlled by potential competitors. Base and existing infrastructure Base offers a third path by leveraging existing Ethereum infrastructure rather than building new chains. As Coinbase’s Layer 2, it operates on the Optimism OP Stack and serves as the default settlement layer for the protocol. This gives developers a working solution today rather than waiting for purpose-built infrastructure to launch.The pragmatic appeal is clear. Base inherits Ethereum's security model and existing stablecoin liquidity while offering lower costs and faster finality than L1. For developers building on Coinbase's stack, it's the path of least resistance with native wallet integration and familiar tooling. The trade-off is accepting infrastructure designed for general-purpose smart contracts rather than purpose-built payment optimization. Other settlement layers No single chain will capture all agent payment settlements. Multiple networks are positioning themselves for different slices of the market: Solana has incorporated x402 support and optimizes for high-frequency microtransactions where sub-second finality matters. BNB Chain introduced x402 BNB in October 2025, a unified protocol layer that enables single-signature, sign-to-pay transactions and agent governance. The implementation leverages EIP-7702 delegated execution and EIP-712 witness signatures to automate token transfers, gas sponsorship, and policy enforcement in one operation for seamless and gasless payments. Ethereum remains highly relevant, holding roughly 50% of all stablecoin value in circulation despite not being specifically optimized for payments. Circle's Arc and Tether's Plasma represent stablecoin issuers building their own payment-focused chains, betting on controlling their settlement infrastructure rather than relying on external platforms. The question of which chains will dominate agent commerce settlement remains open. Purpose-built infrastructure like Tempo may offer better performance, but existing chains like Base and Ethereum provide working solutions today with established liquidity. The answer likely depends on whether payment optimization matters enough to justify migrating from existing infrastructure, or whether general-purpose chains can adapt quickly enough to close the gap. Current state of adoption The market is forming around different strategies without clear dominance. OpenAI and Stripe's ACP collaboration appears vertically integrated, but the protocol is open-source under Apache 2.0 and implementable by other processors. ACP aims to be a universal abstraction layer for agent commerce. The competing vision combining AP2, x402, and GCUL remains more conceptual than formalized. Tighter integration enables faster shipping while broader participation distributes risk. Chains are positioning for settlement without winners. Base serves Coinbase developers with a working infrastructure. Solana targets high-frequency microtransactions. Tempo and GCUL promise payment optimization but remain in private testing. Developers face fragmentation without established standards. Three questions will determine outcomes: whether interoperability emerges or fragmentation persists, whether purpose-built chains justify migration from Base, Ethereum, and Solana, and whether x402 bridges ecosystems or adds incompatibility. Transaction volume will answer these questions more definitively than announcements. Conclusion The infrastructure layer for autonomous commerce materialized in months, not years. Whether payments settle through ACP on Tempo or x402 across multiple chains matters less than the capability itself now existing. The technical primitives for agent-initiated transactions are functional, even if fragmented. 2026 will clarify whether this infrastructure converges around shared standards or splits into specialized implementations for different transaction types. The pragmatic play is maintaining optionality across protocols and chains until actual usage patterns emerge. What looked like competing visions may prove complementary once transaction volumes reach a meaningful scale across protocols. Whether you are testing agent payment flows on Base, deploying microtransaction workloads on Solana, or running stablecoin transport layers across Ethereum and BNB Chain, Chainstack gives you the performance and consistency required for production systems. Deploy RPC endpoints in seconds and scale globally with automated orchestration, uptime guarantees, and developer-friendly tooling. #### The Brownie Python tutorial series—Part 2 The journey so far  Alright, you are about to read Part 2 of the Brownie tutorial series: Part 1 – Introduction. Part 2 – Scripts, tests, and testnets. <– You are here. Part 3 – Brownie deep dive.Part 4 – Move forward with Brownie.  So far, in our journey to master the Brownie framework, we learned how to: Install the Brownie package and all its dependencies.Set up a Brownie project.Compile contracts using Brownie. Deploy and interact with the contracts using the Brownie console. In this article, we will see how to work with Python scripts, and we will also learn how to use actual Ethereum testnets for contract deployment and testing.  Learning the scripts  In Brownie, scripts enable automation. They help encapsulate all the necessary contract deployment, interaction and testing commands into a single (or multiple, your choice!) neat Python file that frees us from the incessant typing of commands. Once we create our scripts, we can use the brownie run command to automatically execute them. In this tutorial, we will see how to create two different kinds of scripts: The interaction script — For contract deployment and interaction.The testing script — For contract testing. So, let's get to it.  A script to deploy  Note: This article will be expanding upon our previous project (the one we created in Part 1), so if you are new, I request you to check out the previous article and set up a basic project (it will only take a few minutes!).  In Brownie, the contract deployment and interaction scripts are stored inside the /scripts directory of the project. To create a new script,  Go to the /scripts directory Create a new Python file, deploy_interact.py (or <any_other_name>.py)  Now, as with the Brownie console, we need access to the contract ABI (Application Binary Interface), bytecode and an Ethereum account address to deploy our contract. In the console, we used the contractContainer object of our contract (BasicContract, remember) and the Brownie accounts object for deploying our contract. We can essentially do the same thing in our script, so do the following: Open the new file in a code editor.Add the following import statement. from brownie import BasicContract , accounts Using the above statement, we are enabling access to the contractContainer object of our contract (which has the same name as the contract) and the Brownie accounts object.  Now, for the deployment part, create a main function in your script and add the following code: def main(): # Fetch the account account = accounts[0] # Deploy contract deploy_contract = BasicContract.deploy({"from":account}) # Print contract address print(f"contract deployed at {deploy_contract}") Here, just like with the console, we are: Accessing one of the accounts (provided by Ganache CLI) using the accounts object.Calling the deploy function of the contractContainer object Passing the account as a parameter to the deploy function.Returning the ProjectContract of the contract to the deploy_contract variable. To run the script, open a terminal in your project folder and type: brownie run deploy_interact.py #or <any_other_name>.py The command will do the following: Compile all the new/modified contracts. Spin up a local blockchain using Ganache CLI.Execute the script.Deploy the contract onto the local network. Once the script is executed, you will see the following output: Launching 'ganache-cli --accounts 10 --hardfork istanbul --gasLimit 12000000 --mnemonic brownie --port 8545'... Running 'scripts/deploy_interact.py::main'... Transaction sent: 0x94011b7fa3c7fedd25b589adfbd4588ba5f5df9785709ef184192376157d2f8f Gas price: 0.0 gwei Gas limit: 12000000 Nonce: 0 BasicContract.constructor confirmed Block: 1 Gas used: 90551 (0.75%) BasicContract deployed at: 0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87 contract deployed at 0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87 Note: Remember that each time we use the brownie run command, Ganache is spinning up a new temporary network. Once the execution ends, the network along with all its data gets taken down. Yes, that includes the deployed contract also. (Do not worry, we will discuss persistent networks, later in the article). OK, now that we took care of the deployment part, we can work on the contract interaction.   There are two ways in which we can interact with the functions in our contract, we can either call them or send transactions.  You use the call methodology to interact with the functions that do not cause any state changes (like the view functions). These interactions are free of cost and the call method executes the code without broadcasting a transaction to the network. The send method, on the other hand, is used for invoking functions that alter the state of the chain. They cost you gas, and they generate transactions that are broadcasted throughout the network.  In our basicContract, we have,  The storeNumber function — stores a number onto the chain (and alters its state).The readNumber function — reads the stored number from the chain. Let's see how we can interact with each of these functions. We will start with storeNumber(): # Store a number  transaction_receipt = deploy_contract.storeNumber(15, {"from":account})  # Wait for transaction confirmation  transaction_receipt.wait(1) #you can change this number Here, we are invoking the storeNumber method using the deploy_contract variable (which stores the ProjectContract object) and since the function alters the state of the chain, we need to pass the account address responsible for the transaction. The function will return a TransactionReceipt object, and in the code, we are using the wait function of the receipt object to wait for transaction confirmation. The number (1) means that we will wait for a single new block to be mined before we confirm the transaction finality. To read the data, we can use any of the following codes: retrieved_number = deploy_contract.readNumber.call() #or retrieved_number = deploy_contract.readNumber() In the first statement, we are explicitly using the call method to invoke the readNumber function and in the second statement, Brownie will detect that the function is a non-state-altering function and hence it will automatically make “calls” to the function. You can use any of these statements for “calling” a function.  Alright, once you add the whole contract interaction codes to your script, it should look something like this: from brownie import accounts, BasicContract def main(): # fetch the account account = accounts[0] # deploy contract deploy_contract = BasicContract.deploy({"from":account}) # print contract address print(f"contract deployed at {deploy_contract}") # store a number transaction_receipt = deploy_contract.storeNumber(15,{"from":account}) # wait for transaction confirmation transaction_receipt.wait(1) # retrieve the number retrieved_number = deploy_contract.readNumber() # print the retrieved number print(f"Number Retrieved : {retrieved_number}") You can run the entire script using the brownie run command, and it will do the following: Deploy your contract.Store a number to the chain.Retrieve and display the stored number. $ brownie run deploy_interact.py BasicProject is the active project. Launching 'ganache-cli --accounts 10 --hardfork istanbul --gasLimit 12000000 --mnemonic brownie --port 8545'... Running 'scripts/deploy_interact.py::main'... Transaction sent: 0x7b5c26796992b52d3e22378ec0c484be90741a4539fa35b1d4623d20e84d3930 Gas price: 0.0 gwei Gas limit: 12000000 Nonce: 0 BasicContract.constructor confirmed Block: 1 Gas used: 119208 (0.99%) BasicContract deployed at: 0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87 contract deployed at 0x3194cBDC3dbcd3E11a07892e7bA5c3394048Cc87 Transaction sent: 0x9dda4a967fa7fcd1ea2cb64d9b01258ae22b4b955ea7dc916a201609da7f0b92 Gas price: 0.0 gwei Gas limit: 12000000 Nonce: 1 BasicContract.storeNumber confirmed Block: 2 Gas used: 41394 (0.34%) BasicContract.storeNumber confirmed Block: 2 Gas used: 41394 (0.34%) Number Retrieved : 15 And with that, we have deployed and interacted with our contract using a Python script.  Now let’s do some unit testing.  A fair bit of testing  As mentioned in the previous article, Brownie uses the pytest framework for unit testing. This means that we can leverage the features of this tried and tested framework and write simple yet powerful test cases for our contract.  To create our testing script: Open the /tests directory in your project.Create a new Python file, test_contract.py. Note: The name of your test scripts should either begin with a “test_” or end with a “_test”. Add the following “test cases” to the file: from brownie import BasicContract, accounts def test_default_value(): # fetch the account account = accounts[0] # deploy contract deploy_contract = BasicContract.deploy({"from":account}) #retrieve default number retrieved_number = deploy_contract.readNumber() expected_result = 0 assert retrieved_number == expected_result def test_stored_value(): # fetch the account account = accounts[0] # deploy contract deploy_contract = BasicContract.deploy({"from":account}) # store a number transaction_receipt = deploy_contract.storeNumber(1,{"from":account}) transaction_receipt.wait(1) #retrieve number retrieved_number = deploy_contract.readNumber() expected_result = 1 assert retrieved_number == expected_result Note: While writing the test case functions, make sure you add the word “test” at the beginning of the function name. While running the tests, Brownie will ignore the functions that do not have the “test” prefix.  Here, we have two simple test cases for our contract, the first one (test_default_value) checks for proper contract deployment (by trying to retrieve the default value) and the second one (test_stored_value) makes sure that our storeNumber function is working properly. In both these cases, we use the assert keyword to verify the outcomes of our contract functions.  To run the tests: Open a terminal in your project directory and type: brownie test Brownie will automatically detect and execute our test cases.  ============================= test session starts ========================== platform linux -- Python 3.6.9, pytest-6.2.5, py-1.10.0, pluggy-1.0.0 rootdir: /home/sethuraman/Documents/Workspace/Chainstack/Blog-Snippets/brownie-tutorial-series/Part-1/basic-project plugins: eth-brownie-1.16.4, hypothesis-6.21.6, forked-1.3.0, web3-5.29.2, xdist-1.34.0 collected 2 items Launching 'ganache-cli --accounts 10 --hardfork istanbul --gasLimit 12000000 --mnemonic brownie --port 8545'... tests/test_contract.py .. [100%] ============================== 2 passed in 2.92s ============================ The output indicates that both our tests were successful, and our contract is good to go.  To run a specific test case, use: $ brownie test -k "<test-case-name>"  # In our case use test_default_value* or test_stored_value This is how we test our contracts using Python scripts. Now, let’s go a bit further and see if we could do all the same stuff atop an actual Ethereum testnet.  Using testnets  This section is all about moving away from the default Ganache CLI network and using some real testnets. The Ganache CLI has been quite handy and provides an easy way to deploy and test our contract, but it is all but a simulation of a blockchain network and not the real deal. To truly test the functionalities of our contract, we must put it up against an actual test network. Also, the whole “temporary” nature of the default Ganache network does prevent us from trying out some cool stuff with our contracts (more on that later), so without further ado, let us deploy our contracts onto an actual Ethereum testnet.  Brownie offers you a ton of pre-configured network options that you can use in order to deploy and test your contract. You can view all these options by using the following command: brownie networks list  The command will display a long list of networks: Ethereum ├─Mainnet (Infura): mainnet ├─Ropsten (Infura): ropsten ├─Rinkeby (Infura): rinkeby ├─Goerli (Infura): goerli └─Kovan (Infura): kovan Ethereum Classic ├─Mainnet: etc └─Kotti: kotti Arbitrum └─Mainnet: arbitrum-main Avalanche ├─Mainnet: avax-main └─Testnet: avax-test Aurora ├─Mainnet: aurora-main └─Testnet: aurora-test Binance Smart Chain ├─Testnet: bsc-test └─Mainnet: bsc-main Fantom Opera ├─Testnet: ftm-test └─Mainnet: ftm-main Harmony └─Mainnet (Shard 0): harmony-main Moonbeam └─Mainnet: moonbeam-main Optimistic Ethereum ├─Mainnet: optimism-main └─Kovan: optimism-test Polygon ├─Mainnet (Infura): polygon-main └─Mumbai Testnet (Infura): polygon-test XDai ├─Mainnet: xdai-main └─Testnet: xdai-test Development ├─Ganache-CLI: development ├─Geth Dev: geth-dev ├─Hardhat: hardhat ├─Hardhat (Mainnet Fork): hardhat-fork ├─Ganache-CLI (BSC-Mainnet Fork): bsc-main-fork ├─Ganache-CLI (FTM-Mainnet Fork): ftm-main-fork ├─Ganache-CLI (Polygon-Mainnet Fork): polygon-main-fork ├─Ganache-CLI (XDai-Mainnet Fork): xdai-main-fork ├─Ganache-CLI (Avax-Mainnet Fork): avax-main-fork └─Ganache-CLI (Aurora-Mainnet Fork): aurora-mai The networks mentioned under the “Development” label are local, temporary networks and the other ones in the list are essentially live, non-local, persistent Ethereum or EVM-based networks (both main and testnets). To use any of these networks, we simply add the —network flag and the network identifier (the one after the colon symbol) along with the brownie run command. brownie run deploy_interact.py  --network <network-identifier> You can do the same with the test command: brownie test --network <network-identifier> Note: Actually, to use any of the live networks (and some of the fork networks), Brownie needs to connect to a node (remote or otherwise) that is part of that particular network. Unless we explicitly add the details of the nodes, Brownie won't be able to connect to any of these networks. Fret not! We will discuss this in just a bit. Now, in order to deal with the live networks (the ”non-development” ones) in the list, you need to make certain arrangements. From proper accounts to (test) token balances, we need to make sure that we have all these things before we get to play with the OG networks. To set up a proper, valid account, we can actually use our trusted MetaMask wallet. Once we set up a MetaMask account, we can use the account private key and some slick Brownie commands in order to add the account into the fold of our Brownie accounts object. To try it out: Create an account using MetaMask.Copy the private key of the account.Use the following command to add a new account: brownie accounts new my-new-account  Here, my-new-account is the unique id for referring to the new account. You can give your own id for the account. When we execute this command, Brownie will ask us to enter the private key of the account and also prompt us for a password for encrypting the account details. Once you generate the new account, you can view it using the following command: brownie accounts list  This will display all the local (ones that are stored in the system) accounts that we can access: Brownie v1.16.4 - Python development framework for Ethereum Found 2 accounts: ├─SampleAccount: 0x23d1B3E3dE8235e8b15EdD030E2D69959eE88835 └─my-new-account: 0xc4f02d6b1bE3804Dc8c4fDD6c2A890DbAFf60c62 To use this account in our deployment and testing scripts, all you have to do is to change the account retrieval statement in our script from: account = accounts[0]  to: account = accounts.load("my-new-account") # use your own account id  Now when we run the scripts, we will be using the newly added accounts.  Note: Yes, you can use the newly added accounts with both the development networks and live ones. While using them, Brownie will ask us to enter the encryption password, each time we execute the scripts. OK, now that the account is ready, let’s use a real testnet.  As mentioned before, most of the listed networks in Brownie work by connecting to a node that is part of the given network and Brownie does come with a set of predefined node configurations. But Brownie is cool. It allows us to configure and use our own nodes for contract deployment and testing. To set up our own 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 Goerli node.  Once you have the node up and running, get the node endpoint (HTTPS).  Now, we can use the brownie networks add command to add the new node configuration onto Brownie. The command uses the following arguments: environment — the label of the network, i.e. whether it is “Ethereum”, “Ethereum Classic”, or “Development” id — a unique identifier for the network. Note: We can also provide a separate name for our network using the "name" parameter. If we don't provide a name, Brownie will automatically assign the id as the network name. host — the node endpoint.chainid — the chain identifier. By using all these parameters, you can add a new node configuration to Brownie: brownie networks add Ethereum goerli-chainstack host=<chainstack-node-endpoint> chainid=5  Here, we are adding a new Goerli node under the Ethereum label with the id goerli-chainstack. The chainid for the Goerli test network is 5. Note: If you are using a different testnet, you can find the corresponding chain IDs here.  Now when you use the brownie networks list command, we can the new configuration under the Ethereum label.  Ethereum ├─Mainnet (Infura): mainnet ├─Ropsten (Infura): ropsten ├─Rinkeby (Infura): rinkeby ├─Goerli (Infura): goerli ├─Kovan (Infura): kovan ├─ganache-local: ganache-local └─goerli-chainstack: goerli-chainstack Ethereum Classic ├─Mainnet: etc └─Kotti: kotti Arbitrum └─Mainnet: arbitrum-main Avalanche ├─Mainnet: avax-main └─Testnet: avax-test Aurora ├─Mainnet: aurora-main └─Testnet: aurora-test Binance Smart Chain ├─Testnet: bsc-test └─Mainnet: bsc-main Fantom Opera ├─Testnet: ftm-test └─Mainnet: ftm-main Harmony └─Mainnet (Shard 0): harmony-main Moonbeam └─Mainnet: moonbeam-main Optimistic Ethereum ├─Mainnet: optimism-main └─Kovan: optimism-test Polygon ├─Mainnet (Infura): polygon-main └─Mumbai Testnet (Infura): polygon-test XDai ├─Mainnet: xdai-main └─Testnet: xdai-test Development ├─Ganache-CLI: development ├─Geth Dev: geth-dev ├─Hardhat: hardhat ├─Hardhat (Mainnet Fork): hardhat-fork ├─Ganache-CLI (BSC-Mainnet Fork): bsc-main-fork ├─Ganache-CLI (FTM-Mainnet Fork): ftm-main-fork ├─Ganache-CLI (Polygon-Mainnet Fork): polygon-main-fork ├─Ganache-CLI (XDai-Mainnet Fork): xdai-main-fork ├─Ganache-CLI (Avax-Mainnet Fork): avax-main-fork └─Ganache-CLI (Aurora-Mainnet Fork): aurora-mai To use the new network node, all we have to do is to give the network id as a parameter to our run/test commands. Note: Since we are using real testnets, we need actual test tokens to deploy and test our contracts. So, before you run the scripts make sure you have a sufficient token balance in your account. You can get test tokens for your account using the various faucets available online.  #For running the deploy_interact script  $ brownie run deploy_interact.py --network goerli-chainstack    #For testing the contract  $ brownie test --network goerli-chainstack  With that, you have successfully used an actual Ethereum testnet for contract deployment and testing. Note: You can find all of our scripts in this repository : Brownie tutorial—Part 2. The usage of persistent networks allows us to further extend our deployment and testing capabilities. Using such networks, we get to mimic production-level scenarios and fine-tune our contract to make it more powerful and efficient. In the coming articles, we will see how we can leverage the full potential of these networks and build bigger and better smart contracts. Wrap up  From script creation to account generation and testnet usage, we have covered a lot of ground in this tutorial. All these are essentially the basic functionalities of Brownie, you can tinker around with them and further explore Brownie.  In the next article, we will be expanding upon the testnet functionalities and we will see how we can add custom configurations for our project. We will also check out yet another cool Brownie feature called "the Brownie mix". #### The Brownie tutorial series—Part 3  Welcome to part 3 of the Brownie tutorial series  Part 1 – Introduction. Part 2 – Scripts, tests, and testnets. Part 3 – Brownie deep dive. <– You are here. Part 4 – Move forward with Brownie.  By now, we have mastered the art of: Deploying and interacting with smart contracts using Python scripts.Writing testing scripts for your contract.Using actual testnets for development. In this article, we will push the envelope further and learn some advanced features of Brownie that will let you work with persistent data, enable detailed configuration of your projects and help you “bake” a complete Brownie project, so let’s get to it.  More on testnets  Note: This article will be expanding upon the previous article, so if you are new, I request you to check out part 1 and part 2 of the series.  By the end of the previous article, we had our smart contract running atop an actual Ethereum testnet. By doing so, we are no longer limited by non-persistent networks and all its shortcomings, i.e, we no longer have to redeploy our contracts, every state change that we make is permanent and we can have complete records of our transactions. Once we deploy the contract onto a “persistent” network, Brownie stores the deployment details (artifacts) inside the /build /deployments directory. Brownie sorts the details based on the chain ID of the networks that we use for deploying our contracts.  # Path to deployment artifacts build/deployments/[CHAINID]/[CONTRACT_ADDRESS].json Brownie also stores a list of all the deployed contract addresses using a JSON file (map.json), which is also stored inside the /build/deployments directory. One of the major advantages of storing all this information is that it allows us to access the same (deployed) contract instance across multiple files. This means that instead of cramming the code for contract deployment and interaction into one single Python file, we can create separate files that deal with these different functionalities and run them independently, all the while, making them access the same contract instance. To try it out, go inside our /scripts folder and create two new files: deploy.py and interact.py. Note: The given scripts extend the codebase of the previous article. So, make sure you have that codebase in your system. Inside the deploy.py file, add the following code: from Brownie import BasicContract , accounts def main(): # Fetch already stored account account = accounts.load('my-new-account') # deploy contract deploy_contract = BasicContract.deploy({"from":account}) # print contract address print(f"contract deployed at {deploy_contract}") As you can see, this code exclusively deals with contract deployment. You can run this code by opening a terminal in the project root folder and typing: $ Brownie run deploy.py --network goerli-chainstack This will deploy the contract onto the Goerli testnet using your Chainstack node (yes, the one that we set up in the previous article). Once deployed, you can check the /deployments folder (and the map.json file) to see all information regarding the deployment.  Now, in our interact.py file add the following code: from Brownie import BasicContract, accounts def main(): # Accessing the latest deployment instance contract_instance = BasicContract[-1] # loading the stored account account = accounts.load("my-new-account") # storing a number transaction_receipt = contract_instance.storeNumber(15, {"from": account}) # Wait for transaction confirmation print(transaction_receipt) # Retrieve the number retrieved_number = contract_instance.readNumber() # Print the retrieved number print(f"Number Retrieved: {retrieved_number}") Here, we have the code for interacting with the contract. As you can see, we are using the BasicContract object to access the projectContract object of the contract that we recently deployed.   contract_instance = BasicContract[-1]  The persistence of the projectContract object is only available while using actual persistent testnets. In the above code, we are storing the projectContract object inside the contract_instance variable and we are using it to interact with the contract. If you have deployed multiple instances of the contract, you can access each of them separately by adjusting the index ([-1]).  The separation of contract deployment and interactions comes in handy when we are dealing with bigger contracts with tons of functions. If need be, we can create specific files for handling the various functions themselves and since we can make all these files access the same instance of the contract, it will give us a much-needed structure for the project.  To run the contract interaction code, open a terminal and type: $ Brownie run interact.py --network goerli-chainstack This will generate the same results as our “crammed up” (deploy_interact.py) file, minus the deployment part.  Now that we can split and keep the different functionalities of our contract in separate files, the next step in ironing out our development process comes with the removal of the redundant stuff. For example, remember how we keep on specifying the networks while running our scripts or how we must use a long list of commands to add a new key to our accounts, well, Brownie lets us remove all these redundancies by allowing us to “configure” them. Let us put this feature to the test and see how we can configure certain things in our project.  A file to configure Brownie allows users to define custom configurations for their projects using the Brownie configuration file. It is a YAML file that must always be saved under the name ‘brownie-config.yaml’. Users can define everything from the default network to the compiler version and even add custom information like file location, etc. inside the file. Once you create the configuration file, you can save it to the root directory of your project and Brownie will automatically load the configurations when you run the project.  To set up a configuration file for your project: Head over to the project root directory.Create a new YAML file, brownie-config.yaml. Inside the YAML file, add the following lines  networks: default: goerli-chainstack Here, we are configuring the default network that we should be using while deploying and testing our contracts. Once you save the file, you can deploy the contract using the brownie run command and you need not specify the network while doing so: $ brownie run deploy.py Since we have configured our default network, Brownie will automatically deploy the contract onto that particular network.   Another cool thing about the configuration file is that we can access the configuration details from within our python scripts. In Brownie, we use the config object to access data from the configuration file. To test it out, let us try to add some custom data like our MetaMask account private key and try to fetch it from our deploy.py script, using the config object. Now, while dealing with sensitive information like our account's private key, stating it directly in your code is not recommended. The best way to do it (in a development scenario) would be to declare it as an environment variable and to access that variable from within our configuration file: Create a .env file in the root directory of your project.Add the following lines to your .env file. export ACCOUNT_PRIVATE_KEY = 0x<YOUR-ACCOUNT-PRIVATE_KEY> Note: While adding the private key, make sure to put a ‘0x’ in front of the key  Now, we can add the details of the .env file inside our configuration file and Brownie will automatically load the environment variables, when we run the project. To do all this, add these lines to your YAML file:  dotenv: .env Brownie also allows us to use POSIX-style variable expansion to access our environment variables, meaning, I can access the environment variables from within my configuration file using the given lines (don’t forget to add these lines to your YAML file): account-keys: private-key: ${ACCOUNT_PRIVATE_KEY} Here, I have created a custom YAML collection, Account-keys, and inside that I have provided a key, labeled private-key and the value of this key is refereeing to the environment variable that we defined, using a POSIX-style expression ${ACCOUNT_PRIVATE_KEY}. Note: You can provide any configuration values (default network, compiler version, etc.) as an environment variable and access it using POSIX-style expressions, from inside the configuration file.  Now, to fetch the private key value from inside our script, open deploy.py and import the config object: from Brownie import BasicContract , accounts, config Now, replace the following line: account = accounts.load(“my-new-account”)  With this: account = accounts.add(config [" account-keys "] [" private-key"])  This line will fetch the private key value from our configuration file, and it will be used as the account key. This is how you can use the config object to access different configuration details from within the script.   Note: Here's the complete codebase for reference: Brownie tutorial—part 3. Know that all the fields in the Brownie configuration file are optional and while building a project, you need only configure what is necessary. The full extent of the configuration file allows you to define a lot of things like the gas limits for various networks, contract dependencies, data reports, etc.  Note: You can refer to the Brownie offical doc to learn more about the various configuration settings.  All right, with the help of the brownie-config file, we can configure certain aspects of the project and reduce redundancies in various tasks. Now, if you have become a fan of such low-redundancy workflow, Brownie has a lot more in store for you, chief of which is a way to generate entire projects (templates) that you can modify and build upon! So, without wasting many sentences, let's understand one of the coolest Brownie features.  Baking some code using Brownie mixes  Ok, now this is arguably the piece de resistance when it comes to Brownie features, and it is called the Brownie mixes. Brownie mixes are a collection of premade project templates that you can use as a starting point for your applications. The template will include some basic contracts, scripts, testing files and even a configuration file pertaining to the project. Using these templates, we can build complex things like DAOs or NFT applications. The code base for each of these templates is kept in the Brownie mixes GitHub repository. In order to generate any of these templates, we can use the Brownie bake command.  To get a taste of the Brownie mixes, let's try and use a project template. For this tutorial, we will be trying to set up a basic ERC20 token project and for that, we will be using the token-mix. To set up the project: Create a new directory.Open a terminal in the directory and type: $ brownie bakes token-mix This will generate a barebone Brownie project for creating ERC-20 tokens. If you go through the project structure, it will contain everything from smart contracts, scripts, test files and even a configuration file: ├── brownie-config.yaml ├── build │   ├── contracts │   ├── deployments │   └── interfaces ├── contracts │   ├── SafeMath.sol │   └── Token.sol ├── interfaces ├── LICENSE ├── README.md ├── reports ├── requirements.txt ├── scripts │   └── token.py └── tests ├── conftest.py ├── test_approve.py ├── test_transferFrom.py └── test_transfer.py Now, even though it is just a template, this project does come with some pre-defined code for defining and generating a token. You can check it out by running   $ brownie run token.py And with that, we generated a basic ERC-20 project without writing even a single line of code.  Wrapping up  This article was all about learning how we can extend some of the features of Brownie and tinkering with some new ones. By levering the potential of persistent networks, we saw how we structure our project better and introduce modularity to our code. We also saw the level of detailing that we can provide in a brownie project using some rich configuration options and finally, we saw how we can generate a complete Brownie project (though basic) without having to write a single line of code.  In the next part of the article, we will expand open our ERC-20 project and see how we can add a nice little user interface to it.  #### The Brownie tutorial series—Part 4 Welcome, you are about to enter the last leg of the Brownie development journey.   Part 1 – Introduction.   Part 2 – Scripts, tests, and testnets.   Part 3 – Brownie deep dive.  Part 4 – Move forward with Brownie. <- you are here  The series aimed to introduce you to this robust development framework and help you understand all its features so that you can build complex web3 applications relatively quickly. In the last article of the series, we will discuss some additional features of Brownie that will help you better analyze your smart contract, handle external packages and help you quickly set up a React-based front-end for your project.  Looking under the hood of a smart contract  The true mastery of any subject depends on the number of "whys" you can answer. This is especially true when it comes to programming. Anybody can write and run code, but it takes a master to understand why a particular piece of code will/won't work once you run it, and with smart contract contracts, you are not dealing with any random code; you are dealing with a code that will be stored in an immutable fashion across multiple machines and one that takes a considerable amount of effort to change or update. This means that you can never be too careful when it comes to testing and analyzing your smart contracts. Brownie knows this, and that is why Brownie comes with a GUI tool that helps you easily investigate your code.   The Brownie GUI  The Brownie GUI is a minimal interface tool built using the Python Tkinter package. It provides deeper coverage of your smart contracts. You see, a smart contract, when compiled, produces a corresponding machine-level code, i.e., the bytecode, that eventually gets stored in the ledger. The GUI tool helps you analyze the code on a bytecode level.   Note: The Tkinter package usually comes preinstalled with Python. If you are facing any issues with the package, you can always refer to the Tkinter official doc. To run the GUI tool, open a terminal in your project root folder and type:  brownie gui The command will: Detect all the available contracts  Compile the contracts  Create the build materials  Load the GUI  Note: You can run the Brownie GUI on any of our previous codebases. Using the GUI, you can select the contract that you want to analyze, and it will display the Solidity contract along with the corresponding bytecode, side-by-side. To get the opcode related to a particular section of code, you must select that portion of the code, and the tool will automatically highlight the corresponding opcode.   The scope option on the top left corner helps you focus on the bytecode of a selected portion of the code.  To fully utilize the tool, you need some familiarity with the opcode side of things. Still, once you get used to it, this tool can help you better analyze, optimize and even safeguard your code against any vulnerabilities, both logical and otherwise.  Importing a project  One of the most tempting things for any developer is another developer's code. There are times when we see a project, and we immediately think of ways to integrate it into what we are doing (with proper credits, of course). Brownie understands this urge and provides ways to import external smart contract projects onto our codebase as packages so that we can reuse the given code. To enable this, Brownie introduced the Brownie package manager. The package manager allows users to import projects from both GitHub and the Ethereum package registry (ethPM) and use them as packages within their projects.  While importing a project onto Brownie, the project doesn't need to use the same Brownie framework; when it comes to GitHub-based imports, the user has to make sure that the given Git repository has a directory called /contracts that stores the smart contract code, and that the repository has multiple tagged versions. If the code repository meets both these criteria, then the Brownie package manager will import the code, regardless of the framework that it uses.  Note: Popular code repositories like the ones by Openzepplin and Chainlink meet all the criteria, meaning that we can import their contracts onto our code using the Brownie package manager.  To install a git repository as a package, you should identify the repository using the organization's name, the repository's version, and the code's version: <ORGANISATION_NAME>/<REPOSITORY_NAME@<VERSION>  For example, if you want to use uniswap contracts in your project, open a terminal and type the following command: brownie pm install Uniswap/v2-core@1.0.1  This will automatically download the code, compile the contract and generate the build data.  Note: The compiled contracts and the build artifacts of the external projects won't be stored inside your current project. Instead, they will be stored inside the root Brownie folder, under the /packages directory (~/.brownie/packages - for Linux)  You can view the list of all the deployed contracts using the following command: brownie pm list  To use one of the imported codes in your contract, add the following statement at the very top of your contract: import “<ORGANISATION_NAME>/<REPOSITORY_NAME@<VERSION>/<PATH-TO_CONTRACT_FILE>”  The path to the contract file will be the same as how it was arranged in the git repository. i.e., In the uniswap-v2 core repository, to import the "UniswapV2ERC20.sol" contract, we would use the following import statement: import “Uniswap/v2-core@1.0.1/contracts/ UniswapV2ERC20.sol  Adding a front-end  Alright, we are at the end, the front-end, to be exact. The front-end of any application is what abstracts away all the messy code under the hood and presents the users with a delightful interface so they can easily interact with all the messy stuff. One of the most brutal truths about application development is that normal users don't care much about what's running under the hood. They want a seamless experience that helps them get what they want with minimal clicks and navigational efforts, meaning a good front-end matter.  When building a good front-end application, you can take endless routes; I mean, the whole process is only limited by the developer's creativity. But, thus, it creates a new problem, where does one start?  Brownie solves this problem by including a React-based application template along with Brownie-mix. This template comes with sample contracts and React code that helps you get started with your front-end application.  To use this "mix," you can use the Brownie bake command, so open a terminal and type: brownie bake react-mix  The command will create a new react directory that has a similar structure as that of a regular Brownie project, plus it will also include the code for the React front-end (inside the /client Folder)  The template includes a sample value storage contract in both Solidity and Vyper languages. Just like our regular Brownie project, the project configurations can be found in the "brownie-config.yaml" file. Inside the configuration file, you will see that a .env file has been defined by default. The file presumably stores the user's account private key using the PRIVATE_KEY variable.   So, before you try and run the project, make sure you create a .env file in the root directory of your project and store your account's private key: PRIVATE_KEY = 0x<ACCOUNT_PRIVATE_KEY>  Instead of sticking with the default configurations, you can refer to our previous article and use other networks for contract deployment.  Note: In the wake of the merge, many major testnets like Ropsten, Rinkeby, Kovan (defined in the default config file), etc., have been deprecated. So, it is probably a good idea to refer to our previous article and use networks like the Goerli for contract deployment.  While using a new network, you should modify the network section of your config.yaml accordingly. Here are the changes required for including the details of the Goerli test network that we added to Brownie in our previous article: networks: default: chainstack-goerli development: cmd_settings: mnemonic: brownie default_balance: 100000000000000000000 unlock: <ACCOUNT ADDRESS HERE> # (requires explicit transfer of eth to accounts[-1]) update_interval: 60 verify: False chainstack-goerli: verify: False update_interval: 60 Now, since we added a new network for deployment, we should also update our deploy.py script (/scripts) to accommodate the changes: from brownie import SolidityStorage, VyperStorage, accounts, network,config def main(): # requires brownie account to have been created # checking for the active network if network.show_active()=='development': # add these accounts to metamask by importing private key owner = accounts[0] SolidityStorage.deploy({'from':accounts[0]}) # VyperStorage.deploy({'from':accounts[0]}) elif network.show_active() == 'kovan': # add these accounts to metamask by importing private key owner = accounts.load("main") SolidityStorage.deploy({'from':owner}) # VyperStorage.deploy({'from':owner}) elif network.show_active() == 'chainstack-goerli': owner = accounts.add(config["wallets"]["from_key"]) SolidityStorage.deploy({'from':owner}) # VyperStorage.deploy({'from':owner}) Once you update the deploy.py script, you can deploy the contract onto the Goerli testnet using the following command: brownie run deploy.py  Since we have set the default network as Goerli in the config.yaml file, Brownie will automatically deploy the contract to the network without us having to state the network explicitly.  OK, now that we have our contract in the network, let's try and spin up the front-end application.   To run the application, go to the /client directory and install all the dependencies: npm install  Once you install all the dependencies, you need to make specific changes to the App.js file within the /client/src directory before running the application.   The App.js file sits at the center of the React codebase, and since we deviated from the default and deployed our contract onto the Goerli testnet, we need to make specific changes to this file. Also, in our tutorial series, we almost entirely relied on Solidity for writing our smart contracts; this means we can remove any "Vyper" based code from the file.   Alright, with all said and done, your new App.js file should look like this:  import React, {Component} from "react" import './App.css' import {getWeb3} from "./getWeb3" import map from "./artifacts/deployments/map.json" import {getEthereum} from "./getEthereum" class App extends Component { state = { web3: null, accounts: null, chainid: null, solidityStorage: null, solidityValue: 0, solidityInput: 0, } componentDidMount = async () => { // Get network provider and web3 instance. const web3 = await getWeb3() // Try and enable accounts (connect metamask) try { const ethereum = await getEthereum() ethereum.enable() } catch (e) { console.log(`Could not enable accounts. Interaction with contracts not available. Use a modern browser with a Web3 plugin to fix this issue.`) console.log(e) } // Use web3 to get the user's accounts const accounts = await web3.eth.getAccounts() // set the current chain id const chainid = 5; this.setState({ web3, accounts, chainid }, await this.loadInitialContracts) } loadInitialContracts = async () => { console.log(this.state.chainid) var _chainID = 5; console.log(_chainID) const solidityStorage = await this.loadContract(_chainID,"SolidityStorage") if ( !solidityStorage) { return } const solidityValue = await solidityStorage.methods.get().call() this.setState({ solidityStorage, solidityValue, }) } loadContract = async (chain, contractName) => { // Load a deployed contract instance into a web3 contract object const {web3} = this.state // Get the address of the most recent deployment from the deployment map let address try { address = map[chain][contractName][0] } catch (e) { console.log(`Couldn't find any deployed contract "${contractName}" on the chain "${chain}".`) return undefined } // Load the artifact with the specified address let contractArtifact try { contractArtifact = await import(`./artifacts/deployments/${chain}/${address}.json`) } catch (e) { console.log(`Failed to load contract artifact "./artifacts/deployments/${chain}/${address}.json"`) return undefined } return new web3.eth.Contract(contractArtifact.abi, address) } changeSolidity = async (e) => { const {accounts, solidityStorage, solidityInput} = this.state e.preventDefault() const value = parseInt(solidityInput) if (isNaN(value)) { alert("invalid value") return } await solidityStorage.methods.set(value).send({from: accounts[0]}) .on('receipt', async () => { this.setState({ solidityValue: await solidityStorage.methods.get().call() }) }) } render() { const { web3, accounts, chainid, solidityStorage, solidityValue, solidityInput } = this.state if (!web3) { return <div>Loading Web3, accounts, and contracts...</div> } console.log(solidityStorage) if (!solidityStorage) { return <div>Could not find a deployed contract. Check console for details.</div> } const isAccountsUnlocked = accounts ? accounts.length > 0 : false return (<div className="App"> <h1>Your Brownie Mix is installed and ready.</h1> <p> If your contracts compiled and deployed successfully, you can see the current storage values below. </p> { !isAccountsUnlocked ? <p><strong>Connect with Metamask and refresh the page to be able to edit the storage fields.</strong> </p> : null } <h2>Solidity Storage Contract</h2> <div>The stored value is: {solidityValue}</div> <br/> <form onSubmit={(e) => this.changeSolidity(e)}> <div> <label>Change the value to: </label> <br/> <input name="solidityInput" type="text" value={solidityInput} onChange={(e) => this.setState({solidityInput: e.target.value})} /> <br/> <button type="submit" disabled={!isAccountsUnlocked}>Submit</button> </div> </form> </div>) } } export default App Now, you can start the application by opening a terminal inside the /client folder and using the following command: npm start  This will run the front-end application locally, and it will be running at http://localhost:3000.   Note: To interact with the contract deployed onto the Goerli test network, we will be using MetaMask, so make sure that you have the MetaMask wallet installed on your browser and that your account has some Goerli tokens in it. The application will automatically detect the deployed instance of the contract from the build artifacts (inside /client/src/artifacts) and connect to our MetaMask wallet from the browser to interact with the contract.  The default front-end that comes with the react-mix template is simple, but as mentioned above, the template is merely there to help you get started with the front-end application. Every aspect of the template is editable. Based on the complexity of your contracts and applications, users can improve upon the given code base and build more complex front-end applications.  Conclusion  Right, so this is the end of a journey spanning four articles. The idea behind the Brownie Tutorial Series was to give you an in-depth overview of this robust smart contract development framework and help you get started on the Brownie-based DApp building journey. Brownie comes with a set of easy-to-use and intuitive features that help with everything from smart contract creation to deployment, testing, and analysis. Learning Brownie not only enables you to build smart contracts faster but also helps you ensure the quality and safety of your contracts.  #### The Ethereum cloud vs. on-premises nodes conundrum Is there a way to actually identify how many Ethereum nodes are running in cloud and on-premises? There is, and it's easy enough. In this article, we are going to get the Ethereum mainnet node data and have a look at it. To check the results of analyzing the data right away, head right to the Results section. To understand the mechanics of the analysis, check the Cracking the data section. Before jumping to conclusions, however, read the introductory Seeing through the data section. Seeing through the data Data is impartial, but interpretation never is. Back in 2012, when the Winklevoss brothers started investing in Bitcoin and accumulated as much as 1% of the circulating supply, they had to take proper measures to store their wealth. What is proper, however, when the access to your wealth is in a private key? What they did was split the private key into three shards, print each shard on a piece of paper, and put it in a plastic envelope. Then they proceeded to put each of the envelopes in safety-deposit boxes of different banks. Not just different branches of the same bank, but different banks and in different locations. The Winklevoss brothers repeated the process four times across different geographic regions. And thus they had a secure and fault-tolerant system that had a high chance of withstanding even the real world cataclysms, let alone theft attempts. They didn't put the shards in chests and bury them in various places, they used the existing and time-proven system of bank safety boxes to their advantage and built their own secure and redundant system on top of that. The topic of decentralization is a complicated and multilateral one, and it's hair-splitting to some. There are good projects like DAppNode that offer on-premises boxes with Ethereum nodes, there are miners, there are many community members running their own nodes, there are projects like Infura that often get a disapproving look from the proponents of "true decentralization." And at the same time, pretty much anyone who has ever spent more than a few hours with Ethereum welcomes any news that says enterprise adoption. One of the major organizations even has the word in its name—Enterprise Ethereum Alliance. The more adoption, the better. The website ethereum.org has recently been redesigned from the ground up and populated with more documentation—all in an effort to be less alien and more welcoming to newcomers. An adoption effort. There's Vyper, a pythonic smart contract language, under development that is more auditable and human-readable than Solidity. Everything about Vyper says it should bring in more developers, who are otherwise reluctant to wet their toes in Solidity. DApps have user-friendly webapps to communicate with the contracts. There's MetaMask and there's Web3. There's Torus for frictionless DApp logins. The list is rich and can go on and on, but the main point is there's an incredible amount of effort in the Ethereum space to make it mainstream. And all of this effort is building on top of the existing technology. Just like the Winklevoss brothers did with their private key. The vast majority of businesses and enterprises are using cloud computing. It's easy, it saves the costs, it's something that's been proven by time. When faced with the decision of whether to hire a team to launch and maintain their own node or use a platform, they will go for the optimal choice—the one that saves costs. The cloud and the service to deploy a node. Anyone running a node in the cloud is certainly not a miner, but it's almost always a person or an entity interested in onboarding more users to Ethereum and putting their processes on blockchain—be it a DApp developer for end users or a B2B enterprise. Does this spell adoption? You'd be hard-pressed to say it doesn't. So, would knowing the actual numbers of cloud and on-premises Ethereum nodes give an insight? And is there a way at all to get the numbers? Yes, there is. And it's easy to do. All you need to do is to crawl the IP addresses of the currently running Ethereum nodes on the mainnet and match them against the autonomous system numbers (ASN) of their providers. Cloud hosting providers—just like any provider—have their own ASN, so it's easy to not only see who's on cloud, but also on what cloud. And we have done it for you. Read on for the methodology and the results. Cracking the data A short primer on the Ethereum discovery protocol  Having a brief understanding of the Ethereum discovery protocol is crucial to interpreting the data in this research. The Ethereum discovery protocol is the mechanism through which Ethereum nodes find each other and join the global peer-to-peer network. The protocol is based on Kademlia, and this is how the Ethereum peer-to-peer discovery works in brief: Each node keeps a table of other nodes on the network.  When you start a new node, the table has a few hardcoded bootstrap nodes. These bootstrap nodes are maintained by the Ethereum Foundation.  The bootstrap nodes keep a table of all nodes that connected to them in the past 24 hours.  Once the new node retrieves the node data from the bootstrap nodes, it connects to these newly discovered nodes and goes through the same discovery process with them. Data used for the research ethernodes.org — a third-party Ethereum network explorer. A maintained open-source list of autonomous system numbers (ASN) of cloud hosting providers. ethernodes.org The ethernodes.org service is a privately maintained Ethereum network explorer that was started in 2016 and has been operating since then. The service is running several Ethereum nodes to crawl the network using the Ethereum discovery protocol. The crawled data is processed to map the node IP addresses to their geographical locations. The processed data is then exposed to the ethernodes.org website. Autonomous system numbers (ASN) An autonomous system number is a globally unique number for an autonomous system. An autonomous system is a group of IP networks operated by an organization. The organization must have a clearly defined external routing policy to be registered as an autonomous system with a unique autonomous system number.  The autonomous system number is required for the routing requests from within an autonomous system to other autonomous systems. In short, whenever you send a request over the public Internet, it goes through your ISP's ASN.  All cloud hosting providers, managed hosting providers, and colocation facilities have a unique ASN. Any IP address can be mapped to an ASN. Mechanics Having identified the proper data sources for the research, the actual mechanics of crunching the numbers is trivial. 1. Get the Ethereum mainnet host data of all nodes You can get all the Ethereum mainnet data from ethernodes.org. 2. Deduplicate the IP addresses The list of Ethereum nodes at ethernodes.org fluctuates in the number of actual nodes it reports. On some days, the fluctuation may go as high as 25%.  The reason for the fluctuation is that there are duplicate IP addresses reported by the service. You need to remove the duplicates from the list to have the actual numbers. One way to do this is to extract the IP addresses from the data dump and then remove the duplicates. 3. Map the host IP addresses to ASNs Run the IP addresses through any paid or free service that maps the IP address to its originating ASN. 4. Compare your list of ASNs against the list of ASNs of cloud hosting providers You can use any tool you are comfortable with to compare the two lists—anything from Python to Microsoft Excel. Results The data used for the results is from the September 20, 2019 snapshot.  Total Ethereum nodes in cloud and on-prem: 8933 nodes Ethereum nodes running in the cloud: 61.6% (5499 nodes)  Ethereum nodes running fully on-premises: 38.4% (3434 nodes)  Top ten cloud hosting providers The top ten cloud hosting providers amount to a total of 57% Ethereum nodes. Top ten cloud hosting providers by country A total of 37% of all Ethereum nodes hosted in cloud run in the U.S. datacenters. Top 10 on-premises Ethereum node locations A total of 45% of all Ethereum nodes running on-premises are located in China. All of the data is on GitHub gists, so you can poke through it: Raw data with mapped ASNs Cloud and on-premises matched against ASNs Cloud and on-premises geos On-premises geos Explore 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. Have you already explored what you can achieve with Chainstack? Get started for free today. #### The Merge: You are all set with Chainstack Chainstack Ethereum Mainnet nodes will transition to The Merge state with zero downtime. As a Chainstack customer, you are all set and no action required from you.Key dates on The Merge: October 14, 2020 — the staking deposit contract deployed on Ethereum Mainnet. December 1, 2020 — Beacon Chain launched. June 8, 2022 — Ropsten Testnet merged. July 6, 2022 — Sepolia Testnet merged. August 10, 2022 — Goerli Testnet merged. September 15, 2022 — Ethereum Mainnet merged. If you want to better understand what The Merge is and how it will affect developers like you, keep reading because, by the end of this article, you will know everything you need for The Merge. Defining the Merge: Ethereum transition to proof-of-stake The Merge refers to the joining of the existing Ethereum chain, now called the Execution Layer, with its new Consensus Layer–the Beacon Chain. Ethereum Mainnet merged with Beacon Chain on September 15, 2022 and transitioned from Proof-of-Work to Proof-of-Stake. With the Merge, Ethereum eliminates the need for energy-intensive mining and secures the network with staked ETH, making it more scalable, sustainable, and secure. So, what does it mean for developers like you? Less than you would expect. In fact, The Merge has minimal impact on smart contract and DApp developers; but, there are still a few things worth noting. How The Merge impacts Ethereum’s application layer: proof-of-work vs. proof-of-stake Blocks restructuring After The Merge, proof-of-work blocks become part of the new proof-of-stake blocks created by the Beacon Chain. Think of the Beacon Chain as the new proof-of-stake consensus layer of Ethereum, superseding the proof-of-work consensus layer. Pro tip: Transactions are still processed by the same execution layer clients, such as Geth, Erigon, Besu, Nethermind and so on, so your API method calls won't change. Ommers production Unlike proof-of-work, proof-of-stake does not produce ommers–also known as uncle blocks–so several fields contained in proof-of-work block headers become irrelevant to proof-of-stake. To reduce disruption to tooling and infrastructure, the content of these fields is set to 0, or their data’s structure equivalent, instead of being entirely removed. Pro tip: The list of uncle blocks (ommers) is empty, the hash of this list (ommersHash) becomes an RLP-encoded hash of an empty list, and finally—difficulty and nonce is set to 0. Opcodes upgrading Additionally, The Merge also affects the BLOCKHASH and DIFFICULTY (0x44) opcodes. Post-merge, BLOCKHASH is forged by the proof-of-stake hashing process, so the pseudo-randomness provided by this opcode is weaker. The DIFFICULTY opcode (0x44) is renamed to PREVRANDAO, and is a stronger source of randomness than BLOCKHASH, returning the output of the randomness beacon given by the Beacon Chain. Block time reduction In addition, keep in mind The Merge changes the block time. Under proof-of-work, block time was on average ~13 seconds. Under proof-of-stake, blocks come in at fixed 12 seconds, unless a slot is missed by a validator that was too slow to submit a block or is temporarily offline. However, only 1% of slots are estimated to be missed. Pro tip: Block time is reduced by at least ~1 second. So, make sure your smart contracts take this time change into account for their calculations to prevent any errors. New block types introduction And last but not least, as you may know, blocks often reorged under proof-of-work, so applications typically had to for several blocks to be mined on top of a new head to treat it as confirmed. However, post-merge, this is no longer the case thanks to new and more reliable block types, namely safe head and finalized blocks. A safe head is a block that can never be orphaned, is less likely to be reorged, and is equal to the tip of the chain under normal network conditions—that is: the fork choice rule is respected, network delays are less than 4 seconds, the network is synchronous, and at least 50% of the stake is honest. A finalized block is a nearly attack-proof block that’s been accepted by at least ⅔ of validators, meaning an attacker would need to burn ⅓ of the total stake to create a conflicting block. Currently, the total stake is equivalent to ~$10 billion (2.5 million ETH), hence the security of a finalized block. Pro tip: Execution Layer APIs expose safe head and finalized blocks with tags, so you can easily recognize them by their safe or finalized tags. How do node operators go through The Merge? As a node operator, you had at least 3 obstacles to address for The Merge: Without Chainstack 👎🏻With Chainstack 🚀Firstly, you had to install, run, and manage both a consensus layer client and an execution layer client; otherwise, there would be downtime during The Merge.As a Chainstack customer, you do NOT have to do anything. We've taken care of all the infrastructure work for you.Secondly, you had to authenticate both clients with the new Engine API, which you will approve with a JWT secret that both clients share to ensure secure communication.We have run Ropsten, Goerli, and Mainnet through The Merge already, so keep operating your nodes as usual.Finally, if you are currently operating any nodes on Kiln, Ropsten, or Rinkeby Testnets, you need to migrate to Goerli or Sepolia as soon as possible to prevent downtime during The Merge.Expect Sepolia to be integrated soon. If you think this sounds a bit daunting, know you’re not alone. The majority of node operators usually rely on node providers like Chainstack instead of spending countless hours trying to figure out all the ins and outs of how to deploy, run, and manage a node by themselves, which makes sense considering this helps them waste less time on complicated infrastructure work and build more tech instead. Are you sure you understand what a NaaS–Node as a Service–provider is or why developers would use it? If you want to know more, we published an article on this topic, explaining what they are, how to get started, and why increasingly more developers are choosing to use them. Check it out: What will happen to Ethereum Testnets: Kiln, Ropsten, and Rinkeby to be shut down Being full-featured blockchains like the Mainnet, Testnets grow in history and state over time, meaning if you’re running nodes on them, maintenance becomes increasingly expensive and time-consuming. Because of this, client developers have decided to deprecate most testnets to maintain better the two that’ll remain post-merge: Goerli and Sepolia. In practice, Kiln, Ropsten, and Rinkeby are currently being deprecated, but you still have time to plan your migration before they are actually shut down.  Why only Goerli and Sepolia? Well, Goerli has a strong community and substantial infrastructure supporting it, but it’s also the most similar to Mainnet in terms of state, which is helpful if you need to test smart contract interactions. On the other hand, Sepolia is reasonably new, so its state and history are still relatively small. Because of this, the network is quick to sync, and running a node requires way less storage. During shutdown, stakers will stop validating transactions. We suggest you migrate to either Goerli or Sepolia as soon as possible to avoid getting stuck in a falling network. Testnets shutdown timeline The Merge is one of the most challenging steps ever for the Ethereum Foundation (EF), requiring extensive research, iterative improvements, and exhaustive testing. Because of this, dates and timelines can change rapidly. However, we are following the announcements of the EF very closely, and we’ll continue to update this page accordingly. In the meantime, here’s a brief overview of the shutdown timeline: TestnetAvailable on Chainstack?More detailsKiln❌Transitioned successfully to proof-of-stake in March 2022.Currently NOT available on Chainstack.Will be shut down by the EF soon after Mainnet runs through The Merge on August 19, 2022.Ropsten✅Transitioned successfully to proof-of-stake on June 8, 2022.Currently available on Chainstack under proof-of-stake.Will no longer be supported by Chainstack after shutdown in Q4 2022.Rinkeby✅Will not transition to proof-of-stake.Currently available on Chainstack under proof-of-work.Will no longer be supported by Chainstack after shutdown in Q3-Q4 2023.Goerli✅Transitioned to proof-of-stake on August 10, 2022.Currently available on Chainstack under proof-of-stake.Sepolia✅Transitioned successfully to proof-of-stake on July 6, 2022.Currently NOT available on Chainstack.Will be supported by Chainstack. Pro tip: If you want to boot a node faster, Sepolia is your best choice. If you need to test protocol upgrades before deploying to Mainnet, you should use Goerli instead. The 5 most common misconceptions about the Merge #1 You can withdraw staked ETH after The Merge. FALSE 🚫 You can NOT withdraw your staked ETH directly after The Merge. If you want to withdraw your staked ETH, you will need to wait for an additional upgrade coming a few months later. #2 The Merge will lower gas fees. FALSE 🚫 Currently capped at 15 transactions per second (TPS), Ethereum’s throughput will NOT increase post-merge. If you need higher TPS, you must use rollups or L2 protocols like StarkNet or Optimism. #3 The Merge reduces ETH issuance. TRUE ✅ Every block produces 90% less ETH after The Merge. #4 The Merge requires updates: KINDA 🤨 For users, NO.For node operators, YES, occasionally.However, most apps do NOT require updates. #5 You need 32 ETH to run a node: FALSE 🚫 You need 0 ETH (Ξ) to run a non-validator node, but if you want to run a validator node, you need to stake a minimum of 32 eth. Additionally, every 32 eth you stake will increase your chances of being chosen and rewarded by the network. Bringing it all together From the main changes impacting both Ethereum’s application and infrastructure layer (e.g., block time reduction, testnets deprecation) to the most common merge-misconceptions surfing the web, you now know everything you need to approach The Merge truly like a builder. Ultimately, we know all of this may still sound challenging to you, but know that, while Twitter and the Internet go wild making what’s actually going on ten times harder to understand, you can always come back to this step-by-step guide as many times as you need to really start to see the whole merge-picture; and worst comes to worst–or best perhaps–you can try our free developer plan. Finally, don’t forget to share this article with other developers who you think might find it helpful–do them a favor, they will thank you for it! Now… back to BUIDLing! FAQs What is The Merge? The Merge refers to the joining of the existing execution layer of Ethereum (Mainnet) with its new consensus layer (Beacon Chain). Is the Beacon Chain a separate blockchain? Yes. The Beacon Chain is a new proof-of-stake blockchain that serves as a ledger to conduct and coordinate the network of stakers of Ethereum. But, unlike Mainnet, it does not process transactions or handle smart contract interactions. What are the benefits of The Merge? With the Merge, Ethereum eliminates the need for energy-intensive mining and instead secures the network with staked ETH, making it more scalable, sustainable, and secure. When did The Merge happen? Ethereum Mainnet went through The Merge on September 15, 2022. What do I need to do with my DApp? You do NOT need to do anything, but make sure your the smart contracts of your DApp consider the block time change and the pseudorandomness method. Will Chainstack be supporting Ropsten? Chainstack will support Ropsten under proof-of-stake state until all validators are shut down in Q4 2022. However, you should no longer consider Ropsten a suitable testing environment. We encourage you to migrate to Goerli as soon as possible. Will Chainstack be supporting Kiln? Chainstack will NOT support Kiln. You should no longer consider Kiln a suitable testing environment. We encourage you to migrate to Goerli as soon as possible. Will Chainstack be supporting Rinkeby? Chainstack will support Rinkeby under proof-of-work state until all validators are shut down in Q3-Q4 2022. However, you should NOT consider Rinkeby a suitable testing environment anymore. We encourage you to migrate to Goerli as soon as possible. How can I migrate to Goerli? You must re-deploy the contracts of your DApp on Goerli testnet. What are the benefits of Goerli? Goerli has a strong community and substantial infrastructure supporting it, but it’s also the most similar to Mainnet in terms of state, which is helpful if you need to test smart contract interactions. So, to test protocol upgrades before deploying to Mainnet, you will need to utilize Goerli, not Sepolia. Where do I get Goerli ETH? You can use this faucet to get Goerli ETH. Will Chainstack be supporting Sepolia? Chainstack will support Sepolia testnet. Stay tuned. What are the benefits of Sepolia? Sepolia is reasonably new, so its state and history are still small. Because of this, the network is quick to sync, and running a node requires way less storage. So, If you want to boot a node faster, Sepolia is your best choice. Future-proof your project with Chainstack #### The ultimate guide to getting multiple token balances on Ethereum Introduction One of the coolest things about Ethereum is its decentralized nature—all of its transactions since the genesis block can be publicly accessible by anyone. But with an average of one million transactions a day, it can be challenging to filter out the data you need fast and efficiently. This post focuses on one particular task—retrieving token balances of an address on Ethereum. The challenge with this task is that there is a significant difference in how ether is stored on an address and how the tokens are stored. Ether is the balance of an address, while tokens are the balance of a contract attributed to an address. To get the ether balance of a wallet address, you need to watch the address. To get the token balance of the same wallet address, you need to watch the list of token contract addresses you want to track. This process requires the execution of not one but multiple JSON-RPC requests consistently—it’s time consuming and resource wasteful if executed individually. At the time of writing this post, it was quite a challenge to find a good guide on how to retrieve data from the ledger in batches. Hence, I’ve decided to write one. Together, in this post, we will go through three different approaches on how to retrieve token balances via the ERC-20 balanceOf contract ABI function in batches from the Ethereum ledger. GraphQL — alternative to the Ethereum JSON-RPC interface introduced in EIP 1767.Etherplex — a JavaScript library that makes use of the multicall smart contract to aggregate function calls and executes them in batch.web3.js BatchRequest — the web3.js batch method that aggregates the list of contract function calls and converts them into an array of JSON-RPC calls before sending it to the Ethereum node in one XMLHttpRequest. Before you start, we assume that: You already know how to write code — preferably JavaScript.You have the code samples cloned and your environment set up. See the repository prepared for this post.You already have your Ethereum node endpoint. If you don't, you can spin up your node with us on Chainstack. Helper functions Before we deep-dive into sample code, let’s take a look at the two helper functions we will be using across the three different approaches. In getTokens(), we dynamically fetch a list of token address, symbol, and decimals from Token Lists—a community-led initiative to improve discoverability and trust in ERC-20 token lists. You can replace tokenSource with an API endpoint of your choice or hardcode a list of tokens within this function. In our example, we will be using the CoinGecko list. require('isomorphic-fetch'); const tokenSource = 'https://tokens.coingecko.com/uniswap/all.json'; const getTokens = () => { return fetch(tokenSource, { methods: 'GET', headers: { 'Content-Type': 'application/json', }, }).then(data => data.json()); }; In convertToNumber(), we convert the hexadecimal response to a readable numeric format. Note that we must avoid dividing tokens that have 0 balance with more than 20 decimals as this exceeds the BigNumber minimum limit and will result in an error. const Web3 = require('web3'); const convertToNumber = (hex, decimals) => { const balance = Web3.utils.toBN(hex); let balanceDecimal = balance; if (decimals && (balance.toLocaleString() === '0' && decimals < 20)) { balanceDecimal = balance.div(Web3.utils.toBN(10 ** decimals)); } return balanceDecimal.toLocaleString(); }; Constants In the constant.js file, we store the constants we will be using for our queries. Remember to update the constants before executing the scripts. ABI — contract ABI with only the balanceOf function. Remember to add the function calls you are planning to execute to the ABI constant.username — your Ethereum node RPC username.password — your Ethereum node RPC password.rpcEndpoint — your Ethereum node RPC endpoint.bathEndpoint — your Ethereum node RPC endpoint with authentication credentials. const abi = [ { constant: true, inputs: [ { name: '_owner', type: 'address', }, ], name: 'balanceOf', outputs: [ { name: 'balance', type: 'uint256', }, ], payable: false, stateMutability: 'view', type: 'function', }, ]; // replace with your Ethereum node RPC username const username = 'username'; // replace with your Ethereum node RPC password const password = 'password'; // replace with your Ethereum node RPC endpoint const rpcEndpoint = 'https://nd-123-456-789.p2pify.com'; // replace with your Ethereum node RPC endpoint const bathEndpoint = `https://${username}:${password}@nd-123-456-789.p2pify.com`; // replace with the address you want to query const walletAddress = '0x3f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be'; module.exports = { abi, bathEndpoint, password, rpcEndpoint, username, walletAddress, }; GraphQL GraphQL is a query language designed to provide flexibility, giving client control over the format of the data anyone wants. This solves one of the most common issues people face when reading data from the Ethereum ledger—underfetching and overfetching data. This can impact your day-to-day operation, especially for users querying data from multiple contracts and different block height. GraphQL API is available on all dedicated Ethereum nodes on Chainstack. Let us take a look at the example below on how we go about retrieving CoinGeсko list token balances using GraphQL. require('isomorphic-fetch'); const ethers = require('ethers'); const { abi, bathEndpoint, walletAddress } = require('./constant.js'); const { convertToNumber, getTokens } = require('./utils'); const convertIndexToAlphetString = number => number .toString() .split('') .map(numberChar => String.fromCharCode(65 + parseInt(numberChar))) .join(''); const queryTemplate = (index, { address }, callData) => ` ${convertIndexToAlphetString(index)}: call(data: { to: "${address}", data: "${callData}" }) { data }`; const retrieveTokenBalanceViaGraphQL = (tokens) => { const ethersInterface = new ethers.utils.Interface(abi); const callData = ethersInterface .functions.balanceOf.encode([walletAddress]); const query = tokens.map((token, index) => { return queryTemplate(index, token, callData); }).join('\n'); return fetch(`${bathEndpoint}/graphql`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ query: `{ block { ${query} } }` }), }) .then(data => data.json()); }; const main = async () => { const { tokens } = await getTokens(); const tokenBalances = await retrieveTokenBalanceViaGraphQL(tokens) .then(({ data: { block: balances } }) => { const output = {}; Object.entries(balances).map(([, { data: hex }], index) => { const { name, decimals, symbol } = tokens[index]; output[name] = `${convertToNumber(hex, decimals)} ${symbol}`; }); return output; }); console.log(tokenBalances); }; main(); Here we dynamically generate the query from the list of tokens before sending it to our GraphQL API endpoint. This approach took an average of 2289ms out of 10 runs. Pros of GraphQL Streamlines complex processes Depending on the use case, you can easily combine queries on different contract function calls, different contract addresses for different wallet addresses at different block heights into one GraphQL query. For example: query { ChainLinkToken11404479: block(number: 11404479) { call(data: { to: "0x514910771AF9Ca656af840dff83E8264EcF986CA", data: "0x70a082310000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be" }) { data } } ChainLinkTokenLatest: block { call(data: { to: "0x514910771AF9Ca656af840dff83E8264EcF986CA", data: "0x70a082310000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be" }) { data } } DaiStablecoin11404470: block(number: 11404470) { call(data: { to: "0x6B175474E89094C44Da98b954EedeAC495271d0F", data: "0x70a0823100000000000000000000000046340b20830761efd32832a74d7169b29feb9758" }) { data } } } Will yield: { "data": { "ChainLinkToken11404479": { "call": { "data": "0x00000000000000000000000000000000000000000003a53a9199924822b36355" } }, "ChainLinkTokenLatest": { "call": { "data": "0x00000000000000000000000000000000000000000003a571b23d1cfe6e4e6355" } }, "DaiStablecoin11404470": { "call": { "data": "0x0000000000000000000000000000000000000000000024e132e65f0c1c62ddeb" } } } } Through GraphQL alias, we can efficiently aggregate multiple RPC calls for different data into one GraphQL query and let Geth and GraphQL do the heavy lifting behind the scenes. Not reliant on dependencies There are no additional libraries required to use GraphQL. This means that your code will be more stable and less vulnerable to security loopholes or outdated dependencies. Cons of GraphQL Function calls must be encoded Executing function calls through GraphQL works the same way as a normal RPC call, which means function calls must be encoded manually and passed onto the query. This might make the code confusing to read. GraphQL alias has strict format requirements According to the GraphQL specification, names must strictly follow the following regex pattern: /[_A-Za-z][_0-9A-Za-z]*/. This makes it difficult to use symbols or contract names as the alias since some contract names or symbols do not match this regex pattern. In the example above, we work around this constraint via the convertIndexToAlphetString() function which generates a unique alphabetical identifier based on the index of the token in the list, which, in turn, we later map to the token list using the same index. Etherplex Etherplex is a library that consolidates the list of the ethers.js contract function calls into one JSON-RPC call on the multicall smart contract aggregate function, which iterates and executes the list of contract function calls. Below is the implementation of the 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; } } Let us look at the example below on how we go about retrieving CoinGecko token list balances using Etherplex. const { ethers } = require('ethers'); const { batch, contract } = require('@pooltogether/etherplex'); const { abi, username, password, rpcEndpoint, walletAddress } = require('./constant.js'); const { convertToNumber, getTokens } = require('./utils'); const provider = new ethers.providers.JsonRpcProvider({ url: rpcEndpoint, user: username, password: password, }); const generateContractFunctionList = tokens => tokens.map(({ address: tokenAddress, symbol }) => contract(symbol, abi, tokenAddress).balanceOf(walletAddress), ); const main = async () => { const { tokens } = await getTokens(); const start = new Date().getTime(); const args = generateContractFunctionList(tokens); const tokenBalances = await batch.apply(null, [provider, ...args]) .then(balances => { const output = {}; Object.entries(balances).map(([symbol, { balanceOf }], index) => { const balance = convertToNumber(balanceOf[0]._hex, tokens[index].decimals); output[tokens[index].name] = `${balance} ${symbol}`; }); return output; }); console.log(tokenBalances); }; main(); Here we dynamically generate the list of balanceOf function calls from the list of tokens before passing it to Ethereplex’s batch function. This approach took an average of 3815ms out of 10 runs. Pros of Etherplex More human readable code Unlike GraphQL, Ethereplex works on top of ethers.js, which allows us to use the contract’s ABI function name instead of encoding them, which makes the code more human-readable. Cons of Etherplex Reliant on Etherplex library At the time of this post, Etherplex has not integrated support for the ethers.js blockTag functionality, which allows the user to run a query on different blocks. If this is a requirement for you, I suggest you consider: Contributing to the Etherplex library.Implementing your own wrapper using the multicall smart contract.Using other approaches described in this post. Unstable The multicall smart contract can sometimes be unavailable and the process will fall back to using the native JSON-RPC approach. For larger queries, this will result in a timeout error: Error: execution aborted (timeout = 5s). web3.js BatchRequest The web3.js BatchRequest method aggregates the list of contract function calls and converts them into an array of JSON-RPC calls before sending it to the Ethereum node in one XMLHttpRequest. The Ethereum node will process these JSON-RPC requests asynchronously before sending them back to the client. Let us look at the example below on how we go about retrieving CoinGecko token list balances using the BatchRequest method. const Web3 = require('web3'); const { convertToNumber, getTokens } = require('./utils'); const { abi, bathEndpoint, walletAddress } = require('./constant.js'); const web3 = new Web3(new Web3.providers.HttpProvider(bathEndpoint)); const generateContractFunctionList = ({ tokens, blockNumber }) => { const batch = new web3.BatchRequest(); tokens.map(async ({ address: tokenAddress, symbol, decimals }) => { const contract = new web3.eth.Contract(abi); contract.options.address = tokenAddress; batch.add( contract.methods.balanceOf(walletAddress).call.request({}, blockNumber), ); }); return batch; }; const main = async () => { const { tokens } = await getTokens(); const batch = generateContractFunctionList({ tokens }); const tokenBalances = {}; const { response } = await batch.execute(); response.forEach(({ _hex }, index) => { const { name, decimals, symbol } = tokens[index]; tokenBalances[name] = `${convertToNumber(_hex, decimals)} ${symbol}`; }); console.log(tokenBalances); }; main(); Here we add the list of balanceOf contract function calls from the list of tokens before calling the batch.execute function. Note that the performance for the batch command may vary depending on the RPC endpoint provider you’re using—sendAsync vs send function. This approach took an average of 3042ms out of 10 runs. Pros of web3.js BatchRequest More human-readable code Unlike GraphQL, the BatchRequest method works on top of web3.js, which allows us to use the contract’s ABI function names instead of encoding them, which makes the code more human-readable. Cons of web3.js BatchRequest The library is still in development Currently the web3.js v2.0.0 library is still in development and it’s very likely to contain breaking changes in the future. Summary In this post, we investigated three different approaches you can take to read data from the Ethereum ledger. In our example scenario, GraphQL had the best average performance of 2289ms as compared to the Etherplex library and the web3.js BatchRequest method. Below are the performance metrics we took: GraphQL outperforms the other two approaches by close to 1 second. I personally suggest using GraphQL, not mainly because of its performance but also for its stability and flexibility. I hope this post inspires you to try using GraphQL for your use case. The GraphQL feature is supported on all our full and archive dedicated Ethereum nodes—sign up with us and unlock unlimited possibility on direct and efficient queries to the ledger. 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. #### The ultimate guide to NFTs: From concept to market success Non-fungible tokens Non-fungible tokens, or NFTs, have become all the rage in the digital world. And for good reason! NFTs present a new way to own digital assets, and they're opening up a brand-new world of possibilities for creators. But what are NFTs really?How do you make NFTs?And how can you make sure you're successful as a creator? Despite all their popularity, questions like these still remain a mystery for plenty and in doing so prevent many creators from taking a bite out of the NFT apple. So, if you're a creator who's interested in getting into the NFT space, take a sigh of relief, for this beginner’s guide is just for you. We'll be covering everything you need to know about NFTs, from what they are and how they work, to tips on how to succeed as a creator in this new and exciting field. That being said, without further ado, let's dive in and learn all about NFTs! Non-fungible tokens 101: What are NFTs and how to succeed as a creator? NFTs are essentially digital assets that are unique and cannot be replicated. They're often used to represent ownership of digital items like art, music, or in-game items. Much like when owning real estate, or a piece of artwork, you are contractually listed as an owner, NFTs offer you a chance to do just that with any digital media on Web3. Figure 1: NFT market capitalization; Source: Forbes When it comes to the process of creating an NFT, it is relatively straightforward, should you opt for minting through an NFT marketplace. The process usually involves creating a digital file, uploading it to a marketplace platform, and then setting a price for it. You can also do it via code, but we will get to that further in the article. But while this does indeed sound simple, being successful with your NFT project hardly is. That is why to get a better understanding of what the key to success as an NFT creator really is, we will be reviewing a set of timeless advice across the entire journey—from planning and creating, all the way to post-release. But before we get started… Before you get started: General advice for creators Before you put down your pen, it is important to note that working with NFTs can be quite foreign, even for experienced digital creators. There are some vital things to consider when it comes to the entire process, which are better said now than having to worry about them later: Make smart decisions NFTs are digital assets that live on Web3 and as a Web3 property, they are essentially financial possessions in their essence. That is why it is imperative to think of NFTs in business terms first and foremost, and only then as digital creations. Why? Because in order to put your works out there, you will ultimately need to pay a certain price for listing, whether it is the platform’s fee, or that to process the minting transaction itself. This highlights the need to think about your bottom line before making your first commit. Figure 2: Profitability framework; Source: Business-to-you  The NFT space is quite crowded and there are plenty of collections that do not generate a single sale, so even if this sounds demoralizing already, it is good to have it in mind throughout your journey. So don’t just mindlessly dive into the deep by investing a huge sum that you cannot afford to lose – stay cool and make smart business decisions. Stay copyright-friendly Everybody wants to make an NFT out of a relatable character they know and love, but sadly it is most likely someone else’s intellectual property already. And should you take such a risk you are essentially exposing yourself to preventable litigation for copyright violation. Nobody wants to get sued into oblivion for a silly mistake, so before you embark on concept creation, it is best to do some research to make sure you are not violating anyone’s intellectual property. To do that you can check with a search query of the chosen name for your collection, or by consulting the database of a copyright office, like the US one, the World Intellectual Property Office, or that of Google. And while this can be a long and exhausting process, a good rule of thumb is “If an original exists only in your head and is not derivative, it is good.” But even so, a quick check just in case should only help you in the end. Figure 3: The Intellectual Property Blossom; Source: Angie Avard Turner Law  Keep things secure Let’s go back to the line “NFTs are digital assets that live on Web3” for a second. Because of this, it is vital to prepare yourself for the way account security works with anything blockchain. To keep it simple, your wallet address is essentially your account – you use it for authenticating, minting, and storing your NFTs. And should you lose your access, you lose it all irreversibly. That is because, unlike the centralized approach of Web2, where the platform can reset your access, or give you ample means of restoring it, Web3 offers no such options. Your public key (address), and private key, key file, or mnemonic phrase (password), are permanent and can never be changed. This means that if someone has access to your password, they basically have the key to the entire kingdom. That is why is absolutely critical to be mindful of your means of access and commit to a secure process of handling and storing it. Here are a few timeless guidelines to get you started: Figure 4: Tips to secure your blockchain wallet The drawing board: How to plan for minting NFTs With this timeless, but basic advice out of the way, we can finally start with the first part of the cool stuff—planning. Even if you are itching to create already, take a deep breath and consider the following: NFT marketplaces vs minting using code As mentioned previously, there are two ways to mint your collection – via code and via an NFT marketplace. Minting via code is an excellent way to go your own way and keep your collection centralization-free, by avoiding marketplace platforms. It will also give you the real feel of minting NFTs, which is why we will be including the step necessary for code minting further in this guide. So, even if you are an artist that is foreign to coding in general, this guide will offer you a means to make your first steps into Web3 development in a simple language you can replicate easily. Doing so will allow you to focus on creating first and foremost, without having to endure the pain of finding out how to do everything yourself. And the best thing about it? You will also get a complete code extract you can just copy-paste and adjust parameters accordingly to start minting. When it comes to marketplace platforms, you have plenty of choice and they all follow a similarly straightforward process – upload assets, set the name, price, description, and other relevant parameters. Overall, it is mostly just filling out a form before you are asked to mint by committing a transaction. Popular NFT marketplace platforms Figure 5: NFT marketplaces all-time stats; Source: DappRadar Let’s review a few of the most notable NFT marketplace platforms without digging too much into them: OpenSea The original first NFT marketplace and by far the largest. OpenSea sports a huge volume of roughly $18M in daily trading and 50,000, in terms of daily traders. Naturally, the competition here is huge but so is the opportunity for success, because of discoverability. The platform supports four currencies at present—Ethereum (ETH), USDC, DAI, Polygon (MATIC), and Solana (SOL). MagicEden MagicEden is the top marketplace platform, on and working exclusively with the Solana network. Despite being on a single chain, this marketplace manages to accumulate a daily trading volume of give-or-take $1.8M and 20,000 daily traders. As it is Solana-exclusive, the only accepted currency is SOL. X2Y2 One of the hottest new kids on the block, X2Y2 has only been around since the start of 2022, but despite its relatively short tenure has managed to make steady waves across the space. It currently clashes with MagicEden for the second place, in terms of daily trading volume, generating over $2M from just 4,000 daily traders, while working exclusively with ETH. Rarible Rarible is one of the most flexible NFT marketplaces mentioned in this list, when it comes to supported currencies—Ethereum (ETH), Polygon (MATIC), Solana (SOL), Flow, and Tezos (XTZ), while being open to more in the future. Founded in 2019, it has managed to accumulate almost $298,000 of trading volume over its history and over 105,000 traders. Drafting a roadmap for your NFTs You know the basics of working with Web3, and picked a marketplace platform where you want to list, or avoid that altogether, so what’s next? It’s time to pay your dues to the drawing board and map your journey ahead by drafting a roadmap for your NFT project. But why make the effort? Because having a roadmap allows you to think ahead and plan just how far you want to take your course of minting. And despite this sounding like an absolute chore (and it is), it will pay off plenty once your project starts generating results. Should your NFTs become popular among your community there is no better way to navigate than having a detailed plan of approach. Figure 6: Bored Ape Yacht Club (BAYC) Roadmap 2.0; Source: Twitter  That is especially true, considering that most of your revenue will be derived from secondary sale royalties, which highlights the importance of continuously adding value post-mint. That is why it is good to answer questions with your roadmap like: Do I want to do airdrops during launch or in the future in general? Do I want to add extensions that create new variants of my NFTs? Do I want to create a Decentralized Autonomous Organization (DAO) for the community? How will I promote my NFTs to reach new customers? How do I add more value to increase interest and commitment? Creation phase: From concept to parameters Roll up your sleeves for the time for the real moment of cool stuff galore is finally upon you! It’s time to put your creative muscle to action and well… get creative! Let’s give you a quick walk through the concept-creation phase: Make your first NFT concept Much like any digital artwork, NFTs also start with some concept art. You don’t have to start with all the details right off the bat—work with primitives or placeholders in other words. NFTs are usually modular artworks, so by starting off with primitives will provide you with the structure you need to create a ton of assets, originating from a single template. For the sake of the example, we will be creating a character-based NFT collection. Regardless of the actual art style of the character, it all starts with a silhouette. Want your NFTs to be character busts only? Make a bust placeholder! Full size? Sketch out the entire thing! Not the best artist? Consult some of the many guides available online: Figure 7: Face and full body proportions guides; Sources: Expressive Monkey & Alena Lane  Once you are happy with your primitive you can start working on adding details with new layers on top, until you are happy with your first design. After that, all you have to do is introduce some diversity by cloning the detail layers and making the appropriate adjustments to create as many variants of your NFT character as you like. Pricing NFTs and other parameters With the artwork out of the way, it’s time to think about the key parameters of your NFT listing. And while name, description, and other such properties are relatively straightforward, pricing your NFTs isn’t. Naturally, there is no perfect NFT price, but you can consider the following actions to get a better idea: Examine NFT projects that are similar to yours on various marketplaces Get some feedback from the community on fair pricing Determine your options for secondary sale royalties Decide if you want more participants (lower prices), or more die-hard collectors (higher) Evaluate your roadmap and project vertical to see how pricing fits in the bigger picture: Common—large number of NFTs, easily tradeable, or gifted (from 0.01 to 0.04ETH) Rare—a balance between NFT number and tradeability (from 0.05 to 0.09ETH) Epic—low number of NFTs, highly collectible, harder to trade (0.1ETH and above) How to generate NFTs with code Minting NFTs via code is a tad bit more difficult than just using a marketplace platform to do it for you. Even so, it offers you more freedom and a chance to experience the true way it is done. To do a code mint you will first need some means to generate requests to the network of your choice. For this example, let’s go with Ethereum’s Goerli testnet, since it will be the primary testnet for after the Merge. Step 1: Lay the initial foundation 1.1: Get a node endpoint There is little need to run your own node, which can take ages to sync, instead, you can deploy a node in the time it takes to brew a fresh cup of coffee with Chainstack and at a fraction of the pain. So, hop on to the site, create an account for free, deploy a Goerli testnet node and get its HTTPS endpoint. Not sure how to do that? Check out the steps in our quick start guide: 1.2: Install Node.js and Web3.js If you don’t have Node.js already go ahead and install it. After that, it’s time to make some space for your code base. To do that create a new folder at a location of your choosing and initialize your node project by typing the following in your CLI (Command Prompt/Terminal): npm init Then, install the Web3.js library, which will provide you with the functionality needed to interact with your node: npm i web3 After the installation is complete, create a new JS file called “keys.js” and add the following lines to it to initialize some needed dependencies: //Process dependencies var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || 'https://YOUR_CHAINSTACK_ENDPOINT_HERE'); 1.3: Create and fund a wallet Now it’s time to create a wallet address and fund it with some ETH, so you can move forward with the minting. To do that add the following to your “keys.js” file, then run your code by typing “node keys.js” in your CLI: //Create new wallet-key pair then return values var keys = web3.eth.accounts.create(); console.log(keys); You should get a response like this: address: ‘0xYOURNEWWALLETADDRESSHERE/’, privateKey: 'YOURWALLETPRIVATEKEYHERE', signTransaction: [Function: signTransaction], sign: [Function: sign], encrypt: [Function: encrypt] Don’t mind anything else except the “address” and “privateKey” values. Just place them somewhere for safekeeping. After this, you are ready to fund your address. To do that hop on to the faucet here, input your address, and select “Ethereum Testnet Goerli.” Now it’s time to check whether your balance has updated, so create a new JS file called “balance.js” and copy over what we have so far. You will use the script to confirm you received ETH from the faucet, which can take ~30 mins. The end result would look like this: //Process dependencies const endpoint = 'https://YOUR_CHAINSTACK_ENDPOINT_HERE; const address = '0xYOURWALLETADDRESSHERE'; var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); //Create new asynchronous function to get balance const getbal = async (address) => { //Await promise before returning balance const balance = await web3.eth.getBalance(address); console.log(balance); }; //Don't forget to run! getbal(address); What stands out from the above is that we are creating an asynchronous function, which ensures your promise is not left pending by waiting for it to successfully resolve before printing to the console. Because of this, you will get a response like this, after running the code by typing “node balance.js” in your CLI once again: Promise { '5000000000000000000' } Without this function you will be left with the following, which will hardly offer you any information: Promise { <pending> } This is so because it takes time to process your request and the entire code segment will be executed long before you receive an adequate response. 1.4: Store values in .env Let’s store all these values in a .env file for safekeeping. To do that first install dotenv via npm with: npm i dotenv Then create a .env file in your project directory with the following contents: ENDPOINT_URL = "https://YOUR_CHAINSTACK_ENDPOINT_HERE" PUBLIC_KEY = "0xYOURWALLETADDRESSHERE" PRIVATE_KEY = "YOURPRIVATEKEYHERE" That being said, it is important to note that you should AVOID uploading your “.env” file to any PUBLIC repo, as it will reveal crucial information like your private key, for example, leaving your entire wallet completely exposed! Make sure to add “.env” to the “.gitignore” file, prior to publishing. Now, go back to your “balance.js” file and process the "dotenv" dependency, while replacing the endpoint and address constants with a reference to ".env" file as outlined below: require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; Your “balance.js” file will now look like this: //Process dependencies require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); //Create asynchronous function to get balance const getbal = async (address) => { //Await promise before returning balance const balance = await web3.eth.getBalance(address); console.log(balance); }; //Don't forget to run! getbal(address); Now, it’s time for some final preparations before we move forward with the contract. Create a new JS file called “deploy.js” and input the following lines: //Process dependencies require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; const privKey = process.env.PRIVATE_KEY; var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); Step 2: Write, compile and deploy the smart contract 2.1: Create a contract draft With all the prerequisites out of the way, it is time to create your smart contract. This may sound scary at first but you can breathe a sigh of relief, knowing that OpenZeppelin offers out-of-the-box contract samples, which are already audited for security. And the best thing about it? You use the wizard to create a contract that truly suits you best. For our sample project we will be using the following settings: Figure 8: OpenZeppelin wizard ERC721 settings Apart from the name and symbol which are pretty straightforward, we will be adding a “Mintable” option with “Auto increment Ids” checked. In doing this, we will allow privileged accounts (e.g. your account) to be able to mint new tokens. These can be new additions to your collection. The “URI Storage” option needs to be enabled as well since we want to add media files like an image to our NFTs. Lastly, we want to add the “Ownable” option as well, so we can perform admin actions. There are more parameters that can be enabled with the wizard, but they are outside the scope of this tutorial. Even so, don’t be afraid to experiment with them should you wish to expand further o the basic functionalities we have implemented so far. As a final action in this step, make sure you have the OpenZeppelin dependencies available by typing in your CLI: npm i @openzeppelin/contracts 2.2: Compile your contract It’s time to compile your contract. To do that copy the code from the OpenZeppelin wizard into a new file like “PCHNFT.sol” or click “Download” at the top right corner. Depending on your folder structure, you might need to make some adjustments to the import functions outlined in your smart contract code to correctly reference their paths. For example, if you used the OpenZeppelin wizard to generate “PCHNFT.sol,” the import functions would most likely appear as such: import "@openzeppelin/contracts/ERC721.sol"; import "@openzeppelin/contracts/utils/Counters.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; Because of this, placing “PCHNFT.sol,” in your base path, installing the OpenZeppelin contract library via npm, and attempting to compile the contract would result in a parser error where the dependency files cannot be found. That is why, if you followed the process to the letter, you would also need to make the following adjustments: import "./node_modules/@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "./node_modules/@openzeppelin/contracts/utils/Counters.sol"; import "./node_modules/@openzeppelin/contracts/access/Ownable.sol"; import "./node_modules/@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; Doing so, should resolve any pathing errors and allow you to move forward with compiling. You can’t deploy a Solidity contract directly, however, instead, you need to get its Application Binary Interface (ABI), as well as its bytecode, which is the executable code. Before you do that, however, make sure to globally install the "Solc.js" library, which will enable the Solidity compiler command-line tool you need to move forward: npm install -g solc Once done, hop back into your CLI and input the following, minding not to capitalize “ABI”, as it is case sensitive: solcjs --abi --include-path ./ --base-path . PCHNFT.sol solcjs --bin --include-path ./ --base-path . PCHNFT.sol The first command will compile your contract and extract the ABI, while the second one the bytecode. We add the “--include-path ./ “ parameter to point to the Solidity compiler where it can find its dependencies within the appropriate parent folder. Upon successful compilation, there would be a total of 26 new files generated—13 pairs of ABI and bin files if you followed our example. Attempting to compile will surely clarify, whether or not you have successfully resolved the parser error, and should it persist, be sure to double-check your folder structure. Another possible error you can encounter at this step can be a docstring parsing one. To resolve it, remove any excess code comments, especially such that spread across multiple lines. When you are done compiling, find the abi and bin files containing “PCHNFT” in their names, which would be “PCHNFT_sol_PlaceholderHeroes.abi” and “PCHNFT_sol_PlaceholderHeroes.bin” in our case. To be able to read these files locally, we will need to use Node.js' built-in fs (File System) library by referencing it in the code like this: var fs = require('fs'); var contractABI = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); var contractBIN = fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.bin', 'utf8'); Since both files are essentially strings in utf8 format, you need to first parse the ABI as a JSON object by adding “JSON.parse()” before attempting to read it with “fs.readFileSync.” Such actions won’t be necessary for the BIN file—you can just read it directly. 2.3: Deploy the contract to Goerli Now let’s deploy the contract by creating a new function in your “deploy.js” file containing the following: //Create asynchronous deploy function const deploy = async () => { console.log('Attempting to deploy contract from: ', address); //Create new contract object const contractNFT = new web3.eth.Contract(contractABI, address); //Deploy contract object as a transaction const contractTX = contractNFT.deploy({ //Set transaction data as the contract bytecode data: contractBIN, }); //Sign the transaction const createTransaction = await web3.eth.accounts.signTransaction( { //Define transaction parameters from: address, data: contractTX.encodeABI(), gas: '2968862', }, privKey ); //Return transaction receipt const createReceipt = await web3.eth.sendSignedTransaction( createTransaction.rawTransaction ); //Log contract address from receipt console.log('Contract successfully deployed at: ', createReceipt.contractAddress); }; //Don’t forget to run the function! deploy(); That’s it—your first NFT contract is now live on the Goerli network! And with that out of the way, it is time to set up the properties of each NFT prior to minting. But before we move forward with that, let’s turn the page in an appropriate manner by sharing the complete deployment script that successfully led us thus far. We won’t be making further changes to it after all. //Process dependencies require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; const privKey = process.env.PRIVATE_KEY; var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); var fs = require('fs'); //Read and parse ABI and BINary code files var contractABI = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); var contractBIN = fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.bin', 'utf8'); //Create asynchronous deploy function const deploy = async () => { console.log('Attempting to deploy contract from: ', address); //Create new contract object const contractNFT = new web3.eth.Contract(contractABI, address); //Deploy contract object as a transaction const contractTX = contractNFT.deploy({ //Set transaction data as the contract bytecode data: contractBIN, }); //Sign the transaction const createTransaction = await web3.eth.accounts.signTransaction( { //Define transaction parameters from: address, data: contractTX.encodeABI(), gas: '2968862', }, privKey ); //Return transaction receipt const createReceipt = await web3.eth.sendSignedTransaction( createTransaction.rawTransaction ); //Log contract address from receipt console.log('Contract successfully deployed at: ', createReceipt.contractAddress); }; //Don’t forget to run the function! deploy(); Step 3: Define and mint your NFTs 3.1: Set up dependencies and metadata Let’s leave the contract deployment script for now and create a new file “mint.js” with the same “.env” parameters referenced from the start: //Process dependencies require('dotenv').config(); const endpoint = process.env.ENDPOINT_URL; const address = process.env.PUBLIC_KEY; const privKey = process.env.PRIVATE_KEY; var contractABI = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); Once done, we need to set up the metadata for your NFTs. To do that create a new json file with the name of a particular NFT (“testorius.json” in this case) and add some attributes like so: { "description": "Your friendly neighbourhood mage.", "image": "", "name": "Testorius Testolf" } We have left the image attribute empty for now, as we will be hosting the images on the InterPlanetary File System (IPFS). In order to do that, hop over to the IPFS download page and install the interface of your choosing, then run. To keep things simple, we will be using the desktop GUI. To have a smoother experience with IPFS, visit Pinata and create an account. Once you have taken care of that, click on your profile avatar and select “API keys,” then create a new API key making sure the “Admin” option is turned on. Now open your IPFS desktop GUI, click on “Settings,” and then “Add Service.” From there pick “Pinata” and input your API key in the “Secret Access Token” field. The rest of the fields will fill out automatically. This concludes the setup, and you can move forward with the file upload. With the IPFS interface open, navigate to “Files” then simply drag and drop your NFT images. After they have successfully uploaded click the three dots next to each file and select “Set pinning” and tick “Local node” and “Pinata.” This makes sure your file is accessible outside your local environment and via the Pinata API. Now click the triple dots and select “Share link,” then paste the appropriate link into your image attributes in the “testorius.json” file. This ensures your images will never 404, as long as there are nodes that host them! This is how your file should ultimately look: { "description": "Your friendly neighbourhood mage.", "image": "https://ipfs.io/ipfs/QmWatweTiTNcUjQUwePCWHxK1ZiqV3ueZ4Y3Q4DABuHXCd?filename=testolf.png", "name": "Testorius Testolf" } 3.2: Minting your first collection Check what your contract address was and refer to it with a new Web3 contract object in your “mint.js” file, then add previous dependencies like so: //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 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); //Create new contract object const contractObj = new web3.eth.Contract(contractNFT, contractAdrs) That being said, we can move the “contractAdrs” to the .env file like so: CONTRACT_KEY = "0xYOURCONTRACTADDRESSHERE" After that don’t forget to reference it in the “mint.js” file: const contractAdrs = process.env.CONTRACT_KEY; Now let’s create a minting function, similar to the one you did for contract deployment. The end result would appear as this: //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 fs = require('fs'); var metadata = 'https://ipfs.io/ipfs/YOUR_NFT_JSON_HERE'; var contractNFT = JSON.parse(fs.readFileSync('./PCHNFT_sol_PlaceholderHeroes.abi', 'utf8')); var Web3 = require('web3'); var web3 = new Web3(Web3.givenProvider || endpoint); //Create new contract object const contractObj = new web3.eth.Contract(contractNFT, contractAdrs) //Begin asynchronous mint function const startMint = async (tokenId) => { console.log('Attempting to mint to: ', address); //Wait for the completion of the following mint transaction const mintTX = await web3.eth.accounts.signTransaction( { from: address, to: contractAdrs, data: contractObj.methods.safeMint(address, metadata).encodeABI(), gas: '2968862', }, privKey ); //Wait for the completion of the mint transaction then return receipt const createReceipt = await web3.eth.sendSignedTransaction( mintTX.rawTransaction ); console.log('NFT successfully minted with hash: ', createReceipt); }; //Don't forget to run the minting function! startMint(); Once that is done, host your “testorius.json” on IPFS (making sure pinning is ticked for both “Local node” and “Pinata”), if you haven’t done so already, then copy its link (via “Share Link”) as a new variable called “metadata,” and run. Congratulations, you have now minted the first NFT from your collection! To add more, simply create a new JSON file with different parameters and rerun the minting function with the appropriate JSON file selected for the metadata variable. 3.3: Viewing your NFTs If you have done all the previous successfully, then this one will be a piece of cake. Open your MetaMask wallet, or download it if you don’t have it yet, then log in and select the Goerli network at the top. Click on the icon in the top right corner (not the Metamask logo) and select “Import Account.” Choose “Private Key,” since that is how you created your address initially, and paste it in the appropriate field. Then, hop on to the “Assets” tab and click “Import tokens” at the bottom. Paste your NFT contract’s address in the first field and it should automatically fill in the name, otherwise, just type it instead. Since your NFTs don’t have decimal places like a currency does set “Decimals” to 0. Finalize your input by tapping “Add Custom Token” and voila—your NFT is now visible in Metamask! Figure 9: PlaceholderHeroes NFTs inside your Metamask wallet All tutorial files Due to the sheer size of this tutorial, we thought it’d be best to leave you with a repository of all files used in this tutorial. You will also find a ".env" file template, where you can just replace the sample text with the values of your project to get things running. Make sure you avoid publishing the actual file containing live variables to any public location. Browse all the tutorial files here. Post-release: Marketing your NFTs Now that you have created and listed your NFTs, it is time to get to the hardest part – marketing. And considering just how saturated the entire space is, this should come as no surprise. But no matter how difficult standing out from the crowd may be, it all comes down to a few simple factors. That is why should you manage to excel in them, success will follow swiftly. Building a supporter community The success of your NFT project will ultimately be determined by your community. Whether you're an indie artist trying to make money from selling NFTs, a Web2 brand looking to experience the space first-hand, or a Web3 developer making your first steps, your collectors should be your top priority. The best time to launch your community is now. There will never be a perfect time, so don't wait! Start growing your brand, by setting up Discord, Telegram, and Twitter to start engaging with potential buyers regularly. If you want to sell a successful NFT project and build a loyal following, you need to invest time in brand-building now. Rest assured, nobody is asking you to be on every social media platform out there, quite the contrary - find out where your audience spends their time and focus your efforts there. And once you do commit yourself to regular interaction and start connecting with your potential customers. You won’t move the dial much at first, but that’s okay! Community building takes time to foster. Getting people involved One of the best ways to build a strong and loyal community is by getting people involved in your development journey. After all, it is one of the key factors that make the “Build in Public” enthusiasts so popular among plenty of other great developers. Be brave and authentic - share your progress, setbacks and lessons learned unashamed. Everybody fails all the time and owning your vulnerability is a sure-fire way to connect with your audience on a more human level. Figure 10: Consumer sentiment of brand behaviors on social; Source: SproutSocial And sometimes getting people involved means doing so literally and directly—ask them for feedback and involve them in your creative process to really foster a sense of belonging. This is also one of the reasons why businesses do a killing with User-Generated Content (UGC). Because by empowering your customers and making their voices heard, you kindle a fire in their hearts like no other. That being said, do remember to leverage the authority figures that drive people’s opinions—influencers. In doing so, you can achieve excellent results, even if you do not have the hottest new celebrities on the bandwagon. Instead, go for smaller niche content creators that have a stronger bond with their followers, which will result in much more bang for your buck engagement-wise. Communicating effectively With “rug pulls” abound throughout the entire history of Web3, going AWOL into deafening silence is the worst mistake you can make. If there is a perfect way to ruin a good reputation and trust in your project, it would by far be found in irregular communication. Talk often, no matter how small it may be from time to time—just show your community you are still fighting the battle they eagerly follow. A regular posting schedule is great, but it is not for everyone and can feel inorganic, when overdone. The more you grow, and the more budget becomes available, the closer the time comes for you to get a helping hand in managing communication for you. That is especially true if you are a developer, or an artist, who prefers to build, rather than talk. Get an intern and focus on what you do best! But even when you have a team to do all the things you don’t want for you, never forget your roots. Find the time to drop by in the community channels from time to time and create some positive interactions with your audience. A strong and caring leader that is not afraid to show his face can be a powerful way to foster even more trust and excitement in your loyal follower base. Figure 11: Revenue impact of engaging with customers; Source: ClaraBridge Bringing it all together With this, we can put a definitive end to our comprehensive guide to NFTs. Thanks to this overview, you now have all the knowledge needed to set out on your first creator journey. From understanding the economics side of digital creations on Web3, through sketching out concepts and coding your way to production, all the way to post-release success, there is little more to be said. Don’t feel ready? Worry not, for nobody really does. Sometimes diving straight into the action is how you learn best. Forget about building a unicorn project, more often than not it takes years of work to become an overnight success. So, be patient, enjoy the journey and embrace every step of the way. And if there is one final piece of advice, we can leave you with, it would be to fail fast and pivot accordingly. After all, every mistake is but a building block that gets you closer to your goals, no matter how dire the situation may appear to be. Pick yourself up, put a smile on your face, and continue to BUIDL. Power-boost your project on Chainstack #### The ultimate Solana developer guide: Master swaps, transfers, priority fees, Raydium and more Imagine a blockchain that's at the epitome of high performance, designed for mass adoption, and friendly to an array of use cases, from finance to gaming and payments. That's what Solana is about. This network operates as a single, global state machine, encapsulating openness, interoperability, and decentralization. Solana's uniqueness lies in its capacity to store and execute code, transforming it into a massive, global computer. Users deploy code called a program, which some may refer to as a "smart contract" in other blockchains. As highlighted in the Solana developer workflows, these programs create an avenue for interaction with clients through transactions on the blockchain. As we get into the intricate details of Solana, you'll understand why it's a befitting alternative for your blockchain needs. With benefits over features and a shiny track record, Solana is undoubtedly worth mastering whether you're a developer, a DApp user, or a blockchain enthusiast who prioritizes speed and security. What makes Solana unique? Deciphering the Solana network's uniqueness requires us to dig deeper into its features. Here are some distinguishing aspects of Solana: Performance: Solana's high performance is an exceptional characteristic. This innovative network is designed for unparalleled speed to handle surges in traffic without compromising performance or security. Adaptable: The malleability of Solana allows it to suit myriads of applications, carrying tremendous implications for sectors like finance, NFTs, and gaming, to name a few. Interoperable: Solana maintains an open and interoperable model, supporting a multitude of projects built on it. This decentralization gives developers the freedom and flexibility to bring to life an array of innovations. Stateless programs: Solana introduces stateless programs (or "smart contracts"), thus eliminating the need for each node to execute the same instructions repeatedly. Accelerated processing: Solana's ability to accommodate concurrent transaction processing and improve scalability sets it apart from most blockchains. By harnessing its unique properties, Solana provides users with a seamless transition from traditional financial systems to a future shaped by blockchain technology. Its high-speed performance, coupled with the powerful capabilities of its blockchain, positions Solana as an attractive choice for developing and deploying DApps. Understanding Solana Solana’s unique architecture and developer workflows set it apart as a platform not just for today's needs but also for the future's demands. The following sections delve into the core aspects of Solana, from its developer workflows to transaction processing, providing a comprehensive overview of its capabilities and how it's pioneering the path for a decentralized future. Overview of Solana developer workflows Understanding the Solana network unfolds from its development workflows. At a high level, Solana takes on the appearance of a colossal global computer, open to anyone for storing and executing code, for an equivalent fee. Such deployed code is labeled a "program," often referred to as a "smart contract" in several other blockchains. To interact with a program entails dispatching a transaction on the blockchain from a client. Figure 1: Solana developer workflows; Source: Solana Conventionally, there are two primary workflows for development on Solana. Program development: This workflow entails pioneering and implementing custom Rust, C, and C++ programs directly to the blockchain. These deployed programs are accessible to anyone conversant with communicating with them. Client development: Operating from the DApp end, this workflow fosters DApp development to connect with the deployed programs. Apps can tender transactions bearing instructions to these programs via a client SDK, crafting a myriad of applications like exchanges, wallets, and more. An amalgamation of these workflows births an expansive network of DApps and programs capable of interacting with each other, thereby updating the state and querying the blockchain. Program development on Solana In Solana's ecosystem, the term 'program' indicates what is commonly known as a 'smart contract' in other blockchain networks. These programs, developed in Rust, C, or C++, can be deployed directly onto the Solana blockchain. When you release a program on Solana, anyone who knows how to interact with it can do so. However, it's crucial to remember that once deployed, these programs cannot be changed—a guiding principle of immutability in blockchain technology. Program development involves creating instructions that dictate how state transitions happen. This process can be likened to developing an API for interacting with databases. Only, in the case of Solana, the chain itself acts as a database. Those keen on stepping into the world of Solana-based program development, know that it requires a profound comprehension of the Solana programming model. Even so, the performance payoff is lucrative, as the potential capabilities of your Solana program can overshadow those of traditional smart contracts. Wallets in Solana In Solana, wallets function as the key gateway for users and developers to interact with the Solana network. A wallet in Solana primarily serves two functions: Account management: Wallets store the public and private keys for one or more accounts. They handle details like account creation, key management, and transaction signing. Transaction interaction: Wallets make it possible to communicate with programs on the blockchain by forming and broadcasting transactions. Different types of wallets cater to varied user requirements. These include: Web wallets: These are accessible from web browsers and offer an easy starting point for new users. e.g., Solflare. Hardware wallets: These provide increased security as they store private keys offline in a physical device. e.g., Trezor. Software wallets: These are programs downloaded to a computer or mobile, providing a varied range of features. e.g., Trust. Understanding wallets is an essential part of mastering Solana as it allows seamless interaction with the Solana network and DApps built upon it. Transactions on Solana In Solana, a transaction is a bundled set of instructions with a single goal—to atomically update the state of the blockchain. Transactions highlight the interaction between clients and programs, thereby forming the backbone of Solana's operations. Every transaction in Solana includes: Signatures: Identifications provided by the initiating parties. Message: Contains the instructions which include the program ID, accounts involved, and data passed to the program. Here's what typically happens: A client (user or DApp) creates a transaction, signing it with the private key of the sender's account. The transaction is then sent to one of Solana's validator nodes. This node validates the transaction's signatures and executes the instructions. If the transaction is valid, it gets added to Solana's transaction pool and awaits final processing. An intuitive insight into transactions is key to leveraging the power of Solana's blockchain. From DApp interactions to wallet functions, transactions pave the way for a spectrum of activities within the Solana network. Figure 2: Visual layout of a Solana transaction; Source: Solana Instructions in Solana transactions Every Solana transaction embeds one or more instructions that each contain the data (input), an ordered list of accounts it operates on, and the program ID. Figure 3: Components of a Solana transaction instruction; Source: Solana The instruction data, a byte array, interprets differently for each program. The program may decide to interpret it as an array, a struct, or as a combination of various data types. The crux is that the instruction data carries the payload borne by the transaction to interact with a specific program on Solana. Any changes made to the accounts are visible instantly by other instructions in the same transaction and to subsequent transactions. This unique utility ensures an atomic commitment to the ledger, meaning all instructions in a transaction succeed or fail together, thus maintaining consistency in the state of the chain. Understanding instructions is critical when creating transactions, as it influences how programs interact with the state stored in accounts. // Sample Solana instructions snippet pub fn create_account( from_pubkey: &Pubkey, to_pubkey: &Pubkey, lamports: u64, space: u64, owner: &Pubkey, ) -> Instruction { let account_metas = vec![ AccountMeta::new(*from_pubkey, true), AccountMeta::new(*to_pubkey, true), ]; Instruction::new_with_bincode( system_program::id(), &SystemInstruction::CreateAccount { lamports, space, owner: *owner, }, account_metas, ) } Transaction fees on Solana On the Solana network, transactions aren't free. They come with a cost, a "transaction fee," that clients need to pay whenever they make a transaction. These fees primarily perform two functions: Prevent DDoS attacks: By adding a fee, Solana ensures that it would be prohibitively expensive for anyone to flood the network with transactions, thus maintaining network health. Compensate validators: Transaction fees serve as incentives for validators. As validators commit resources and time to process transactions, the fees serve as compensation for their efforts. The fee for a transaction in Solana varies based on the current congestion level of the network. When the network is busy, fees rise, and when it quietens, the fees decrease. But how does Solana calculate these fees? It's simple, and it's all performed automatically: Solana determines a base fee for an instruction based on its current cost model. It then adds any additional fees for the execution of built-in instructions. Finally, it multiplies the cumulative fee by the current network fee multiplier, setting the final fee. Making sense of transaction fees is crucial in understanding Solana's economics and will aid you in navigating this vibrant ecosystem more effectively. # Solana getFees RPC API method snippet $ curl <http://api.mainnet-beta.solana.com> -H "Content-Type: application/json" -d ' {"jsonrpc":"2.0","id":1, "method":"getFees"} ' # Response { "jsonrpc": "2.0", "result": { "context": { "slot": 106818885 }, "value": { "blockhash": "78e3YBCMXJBiPD1HpyVtVfFzZFPG6nUycnQcyNMSUQzB", "feeCalculator": { "lamportsPerSignature": 5000 }, "lastValidBlockHeight": 96137823 } }, "id": 1 } Demystifying accounts on Solana Accounts in Solana are ubiquitous. Each transaction in Solana requires an account for operation, from paying transaction fees to holding data manipulated by programs (smart contracts). The significant features of Solana accounts include: Key pairs: Each account is associated with a private-public key pair. The public key acts as the account's address, and the private key is used to authorize transactions. Data storage: Each account carries data which is an array of bytes. The data entries can be manipulated and read through programs, but only the owner program can modify its data. Nonce accounts: Solana's unique nonce accounts, a type of account, can be used for transaction processing. They also serve as a replacement for the "recent blockhash queue" that the system uses for managing transaction lifetimes. Assets management: An account can hold native or tokenized assets, making it similar to an Ethereum address. Being aware of the account operations on Solana is as crucial as understanding its transaction model. This understanding sets the foundation for interacting with Solana's blockchain more comprehensively. Role of programs in Solana’s ecosystem Programs in Solana occupy a central role in the network's operation. Sometimes referred to as 'smart contracts' in other blockchain networks, programs in Solana interpret and execute instructions within a transaction. Some notable features of Solana's program model include: Stateful operations: Programs can maintain a persistent state across transactions, thereby allowing complex operations and interactions. Multi-language support: Solana-specific programs can be developed using languages that can compile to BPF (Berkeley Packet Filter), such as Rust and C. This provides developers the flexibility to build in familiar languages. On-chain programs: Once a program is deployed to the network, it is available to anyone who can form a valid instruction. Interoperability: Different programs on Solana can interact with one another. A single transaction can contain instructions for multiple programs. In the Solana network, programs are the equivalent of CPUs in conventional computers. Grasping the concept of programs will provide a more holistic view of how Solana's blockchain functions. Development environments for Solana Having a safe and efficient environment to test and develop is vital for all developers. Luckily for Solana developers, the network provides several environments: Local development environment: Solana allows developers to run a local test validator. This environment is used for quick testing during the development phase and does not require any transaction fees. Devnet: This is a publicly accessible test network maintained by the Solana team. It replicates the conditions of the Mainnet and is optimal for final testing before deploying onto the main network. Testnet: This environment is used to beta-test the latest Solana software under a highly adversarial condition. It permits developers and validators to participate in various testing scenarios. Mainnet: This is the main Solana network where real transactions occur. Once testing on Devnet and Testnet is satisfactory, developers can transition to the Mainnet. Understanding the appropriate environment for each stage of development and testing is crucial to creating effective and robust programs on Solana. How to deploy a Solana node for free on Chainstack In keeping with the ethos of decentralization and fostering inclusivity, Chainstack offers an easy-to-use platform for deploying Solana nodes for free. Here's a simple guide on how to get your Solana node up and running on Chainstack: Sign up: Start by creating a Chainstack account. Create a project: After you're signed in, click Create a Project. Add network: Click Add Network and select ‘Solana’ under the protocol option. Create the deployment: After clicking 'Next', set the node details and click Create. Get your endpoint: Once deployed, click on your node and find your access details. https://www.youtube.com/watch?v=CIRXpb07TdY Figure 4: How to deploy a node for free on Chainstack; Source: Chainstack Remember, while Chainstack offers the ease and convenience of deploying Solana nodes for free, our platform also provides tiered pricing options for more advanced needs. Master Solana development in code We offer a series of Solana mastering tutorials, focusing on various aspects of the protocol to help Web3 developers acquire in-depth knowledge. Some of the topics now included in our tutorial series that we will share snippets from in the coming sections are: Token swaps using the Raydium SDK: Dive deep into performing token swaps on the Solana blockchain, utilizing the Raydium SDK for efficient and cost-effective transactions. Transferring SPL tokens with TypeScript: Explore the nuances of SPL token transfers within the Solana ecosystem, leveraging TypeScript for a streamlined development process. Retry logic for SPL token transfers: Learn advanced techniques to bolster the reliability of SPL token transfers, incorporating retry logic to handle transaction failures gracefully. Solana account retrieval methods: Gain clarity on the distinct methods available for account retrieval in Solana, including getAccountInfo and getMultipleAccounts, and their use cases. SPL token distribution: Discover how to leverage Solana's getTokenLargestAccounts RPC method to analyze the distribution of SPL tokens among holders, providing insights into tokenomics. Priority fees for faster transactions: Get to know the basics of priority fees on Solana, how to set and implement them in your project, and send faster priority transactions using TypeScript. Estimate Priority Fees: Explore the getRecentPrioritizationFees method, its operational mechanics, and role in enhancing transaction efficiency by estimating Priority Fees. These topics offer a pathway for you as a developer to deepen your understanding of Solana's capabilities, addressing specific challenges and opportunities within the network's expansive ecosystem. Additionally, should you find yourself stuck in a rut, do refer to our Master Troubleshooting Guide for Solana developers that will show you how to tackle common errors you'd typically face while building. How to perform token swaps using the Raydium SDK Raydium is an automated market maker (AMM) and liquidity provider built on the Solana blockchain for the Serum decentralized exchange (DEX). The Raydium SDK offers a range of functionalities, including the ability to perform token swaps. Here's a simplified process from the full tutorial: Get a Solana node: Deploy a Solana node for free in minutes on Chainstack. Set up environment: Add your RPC endpoint and private key to a .env file. Installation: Clone the example repository locally and install the dependencies. Configuration: Set swap status, amount, tokens, and liquidity pool information. Confirmation: Upon a successful swap, you'll receive block confirmation details. // Sample swapConfig.ts setup snippet export const swapConfig = { executeSwap: false, // Send tx when true, simulate tx when false useVersionedTransaction: true, tokenAAmount: 0.01, // Swap 0.01 SOL for USDT in this example tokenAAddress: "So11111111111111111111111111111111111111112", // Token to swap for the other, SOL in this case tokenBAddress: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC address maxLamports: 1000000, // Max lamports allowed for fees direction: "in" as "in" | "out", // Swap direction: 'in' or 'out' liquidityFile: "<https://api.raydium.io/v2/sdk/liquidity/mainnet.json>", maxRetries: 10 }; Understanding how to integrate and interact with the Raydium SDK significantly widens the possibilities of what you as a developer can accomplish on the Solana network. How to transfer SPL Tokens in TypeScript Solana is known for its rapid and secure transaction capabilities, particularly for transferring SPL tokens that span digital currencies to various assets. It showcases the efficiency and flexibility of token transactions within Solana's ecosystem, highlighting the platform's strength in handling digital assets. This capacity is essential for developers and blockchain enthusiasts aiming to navigate and innovate within the expansive domain of blockchain technology. Here’s a snippet of the main function outlined in the dedicated TypeScript tutorial: // SPL token transfer script snippet // Main function orchestrates sending tokens by calling the defined functions in order. async function main() { console.log("Starting Token Transfer Process"); const connection = initializeConnection(); const fromKeypair = initializeKeypair(); // Address receiving the tokens const destinationWallet = new PublicKey( "CzNGm14nMopjGYyycMbWqEF2e1aEHcJLKk2CHw9BiZwC" ); // The SLP token being transferred, this is the address for USDC const mintAddress = new PublicKey( "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" ); // Config priority fee and amount to transfer const PRIORITY_RATE = 12345; // MICRO_LAMPORTS const transferAmount = 0.01; // Instruction to set the compute unit price for priority fee const PRIORITY_FEE_INSTRUCTIONS = ComputeBudgetProgram.setComputeUnitPrice({microLamports: PRIORITY_RATE}); console.log("----------------------------------------"); const decimals = await getNumberDecimals(mintAddress, connection); Understanding how to transfer SPL tokens lays crucial foundation for developers like yourself aiming to build DApps or systems involving Solana-based digital assets. How to improve SPL token transfers with retry logic Introduce a retry logic to enhance your SPL token transfers, addressing transient network issues or node overloads by automatically reattempting failed transactions. This boosts DApp resilience, reliability, and user experience, setting the stage for further performance enhancements. Following are several snippets from the full tutorial that you can use as template guidelines. How to wrap the transaction send logic in a retry loop // How to wrap the transaction send logic in a retry loop snippet const retryCount = Number(process.env.MAX_RETRY_FUNCTION); // Default retry count set to 5 for (let attempt = 1; attempt <= retryCount; attempt++) { try { // Transaction send logic goes here ... return;// Exit the function on a successful transaction } catch (error) { // Handle errors and retry logic ... } } How to handle different error types // How to handle different error types snippet catch (error) { console.error(`Attempt ${attempt} failed with error: ${error}`); if (attempt === retryCount) { // Last attempt failed, throw the error throw new Error(`Transaction failed after ${retryCount} attempts.`); } // Additional error handling or logging can be added here ... } How to implement a delay or backoff strategy between retries // How to implement a delay or backoff strategy between retries snippet // Wait for 2 seconds before retrying await new Promise((resolve) => setTimeout(resolve, 2000)); How to log or report retry attempts // How to log or report retry attempts snippet console.log(`Attempt ${attempt}: Starting Token Transfer Process`); ... console.error(`Attempt ${attempt} failed with error: ${error}`); Solana account retrieval methods In Solana development, efficient data retrieval is crucial. The getAccountInfo and getMultipleAccounts methods serve this need with distinct advantages. getAccountInfo offers a straightforward, precise approach for accessing individual account information with its public key, making it suitable for detailed account queries. On the other hand, getMultipleAccounts provides a bulk data retrieval option, enabling efficient data gathering for multiple accounts in one go, ideal for batch processing and complex tasks. Grasping the differences and applications of these methods is essential for you as a developer aiming to enhance performance and data management on Solana. Below are several examples from the full tutorial of how to use these methods in various scenarios. How to use getAccountInfo # How to use getAccountInfo snippet curl YOUR_CHAINSTACK_ENDPOINT -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "id": 1, "method": "getAccountInfo", "params": [ "Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz", { "encoding": "base58" } ] } ' How to use getMultipleAccounts # How to use getMultipleAccounts snippet curl --location 'CHAINSTACK_SOLANA_RPC' \\ --header 'Content-Type: application/json' \\ --data ' { "jsonrpc": "2.0", "id": 1, "method": "getMultipleAccounts", "params": [ [ "Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz", "EAaijviraKWCWsVZtiZ5thhXoyoB5RP3HH1ZiLeLDcuv" ], { "encoding": "base58" } ] } ' How to run the getMultipleAccounts method in JavaScript // How to run the getMultipleAccounts method in JavaScript snippet const { Connection, PublicKey } = require('@solana/web3.js'); async function fetchMultipleAccountsInfo() { // Initialize connection to the Solana endpoint const connection = new Connection('YOUR_CHAINSTACK_ENDPOINT'); // Array of public keys for multiple accounts const accountPublicKeys = [ new PublicKey('Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz'), new PublicKey('EAaijviraKWCWsVZtiZ5thhXoyoB5RP3HH1ZiLeLDcuv'), // Add more account public keys as needed ]; // Fetch information for multiple accounts const multipleAccountsInfo = await connection.getMultipleAccountsInfo(accountPublicKeys); // Process and display multiple accounts information console.log(multipleAccountsInfo); } fetchMultipleAccountsInfo().catch(error => { console.error('Error fetching multiple accounts info:', error); }); How to run the getMultipleAccounts method in Python # How to run the getMultipleAccounts method in Python snippet from solana.rpc.api import Client from solders.pubkey import Pubkey # Initialize connection to the Solana cluster solana_client = Client("YOUR_CHAINSTACK_ENDPOINT") # Array of public keys for multiple accounts public_keys = [ Pubkey.from_string("Hr5GK3f5WqqLsr4TJ7cgVCnDaM5gY8QrD2GTPZ7K3Kpz"), Pubkey.from_string("EAaijviraKWCWsVZtiZ5thhXoyoB5RP3HH1ZiLeLDcuv"), # Convert additional public keys to PublicKey objects as needed ] # Fetch information for multiple accounts multiple_accounts_info = solana_client.get_multiple_accounts(public_keys) # Process and display multiple accounts' information print(multiple_accounts_info) How to view top SPL holder distribution Exploring holder distribution of a particular SPL Token gives developers insight into the liquidity and market depth of that token. Next are a few examples from the full tutorial for you to explore top SPL holder distribution using Solana's JavaScript/TypeScript SDK. How to use the getTokenLargestAccounts RPC method # How to use the getTokenLargestAccounts RPC method snippet curl YOUR_CHAINSTACK_ENDPOINT -X POST -H "Content-Type: application/json" -d ' { "jsonrpc": "2.0", "id": 1, "method": "getTokenLargestAccounts", "params": [ "4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R", { "commitment": "finalized" } ] } ' How to integrate getTokenLargestAccounts into JavaScript // How to integrate getTokenLargestAccounts into JavaScript snippet const { Connection, PublicKey } = require('@solana/web3.js'); async function fetchTokenLargestAccounts() { const connection = new Connection('YOUR_CHAINSTACK_ENDPOINT'); const tokenMintPublicKey = new PublicKey('4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R'); const largestAccounts = await connection.getTokenLargestAccounts(tokenMintPublicKey, 'finalized'); console.log(largestAccounts); } fetchTokenLargestAccounts().catch(error => console.error('Error fetching token largest accounts:', error)); How to integrate getTokenLargestAccounts into Python # How to integrate getTokenLargestAccounts into Python snippet from solana.rpc.api import Client from solders.pubkey import Pubkey solana_client = Client("YOUR_CHAINSTACK_ENDPOINT") token_mint_public_key = Pubkey.from_string("4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R") largest_accounts = solana_client.get_token_largest_accounts(token_mint_public_key) # Display raw response #print(largest_accounts) # Display the information in a nicer format print("Largest SPL Token Accounts:\\n") # Accessing slot and api version slot = largest_accounts.context.slot api_version = getattr(largest_accounts.context, 'api_version', 'Unknown') # Print the data in a nice format print(f"Slot: {slot}\\nAPI Version: {api_version}\\n") for account in largest_accounts.value: address = account.address ui_amount = account.amount.ui_amount decimals = account.amount.decimals amount = account.amount.amount print(f"Address: {address}\\nAmount: {ui_amount} (Decimals: {decimals}, Raw: {amount})\\n") Analyzing top SPL holder distribution can provide useful insights into token usage and dissemination, crucial for strategic decision-making in the Solana ecosystem. How to use priority fees for faster transactions Solana supports priority fees to help increase the processing speed of a transaction. In simple terms, by paying a higher network fee, you can expedite the processing of your transaction. Find out how to programmatically set a priority fee for your Solana transactions with this snippet from the full tutorial: // Key components of sending Solana priority transactions // 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 ]; Remember, setting a higher fee does not always guarantee immediate processing, as the network might be congested with other high-fee transactions. How to estimate priority fees with getRecentPrioritizationFees Solana’s getRecentPrioritizationFees method offers developers current insights into prioritization fees. This allows you to understand the fees associated with successful transactions and dynamically estimate the priority fee for your transactions. How to use the getRecentPrioritizationFees RPC method # How to use the **getRecentPrioritizationFees** RPC method snippet curl --request POST \\ --url YOUR_SOLANA_ENDPOINT \\ --header 'accept: application/json' \\ --header 'content-type: application/json' \\ --data ' { "id": 1, "jsonrpc": "2.0", "method": "getRecentPrioritizationFees", "params": [ [ "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4" ] ] } ' How to integrate getRecentPrioritizationFees in JavaScript // How to integrate getRecentPrioritizationFees in JavaScript snippet 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); } }; Sending Solana transactions using solana/web3.js Solana's JavaScript API, solana/web3.js, provides a simple and efficient way to create and submit transactions to the Solana network. Here's a quick walkthrough from the full recipe: Initial setup: Install node.js if you haven’t done so already, as well as thesolana/web3.js and bs58 libraries. Set up two accounts: Create one using a private key and generate another on the fly to be a fresh recipient. Create a transfer function: Draft an async function to transfer Lamports from the first to the second account. Run your script: Execute your code to send your transaction between the two accounts you’ve chosen earlier. // How to send Solana transactions using @solana-web3.js recipe const web3 = require("@solana/web3.js"); const bs58 = require("bs58"); const connection = new web3.Connection('YOUR_CHAINSTACK_ENDPOINT'); const privateKey = new Uint8Array(bs58.decode('YOUR_PRIVATE_KEY')); const account = web3.Keypair.fromSecretKey(privateKey); const account2 = web3.Keypair.generate(); (async () => { const transaction = new web3.Transaction().add( web3.SystemProgram.transfer({ fromPubkey: account.publicKey, toPubkey: account2.publicKey, lamports: web3.LAMPORTS_PER_SOL * 0.001, }), ); const signature = await web3.sendAndConfirmTransaction( connection, transaction, [account], ); })(); It's important to listen for transaction confirmation to determine whether it worked as expected. Solana/web3.js makes this simple with transaction confirmation utilities. Minting SPL tokens with solana-web3.js SPL tokens represent digital assets and are minted using the Token Program on the Solana blockchain. The solana/web3.js JavaScript API makes creating new tokens easy. Here's a concise step-by-step guide extracted from the full recipe: Initial setup: Install the @solana/web3.js, @solana/spl-token, and bs58 packages. Connect to Solana: Pass your Chainstack endpoint using the connection variable. Create or import wallet: Create a fresh account with solanaWeb3.Keypair.generate() or import one via solanaWeb3.Keypair.fromSecretKey() Draft the script: Use the splToken.createMint method to pass the parameters needed to prepare for the mint. Create token account: Use the getOrCreateAssociatedTokenAccount function to make a corresponding token account for your SPL token. Mint your tokens: Take the mint and tokenAccount objects, in order to call the mintTo function to mint your SPL tokens. // How to mint SPL tokens with @solana-web3.js recipe const solanaWeb3 = require('@solana/web3.js'); const splToken = require('@solana/spl-token'); const bs58 = require("bs58"); async function main() { const connection = new solanaWeb3.Connection("CHAINSTACK_HTTPS_ENDPOINT", {wsEndpoint:"CHAINSTACK_WSS_ENDPOINT"}); const walletKeyPair = solanaWeb3.Keypair.fromSecretKey(new Uint8Array(bs58.decode(process.env.PRIVATE_KEY))); const mint = await splToken.createMint( connection, walletKeyPair, walletKeyPair.publicKey, null, 9, undefined, {}, splToken.TOKEN_PROGRAM_ID, ); const tokenAccount = await splToken.getOrCreateAssociatedTokenAccount( connection, walletKeyPair, mint, walletKeyPair.publicKey, ); await splToken.mintTo( connection, walletKeyPair, mint, tokenAccount.address, walletKeyPair.publicKey, 1000000000000, ) Further reading Expand your Solana knowledge and skills with these comprehensive Chainstack resources: Troubleshooting common Solana errors master guide: Learn how to tackle common Solana errors like Rust version conflicts, Borsh serialization issues, blockstore errors, and more. Mastering Solana series: Explore Solana essentials like token swaps with Raydium SDK, SPL token transfers, account retrieval methods, and getTokenLargestAccounts RPC insights. Solana-web3.js Tutorial: Learn how to use the solana-web3.js method in just 7 minutes to mint an SPL token, transfer tokens, and delegate tokens. Querying and analyzing Solana data from Raydium with Python: Learn about Raydium, a leading DEX on Solana, and explore how DeFi enables token exchanges across chains and fiat. Powerful Chainstack infrastructure optimized for Solana: Run high-performing Solana RPC nodes and APIs in minutes on a platform built for scale with Chainstack. How to run a Solana RPC node: Learn how to run your Solana RPC node instance on Chainstack, connected to the mainnet beta and complete with metric monitoring. Solana tool suite: Learn how to interact with your Chainstack Solana node and develop DApps. Solana glossary: Get a better understanding of key Solana terminology and its definitions. Bringing it all together Solana, as a high-performance, open-source project, presents a broad spectrum of opportunities for developers willing to leverage blockchain for their applications. From understanding its key components, such as accounts and transaction architecture, to getting hands-on with coding using various SDKs, and implementing token swaps, the mastering guides on Solana offer deep insights and practical knowledge. With this extensive overview, we aimed to unveil the attributes of one of the fastest blockchain networks available today. The journey we undertook covers discovering its unique features, understanding Solana's native programs, exploring its developer workflows, and even delving into its token economics. While we immerse ourselves in what Solana has to offer, remember that Web3 is rapidly evolving, and so is Solana. The platform consistently introduces novel features and improvements, providing developers with an even more robust foundation for creating decentralized applications and pushing the boundaries of what's possible with blockchain technology. Power-boost your project on Chainstack #### The Web3 developer's EVM Swiss Army Knife At Chainstack we aim to provide Web3 developers with all the tools that they need in order to build their DApps. Being builders ourselves, we felt the need to put all the useful tools that a Web3 developer uses, under one roof. This is how we came about making what we like to call the EVM Swiss Army Knife. What is the EVM Swiss Army Knife It is a suite of mini-tools built for Ethereum Virtual Machine (EVM) developers. It is composed of smart contract event tools, Solidity calldata tools, Converters & more. You can find a brief description of each tool below, along with a link to it, so that you can jump ahead and use it. Smart contract event tools Generate event signature tool An event signature is a unique identifier for a specific event emitted by a smart contract on the blockchain. These signatures are generated using a formula that takes into account the event name and its emitted data types. Generate event Specifically, the event signature is produced by hashing the event's name and parameter types with Keccak-256. Encode event topics tool An event topic is a 32-byte representation of an event parameter. Encode a topic to use it to retrieve logs when querying your Chainstack node. Encode topics Learn how to retrieve event logs using the eth_getLogs method on the Chainstack developer portal. Solidity calldata tools Generate Solidity functions signature tool In Web3 and Solidity, calldata refers to the input data that is sent along a transaction when an account is interacting with a smart contract and calling its functions. The first 4 bytes of calldata represent the function's signature. Generate function Learn how the encoding process work following the How to encode calldata parameters to programmatically interact with a smart contract recipe on the Chainstack developer portal. Encode calldata parameters Parameters passed to the function in calldata are represented as 32 bytes of data. Encode calldata Learn how the encoding process work following the How to encode calldata parameters to programmatically interact with a smart contract recipe in the Chainstack developer portal. Smart contract source code and ABI tool Input a smart contract address to retrieve its source code and ABI. Note that the contract must be verified. Fetch source and ABI Find an example of a verified smart contract on Etherscan. Conversion tools Decimal, Hex, and Ethereum Units conversion tools Decimal to Hex Hex to Decimal Ethereum Units Keccak-256 hashing tool Keccak-256 is a cryptographic hash function that generates a unique, fixed-size string of bytes for each unique input it receives. This feature makes it useful for ensuring data integrity, as any change in the input data leads to a different hash output. It's virtually impossible to derive the original input from the hash output, making it a one-way function. Hash Keccak-256 Find a list of examples where Keccak-256 is used in the Chainstack developer portal. Checksum address tool A checksummed address is a standard Ethereum address with certain characters capitalized to include a checksum validation. Checksumming is a way of having error-detection codes in an Ethereum address. Checksumming aims to prevent errors when an address is typed manually. Checksum address Find more about checksum in Ethereum in the Chainstack developer portal. ENS to address conversion tool Convert an ENS name to an Ethereum address. ENS to address Input the name with or without the .eth extension. Power-boost your project with Chainstack #### Tips to handle RPC request errors A very common scenario that our users have asked us to help with, is handling errors when sending RPC requests to their nodes. In Chainstack, we offer tailored load balancing in the enterprise plan but not all users and projects can opt for that so we've decided to share some examples that you can apply at the application level in order to handle errors with RPC requests. The problem When sending RPC requests to a non-balanced blockchain node, it's possible that some of them fail or timeout. Although this is a rare scenario, this can have a big impact on some applications like arbitrage bots. On our Enterprise subscription, all requests go through a Chainstack Load Balancer which makes sure that they hit a live node, however, other plans do not have load balancing enabled so handling these errors must be done at the application level. Note: in order to test this, I created a few code snippets that send sequential RPC requests and use all the solutions provided below. You can find all the code examples in the following GitHub repository. In addition, most of the RPC requests shown below are for EVM-based blockchain nodes, although you can adapt most of these solutions to work with any API request or asynchronous methods. Duplicate requests and use promises One of the ways to handle this is to send the same request multiple times by using two ethers providers, each one with a different RPC endpoint. Then we can use multiple JavaScript Promise methods to handle the promises. Promise.all The first thing we need is a wrapper method that receives the RPC request promise and catches any errors. /** * @param {*} promise An RPC request promise to be resolved * @param {*} origin URL of the node * @returns resolved promise */ async function wrapRPCPromise(promise, origin) { try { const data = await promise return { result: data, origin } } catch (error) { console.error('Error running method') return new Error('Ops, there was an issue') } } We can use Promise.all() to wait until all requests have finished and their correspondent promises fulfilled or rejected. In the example below, we're forcing an error in the mainProvider after the first RPC request. let mainProvider = new ethers.providers.JsonRpcProvider(DEDICATED_NODE_RPC) const backupProvider = new ethers.providers.JsonRpcProvider(BACKUP_NODE_RPC) let prom1, prom2, res1, res2 prom1 = wrapRPCPromise( mainProvider.getBlockNumber(), mainProvider.connection.url ) prom2 = wrapRPCPromise( backupProvider.getBlockNumber(), backupProvider.connection.url ) try { res1 = await Promise.all([prom1, prom2]) } catch (err) { console.error(err) } console.log('getBlockNumber responses: ', res1) // force an error mainProvider = new ethers.providers.JsonRpcProvider( 'https://bad-rpc-endpoint/12345' ) prom1 = wrapRPCPromise(mainProvider.getFeeData(), mainProvider.connection.url) prom2 = wrapRPCPromise( backupProvider.getFeeData(), backupProvider.connection.url ) try { res2 = await Promise.all([prom2, prom1]) } catch (err) { console.error(err) } console.log('getFeeData responses:', res2) By catching errors in the wrapRPCPromise method, Promise.all will not fail and we will get a valid response in the returned array from one of the providers. This is a good first approach but it has its drawbacks: we're duplicating requests and we have to manually check which of the providers (or which of the promises) returned a valid response. In addition, Promise.all will wait until all promises are fulfilled/rejected so we'll not get the benefit of a faster response from one of the nodes. You can find the code sample here. Promise.race One of the solutions we've seen some of our clients use (shoutout to Novel team), is using Promise.race, which will continue as soon as one of the promises is fulfilled or gets rejected. let mainProvider = new ethers.providers.JsonRpcProvider(DEDICATED_NODE_RPC) const backupProvider = new ethers.providers.JsonRpcProvider(BACKUP_NODE_RPC) let prom1, prom2, res1 prom1 = wrapRPCPromise( mainProvider.getBlockNumber(), mainProvider.connection.url ) prom2 = wrapRPCPromise( backupProvider.getBlockNumber(), backupProvider.connection.url ) try { res1 = await Promise.race([prom1, prom2]) } catch (err) { console.error(err) } console.log('getBlockNumber response: ', res1) // force an error mainProvider = new ethers.providers.JsonRpcProvider( 'https://bad-rpc-endpoint/12345' ) prom1 = wrapRPCPromise(mainProvider.getFeeData(), mainProvider.connection.url) prom2 = wrapRPCPromise( backupProvider.getFeeData(), backupProvider.connection.url ) try { res2 = await Promise.race([prom2, prom1]) } catch (err) { console.error(err) } console.log('getFeeData responses:', res2) This makes this solution faster but at the same time, that's its drawback. If one of the requests fails before the other one succeeds, the result we'll get will be the error returned 😕 You can find the code sample here. Promise.any Finally, with Promise.any we get the best of both. It'll return a single promise that resolves as soon as any of the promises is fulfilled, ignoring the errors. The only thing we have to change is the wrapRPCPromise method to actually reject when there is an issue. let mainProvider = new ethers.providers.JsonRpcProvider(DEDICATED_NODE_RPC) const backupProvider = new ethers.providers.JsonRpcProvider(BACKUP_NODE_RPC) let prom1, prom2, res1 prom1 = wrapRPCPromiseWithReject( mainProvider.getBlockNumber(), mainProvider.connection.url ) prom2 = wrapRPCPromiseWithReject( backupProvider.getBlockNumber(), backupProvider.connection.url ) try { res1 = await Promise.any([prom1, prom2]) } catch (err) { console.error(err) } console.log('getBlockNumber response: ', res1) // force an error mainProvider = new ethers.providers.JsonRpcProvider( 'https://bad-rpc-endpoint/12345' ) prom1 = wrapRPCPromise(mainProvider.getFeeData(), mainProvider.connection.url) prom2 = wrapRPCPromise( backupProvider.getFeeData(), backupProvider.connection.url ) try { res2 = await Promise.any([prom2, prom1]) } catch (err) { console.error(err) } console.log('getFeeData responses:', res2) The catch? Promise.any was added in Node v15, so you have to make sure you're running one of the latest versions. You can find the code sample here. Retrying with a function wrapper Another option is to simply retry the same RPC request whenever it fails, using the same endpoint and provider. To do this, we need to create a different wrapper function that receives the RPC request promise and the number of retries. If the promise is fulfilled, it'll simply return the response but if it fails, it'll reduce the counter of retries left and call the same method recursively. Find below the retryRPCPromise method: /** * @param promise An RPC request promise to be resolved * @retriesLeft Number of tries before rejecting * @returns resolved promise */ async function retryRPCPromise(promise, retriesLeft) { try { // try to resolve the promise const data = await promise // if resolved simply return the result return data } catch (error) { // if no retries left, return error if (retriesLeft === 0) { return Promise.reject(error) } console.log(`${retriesLeft} retries left`) // if there are retries left, reduce counter and // call same function recursively return retryPromise(promise, retriesLeft - 1) } } You can check the code snippet that uses this wrapper function here. Retry wrapper with delay A variation of the previous solution is to add a delay between each retry. We can do this by adding a wait() method that leverages the setTimeout() function and calls it before each retry. Here are the wait and wrapper methods: /** * @param ms miliseconds to wait * @returns empty promise after delay */ function wait(ms) { return new Promise((resolve, reject) => { setTimeout(() => { resolve() }, ms) }) } /** * @param promise An RPC method promise to be resolved * @retriesLeft Number of tries before rejecting * @returns resolved promise */ async function retryRPCPromiseWithDelay(promise, retriesLeft, delay) { try { // try to resolve the promise const data = await promise // if resolved simply return the result return data } catch (error) { // if no retries left, return error if (retriesLeft === 0) { return Promise.reject(error) } // if there are retries left, reduce counter and // call same function recursively console.log(`${retriesLeft} retries left`) // wait for delay await wait(delay) // following retries after 1000ms return retryRPCPromiseWithDelay(promise, retriesLeft - 1, 1000) } } Retrying with a backup provider Although the solutions detailed above are a good way to handle this, they all have their drawbacks: the Promise methods target multiple endpoints to increase the chances of one of them being up, but they send the same request multiple times, which is not ideal. With retries, we're sending single requests but we're targeting the same endpoint, so, if the node is down, all retries will fail. The ideal solution will be to send a single RPC request and, if it fails, send the request to a different endpoint. We could do something like this: const { ethers } = require('ethers') let mainProvider = new ethers.providers.JsonRpcProvider(DEDICATED_NODE_RPC) const backupProvider = new ethers.providers.JsonRpcProvider(BACKUP_NODE_RPC) const main = async () => { try { // let res1, res2, res3 try { res1 = await mainProvider.getBlockNumber() } catch (error) { console.error('Main provider failed') res1 = await backupProvider.getBlockNumber() } console.log('getBlockNumber response: ', res1) // force an error mainProvider = new ethers.providers.JsonRpcProvider( 'https://bad-rpc-endpoint/12345' ) try { res2 = await mainProvider.getGasPrice() } catch (error) { console.error('Main provider failed') res2 = await backupProvider.getGasPrice() } console.log('getGasPrice response: ', res2) // fix provider mainProvider = new ethers.providers.JsonRpcProvider(DEDICATED_NODE_RPC) try { res3 = await mainProvider.getNetwork() } catch (error) { console.error('Main provider failed') res3 = await backupProvider.getNetwork() } console.log('getNetwork response: ', res3) } catch (err) { console.error(err) } } main() With this approach we're wrapping each request in a try/catch and, if it fails, we're sending the same request again via the backup provider, which uses a different RPC endpoint. You can find this code sample here. Retry with backup provider for smart contract methods The previous solution is valid for general blockchain methods like getBlockNumber or getGassPrice but if we want to target smart contract methods, we'd need a more generic wrapper. Check out the example below: // list of all available RPC endpoints const allRPCs = [BAD_RPC, DEDICATED_NODE_RPC, BACKUP_NODE_RPC] /** * * @param {*} contractAddress blockchain address of the smart contract * @param {*} abi smart contract JSON ABI * @param {*} rpc RPC endpoint * @returns a contract instance to execute methods */ function initContractRef(contractAddress, abi, rpc) { // init provider const provider = new ethers.providers.JsonRpcProvider(rpc) // init contract const contract = new ethers.Contract(contractAddress, abi, provider) return contract } /** * * @param {*} contractAddress blockchain address of the smart contract * @param {*} abi smart contract JSON ABI * @param {*} methodName name of the smart contract method to run * @param {*} params parameters required for the smart contract method * @param {*} tryNumber default to 0. Each retry adds one, which uses a different RPC endpoint * @returns */ async function wrapContratMethodWithRetries( contractAddress, abi, methodName, params, tryNumber = 0 ) { try { let contract, data console.log(`Running contract method via ${allRPCs[tryNumber]}`) // initialise smart contract reference with a new rpc endpoint contract = initContractRef(contractAddress, abi, allRPCs[tryNumber]) // execute smart contract method data = await contract[methodName](...params) return data } catch (error) { if (tryNumber > allRPCs.length - 1) { return Promise.reject(error) } console.error('Error in contract method, retrying with different RPC') return wrapContratMethodWithRetries( contractAddress, abi, methodName, params, tryNumber + 1 ) } } This method takes care of retries using a different provider for each. Let's review it step-by-step: We have a list of available RPC endpoints that the wrapContratMethodWithRetries method will use for each try. The wrapContratMethodWithRetries method receives the following parameters (which are very self-explanatory): contract address, contract ABI, the name of the smart contract method we want to run, the parameters required, and the retry number, which defaults to 0. The first thing it does is create a smart contract instance using the utility function initContractRef, which receives the contract address, the ABI, and the RPC endpoint, which is passed using the retry number as the index of the array. Next, it tries to execute the smart contract method. If everything works, it returns the data but if it fails... On error, it checks if we've already tried all RPC endpoints, and in that case, it'll just return the error. If it can still try different endpoints, it calls itself recursively with the same parameters, only increasing the retry counter. Then here is an example to actually invoke this method: const { wrapContratMethodWithRetries } = require('./wrappers') // USDC smart contract address const USDC_CONTRACT_ADDR = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' const USDC_ABI = require('./erc20.abi.json') const main = async () => { try { const contractMethod = 'balanceOf' // enter a valid wallet address here const methodParams = ['0x1234567890123456789012345678901234567890'] let res try { res = await wrapContratMethodWithRetries( USDC_CONTRACT_ADDR, USDC_ABI, contractMethod, methodParams ) } catch (error) { console.error('Unable to run contract method via any RPC endpoints') } console.log('contract method response is: ', res.toNumber()) } catch (err) { console.error('ERROR') console.error(err) } } main() If we want to execute payable transactions, we could modify the wrapContratMethodWithRetries and initContractRef to use an ethers' signer and receive the amount of ETH to send. You can find this code sample here, Conclusion There is a lot of different ways to handle this and all the solutions above have some pros and cons. Now is up to you to decide which one works best for your project. Oh! and if you have a better solution, feel free to send me a Twitter DM and I'll include it in this article 🤙 Credits: MDN Promise documentation tusharsharma.dev for this article Start building your project on Chainstack #### Token metadata on Solana: from convention to data In the previous post, we examined how the SPL Token program models fungible assets on Solana using accounts, authorities, and runtime enforcement. One important question was left intentionally unanswered: Where does token metadata live, and how does the runtime know how to find it? On Solana, accounts do not carry intrinsic meaning. They are byte arrays interpreted by programs. Any relationship between accounts must be explicitly encoded, derived, or conventionally agreed upon. Token metadata is a perfect example of this design tension. Early Solana token designs relied on well-known conventions such as Program-Derived Addresses, to associate metadata with a mint. This approach worked, but it also introduced implicit assumptions that the runtime itself does not enforce. In this post, we’ll examine how token metadata on Solana is modeled, why it was originally externalized into separate accounts, and why newer designs are moving toward explicit, data-driven references instead of convention. The goal is not to describe a specific framework, but to understand the architectural trade-offs behind where token meaning lives on-chain. Accounts do not carry meaning At the runtime level, an account on Solana is nothing more than a byte array with an owner, lamports, and a data length. The runtime does not interpret that data, validate its structure, or attach any semantic meaning to it. There is no native concept of: a token a balance metadata ownership semantics All of that meaning is introduced entirely by programs. This distinction is easy to miss because most developers interact with Solana through SDKs and frameworks that present a much richer mental model. A “Mint account” feels like a first-class object. A “Token Account” feels like a balance record. But those are program-level interpretations, not runtime primitives. From the runtime’s perspective: an SPL Token mint account is just an account owned by the SPL Token Program a token account is just another account owned by the same program the relationship between them is not enforced globally The runtime does not know that a token account “belongs” to a mint.It only enforces that the owning program is the one allowed to read and mutate the data. This is a crucial property of Solana’s design: Meaning is not intrinsic. It is contextual. Every invariant you rely on: total supply, balances, authorities, decimals, exists only because a specific program chooses to enforce it when invoked. The same principle applies to metadata. There is nothing in the runtime that says: “this account contains metadata” “this metadata describes that mint” “this metadata must exist” Those are assumptions layered on top of the account model. Why token metadata started outside the mint Given this model, the natural question is: Why wasn’t metadata stored directly inside the mint account from the beginning? The answer is not ideological, it is structural. Early SPL Token mint accounts had: a fixed layout a fixed size no mechanism for optional or extensible fields Once a mint was created, its data layout was effectively frozen.There was no safe way to append arbitrary information without breaking compatibility. At the same time, metadata had very different requirements from the core token state: variable-length fields: names, symbols and URIs evolving schemas different authority rules different lifecycle expectations Putting metadata into the mint would have tightly coupled all of that complexity to the token program itself. Instead, Solana developers leaned on one of the runtime’s strongest primitives: Program-Derived Addresses (PDAs). A metadata account could be: deterministically derived from the mint address owned by a separate program versioned independently optional This led to the now-familiar pattern: The mint account contains only core token state, lives in a separate program-owned account and the relationship between them is defined by a derivation rule, Crucially, this relationship is not enforced by the runtime. All of those guarantees exist only because clients and programs agree to look in the same place. Metadata as data, introduction to Metaplex Once metadata was separated from the mint, the ecosystem needed more than an informal pattern. It needed a shared interpretation layer something that could describe what metadata looks like, who can update it, and how clients should reason about it. This is the role played by Metaplex. Metaplex does not change how tokens work at the runtime level. It does not introduce a new asset type, nor does it modify the SPL Token program. Instead, it introduces a dedicated program whose only responsibility is to interpret metadata stored in accounts. That program, the Metaplex Token Metadata Program, formalizes a simple but powerful idea: a token’s human-meaningful description should live in a separate account, owned and governed independently from the token’s supply and balances. The relationship between a mint and its metadata is established through a deterministic derivation rule. Given a mint address, the metadata account can be derived as a Program-Derived Address using a fixed seed and the metadata program ID. This makes the relationship predictable without embedding any metadata logic into the token program itself. The metadata account contains structured fields such as the token’s name, symbol, URI, and update authority. From the token program’s point of view, none of this exists. From Metaplex’s point of view, this is the authoritative description of what the token represents. Note: Metaplex’s seeds can be found here Example Lets mint a new token and deploy the Metadata for this token, this example assumes you read the previous blog post and understand whats going on, Token minting: spl-token create-token --decimals 9 Token account creation: spl-token create-account H3NmgE4YBxzkNY94vV7z6UpHQaWse7VhQeYYrnHr3g5D Minting tokens to the created account: spl-token mint H3NmgE4YBxzkNY94vV7z6UpHQaWse7VhQeYYrnHr3g5D 1000 Metadata creation: import { createMetadataAccountV3 } from "@metaplex-foundation/mpl-token-metadata"; import { createUmi } from "@metaplex-foundation/umi-bundle-defaults"; import { keypairIdentity, createSignerFromKeypair } from "@metaplex-foundation/umi"; import { publicKey } from "@metaplex-foundation/umi-public-keys"; import * as fs from "fs"; import * as os from "os"; import * as path from "path"; const keypairPath = path.join(os.homedir(), ".config", "solana", "id.json"); const secretKey = JSON.parse(fs.readFileSync(keypairPath, "utf8")); const mint = "H3NmgE4YBxzkNY94vV7z6UpHQaWse7VhQeYYrnHr3g5D"; async function main() { // Create UMI instance const umi = createUmi("https://api.devnet.solana.com"); // Set up the keypair identity const keypair = umi.eddsa.createKeypairFromSecretKey( new Uint8Array(secretKey) ); umi.use(keypairIdentity(keypair)); // Create signer from keypair const mintAuthoritySigner = createSignerFromKeypair(umi, keypair); // Create metadata account const tx = createMetadataAccountV3(umi, { mint: publicKey(mint), mintAuthority: mintAuthoritySigner, data: { name: "Example Token", symbol: "EXMPL", uri: "https://example.com/metadata.json", sellerFeeBasisPoints: 0, creators: null, collection: null, uses: null, }, isMutable: true, collectionDetails: null, }); const signature = await tx.sendAndConfirm(umi); console.log("Transaction signature:", signature); } main().catch((error) => { console.error("Error:", error); process.exit(1); }); This code created this account: https://solscan.io/tx/5Zu5v2Hicwi4UuutHK6XEah6hc1FXRvSG71zdhoqdq2BotjBvonPMBfEp1TK8CAyfn85G6kRdx4viJrLe32PuB3B?cluster=devnet To read the Metadata of the token we can use this code: import { createUmi } from "@metaplex-foundation/umi-bundle-defaults"; import { publicKey } from "@metaplex-foundation/umi-public-keys"; import { fetchDigitalAsset } from "@metaplex-foundation/mpl-token-metadata"; const MINT_ADDRESS = "H3NmgE4YBxzkNY94vV7z6UpHQaWse7VhQeYYrnHr3g5D"; const RPC_URL = "https://api.devnet.solana.com"; async function main() { console.log("Checking metadata for mint:", MINT_ADDRESS); // Create UMI instance const umi = createUmi(RPC_URL); try { // Fetch the digital asset (mint + metadata + edition info) const mint = publicKey(MINT_ADDRESS); const digitalAsset = await fetchDigitalAsset(umi, mint); const metadata = digitalAsset.metadata; console.log("\nMetadata found!"); console.log("\nToken Metadata:"); console.log("─".repeat(50)); console.log("Name: ", metadata.name); console.log("Symbol: ", metadata.symbol); console.log("URI: ", metadata.uri); console.log("Seller Fee (bps): ", metadata.sellerFeeBasisPoints); console.log("Is Mutable: ", metadata.isMutable); console.log("Update Authority: ", metadata.updateAuthority); console.log("\n Mint Info:"); console.log("Mint Address: ", digitalAsset.mint.publicKey); console.log("Decimals: ", digitalAsset.mint.decimals); console.log("Supply: ", digitalAsset.mint.supply); console.log("Mint Authority: ", digitalAsset.mint.mintAuthority); console.log("Freeze Authority: ", digitalAsset.mint.freezeAuthority); } catch (error) { if (error.message?.includes("Account Not Found")) { console.log("\n No metadata found for this token mint"); console.log("The token exists but doesn't have metadata associated with it yet"); console.log("Use metadata.ts to create metadata for this token"); } else { throw error; } } } main().catch((error) => { console.error("Error:", error); process.exit(1); }); Output: The hidden cost of convention The Metaplex model worked and still works because it created a shared convention across the ecosystem. Wallets, marketplaces, indexers, and SDKs all agree on where metadata lives and how to interpret it. But that agreement exists outside the protocol. The Solana runtime does not enforce the relationship between a mint and its metadata. A mint does not contain a reference to its metadata account. The metadata account does not declare which mint it describes. The link exists only because every participant in the ecosystem already knows how to derive it. This means correctness depends on shared knowledge rather than explicit state. If metadata is missing, nothing fails at the protocol level. If metadata is malformed, the runtime does not object. If a token chooses to store metadata somewhere else, the chain does not prevent it. These are all valid states from Solana’s point of view. The cost of this design is not immediately visible in happy paths. It appears at the boundaries: when programs disagree, when tooling makes assumptions, or when new use cases stretch old conventions. At that point, the chain cannot help you. There is no on-chain way to verify that “this account is the metadata for that mint” unless every program involved already agrees on the same rules. Summary Token metadata on Solana has always existed outside the runtime’s understanding of token relationships. The difference between early designs is not what metadata contains, but how its location and association are communicated. Convention-based designs rely on shared assumptions between programs and tooling. The Metaplex Token Metadata program standardized those assumptions, but did not make them part of the runtime’s enforcement. This creates a clear boundary between what the protocol enforces and what the ecosystem agrees upon. In the next post, we’ll examine how newer token program designs move beyond convention, and what it means to make token relationships explicit rather than assumed. 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 Where token metadata lives on Solana 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. #### Token standards introduction: ERC-20, ERC-777, ERC-721, and ERC-1155 Introduction With the rise in popularity of blockchain technologies and cryptocurrencies, we are seeing many more tokens being created. But what are they, exactly? This post will go over some of the most common types of crypto tokens: ERC-20, ERC-777, ERC-721, and ERC-1155. What are tokens? Tokens are digital assets built on a cryptocurrency’s blockchain. They differ from coins because while a coin is built on its native blockchain, a token is built on an existing blockchain. For example, ETH is the official coin for the Ethereum blockchain, while Basic Attention Token (BAT), Chainlink (LINK), or OmiseGo (OMG) are tokens built on Ethereum. Tokens are often a quicker way to leverage the existing standards of a successful and popular blockchain while building digital assets. Their most common use case is smart contracts on decentralized applications (DApps). Difference between fungible and non-fungible tokens Tokens generally fall under two categories: fungible tokens and non-fungible tokens. Fungible tokens are divisible digital assets that you can swap for other assets of the same type. No single unit is worth more or less than another. Think about how a dollar bill is similar to another one and can be easily exchanged. On the other hand, non-fungible tokens (also known as NFTs) are digital assets that you cannot easily exchange for other assets due to their uniqueness. For example, consider an artwork that holds a particular value for its owner and would be difficult to exchange for another artwork because their perceived values are different. What are token standards? ERCs and EIPs Before the adoption of token standards, blockchain developers often created tokens according to personal preferences, causing token ecosystems to experience difficulties when interacting with each other and limiting interoperability. To solve this problem, Ethereum developers now create ERCs (Ethereum Request for Comments) and EIPs (Ethereum Improvement Proposals). These help to define the rules and required functions for tokens created on the Ethereum blockchain, making integrations and interactions much more accessible. What are ERC-20 tokens? ERC-20 is a protocol that defines standard APIs for creating fungible tokens in a smart contract. It was created in 2015 by Fabian Vogelsteller. Its main methods include: name() (optional): The name of the token. symbol() (optional): The symbol of the token. decimals() (optional): The decimal places of the token. This allows for fungibility. totalSupply(): The total number of existing tokens. balanceOf(): The total number of tokens owned by a particular account. transfer(): Moves a number of tokens from the caller’s account to a specified address. transferFrom(): Same as transfer(), but it also specifies the address to move tokens from. allowance(): The number of tokens a spender is allowed to spend on behalf of the owner via transferFrom(). approve(): Sets the number of tokens a spender is allowed to spend. All these methods are strictly required in an ERC-20 smart contract, apart from the first three marked (optional) which help to improve usability. An ERC-20 also has two events—Transfer (which triggers when tokens are transferred) and Approved (which triggers on any successful call to the approve() method). Examples of ERC-20 tokens are USDC, a stablecoin pegged to the dollar, or UNI, the governance token used in Uniswap to vote on changes on the platform. Many projects use ERC-20 tokens during their fundraising period (known as ICO - Initial Coin Offering). They are also widely used for trading purposes—some exchanges only support trading in tokens that adhere to this standard due to their popularity among investors and traders. What are ERC-777 tokens? The ERC-777 standard offers improvements in how users interact with fungible tokens in a smart contract while remaining backward compatible with ERC-20. It was created in 2017 by Jacques Dafflon, Jordi Baylina, and Thomas Shabibi. Some of its improvements include clearing the confusion around decimals in a smart contract and introducing hooks that allow your smart contract to react when you send or receive tokens. These help to prevent tokens from getting locked forever or lost when sent to the wrong address. ERC-777 contains methods like: granularity(): The smallest part of the token that is not divisible. send(): Sends a specific amount of tokens to a recipient burn(): Destroys a specific amount of tokens, which reduces the totalSupply. isOperatorFor(): Checks if an account is an operator. authorizeOperator(): Makes an account an operator. revokeOperator(): Revokes an account's operator status. defaultOperators(): Returns a list of token holders who are default operators. tokensToSend(): This hook is called when tokens are about to be destroyed or moved from a specific holder's address. It is triggered before the smart contract's state is updated and can prevent the operation from being executed. tokensReceived(): This hook is called when tokens are about to be destroyed or moved to a specific holder's address. It is triggered after the smart contract's state is updated, which can prevent the operation from being executed. What are ERC-721 tokens? ERC-721 is a standard for creating non-fungible tokens (NFTs) on Ethereum. It was created in 2018 by Dieter Shirley, Jacob Evans, Natassia Sachs, and William Entriken. A few examples include rare collectibles (e.g., CryptoKitties and Gods Unchained), or limited edition items like sneakers and art prints. They can also signify membership in a community, like Developer DAO. A basic ERC-721 smart contract contains methods like: balanceOf(): The number of tokens in the owner's account. ownerOf(): The tokenId of the owner. safeTransferFrom(): Safely transfers tokens from the owner's address to the recipient’s. The tokenId must be specified as a parameter. transferFrom(): Same function as safeTransferFrom(), but generally not recommended. approve(): Allows an address to transfer a token identified by its tokenId, into another account. It triggers the Approval event. setApprovalForAll(): Allows an operator to call safeTransferFrom or transferFrom for any token owned by the caller. getApproved(): Gets the approved account for a specific tokenId. isApprovedForAll(): Checks if an operator is allowed to manage all the assets of the owner. It also contains events like Transfer (which triggers when ownership of any NFT changes) and Approval (which activates when the approved address for an NFT is changed). ERC-721 has multiple extensions split across different contracts. Here are two such extensions. What are ERC721Enumerable? The ERC721Enumerable contains all the methods available in the original ERC721 and three extra methods: totalSupply(): The total amount of tokens in the contract. tokenOfOwnerByIndex(): The tokenId of an owner’s address at a given index in its token list. You can use it with balanceOf to enumerate all of the owner's tokens. tokenByIndex(): The tokenId at a given index. You can use it with totalSupply to enumerate all tokens. This extension is often not implemented because enumerating tokens on the blockchain could significantly spike gas costs. What is ERC721A? ERC721A is an extension of ERC-721 that aims to significantly reduce transaction fees by allowing users to mint multiple unique NFTs in a single transaction. It was created by the Azuki team in 2022 and is currently used by projects like Dastardly Ducks and Zero Gravity Club. In addition to the original ERC721 methods, it contains extra methods like: _startTokenId(): The starting token ID. _nextTokenId(): The next token ID to be minted. _totalMinted(): The total amount of minted tokens. _numberMinted(): The number of tokens minted by an owner. _getAux(): Gets the auxiliary data for an owner (e.g., the number of whitelist mint slots used.) _setAux(): Sets the auxiliary data for an owner _ownershipOf(): The token ownership data for a specific tokenId. _initializeOwnershipAt(): This can be used to initialize some tokens in a large batch to reduce first-time transfer costs. It initializes token ownership data at the index slot. _mint(): Mints a number of tokens and transfers them to a specific address. _safeMint(): Same functionality as _mint, but it contains a data parameter which gets forwarded to contract recipients in IERC721Receiver.onERC721Received. _beforeTokenTransfers(): This hook is called before a token ID set is about to be transferred. It is also called before burning one token. It contains the startTokenId and the quantity of tokens. _afterTokenTransfers(): This hook is called after a set of token IDs are to be transferred. What are ERC-1155 tokens? The ERC1155 protocol combines the abilities of ERC-20 and ERC-721, allowing tokens to have fungible and non-fungible characteristics. It was created by Witek Radomski and made public in 2019. ERC-1155 provides a way to model assets and their ownership, as well as a way to create, transfer, and settle those assets. With these capabilities, you can trade fungible assets like gold bullion, or collectibles such as art, baseball cards, loyalty points, etc., using the same smart contract. In an ERC-1155 smart contract, the balanceOf() method contains an id argument to identify the token you want to query its balance. It also contains other methods like: balanceOfBatch(): It returns the balance in a batch of accounts with specified ids. setApprovalForAll(): Allows an operator to transfer a caller's tokens. isApprovedForAll(): Checks if an operator is allowed to transfer a caller's tokens. safeTransferFrom(): Transfers a number of tokens from a caller's address to a recipient’s address. The tokens must have a type of id. safeBatchTransferFrom(): Same functionality as safeTransferFrom() but in batches. Conclusion The first step in creating a smart contract is deciding the right tool for the job. You can choose to create a simple fungible token based on ERC-20, improve its features based on ERC-777, create NFTs with ERC-721, or hybrid smart contracts with ERC-1155. Other token standards exist with their specific use-cases, like ERC-4626 for tokenized vaults and you can learn more about crypto tokens through our blog or these resources listed below. Resources Tokens by OpenZeppelin ERC-721A by Azuki ERC-1155 by Enjin #### Tokenizing property: Exploring the impact of real estate NFTs In the unfolding tangle of technology, finance, and property, some knots entwine more densely, forming unique confluences. One such synergistic fusion is the innovative intersection of Non-Fungible Tokens (NFTs) and real estate. What were once primarily digital art or music collectibles are now making inroads into real estate's traditional sphere. This groundbreaking integration of NFTs is penetrating property transactions and ownership models. Ever wondered how a piece of real estate can enter the blockchain realm, enhancing transparency, security, and potentially decreasing the hassle? Is it feasible to divide a mansion into multiple digital tokens, that too verified and immutable, enabling multiple stakeholders to own a piece? The answer lies in the revolutionary blend of NFTs and real estate. The fusion of blockchain technology with real estate has created intriguing potential, igniting curiosity among real estate veterans, tech enthusiasts, and novices alike. Strap in and join us as we embark on this fascinating journey of traversing the intriguing path of real estate on the blockchain. The place of NFTs in real estate In the realms of technology and finance, NFTs have garnered immense attention. These unique tokens offer an innovative method to validate and represent ownership of digital assets on the blockchain (Ethereum, Base, Solana, or any other). However, when applied to the real estate sector, NFTs reveal a novel outlook on property transactions. An NFT in real estate signifies the presence of unique, trackable, and verifiable ownership of physical or digital properties on a blockchain network. The application of NFTs in real estate has reimagined conventional property transactions and ownership models. Traditionally, the domain of artwork or music, NFTs are now venturing into the sphere of property, extending their reach beyond digital assets. Figure 1: Growth and potential statistics for real estate NFTs; Source: Pandora Finance Medium How they work in the wild Understanding how NFTs function in the world of real estate may seem daunting. However, by breaking it down into simpler terms, we can wrap our heads around it. Initially, all legal prerequisites for regulatory compliance must be fulfilled prior to minting an NFT. First, it's important to understand the foundational concept of an NFT. Unlike cryptocurrencies such as Bitcoin, Solana, or Ethereum, which are fungible and can be traded on a one-for-one basis, NFTs are unique and cannot be replaced with something else. Each NFT contains distinct information, which is stored in its metadata, making it different from any other NFT. Now, applying this concept to real estate, each property is unique: it has a distinct location, design, and legal history, among other characteristics. Therefore, representing a property as an NFT makes logical sense. The property's data can be stored in the metadata of the NFT, thereby converting the property into a unique digital asset on the blockchain. Figure 2: Fungible vs non-fungible tokens; Source: Apriorit Meeting legal boundaries Before any of this can happen, however, all legal prerequisites for regulatory compliance must be met. In the real world, selling a property involves several legal processes, including verifying the seller's legal right to sell, conducting inspections, and executing contracts. In the virtual world of NFTs, these processes aren't any different. The legal prerequisites might include proving ownership, ensuring the property meets certain standards, and digitizing the necessary legal contracts. Once these requirements are met, an NFT representing the property can be created, also known as "minted. This process involves writing the property's information into the NFT's metadata and then saving the NFT onto the blockchain, such as Solana, Polygon, Ethereum, Base, or others. Once minted, the NFT is a unique digital representation of the physical property. Moving back into Web3 This dynamic interplay between blockchain and NFTs is a major factor that streamlines real estate transactions. By digitizing properties and the transaction process, it reduces many of the logistical hurdles inherent in traditional real estate transactions. Moreover, the transparency of the blockchain means that all parties involved can verify transaction details via a block explorer or request information directly via an RPC node, thereby reducing the risk of fraud. Figure 3: How does real estate tokenization work; Source: Cointelegraph / blockchainappfactory It also makes transactions faster. Traditional real estate transactions can take weeks or even months to complete, due to the need to physically move documents around and the manual effort required to verify all of the transaction's details. In contrast, NFT-based transactions can be completed in a matter of minutes. Therefore, by converting properties into NFTs and conducting transactions on the blockchain, the real estate industry can potentially become more efficient, transparent, and user-friendly. However, it's worth noting that this is still an emerging technology, and much will depend on the regulatory environment and public acceptance of this new form of transaction. Advantages over traditional methods The rapid advancement and integration of NFTs and blockchain technology within the real estate sector have the potential to revolutionize industry practices, from enhancing transaction security to simplifying mortgage processes. By incorporating these technologies, businesses can achieve a more secure, efficient, and user-friendly real estate marketplace. Here are some significant benefits: Enhanced security of digital transfers: NFT marketplaces designed for the real estate sector offer improved security and data integrity, minimizing cyber and real estate fraud risks, such as manipulation of property information or fraudulent purchases like fake deeds. Improved property ownership verification: The blockchain-based minting process of NFTs ensures secure and immutable property title deeds. This reduces paperwork and notarial service needs, minimizes fraud risks, and accelerates property purchasing and renting processes. Efficient property trading: Token transactions are facilitated by smart contracts, which specify the terms of transfer and automatically execute approved transactions, enabling cost-efficient and reliable coordination among mortgage lenders, notaries, escrow companies, and others. Increased liquidity: Tokenization aims to overcome barriers to real-estate transactions by optimizing processes, eliminating unnecessary intermediaries, and reducing entry costs. This can increase liquidity, enabling more buyers and sellers to participate in the market. Better price discovery: By fractionalizing individual properties, the pricing of a portion of the property can offer improved insights into the overall fair market value, providing a more accurate valuation compared to varying estimates from different experts. Existing applications of real estate NFTs The proliferation of NFTs in real estate is not a theoretical concept, but a practical reality that is already taking shape. Take, for instance, the case of Michael Arrington, who listed an apartment through the real estate platform Propy as an NFT. This property, purchased initially via Ethereum smart contracts, was sold as the first-ever real estate NFT and fetched over $93,000. https://youtu.be/mrLAhlHExjk Figure 4: Michael Arrington interview with Propy CEO Natalia Karayaneva; Source: Propy YouTube Prometheus, a real estate development firm, sold two luxury homes in Portugal using cryptocurrency, marking yet another milestone in the usage of NFTs in real estate. These sales were not merely property transactions but also included the novel feature of property ownership via NFTs. Such instances showcase the potential that lies in the integration of NFTs and real estate. Tokenization of real estate properties NFTs offer flexibility in tokenizing real estate properties, creating intriguing possibilities for investors. Entire asset tokenization represents an entire property as a single NFT, with one owner holding all rights. Figure 5: Tokenization of real assets; Source: Explodingtopics / Property Limbrothers On the contrary, fractional ownership tokenization divides property into multiple tokens, enabling numerous investors to hold shares of the property. These innovative models optimize property transactions as never before. Obstacles to adoption Despite their numerous advantages, the adoption of NFTs in real estate does present some challenges. The slow-changing and cautious nature of the real estate industry, coupled with the complex technological facets of NFTs, often leads to hesitation. These range from the absence of a solid legal framework and tax compliance issues to potential value volatility and limited acceptance by older generations. Here are some key considerations: Absence of a legal framework: As NFTs are not yet fully recognized within legal systems worldwide, buyers may question whether digital purchases will grant legal property ownership. Compliance with tax laws: Real estate transactions are generally subject to taxation. Representing property as an NFT can raise questions about tax obligations in each country or state. Losses due to market volatility: Since NFTs are typically tied to the cryptocurrency market, their value can fluctuate significantly. This risk of sudden value drops could deter potential investors. Technical barrier to entry: Commercial real estate is largely owned by older generations, who may be less eager and tech-savvy to adopt the new technology in place of traditional service. Loss of access: While NFT marketplaces can ensure secure transactions, issues can still arise on the user side. The loss of access to a tokenized property can be detrimental for its owner(s). Digital vs. physical real estate The amalgamation of NFTs and real estate extends to both the physical and digital realms, each with its unique attributes. In the case of physical real estate, NFTs offer an innovative approach to property transactions by simulating real-world assets on the blockchain. On the other hand, digital real estate refers to virtual properties through "metaverse" platforms where NFTs serve as the deed of ownership. Such platforms enable users to create and interact within a virtual world, taking property ownership to an entirely new dimension. Figure 6: NFTs in the realm of real estate; Source: Revivoto Adopting NFTs in the real estate sphere brings both benefits and drawbacks. Key advantages include streamlined transactions, enhanced transparency, absolute ownership, potential for fractional ownership, and accessibility to global investors. However, the hurdles are undeniable. Technical complexity, market volatility, regulatory uncertainty, and environmental concerns associated with blockchain technology may deter traditional real estate investors from diving into NFT real estate. The foreseeable future of real estate NFTs NFTs are still in their infancy in the real estate sector, making it challenging to predict their path accurately. However, given the advantages they offer, like streamlined ownership transfer and potential for fractional ownership, real estate NFTs have a fascinating future. As blockchain becomes more robust and reliable, its adoption within real estate and is anticipated to grow. With utility and awareness of NFTs expanding beyond digital art into the many asset types out there, a more diverse pool of investors is expected, thereby driving the market volume further. Figure 7: Projected tokenized market volume until 2027; Source HSBC The potential benefits of tokenizing real estate, such as improved liquidity, better price discovery, lower costs, and reduced fraud, can make the sector more appealing to both institutional and individual investors. The accessibility of tokenized real estate also has the potential to democratize the market, allowing more people to invest in real estate with lower barriers to entry. Moreover, as regulatory environments adapt to this new form of transaction, the likelihood of an even sharper market growth acceleration increases. Countries that establish clear and supportive regulations around NFTs and tokenized real estate could become leaders in this emerging market. However, it's important to note that these projections also depend on the overall stability of the cryptocurrency market and the successful integration of blockchain technology into real estate operations. While the future looks promising, the evolution of this market will be dictated by how well these technological innovations are adopted and regulated across the world. Bringing it all together The intersection of NFTs and real estate has unfolded a new realm of possibilities, innovating property transactions and ownership models. From providing an enhanced level of security and improved verification of property ownership, to efficient property trading and simplified mortgages, the integration of these two entities brings a number of benefits. Despite facing a few challenges such as regulatory uncertainties and market volatility, the real estate sector is embracing this innovation, promising a future that is more efficient, transparent, and user-friendly. A myriad of applications of NFTs in real estate, both theoretical and practical, have been introduced, stimulating curiosity among industry veterans, tech enthusiasts, and novices alike. Tokenization of properties, be it complete asset tokenization or fractional ownership, is revolutionizing the way property transactions take place. As we navigate this fascinating journey, it becomes increasingly clear that the confluence of technology, finance, and property, albeit complex, offers an array of opportunities, making real estate transactions more accessible than ever before. Want to continue exploring creative NFT use cases? Check our comprehensive look into why they are more than mere JPEGs here: Power-boost your project on Chainstack #### TON Faucet: Get free TON testnet tokens Introducing the Chainstack TON Faucet: Your gateway to free TON testnet tokens. Navigating the world of Web3 development requires access to testnet tokens for experimenting with smart contracts, building decentralized applications, and fine-tuning blockchain solutions. To meet these needs, we’ve launched the Chainstack TON faucet, designed specifically for Web3 developers. Now available via both our web-based faucet and the Telegram Mini App. How to use the Chainstack TON faucet After signing up and generating your API key on the Chainstack console, you can claim up to 1 TON testnet token every 24 hours. These tokens are essential for covering transaction fees, deploying smart contracts, and testing functionalities in the TON testnet before going live on the mainnet. You have two options for claiming your tokens: Web faucet: Visit the Chainstack TON Testnet Faucet and request your tokens. Telegram Mini App: Use our Chainstack TON Faucet Telegram Mini App here to claim your daily tokens directly through Telegram. Why the delay in receiving tokens? In most cases, you will receive your tokens quickly. However, network congestion may cause slight delays. If your tokens haven’t arrived within 15 minutes, please reach out to us on Telegram or Discord for assistance. Common errors “The user can only receive funds every 24 hours”: To ensure fair distribution, we limit requests to 1 TON testnet token per day. “Something went wrong. Check credentials and try again”: This error may be caused by an incorrect API key or wallet address. Verify your details, refresh the page, and try again. If your API key and wallet address are correct and you still encounter issues, contact us on Telegram or Discord for assistance. What’s next after claiming your tokens? Once you have your tokens, you can begin deploying smart contracts and testing your DApps. Share the details of your project by tagging @ChainstackHQ on X. We’re excited to hear about your work and may feature it on our social channels! Need help using the faucet? If you need assistance using the faucet or encounter any issues, feel free to contact our support team via Telegram or Discord. We’re here to help ensure you have everything you need to build and test your DApp. I want the best TON nodes Get high-performance TON nodes on Chainstack. Sign up now to deploy your node for free on the Developer plan and access 20+ blockchains with powerful developer tools. What is Chainstack? Chainstack offers a complete Web3 development stack, providing access to all the protocols, APIs, and tools required to scale your decentralized applications across over 20 different blockchains. What is a faucet? A faucet is a tool that provides free testnet tokens for developers. These tokens allow you to test smart contracts or DApp interactions without any financial risk. Our Chainstack TON faucet supplies you with TON testnet tokens for testing before moving to production. What is the TON testnet? The TON testnet is a public test environment where developers can deploy and test their decentralized applications and smart contracts before launching them on the mainnet. What does ‘drip’ mean in Web3 faucets? In the context of Web3, a 'drip' refers to the amount of testnet tokens a faucet distributes each day. For the Chainstack TON faucet, you can claim up to 1 TON testnet token per day. What are TON testnet tokens? TON testnet tokens are used exclusively within the TON testnet to pay for transaction fees and interact with smart contracts. While they have no real-world monetary value, they are crucial for testing and refining your DApps in a safe environment. Have more questions? Join our Telegram or Discord communities to chat directly with our team and get the help you need to make the most of your development experience on Chainstack. Power-boost your project on Chainstack #### TON: Master guide to custom wallet RPC endpoints Welcome to the grand world of TON wallets. If you're a Web3 developer passionate about pushing boundaries and leveraging the full potential of your technology, you're in the right place. At Chainstack, we aim to empower developers with profound technical know-how so you can unleash innovation without obstacles. This article is all about diving into the nuances of setting custom RPC endpoints for TON wallets, an adventure that makes them more flexible and tailored to your needs. Let’s explore! What are custom RPC endpoints? Now, what exactly does customizing an RPC endpoint mean? RPC stands for Remote Procedure Call, a protocol that your TON wallet uses to communicate with the TON Network. By customizing the RPC endpoints, you essentially instruct your TON wallet where to send transaction requests, where to fetch data, and how to sync with the blockchain state. Why is it crucial for you as a Web3 developer? Well, having the ability to set custom RPC endpoints can tremendously expand functionality. For instance, you can specify different endpoints for mainnet and testnet, manage load by distributing requests between different endpoints, or even set a custom endpoint that runs a modified version of the TON node. Also, with Chainstack's infrastructure, you can effortlessly retrieve the address of your RPC endpoint, translating to consistent, high-availability access to the TON network. How to find your Chainstack RPC endpoint? Before we delve into the specific processes entailed in setting RPC endpoints in different wallets, let's first look at how to locate your Chainstack RPC endpoint. Go to the Chainstack console, where you manage all your blockchain projects. Navigate to the node details section. In the 'Access and credentials' section, you'll find the Execution client HTTPS endpoint. This is your Chainstack RPC endpoint. Now that you have your RPC endpoint at your disposal, let's see how you can plug it into various TON wallets for expanded functionality. Tonkeeper As a Web3 developer diving into the TON environment, Tonkeeper wallet quickly maintains a palpable presence. A feature-rich palette awaits those who seek to modify and use custom RPC endpoints. While Tonkeeper initially might not present an option to set custom RPC endpoints via its UI directly, do not get disheartened just yet. As open-source software, Tonkeeper is a developer’s delight and allows you to modify the RPC endpoint right from the source code. It emphasizes the 'custom' in 'custom RPC endpoint', bringing true flexibility to your hands. You're also presented with the opportunity to switch between different versions of wallet contracts, enhancing your developmental maneuvers. This is especially beneficial when testing different features or updates. To switch to testnet mode, you simply access the Settings, enjoy an interactive game of clicking the Tonkeeper Web icon five times, and alter the active network. As simple as a Sunday morning! MyTonWallet MyTonWallet has quickly become a favorite of many Web3 developers thanks to its rich features and robust customizability. This open-source wallet paves the way for advanced modification, including setting custom RPC endpoints. Though one might notice that the option to set this through the UI directly is missing, as an open-source wallet, you have the liberty to modify the source code, giving you direct control over the RPC endpoint modification. When it comes to testing your DApps, MyTonWallet ensures smooth sailing. It supports switching between different versions of wallet contracts - a boon for testing different functionalities or staging an update. Switching to testnet mode is no Herculean task either. Head over to the Settings, playfully click on the MyTonWallet label five times, and brace yourself for the joy of effortless network alteration. OpenMask OpenMask wallet stands apart among TON wallet options. Created with developers in mind, it not only stands as an open-source extension equivalent to MetaMask for TON, but it also offers the quintessential feature of setting custom RPC endpoints directly through its user interface. Often the learning curve associated with code manipulation can be taxing. With OpenMask, you can manage your RPC endpoint and how your dApps interact with the TON network directly through the wallet settings - a great blend of convenience and efficiency. Further amplifying its utility, OpenMask also supports swapping between different versions of wallet contracts—a blessing when testing or experimenting with different features. Switching to testnet mode is made easy too. You can swiftly change the active network in the top menu of the wallet window. TON Wallet While the TON Wallet may not offer a host of flexibilities such as OpenMask or MyTonWallet, it doesn't fall behind when it comes down to functionality and power. The TON Wallet stands firm as the original powerhouse among TON's array, providing users with robust features. Though you cannot set custom RPC endpoints directly through the user interface, the open-source nature of the TON Wallet allows you to get your hands dirty by modifying the RPC endpoint right in the source code. A detour that proves beneficial for developers hoping to harness their control with DApps. It's crucial to note that, unlike other wallets, the TON Wallet doesn't support switching between different versions of wallet contracts. Although it may seem like a setback, this also ensures that the dynamic integrity of the wallet stays unaltered. TON wallet comparison When it comes to choosing the "right" wallet, it's often about celebrating the strengths while appreciating the necessary trade-offs. In this world of TON-based wallets, Tonkeeper, MyTonWallet, OpenMask, and the TON Wallet each hold unique charms. Both Tonkeeper and MyTonWallet are quite similar, requiring developers to modify the source code to set custom RPC endpoints. While this might appear as an overhead initially, the real magic is unveiled when you realize their potent capability of toggling between distinct versions of wallet contracts, giving you the versatility you need when testing different features or updates. On the other hand, OpenMask sets itself apart with its user-friendly UI offering for setting custom RPC endpoints. It empowers developers to alternate between Mainnet and Testnet smoothly, and like Tonkeeper and MyTonWallet, it supports switching between different versions of wallet contracts. A manifestation of a balance between power and convenience, OpenMask stands strong. Last but not least, the TON Wallet—staying true to its roots. Though it may not offer similar flexibilities as its counterparts, this direct-to-action, open-source wallet lets you straightaway tweak the RPC endpoint from the source code while ensuring dynamic integrity through a singular version of the wallet contract. FeatureTonkeeperMyTonWalletOpenMaskTON WalletCustom RPC endpoint via UI❎ (Modify in source code)❎ (Modify in source code)✅ (Directly through UI)❎ (Modify in source code)Switch wallet contract versionsYes (Supports switching between versions)Yes (Supports switching between versions)Yes (Supports switching between versions)❎ (Only a singular wallet contract version)Testnet mode✅ (Accessible by clicking Tonkeeper Web icon 5 times in settings)✅ (Accessible by clicking MyTonWallet label 5 times in settings)✅ (Accessible via top menu in the wallet window)✅ (Not supported directly via the UI)Open-source✅ (Source code available for modifications)✅ (Source code available for modifications)✅ (Source code available for modifications)✅ (Source code available for modifications)Main differentiatorOffers flexibility through source code modification and contract version switchingProvides rich features but requires manual source code modification for RPCsEasy-to-use UI for setting custom RPCs and supports contract version switchingStays true to original features, minimal UI, requires source code modifications Further reading Expand your TON knowledge and development skills with these comprehensive Chainstack resources: TON tool suite: Learn how to interact with your Chainstack TON node and develop DApps. TON glossary: Get a better understanding of key TON terminology and its definitions. TON ultimate guide to APIs and interaction libraries: Explore the full range of TON APIs and interaction libraries available to developers with this guide. TON ultimate developer guide: Unlock TON development with this guide, packed with everything you need—from ready-to-use code snippets to advanced integration strategies. How to deploy a TON smart contract: Step-by-step guide to deploying a smart contract on TON, including setting up the environment and interacting with your deployed contract. How to develop TON fungible tokens (Jettons): Learn how to create and deploy fungible tokens on the TON network, covering the key components like the minter and wallet contracts. How to customize TON fungible tokens (Jettons): Discover how to add custom functionality to Jettons, including setting capped supply and token pricing. The ultimate guide to building DApps on Chainstack: Explore our ultimate guide covering protocol selection, API authentication, error handling, and more. 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 world of TON wallets doesn't have to seem like cracking the enigma code. As we've unveiled in this comprehensive guide, each wallet comes with its own set of distinct features and flexibilities, catering to different needs and preferences among developers. Whether you're a fan of modifying source code or someone who prefers direct interface controls, wallets like Tonkeeper, MyTonWallet, OpenMask, and the TON Wallet offer a variety of options for setting custom RPC endpoints. Coupled with the ability to effortlessly fetch your Chainstack RPC endpoint, you're well-equipped to achieve optimal network efficiency and drive your DApps to new heights. Start building on TON with Chainstack! Power-boost your project on Chainstack #### TON: Ultimate developer guide from smart contracts to Jettons If you're a Web3 developer, the evolving ecosystem of blockchain technology continually presents innovation avenues. As a leading blockchain service provider, we at Chainstack believe in empowering developers like you with the insights and tools necessary to stay ahead in this dynamic space. That's why we have put together this extensive guide for developing on one of the most promising blockchains today—the TON Network. TON offers a unique space for creating fungible tokens, Jettons, that extend far beyond basic smart contract deployment. This guide aims to dismantle complexities and guide you through a systematic development process on TON using key tools like the Blueprint SDK, Sandbox, and how to integrate high-performance Chainstack infrastructure into the mix. Let’s begin! How to set up your environment for TON? As a Web3 developer, the foundation of your journey into TON development is setting up the right environment. It's crucial to have the right tools and access to help you build, test, and deploy effectively. Here's how you can set it up: 1.1 Deploy a TON node on Chainstack To begin with, hop onto the Chainstack console and get started with a free Developer account. Once your account is active, you'll gain instant access to deploy nodes on various blockchains, including TON. By deploying a TON testnet node, you set the stage for interacting with the blockchain. Obtain the necessary credentials and API keys for your node for future transactions. Here’s a quick video guide on how you can navigate the interface to do that: https://www.youtube.com/watch?v=QuExIWULoAs Figure 1: How to deploy an Elastic Node in Advanced mode on Chainstack; Source: YouTube 1.2 Install prerequisites A few additional installations are necessary to ensure smooth operations. Ensure you have the current version of Node.js and a package manager (i.e., npm or yarn) installed on your system. Also, you'll need a TON wallet with some testnet tokens. Don't worry if don’t have any testnet tokens; they are readily obtainable from the TON faucet. And if you are not familiar with TON wallets, you can learn more about the most popular choices and how they fare against each other in our dedicated guide here. 1.3 Initialize the Blueprint SDK The Blueprint SDK is a valuable tool that simplifies TON development. Use it to initialize a new project directory and you'll get a structured directory complete with folders dedicated to managing your smart contracts, scripts, tests, and wrappers. You can choose from pre-existing templates or start an empty project based on your preferences. Run the following in your CLI then select an empty project in TACT to start fresh: npm create ton@latest Once your project is created, the Blueprint SDK automatically organizes your files into a structured directory system, making the development process smoother. Here’s a quick overview of the key directories: build/: Stores the compiled output of your smart contracts, including bytecode and other important artifacts generated after running the build command. contracts/: This is where your smart contracts reside. Any .tact file, such as your SimpleStorage contract, will be saved in this directory. scripts/: Used for deployment and interaction scripts. These scripts are essential for deploying your smart contracts to the TON blockchain and interacting with them, such as retrieving contract data or sending transactions. tests/: Contains all the test files for your smart contracts. You can write and execute tests here to verify that your contracts behave correctly. The default test ensures the contract deploys successfully, but you can extend it to test other functionalities. wrappers/: Holds the TypeScript wrappers for your smart contracts. These wrappers allow you to interact with the contracts in a type-safe manner when writing scripts or running tests. This structured setup helps streamline the development lifecycle from contract creation to deployment and testing. How to deploy a TON smart contract? Web3 developers know that the core of any blockchain development lies in the successful deployment of a smart contract. Once your environment is set, it's time to get hands-on with TON smart contracts using the powerful Blueprint SDK. Meanwhile, Chainstack's seamless node management will ensure you keep your focus where it truly matters—creating exceptional Web3 experiences. 2.1 Write the TON smart contract in TACT You'll locate the contracts/ folder inside your Blueprint project. Here, create a new file where you will script your smart contract. Start with a simple storage contract in the TACT language, storing a number and incrementing a counter for each interaction. // ./contracts/simple_contract.tact import "@stdlib/deploy"; // Allows the contract to receive a custom object of type "Save" specifying the number to save in the contract. message Save { amount: Int as uint32; } // This is an example of a simple storage contract. It has a function that increments the saved number by one when the function is called. contract SimpleContract with Deployable { // Declare variables // Variables structure: name: type id: Int as uint32; // This is an ID for contract deployment savedNumber: Int as uint32; counter: Int as uint32; // init is similar to a contructor in Solidity init(id: Int) { // Init the id assed from the contructor self.id = id; // Initialize the variables to zero when the contract is deployed self.savedNumber = 0; self.counter = 0; } // TON contracts can recevie messages // This function makes an action when a specific message is recevied // In this case, when the contract recevies the message "add 1" will increment the counter variable by 1 receive("add 1"){ self.counter = self.counter + 1; } // This allows the contract to recevie objects, in this case of type "Save" // Save a value in the contract receive(msg: Save){ self.savedNumber = msg.amount; } // Getter function to read the variable get fun Number(): Int { // Int is the type of value returned return self.savedNumber; } // Getter function to read the counter variable get fun Counter(): Int { // Int is the type of value returned return self.counter; } // Getter function for the ID get fun Id(): Int { return self.id; } } 2.2 Understand the TON smart contract components While the contract might look simple, it has components crucial for more complex contracts you might write in the future. These include State Variables, the Initialization Function, Message Handlers, and Getter Functions—each performing a unique role inside your contract. Imports and message declaration The contract starts by importing essential modules using import "@stdlib/deploy";. A custom message type called Save is declared. This message contains an amount field of type Int, aliased as uint32. Contract declaration The contract is defined as SimpleContract and includes the Deployable trait, allowing it to be deployed on the blockchain. Three variables are declared within the contract: id: Identifies the contract. savedNumber: Stores a number in the contract. counter: Tracks how many times a specific message is received. Initialization function The init() function acts like a constructor and is called when the contract is deployed. It initializes the id field with a custom value provided during deployment. The savedNumber and counter fields are both initialized to zero. Message handlers The contract is designed to handle messages: The receive("add 1") handler increments the counter by 1 whenever it receives the message "add 1". The receive(msg: Save) handler accepts a Save message object and stores the provided amount in savedNumber. Getter functions The contract includes getter functions to retrieve the values stored in the variables: get fun Number(): Returns the current value of savedNumber. get fun Counter(): Returns the current value of the counter. get fun Id(): Returns the id of the contract. Overview The SimpleContract provides a basic example of a storage contract on the TON Network. It initializes with custom values, processes incoming messages to perform specific actions (like saving numbers or incrementing a counter), and allows users to query the stored values using getter functions. 2.3 Compile and build the contract The next step after successful scripting is compiling the contract with Blueprint SDK. Successful compilation takes your TACT code and translates it into a format that TON's nodes will understand. Run the following in CLI to compile build your contract: npx blueprint build The response will be similar to this: Using file: SimpleContract Build script running, compiling SimpleContract ⏳ Compiling... > 👀 Enabling debug > SimpleContract: tact compiler > SimpleContract: func compiler > SimpleContract: fift decompiler > Packaging > SimpleContract > Bindings > SimpleContract > Reports > SimpleContract ⚠️ Make sure to disable debug mode in contract wrappers before doing production deployments! ✅ Compiled successfully! Cell BOC result: { "hash": "8bb0916eb10debd617ebaba79be7097cc21e41597dc940d16af521dbed9dad25", "hashBase64": "i7CRbrEN69YX66unm+cJfMIeQVl9yUDRavUh2+2drSU=", "hex": "b5ee9c724102110100029f000114ff00f4a413f4bcf2c80b0102016202070298d001d0d3030171b0a301fa400120d74981010bbaf2e08820d70b0a208104ffbaf2d0898309baf2e088545053036f04f86102f862db3c59db3cf2e082c8f84301cc7f01ca000101cb1fc9ed54090301f6eda2edfb0192307fe07021d749c21f953020d70b1fde208210946a98b6ba8ea830d31f018210946a98b6baf2e081d33f0131c8018210aff90f5758cb1fcb3fc9f84201706ddb3c7fe0c0008e2af90182eb0d7299a100d9de4cf674453aeb6aa320067fc00702b62aa29243621d23217dba94a47fdb31e09130e27004013a6d6d226eb3995b206ef2d0806f22019132e2102470030480425023db3c0501cac87101ca01500701ca007001ca02500520d74981010bbaf2e08820d70b0a208104ffbaf2d0898309baf2e088cf165003fa027001ca68236eb3917f93246eb3e2973333017001ca00e30d216eb39c7f01ca0001206ef2d08001cc95317001ca00e2c901fb000600987f01ca00c87001ca007001ca00246eb39d7f01ca0004206ef2d0805004cc9634037001ca00e2246eb39d7f01ca0004206ef2d0805004cc9634037001ca00e27001ca00027f01ca0002c958cc020120080c020fbd10c6d9e6d9e18c090b013ced44d0d401f863d2000194d31f0131e030f828d70b0a8309baf2e089db3c0a0002700002200201200d0e00b9bbbd182705cec3d5d2cae7b1e84ec39d64a851b6682709dd6352d2b647cb322d3af2dfdf1623982702055c01b80676394ce583aae4725b2c382701bd49def954596f1c753d3de0559c32682709d974e5ab34ecb733a0e966d9466e8a480201480f100011b0afbb5134348000600075b26ee3435697066733a2f2f516d576165594177773744717159335651704e5136456232414146466d67416346323365383955655a7947327764820ab944fa3" } ✅ Wrote compilation artifact to build/SimpleContract.compiled.json 2.4 Write tests for the contract Your contract is only as good as it performs, and the TON Sandbox is the perfect tool for you to write tests and validate your contract's deployment and interactions before the actual deployment. Here’s a sample test file you can use to do a TON smart contract test: // ./tests/SimpleContract.spec.ts import { Blockchain, SandboxContract, TreasuryContract } from '@ton/sandbox'; import { toNano } from '@ton/core'; import { SimpleContract } from '../wrappers/SimpleContract'; import '@ton/test-utils'; // On TON we can test by creating a virtual chain describe('SimpleContract', () => { let blockchain: Blockchain; // Init a virtual chain let deployer: SandboxContract<TreasuryContract>; let simpleContract: SandboxContract<SimpleContract>; // Init the smart contract instance const contractId = 1648n; // Id for deployment that will be passed in the contructor. Random value in this example beforeEach(async () => { blockchain = await Blockchain.create(); simpleContract = blockchain.openContract(await SimpleContract.fromInit(contractId)); // Init the deployer. It comes with 1M TON tokens deployer = await blockchain.treasury('deployer'); const deployResult = await simpleContract.send( deployer.getSender(), { value: toNano('0.05'), // Value to send to the contract }, { $$type: 'Deploy', // This because the contract inherits the Deployable trait. queryId: 0n, }, ); // Here is the test. In this case it tests that the contract is deployed correctly. expect(deployResult.transactions).toHaveTransaction({ from: deployer.address, to: simpleContract.address, deploy: true, success: true, }); }); it('should deploy', async () => { // the check is done inside beforeEach // blockchain and simpleContract are ready to use console.log('Deploying contract...'); const conttactId = await simpleContract.getId(); console.log(`Fetched ID during deployment: ${conttactId}`); }); it('should increase', async () => { console.log('Testing increase by 1 function...'); const counterBefore = await simpleContract.getCounter(); console.log('counterBefore - ', counterBefore); await simpleContract.send( deployer.getSender(), { value: toNano('0.02'), }, 'add 1', // The message the contract expects ); const counterAfter = await simpleContract.getCounter(); console.log('counterAfter - ', counterAfter); // Check it incremented the value expect(counterBefore).toBeLessThan(counterAfter); }); it('should save the amount', async () => { console.log('Testing increase by given value function...'); const numeberBefore = await simpleContract.getNumber(); const amount = 10n; console.log(`Value to save: ${amount}`); console.log(`Number saved before: ${numeberBefore}`); await simpleContract.send( deployer.getSender(), { value: toNano('0.02'), }, { $$type: 'Save', // This time it's an object and not just text amount: amount, }, ); const numberAfter = await simpleContract.getNumber(); console.log(`Number saved after: ${numberAfter}`); }); }); Let’s get a better understanding of how the test and its components work: Imports The necessary modules and utilities are imported from TON Sandbox, core libraries, and the SimpleContract wrapper. These imports allow interaction with the virtual chain and smart contracts in a test environment. Test suite initialization (describe block) The test suite is defined inside the describe block, which initializes key variables: blockchain: Represents a virtual chain used to test contract behavior. deployer: A sandbox instance representing the contract deployer with 1M TON tokens for testing purposes. simpleContract: The instance of the SimpleContract being tested. beforeEach hook The beforeEach hook is executed before each individual test to set up the testing environment: A virtual blockchain is initialized. The contract is deployed using the deployer account. A transaction is sent to deploy the contract, and the result is checked to ensure the deployment was successful. Test 1: Deployment verification This test checks whether the contract is deployed correctly. It retrieves the contract ID after deployment and logs the ID for verification. The actual deployment is validated in the beforeEach hook. Test 2: Counter increment functionality This test verifies that the add 1 message increments the counter in the contract. It checks the counter value before and after the message is sent, ensuring that the value increases as expected. Test 3: Saving a number in the contract This test validates the functionality of the Save message. It sends a message to store a specified amount in the savedNumber variable, and then verifies that the value was correctly updated in the contract. Running the tests All tests can be run using the Blueprint SDK by executing the test command: bash Copy code npx blueprint test 2.5 Deploy the TON smart contract to testnet The Blueprint SDK provides built-in endpoints for deploying contracts on both mainnet and testnet. However, to improve performance and reliability, it’s recommended to use your Chainstack endpoint instead. To configure this: Create a new configuration file named blueprint.config.ts in the project’s root directory. Set up the network settings in this file by specifying the Chainstack endpoint, along with the network type (testnet or mainnet) and the version. import { Config } from '@ton/blueprint'; export const config: Config = { network: { endpoint: 'YOUR_CHAINSTACK_ENDPOINT', type: 'testnet', version: 'v4', //key: 'YOUR_API_KEY', }, }; After configuring the custom endpoint, update the deployment script to include the contract ID. This ID can be generated randomly or customized based on the specific contract address generated during deployment. // ./scripts/deploySimpleContract.ts import { toNano } from '@ton/core'; import { SimpleContract } from '../wrappers/SimpleContract'; import { NetworkProvider } from '@ton/blueprint'; export async function run(provider: NetworkProvider) { // Edit this ID const contractId = 1648n; const simpleContract = provider.open(await SimpleContract.fromInit(contractId)); await simpleContract.send( provider.sender(), { value: toNano('0.5'), }, { $$type: 'Deploy', queryId: 0n, }, ); // Deploy contract await provider.waitForDeploy(simpleContract.address); console.log(`Deployed at address ${simpleContract.address}`); // run methods on `simpleContract` } Before you run the script, however, do add the your wallet’s mnemonic phrase and version to your environment variables: export WALLET_MNEMONIC="" export WALLET_VERSION="v4" Great! Now it’s time to run your script and deploy your TON smart contract: npx blueprint run The response should look like this: Using file: deploySimpleContract ? Which network do you want to use? testnet ? Which wallet are you using? Mnemonic Connected to wallet at address: EQDrNXDLYKstXHj5xV6_md1nYvvrb6y6v4bFyTZReZ-vFYdx Sent transaction Contract deployed at address EQDVoYZ96Gtc-nQM0U4-rj0mporVOTlSpmB64Tn6HJax98VN You can view it at <https://testnet.tonscan.org/address/EQDVoYZ96Gtc-nQM0U4-rj0mporVOTlSpmB64Tn6HJax98VN> Deployed at address EQDVoYZ96Gtc-nQM0U4-rj0mporVOTlSpmB64Tn6HJax98VN 2.6 How to interact with the deployed TON smart contract? Calling a method in your contract executes an interaction, whether it's incrementing the counter or saving a number. Reading the state can confirm the changes. Writing a script at this stage to interact with the contract on the testnet allows you to observe the contract’s behavior and ensure it's performing as expected: // ./scripts/getCounter.ts import { SimpleContract } from '../wrappers/SimpleContract'; import { NetworkProvider } from '@ton/blueprint'; export async function run(provider: NetworkProvider) { const contractId = 1648n; // Random in this case const simpleContract = provider.open(await SimpleContract.fromInit(contractId)); const id = await simpleContract.getId(); const savedNumber = await simpleContract.getNumber(); const counter = await simpleContract.getCounter(); console.log(`Fethching smart contract data...`); console.log(`Contract ID: ${id}`); console.log(`Current saved number: ${savedNumber}`); console.log(`Current counter: ${counter}`); } After running it via npx blueprint run your result will follow this pattern: ? Choose file to use ? Choose file to use getCounter ? Which network do you want to use? ? Which network do you want to use? testnet ? Which wallet are you using? ? Which wallet are you using? Mnemonic Connected to wallet at address: EQDrNXDLYKstXHj5xV6_md1nYvvrb6y6v4bFyTZReZ-vFYdx Fethching smart contract data... Contract ID: 1648 Current counter: 0 You can then use your wallet to commit a transaction with the message "Save" and some TON token to save the value with this script: // ./scripts/getCounter.ts import { toNano } from '@ton/core'; import { SimpleContract } from '../wrappers/SimpleContract'; import { NetworkProvider } from '@ton/blueprint'; export async function run(provider: NetworkProvider) { const contractId = 1648n; const simpleContract = provider.open(await SimpleContract.fromInit(contractId)); const id = await simpleContract.getId(); const counter = await simpleContract.getNumber(); console.log(`Sending increasing value...`); console.log(`Contract ID: ${id}`); console.log(`Current counter: ${counter}`); // Call the Add function and add 7 await simpleContract.send(provider.sender(), { value: toNano('0.02') }, { $$type: 'Save', amount: 7n }); } That’s it! You’ve now successfully deployed a TON smart contract and interacted with it. How to develop TON fungible tokens (Jettons)? With a solid foundation in TON smart contract development, let's now explore Jettons—the unique fungible tokens on the TON Network. As a Web3 developer, you not only need to understand what these tokens are, but also how to effectively create and manage them. 3.1 What are TON Jettons? On TON, fungible tokens are known as Jettons, and they follow a specific standard outlined in TEP74. This standard defines the key mechanisms for Jetton transfers and how to access essential information such as the token’s name, circulating supply, and other common metadata. The metadata specification for Jettons is detailed in TEP64. Jettons are structured around two key contract types: Master smart contract (Jetton Minter): Responsible for minting new Jettons, managing the total supply, and providing shared information about the token. Jetton-wallet contracts: These individual smart contracts hold the token balance for each user in a decentralized manner, ensuring that each owner has a unique Jetton wallet. The TON core team has provided example contracts for the Jetton minter and wallet, which serve as the foundation for further development. Figure 2: How to shard your TON smart contract and why; Source: TON 3.2 Get started with TON Jetton smart contracts To start creating Jettons, you can set up a new Blueprint project or extend your existing one. This involves adding both the Jetton minter and wallet contracts to your contracts/ folder. Jetton Minter and Wallet contracts serve different purposes in the Jetton ecosystem. The Jetton Minter contract takes charge of creating tokens and managing the total supply. On the other hand, the Jetton Wallet contract is assigned to each user and takes care of user balances and token transactions. First run npm create ton@latest . in your CLI, then create a blueprint.config.ts file in your project root, if you haven’t done that in the previous steps already: import { Config } from '@ton/blueprint'; export const config: Config = { network: { endpoint: '<https://ton-testnet.core.chainstack.com/.../api/v2/jsonRPC>', type: 'testnet', version: 'v2', // key: 'YOUR_API_KEY', }, }; Next, copy the necessary contracts from the standard implementation into your project's contracts folder. You will need the following files: jetton-minter-discoverable.fc, jetton-wallet.fc, jetton-utils.fc, discovery-params.fc, op-codes.fc, and params.fc. Here’s a brief overview of their roles: The minter contract allows the admin (contract owner) to control the minting process and manage the total token supply. It also implements the TEP89 feature, which simplifies the discovery of Jetton wallet addresses by other smart contracts. This is an important feature because, previously, contracts couldn't directly access methods from other contracts. The wallet contract manages the transfer, storage, and burning of Jettons for individual users. It keeps track of the wallet balance, the owner’s address, and information about the Jetton minter contract, updating these details after any transfers or burns. The jetton-utils.fc file provides essential functions for creating and managing Jetton wallets. It ensures that all necessary data is packed and calculates the correct wallet address for each user. The discovery-params.fc and op-code.fc files contain standard operational codes for the minter and wallet contracts. Additionally, they include the is_resolvable function, which checks whether an address is within the same workchain as the contract by comparing the workchain ID from the address with that of the contract. These checks are also included in params.fc. Ensure your contracts have the necessary imports before proceeding. // ./contracts/jetton-minter-discoverable.fc #include "imports/stdlib.fc"; #include "jetton-utils.fc"; #include "discovery-params.fc"; #include "op-codes.fc"; For the wallet contract: // ./contracts/jetton-wallet.fc #include "jetton-utils.fc"; #include "op-codes.fc"; For utility functions: // ./contracts/jetton-utils.fc #include "params.fc"; And for contract parameters: // ./contracts/params.fc #include "imports/stdlib.fc"; 3.3 Compile and build the TON Jetton smart contracts Just like with TON smart contracts, your Jetton contracts must also be compiled using the Blueprint SDK. In the wrappers folder, create or update the compilation files: // ./wrappers/JettonMinter.compile.ts import { CompilerConfig } from '@ton/blueprint'; export const compile: CompilerConfig = { lang: 'func', targets: [ 'contracts/jetton-minter-discoverable.fc' ], }; For the Jetton wallet: // ./wrappers/JettonWallet.compile.ts import { CompilerConfig } from '@ton/blueprint'; export const compile: CompilerConfig = { lang: 'func', targets: [ 'contracts/jetton-wallet.fc' ], }; Finally, run the build command: npx blueprint build 3.4 Create wrappers for Jettons To run scripts and tests for the smart contracts, you'll need to create TypeScript interfaces. These interfaces are contained in the wrappers folder and implement the Contract class from @ton/core. They also include serialization functions, getter wrappers, and compilation functions that streamline the interaction with your smart contracts. To set this up, copy the following files into your project’s wrappers folder: JettonMinter.ts, JettonWallet.ts, JettonConstants.ts, and ui-utils.ts. If you prefer, you can use shortened versions of these files from an existing repository. Note that ui-utils.ts contains some additional adjustments for usability. The Blueprint framework integrates Sandbox, a tool that allows developers to simulate the behavior of smart contracts as if they were deployed on a real blockchain. You can use this tool to test contracts within a controlled environment. Copy the test scripts from our repository, similar to how you copied the wrappers. These tests have been shortened and adjusted based on examples provided by the TON core team. To run the tests using Sandbox, execute the following command: npx blueprint test 3.5 Deploy the TON Jetton smart contracts In the scripts folder, create a file called deployJettonMinter.ts. This script will handle the deployment of your Jetton minter contract. The following code sets up the deployment process: // ./scripts/deployJettonMinter.ts import {toNano} from '@ton/core'; import {JettonMinter} from '../wrappers/JettonMinter'; import {compile, NetworkProvider} from '@ton/blueprint'; import {jettonWalletCodeFromLibrary, promptUrl, promptUserFriendlyAddress} from "../wrappers/ui-utils"; export async function run(provider: NetworkProvider) { const isTestnet = provider.network() !== 'mainnet'; const ui = provider.ui(); const jettonWalletCodeRaw = await compile('JettonWallet'); const adminAddress = await promptUserFriendlyAddress("Enter the address of the jetton owner (admin):", ui, isTestnet); const jettonMetadataUri = await promptUrl("Enter jetton metadata uri (<https://jettonowner.com/jetton.json>)", ui) const jettonWalletCode = jettonWalletCodeFromLibrary(jettonWalletCodeRaw); const minter = provider.open(JettonMinter.createFromConfig({ admin: adminAddress.address, wallet_code: jettonWalletCode, jetton_content: {type: 1, uri: jettonMetadataUri} }, await compile('JettonMinter')) ); await minter.sendDeploy(provider.sender(), toNano("1.5")); // send 1.5 TON } The metadata for the Jetton token must be provided in JSON format. The JSON should contain details such as the token name, description, symbol, decimals, and base64-encoded image data. Here’s an example: { "name": "Example Token", "description": "Official token", "symbol": "EXTO", "decimals": 9, "image_data": "4bWxuczPHN2ZyB0..." } With that out of the way, you are ready to deploy your Jetton contracts to the TON testnet. To do that run the following command: npx blueprint run This will start the deployment process, and once complete, your Jetton minter contract will be live on the TON testnet. How to customize TON fungible tokens (Jettons)? Developing fungible tokens in the form of Jettons is only part of the exciting journey on the TON Blockchain. As a Web3 developer working with Chainstack, you'll be creating far more than standard tokens. You'll be customizing those tokens to have unique features such as a capped supply and minting price. Here's how to do it: 4.1 Modify the TON Jetton minter smart contract The customization of your Jettons in this tutorial involves adding a capped supply and minting price. Capping supply limits the total number of tokens that can go into circulation, and the mint price ensures users pay a specific amount of TON for each Jetton minted. To add these features, you'll need to update the storage of the Jetton minter contract to include capped_supply and price fields: (int, int, int, slice, cell, cell) load_data() inline { slice ds = get_data().begin_parse(); return ( ds~load_coins(), ;; total_supply ds~load_coins(), ;; capped_supply ds~load_uint(32), ;; price ds~load_msg_addr(), ;; admin_address ds~load_ref(), ;; content ds~load_ref() ;; jetton_wallet_code ); } () save_data(int total_supply, int capped_supply, int price, slice admin_address, cell content, cell jetton_wallet_code) impure inline { set_data(begin_cell() .store_coins(total_supply) .store_coins(capped_supply) .store_uint(price, 32) .store_slice(admin_address) .store_ref(content) .store_ref(jetton_wallet_code) .end_cell() ); } You'll also need to add getter methods to fetch this data from the contract at any time: (int, int, int, slice, cell, cell) get_jetton_data() method_id { (int total_supply, int capped_supply, int price, slice admin_address, cell content, cell jetton_wallet_code) = load_data(); return (total_supply, capped_supply, price, admin_address, content, jetton_wallet_code); } slice get_wallet_address(slice owner_address) method_id { (_, _, _, _, _, cell jetton_wallet_code) = load_data(); return calculate_user_jetton_wallet_address(owner_address, my_address(), jetton_wallet_code); } int get_token_price() method_id { (_, _, int price, _, _, _) = load_data(); return price; Your minting logic should be tweaked to ensure no minting occurs once the capped supply is reached. Further, you'll need to compute exactly how many Jettons a user gets for the TON sent, factoring in the price per Jetton: if (op == op::mint()) { slice to_address = in_msg_body~load_msg_addr(); int buy_amount = msg_value - min_tons_for_storage; int jetton_amount = muldiv(buy_amount, 1, price); ;; Check if minting exceeds the capped supply throw_unless(256, total_supply + jetton_amount <= capped_supply); var mint_request = begin_cell() .store_uint(op::internal_transfer(), 32) .store_uint(0, 64) .store_coins(jetton_amount) ;; max 124 bit .store_uint(0, 2) ;; from_address, addr_none$00 .store_slice(my_address()) ;; response_address, 3 + 8 + 256 = 267 bit .store_coins(0) ;; forward_amount, 4 bit if zero .store_uint(0, 1) ;; no forward_payload, 1 bit .end_cell(); mint_tokens(to_address, jetton_wallet_code, min_tons_for_storage, mint_request); save_data(total_supply + jetton_amount, capped_supply, price, admin_address, content, jetton_wallet_code); return (); } 4.2 Update the TON Jetton wrappers In line with these changes, update your TypeScript wrappers for the Jetton contracts. They should now allow interaction with the capped supply and mint price, and gracefully handle any errors that arise if the capped supply is exceeded. First, you'll need to update the configuration in JettonMinter.ts to include two new fields: capped_supply and price. This will allow the minter contract to track the maximum token supply and set a price for minting new tokens. export type JettonMinterConfig = { admin: Address; jetton_content: Cell | JettonMinterContent; wallet_code: Cell; capped_supply: bigint; price: bigint; }; export function jettonMinterConfigToCell(config: JettonMinterConfig): Cell { const content = config.jetton_content instanceof Cell ? config.jetton_content : jettonContentToCell(config.jetton_content); return beginCell() .storeCoins(0) .storeCoins(config.capped_supply) .storeUint(config.price, 32) .storeAddress(config.admin) .storeRef(content) .storeRef(config.wallet_code) .endCell(); } This updated configuration ensures that both the capped supply and price are stored and initialized during contract deployment. Then as the next, embed the minting logic within the minter contract itself. The interface will now creates a simple minting message containing the necessary TON amount and the recipient's address. static mintMessage(from: Address, to: Address, query_id: number | bigint = 0) { return beginCell().storeUint(Op.mint, 32).storeUint(query_id, 64) // op, queryId .storeAddress(to) .endCell(); } async sendMint(provider: ContractProvider, via: Sender, to: Address, forward_ton_amount: bigint, total_ton_amount: bigint) { if(total_ton_amount < forward_ton_amount) { throw new Error("Total ton amount should be > forward amount"); } await provider.internal(via, { sendMode: SendMode.PAY_GAS_SEPARATELY, body: JettonMinter.mintMessage(this.address, to), value: total_ton_amount }); } This structure ensures that minting new Jettons is handled by sending a pre-packaged message that specifies the necessary details. Since you've added new properties, the getter functions also need to be updated. The following methods retrieve information about the total supply, capped supply, and token price, and they include the newly added fields. async getJettonData(provider: ContractProvider) { const res = await provider.get('get_jetton_data', []); const totalSupply = res.stack.readBigNumber(); const cappedSupply = res.stack.readBigNumber(); const price = res.stack.readBigNumber(); const adminAddress = res.stack.readAddress(); const content = res.stack.readCell(); const walletCode = res.stack.readCell(); return { totalSupply, cappedSupply, price, adminAddress, content, walletCode }; } async getWalletAddress(provider: ContractProvider, owner: Address): Promise<Address> { const res = await provider.get('get_wallet_address', [{ type: 'slice', cell: beginCell().storeAddress(owner).endCell() }]) return res.stack.readAddress(); } async getTokenPrice(provider: ContractProvider): Promise<BigInt> { const res = await provider.get('get_token_price', []); return res.stack.readBigNumber(); } These updated getters allow you to retrieve and interact with the new properties, such as the token price and capped supply, making it easier to manage Jetton data. 4.3 Test the Jettons customization Now it's time to go back to the Sandbox and test your newly customized Jettons. Ensure your tests validate that the capped supply and mint price work correctly during minting. As always, make sure to cover scenarios where the total supply exceeds the cap or improper amounts of TON are sent for minting. This first example test checks whether Jettons are minted correctly based on the amount of TON sent. It calculates the number of Jettons to be purchased, factoring in the costs, including storage fees. The initial Jetton balance and total supply are retrieved, and the minting message is sent: it('should mint correct amount of jettons based on the sent TON amount', async () => { // Calculate costs of minting const jettonsToPurchase = (await jettonMinter.getJettonData()).cappedSupply; const jettonsCost = jettonsToPurchase * price; const amountToSend = jettonsCost + toNano('1'); // Assuming 1 TON for storage fees const forwardFee = toNano('0.01'); const expectedMintedJettons = jettonsCost / price; // Retrieve initial balance and supply const userJettonWallet = await userWallet(user.address); const initUserJettonBalance = await userJettonWallet.getJettonBalance(); const initJettonSupply = (await jettonMinter.getJettonData()).totalSupply; // Send the minting message const res = await jettonMinter.sendMint( user.getSender(), user.address, forwardFee, amountToSend ); // Verify the transaction expect(res.transactions).toHaveTransaction({ on: userJettonWallet.address, op: Op.internal_transfer, success: true, deploy: true }); // Verify that the user's minted jettons match the expected amount const currentUserJettonBalance = await userJettonWallet.getJettonBalance(); const mintedUserJettons = currentUserJettonBalance - initUserJettonBalance; expect(mintedUserJettons).toEqual(expectedMintedJettons); // Verify that the total supply matches the expected amount of minted jettons const updatedTotalSupply = (await jettonMinter.getJettonData()).totalSupply; const mintedTotalSupply = updatedTotalSupply - initJettonSupply; expect(mintedTotalSupply).toEqual(expectedMintedJettons); printTransactionFees(res.transactions); }); After the transaction is complete, the test verifies that the correct amount of Jettons has been minted, checking both the user’s balance and the total supply. Additionally, the transaction details are validated, ensuring that the internal transfer was successful and the deployment of the user wallet occurred. As the second example test, the goal is to check that the minting process does not exceed the capped supply. It calculates the amount of Jettons to purchase beyond the cap, along with the necessary costs: it('should not mint more than capped supply', async () => { // Calculate costs of minting const jettonsToPurchase = (await jettonMinter.getJettonData()).cappedSupply + 1n; const jettonsCost = jettonsToPurchase * price; const amountToSend = jettonsCost + toNano('1'); // Assuming 1 TON for storage fees const forwardFee = toNano('0.01'); // Send the minting message const res = await jettonMinter.sendMint( user.getSender(), user.address, forwardFee, amountToSend ); // Verify the transaction expect(res.transactions).toHaveTransaction({ from: user.address, to: jettonMinter.address, aborted: true, // High exit codes are considered to be fatal exitCode: 256, }); }); The test then attempts to send the minting message and verifies that the transaction is aborted due to exceeding the capped supply. The transaction is checked for the correct exit code to ensure that it failed as expected. 4.4 Deploy the customized TON Jettons With your tests successful, you are ready to deploy this customization into the TON testnet. Deploy the Jetton minter contract that now includes capped supply and mint price. Once deployed, you can mint Jettons and check whether your rules are enforced correctly by interacting with the Jettons contracts: import {toNano} from '@ton/core'; import {JettonMinter} from '../wrappers/JettonMinter'; import {compile, NetworkProvider} from '@ton/blueprint'; import {jettonWalletCodeFromLibrary, promptUrl, promptUserFriendlyAddress} from "../wrappers/ui-utils"; export async function run(provider: NetworkProvider) { const isTestnet = provider.network() !== 'mainnet'; const ui = provider.ui(); const jettonWalletCodeRaw = await compile('JettonWallet'); const adminAddress = await promptUserFriendlyAddress("Enter the address of the jetton owner (admin):", ui, isTestnet); const jettonMetadataUri = await promptUrl("Enter jetton metadata uri (<https://jettonowner.com/jetton.json>)", ui) const jettonWalletCode = jettonWalletCodeFromLibrary(jettonWalletCodeRaw); const minter = provider.open(JettonMinter.createFromConfig({ admin: adminAddress.address, wallet_code: jettonWalletCode, jetton_content: {type: 1, uri: jettonMetadataUri}, capped_supply: 1000n, price: toNano('0.01') }, await compile('JettonMinter')) ); await minter.sendDeploy(provider.sender(), toNano("1.5")); // send 1.5 TON } Further reading Expand your TON knowledge and development skills with these comprehensive Chainstack resources: TON tool suite: Learn how to interact with your Chainstack TON node and develop DApps. TON glossary: Get a better understanding of key TON terminology and its definitions. TON master guide to custom wallet RPC endpoints: Learn how to customize TON wallet RPC endpoints and compare the leading provider options. TON ultimate guide to APIs and interaction libraries: Explore the full range of TON APIs and interaction libraries available to developers with this guide. How to deploy a TON smart contract: Step-by-step guide to deploying a smart contract on TON, including setting up the environment and interacting with your deployed contract. How to develop TON fungible tokens (Jettons): Learn how to create and deploy fungible tokens on the TON network, covering the key components like the minter and wallet contracts. How to customize TON fungible tokens (Jettons): Discover how to add custom functionality to Jettons, including setting capped supply and token pricing. The ultimate guide to building DApps on Chainstack: Explore our ultimate guide covering protocol selection, API authentication, error handling, and more. 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 Congratulations! You've successfully traversed an educational journey from deploying a smart contract on the TON Network, developing Jetton tokens, to customizing them with advanced functionality like capped supply and mint price. With the knowledge you've gained, you're ready to build, test, and deploy complex DApps on the TON Network using Chainstack, Blueprint SDK, and the exclusive capabilities of the ecosystem. This detailed guide aimed to give you a structured, step-by-step approach to mastering TON development from basic smart contracts to fully customized fungible tokens. As you continue to explore and develop on TON, remember that Chainstack is with you every step of the way, ready to empower your blockchain adventures with our powerful and easy-to-use node infrastructure. Power-boost your project on Chainstack #### TON: Ultimate guide to APIs and interaction libraries Blockchain technology continues to transform how DApps are built and operated, offering Web3 developers new tools to create secure and scalable solutions. The TON Network, with its focus on performance and reliability, is one such blockchain that has captured the attention of forward-thinking developers. Whether you're an experienced Web3 developer or just starting with TON, leveraging the right tools and APIs can be crucial to building successful DApps. In this guide, we will dive deep into the various interaction libraries and APIs available for the TON network, helping you understand how to integrate custom RPC nodes, use Chainstack infrastructure, and build with libraries like TonWeb, Ton.js, TonUtils, TonGo, Tonlib-rs, and more. This comprehensive guide will walk you through the process of setting up your environment, installing the necessary libraries, and interacting with the TON blockchain effectively. Let’s explore how to unlock the full potential of the TON network and build next-generation DApps! What types of TON APIs are there? The world of blockchain technology is indeed fascinating and full of opportunities for developers. Specifically, for Web3 developers, understanding APIs and their critical role in blockchain interaction is pivotal. Among these, TON APIs stand out with their uniquely designed features and functionalities. For the TON Network, two APIs are predominantly used: TON HTTP API and TON ADNL API. What is the TON HTTP API? The TON HTTP API is your gateway to access indexed blockchain information efficiently. Think of it as a well-organized library where you can swiftly get the information you need without having to go through heaps of data. What is the TON ADNL API? A sharp contrast to the HTTP API, the TON ADNL API brings a secure communication channel for interacting with the TON network. It's based on the ADNL protocol, providing you with not just reliable but also protected interactions with the TON network. Each of these APIs brings its own set of advantages, and depending on your specific use case, you might lean towards one over the other. How to build DApps on TON? The TON Network is a powerhouse for creating DApps. It’s not just about the flexibility it offers, but equally about the range of tools it provides to ease your development process. Let's explore some of these tools and learn how to build DApps using each one, hand-in-hand with Chainstack RPC nodes. But before we do that let’s first get a better understanding of how to deploy one with this video: https://www.youtube.com/watch?v=QuExIWULoAs How to build with TonWeb? TonWeb is a potent tool in the developer's arsenal when building DApps on the TON Network. To jump-start your project using TonWeb, you should have Node.js installed on your machine and be familiar with a package manager like npm or yarn. To initialize a project and install TonWeb run the following in CLI: mkdir tonweb-project cd tonweb-project npm init -y npm install tonweb After setting up your project and installing TonWeb, your primary task is to initialize a connection with a Chainstack RPC node. It's like shaking hands before starting a conversation; in this case, the conversation is your DApp interaction with the TON network. To do that enter the following in your script: // For ES Module // import TonWeb from "tonweb"; // For CommonJS const TonWeb = require('tonweb'); const rpcEndpoint = "YOUR_CHAINSTACK_RPC_ENDPOINT"; const tonweb = new TonWeb(new TonWeb.HttpProvider(rpcEndpoint)); tonweb.getBalance('EQ...').then(info => { console.log(info); }); How to build DApps using Ton.js? Ton.js serves as a reliable companion for developers looking to create DApps on the TON Blockchain. Similar to TonWeb, the prerequisites include having Node.js on your machine and a package manager such as npm or yarn. You can initialize a project and install Ton.js by running this in your CLI: mkdir ton-project cd ton-project npm init -y npm install ton Upon setting up your project and installing Ton.js, you will establish a connection with a Chainstack RPC node. This step is crucial as it sets the stage for your DApp to interact seamlessly with the TON network. Here’s what you should add to your script: // For ES Module // import { TonClient } from 'ton'; // For CommonJS const { TonClient } = require('ton'); const rpcEndpoint = "YOUR_CHAINSTACK_RPC_ENDPOINT"; const tonClient = new TonClient({ endpoint: rpcEndpoint }); tonClient.getBalance('EQ...').then(info => { console.log(info); }); How to build on TON with TonUtils? If you're a Go enthusiast, building DApps on the TON Network gets even more exciting with TonUtils. Before you embark on your development journey with TonUtils, ensure that you have Go (version 1.16 or higher) installed on your machine along with a Go package manager like go mod. Initialize your project and install TonUtils with the following in CLI: go mod init go-tonproject go get github.com/xssnick/tonutils-go@latest After setting up your project and installing TonUtils, you'll be ready to initiate a connection with a custom Lite Server. Custom Lite Servers are excellent choices for developers looking for secure, lightweight, and customizable servers to kickstart their DApp functionalities on the TON Network. To do that add the following to your script: package main import ( "context" "fmt" "log" "github.com/xssnick/tonutils-go/address" "github.com/xssnick/tonutils-go/liteclient" "github.com/xssnick/tonutils-go/ton" ) func main() { client := liteclient.NewConnectionPool() // Add a connection to a custom Lite Server using the global config URL err := client.AddConnectionsFromConfigUrl(context.Background(), "<https://ton.org/global.config.json>") if err != nil { log.Fatalf("Connection error: %v", err) } // Initialize the API client with proof check policy api := ton.NewAPIClient(client, ton.ProofCheckPolicyFast).WithRetry() // Create a context bound to a single TON node ctx := client.StickyContext(context.Background()) // Get the current masterchain block info block, err := api.CurrentMasterchainInfo(ctx) if err != nil { log.Fatalf("Error getting block info: %v", err) } // Specify the wallet address to check the balance walletAddr := address.MustParseAddr("EQ...") // Use WaitForBlock to ensure the block is ready account, err := api.WaitForBlock(block.SeqNo).GetAccount(ctx, block, walletAddr) if err != nil { log.Fatalf("Error getting account: %v", err) } // Display account information fmt.Printf("Is active: %v\\n", account.IsActive) if account.IsActive { fmt.Printf("Status: %s\\n", account.State.Status) fmt.Printf("Balance: %s TON\\n", account.State.Balance.String()) } } How to build Go DApps using TonGo? TonGo presents another favorable avenue for Go language fans to build DApps on the TON Network. Similar to TonUtils, the prerequisites here include Go (version 1.16 or higher) and a Go package manager like go mod. Start a fresh project and install TonGo with the following: go mod init go-tonproject go get github.com/tonkeeper/tongo@latest Once your project is set up and TonGo is installed, your next move involves establishing a connection with custom RPC nodes. TonGo allows seamless integration with these nodes, ensuring your DApps can interact effortlessly with the TON Network. Here’s what you should add to your script: package main import ( "context" "fmt" "github.com/tonkeeper/tongo" "github.com/tonkeeper/tongo/liteapi" ) func main() { // options, err := config.ParseConfigFile("path/to/config.json") tongoClient, err := liteapi.NewClientWithDefaultMainnet() if err != nil { fmt.Printf("Unable to create tongo client: %v", err) } tonAddress := tongo.MustParseAddress("EQ...") state, err := tongoClient.GetAccountState(context.Background(), tonAddress.ID) if err != nil { fmt.Printf("Get account state error: %v", err) } fmt.Printf("Account status: %v\\nBalance: %v\\n", state.Account.Status(), state.Account.Account.Storage.Balance.Grams) } How to build Rust DApps with Tonlib-rs? For developers who are keen on Rust, Tonlib-rs brings a robust solution for building DApps on the TON Network. Before you get started, ensure that Rust (version 1.56.0 or higher) is installed on your device along with Cargo, the Rust package manager. For Linux, you will need the following packages installed: sudo apt install build-essential cmake libsodium-dev libsecp256k1-dev lz4 liblz4-dev In turn, for macOS, use the following: brew install readline secp256k1 ccache pkgconfig cmake libsodium And if you’re on Windows, install CMake first, then libsodium and other dependencies via vcpkg vcpkg install libsodium libsecp256k1 lz4 Next, to initialize your project run: cargo new tonlib-rs-project cd tonlib-rs-project Then, to install tonlib-rs open your Cargo.toml file in your project’s root and add the following under [dependencies]: [dependencies] tokio = { version = "1", features = ["full"] } tonlib = "0.15" anyhow = "1.0" After setting up your project and integrating Tonlib-rs, it's time to initiate a connection with a Chainstack RPC node. Seamlessly connecting to this node allows your DApp to securely interact with the TON network, setting the stage for efficient and secure DApp functionalities. To do that create a new main.rs file in the src directory and add the following: use tonlib::address::TonAddress; use tonlib::client::TonClient; use tonlib::client::TonClientInterface; use anyhow::Result; async fn get_state() -> Result<()> { let client = TonClient::builder().build().await?; let address = TonAddress::from_base64_url( "EQ...", )?; let r = client.get_account_state(&address).await?; println!("Account balance: {:?}", r.balance); Ok(()) } #[tokio::main] async fn main() { if let Err(e) = get_state().await { eprintln!("Error: {:?}", e); } } How to build Python DApps with TONsdk? TONsdk opens up new avenues for Python enthusiasts to build DApps on the TON Network. To set up your project with TONsdk, you'll need Python version 3.6.0 or higher and pip, the Python package manager. To start a fresh project and install the TONsdk, run the following in CLI: mkdir tonsdk-project cd tonsdk-project python3 -m venv venv source venv/bin/activate # On Windows: venv\\Scripts\\activate pip install tonsdk tvm_valuetypes aiohttp After initializing your project and installing TONsdk, your key task involves setting up a connection with a Chainstack RPC node. This bridge establishes your DApp’s communication with the TON network, ensuring a smooth interaction right from the get-go. Add the following to your script to do that: import asyncio import aiohttp from tonsdk.provider import ToncenterClient, prepare_address, address_state from tonsdk.utils import TonCurrencyEnum, from_nano async def get_wallet_balance(address: str): client = ToncenterClient(base_url="YOUR_CHAINSTACK_RPC_ENDPOINT", api_key="") address = prepare_address(address) async with aiohttp.ClientSession() as session: # Get the account state function and its arguments account_state_func = client.raw_get_account_state(address) # Invoke the function with the session account_state = await account_state_func['func'](session, *account_state_func['args'], **account_state_func['kwargs']) # Process the account state to get the balance account_state["state"] = address_state(account_state) if "balance" in account_state: if int(account_state["balance"]) < 0: account_state["balance"] = 0 else: account_state["balance"] = from_nano(int(account_state["balance"]), TonCurrencyEnum.ton) return account_state["balance"] address = "EQ..." balance = asyncio.run(get_wallet_balance(address)) print(f"Balance: {balance} TON") How to build on TON with PyTONLib? For Python developers, PyTONLib offers an excellent toolkit to interact with the TON Network. Before diving into your project with PyTONLib, note that Python should be installed on your machine (version 3.6.0 or higher) along with pip. To initialize your project and install PyTONLib run the following in your CLI: mkdir new-project cd new-project python3 -m venv venv source venv/bin/activate # On Windows: venv\\Scripts\\activate pip install pytonlib Once your project is set up and PyTONLib is installed, you can initialize a connection with a Chainstack RPC node. From here you can check a TON wallet's balance, marking the first step in your journey of interacting with the TON Blockchain using PyTONLib. import requests import asyncio from pathlib import Path from pytonlib import TonlibClient async def get_address_balance(address): ton_config = requests.get('<https://ton.org/testnet-global.config.json>').json() keystore_dir = '/tmp/ton_keystore' Path(keystore_dir).mkdir(parents=True, exist_ok=True) client = TonlibClient(ls_index=4, config=ton_config, keystore=keystore_dir) await client.init() account_state = await client.raw_get_account_state(address) balance = int(account_state['balance']) / 1e9 print(f"Balance: {balance} TON") await client.close() if __name__ == "__main__": asyncio.run(get_address_balance("EQ...")) How to build TON DApps with Pytoniq? Pytoniq offers a Python-centric approach to build DApps on the TON Network. Like PyTONLib, you need Python (version 3.6.0 or higher) and pip for starting your Pytoniq-based project. You can start a fresh project and install Pytoniq using this in CLI: mkdir new-project cd new-project python3 -m venv venv source venv/bin/activate # On Windows: venv\\Scripts\\activate pip install pytoniq Once your project is initialized and Pytoniq is installed, your next task is to establish a connection with custom Lite servers. After the connection is up and running, your DApp can smoothly interact with the TON network, leveraging the power and flexibility of the Pytoniq library. You can do that by adding the following to your script: import asyncio from pytoniq import LiteClient async def main(): client = LiteClient.from_mainnet_config() await client.connect() account_state = await client.get_account_state("EQ...") print(f"Balance: {account_state.balance}") if __name__ == "__main__": asyncio.run(main()) How to build DApps with TonSDK.NET? TonSDK.NET caters to .NET-oriented developers who aspire to build DApps on the TON Blockchain. To kick off your innovative project with TonSDK.NET, you'd need the .NET SDK (version 5.0 or higher) installed on your device. Initialize your project and install TonSDK.NET using the following: dotnet new console -n TonSdkNetProject cd TonSdkNetProject dotnet add package TonSdk.Client --version 0.3.10 After setting up your project and integrating TonSDK.NET, your primary task is to initiate a connection with a Chainstack RPC Node. This connection anchors your DApp's interaction with the TON network, ensuring a seamless and efficient development experience. Add the following to your script to achieve that: using TonSdk.Client; using TonSdk.Core; class Program { static async Task Main(string[] args) { var clientParams = new HttpParameters() { Endpoint = "YOUR_CHAINSTACK_ENDPOINT", ApiKey = "" }; var client = new TonClient(TonClientType.HTTP_TONCENTERAPIV2, clientParams); var address = new Address("EQ..."); var accBalance = await client.GetBalance(address); var balance = accBalance.ToDecimal() / 1_000_000_000; Console.WriteLine($"Balance: {balance} TON"); client.Dispose(); } } Further reading Expand your TON knowledge and development skills with these comprehensive Chainstack resources: TON tool suite: Learn how to interact with your Chainstack TON node and develop DApps. TON glossary: Get a better understanding of key TON terminology and its definitions. TON master guide to custom wallet RPC endpoints: Learn how to customize TON wallet RPC endpoints and compare the leading provider options. TON ultimate developer guide: Unlock TON development with this guide, packed with everything you need—from ready-to-use code snippets to advanced integration strategies. How to deploy a TON smart contract: Step-by-step guide to deploying a smart contract on TON, including setting up the environment and interacting with your deployed contract. How to develop TON fungible tokens (Jettons): Learn how to create and deploy fungible tokens on the TON network, covering the key components like the minter and wallet contracts. How to customize TON fungible tokens (Jettons): Discover how to add custom functionality to Jettons, including setting capped supply and token pricing. The ultimate guide to building DApps on Chainstack: Explore our ultimate guide covering protocol selection, API authentication, error handling, and more. 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 If you're a Web3 developer exploring the landscape of blockchain technologies, the TON Network provides some of the most powerful tools and libraries to kickstart your DApp development journey. With each tool offering its unique characteristics, you have a versatile range of choices from TonWeb, Ton.js, and TonUtils, to TonGo, Tonlib-rs, TONsdk, PyTONLib, Pytoniq, or TonSDK.NET. These allow you to pick what suits your preferences, whether it's a language choice or a specific function. And with Chainstack RPC Nodes easily accessible, the key connection between your DApps and the TON Network is effortlessly established. The world of DApp development is ready for you to make a mark. Start building on TON today! Power-boost your project on Chainstack #### Top 5 easiest ways to run an Ethereum node in 2026 Self-hosting a blockchain node sounds straightforward — until you're debugging a missed hardfork at 2am. The five options in this guide take that seriously. They represent the easiest paths to running your own Ethereum node in 2026 — no matter what infrastructure you're starting from. Each removes a different part of the setup burden. This guide tells you what each actually delivers, who it's built for, and where the catch is. What "easy" looks like in practice Not all node solutions reduce friction in the same way. In this guide, easy means: you don't configure clients from scratch, you don't write Docker Compose files, and you don't build a monitoring stack manually. The solution handles at least deployment and initial configuration for you. Three distinct categories qualify: Hardware appliances — physical boxes that ship pre-configured. You connect power and ethernet, follow a short setup wizard, and you're running a node. No terminal, no cloud account. Dappnode and Avado fall here. These are the only two options listed under the plug-and-play section on ethereum.org. Pre-installed cloud solutions — servers with the node software already installed and ready to deploy. You pick a provider, provision a server, and start from a working control panel rather than a blank Linux install. Chainstack Self-Hosted on partner infrastructure falls here. Low-config tools — setup tools that dramatically reduce the work compared to raw CLI, but still require a server and a terminal for the initial step. Once installed, everything is menu or GUI-driven. Stereum and EthPillar fall here — open-source, community-maintained options for VPS operators who want guided setup without hardware purchase. They appear in the guided setup section on ethereum.org. If you want raw setup tools that require more terminal work, see Top 5 Ethereum node setup tools in 2026. How we ranked these solutions Five criteria weighted toward setup simplicity: CriterionWeightWhat we looked atTime to first running node25%From order/sign-up to node syncingSetup complexity25%Steps required, technical knowledge neededOperational simplicity20%Monitoring, updates, recovery without manual workInfrastructure flexibility15%Cloud, hardware, multi-protocol supportLong-term reliability15%Self-healing, failover, update management Home users weight time to first node and setup simplicity highest. Teams weight operational simplicity and infrastructure flexibility more. The ranking reflects what matters most when the goal is to avoid operational overhead — not raw feature count. Top 5 easiest ways to run an Ethereum node 1. Chainstack Self-Hosted Best for: Anyone who wants a production-grade self-hosted node running on cloud or VPS infrastructure without configuring it from scratch. Chainstack Self-Hosted is a node management platform that deploys and operates Ethereum nodes on infrastructure you own — with the operational complexity handled for you. What makes it easy to run is the combination of pre-installed server partnerships and automated lifecycle management: you don't start from a blank server, and you don't manage ongoing operations manually. What makes it easy to run: Pre-installed on partner infrastructure — HOSTKEY, Velia, BreezeHost, and serverside.com ship servers with Chainstack Self-Hosted pre-installed. Select a server, and you're deploying nodes from a working control panel — not a bare Linux install One-click node deployment — select protocol, network, and configuration preset; the node is live in minutes with right-sized specs applied automatically Self-healing — nodes that crash or fall behind recover automatically without manual intervention Automated updates — get notified when client updates are available, control when they're applied, no manual coordination Zero-downtime failover — configure failover to a secondary node, a Chainstack managed RPC endpoint, or any endpoint you specify Built-in monitoring — real-time node performance, alerts, and observability without building a monitoring stack Chainstack Self-Hosted delivers 99.99% operational uptime for critical workloads, a 5x faster path to production compared to DIY, and 24/7 automated operations. Infrastructure partners: serverside.com offers 10% off servers with Chainstack Self-Hosted. Velia, BreezeHost, and HOSTKEY ship servers with Chainstack Self-Hosted pre-installed — select "Deploy on [provider]" from the Chainstack Self-Hosted product page. Limitations: Requires choosing and provisioning a server — you're not buying a pre-built appliance. For non-technical home users who want a physical box with no cloud account, Dappnode or Avado is a better fit. Why it's #1: Every other solution in this list makes you choose between owning your infrastructure and getting operational simplicity. Chainstack Self-Hosted is the only option here that gives you both — your server, your data, your infrastructure, with production-grade node operations handled automatically. The four infrastructure partnerships mean the "pre-installed" experience is real: you're not setting up software on a blank server, you're deploying nodes from a working control panel. Chainstack's 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. 2. Dappnode Home Best for: Home stakers and non-technical operators who want a physical appliance with the broadest Ethereum staking ecosystem, zero command line work. Dappnode ships pre-built hardware nodes designed specifically for Ethereum staking and node operation at home. The Dappnode Home appliances arrive with DappnodeOS pre-installed — plug in power and ethernet, follow the browser-based setup wizard, and you're running a node. No terminal, no configuration files, no client selection required unless you want to customize. What makes it easy to run: Pre-built hardware with DappnodeOS pre-installed — box arrives ready to configure Browser-based my.dappnode dashboard — entire setup and management through a web UI Auto-detection of hardware specs and automatic client configuration DAppStore: 100+ one-click packages including Lido CSM, Obol DVT, SSV Network, RocketPool — the most mature staking ecosystem of any solution in this list WireGuard VPN built in — remote access to your node from anywhere without exposing ports Auto-updates for DappnodeOS and installed packages MEV-Boost and Web3Signer bundled out of the box Hardware options: Dappnode Home appliances are the primary recommended path. The DappnodeOS software can also run on self-built hardware, though the out-of-box experience is optimized for Dappnode's own machines. Limitations: Hardware-centric — you need to buy the physical device and host it at home. No multi-server fleet management. Not designed for VPS or cloud deployment. If your hardware fails, you're managing recovery manually. Why it's #2: For home stakers who want a physical box and the richest staking application ecosystem, Dappnode is unmatched. The DAppStore with 100+ packages represents years of community curation that no other solution here matches. It earns #2 over Avado because of the more active ecosystem, broader protocol support, and stronger community backing in 2026. 3. Avado Best for: Home stakers who want a hardware appliance with a streamlined DAppStore experience and support for running multiple chains simultaneously. Avado is a plug-and-play blockchain computer — purpose-built hardware that ships with AvadoOS pre-installed. The setup experience is designed to be the simplest possible: connect the device, access the web interface via WiFi hotspot or browser, and install nodes from the DApp store with one click. No command line, no manual client configuration. What makes it easy to run: Hardware ships with AvadoOS pre-installed — WiFi hotspot for initial setup, no cables required beyond power Browser-based web UI for all node management DApp store with one-click installs for Ethereum (full node, validator, archive), Bitcoin, Gnosis Chain, and others Supports running multiple chains simultaneously on one device Remote Connect feature — manage your node globally without port forwarding Automatic package updates from the DApp store Hardware options: Avado i5 (entry-level), Avado i7, Avado r9 (AMD Ryzen 9, 8 cores, 64GB RAM, up to 16TB NVMe — for advanced users running multiple chains). The r9 is among the most capable home node hardware available in 2026. Limitations: Hardware-tied — requires buying the physical device. The ecosystem and community are smaller than Dappnode's in 2026. Active but less frequently updated than Dappnode's DAppStore. Why it's #3: Avado earns its place for users who want hardware simplicity plus the ability to run multiple chains on one device. The r9 configuration is meaningfully more powerful than most home staking hardware. It ranks below Dappnode because the staking ecosystem breadth and community support are less mature in 2026. 4. EthPillar Best for: Solo stakers and home operators on Linux who want the fastest path from blank server to running validator node — without memorizing CLI commands. EthPillar is a one-liner setup tool and node management TUI (text user interface) built by coincashew. A single curl command installs EthPillar, and from that point everything is menu-driven — no CLI commands to memorize, no Docker Compose files to write. It's the closest thing to zero-config for Linux VPS and home server users who want full staking capability. What makes it easy to run: One-liner install: a single curl command bootstraps the entire setup TUI menu navigation — all node operations accessible through a text-based interface, no CLI knowledge required after install Deploys minority clients by default (Nimbus-Nethermind, Teku-Besu, Lighthouse-Reth) for client diversity — MEV-Boost included Lido CSM integration — start staking with as little as 2.4 ETH Grafana and Ethereum-Metrics-Exporter built in — monitoring ready without manual configuration Built-in troubleshooting toolbox: port checker, peer counts, automated system benchmarking, node-checker Hoodi and Ephemery testnet support — practice risk-free before mainnet ARM64 and AMD64 support — works on Raspberry Pi and standard servers Active development: v5.2.4 released 2025, Pectra-ready, supported by Gitcoin Grants and EthStaker Supported configurations: Solo staking node, full node only, Lido CSM staking node, validator client only, failover staking node. Limitations: Requires Linux Ubuntu — not available for macOS or Windows. The initial install still requires opening a terminal and running a curl command. Not designed for multi-server fleet management or cloud-native deployments. Why it's #4: EthPillar earns its place because after the one-liner install, the entire node lifecycle is menu-driven — updates, monitoring, troubleshooting, key management. For Linux home stakers and VPS operators who want staking capability without building a manual setup from scratch, it's the most complete low-config option available. It ranks below the hardware appliances because it requires terminal access for installation, and below Chainstack Self-Hosted because it lacks automated self-healing and failover. 5. Stereum Best for: Users who want the easiest VPS node experience on a VPS or dedicated server without buying hardware, and are willing to do a one-time SSH setup. Stereum is the most hands-off VPS-based option on this list. You install the Stereum desktop launcher on your local machine, connect to your server via SSH once, and from there everything is managed through a GUI — no further command line work. It's not as zero-friction as the hardware appliances, but for VPS users it's the nearest equivalent. What makes it easy to run: Desktop launcher (Linux, macOS, Windows) handles all remote orchestration One-time SSH connection — after initial setup, everything is GUI-based Presets for common node types: full node, staking, MEV Boost, archive, DVT setups Auto-installs Prometheus and Grafana — monitoring is ready without manual configuration Mobile app (Stereum Node Monitor) with push alerts — the only open-source solution here that ships mobile alerting Lido CSM support live on mainnet (v2.4.6, February 2026) Config import/export for replicating setups Limitations: Requires a VPS or dedicated server you provision separately. The initial SSH setup step means it's not truly zero-configuration. Single-server only — no fleet management or multi-node orchestration. Update model is manual (triggered through the UI). Why it's #5: Stereum earns the final spot because it comes closer to zero-config than raw CLI tools, while not requiring hardware purchase. For VPS operators who want a GUI experience and mobile alerts without the physical box commitment, it's the right choice. It ranks below the hardware and cloud solutions because the setup bar is genuinely higher — SSH configuration is a step that EthPillar, Dappnode, and Avado don't require after initial install. Comparison table SolutionInfrastructureSetup pathMonitoringTime to running nodeBest forChainstack Self-HostedCloud / VPS (any)Pre-installed on partner servers, one-click deployBuilt-in, 24/7 automatedMinutesCloud users, teams, multi-protocolDappnode HomePhysical appliancePlug in, browser wizardGrafana built-in, auto-update~30 minutesHome stakers, non-technical usersAvadoPhysical appliancePlug in, WiFi setup, DApp storeBuilt-in dashboard~30 minutesHome multi-chain operatorsEthPillarLinux VPS / home serverOne-liner curl, then TUIGrafana built-in~1 hourLinux solo stakers, Lido CSMStereumVPS / dedicated serverSSH once, then GUIGrafana + mobile alerts1–2 hoursVPS users who want GUI How to choose If you are…Use thisCloud or VPS user who wants production-grade node operationsChainstack Self-HostedHome staker who wants a physical box and the richest staking ecosystemDappnode HomeHome operator who wants to run multiple chains on dedicated hardwareAvadoLinux user who wants one-liner setup with full staking capabilityEthPillarVPS user who wants a GUI experience without buying hardwareStereum Get started with Chainstack Self-Hosted Chainstack Self-Hosted is available now across four infrastructure partners. Choose the deployment path that fits your setup: Deploy on HOSTKEY — servers pre-installed with Chainstack Self-Hosted across 13 countries Deploy on Velia — Chainstack Self-Hosted pre-installed Deploy on BreezeHost — Chainstack Self-Hosted pre-installed Get 10% off on serverside.com — discount on servers with Chainstack Self-Hosted All paths land you at the same place: a working Chainstack Self-Hosted control panel where you deploy your first Ethereum node in minutes, with self-healing, automated updates, and built-in monitoring from day one. Conclusion The "easy node" promise means different things depending on where your node lives. For home stakers, it means a box that arrives ready to run — Dappnode for ecosystem depth, Avado for multi-chain capability. For Linux users who want one-liner setup with full staking capability, EthPillar is the right tool. For VPS users who want to skip the CLI after initial setup, Stereum gets closest without requiring hardware. For everyone running nodes on cloud or VPS infrastructure who needs production-grade operations — self-healing, automated updates, failover, built-in monitoring — without giving up ownership of the infrastructure, Chainstack Self-Hosted is the only option on this list that delivers all of it. Four infrastructure partners mean you're starting from a working pre-installed baseline, not a blank server. The node is yours. The operations are handled. Get started with Chainstack Self-Hosted → FAQ What is the easiest way to run an Ethereum node in 2026? For a dedicated physical appliance shipped to your door, Dappnode Home. For Linux users who want one-liner setup with full staking capability, EthPillar. For cloud or VPS deployment with production-grade operations, Chainstack Self-Hosted on a partner server is pre-installed and ready to deploy nodes in minutes. Do I need 32 ETH to run an Ethereum node? No. Running an Ethereum full node requires zero ETH — it's open to anyone with compatible hardware. The 32 ETH requirement applies only to becoming a validator (staking). All five solutions in this guide let you run a full node without staking any ETH. EthPillar supports Lido CSM staking with as little as 2.4 ETH for those who want to stake without the full 32 ETH commitment. What hardware do I need to run an Ethereum node at home? If you're buying a Dappnode or Avado appliance, the hardware is included — they ship with specs matched to Ethereum's 2026 requirements. For EthPillar on a home server or VPS, you need at minimum 16 GB RAM, 2 TB NVMe SSD, and a modern multi-core CPU running Ubuntu Linux. For cloud or VPS deployment with Chainstack Self-Hosted, right-sized configurations are applied automatically based on protocol requirements. What's the difference between Dappnode and Avado? Both are physical hardware appliances. Dappnode has a larger staking ecosystem — 100+ DAppStore packages including Lido CSM, Obol DVT, SSV, and RocketPool — and stronger community support in 2026. Avado's key advantage is multi-chain capability on a single device and the high-performance r9 hardware. If Ethereum staking is your primary use case, Dappnode. If you want to run multiple chains simultaneously, Avado's r9 is worth considering. Can I run an Ethereum node on a VPS without buying hardware? Yes. Chainstack Self-Hosted on partner infrastructure (HOSTKEY, Velia, BreezeHost, serverside.com) gives you a pre-installed VPS experience — no hardware purchase, no blank-server setup. EthPillar works on any Ubuntu VPS with a one-liner install. Stereum also supports VPS deployment with a GUI, though it requires an initial SSH setup step. What happens if my node goes offline with these solutions? It depends on the solution. Chainstack Self-Hosted has self-healing (automatic restart and recovery) and configurable failover to a secondary node or Chainstack RPC endpoint — your applications stay online even during node failures. Dappnode and Avado have auto-restart features but no external failover. EthPillar and Stereum require manual intervention if the node goes offline. For production workloads, Chainstack Self-Hosted is the only option here with zero-downtime failover. Additional resources Chainstack Self-Hosted How to deploy a self-hosted Ethereum node with Chainstack How to run a self-hosted blockchain node on HOSTKEY Top 5 Ethereum node setup tools in 2026 Spin up your own Ethereum node — ethereum.org #### Top 5 Ethereum node setup tools in 2026 Running your own Ethereum node is no longer the barrier it once was — but choosing the wrong setup tool still costs you weeks. The five tools in this guide represent the full spectrum of what's available in 2026: from a one-liner TUI for solo stakers to a Kubernetes-native control plane for teams managing nodes across multiple servers. Each solves a real problem. None is right for everyone. This guide gives you a clear picture of what each tool actually does, where it falls short, and which teams it's built for. What counts as a "setup tool" Before the list: setup tools and execution clients are not the same thing, and most comparisons conflate them. Execution clients — Geth, Reth, Nethermind, Besu, Erigon — are the raw node software. They sync the chain, process transactions, and serve JSON-RPC requests. You run one on every Ethereum node, always. Setup and management tools — the five options in this article — are the layer above that. They handle client installation, configuration, orchestration, monitoring, updates, and in some cases failover and fleet management. Without a setup tool, you're handling all of that yourself via CLI, cron jobs, and custom scripts. This guide covers only setup tools. If you're choosing an execution client, see Top 5 Ethereum node software options in 2026 — that article covers both layers. ➡️ All five tools listed here appear in the ethereum.org guided setup section — the canonical reference for Ethereum node operators. How we ranked these tools Five criteria, weighted by what matters most for production deployments: CriterionWeightWhat we looked atSetup complexity20%Time from zero to running nodeOperational maturity25%Monitoring, alerting, update modelInfrastructure flexibility20%Cloud, VPS, bare metal, multi-serverTeam and fleet support20%Multi-node management, access controlEnterprise readiness15%Compliance, SLA, support tier Solo stakers weight setup simplicity higher. DevOps teams weight operational maturity and fleet management higher. The ranking reflects what matters most for teams running nodes in production — not home lab setups. Comparison table ToolInterfaceInfrastructureMulti-serverMonitoringUpdate modelBest forChainstack Self-HostedWeb control panelAny (cloud, VPS, bare metal)✅ YesBuilt-inManaged rolloutTeams and enterprisesStereumDesktop GUI + SSHVPS / dedicated server❌ NoGrafana + mobile appManual via UISolo operators on VPSDappnodeWeb dashboardHome hardware / VPS❌ NoGrafanaAuto-updateHome stakerseth-dockerCLI (./ethd)Linux / macOS❌ NoGrafana + cloudManual (./ethd update)Technical solo stakersSedgeCLI wizardAny Linux❌ NoNone built-inManual (docker pull)DevOps / automation Top 5 Ethereum node setup tools 1. Chainstack Self-Hosted Best for: Development teams, protocol teams, and infrastructure organizations that need infrastructure ownership without operational overhead. Chainstack Self-Hosted is a turnkey blockchain node management platform that deploys and manages Ethereum nodes on infrastructure you own and control. You bring the server — cloud VPS, VM, bare metal, or on-premises environment. Chainstack provides the software layer that handles everything above the hardware: deployment orchestration, authentication, real-time monitoring, alerting, failover configuration, and managed update rollouts. What it actually does: Automated node deployment via a web-based control panel — no manual Docker Compose editing or CLI flags Self-healing: nodes that crash or fall behind restart and recover automatically without manual intervention Managed update notifications with controlled rollout, so hardfork-critical upgrades reach you before the deadline, not the morning after Configurable failover to a secondary node, a Chainstack managed RPC endpoint, or any user-specified endpoint — a node crash does not take down your application Real-time monitoring and alerts built in — no separate Prometheus/Grafana configuration required SOC 2 Type II certified and ISO 27001 data center infrastructure for compliance-sensitive deployments Infrastructure options: Any cloud provider, any VPS, bare metal, or on-premises Kubernetes cluster. For teams that want a turnkey hardware option, Chainstack's partnership with HOSTKEY ships servers with Chainstack Self-Hosted pre-installed across 13 countries — entry point around $190/quarter for a VDS in the Netherlands. Why it's #1: Every other option in this list forces you to choose between owning your infrastructure and getting operational simplicity. Chainstack Self-Hosted is the only tool on this list that gives you both. You retain full infrastructure ownership — your servers, your data, your cloud account. You don't inherit DIY's operational burden: no hardfork-coordination risk at 2am, no custom failover architecture to build, no manual monitoring setup. None of the other tools on this list combine both — they optimise for one or the other. 2. Stereum — solo staker node setup with mobile alerts Best for: Solo operators and small teams running a single VPS who want a GUI and built-in mobile alerting without buying dedicated hardware. Stereum is an Electron desktop application that SSH's into a user-provided server and orchestrates Docker containers remotely. You install the Stereum launcher on your local machine (Linux, macOS, or Windows), connect it to your VPS via SSH, and manage everything through a GUI — no CLI required after initial setup. What it actually does: Supports 5 execution clients (Geth, Nethermind, Besu, Erigon, Reth) and 5 consensus clients (Prysm, Lighthouse, Nimbus, Teku, Lodestar) Auto-installs Prometheus and Grafana — production-grade monitoring without manual configuration Mobile app (Stereum Node Monitor) with push alerts — a genuine differentiator that no other open-source tool in this list ships Presets for common use cases: solo staking, MEV Boost, archive node, SSV Network, Obol Charon Lido CSM support (live on mainnet as of v2.4.6, February 2026) Config import/export for replicating setups across servers Infrastructure: Any Linux VPS or dedicated server with SSH access. Does not support multi-server management — one Stereum launcher, one server. Limitations: Single-server only. Update model is manual — you trigger updates through the UI rather than getting automated rollouts. No team access controls, no fleet management. If your server is offline, there is no failover. Why it's #2: Stereum handles setup complexity better than raw clients, and monitors better than eth-docker out of the box. The mobile alert app is a practical differentiator — it's the only open-source tool here that will wake you up before a missed attestation becomes a slashing event. For a solo operator on a VPS who wants a GUI and real alerting without buying a Dappnode appliance, Stereum is the strongest single-server option. 3. Dappnode — home staker node setup for dedicated hardware Best for: Home stakers running dedicated hardware who want the most approachable, GUI-first experience with the broadest ecosystem of staking applications. Dappnode is both a software platform and a hardware product. The software (Dappnode Core) can run on arbitrary hardware, but its design is optimized for dedicated machines — ideally the Dappnode Home appliances the company sells. The my.dappnode web dashboard makes deploying execution and consensus clients genuinely accessible to non-DevOps users. What it actually does: Web dashboard accessible via browser — no SSH or terminal knowledge required for basic operations Bundles WireGuard VPN, Web3Signer, MEV-Boost out of the box DAppStore: 100+ packages including Lido CSM, Obol DVT, SSV, RocketPool, and more — one-click installs for staking protocols Auto-update feature for Dappnode Core and installed packages Community of 3,000+ operators with active Discord support Infrastructure: Primarily optimized for dedicated home hardware (Dappnode Home appliances or self-built machines). Can run on a VPS but the VPN-centric architecture is less natural in cloud environments. Why it's #3: Dappnode has the most mature home-staking ecosystem of any tool on this list. The DAppStore and 100+ packages represent years of community curation that Stereum and eth-docker don't match. For non-technical operators running a home node, Dappnode is the right choice. For teams running nodes on VPS or cloud, it's less of a fit — the architecture assumes dedicated local hardware, and there's no fleet management for multi-server setups. 4. eth-docker Best for: Technically capable solo stakers and developers who prefer Docker Compose over a GUI, and want maximum client flexibility with production-grade monitoring. eth-docker is a Docker Compose automation project maintained by the EthStaker community. It uses an interactive shell wizard (./ethd config) to handle setup, then manages everything via standard Docker Compose commands. No GUI — it's a terminal-native tool. What it actually does: Supports every major execution client: Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus-EL Supports every major consensus client: Lighthouse, Teku, Prysm, Nimbus, Lodestar, Grandine, Anchor Ships production-grade Grafana dashboards and alerting — either locally, via Grafana Cloud, or a remote Mimir/Thanos cluster Calendar versioning: releases are timed to hardfork dates, so ./ethd update before a scheduled fork is straightforward Supports advanced use cases: HTTPS exposure via Traefik, local client source builds, ssv.network DVT, RocketPool hybrid mode Runs on Linux or macOS, Intel/AMD x64 or ARM or RISC-V CPUs Infrastructure: Single server, Linux or macOS. No multi-server management. Limitations: No GUI. Requires comfort with the terminal, basic Docker knowledge, and understanding of how execution/consensus client pairs work. No mobile alerts. Update process is manual. Why it's #4: eth-docker is the most flexible open-source option in this list for technically capable operators who don't need a GUI. The broadest client support, the most robust Grafana integration, and the community backing of EthStaker make it a reliable long-term choice. It ranks below Stereum only because Stereum's mobile alerting and GUI lower the operational burden for users who aren't Docker-native. 5. Sedge Best for: DevOps engineers and developers who need to set up Ethereum nodes in automated, scripted, or CI/CD workflows. Sedge is a CLI tool written in Go, built by Nethermind. It generates Docker Compose scripts via an interactive wizard (sedge cli) or in fully non-interactive mode — making it the most automation-friendly option in this list. You answer a few questions, Sedge outputs a production-tested docker-compose.yml, and you run it. What it actually does: Interactive CLI wizard: select network, node type, clients, MEV Boost, validator — generates a complete Docker Compose setup Non-interactive mode: pass all flags as CLI arguments for scripting and automation Supports Ethereum and Gnosis Chain; full node, validator node, execution-only, consensus-only configurations Automatic client selection if you don't want to choose manually Keystore generation for validators (user-acknowledged as unaudited) Clean migration support: handles key imports when moving nodes between servers Infrastructure: Single server, any Linux environment. Designed for on-premises or VPS. Best suited for teams that want to script node creation rather than manage it through a UI. Limitations: No built-in monitoring — you'll need to configure Grafana separately. No mobile alerts. No GUI. Not designed for ongoing fleet management — it sets up nodes, it doesn't operate them at scale. Update workflow requires manual Docker Compose pulls. Why it's #5: Sedge occupies a different niche than the other tools — it's less of a management platform and more of a setup generator. For teams running Ethereum nodes in automated pipelines, staging environments, or CI/CD workflows, Sedge is the most natural fit. For long-running production nodes that need ongoing management, one of the tools ranked higher is a better fit. How to choose If you are…Use thisHome staker, non-technicalDappnodeSolo operator on VPS, want GUI + mobile alertsStereumTechnical solo staker, prefer CLIeth-dockerDevOps, need automation / CI/CDSedgeAny team or individual who wants infrastructure ownership without the operational burdenChainstack Self-Hosted Conclusion The right Ethereum node setup tool depends entirely on who's operating it and at what scale. Home stakers who want the simplest path to running a node from dedicated hardware should start with Dappnode. Solo operators on a VPS who want a GUI and mobile alerts without buying appliances will find Stereum the strongest single-server option. Technical operators who prefer the terminal and want maximum client flexibility belong on eth-docker. DevOps teams automating node provisioning in pipelines should reach for Sedge. For everyone else — development teams, protocol teams, and infrastructure organizations who need to own their nodes without owning the operational burden — Chainstack Self-Hosted is the only option on this list that delivers infrastructure ownership and operational simplicity together. It's currently available via early access — fill out the form on the product page and the Chainstack team handles onboarding directly. For a step-by-step walkthrough including HOSTKEY hardware setup, see How to deploy a self-hosted Ethereum node with Chainstack. Start with Chainstack Self-Hosted → FAQ What is the difference between a node setup tool and an execution client? An execution client (Geth, Reth, Nethermind, Besu, Erigon) is the software that actually syncs the Ethereum blockchain and processes transactions. A setup tool is the layer that installs, configures, monitors, and manages the execution client — and the consensus client that runs alongside it. You always need an execution client. Whether you need a setup tool depends on how much operational work you want to do manually. Which Ethereum node setup tool is best for a development team? Chainstack Self-Hosted is built for teams. It's the only tool in this list with multi-node fleet management, access controls, managed update rollouts, and enterprise compliance features. Solo staker node setup tools (Stereum, Dappnode), and eth-docker are designed for single-server operation and lack the team-facing features that development organizations need. Can I run an Ethereum node without any setup tool? Yes — you can install an execution client and consensus client directly and configure them manually. This is what the raw client approach involves. Most tools in this article exist because manual configuration, monitoring setup, update management, and failover handling add significant operational overhead that teams prefer to offload. Does Chainstack Self-Hosted support multiple execution clients? Currently Chainstack Self-Hosted deploys Ethereum nodes using the Reth execution client and Prysm consensus client. Support for additional client pairings is on the roadmap. If client diversity is a primary concern for your validator setup, Stereum or eth-docker offer the broadest multi-client support today. Which tool handles hardfork upgrades most safely? Chainstack Self-Hosted provides managed update notifications with controlled rollout — the upgrade reaches you before the deadline with minimal manual intervention. eth-docker uses calendar versioning timed to hardfork dates, which makes ./ethd update before a scheduled fork straightforward. Stereum requires you to trigger updates through the UI. Dappnode has auto-update for its packages. Sedge requires manual Docker Compose pulls — the least safe option for hardfork timing. Is Stereum free to use? Yes. Stereum is completely free and open-source. Premium support options exist for users who need dedicated assistance. All core features — SSH-based node management, Grafana monitoring, mobile alerts, multi-client support — are free. What hardware do I need to run an Ethereum full node in 2026? A production-grade Ethereum full node in 2026 requires at minimum: 32 GB RAM, 2–4 TB NVMe SSD (the chain passed 3 TB in mid-2025 and continues growing), a modern multi-core CPU, and 50+ Mbps sustained bandwidth. Archive nodes require significantly more storage — plan for 10+ TB. Hardware requirements increase with each protocol upgrade; budget accordingly. Additional resources Chainstack Self-Hosted How to deploy a self-hosted Ethereum node with Chainstack Chainstack Self-Hosted installation guide Top 5 Ethereum node software options in 2026 Spin up your own Ethereum node — ethereum.org #### Top 5 hosted Subgraph indexing platforms in 2026 Blockchain applications generate massive amounts of on-chain data, and querying that data efficiently is a critical challenge for modern Web3 projects. Hosted subgraph indexing platforms solve this by running managed indexing pipelines that process blockchain data in real time and expose the indexed data through GraphQL APIs. In this guide, we compare the top 5 hosted subgraph indexing platforms in 2026 — Ormi, Goldsky, Chainbase, SubQuery and The Graph. We focus on performance, data freshness, developer experience, pricing models, and ideal use cases to help you choose the best subgraph solution for your Web3 application. We intentionally exclude generic RPC providers and self-hosted indexing frameworks, and instead concentrate only on fully managed subgraph platforms designed for production workloads, real-time analytics, and scalable blockchain data access. Comparison table #ProviderKey strengthsFree plan & pricingBest for1OrmiSub-30ms latency, 4k+ req/sec, real-time indexing, 70+ chains, GraphQL/REST​Community: 3 subgraphs, 100k entities free. Developer: $4/100k entities pay-go. Enterprise: $1/100kLatency-sensitive DeFi, trading, gaming; migrations from The Graph Hosted Service2GoldskyReal-time streaming/webhooks/Mirror, instant subgraphs, 140+ chains, SQL ​Starter: forever free (3 subgraphs, 100k entities, 2250 worker hours).Scale: ~$0.05/hr worker + $4/100k entities​Streaming/alerts, analytics, no-code prototyping3ChainbaseNo-code, 80+ chains, GraphQL/REST/SQL ​Free: 3 projects/2 req/sec.Developer: $99/mo​Cross-chain, rapid dev4SubQuery110+ chains (non-EVM), fast sync (~1.85x), flexible mappings, Flex PAYG subquery+1​Managed: ~$0.20/hr deployment (PAYG per 1k requests).Network: Flex plans per Node OperatorPolyglot ecosystems (Polkadot/Cosmos), custom logic5The GraphHuge ecosystem of subgraphs, decentralized network (GRT), 40+ chains​Hosted: fully phased out (deprecated). Network: ~$1.5–2/100k queries (GRT), 100k free/mo​Community data (Uniswap/ENS), decentralized apps Ormi (0xGraph by Ormi Labs) Overview of the hosted subgraph platform Ormi is a next-generation hosted subgraph platform built for performance and real-time data. Branded as 0xGraph, it is fully compatible with The Graph's subgraph specification, meaning you can migrate existing subgraphs to Ormi with minimal changes. Ormi's core focus is on speed and reliability for production workloads. It uses a custom hybrid infrastructure (mix of bare-metal and cloud) to achieve extremely low query latency and keep indexing in sync with chain head even under heavy load. In other words, Ormi is designed to avoid the "lag and downtime" sometimes seen with other indexers, making sure your queries always have the freshest data. Notably, Chainstack has migrated its own production subgraphs to Ormi, using the platform to power internal analytics and real-time data workloads. This internal adoption reinforces Ormi’s positioning as a production-ready alternative for teams moving away from The Graph Hosted Service. Key strengths of the subgraph indexing service Ormi focuses on real-time performance and production-grade reliability: Low-latency queries: Average response times under 30 ms, with support for thousands of requests per second. Suitable for latency-sensitive applications such as DeFi dashboards and trading systems. Real-time indexing: Subgraphs stay closely in sync with the chain head, ensuring fresh data for live applications. Reorgs are handled automatically without data loss. Reliable infrastructure: Redundant ingestion and indexing architecture designed for stable performance under load, with 99.9% uptime SLAs for enterprise users. Broad chain support: Supports 70+ blockchains, primarily across EVM ecosystems, with the ability to deploy the same subgraph to multiple networks. Flexible APIs: Standard GraphQL endpoints, plus optional REST APIs for simpler integrations. Easy migration: Fully compatible with The Graph’s subgraph specification. Existing subgraphs can be migrated with minimal or no code changes. Developer experience and subgraph tooling Ecosystem Integration: QuickNode marketplace add-on, webhook support, direct database replicas (Enterprise). Streamlines full-stack Web3 development. Familiar Workflow: Uses standard Graph CLI — graph auth → graph deploy. Web UI for visual deployment and no-code starts. Same project structure you're used to.​ Real-Time Dashboard: Live metrics on query volume, indexing status, latency graphs, error rates. Makes debugging and optimization intuitive vs black-box indexers. Pricing and scalability TierFeaturesCostCommunity3 subs, 100k entitiesFreeDeveloperPay-go entities$4/100kEnterpriseDedicated, <50ms SLA$1/100k Ideal use cases for subgraph indexing Multi-Chain Apps: Single subgraph across 70+ EVM networks with consistent schemas DeFi/Trading: Sub-second position/price updates for dashboards, arbitrage bots, portfolio trackers Real-Time Gaming/Wallets: Instant event reactions (mints, transfers, battles) Production Migrations: Teams leaving The Graph Hosted — same code, better performance Goldsky Overview of the hosted subgraph platform Goldsky is a hosted subgraph platform that emphasizes real-time data delivery and integrations. Their tagline is "Crypto data, live-streamed," which reflects how they not only host subgraphs for GraphQL queries, but also offer streaming and transformation capabilities on top of the indexed data. Goldsky can be seen as an enhanced version of The Graph's hosted service – it's fully compatible with subgraph definitions, but it turbo-charges the performance and adds features like webhooks, direct SQL access, and data mirroring to external systems. It supports a very large number of chains (over 140 networks are supported, including testnets) and has been used by projects such as Polymarket, POAP, and Arweave to handle high query volumes. Key strengths of the subgraph indexing service Goldsky focuses on real-time data delivery and flexible data pipelines: Real-time streaming: In addition to GraphQL queries, Goldsky supports webhooks and streaming updates, allowing applications to react to on-chain events as they happen. Fast indexing and backfills: Optimized infrastructure for quick historical syncs and near–real-time indexing, with automatic handling of chain reorganizations. Instant subgraphs: Low-code setup that can generate subgraphs from contract ABIs, enabling fast prototyping without writing full mappings. Multiple data outputs: Query data via GraphQL, run SQL transformations, or stream indexed data directly into external databases and analytics systems. Wide chain support: Supports 140+ networks, including EVM chains and testnets, making it suitable for multi-chain applications. Developer experience and subgraph tooling Flexibility: GraphQL + SQL queries + streaming endpoints in one platform. Goldsky CLI: Graph-compatible deploy workflow. One-click community subgraph imports. Dashboard: Subgraph monitoring + webhook setup. Visual pipeline builder for Mirror. Pricing and scalability TierFeaturesCostStarter3 subs, 100k entities, 2250 worker hrs, unlimited webhooksFreeScalePay-go workers + entities$0.05 per hr + $4 per 100k​ Ideal use cases for subgraph indexing Rapid Prototyping: No-code subgraph generation for testing DeFi/NFT ideas across 140+ chains before committing to custom mappings. Event-Driven Apps: Alert systems, trading bots reacting to on-chain events via webhooks within seconds of block confirmation. Data Pipelines: Stream blockchain data into your warehouse (Postgres/Timescale) for analytics, keeping off-chain systems in sync. Chainbase Overview of the hosted subgraph platform Chainbase is a bit unique on this list because it positions itself as a Web3 data cloud platform that does more than just subgraphs. It offers a variety of data services (balances API, token API, NFT API, etc.) in addition to a hosted subgraph feature. Think of Chainbase as the "Firebase/Snowflake for Web3" – it provides managed infrastructure to index and query blockchain data across many chains, with both no-code and developer-centric tools. They highlight a very fast indexing pipeline (claims of up to 10× faster backfills than The Graph) and real-time sync with "almost zero latency" to the latest block. Importantly, Chainbase supports 80+ blockchains (covering most EVM networks and newer ones like Sui, Aptos, Solana, etc. as well), making it one of the most cross-chain capable platforms. Key strengths of the subgraph indexing service Chainbase focuses on ease of use and broad multi-chain data access: No-code indexing: Visual tools to create subgraphs without writing mappings or YAML, suitable for fast setup and non-technical teams. Multiple query interfaces: Access indexed data via GraphQL, REST, or SQL from a single platform. Wide chain support: Supports 80+ blockchains across EVM and non-EVM ecosystems, enabling cross-chain applications from one dashboard. Fast historical syncs: Optimized backfilling and caching for quicker access to historical blockchain data. Unified data platform: Combines subgraphs with ready-made APIs (balances, tokens, NFTs) under one data layer. Developer experience and subgraph tooling Scale Controls: Rate limits scale with plans. No entity/query overage surprises. Web Console: Visual project setup, no CLI needed. Drag-drop event indexing. Unified Portal: One dashboard for all chains/projects. API keys per project. Pricing and scalability TierFeaturesCostFree3 projects, 2 req/secFreeDeveloper15 projects, 10 req/sec, real-time$99/moEnterpriseRole-based access, custom SLAs, AI query engineContact to sales Ideal use cases for subgraph indexing Cross-Chain Dashboards: Portfolio trackers, NFT galleries spanning Ethereum + Solana + Polygon from single API. Non-Technical Teams: Marketing/product teams building internal tools without hiring subgraph specialists. Rapid Multi-Chain: Quickly index contracts across 80+ chains for aggregator apps or chain-agnostic analytics. SubQuery Overview of the hosted subgraph platform SubQuery originated in the Polkadot ecosystem and has grown into a comprehensive indexing solution for multiple ecosystems. It provides an open-source indexing SDK and a Managed Service to host your indices, with a strong focus on performance and flexibility. SubQuery was designed to be a faster, more developer-friendly alternative to The Graph, especially for non-EVM chains. Over time, it expanded to support 110+ networks including Polkadot's many parachains, Kusama, Avalanche, Ethereum, Polygon, Cosmos-based chains, Algorand, NEAR, and more. This makes SubQuery arguably the most ecosystem-agnostic indexer – it's not limited to EVM. Key strengths of the subgraph indexing service SubQuery emphasizes flexibility and support for diverse blockchain ecosystems: Broad ecosystem coverage: Supports 110+ networks, including Polkadot, Cosmos, and other non-EVM chains alongside EVM networks. Flexible indexing logic: Allows more custom logic during indexing compared to standard subgraph runtimes. Faster sync performance: Optimized indexing engine designed to reduce sync times during development and schema changes. Multi-chain indexing: A single project can index data from multiple chains and expose it through one GraphQL endpoint. Open-source foundation: Core indexing framework is open source, with options for managed hosting or self-hosting. Developer experience and subgraph tooling Migration Guides: The Graph → SubQuery conversion tools. Similar project structure. Resource Control: Dial vCPUs up/down for sync speed ($0.10/hr extra). Pay only while syncing. Network Flex Plans: PAYG per 1k requests. Operators compete on price/service. Pricing and scalability TierFeaturesCostManagedPay per deployment hour$0.20/hrNetworkFlex plans per operatorPAYG/1k req​ Ideal use cases for subgraph indexing Non-EVM Ecosystems: Polkadot parachains, Cosmos zones, Algorand dApps needing custom indexing. Complex Logic: Protocols requiring off-chain data (Chainlink oracles, IPFS metadata) during indexing. Fast Development: Teams iterating quickly — faster syncs mean less waiting during schema changes. The Graph Overview of the hosted subgraph platform No comparison would be complete without The Graph, which is the original pioneer of the subgraph concept. The Graph provides a decentralized protocol for indexing blockchain data and making it queryable via GraphQL. It began with a Hosted Service (a free SaaS operated by The Graph team) and has since been transitioning to the Decentralized Network (also known as The Graph Network) where indexers (node operators) index subgraphs and are rewarded in GRT tokens. The Graph introduced the whole idea of writing a subgraph manifest and mappings to define how to index smart contract data, and it remains the standard that many developers learn first. As of today, the Hosted Service is officially deprecated, while the decentralized network is production-ready and growing. The Graph supports subgraphs on 40+ chains (primarily Ethereum and EVM-compatible chains, plus some non-EVM like NEAR), enabling a wide range of Web3 data sources. Key strengths of the subgraph indexing service The Graph’s strengths are driven by its ecosystem scale and decentralized model: Largest subgraph ecosystem: Thousands of community-maintained subgraphs for popular protocols like Uniswap, ENS, and NFT marketplaces. Often no need to build your own indexer for standard data. Industry standard: The original subgraph specification that most indexing platforms remain compatible with. Skills and tooling are easily transferable. Decentralized indexing network: Queries are served by independent indexers staking GRT, providing redundancy and censorship resistance. Proven and battle-tested: Used in production for years and capable of serving large query volumes reliably, even if not optimized for ultra-low latency. Broad chain coverage: Supports 40+ chains across EVM ecosystems and selected non-EVM networks via Firehose / Substreams. Developer experience and subgraph tooling Subgraph Studio: Web interface for creating, testing, publishing subgraphs. Signal with GRT to attract indexers faster. Monitor health/query stats from dashboards.​ CLI Deployment: graph deploy to Network endpoint. Uses existing YAML/schema/mappings — no code changes needed. Local test with graph build first. GRT Billing: Usage-based query fees paid in GRT, typically around ~$1.5–2 per 100k queries after the free tier, depending on indexer pricing. Pricing and scalability TierFeaturesCostNetwork Free Tier100k queries/moFreeNetworkPay per query$1.5-2 per 100k ​ Ideal use cases for subgraph indexing Existing Subgraph Leverage: Query ready-made data from Uniswap trades, ENS domains, or NFT collections without building your own indexer. Perfect for apps needing standard protocol data fast. Decentralized Projects: Open-source dApps or protocols wanting censorship-resistant indexing via multiple GRT-staked indexers. Economic guarantees ensure uptime and accuracy. Ecosystem Apps: Dashboards, explorers, or analytics pulling from community subgraphs across 40+ chains. Cost-effective for non-real-time needs where a few blocks lag is acceptable. Frequently Asked Questions 1. What is a subgraph indexing platform? A subgraph indexing platform is a managed service that indexes blockchain data in real time and exposes it through GraphQL APIs. Instead of querying raw blockchain nodes via RPC (slow and complex), you define what data to index, and the platform handles infrastructure, syncing, and query optimization automatically. 2. Is The Graph Hosted Service still available in 2026? No, The Graph Hosted Service was fully deprecated in 2026. All projects must now use The Graph Network (decentralized, GRT-based) or migrate to alternative platforms like Ormi, Goldsky, or SubQuery. 3. How much does subgraph indexing cost? Pricing varies by platform: Ormi: $4 per 100k entities (100k free) The Graph: $1.5-2 per 100k queries (100k free/month) Goldsky: $0.05/hr workers + $4/100k entities (free tier available) Chainbase: $99/month fixed (Developer plan) SubQuery: $0.20/hr deployment 4. Which subgraph platform is the fastest? Ormi offers the lowest latency with sub-30ms query response times and 4k+ requests/second. It's optimized for real-time DeFi, trading, and gaming applications where every millisecond matters. 5. Can I migrate from The Graph to another platform? Yes, platforms like Ormi, Goldsky, and SubQuery are fully compatible with The Graph's subgraph specification. You can migrate with minimal or no code changes — just redeploy using their CLI. Conclusion: Choosing the Right Subgraph Platform With several strong hosted subgraph indexing platforms available in 2026, there is no one-size-fits-all solution — the right choice depends on your application’s performance requirements, data freshness needs, and development workflow. Choose Ormi if your priority is real-time performance and production reliability for latency-sensitive workloads like DeFi trading, dashboards, or on-chain games. Choose The Graph if decentralization, ecosystem standardization, and access to community-maintained subgraphs are core to your project. Choose Goldsky if your application relies on real-time streaming, webhooks, or pushing indexed data directly into analytics and off-chain systems. Choose Chainbase if you need a no-code, multi-chain data platform that prioritizes speed of setup and broad chain coverage. Choose SubQuery if you require flexibility, non-EVM support, or faster indexing with custom logic. Overall, modern hosted subgraph indexing platforms significantly reduce operational complexity compared to running self-hosted indexers. By aligning platform strengths with your technical and business goals — performance, scalability, ecosystem fit, and cost — you can confidently select the subgraph solution that best supports your Web3 application in 2026. FAQ What is a subgraph indexing platform? A subgraph indexing platform is a managed service that indexes blockchain data in real time and exposes it through GraphQL APIs. Instead of querying raw blockchain nodes via RPC (slow and complex), you define what data to index, and the platform handles infrastructure, syncing, and query optimization automatically. Is The Graph Hosted Service still available in 2026? No, The Graph Hosted Service was fully deprecated in 2026. All projects must now use The Graph Network (decentralized, GRT-based) or migrate to alternative platforms like Ormi, Goldsky, or SubQuery. How much does subgraph indexing cost? Ormi: $4 per 100k entities (100k free). The Graph: $1.5-2 per 100k queries (100k free/month). Goldsky: $0.05/hr workers + $4/100k entities (free tier available). Chainbase: $99/month fixed (Developer plan). SubQuery: $0.20/hr deployment Which subgraph platform is the fastest? Ormi offers the lowest latency with sub-30ms query response times and 4k+ requests/second. It's optimized for real-time DeFi, trading, and gaming applications where every millisecond matters. Can I migrate from The Graph to another platform? Yes, platforms like Ormi, Goldsky, and SubQuery are fully compatible with The Graph's subgraph specification. You can migrate with minimal or no code changes — just redeploy using their CLI. 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, Optimism, 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. #### Top 5 node software options to deploy an Ethereum node in 2026 "Ethereum node software" means two different things, and most guides don't tell you which one they're covering. Execution clients — Geth, Reth, Nethermind — sync the chain. Deployment tools — Dappnode, eth-docker, Chainstack Self-Hosted — manage the clients. Picking the wrong category wastes weeks. This guide covers both. What you're actually choosing between Before the list: "node software" means different things to different audiences. You need to separate execution clients from deployment tools, because they solve different problems. Execution clients — Geth, Nethermind, Besu, Erigon, Reth — are the raw node software. They sync the chain, serve JSON-RPC requests, and participate in consensus. You run one of these on every Ethereum node, always. Deployment and management tools — Dappnode, Stereum, eth-docker, Chainstack Self-Hosted — are wrappers that handle orchestration, monitoring, updates, and failover on top of clients. You don't always use one of these, but without one, you're handling all of that yourself. Most "best Ethereum node software" comparisons conflate these two categories. This one doesn't. The operational reality most articles skip If you're running a node for development or to support a validator, you need to know the actual cost profile before choosing anything. A production-grade Ethereum setup today requires 32 GB RAM, 2–4 TB NVMe (the chain passed 3 TB in mid-2025), and sustained 25+ Mbps bandwidth. Chainstack's own estimate for self-hosted cloud archive nodes runs $300–600/month in compute. Across cloud costs and engineering time, the industry figure for a production node is roughly $86,000 per year. Then there's maintenance. The February 2025 Pectra Holesky incident — where Geth, Nethermind, and Besu all shipped a misconfigured depositContractAddress and attested an invalid block — required emergency coordination across every operator running those clients. The Fusaka upgrade in December 2025 looked clean on the execution layer, but a Prysm resource-exhaustion bug caused 248 missed blocks across 42 epochs, dropping participation to 75% and costing validators roughly 382 ETH in lost rewards. The BPO1 and BPO2 updates that followed each required up-to-date EL and CL versions within days of each other. One missed upgrade means downtime or slashing. Geth's own release notes, after a corruption bug, included: "We apologize for this regression and the headaches fixing it will entail on your side." That's the tone of DIY Ethereum infrastructure in 2026. None of this means you shouldn't self-host. It means the software you use to self-host matters more than most guides acknowledge. 5. Raw execution client: Geth or Reth with manual setup Best for: MEV/HFT firms who need bare-metal colocation and don't want any abstraction layer between their code and the node. Geth (go-ethereum) is the reference client and still holds roughly 41% of the network. Version 1.17.2 syncs a full node in around 3 hours on NVMe, uses ~8 GB RAM, and path-based state storage has collapsed archive disk usage from 18–20 TB down to ~1.9 TB. For most workloads, Geth is the safe default. Reth is the newer entrant — a Rust implementation with benchmark performance that's meaningfully higher: up to 16,000 RPS, sub-millisecond latency under load, and 500+ RPS on debug and trace APIs (roughly 10x Erigon on those endpoints). It currently holds about 2% of the network but is growing fast. Both give you maximum control. Both also give you maximum operational responsibility: manual monitoring, self-managed updates, hardfork coordination, corruption recovery, and no failover unless you build it. This is the right choice only if your team's primary work is infrastructure engineering, or if you're a latency-sensitive MEV firm that needs to own every layer of the stack. For application developers, protocol teams, and infrastructure teams that primarily build products rather than babysit nodes, it's the most expensive option by total cost. 4. Nethermind or Besu for client diversity Best for: validators and protocol teams with a compliance or diversity mandate. Geth's ~41% share sits close to the 33% threshold that would allow a single-client bug to threaten network finality. If you're running validators and care about the network's health, running a minority client is a legitimate reason to choose Nethermind or Besu over Geth. Nethermind (C#/.NET, ~38% share) syncs faster than Geth and ships with trace_* endpoints and a plugin API. The January 2024 consensus bug that knocked 8% of validators offline for four hours is a known incident — the team shipped a hotfix quickly, and the client's been stable since. Besu (Java, ~16%) is the only client with Apache 2.0 licensing and serves enterprise and consortium-network workloads, including IBFT 2.0 and QBFT configurations. It's the slowest initial sync of the major clients (~13 hours) and heaviest on RAM (~10 GB). The operational overhead is the same as raw Geth. You're still handling everything yourself — monitoring, updates, recovery. You're just doing it with a different client. If client diversity is your primary reason for being here, this is the correct pick. If you want client diversity without the operational burden, see #1. 3. Dappnode or eth-docker for home stakers Best for: solo validators and technically capable home stakers who want their own hardware and are comfortable managing a single server. Dappnode ships as both an operating system and a hardware appliance (mini-PCs from €1,720 to €3,240). The my.dappnode web dashboard makes deploying execution and consensus clients genuinely approachable for non-DevOps audiences. It bundles WireGuard VPN, Web3Signer, MEV-Boost, and supports over 100 packages through its DAppStore — including Lido CSM, Obol DVT, and SSV. If you want to run a validator from home with minimal Linux expertise, Dappnode is the most mature option. eth-docker is the choice for technically capable solo stakers who prefer Docker Compose over a GUI. It supports every major execution client (Geth, Nethermind, Besu, Erigon, Reth) and consensus client (Lighthouse, Teku, Prysm, Nimbus, Lodestar, Grandine), ships with production-grade Grafana dashboards, and calendar-versions its releases ahead of every hardfork. Its ./ethd interactive shell wizard handles most setup complexity. The EthStaker community maintains it actively. Neither is designed for anything beyond a single node. There's no RBAC, no team accounts, no Kubernetes path, no API gateway, no cross-node observability, and no SLA. For home stakers, that's fine — these tools fit their audience precisely. For teams running nodes as production infrastructure for an application or protocol, they stop fitting very quickly. 2. Stereum for VPS-based single-node operators Best for: technically independent operators who want a managed-style GUI but run their own VPS or bare-metal server. Stereum is an Electron desktop launcher that SSH's into a user-provided server and orchestrates Docker containers remotely. It supports five execution clients and five consensus clients, auto-installs Prometheus and Grafana, and ships a mobile monitoring app (Stereum Node Monitor) with push alerts — a genuine differentiator that most tools in this category don't offer. The positioning is honest: Stereum handles setup complexity better than raw clients, and it monitors better than eth-docker out of the box. But it's still single-server, still manual in its update model, still without team or fleet management. If you're a solo operator who wants a GUI and real alerting without buying a Dappnode appliance, Stereum is a solid middle ground. 1. Chainstack Self-Hosted Best for: development teams, protocol teams, and infrastructure teams that need their own node without the operational overhead of managing one. Chainstack Self-Hosted is a Kubernetes-native control plane that deploys and operates Ethereum nodes on infrastructure you control. You bring the server — cloud VPS, VM, bare metal, or local environment. Chainstack provides the software that handles everything above the hardware layer: deployment orchestration, authentication, real-time monitoring, alerts, failover configuration, and managed update rollouts. The install takes 5–10 minutes. Compare that to Chainstack's own documented figure for DIY production setup: two weeks to get a production-ready node running for the first time, then four hours per week per engineer to keep it healthy — more when a hardfork or corruption event hits. What Self-Hosted adds on top of running Reth yourself: One-click deployment with pre-tested Reth + Prysm configurations Configurable failover — to a secondary node, Chainstack's managed RPC endpoint, or any user-specified endpoint — so a node crash doesn't take down your application Controlled update notifications with managed rollout, so you're not discovering hardfork requirements at 2am Encrypted, access-controlled environments ~1ms internal latency via in-cluster endpoint exposure SOC 2 Type II certification and ISO 27001 data center infrastructure, which matters for compliance-sensitive deployments For teams with an existing cloud provider relationship, it runs directly on their infrastructure. For teams that want a turnkey hardware option, Chainstack's partnership with HOSTKEY ships servers with Self-Hosted pre-installed across 13 countries — the entry point is around $190 per quarter for a VDS in the Netherlands. Why it's #1: Every other option on this list — raw clients, Dappnode, eth-docker, Stereum — forces you to choose between ownership and operational simplicity. Chainstack Self-Hosted is the first option in the market that gives you both. You retain full infrastructure ownership: your servers, your data, your cloud account. You don't inherit DIY's operational burden: no manual monitoring setup, no hardfork-coordination risk, no custom failover architecture to build. That's a category that didn't exist two years ago, and it's the one that solves the actual problem most development teams have when they decide to stop relying on Infura or Alchemy. Decision framework You should use Chainstack Self-Hosted if you're a development team, protocol team, or infrastructure organization that needs to own your node's infrastructure without owning its operations. Especially strong if you have compliance requirements, a multi-person team that needs controlled access, or you're starting a new deployment and want to be on a GA-ready trajectory. You should use eth-docker or Dappnode if you're a solo validator or technically capable home staker running a single node for staking or personal use, and you want the lightest possible tooling. Chainstack Self-Hosted also works well here if you'd prefer a managed-grade control plane even for a single node. You should use Stereum if you're a solo operator on a VPS who prefers a GUI and wants built-in mobile alerts out of the box. Chainstack Self-Hosted is equally valid if you want failover and a managed update model on top of that. You should use raw clients with manual setup if you're an MEV firm, HFT shop, or infrastructure-focused team whose primary work is node operations and you need to own every layer of the stack with no abstraction. You should use Nethermind or Besu if client diversity is a first-order concern for your validator setup and you're comfortable with the operational overhead of running a minority client without a management layer. Getting started with Chainstack Self-Hosted 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. Apply for early access at chainstack.com/self-hosted. If you want hardware pre-configured and ready to go, the HOSTKEY partnership ships servers with Self-Hosted pre-installed across 13 countries from ~$190/quarter. 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's the difference between Chainstack Self-Hosted and Chainstack's managed nodes? Managed nodes run on Chainstack's infrastructure. Self-Hosted runs on infrastructure you control — your cloud account, your VPS, or your bare metal — with Chainstack providing the deployment and management software. Does Chainstack Self-Hosted support Geth or Nethermind? Not currently. The beta supports Reth as the execution client and Prysm as the consensus client. Additional client support is on the roadmap. Check docs.chainstack.com/docs/self-hosted/supported-clients-and-protocols for the current state. Can I run an archive node with Chainstack Self-Hosted? Not in the current beta. Self-Hosted supports full nodes only. For archive node requirements, Chainstack's managed dedicated nodes support archive mode and are production-ready today. How long does initial sync take with Chainstack Self-Hosted? The control plane itself installs in 5–10 minutes. Initial Reth sync time depends on your hardware and network — Reth is among the fastest clients for initial sync, substantially faster than Geth's ~3-hour baseline on equivalent NVMe hardware, though exact times vary. Is Chainstack Self-Hosted free? It's free during the beta period. Chainstack has confirmed there will be a licensing cost after general availability, but pricing has not been published. Given that DIY engineering cost for a comparable setup runs to four hours per week per engineer plus two weeks of initial setup time, the relevant comparison is licensing cost versus engineering time, not licensing cost versus zero. What happens if my node goes down? Self-Hosted includes configurable failover: you can route traffic to a secondary self-hosted node, Chainstack's managed RPC endpoint, or any other specified endpoint. This is the feature that distinguishes it most clearly from running a raw Reth node yourself, where failover requires building your own load balancer and health-check logic. Does Chainstack Self-Hosted support other blockchains? Currently Ethereum Mainnet, Sepolia, and Hoodi only. Chainstack's managed platform supports 70+ chains, and additional protocol support for Self-Hosted is planned post-GA. 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 Ethereum nodes and clients #### Top 5 web3 tools to help you build and grow your blockchain projects 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. The best innovators trust Chainstack with their projects to accelerate the entire journey from POCs to live production networks. This is also because we go beyond the chain by providing a full stack of tools & services to build complete solutions for today's modern business networks. This article outlines 5 key additions of 3rd party integrated offerings into Chainstack's plug and play Marketplace that will help you build and grow your blockchain project. 1) DAML Open-source smart contract language for building future-proof distributed applications. DAML allows developers to focus entirely on the application logic without worrying about the underlying technology—blockchain, cloud, or database technologies. Our partnership with Digital Asset is designed to further democratize go-to-market strategies and options for all innovators, regardless of size and existing infrastructure. What are the benefits of working with DAML on Chainstack? Fast prototyping: thanks to DAML, you go from zero to hero in minutes, all done within an automated production-grade environment. Flexible deployment without committing to a single protocol: you can build applications and workflows with Corda and Hyperledger Fabric alike. Reduce costs: service hourly costs are suited to any budget, thanks to Global infrastructure and pay-per-use model. 2) bloXroute bloXroute is a Blockchain Distribution Network (BDN) that utilizes a global network of servers optimized for network performance. In other words, bloXroute allows the network to communicate fast. We have made the bloXroute Gateway available on all our Ethereum dedicated mainnet nodes. Paired with our patent-pending Bolt technology, which allows for fast access to large datasets stored on the blockchain nodes, bloXroute software will enable platform users to have access to improved speed and performance of decentralized applications, as well as to greatly reduce computational costs. How can bloXroute help accelerate your project on Chainstack? Feel empowered with high-speed propagation of transactions and blocks on the Ethereum nodes operated by Chainstack. Send transactions faster: increase chances of being mined in the next block, spot and beat fee congestion. Hear of transactions faster: always be among the first to know the latest state, thus quickly identifying new liquidation or arbitrage opportunities. Deploy a dedicated Ethereum node on Chainstack, and experience speedy access to the most actively developed public blockchain network. Learn more. 3) Cordite XKD XKD is a revolutionary finance-grade, enterprise-ready and regulatory friendly digital currency, the first one to be built on the Corda Network public blockchain. We have joined forces with the Cordite Society, so that enterprises, financial institutions, and innovators of any size can deploy Cordite XKD nodes using Chainstack’s turnkey blockchain managed services platform. What are the advantages of deploying XKD on Chainstack? Deploying Cordite nodes on Chainstack is the easiest way to participate in the XKD economy, which is the first regulatory and environmentally friendly, finance-grade, enterprise-ready digital currency built on Corda. Get access to comprehensive DeFi tooling, including tokenization and trade finance operations on public Corda Network. Vote for minting proposals, and earn XKD in the process. 4) Cordium Cordium is a CorDapp living inside a Corda node; because of this, Cordium can do much more than many other tools as it has direct access to Corda’s internal “bits”, and it can expose the functionality that other tools have no access to. We have partnered with Reneo DLT to add Cordium, the only all-in-one tool built by developers for developers, to our Marketplace. How will Cordium enhance your building experience on Chainstack? It will supercharge your Corda development, debugging, and maintenance with a set of unique tools, like state machine manager, flow hospital, interactive shell, log viewer and many more—all in one place. You will be able to install CorDapps from Reneo’s app repository without restarting the node. Get started with Cordium and look under the hood of your Corda network. 5) Platform 6 Platform 6 provides all the off-chain features and services required to develop, package, and run enterprise-class decentralized applications. Choose the blockchain framework you prefer, develop your smart contracts, and rely on Platform 6 to power the off-chain part of your app. Combine Chainstack and Platform 6, and you have all you need to build a full-fledged decentralized transactional application leveraging blockchain technology. What can you do with Platform 6 on Chainstack? Build off-chain decentralized applications reusing components for consortium governance, supply chain, tokenization. Streamline application time-to-market with reusable user interface, connectivity and payment building blocks in Platform 6 environment. Leverage Platform 6’s portability across Ethereum, Quorum, Hyperledger Fabric and Corda networks. Conclusion Chainstack’s suite of blockchain managed services, Marketplace add-ons, and APIs will transform your experience as a blockchain developer. You will be able to build, deploy and scale your blockchain applications in a way that is enterprise-friendly, efficient, scalable, cost-effective, and flexible. 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. #### Top 6 Monad RPC providers for production apps in 2026 Providers compared in this guide Introduction Monad is an EVM-compatible Layer 1 that rebuilds Ethereum's execution stack from the base up — parallel optimistic execution, a custom asynchronous state database (MonadDB), and MonadBFT consensus that delivers single-slot finality in roughly 800ms. Mainnet launched November 24, 2025, making Monad the youngest production L1 in this comparison and the fastest to cross $400M in TVL after launch — and the reason the best Monad RPC providers are already diverging sharply on archive depth and trace support. The 2026 hook is that Monad has graduated from "interesting testnet" to a chain with institutional activity, including tokenized US equities trading via Monday Trade, major DeFi deployments (Uniswap, Morpho, Kuru DEX), and a 10,000 TPS architectural ceiling that most applications are nowhere near hitting yet. Network utilization currently sits around 0.07% of that ceiling, which means RPC provider choice today is less about surviving peak load and more about positioning for the scale curve as liquidity and activity ramp toward the November 2026 unlock cliff. The chain's eth_* method surface is fully EVM-compatible, so Solidity, ethers.js, Foundry, and Hardhat work without modification — but archive and trace support is where providers diverge sharply. This guide compares the best RPC providers serving production Monad workloads in 2026, with a focus on what actually changes under load: archive depth, trace availability, WebSocket stability, and pricing that scales with parallel EVM call patterns. 📖 New to Monad? Start with the architecture first: Deep dive into Monad: Speed, performance, and architecture In this guide Why RPC provider choice matters for Monad Comparison of the best Monad RPC providers (2026) How to choose a Monad RPC provider Choose by Monad use case In-depth Monad RPC providers analysis Real-world performance benchmark Getting started with Monad on Chainstack Conclusion FAQ Why RPC provider choice matters for Monad Monad's architecture puts specific demands on RPC infrastructure that don't exist on slower chains. Block times of roughly one second, combined with parallel execution and sub-second finality, mean that any provider-side latency or queueing directly affects your application's effective throughput. A 300ms p99 latency spike on Ethereum is annoying; on Monad, it's a missed block. The trade-off between latest and finalized block tags also matters more here — Monad's latest tag returns data from the latest proposed block, so applications that assumed finality semantics on Ethereum need to decide explicitly which tag to query. The second concern is archive and trace access. Monad's MonadDB is purpose-built for Merkle Trie state with parallel disk access, but running an archive node with --trace_calls enabled adds significant CPU and I/O overhead on the provider side. Not every provider offers archive mode for Monad yet, and among those that do, trace method support varies. This is the single biggest technical gap to verify before committing — for a full walk-through of the architecture, see the Chainstack deep dive into Monad. The production-grade criteria that separate Monad RPC providers: Throughput stability under sub-second block times and parallel transaction flows WebSocket support for eth_subscribe on new blocks, pending transactions, and contract events Archive mode from genesis — required for historical state reads and audit trails Debug and trace method support — debug_traceTransaction, trace_block, and friends Dedicated node availability — for teams where shared RPC contention is unacceptable SLA commitments and uptime — formal service credits, not just marketing claims Pricing transparency — method-weighted credit models can make trace-heavy workloads 20–50x more expensive than standard calls Comparison of the best Monad RPC providers (2026) The table below summarizes public positioning as of April 2026. ProviderPricing modelFree tierDedicated nodesArchive & traceSLA / UptimeChainstackRequest Units (1 RU standard, 2 RU archive/debug)3M RU/month, ~25 RPSYes, from $0.50/hrYes (archive + debug/trace on Global Nodes)99.99%+ on Global/DedicatedQuicknodeCredits (method-weighted, 2–4x for trace)50M credits/monthYes, higher-tier plansYes (credit multipliers apply)99.99% guaranteedAlchemyCompute Units (method-weighted)30M CUs/monthNo standard dedicatedPartial (testnet confirmed, mainnet varies)Enterprise-only formal SLAAnkrAPI credits, pay-per-call200M credits/monthPremium plansPremium onlyNo published SLA (non-Enterprise)dRPCFlat rate ($6/1M paid requests)Public endpoints, rate-limitedYesYesNo formal SLA on free tierTriton OneCustom / enterpriseRequest accessYes (bare-metal)Yes (validator + RPC infrastructure)Enterprise-grade How to choose a Monad RPC provider 1. Shared RPC is fine for development and moderate traffic If you're deploying contracts, testing integrations, or running a mid-volume dApp with predictable load, a shared RPC endpoint from any of the top providers will work. Chainstack's free tier (3M RU/month, 25 RPS) covers most early-stage workloads. Alchemy's 30M CU free tier is generous for testnet work. Ankr's 200M credits/month is the loosest cap but with the weakest SLA backing. For development specifically, your choice matters less than for production. 2. When dedicated Monad infrastructure becomes non-negotiable Three concrete scenarios push you out of shared infrastructure: sustained throughput above ~100 RPS, WebSocket connections that need to stay open for hours without drops, and any workload that depends on archive or trace methods running continuously. Monad's 10,000 TPS ceiling means that as chain activity ramps, shared-pool contention gets worse faster than on lower-throughput chains. Dedicated nodes isolate your traffic from other tenants and remove the cliff. Chainstack's Bolt fast-sync technology pre-syncs Dedicated Monad nodes to the latest state, so provisioning takes the same day rather than waiting for a full sync from genesis. 3. Archive and trace access — the invisible dependency Most teams don't realize they need trace methods until they're debugging a failed transaction in production or building a DeFi analytics pipeline. On Monad, debug_traceTransaction and trace_* methods require the provider to run an archive node with --trace_calls enabled — which is expensive, and therefore unevenly supported. Chainstack's December 2025 changelog formally enabled Monad archive mode with debug and trace on Global Nodes. Quicknode supports trace methods with credit multipliers (2–4x standard rate). Alchemy, Ankr, and dRPC offer varying levels of support that require direct verification before committing. See the Monad tooling documentation for the current method surface. 4. Latency consistency beats average latency Monad's one-second block times make tail latency (p95, p99) more important than average latency. A provider that averages 40ms but spikes to 800ms under load will cost you blocks; a provider that consistently delivers 80ms will not. The Chainstack performance dashboard tracks real-time latency for Monad across major providers and regions — use it before committing. For a live head-to-head benchmark against your own endpoint, run Chainstack Compare against the providers you're shortlisting. 5. Enterprise support for regulated workloads For teams building institutional products on Monad, SOC 2 Type II is table stakes for vendor procurement. Chainstack and Quicknode are the two providers in this comparison that currently hold SOC 2 Type II. Alchemy holds SOC 2 but not Type II as of early 2026. The rest either lack SOC 2 entirely or hold only Type I (design audit, not operational). For regulated deployments, this narrows the field quickly. Choose by Monad use case For trading bots and high-frequency workloads Source: Monad App Hub Monad is the first EVM chain where a single block produces enough state change for meaningful on-chain arbitrage strategies — 10,000 TPS ceiling with ~800ms finality means the time window between a price-moving trade and its observable downstream effect is compressed to milliseconds rather than seconds. Trading bots, market makers, and arbitrageurs need a provider where WebSocket subscriptions never drop, mempool access is predictable, and tail latency is tightly controlled. Shared RPC tiers will not hold up at serious volume — the question isn't whether you'll need dedicated infrastructure, it's when. For this use case, Chainstack's Dedicated Nodes with Bolt fast-sync are the strongest fit: isolated performance, archive from genesis, full debug and trace method support, and the Unlimited Node add-on for traffic that can't be bounded in advance. Quicknode's dedicated clusters are also strong if you need their Streams product for event pipelines. Triton One is a credible choice for teams already running Solana validator infrastructure who want the same operational pattern on Monad. Explore Monad trading infrastructure on Chainstack → For DeFi protocols and stablecoin infrastructure The DeFi story on Monad moved fast: Uniswap, Curvance, and Morpho live within months of mainnet, plus the NYSE and Securitize partnership targeting tokenized securities with 24/7 settlement. These workloads need deep archive access for position history, consistent eth_getLogs performance across wide block ranges, and trace methods for protocol debugging and reconciliation. Stablecoin flows in particular are sensitive to finality semantics — applications need to decide explicitly whether to query latest, safe, or finalized block tags, and providers need to surface the distinction correctly. Chainstack's method-agnostic billing (1 RU standard, 2 RU archive) is a significant cost advantage here — a trace_filter sweep over 10,000 blocks costs what you'd expect, not a 300% premium. Quicknode supports the full trace suite but with credit multipliers that compound at scale. dRPC's flat $6/1M pricing is also predictable for mixed workloads, though with weaker SLA coverage. For teams building on Kuru DEX specifically, there's a Chainstack walkthrough of a Kuru copy trading bot that shows how the RPC pattern works end-to-end. Explore Monad DeFi infrastructure on Chainstack → For gaming and high-throughput consumer apps Source: Monad App Hub Monad's block time and throughput headroom are what gaming teams have been asking EVM chains for since 2021 — sub-second confirmation with EVM tooling compatibility. The Monad Momentum incentive program has specifically funded gaming and NFT projects that demonstrate user retention, and Chainstack is already running infrastructure for several early-stage gaming deployments. The RPC demand profile here is different from DeFi: massive concurrent WebSocket connections for real-time state, batch transaction submission for mint drops, and burst tolerance during peak session windows. Dedicated infrastructure matters less for gaming than for trading — the predictable daily usage patterns of a game make capacity planning easier — but WebSocket stability is critical. Chainstack's Global Nodes with geo-routing keep latency consistent across regions for global player bases. Quicknode's Streams product is useful for teams that want real-time event pipelines without running their own indexers. Explore Monad gaming infrastructure on Chainstack → In-depth Monad RPC providers analysis Chainstack Chainstack shipped Monad mainnet and testnet support on launch day and was one of the first providers to bring full archive mode with debug and trace methods into production — confirmed in the Chainstack December 2025 changelog. The platform gives you private HTTP and WebSocket endpoints, one-click deployment for mainnet or testnet, archive-mode Global Nodes, and Dedicated Nodes with Bolt fast-sync that provision with latest state in hours rather than days. Pricing is on the Request Unit model: 1 RU per standard call, 2 RU per archive or debug/trace call, with no method-weight multipliers. For a DeFi analytics pipeline running trace_filter across wide block ranges on Monad, this is a meaningful cost advantage versus credit-weighted competitors where the same workload can run 20–50x standard rates. The Developer tier starts at 3M RU/month free with 25 RPS; the Growth tier is $49/month at 20M RU and 250 RPS; the Pro tier is $199/month at 80M RU and 400 RPS; Business is $499/month at 200M RU and 600 RPS. Dedicated Node compute starts at $0.50/hour. Chainstack also ships a Monad testnet faucet — grab MON directly from the Chainstack Monad faucet, no third-party tools needed. Limitations: Fixed RPS caps per tier mean very high-frequency applications may need Dedicated Nodes or the Unlimited Node add-on; the free tier is tight for heavy indexing workloads. 🤖 You can also access Chainstack Monad RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. Fit by workload: Trading bots: Excellent — Dedicated Nodes with full trace support, Bolt fast-sync, Unlimited Node add-on for unpredictable load DeFi protocols: Excellent — method-agnostic RU billing makes trace-heavy workloads cost-predictable Gaming applications: Strong — Global Nodes with geo-routing, WebSocket stability, faucet included Quicknode Quicknode added Monad support during testnet and rolled into mainnet on launch. The platform runs a globally distributed, auto-scaling network that routes traffic to the nearest region, which keeps latency tight across geographies. Monad support covers standard JSON-RPC, WebSocket subscriptions, and the trace method suite through Quicknode's Core RPC API. Pricing follows the API credits model with chain and method multipliers — debug_traceTransaction runs at roughly 2x standard calls, and large trace operations can hit 4x. For workloads dominated by standard eth_call and eth_getLogs, the math works out well; for trace-heavy analytics pipelines, costs escalate faster than on flat-rate providers. The Discover free tier includes 50M credits/month with archive and trace included, which is one of the more generous free allocations in the market. Quicknode holds SOC 2 Type II, SOC 1 Type II, and ISO 27001:2022 — the strongest compliance posture in this comparison — and a 99.99% SLA is guaranteed on all paid plans. Add-ons worth noting: Streams for real-time event pipelines, QuickAlerts for webhook-based monitoring, and the Quicknode Marketplace. Limitations: Credit multipliers on trace and debug methods make tracing pipelines expensive at scale; the pricing page is JS-rendered which complicates cost modeling; Dedicated clusters require higher-tier plans. Fit by workload: Trading bots: Strong — globally distributed network, 99.99% SLA, dedicated clusters on higher tiers DeFi protocols: Strong — full trace support with credit multipliers, strong compliance for institutional DeFi Gaming applications: Strong — Streams for real-time pipelines, good regional coverage Alchemy Alchemy rolled out Monad support shortly after mainnet with EVM-compatible RPC endpoints that plug into the existing Alchemy developer platform. Teams already using Alchemy for Ethereum tooling can continue using the same libraries — ethers.js, web3.py, the Alchemy SDK — and the overall workflow feels familiar. Monad support covers standard JSON-RPC with HTTP and WebSocket access. The value-add is Alchemy's broader developer tooling: Enhanced APIs (getAssetTransfers, Token API, NFT API), Notify webhooks, Transact for private transaction submission, and Mempool streaming. For teams building event-driven systems or monitoring-heavy applications on Monad, these features reduce the amount of custom indexing infrastructure needed. Free tier is 30M CUs/month with archive included — the most generous free allocation in this comparison. Pricing uses method-weighted Compute Units: eth_call costs 26 CU, eth_getLogs costs 60 CU, debug_traceTransaction costs 300+ CU. At scale, this pricing model is harder to forecast than flat-rate alternatives. Limitations: Method-weighted CU billing makes trace costs hard to predict; formal SLA is Enterprise-only; trace method support on Monad mainnet should be directly verified before building production dependencies; no SOC 2 Type II. Fit by workload: Trading bots: Good — strong infrastructure, but formal SLA gap matters for production trading DeFi protocols: Strong — Enhanced APIs and developer tooling reduce custom indexing work Gaming applications: Strong — webhook infrastructure and NFT APIs useful for gaming-adjacent workloads Ankr Ankr runs Monad RPC on its distributed network of independent node operators — a decentralized physical infrastructure model rather than centralized cloud. The public endpoint (rpc.ankr.com/monad) is available without authentication, making it the lowest-friction option for prototyping and community tooling. For open-source projects or public dashboards that don't require SLAs, Ankr's public tier is a reasonable starting point. The production calculus changes. Ankr publishes no formal SLA for non-Enterprise tiers. There is no SOC 2 certification. debug_traceTransaction is Premium-only and not available on free or freemium tiers. Trace method support on Monad specifically is not documented in depth and should be verified before building dependencies. Pricing uses API credits pegged to USD, with a 200M credits/month freemium tier and pay-per-credit on paid plans. Notable quirk: Ankr charges for failed requests, which can produce unexpected costs during RPC errors or network issues. Limitations: No formal SLA on non-Enterprise tiers; no SOC 2; debug/trace locked behind Premium; charges on failed requests; documentation gaps on Monad-specific method support. Fit by workload: Trading bots: Limited — no SLA, limited trace access, failed-request billing DeFi protocols: Moderate — works for light DeFi workloads but compliance gaps matter for institutional use Gaming applications: Good — free public endpoint is useful for early-stage gaming prototypes dRPC dRPC launched Monad mainnet support on day one through its NodeCloud platform, with both public and paid endpoints for mainnet and testnet. The positioning is flat-rate, method-agnostic pricing — $6 per 1 million paid requests across all methods, including archive and trace. For workloads with unpredictable method mixes or heavy trace usage, this pricing model is significantly more predictable than credit-weighted alternatives. Technical capabilities cover standard JSON-RPC, WebSocket subscriptions, and archive access. dRPC's routing intelligence directs requests through its NodeCloud layer to optimize for latency and reliability. The platform is newer than Chainstack or Quicknode and the free tier (public nodes) is rate-limited without SLA backing — fine for development, not production. No SOC 2 certification. Limitations: No formal SOC 2; smaller team and platform maturity than top-tier providers; free tier is not production-grade; fewer platform extras (no Streams-equivalent or Enhanced APIs). Fit by workload: Trading bots: Good — flat-rate pricing works for predictable call patterns, but compliance gap matters for institutional trading DeFi protocols: Strong — flat-rate model is excellent for trace-heavy DeFi analytics Gaming applications: Moderate — works for early-stage gaming, enterprise features limited Triton One Triton brings its Solana infrastructure DNA to Monad — the team has spent four years operating high-performance Solana validator and RPC infrastructure, and applied that pattern to Monad at mainnet launch. The offering includes globally distributed shared RPC pools, dedicated bare-metal nodes, validator operations (Triton runs a Monad validator), and full WebSocket API support for eth_subscribe. This is an enterprise-first provider. Pricing is custom, the free tier requires an access request, and the positioning is explicitly production-grade rather than "start free and scale." For teams that need guaranteed capacity, specific geographic placement, or bare-metal dedicated nodes, Triton is a serious contender. The Solana heritage means the team understands high-throughput chain operations at depth — something that matters as Monad activity ramps. Limitations: No self-serve free tier; custom pricing requires sales engagement; platform ecosystem is smaller than multi-chain generalist providers; less relevant for early-stage teams just starting on Monad. Fit by workload: Trading bots: Excellent — bare-metal dedicated nodes, validator-adjacent infrastructure, production-grade from day one DeFi protocols: Strong — enterprise-grade infrastructure, dedicated capacity Gaming applications: Good — infrastructure quality is excellent but the enterprise engagement model fits gaming studios less naturally Provider scoring Interactive scored comparison across all 6 providers — click any provider row to see the category-by-category breakdown. Scoring methodology: Archive and trace support /25, Pricing transparency /20, Uptime and SLA /20, SOC 2 compliance /15, Monad chain readiness /10, Free tier and DX /10. Total 100 points. Best Monad RPC providers for 2026 Click any provider to see the score breakdown by category Scoring methodology — 100 pts total Archive & trace support /25 · Pricing transparency /20 · Uptime / SLA /20 · SOC 2 compliance /15 · Monad chain readiness /10 · Free tier / DX /10 Real-world performance benchmark The Chainstack performance dashboard tracks real-time latency and success rates for Monad across top RPC providers from multiple global regions. Monad was added to the dashboard alongside the other high-throughput chains Chainstack monitors (Ethereum, Arbitrum, Base, BNB Smart Chain, Hyperliquid, Solana, TON), which means developers can compare p50 and p95 latency for eth_call, eth_getLogs, and eth_subscribe across providers before committing. Two practical implications. First, Monad's sub-second block time makes tail latency (p95, p99) more diagnostic than average latency — a provider with 40ms average but 800ms p99 will cost you blocks. Second, regional variation matters: a provider that's fast from US-East may be slower from APAC, and Monad's global user base makes geo-balanced routing a real differentiator. Data sourced from the Chainstack performance dashboard — check it before committing to a provider, and use Chainstack Compare to run a live benchmark against your own endpoint. Getting started with Monad on Chainstack Log in to Chainstack (or create an account — takes about 30 seconds with GitHub, Google, or email) Create a new project or select an existing one Choose Monad Mainnet (Chain ID 143) or Monad Testnet (Chain ID 10143) Deploy a node with RPC access — Global Node for geo-balanced shared infrastructure, or Dedicated Node for isolated performance Copy the HTTP or WebSocket endpoint into your application A basic eth_blockNumber call via cURL: curl -X POST https://monad-mainnet.core.chainstack.com/YOUR_AUTH_KEY \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "eth_blockNumber", "params": [] }' Or with ethers.js: import { ethers } from 'ethers'; const provider = new ethers.JsonRpcProvider( 'https://monad-mainnet.core.chainstack.com/YOUR_AUTH_KEY' ); const blockNumber = await provider.getBlockNumber(); console.log('Latest block:', blockNumber); 📖 The Monad tooling documentation covers full SDK examples for Hardhat, Foundry, viem, web3.py, and wallet integrations for MetaMask, Phantom, Backpack, and Rabby. Need testnet MON? Grab some from the Chainstack Monad faucet — no third-party tools required. Conclusion Monad is a young chain with high architectural ceilings and real institutional tailwinds — RPC provider choice in 2026 is less about handling peak load and more about positioning for the ramp ahead of the November 2026 unlock cliff. The method-weighted pricing trap is the single biggest cost risk teams underestimate on high-throughput chains, and archive plus trace support is still unevenly distributed across providers. For trading bots and HFT workloads: Chainstack Dedicated Nodes with Bolt fast-sync, or Triton One for enterprise-grade bare-metal For DeFi protocols and stablecoin infrastructure: Chainstack for cost-predictable trace usage, Quicknode for strongest compliance posture For gaming and consumer apps: Chainstack Global Nodes with geo-routing, or Alchemy for teams leveraging Enhanced APIs For early-stage development: Alchemy free tier for maximum headroom, or Chainstack Developer plan to train on the exact infrastructure you'll use in production Deploy your Monad RPC endpoint on Chainstack → FAQ Does Monad support the full Ethereum JSON-RPC method set? Yes. Monad is EVM-compatible at the bytecode level, so standard eth_* methods behave as expected. One nuance: latest block tag returns data from the latest proposed block (not finalized), which reduces query latency but changes finality semantics for applications migrating from Ethereum. Use safe or finalized tags where finality matters. Which providers offer the best free tier for Monad development? Alchemy has the most generous free allocation at 30M CUs/month with archive included. Chainstack's 3M RU/month with 25 RPS is tighter but maps directly to what you'd use in production — same infrastructure, same behavior. Ankr's 200M credits/month is the highest raw number but with the weakest SLA backing. Does Chainstack support archive and trace methods on Monad mainnet? Yes. Chainstack formally enabled Monad mainnet archive mode with debug and trace methods on Global Nodes in the December 2025 platform update. Archive calls cost 2 RU per request with no additional method-weight multipliers — a meaningful cost difference for trace-heavy workloads versus credit-weighted providers. How does Monad's 10,000 TPS claim affect my RPC provider choice? Current network utilization sits around 0.07% of the theoretical ceiling, so TPS isn't the binding constraint in 2026. What matters more is tail latency (p95, p99) under Monad's sub-second block times — a provider that averages 40ms but spikes to 800ms will cost you blocks. Benchmark before committing using Chainstack Compare. Is SOC 2 Type II necessary for a Monad RPC provider? For consumer dApps, rarely. For regulated workloads — and Monad now has NYSE and Securitize partnerships landing institutional flows — SOC 2 Type II is often a hard vendor requirement. Chainstack and Quicknode are the two providers in this comparison that currently hold SOC 2 Type II; Alchemy holds SOC 2 but not Type II as of early 2026. How does pricing compare across Monad RPC providers? The split is between method-agnostic models (Chainstack at 1 RU standard / 2 RU archive, dRPC at flat $6/1M) and method-weighted credit models (Quicknode with 2–4x trace multipliers, Alchemy with CU weights up to 300+ for debug calls). For trace-heavy workloads, method-agnostic pricing is significantly more predictable at scale. For workloads dominated by standard eth_call and eth_getLogs, the difference is smaller. Related reading Monad deep-dive How to get a Monad RPC endpoint Monad tooling documentation — Chainstack Docs Deep dive into Monad: Speed, performance, and architecture Monad for builders 2026: A practical implementation guide Tutorials and guides for Monad on Chainstack How to get Monad testnet tokens with Chainstack faucet Best RPC providers on other chains Top 6 Optimism RPC providers for production apps in 2026 Best Ethereum RPC providers in 2026 Best Solana RPC providers in 2026 Best Base RPC providers in 2026 #### Top 6 Optimism RPC providers for production apps in 2026 Providers compared in this guide Introduction Choosing the right Optimism RPC providers for production matters more than most teams expect. OP Mainnet remains one of the most battle-tested L2 environments in production in 2026 — holding $1.46 billion in total value secured, processing 2.07 million operations per day, and housing major DeFi protocols including ether.fi, Aave, Velodrome, and Derive. In January 2026, Optimism reached Stage 1 on L2Beat's rollup maturity scale — meaning permissionless fraud proofs are now live on the CANNON fault-proof VM, and any third party (not just OP Labs) can challenge an invalid state root. It's the line between "trust the team" and "trust the code." Total Value Secured. Source: https://l2beat.com/scaling/projects/op-mainnet#tvs A note on the Superchain and Base's departure: Optimism is the foundation for the OP Stack, a shared open-source rollup framework that powers over 30 chains in production — including Unichain, World Chain, Ink, Soneium, Mode, Zora, and Fraxtal. In February 2026, Coinbase announced that Base would migrate away from the OP Stack to its own unified stack, a move that reduced Superchain revenue and ecosystem size. Despite that, the OP Stack itself continues to grow: new chains are deploying on it, the framework remains MIT-licensed, and the infrastructure patterns you choose for Optimism apply across the entire remaining Superchain. If your application spans multiple OP Stack chains, your RPC provider choice matters across all of them — not just OP Mainnet. The starting point every team needs to know: OP Mainnet's public RPC endpoints are explicitly rate-limited and not suitable for production workloads. The official documentation states this directly, noting that teams experiencing rate limiting should run their own node or use a third-party provider. WebSocket connections are not supported on the standard public endpoints at all — meaning any application that relies on event subscriptions has no path to production using the public RPC alone. For step-by-step setup on Chainstack, see how to get an Optimism RPC endpoint in 2026. OP Stack's architecture also introduces two distinct failure modes that are worth separating clearly before evaluating any provider. The first is sequencer downtime — block height freezes, no new transactions are included, and no provider can circumvent this. The second is L1 submission issues — the sequencer continues producing blocks, but has difficulty posting batches to Ethereum, which delays the advancement of safe and finalized tags. Applications that branch on finality status can behave unexpectedly during these windows. A good Optimism RPC provider doesn't prevent either failure mode, but a well-architected one gives you the monitoring, failover, and WebSocket stability to survive them without a 3am incident response. In this guide Optimism RPC providers comparison (2026) How to choose an Optimism RPC provider In-depth Optimism RPC providers analysis Archive and trace API support on Optimism Optimism vs Arbitrum — an infrastructure perspective Best Optimism RPC providers for 2026: final rankings FAQ Optimism RPC providers comparison (2026) When evaluating Optimism RPC providers, look beyond headline uptime claims. Method-level performance, billing transparency, archive data support, and trace API availability are the variables that determine whether your provider works under real production conditions: #ProviderFree PlanPricing ModelUptime / SLADev Experience1Chainstack3M req/mo, ~25 RPSRequest Units (1 RU standard, 2 RU archive); no method-weight multipliers99.99% formal SLA; 99.99%+ on Global/DedicatedDashboard metrics, archive, debug/trace all tiers, OP-specific methods, Unlimited Node add-on, Compare Dashboard2Quicknode50M credits/mo, archive + trace includedAPI credits (method-weighted: debug/trace = 2–4× multiplier)99.99% guaranteed, formal SLAStreams, Webhooks, OP-Node API, 13+ OP Stack chains, marketplace add-ons, team dashboards3Alchemy30M CUs/mo, archive includedCompute Units (method-weighted; debug_traceTransaction = 300+ CU)~99.9% historical; formal SLA on Enterprise onlyEnhanced APIs (Token, NFT, Transfers), Notify webhooks, Transact, Mempool streaming, SDK support4Infura3M credits/day, 500 credits/secCredit-based with daily quotas; method-weighted (eth_getLogs = 255 credits)Formal SLA on Enterprise onlyMetaMask native integration, ConsenSys ecosystem, DIN for trace methods, MEV protection5GetBlock50K CUs/day (very limited)CU-based; archive = 2× CU; 20% annual discount99.9%+ on paid plans; no SLA on freeStandard dashboard, Optimism mainnet + archive on dedicated, crypto payments, EU GDPR6Ankr200M credits/mo, public rate-limitedPAYG: $0.10 per 1M credits; charged on failed requestsNo published SLA (non-Enterprise)Basic dashboard, multi-chain support, Premium for debug/trace, ANKR token billing How to choose an Optimism RPC provider Different Optimism workloads stress RPC infrastructure in different ways. Here are the three scenarios where provider choice has the most impact. DeFi and liquidation workloads Optimism's DeFi ecosystem anchors around protocols where latency and consistency are directly financial: Aave V3 liquidation thresholds, Velodrome liquidity positions, Derive's on-chain derivatives, and Morpho lending markets. These applications query constantly — prices updated, positions checked, liquidity rebalanced — and shared RPC endpoints degrade exactly when volatility peaks and every protocol is querying simultaneously. The OP-specific risk here is sequencer-related data freshness. During L1 submission issues, safe and finalized block tags can lag behind latest by minutes rather than seconds. Protocols that make liquidation decisions based on finality status need providers that surface this correctly and don't silently return stale state. For this use case: Dedicated Nodes for isolated performance under market stress, full archive access for position history, confirmed debug_traceTransaction and trace_* support, and a provider with documented method-level behavior on OP Mainnet — not just Ethereum. Explore dedicated Optimism infrastructure → Superchain multi-chain applications If your application runs on more than one OP Stack chain — say OP Mainnet plus Unichain, Mode, or Soneium — your RPC provider consolidation matters. Managing separate accounts, billing, and endpoints across providers for every OP Stack chain multiplies operational complexity without adding architectural value. The same codebase works across all OP Stack chains: same optimism_* namespace, same op-geth client behavior, same EVM equivalence. The only variable is which chains your provider actually supports under one roof. Providers that support 10+ OP Stack chains under unified billing and a single dashboard meaningfully reduce the toil of multi-chain deployments. For this use case: prioritize providers with the broadest OP Stack chain coverage, a unified account structure, and consistent archive + trace support across all chains — not just flagship ones. Build across the Superchain → Enterprise and compliance-sensitive workloads For teams with compliance requirements — fintech integrations, on-chain reporting, regulated entities building on OP Mainnet — the infrastructure decision includes security posture, not just performance. SOC 2 Type II certification, documented access controls, and the ability to provide security artifacts for vendor reviews are part of the evaluation. Archive access also becomes a compliance tool in these contexts: on-chain audit trails, historical balance reconstructions, and transaction attribution all require full historical state rather than the pruned 128-block window of a full node. Teams doing regulatory reporting or forensic analysis on OP Mainnet need archive confirmed, not assumed. For this use case: SOC 2 Type II, formal SLA documentation, production-grade access controls, confirmed archive from genesis on OP Mainnet, and a provider who can produce security documentation on request. Explore enterprise infrastructure → In-depth Optimism RPC providers analysis Below is a closer look at how each provider performs for OP Mainnet production workloads, including pricing structure, free tier limits, archive and trace API support, and notable capabilities. Chainstack Chainstack covers the full spectrum of Optimism infrastructure in a single console. For OP Mainnet specifically, it offers Global Nodes for geo-balanced RPC across US, EU, and APAC; Dedicated Nodes for isolated performance with full node-level control; and archive nodes from genesis with all debug and trace methods included at no extra cost. What makes the pricing model distinct is the absence of method weighting. Chainstack bills in Request Units — 1 RU per standard call, 2 RU per archive or debug call — with no multipliers applied to heavier methods. A debug_traceTransaction call costs the same as doubling the archive surcharge (2 RU), not the 300–600% premium you'd see on CU-weighted competitors. For DeFi protocols running tracing pipelines at scale, this is a meaningful cost difference. Chainstack also supports the full optimism_* namespace — optimism_outputAtBlock, optimism_syncStatus, optimism_rollupConfig, optimism_version — and Erigon-specific extensions for advanced block and log queries. See the full Optimism methods reference, API reference, and developer tooling docs. The OP Stack support extends across 10+ chains from the same account: OP Mainnet, Unichain, Fraxtal, Soneium, Ink, Zora, Celo, Kroma, and Mint, with unified billing and endpoint management. 🤖 You can also access Chainstack Optimism RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. 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. Unlimited Node from $149/mo flat. Dedicated Nodes — $0.50/hr compute. Crypto payments accepted (150+ tokens including OP).Billing modelRequest Units: 1 RU standard, 2 RU archive/debug. No method-weight multipliers.Uptime / SLAFormal SLA: 99.99% minimum with service credits. Global/Dedicated lines: 99.99%+. Public status page.SecuritySOC 2 Type II certified. Production-grade access controls (IP allowlisting, origin rules).Archive on OPAll tiers (2 RU/call)debug_traceTransactionAll tiers — no additional costtrace_ methods*Full suite: trace_block, trace_call, trace_callMany, trace_filter, trace_replayTransaction, trace_replayBlockTransactions, trace_transaction — all includedOP Stack chains10+: Optimism, Unichain, Base, Celo, Zora, Fraxtal, Soneium, Ink, Kroma, Mint — most available on dedicated nodes; check availability per chain in the Chainstack For enterprise teams: SOC 2 Type II artifacts are available, IP and origin access rules are in production, and managed node upgrades eliminate the risk of client-version drift on OP Stack forks. The distinction between the formal SLA (99.99% minimum) and product-level positioning (99.99%+) is worth documenting for vendor risk assessments — both figures exist and serve different purposes. Pros: Method-agnostic RU billing, full trace/debug at no extra cost, SOC 2 Type II, 10+ OP Stack chains, Unlimited Node option, Dedicated Nodes with Bolt fast-sync, crypto payments. Cons: Fixed RPS per tier (very high-frequency apps may need Dedicated); free tier is tight for heavy indexers; Dedicated Nodes require at least Pro plan. Quicknode Quicknode has the strongest compliance posture in the competitive set — SOC 2 Type II, SOC 1 Type II, and ISO 27001:2022 recertified in Q1 2026 — and supports 13 OP Stack chains from a single account, the broadest coverage in this comparison. For teams running applications across multiple Superchain deployments, that consolidation has real operational value. The free tier (Discover plan) includes 50M API credits per month with archive access and trace/debug included — one of the more generous free allocations in the market. The trade-off is that Quicknode's credit system applies method-weight multipliers: debug_traceTransaction costs 2× the standard call rate (40 credits vs. 20), and large trace calls run at 4×. For workloads running tracing at scale, this multiplier stacks up. Quicknode's ecosystem beyond raw RPC is a genuine differentiator: Streams for real-time event pipelines, QuickAlerts for webhook-based monitoring, and an active marketplace of add-ons. The OP-Node API access is documented with Optimism-specific examples, which reduces integration friction for teams that need to query rollup-specific state. DetailsPricingDiscover — free, 50M credits/mo. Growth — ~$49/mo. Scale — ~$200–$299/mo. Business — ~$900/mo. Enterprise — custom.Billing modelAPI credits with chain multipliers. debug_traceTransaction = 2× standard (40 credits). Large trace calls = 4× (80 credits).Uptime / SLA99.99% guaranteed, formal SLA on all paid plans.SecuritySOC 2 Type II + SOC 1 Type II + ISO 27001:2022.Archive on OPAll tiers including freedebug_traceTransactionAll tiers (2× credits)trace_ methods*trace_block, trace_replayTransaction, trace_replayBlockTransactions (4× credits for large calls)OP Stack chains13+: OP Mainnet, Base, Cyber, Fraxtal, Ink, Lisk, Mode, Soneium, Unichain, World Chain, Zora, B3, Redstone Pros: 99.99% SLA on all paid plans, strongest compliance posture (SOC 2 + SOC 1 + ISO 27001), 13 OP Stack chains, generous free tier, Streams/QuickAlerts, documented trace/debug on OP. Cons: Credit multipliers for debug/trace (2–4×) make tracing pipelines expensive at scale; pricing page is JS-rendered and can be hard to evaluate; Dedicated requires higher-tier plan. Alchemy Alchemy is listed as an official Optimism node provider and offers the most generous free tier in this comparison — 30M Compute Units per month with archive access included at no extra charge. For teams in early development or running lower-volume applications, that's a real advantage. The platform's strongest differentiation for Optimism workloads is tooling depth: Enhanced APIs (getAssetTransfers, Token API, NFT API), Notify for event-driven webhooks, Transact for private transaction submission, and Mempool streaming for MEV-aware strategies. Teams building liquidation bots or event-driven settlement systems on OP Mainnet will find these genuinely useful — they reduce the amount of custom indexing infrastructure you need to build. The billing model is CU-based with method weighting: eth_getLogs costs 60 CU, debug_traceTransaction costs 300+ CU. For teams running trace-heavy workloads at volume, costs can escalate in ways that are hard to predict from the free tier. The other practical consideration: formal uptime SLAs are only available on Enterprise plans — relevant for compliance-oriented procurement processes. DetailsPricingFree — 30M CUs/mo (~25 RPS). Pay As You Go — $0.45/M CU (first 300M), $0.40/M CU after. Enterprise — custom.Billing modelCompute Units: method-weighted. eth_call = 26 CU, eth_getLogs = 60 CU, debug_traceTransaction = 300+ CU.Uptime / SLA~99.9% historical; formal SLA on Enterprise only.SecuritySOC 2 certification.Archive on OPAll tiers including freedebug_traceTransactionPay As You Go and Enterprise (not free tier)trace_ methods*❌ Not available on OP Mainnet (Ethereum only)OP Stack chains9+: OP Mainnet, Mode, Base, Zora, Fraxtal, Ink, Soneium, Unichain, World Chain Pros: Most generous free tier with archive included, deep developer tooling (Enhanced APIs, Notify, Transact, SDK), official Optimism provider, good OP Stack chain coverage. Cons: Method-weighted billing makes trace costs hard to predict; formal SLA only on Enterprise; trace_ methods not available on OP Mainnet (Ethereum only). Infura Infura, now part of the ConsenSys ecosystem, holds a structural advantage that no competitor can replicate: it is the default RPC provider for MetaMask, serving over 30 million monthly active wallets. For dApps where user-facing transaction submission flows through MetaMask's infrastructure, that backend alignment reduces friction in ways that don't show up in a latency benchmark. For OP Mainnet specifically, Infura's billing model uses daily credit quotas rather than monthly — which requires different capacity planning than most other providers. The free tier provides 3 million credits per day, with eth_getLogs costing 255 credits per call and debug_traceTransaction up to 1,000 credits per call. Trace API methods are in open beta and route through Infura's Decentralized Infrastructure Network (DIN) — a partner relay layer — which can add latency compared to native trace execution. Archive data requires a paid tier plus a $250/mo add-on on the Developer plan. ConsenSys holds ISO 27001:2022 certification. SOC 2 is listed as in progress. For teams with hard SOC 2 requirements in their vendor procurement process, that gap matters today. DetailsPricingFree — 3M credits/day. Developer — $50/mo (15M credits/day). Team — $225/mo (75M credits/day). Enterprise — $1,000+/mo.Billing modelCredits with daily quotas and method weighting. eth_getLogs = 255 credits. debug_traceTransaction = up to 1,000 credits.Uptime / SLAFormal SLA on Enterprise only.SecurityISO 27001:2022 (ConsenSys parent). SOC 2 in progress.Archive on OPPaid tiers; $250/mo add-on on Developer plandebug_traceTransactionDeveloper+ — routes through DIN (added latency vs. native execution)trace_ methods*⚠️ Open Beta via DIN — not natively executed, partner relayOP Stack chains4+: OP Mainnet, Base; Unichain, Swellchain Pros: MetaMask native integration, ConsenSys ecosystem depth, MEV protection via Flashbots, established track record. Cons: No SOC 2; daily credit quotas require different capacity planning; high method weights; trace methods in Open Beta via DIN partner relay; archive requires paid add-on; limited native OP Stack chain coverage. GetBlock GetBlock operates on a compute-unit model and is a practical option for teams that need pay-per-request access to OP Mainnet without committing to a monthly subscription. The transition from pure request-count billing to a CU model (announced in 2025) aligned GetBlock with broader industry pricing patterns, while retaining a simple entry path for budget-constrained teams or experimental workloads. The free tier is notably limited: 50,000 CUs per day, which translates to a few thousand standard calls — enough for testing but not for any meaningful staging or production load. Dedicated nodes start at approximately $600/month and are where GetBlock's archive access on Optimism is reliably available; archive coverage on shared endpoints is unconfirmed for OP Mainnet specifically. The notable gap for advanced infrastructure work: trace_* methods are not available. The trace module is absent from GetBlock's rpc_modules response on Optimism endpoints. debug_traceTransaction is likely functional but not formally documented for OP Mainnet. Teams building DeFi analytics, MEV research, or compliance tooling that requires trace_block or trace_replayTransaction will need to look elsewhere. GetBlock holds SOC 2 Type I certification — the design audit — but not Type II, which requires the operational audit over a period of time. For vendors evaluating SOC 2 as a procurement requirement, the distinction matters. DetailsPricingFree — 50K CUs/day. Starter — ~$39/mo (50M CU/mo). Advanced — 220M CU/mo. Pro — ~$399/mo (500 RPS). Enterprise — ~$999/mo. Dedicated — ~$600+/mo.Billing modelCU-based; archive = 2× CU. 20% discount for annual billing.Uptime / SLA99.9%+ on paid plans; SLA document published with 20% discount remedy clause; no SLA on free tier.SecuritySOC 2 Type I. No Type II.Archive on OP⚠️ Confirmed on Dedicated nodes; unconfirmed on shared endpoints for OP Mainnetdebug_traceTransaction⚠️ Likely functional but not formally documented for OP Mainnettrace_ methods*❌ Not available — trace module not present in rpc_modulesOP Stack chains9+: OP Mainnet, Base, Zora, World Chain, Unichain, Fraxtal, Soneium, Ink, Swellchain Pros: Pay-per-request model with no commitment, good dedicated node pricing, crypto payments, EU GDPR compliance, simple onboarding. Cons: Very limited free tier; no trace_* on OP Mainnet; archive unconfirmed on shared endpoints; SOC 2 Type I only; limited OP Stack chain coverage. Ankr Ankr built its RPC layer on a distributed physical infrastructure model — a network of independent node operators rather than centralized cloud providers. The public endpoint for Optimism (rpc.ankr.com/optimism) is free with no authentication required and no API key, making it the fastest possible starting point for development and prototyping. For open-source tools, public dashboards, or community-facing applications that don't require guarantees, Ankr's public tier is a low-friction option. The production calculus changes significantly. Ankr publishes no formal uptime SLA for non-Enterprise tiers. There is no SOC 2 certification. debug_traceTransaction is Premium-only — it's not available on the free or freemium tiers. trace_* method support on OP Mainnet specifically is not documented, and while it may be available on Premium, teams would need to verify this before building a dependency on it. The billing model charges for failed requests, which can produce unexpected costs during RPC errors or sequencer issues. Ankr's OP Stack chain coverage is limited to two chains: OP Mainnet and Base. If your application spans additional OP Stack deployments, Ankr won't consolidate them. DetailsPricingPublic: free, no auth, rate-limited. Freemium: 200M credits/mo with sign-in. Premium PAYG: ~$0.10/1M credits. Enterprise: custom.Billing modelAPI credits pegged to USD. Can pay with ANKR tokens. Charges on failed requests.Uptime / SLANo published SLA for non-Enterprise tiers.SecurityNo SOC 2 certification.Archive on OPAll tiers for standard archive methods; debug/trace archive requires Premiumdebug_traceTransactionPremium only — not available on free or freemiumtrace_ methods*⚠️ Premium only; not documented for OP Mainnet specifically — requires verificationOP Stack chains3+: OP Mainnet, Base, and Swellchain Pros: Free public endpoint with no auth required, fast onboarding, DePIN infrastructure model, ANKR token billing option, broad EVM chain coverage overall. Cons: No SOC 2; no SLA for non-Enterprise; debug/trace locked behind Premium; charges on failed requests; trace_* unconfirmed on OP; narrowest OP Stack chain coverage in this comparison. Archive and trace API support on Optimism Archive data and trace methods are not edge cases for Optimism workloads — they are standard requirements for DeFi analytics, MEV research, protocol debugging, and compliance reporting. The availability matrix below reflects confirmed support based on provider documentation and API testing. Cells marked ⚠️ require direct verification with the provider before building a production dependency. ProviderArchive on OPdebug_traceTransactiontrace_blockChainstackAll tiersAll tiers, no extra costAll tiersQuicknodeAll tiersAll tiers (2× credits)All tiers (2×)AlchemyAll tiersPaid tiers only⚠️ Unconfirmed on OPInfuraPaid tiers ($250 add-on)Developer+ via DIN⚠️ Open Beta via DINGetBlock⚠️ Dedicated only⚠️ Likely, undocumented❌ Not availableAnkrStandard methods, all tiersPremium only⚠️ Premium, undocumented on OP The key takeaway: Only Chainstack and Quicknode offer fully confirmed, documented trace_* method support on Optimism across all paid tiers. Chainstack is the only provider where trace and debug methods carry no method-weight premium — they cost 2 RU, the same as any archive call. For protocols running trace_filter over wide block ranges or debug_traceTransaction across thousands of historical transactions, that billing model is the difference between a predictable infrastructure cost and an unpredictable one. For teams building on archive data infrastructure, the decision is usually between Chainstack (method-agnostic billing, all tiers) and Quicknode (credit multipliers but strong compliance posture) — depending on whether compliance certification or cost predictability is the higher priority. Optimism vs Arbitrum — an infrastructure perspective Teams choosing between Optimism and Arbitrum for a new deployment are increasingly making an infrastructure decision as much as an ecosystem one. The table below covers the variables that affect RPC provider behavior, tooling compatibility, and operational design: Optimism (OP Mainnet)Arbitrum OneRollup typeOptimistic RollupOptimistic RollupBlock time2s (Flashblocks: 250ms preconfirmations)~0.25s variableL1 finality~13 min (Ethereum finalization)~13 min (Ethereum finalization)Challenge period7 days7 daysEVM compatibilityEVM-equivalent (direct op-geth fork)EVM-compatible (Geth + ArbOS layer)Custom namespacesoptimism_* (rollup state, sync status)arb_* (ArbOS-specific)Trace APItrace_* + debug_* via Erigon/op-getharb_traceTransaction + standard debug_*Fault proof systemCANNON FPVM (interactive bisection)BoLD (WASM multi-round)L2 Stage (L2Beat)Stage 1 (Jan 2026)Stage 1 (Jan 2026)TVS~$1.46B~$16–19BDA modelEthereum blobs (EIP-4844)Ethereum blobs or AnyTrust (DAC)Framework licenseOP Stack — MIT licensedOrbit — BSL unless settling to Arb One/Nova The practical infrastructure difference: OP Mainnet's direct Geth fork means standard Ethereum tooling works without modification. Any library, SDK, or toolchain that targets Ethereum JSON-RPC works on OP Mainnet without an adapter layer. Arbitrum's ArbOS introduces custom arb_* methods and slightly different behavior for edge cases in gas estimation and transaction replay — meaning some tooling needs explicit Arbitrum support, not just generic EVM compatibility. For RPC provider selection specifically, Optimism's OP Stack architecture means that a provider supporting one OP Stack chain likely supports others. Arbitrum Orbit is a separate framework with separate deployment and support considerations — provider coverage doesn't transfer the same way. Choosing the right Optimism RPC provider for your stage The right provider depends on where you are in the product lifecycle, what methods your application actually calls, and what compliance posture your organization requires. Side project or active development You don't need a paid plan to start. Alchemy's 30M CU free tier (with archive included) is the best sandbox for building on OP Mainnet. Chainstack's free Developer plan (3M RU/mo) is the better pick if you want to learn the exact infrastructure you'd use in production — same endpoint, same methods, same behavior. Ankr's public endpoint requires no account at all if you just need a quick RPC URL. Production dApp with moderate traffic Move to a Growth or equivalent paid tier and choose based on your method mix. If your app calls standard methods (eth_call, eth_getLogs, eth_getBlockByNumber), all major providers perform well. If you call debug_traceTransaction or trace_*, Chainstack's 2 RU flat cost is significantly cheaper than Quicknode's 2–4× credit multipliers at volume. DeFi protocol or trading bot Use Dedicated Nodes. Shared infrastructure degrades precisely when you need it most — during high-volatility windows when the whole market is querying at once. Dedicated infrastructure is the only path to consistent tail latency, and for any protocol where a delayed transaction has financial consequences, it's not optional. Require confirmed trace/debug support and full archive before signing a contract. Enterprise or compliance-sensitive deployment SOC 2 Type II is a hard requirement for many legal, fintech, or institutional teams. That narrows the field to Chainstack and Quicknode. Between them: Chainstack offers method-agnostic billing and broader OP Stack chain coverage; Quicknode offers the strongest formal compliance posture (SOC 2 + SOC 1 + ISO 27001) and a 99.99% SLA across all paid tiers. Both are defensible choices — the decision comes down to whether cost predictability at trace volume or certification breadth matters more to your procurement process. Best Optimism RPC providers for 2026 Click any provider to see the score breakdown by category Scoring methodology — 100 pts total Archive + trace /25 Pricing transparency /20 Uptime / SLA /20 SOC 2 compliance /15 OP Stack chain coverage /10 Free tier / DX /10 Based on archive support, trace API availability, pricing transparency, compliance posture, and OP Stack chain coverage: 🥇 Chainstack The strongest all-round option for production Optimism workloads. SOC 2 Type II, method-agnostic billing (trace/debug at no premium), full trace_* suite on all paid tiers, 10+ OP Stack chains, Dedicated Nodes with Bolt fast-sync, Unlimited Node add-on, and crypto payments accepted. The right default for DeFi protocols, analytics teams, and enterprise deployments. 🥈 Quicknode Best formal compliance posture in the set (SOC 2 Type II + SOC 1 + ISO 27001), 99.99% SLA on all paid plans, 13 OP Stack chains, and a strong free tier. The credit multipliers on trace/debug (2–4×) are the main friction point for trace-heavy workloads, but for teams where compliance certification breadth is the primary procurement criterion, Quicknode is a strong option. 🥉 Alchemy The best free tier for Optimism development, with archive included at no cost and deep developer tooling that reduces custom indexing work. The absence of SOC 2 and the uncertainty around trace_* on OP Mainnet specifically limit its appeal for compliance-oriented or trace-heavy production deployments. For teams building without SOC 2 requirements, it's a solid option at mid-tier volume. 🏅 Infura The MetaMask integration advantage is real and unique. For dApps where MetaMask is the primary wallet and transaction submission UX, Infura's backend alignment reduces a specific class of friction. The daily credit quotas, trace methods in Open Beta via DIN, and absence of SOC 2 certification make it a secondary choice for pure infrastructure evaluation. 🏅 Ankr The free public endpoint requires no account and is the fastest possible starting point for prototyping or community tooling. Not a production recommendation: no SLA, no SOC 2, debug/trace locked behind Premium, and the narrowest OP Stack coverage in this comparison. Use it to explore; don't build a production dependency on it. 🏅 GetBlock Clean entry point for budget-constrained teams that need pay-per-request access without a monthly subscription. The lack of trace_* methods and the uncertainty around archive on shared Optimism endpoints are genuine limitations for advanced use cases. Suitable for standard EVM workloads on a fixed budget. Conclusion Optimism is a production-grade L2 with real adoption, a credible security model, and an active DeFi ecosystem. The infrastructure decision that most teams underestimate is how quickly public RPC rate limits become the binding constraint — and how much the choice of provider shapes what's possible at the method level, not just the throughput level. For most production workloads on OP Mainnet, Chainstack is the clearest choice: method-agnostic billing means your trace_filter pipeline costs what you'd expect, SOC 2 Type II covers compliance procurement, and Dedicated Nodes give you performance isolation when the market moves. The Superchain coverage — 10+ OP Stack chains from the same account — means the infrastructure decision you make for OP Mainnet applies across your multi-chain stack without starting over. Building on Optimism? Deploy your Optimism node on Chainstack → FAQ What is the difference between a full node and an archive node on Optimism? A full node retains approximately the last 128 blocks of state — sufficient for transaction submission and current balance queries. An archive node retains the full historical state from genesis, which is required for historical eth_call simulations, eth_getLogs over wide block ranges, and any debug_* or trace_* operation on older blocks. For DeFi protocols, analytics platforms, and compliance reporting, archive access is a baseline requirement, not a premium feature. Do trace methods work the same on Optimism as on Ethereum mainnet? Largely yes. OP Mainnet runs on op-geth, a direct fork of Ethereum's Geth client, which means the debug_* and trace_* method interfaces behave the same way. The trace_* namespace requires an Erigon or equivalent client with trace support — not all providers run this client on OP Mainnet specifically. Verify trace_block and trace_filter support directly with your provider before building a dependency. Does Optimism support WebSocket connections? The official public RPC endpoint does not support WebSockets. All major paid providers — Chainstack, Quicknode, Alchemy, Infura — provide WebSocket endpoints for Optimism, including support for eth_subscribe and Optimism-specific event streams. WebSocket reliability under load is worth testing specifically during high-traffic periods. What is Optimism's Flashblocks feature and which providers support it? Flashblocks is a preconfirmation layer that reduces effective block time on OP Mainnet from 2 seconds to 250ms, giving applications faster transaction feedback before L1 finalization. It's available via a separate WebSocket endpoint (wss://op-mainnet-fb-ws-pub.optimism.io/ws) on the official infrastructure, but the public URL is strictly rate-limited. Contact your RPC provider directly to confirm whether they offer a non-rate-limited Flashblocks WebSocket endpoint for production use. Is SOC 2 certification really necessary for an RPC provider? It depends on your context. For consumer dApps with no institutional users, SOC 2 is rarely a blocker. For fintech integrations, regulated entity deployments, or enterprise procurement processes, SOC 2 Type II is often a hard vendor requirement — the certificate must exist in the vendor's compliance documentation. Of the six providers in this comparison, only Chainstack and Quicknode hold SOC 2 Type II certification. What happens to my application if the Optimism sequencer goes down? Sequencer downtime means block height freezes and new transactions cannot be included. No RPC provider can bypass this — it's an upstream infrastructure event. The sequencer does have a fallback path: users can submit transactions directly to Ethereum L1 via the canonical bridge, though with higher latency and cost. Applications should implement sequencer health monitoring and graceful degradation — display a maintenance mode, pause write operations, and resume once block production resumes. A good RPC provider helps by surfacing sequencer status accurately and maintaining connection stability so your monitoring layer can detect the event cleanly. Can I use the same Chainstack account for multiple OP Stack chains? Yes. Chainstack supports 10+ OP Stack chains — OP Mainnet, Unichain, Fraxtal, Soneium, Ink, Zora, Kroma, Mint, and others — from a single account with unified billing. Request Units are shared across all endpoints, so you're not paying separate plan fees for each chain. This is the main infrastructure consolidation advantage for teams building applications that span the Superchain. Related reading Optimism deep-dive How to get an Optimism RPC endpoint in 2026 Optimism blockchain – Ethereum Layer 2 scaling solution Optimism: Bridge ether from Ethereum L1 to Optimism L2 Build better with Optimism on Chainstack Best RPC providers on other chains Best Base RPC providers in 2026 Best Ethereum RPC providers in 2026 Best Solana RPC providers in 2026 Best Tempo RPC providers in 2026 #### Top 6 TON RPC providers for production apps in 2026 Providers compared in this guide The Open Network (TON) is the Telegram-native sharded L1 built for mass adoption — now processing over 2 million transactions per day and serving an ecosystem of 950M+ Telegram users. In 2026, TON's trajectory shifted sharply: Telegram announced it would replace the TON Foundation as the network's main driver and its largest validator, cut transaction fees by roughly sixfold to ~$0.0005, and accelerated TON Pay 2.0 — a Layer 2 payments network targeting mass in-app use — toward a mid-2026 release. For builders, that means infrastructure stability matters more than ever: the RPC endpoint handling your Mini App or payment processor is the single layer between your code and one of the fastest-growing non-EVM chains. TON's architecture makes provider selection non-trivial. Its sharded workchain/shardchain model, the dual HTTP v2/v3 API surface, and native ADNL protocol all create requirements that don't map onto generic EVM tooling. Running your own node means managing specialized binaries and high-IO storage costing $150–300/month before operational overhead — while community liteserver proxies impose hard rate limits and carry no SLA. The right managed RPC provider eliminates that complexity while keeping production guarantees intact. This guide compares the six providers with verified TON mainnet and testnet support in 2026 — across pricing, archive access, ADNL support, dedicated infrastructure, and compliance. 🤔 Already using Chainstack? Jump straight to the TON tooling docs or deploy your endpoint in minutes. Why RPC provider choice matters for TON TON's architecture produces failure modes that don't exist on EVM chains. The masterchain coordinates multiple workchains, each of which can spawn shardchains dynamically — meaning a provider that routes all traffic to a single region will see latency spikes under load as the sharding topology shifts. Any serious production workload, from a payment processor handling in-app USDT transfers to a Jetton indexer tracking tens of thousands of daily token events, needs a provider with geo-distributed nodes and a clear RPS commitment per plan tier. For a deeper look at the architecture itself, the TON ultimate developer guide covers smart contracts, Jettons, and the workchain model in detail. The v2/v3 API split also introduces a decision that has no EVM equivalent. TON API v2 serves requests off a live node (lowest latency, real-time data), while TON API v3 serves requests off an indexer (higher stability, structured historical data). For wallet backends and payment confirmation flows, v2 is essential. For analytics dashboards, Jetton balance reconciliation, and block explorers, v3 is significantly more reliable. The TON ultimate guide to APIs and interaction libraries breaks down the full API surface and available SDKs. A provider that only offers one of the two surfaces forces you to build your own workarounds. Key criteria for evaluating TON RPC providers in production: API surface coverage — both HTTP v2 and v3 (indexer) endpoints, not just one ADNL protocol support — required for low-level peer-to-peer operations and advanced dedicated node use cases Archive access — full transaction history without pruning; critical for payment reconciliation and explorers Dedicated node availability — isolated compute and RPS, required when traffic exceeds shared-tier limits SLA and uptime commitment — explicitly documented; 99.9%+ with dedicated support access Pricing transparency — no method weighting, no hidden overages on archive calls Security compliance — SOC 2 Type II or equivalent for regulated or enterprise deployments TON RPC provider comparison The table below summarizes public positioning as of May 2026. ProviderPricing modelFree tierDedicated nodesArchive accessADNL supportChainstackRU-based (flat per request)3M RU/month, 25 RPSYes (Pro+)Yes (all plans, $49+/month)Yes (Dedicated Nodes only)QuicknodeCredit-based (method-weighted)30-day trial onlyYes (paid)Yes (mainnet)Not documenteddRPCPer-request ($6/1M on paid)Public endpoints (no SLA); TON on Growth Plan+Not documentedNot documentedNot documentedAnkrAPI credit200M credits/month (shared, no SLA)Yes (paid)Not documentedNot documentedGetBlockCU-based40K requests/dayYes (dedicated plans)Not documentedNot documentedOrbs TON AccessFree (decentralized)Unlimited, keylessNoNoNo Note: Alchemy does not currently support TON — teams on multi-chain Alchemy stacks will need a separate provider for this network. How to choose a TON RPC provider Shared RPC for moderate traffic A shared Global Node endpoint is sufficient for development, staging, and early-production workloads handling fewer than ~25–50 RPS continuously. At this scale, rate limits on free tiers are manageable, and the primary risk is occasional 429 errors during traffic bursts rather than sustained degradation. Both Chainstack and Quicknode offer shared endpoints for TON mainnet. Orbs TON Access is the only keyless, rate-limit-free option but provides no SLA and no archive access. When dedicated infrastructure matters Three scenarios reliably push teams past shared-tier limits on TON: High-frequency payment processing. A Telegram Mini App handling thousands of concurrent in-app USDT transactions will query getTransactions and getAddressBalance at rates that exceed shared RPS caps within minutes of a traffic spike. Jetton indexer or block explorer. Backfilling token transfer histories against the TON v3 indexer generates sustained heavy-method load. Shared endpoints throttle under this pattern; dedicated compute keeps indexing throughput predictable. Real-time wallet backends. Wallet apps that subscribe to address state changes via WebSocket and need sub-100ms response times on getMasterchainInfo and getAccountState cannot tolerate the p99 variability of shared infrastructure at peak. ADNL and advanced protocol access ADNL (Abstract Datagram Network Layer) is TON's native low-level networking protocol — it provides direct peer-to-peer communication at a layer below the HTTP API, with encrypted sessions and public-key-based node identity. Most applications don't need it: the HTTP v2 and v3 APIs cover wallet integration, payment flows, DeFi reads, and contract interaction. Teams that do need ADNL include protocol-level tooling builders, node operators, and any application requiring raw liteserver communication without an HTTP-to-ADNL translation layer. Chainstack's Dedicated Nodes are the only managed option in this comparison with confirmed ADNL support. Latency consistency vs. average latency On TON, mean latency figures from providers are almost always measured on uncongested shared infrastructure. The number that matters is p95 under your expected request mix — particularly for getTransactions calls on accounts with large transaction histories, which are significantly heavier than simple balance queries. Before committing to a provider, check the Chainstack performance dashboard for real-time latency data across providers on TON, and verify that WebSocket connections remain stable under sustained load. Enterprise support for regulated deployments For fintech products, custodial wallets, and any deployment handling significant user funds, SLA coverage and security certification are non-negotiable. Chainstack holds SOC 2 Type II certification and provides SLA-backed uptime at 99.99% across its paid plans. Quicknode also holds SOC 2 Type II and ISO 27001. Other providers in this comparison either do not publish equivalent certifications or restrict SLA terms to enterprise-only contracts. Choose by use case For Telegram Mini Apps and stablecoin payment flows TON is Telegram's designated blockchain for Mini App payments — and with TON Pay 2.0 targeting mid-2026, payment infrastructure requirements are escalating. A Mini App handling USDT transfers needs to confirm transaction finality quickly, detect incoming payments reliably, and handle traffic spikes when viral Mini Apps attract millions of simultaneous sessions. This means consistent RPS capacity, reliable WebSocket connections for address monitoring, and rock-solid getTransactions method coverage with no silent failures. For production payment flows, Chainstack is the strongest option: flat RU pricing (no method weighting on getTransactions), geo-distributed Global Nodes that automatically route to the nearest server, and an Unlimited Node add-on for teams needing flat-fee throughput with no per-request billing. Quicknode is the second-best option for teams already in its credit ecosystem who can budget for TON's credit consumption. dRPC works for cost-sensitive early-stage payment apps, but requires a paid Growth Plan for TON access and has no documented SLA. Explore stablecoin payment infrastructure on Chainstack → For DeFi protocols, Jetton indexing, and on-chain analytics Source: Defillama The TON DeFi ecosystem — including DEXes like STON.fi, lending protocols, and Jetton issuance — requires both real-time method access (v2) for transaction submission and indexer access (v3) for token balance lookups, liquidity pool reads, and historical trade data. A provider that only surfaces v2 forces teams to run their own indexer or accept incomplete data coverage. Heavy indexing workloads — particularly transactionsByMessage, getJettonMasters, and adjacent transaction lookups — generate request volumes that overwhelm shared-tier endpoints quickly. Chainstack's Dedicated Nodes with v2 and v3 coverage are the most complete option for DeFi infrastructure. The v2/v3 architecture is documented in Chainstack's own TON tooling docs, and archive access is available from the Growth plan ($49/month) with no extra method costs. Quicknode's TON v3 HTTP API support (confirmed in April 2026 docs) makes it a viable alternative for teams already on the Quicknode platform. Ankr provides broad coverage but with rate limits and no clear archive depth documentation. Explore DeFi infrastructure on Chainstack → For enterprise wallets, custodians, and compliance-sensitive deployments TON's integration with Telegram's 950M user base is attracting wallet providers and custodians who need to support end-user fund management at scale. Enterprise deployments in this category require SOC 2 Type II-certified infrastructure, contractual SLA coverage, dedicated endpoints (no noisy neighbors), and support access that goes beyond community forums. These are requirements that only Chainstack and Quicknode satisfy in this comparison. Chainstack's Enterprise plan ($990/month, 400M RU, unlimited RPS) covers large-scale wallet operations with documented uptime guarantees, dedicated endpoint isolation, and ADNL access on Dedicated Nodes for teams that need protocol-level access. Quicknode is a credible alternative for enterprise teams with existing Quicknode contracts, though TON-specific product depth (Streams, Webhooks) is still documented as "coming soon." For compliance-sensitive teams, both providers offer substantially more than the remaining field. Explore enterprise blockchain infrastructure on Chainstack → Provider-by-provider breakdown Chainstack Chainstack is the most fully-featured TON RPC provider in production as of 2026. Its TON infrastructure exposes both HTTP API v2 (real-time node requests) and v3 (indexed data), covers mainnet and testnet, and includes ADNL protocol access on Dedicated Nodes. Archive access is available from the Growth plan at $49/month with no method-level cost distinctions — every request counts as one request unit, whether it's a simple balance check or a deep historical transaction lookup. The Global Nodes tier routes automatically to the geographically nearest server, keeping latency competitive across regions. Pricing uses a flat RU model: Developer (free, 3M RU/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). The Unlimited Node add-on converts billing to flat-fee RPS tiers with no per-request overages — the right choice for teams with predictable high-volume traffic. WebSocket endpoints are included. SOC 2 Type II certification is held and documented. Chainstack is also the only provider in this comparison with a dedicated TON testnet faucet at faucet.chainstack.com/ton-testnet-faucet, which significantly reduces the friction of testnet development compared to relying on community faucets. Limitations: The Unlimited Node add-on costs extra on top of base plan pricing. ADNL access is restricted to Dedicated Nodes (Pro plan and above), so teams on Developer or Growth plans using shared infrastructure don't get ADNL without upgrading. Fit by workload: Telegram Mini App payments: Excellent — flat pricing, no method weighting on getTransactions, geo-load-balanced Global Nodes DeFi / Jetton indexing: Excellent — v2 + v3 both available, archive from $49/month, Dedicated Nodes for sustained indexer load Enterprise wallets: Excellent — SOC 2 Type II, 99.99% uptime SLA, ADNL on Dedicated Nodes, Enterprise plan with contractual coverage Quicknode Quicknode supports TON mainnet with both HTTP API v2 and v3 (HTTP API and TON V3 HTTP API), documented in its April 2026 release. Archive access is confirmed for mainnet. Quicknode's credit model weights requests by method complexity, which is manageable for teams with predictable workloads but can produce billing surprises under heavy archive or complex v3 query loads. SOC 2 Type II and ISO 27001 certifications make it one of two providers in this comparison with documented security compliance. Quicknode's broader ecosystem strength — Streams, Webhooks, the Marketplace add-on library — doesn't yet fully translate to TON: the chains page lists additional TON products as "coming soon." Teams building multi-chain products with an existing Quicknode account will find the TON support adequate for most production use cases. Teams building exclusively on TON will find Chainstack's deeper TON-specific documentation and support more appropriate. Limitations: TON-specific products (Streams, backfill) documented as coming soon rather than live. Credit billing adds forecasting complexity for heavy archive workloads. No free tier — 30-day trial only. Fit by workload: Telegram Mini App payments: Strong — reliable endpoints, archive access, SOC 2, but credit model adds billing complexity DeFi / Jetton indexing: Good — v3 supported, but heavier methods consume more credits; monitor spend carefully Enterprise wallets: Strong — SOC 2 + ISO 27001, 99.99% SLA, existing enterprise contracts apply dRPC dRPC routes requests through a distributed network of independent node operators with an AI-driven load balancer. For TON specifically, access requires a paid Growth Plan — TON is listed among chains available only on paid tiers. The flat per-request pricing ($6/1M requests after a mid-2025 update) is among the cheapest in this comparison for moderate-volume workloads, and dRPC's public endpoints provide frictionless testing without API key registration. dRPC's distributed architecture creates a real latency consistency trade-off: request routing across independent operators introduces variability that purpose-built global infrastructure (Chainstack, Quicknode) doesn't. For payment processors with p95 latency requirements, this variability is a risk. For cost-sensitive analytics pipelines or secondary fallback endpoints, it's acceptable. Limitations: TON requires paid plan. No documented SLA. Latency variability is a known characteristic of the distributed routing model. No documented ADNL support or archive depth. Fit by workload: Telegram Mini App payments: Moderate — cost-effective for moderate load, but no SLA and latency variability is a risk for real-time payment confirmation DeFi / Jetton indexing: Good — viable for non-time-sensitive analytics at low cost; verify archive depth before relying on it Enterprise wallets: Limited — no SOC 2 documentation, no contractual SLA, not suitable for compliance-sensitive deployments Ankr Ankr has supported TON in its multi-chain coverage for several years, offering both public RPC endpoints and paid private endpoints. The free tier is generous by request volume (200M API credits/month), but public endpoints impose aggressive rate limits that make them unreliable for sustained production use — they're best treated as a testing convenience, not a production tool. Paid plans add rate-limit isolation, dedicated support, and a cleaner endpoint experience. Ankr's TON coverage includes mainnet access over HTTP; the provider holds a SOC 2 Type 2 certification (reported 2025). Archive depth and v3 indexer support are not clearly documented for TON specifically, which creates risk for teams that need deep transaction history. Limitations: Free public endpoints throttle aggressively. Archive depth for TON not clearly documented. v3 API support not confirmed. Less TON-specific documentation depth than Chainstack or Quicknode. Fit by workload: Telegram Mini App payments: Moderate — public tier throttles too aggressively for production; paid plans are viable for small-to-medium scale DeFi / Jetton indexing: Moderate — adequate for lightweight queries; archive depth uncertainty is a risk for heavy indexing Enterprise wallets: Limited — SOC 2 Type 2 is a positive, but missing clear SLA terms and archive documentation reduce confidence GetBlock GetBlock supports TON mainnet and testnet via its HTTP-based API, including both JSON-RPC and JSON-RPC v2. Its free tier provides 40K requests per day — useful for development and testing but constrained for production use. GetBlock's regional endpoint selection (Frankfurt and US-East bare-metal) is a meaningful differentiator for teams optimizing for specific geographic latency; paid plans add up to 300 RPS and unlimited API keys. GetBlock's pricing uses CU-based billing, and TON is listed as available on paid plans with independent verification recommended before production deployment. The platform lacks the same depth of TON-specific documentation as Chainstack, and archive support for TON is not explicitly documented. Limitations: 300 RPS ceiling on paid plans (below Chainstack and Quicknode at comparable tiers). CU billing can be difficult to forecast for mixed workloads. TON archive depth not clearly documented. Limited ecosystem tooling for TON-specific workflows. Fit by workload: Telegram Mini App payments: Moderate — regional endpoints are useful for geo-optimized deployments; rate limits constrain scale DeFi / Jetton indexing: Moderate — suitable for smaller indexing tasks; 300 RPS ceiling restricts high-volume use cases Enterprise wallets: Limited — no documented SLA or compliance certification matching enterprise requirements Orbs TON Access Orbs TON Access is a purpose-built, decentralized RPC gateway for TON, operated by the Orbs Network validators with roughly $100M staked. Its defining feature is anonymous, keyless access — no API key registration, no rate limits per user, no centralized business dependency. It supports all three TON API flavors (HTTP v2, HTTP v4 by TonHub, and raw ADNL), making it uniquely suited for client-side dApp frontends where storing API keys is inherently insecure. TON Access is not a production substitute for managed RPC infrastructure — it provides no SLA, no archive access, no dedicated nodes, and no compliance documentation. Its architectural guarantee is decentralization: routing through dozens of independent validators means no single vendor outage takes down your access. For browser-based dApps that can't hold a server-side API key, it's the right choice. For everything else, the absence of SLA and archive coverage makes it a poor primary endpoint. Limitations: No SLA, no archive, no dedicated nodes. Not suitable as a primary endpoint for server-side production workloads handling user funds. Performance varies by validator node quality. Fit by workload: Telegram Mini App payments: Limited — no SLA, not suitable for production payment processing; useful for client-side prototypes DeFi / Jetton indexing: Limited — no archive access, not suitable for historical data workloads Enterprise wallets: Limited — no compliance documentation whatsoever Provider scoring chart TON RPC provider scores — 2026 Click any provider to expand the scoring breakdown. Max score: 100. Scoring methodology for TON (non-EVM, messaging-native chain): API breadth (v2 + v3 + ADNL): 30 points Archive access and data depth: 25 points Pricing transparency: 20 points Uptime / SLA commitment: 15 points SOC 2 compliance: 10 points Getting started with TON on Chainstack Getting a production-ready TON endpoint on Chainstack takes under five minutes: Create a free Chainstack account or log into the console Create a new project and click Add node Select TON and choose Mainnet or Testnet Pick your plan and click Deploy — the node is live in seconds Navigate to Access and credentials to copy your HTTPS or WebSocket endpoint Here's a minimal cURL call to verify your endpoint is live: curl --request GET \ --url YOUR_CHAINSTACK_TON_ENDPOINT/api/v2/getMasterchainInfo For SDK-based integration, the TON tooling documentation covers TonWeb, Ton.js, Blueprint, and SDKs for Python, Go, Rust, and .NET — all pre-configured for Chainstack endpoints. Need testnet TON for development? Grab some from the Chainstack TON testnet faucet. Conclusion TON's sharded architecture and dual v2/v3 API surface make provider selection more consequential than on typical EVM chains — teams that pick a shared endpoint without verifying archive depth, v3 indexer support, and RPS headroom will hit problems in production. Telegram Mini Apps and payment processors: Chainstack for its flat RU pricing, geo-distributed Global Nodes, and Unlimited Node add-on; Quicknode as a secondary option for multi-chain teams DeFi protocols and Jetton indexers: Chainstack Dedicated Nodes for sustained v3 indexer load with archive; Quicknode for teams with existing credit budgets Enterprise wallets and custodians: Chainstack or Quicknode exclusively — both hold SOC 2 Type II and provide contractual SLA coverage Client-side dApps without a backend: Orbs TON Access for keyless, decentralized access with no API key exposure risk Cost-sensitive early-stage projects: dRPC for low-cost paid access; Ankr for high free-request-volume prototyping Deploy your TON RPC endpoint on Chainstack → FAQ What is the difference between TON API v2 and v3, and which should I use? TON API v2 serves requests directly off a live node — lowest latency, real-time data, essential for payment confirmation and wallet state. TON API v3 serves requests off an indexer — higher stability, structured historical data, better for Jetton balance lookups, NFT metadata, and analytics. Most production applications need both: v2 for transaction submission and live state, v3 for anything requiring reliable historical data. Chainstack's TON tooling documentation explains the trade-offs in detail. Is there a meaningful free tier for TON development? Yes. Chainstack's Developer plan gives 3M RU/month (25 RPS) with full mainnet and testnet access, archive data, and a testnet faucet — no credit card required. Ankr's free public tier is more generous by raw request count (200M credits/month) but throttles aggressively in practice. dRPC's free public endpoints work without an API key but provide no SLA and require a paid plan for TON specifically. Quicknode's trial is 30 days with no ongoing free tier. Should I use ADNL or HTTP API for my TON application? For the vast majority of applications — wallets, payment processors, DeFi frontends, NFT platforms, Mini Apps — the HTTP API (v2 or v3) is the right choice. ADNL is TON's low-level peer-to-peer protocol requiring either a lite-client binary or a library with native ADNL support, and it adds meaningful integration complexity. Reserve ADNL for protocol-level tooling, validator management, or applications that genuinely require direct liteserver access without an HTTP translation layer. Chainstack supports ADNL on Dedicated Nodes. How do I benchmark latency for my specific TON method mix? Mean latency benchmarks are misleading for TON — a provider with good average response time can still show 800ms+ p95 on heavy getTransactions calls with large history. Run your actual method mix (not just getMasterchainInfo) from your deployment region for at least 24 hours. The Chainstack performance dashboard tracks real-time latency across providers for TON and other chains — use it to validate p95 figures before committing. The CompareNodes public endpoint comparison tool also lets you test Chainstack, dRPC, and Quicknode endpoints from your browser location. What compliance certifications does a TON RPC provider need for regulated deployments? At minimum, SOC 2 Type II demonstrates that a provider has undergone independent audit of its security controls — not just a self-declaration. Chainstack holds SOC 2 Type II. Quicknode holds both SOC 2 Type II and ISO 27001. For financial services, custodians, or any product handling user funds in a regulated jurisdiction, verify the current certification status directly with the provider before signing infrastructure contracts. How does TON's non-EVM architecture affect RPC pricing? EVM chains have well-defined method cost tiers (eth_call, eth_getLogs are expensive; eth_getBalance is cheap), and providers like Alchemy and Quicknode use CU/credit models that reflect this. TON's method complexity doesn't map cleanly onto EVM pricing heuristics. Chainstack uses a flat 1 RU per request model for TON — no method weighting — which makes billing predictable regardless of whether you're calling getMasterchainInfo (cheap on any provider) or getTransactions on an address with years of history (expensive in practice). For teams running heavy v3 indexer queries, the flat model is meaningfully cheaper than weighted alternatives. Related reading TON deep-dive TON: Ultimate guide to APIs and interaction libraries TON: Ultimate developer guide from smart contracts to Jettons TON: Choosing v2 or v3 API How to develop fungible tokens (Jettons) Best RPC providers on other chains Best Solana RPC providers in 2026 Best Ethereum RPC providers for production workloads in 2026 Best Aptos RPC providers in 2026 #### Top 7 Arbitrum RPC providers for DeFi and production in 2026 Providers compared in this guide Arbitrum is the second-largest Ethereum Layer 2 by DeFi liquidity, holding 22% of all Layer 2 TVL — approximately $1.6 billion — entering 2026 and running over 2.1 billion lifetime transactions, trailing only Base in overall L2 rankings. The ArbOS Dia upgrade, Stylus multi-language smart contracts (Rust, C, C++), and the Orbit framework expanding toward 100+ custom chains make 2026 a pivotal year for Arbitrum infrastructure. Source: Defillama Choosing the wrong RPC provider on Arbitrum isn't just a latency problem. Nitro's execution model means archive state queries, trace APIs (arbtrace_*, debug_*), and WebSocket subscriptions all behave differently across providers — and gaps in any one of them can block entire product categories. This guide compares seven providers across the criteria that actually matter for production workloads in 2026. This article covers Chainstack, Quicknode, Alchemy, Ankr, dRPC, Infura, and Dwellir — evaluated on archive access, trace API support, pricing transparency, and uptime commitments. 🤔 Already using Chainstack? Jump straight to the Arbitrum tooling docs or deploy your endpoint in minutes at chainstack.com/build-better-with-arbitrum. In this guide Why RPC provider choice matters for Arbitrum Comparison table How to choose an Arbitrum RPC provider Choose by use case Provider breakdown Scoring chart Real-world performance benchmark Getting started with Arbitrum on Chainstack Conclusion FAQ Related reading Why RPC provider choice matters for Arbitrum Arbitrum's Nitro stack introduces a wrinkle that every production team eventually hits: blocks added before Nitro migration (block #22,207,815) cannot be queried with standard Geth methods — only arbtrace_*. Teams building analytics dashboards, forensic tools, or tax accounting layers need a provider that exposes both debug_* and arbtrace_* namespaces natively, not via partner routing. Not all providers do. The other pressure is Stylus adoption in 2026. As developers ship contracts in Rust and C alongside Solidity, RPC workloads shift toward compute-heavier calls that stress method-weighted pricing models. A provider that costs $5/million for eth_call may bill $50/million once Stylus-heavy trace calls are factored in. Predictable, per-request pricing matters more on Arbitrum than on chains with lighter method profiles. Key criteria for production-grade Arbitrum RPC in 2026: Archive + trace access — both debug_* and arbtrace_* natively, not via third-party routing WebSocket stability — eth_subscribe for logs, pending transactions, and block headers Dedicated node options — isolated hardware when shared infrastructure hits rate ceilings Pricing predictability — flat or per-request models outperform method-weighted CU models for Arbitrum workloads SLA and uptime guarantees — published commitments, not informal promises SOC 2 compliance — required for institutional DeFi, tokenized asset platforms, and regulated products Comparison table The table below summarizes public positioning as of April 2026. ProviderPricing modelFree tierDedicated nodesArchive & traceSLAChainstackRU (1 RU/request)3M RU / 25 RPSYes (paid plans)Yes — debug_* + arbtrace_*99.99%QuicknodeCredit (method-weighted, ~20x)30-day trial onlyYes (dedicated clusters)Yes — no archive premium99.99%AlchemyCU (method-weighted, ~26 CU)30M CU/monthNo standard optionNo trace API for Arbitrum99.9%AnkrAPI credit (200 credits/request)200M credits/monthNot documentedYes — archive included99.9%dRPCFlat $6/1M requests (20 CU)Yes — public nodesNoLimitedNot documentedInfuraCredit (method-weighted)YesNoVia DIN partner routing99.9%DwellirFlat 1:1 pricing ($1.96–5/M)YesYes — bare metalYes — all paid plans99.9% Note: Alchemy does not expose trace APIs for Arbitrum — debug_traceTransaction and arbtrace_* are Ethereum mainnet only. Teams needing trace access on Arbitrum One must use a different provider. How to choose an Arbitrum RPC provider Shared RPC for development and moderate traffic For teams under a few hundred RPS with no trace requirements, shared Global Nodes from Chainstack or Quicknode's shared endpoints cover most needs. dRPC's flat pricing at $6/million makes it attractive for high-volume, low-complexity workloads (balance checks, event logs, transaction submission) where trace isn't required and cost predictability matters. When dedicated infrastructure matters Dedicated nodes become necessary at three thresholds: sustained traffic above 300 RPS, workloads requiring custom node configuration (e.g., custom archival windows, plugin injection), or compliance requirements mandating traffic isolation. For Arbitrum, dedicated nodes also unlock full debug_* and arbtrace_* access at providers where trace APIs are gated behind isolated infrastructure. Chainstack's Dedicated Nodes include Bolt fast-sync for rapid deployment and support both full and archive configurations. Archive and trace access on Arbitrum Archive on Arbitrum means different things at different providers. Full archive retains every historical state diff and trace from genesis. Post-Nitro trace queries use debug_*; pre-Nitro queries require arbtrace_*. Providers that route trace through partner networks (Infura's DIN model) add latency and reduce reliability compared to native implementations. Chainstack, Quicknode, and Dwellir expose trace natively on dedicated nodes. Alchemy's missing trace API for Arbitrum is a hard blocker for analytics and compliance use cases — no workaround exists within the Alchemy platform. Latency consistency vs. average latency Average p50 latency is a marketing number. Production DeFi and trading applications care about p95 and p99 — the tail behavior under load. A provider delivering 45ms average but 800ms p99 during peak blocks is worse than one delivering 70ms average with consistent p95 under 150ms. Use Chainstack Compare to benchmark your specific method mix against your endpoint before committing to a provider. Enterprise support for regulated products Robinhood launching tokenized equities on Arbitrum One in 2025, and the Arbitrum Foundation's 2026 "Arbitrum Everywhere" institutional expansion, mean regulated products are increasingly Arbitrum-native. For those teams, SOC 2 Type II certification is a baseline vendor requirement. Chainstack holds SOC 2 Type II. Quicknode holds SOC 2 Type II plus ISO 27001. Alchemy holds SOC 2 Type II. Infura and Ankr do not publish equivalent certifications. Choose by use case For DeFi protocols and on-chain liquidity infrastructure Source: Arbitrum Portal Arbitrum's position as home to Uniswap pools, Aave lending markets, and GMX perpetuals means DeFi RPC workloads are dominated by eth_getLogs (scanning position events), eth_call (reading pool state), and eth_subscribe (block and pending transaction feeds). These three methods together represent the bulk of DeFi protocol RPC traffic. Providers with method-weighted pricing punish exactly this mix: eth_getLogs calls tend to be heavy on CU-based models. Chainstack's 1 RU per request model and dRPC's flat $6/million make cost modeling straightforward for this workload. Quicknode's 20x credit multiplier combined with additional multipliers for log-heavy calls can produce 40–80x effective cost inflation on high-frequency eth_getLogs workloads compared to flat-rate providers. For DeFi teams operating at scale, the pricing model choice directly translates to infrastructure budget. Explore dedicated infrastructure on Chainstack → For trading bots, MEV searchers, and high-throughput automation Arbitrum's 250ms block time is a double-edged sword for trading infrastructure: fast enough to require real-time WebSocket subscriptions, tight enough that latency variance in RPC responses directly impacts inclusion probability. MEV searchers and arbitrage bots running on Arbitrum need stable WebSocket connections, low tail latency, and — critically — access to the mempool state via eth_subscribe("newPendingTransactions"). Note: As of April 2026, Infura's WebSocket support for Arbitrum remains in public beta — not recommended for production trading infrastructure. Quicknode and Chainstack both deliver production-stable WebSocket implementations for Arbitrum. Chainstack's Dedicated Nodes with the Unlimited Node add-on eliminate per-request billing entirely — a significant advantage for trading bots that may spike to thousands of requests per second during market volatility. Quicknode's Streams product provides a push-based alternative for teams preferring filtered data delivery over raw subscription management. Explore trading infrastructure on Chainstack → For analytics platforms, indexers, and data pipelines Analytics workloads on Arbitrum require archive nodes with native trace support — both post-Nitro debug_traceTransaction and pre-Nitro arbtrace_block. Block explorers, on-chain credit scoring systems, tax accounting tools, and DeFi analytics dashboards all share this requirement. The key differentiator is whether trace is implemented natively or routed through partner infrastructure. Chainstack's global archive nodes support both debug_* and arbtrace_* natively, with debug and trace confirmed on both Global Nodes (paid plans) and Dedicated Nodes. Dwellir's bare-metal dedicated nodes are also strong for this use case, with 1:1 pricing that doesn't penalize trace-heavy workloads. Alchemy's missing trace API for Arbitrum removes it from consideration for any indexing pipeline that needs transaction replay or historical state reconstruction. Explore dedicated infrastructure on Chainstack → Provider breakdown Chainstack Chainstack supports Arbitrum One mainnet and Sepolia testnet across Global Nodes and Dedicated Nodes — with full and archive configurations available on both. The 1 RU per request pricing model applies equally to eth_call, eth_getLogs, debug_traceTransaction, and arbtrace_block: no method multipliers, no archive surcharge. For Arbitrum specifically, this matters because Stylus workloads in 2026 skew toward computation-heavy calls that would cost significantly more under method-weighted models. Archive access includes both debug_* and arbtrace_* namespaces, natively on Chainstack infrastructure — no partner routing. The Unlimited Node add-on converts any plan to flat-fee unlimited requests, which is the right configuration for trading bots or indexers that cannot tolerate per-request billing uncertainty. SOC 2 Type II certification and 99.99% SLA make Chainstack viable for regulated deployments. The Arbitrum Sepolia testnet faucet is available at faucet.chainstack.com. Pricing: Developer free (3M RU / 25 RPS) → Growth $49/month (20M RU) → Pro $199/month (80M RU) → Business $499/month (200M RU) → Enterprise $990/month (400M RU). Overage from $5/1M RU at Enterprise tier. Unlimited Node add-on available as flat-fee RPS tiers. 🤖 You can also access Chainstack Arbitrum RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP. Quicknode Quicknode supports Arbitrum One with a global edge network, production-stable WebSocket, and native archive plus trace access — without an archive premium, which keeps historical query costs predictable. The key limitation is credit-based pricing: Arbitrum requests consume approximately 20 credits at base, with additional multipliers for heavier methods. For trace-intensive workloads, effective costs can reach 40–80x the advertised per-credit rate. Quicknode's Streams product (real-time filtered data to PostgreSQL, S3, Snowflake, or webhooks) is a genuine differentiator for teams building data pipelines who prefer push delivery over polling. SOC 2 Type II plus ISO 27001 makes Quicknode the strongest certification posture in this comparison. Pricing: 30-day trial, then plans from $49/month. Dedicated clusters available on higher tiers. Enterprise pricing on request. Alchemy Alchemy supports Arbitrum One mainnet with HTTP and WebSocket endpoints, a generous 30M CU free tier, and strong developer tooling. The critical gap: trace APIs are not available for Arbitrum on Alchemy — debug_traceTransaction and the arbtrace_* namespace are Ethereum mainnet only. For any workload requiring transaction replay, historical state reconstruction, or pre-Nitro block queries, Alchemy is not a viable option for Arbitrum. Teams on Alchemy for Ethereum will need a separate provider for Arbitrum if trace is required. No standard dedicated node option is available; dedicated infrastructure requires enterprise negotiation. SOC 2 Type II certified. Pricing: Free tier (30M CU/month), then Growth $49/month and Scale $199/month. CU costs vary by method — eth_call costs 26 CU, heavier methods more. Ankr Ankr provides Arbitrum One access with archive nodes included and a 200M credit free tier — the most generous free allocation in this comparison by raw credit volume. The caveat: Arbitrum requests consume 200 credits each on Ankr's model, which translates to approximately $20/million at standard rates — among the highest effective per-request costs in the comparison. Ankr operates a decentralized network of node operators, which provides resilience but can introduce latency variance compared to centralized infrastructure. SOC 2 Type 2 certification was published in 2025, improving Ankr's enterprise positioning. Useful as a multi-chain entry point for teams already running Ankr across 40+ chains. Pricing: 200M credits free/month, then paid tiers based on credit consumption. Dedicated node options not prominently documented for Arbitrum. dRPC dRPC takes a flat-pricing approach: $6 per million requests at 20 CU per call regardless of method. This eliminates the method-multiplier math that makes Alchemy, Quicknode, and Ankr costs unpredictable for heavy Arbitrum workloads. The tradeoff is infrastructure depth: no dedicated nodes, no documented SLA, and limited trace API support. dRPC's decentralized routing across geo-distributed clusters delivers reasonable latency for standard RPC calls but introduces variability that makes it unsuitable as a sole provider for latency-sensitive trading applications. Best positioned as a cost-optimized secondary or burst endpoint alongside a primary dedicated provider. Pricing: Public nodes free (no SLA), paid plans from $6/1M requests. Infura Infura supports Arbitrum One with archive access enabled by default and no archive premium — archive queries currently cost the same as standard requests. The two production concerns in 2026: trace and debug APIs route through the Decentralized Infrastructure Network (DIN) partner infrastructure (including Chainstack, Grove, and Pocket) rather than native Infura nodes, adding latency and an architectural dependency. More critically, WebSocket support for Arbitrum remains in public beta as of April 2026 — not recommended for any production application requiring eth_subscribe. ConsenSys backing and MetaMask ecosystem integration give Infura institutional credibility, but the beta WebSocket status is a hard limitation for production DeFi and trading workloads. Pricing: Credit-based with method-specific costs. Debug calls at 1,000 credits each can make trace-heavy workloads 2–5x more expensive than flat-rate providers. Dwellir Dwellir provides enterprise-grade Arbitrum infrastructure on bare-metal dedicated nodes with 1:1 transparent pricing — every RPC response costs one credit regardless of method complexity. This is the same positioning as Chainstack's RU model but implemented at a different price point ($1.96–5.00 per million requests depending on plan). Full archive support including trace and debug APIs on all paid plans, with stable WebSocket production support. Dwellir's strength is DeFi protocols and analytics platforms where the combination of trace access, flat pricing, and dedicated infrastructure alignment eliminates the variable cost exposure from method-weighted models. Pricing: Free plan available, paid plans from $1.96/million requests. Bare-metal dedicated nodes available on enterprise plans. Scoring chart ProviderArchive + trace (/25)Pricing transparency (/20)Uptime / SLA (/20)SOC 2 compliance (/15)WebSocket stability (/10)Free tier / DX (/10)TotalChainstack2519201510998Quicknode2314201510789Dwellir221917129887Ankr1812171281077dRPC14191067965Infura161217105868Alchemy813171581071 Criteria weights reflect Arbitrum production priorities in 2026: archive + trace is the single most differentiating axis because Alchemy's trace gap and Infura's DIN routing make it a hard binary for analytics workloads. Pricing transparency is weighted equally with uptime because method-weighted models introduce unpredictable cost exposure at Arbitrum-specific method mixes. Real-world performance benchmark Arbitrum is tracked on the Chainstack performance dashboard. Benchmarks below are from Growth-tier plan tests across EU, JP, and US West regions as of Q1 2026. MethodProviderEU (ms)JP (ms)US West (ms)eth_callChainstack385241eth_callQuicknode456748eth_callAlchemy517844eth_getLogsChainstack557158eth_getLogsQuicknode628864eth_subscribeChainstack284431eth_subscribeQuicknode345237debug_traceTransactionChainstack180240190debug_traceTransactionQuicknode210290220 Data sourced from the Chainstack performance dashboard. Alchemy excluded from trace benchmark due to missing trace API for Arbitrum. Getting started with Arbitrum on Chainstack Getting a production Arbitrum endpoint on Chainstack takes about two minutes: Log in to Chainstack (or create a free account). Create a new project or select an existing one. Choose Arbitrum One Mainnet or Arbitrum Sepolia Testnet. Select the node type that fits your needs — Global Nodes, Dedicated Nodes, Trader, or Unlimited. Copy the HTTP or WebSocket endpoint URL. A basic eth_getBlockByNumber call with ethers.js looks like this: const { ethers } = require("ethers"); const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ARBITRUM_ENDPOINT"); async function getLatestBlock() { const block = await provider.getBlock("latest"); console.log(`Block number: ${block.number}`); console.log(`Gas used: ${block.gasUsed}`); } getLatestBlock(); 📖 For the full guide on how to get the Arbitrum endpoint, check this article. Conclusion For Arbitrum production workloads in 2026, the single most important filter is trace API support. Alchemy's missing trace implementation removes it from analytics, compliance, and historical data use cases. Infura's beta WebSocket removes it from trading and streaming applications. That narrows the production-ready field to Chainstack, Quicknode, and Dwellir — with dRPC as a cost-optimized secondary. DeFi protocols and liquidity infrastructure → Chainstack (flat pricing, archive + trace, stable WebSocket) Trading bots and MEV searchers → Chainstack or Quicknode (lowest tail latency, stable WebSocket, dedicated options) Analytics platforms and indexers → Chainstack or Dwellir (native trace, flat pricing, full archive from genesis) Multi-chain teams already on Ankr → Ankr (keeps provider consolidation, though pricing is high per request) Cost-optimized burst / secondary endpoint → dRPC ($6/million flat, no SLA commitment) Regulated / institutional deployments → Chainstack or Quicknode (SOC 2 Type II, dedicated infrastructure, published SLA) Deploy your Arbitrum RPC endpoint on Chainstack → FAQ Does Arbitrum require a different RPC setup than Ethereum mainnet? Yes. Arbitrum's Nitro stack uses two separate trace namespaces: arbtrace_* for blocks before the Nitro migration (#22,207,815) and debug_* for post-Nitro blocks. Standard Ethereum providers that only expose debug_* will silently return empty results for pre-Nitro historical queries. Always verify that your provider exposes both namespaces natively before building any analytics or compliance tooling. Which provider offers the best free tier for Arbitrum development? For prototyping, Ankr's 200M credit free tier has the highest raw credit volume, though each Arbitrum request consumes 200 credits (~1M effective requests). Chainstack's Developer plan (3M RU at 1 RU/request) gives 3M actual API calls with no method multiplier. Alchemy's 30M CU/month is generous but excludes trace access on Arbitrum. For beginners, Chainstack's free tier gives the clearest cost-to-call ratio. How does the ArbOS Dia upgrade in 2026 affect RPC behavior? ArbOS Dia (launched January 2026) improves EIP-1559 base-fee control and adds new precompiles for Stylus. From an RPC perspective, it doesn't break existing method surfaces — existing eth_*, arbtrace_*, and debug_* calls continue to work. However, Stylus contract interactions now surface in trace outputs differently than standard EVM calls, so trace parsers built for pre-Stylus workloads may need updates. How much does tail latency vary across providers for Arbitrum? P95 and P99 latency diverge significantly under production load. Benchmarks on the Chainstack performance dashboard show Chainstack and Quicknode maintaining consistent p95 under 150ms for eth_call and eth_getLogs. dRPC's decentralized routing can produce p99 spikes above 500ms. Use Chainstack Compare to test your specific method mix before committing. Which providers support Arbitrum for regulated and institutional use cases? Chainstack (SOC 2 Type II, 99.99% SLA) and Quicknode (SOC 2 Type II + ISO 27001, 99.99% SLA) are the two providers with published compliance certifications suitable for institutional deployments. Both support dedicated infrastructure, access controls, and enterprise support tiers. Alchemy holds SOC 2 Type II but lacks trace API support for Arbitrum, limiting its institutional utility on this chain. Is Chainstack's RU model cheaper than Alchemy's CU model for Arbitrum? For most Arbitrum production workloads, yes — significantly. Chainstack charges 1 RU per request regardless of method. Alchemy charges 26 CU for eth_call, 75 CU for eth_getLogs, and has no trace API for Arbitrum. For a workload of 1M daily calls split across eth_call, eth_getLogs, and eth_subscribe, the effective Alchemy CU spend is typically 30–80x the advertised per-CU rate, making Chainstack's flat model substantially cheaper at equivalent traffic levels. Related reading Arbitrum deep-dive: How to get an Arbitrum RPC endpoint in 2026 Compare Dashboard now tracks Arbitrum and BNB Smart Chain Arbitrum debug and trace APIs — Chainstack Docs More Arbitrum articles on the Chainstack Blog Best RPC providers on other chains: Best Base RPC providers for onchain applications in 2026 Best Ethereum RPC providers for production workloads in 2026 Top 6 Optimism RPC providers for production apps in 2026 #### Top 7 RWA token data tools for developers in 2026 Real-world asset tokens look like ordinary ERC-20s until you try to query them in bulk. Pull totalSupply and balanceOf and you get raw numbers. But the actual question — what's the NAV right now, what yield pattern does this token use, can this wallet even hold it — requires contract-specific ABI calls that differ across Ondo, BUIDL, Maple, and Backed. There's no standard oracle interface for tokenized treasuries. Compliance checks use four different models across the five largest RWA issuers. Price sources range from on-chain oracles to constant $1 NAVs to ERC-4626 vault math. Tools built for generic ERC-20 data return incomplete or misleading results when pointed at these tokens. This guide ranks the best tools for querying RWA tokens in 2026 — from purpose-built Python SDKs to analytics APIs to raw RPC access. Each entry covers what it actually queries, what it misses, and what infrastructure it needs to run reliably. Why querying RWA tokens is harder than it looks A developer building on top of tokenized finance runs into the same problem across every project: there's no unified data layer. Consider querying the price of five common RWA tokens: USDY (Ondo) — read getPriceData() from a custom RWADynamicOracle contract OUSG (Ondo) — read getAssetPrice() from a different Ondo oracle bIB01 (Backed) — query a Chainlink aggregator feed syrupUSDC (Maple) — call convertToAssets(1e6) on an ERC-4626 vault BUIDL (BlackRock via Securitize) — the NAV is always $1.00; it's enforced at the contract level, not read from an oracle Same question, five different call signatures, four different contract types. Now add compliance checks: Ondo USDY uses a blocklist, OUSG uses a KYC registry, Backed uses Chainalysis sanctions screening, Maple's syrupUSDC uses a bitmap permission manager, and BUIDL uses Securitize's DS Protocol preTransferCheck. Every implementation is different. This is the actual problem the tools below solve — or don't. The tools, ranked 1. Chainstack rwa-sdk — best for on-chain querying without an indexer Type: On-chain token querying (read-only) · Language: Python · License: MIT · Link: github.com/chainstacklabs/rwa-sdk What it is: An open-source Python SDK for querying RWA token data directly on EVM chains via eth_call. No database, no indexer, no API keys beyond an RPC endpoint. The SDK covers Ondo Finance (USDY, OUSG, rUSDY, rOUSG), BlackRock BUIDL via Securitize (BUIDL, BUIDL-I), Backed Finance (bIB01, bCSPX, bNVDA), Maple Finance (syrupUSDC, syrupUSDT), and Centrifuge (JTRSY) — the protocols that account for the majority of on-chain RWA value. Tokens are returned as typed Pydantic models with normalized fields: price, tvl, yield_type, compliance_method. from rwa_sdk import RWAChain rwa = RWAChain(rpc_url="https://ethereum-mainnet.core.chainstack.com/YOUR_KEY") # Query all supported tokens in one pass for t in rwa.all_tokens(): price = f"${t.price:.4f}" if t.price else "N/A" print(f"{t.symbol:12s} | {t.protocol:10s} | {price:>12s} | ${t.tvl:,.0f}") Output against mainnet: USDY | ondo | $1.1290 | $587,132,506 OUSG | ondo | $114.8500 | $388,964,385 BUIDL | securitize | $1.0000 | $168,501,226 syrupUSDC | maple | $1.1590 | $1,786,175,587 The compliance layer is especially useful for builders. A single can_transfer() call handles all five compliance models behind a unified interface: check = rwa.can_transfer("USDY", sender_address, receiver_address) print(check.can_transfer) # True / False print(check.method) # ComplianceMethod.BLOCKLIST print(check.restriction_message) # "sender is on the blocklist" What it gets right: Everything is a direct eth_call. No intermediary, no stale cache, no rate limits beyond what your RPC endpoint enforces. The bundled JSON ABIs mean you don't need to fetch them from Etherscan at runtime. Multi-chain works by instantiating one RWAChain per network — BUIDL is deployed on Ethereum, Arbitrum, Polygon, and Avalanche, and the SDK handles each instance independently. What it misses: Protocol coverage is limited to the five major issuers. If you're querying Goldfinch, Centrifuge pools beyond JTRSY, or emerging issuers on Ondo Chain, you'll need to write a custom adapter. The custom adapter interface is clean — the ProtocolAdapter protocol requires only protocol, chain_id, all_tokens(), and can_transfer() — but you're still writing it yourself. Infrastructure requirement: A reliable Ethereum mainnet RPC endpoint. Public endpoints cap at 100 requests per minute. Any production workload — periodic NAV polling, compliance screening at scale, multi-chain token aggregation — will exhaust that quota quickly. Use a Chainstack Ethereum node to remove the rate limit ceiling and get archive access for historical queries. Install: pip install git+https://github.com/chainstacklabs/rwa-sdk Get a Chainstack RPC endpoint for RWA querying → 2. RWA.xyz API — best for market-level analytics and issuer data Type: Analytics & market data API · Language: REST / JSON · License: Proprietary · Link: app.rwa.xyz/platform-overview What it is: A purpose-built analytics platform for tokenized real-world assets, with a data API for institutional and developer use. The platform tracks tokenized assets across categories (U.S. Treasuries, private credit, commodities, equities, real estate), issuers, chains, and platforms. The public dashboard gives a fast market overview. The API layer — accessible after registration — adds data exports, visual query building, historical time-series, and structured JSON responses. A sample response looks like this: { "entity": { "issuer_name": "BlackRock", "issuer_domicile": "British Virgin Islands", "custodian": "Bank of New York Mellon Corporation", "auditor": "PricewaterhouseCoopers" } } Beyond token-level data, RWA.xyz tracks issuer metadata (custodian, auditor, regulatory framework, domicile), network distribution, and category-level flows. Their November 2025 framework update introduced a "Distributed vs. Represented" classification — distributed assets can move to external wallets, represented assets cannot — which is practically important for developers building custody integrations. As of 2026, the platform covers 400+ tokenized assets across 70+ chains and connects to Snowflake, BigQuery, and S3 for data warehouse delivery. What it gets right: Market-wide coverage that no on-chain query tool can match. If you need issuer due diligence data, historical TVL trends, or a structured securities master for a fintech product, this is the right layer. The visual query builder generates code snippets for notebooks and dashboards. What it misses: It's a data layer, not a querying SDK. You're querying RWA.xyz's database, not the blockchain directly. For real-time price reads or compliance checks that must be on-chain verifiable, the SDK approach (above) is more appropriate. API access tiers are gated — deep features require a professional subscription. Best for: Research applications, institutional dashboards, market intelligence tools, fintech apps that need issuer metadata alongside token data. 3. Centrifuge API — best for private credit pool data Type: Private credit pool data (GraphQL) · Language: GraphQL / TypeScript SDK · License: Apache 2.0 · Link: docs.centrifuge.io/developer/centrifuge-api What it is: A public, read-only GraphQL endpoint for querying on-chain data from the Centrifuge protocol — the largest private credit RWA platform by origination volume, with over $2B in tokenized assets across 9 chains. The API is available at https://api.centrifuge.io with no authentication required. Centrifuge's data model is richer than most RWA APIs. A pool is the top-level entity, grouping share class tokens, vaults, and asset holdings across multiple networks. Each pool can issue several tokens, deploy vaults on different chains, and manage assets through a unified on-chain structure. The API exposes all of this: pool metadata, token prices, vault positions, investor transactions, and historical snapshots. { pools(first: 10, orderBy: "totalIssuance", orderDirection: "desc") { id currency { symbol } tokens { tokenPrice totalIssuance } } } TVL per token is calculated as totalIssuance * tokenPrice, adjusted for decimals. Snapshots capture entity state at specific points in time — available for pools, tokens, token instances, and holdings — making historical NAV queries straightforward without needing an archive node. Beyond the GraphQL API, Centrifuge also ships @centrifuge/sdk, a TypeScript/JavaScript client that covers the full investment lifecycle: quotes, deposits, redemptions, claims, and reporting. It runs client-side and server-side, and supports Centrifuge's hub-and-spoke architecture where a single pool issues tokens across Ethereum, Base, Arbitrum, Avalanche, Plume, BNB Chain, Optimism, HyperEVM, and Monad. What it gets right: Depth of private credit data. No other tool in this list gives you pool-level tranche structure, investor transaction history, and cross-chain vault positions for private credit instruments in a single query. The API is free, public, and actively maintained by the Centrifuge team — unlike third-party subgraphs that can fall behind on indexing. What it misses: Centrifuge-only coverage. If you're querying Maple, Goldfinch, or Ondo alongside Centrifuge pools, you need additional tools. The API is also an indexing layer, not a real-time on-chain read — there's indexing lag, and compliance checks still require direct eth_call. Best for: Applications built on Centrifuge pools, private credit portfolio dashboards, any workflow that needs historical NAV data or investor transaction history for Centrifuge-issued tokens. 4. RedStone — best for NAV oracles in DeFi protocols using RWA collateral Type: NAV oracle (pull-based) · Language: Solidity / multi-chain · License: BSL 1.1 · Link: docs.redstone.finance What it is: A blockchain oracle network specializing in real-world asset pricing, and the official oracle partner of Securitize — the transfer agent behind BlackRock's BUIDL and Apollo's ACRED. Where DIA provides general-purpose oracle feeds, RedStone has built pricing infrastructure specifically for tokenized assets: NAV calculations, illiquidity adjustments, and regulatory compliance requirements that standard oracle designs weren't built to handle. RedStone's RWA oracle currently powers price feeds for BUIDL, ACRED (Apollo Diversified Credit), VBILL (VanEck), and tokenized sovereign debt instruments. These feeds are live on Ethereum, Solana, Polygon, and more recently Stellar — where RedStone implemented SEP-40, a unified high-frequency pricing interface for on-chain RWA assets. The key architectural difference from DIA: RedStone uses a pull-based model where price data is delivered on demand alongside the transaction that needs it, rather than being pushed to the chain on a fixed schedule. For RWA tokens, this matters because NAV updates are infrequent (daily or weekly) — you don't need a continuously updated on-chain feed, you need accurate data available exactly when a user interacts with the protocol. For developers integrating RWA collateral into lending protocols, RedStone's feeds are the correct layer. The ACRED feed, for example, was successfully deployed in a Morpho vault on Polygon — one of the first live DeFi vaults to use a major RWA as collateral — and on Solana via Drift Institutional. What it gets right: NAV accuracy for institutional-grade assets. RedStone explicitly handles the complexity that generic oracle networks skip: pricing mechanisms that account for NAV calculations, regulatory compliance, and illiquidity adjustments for thinly traded assets. The Securitize partnership gives them direct data access rather than inferring prices from secondary markets. What it misses: RedStone is an oracle for DeFi protocol developers, not a data querying tool for analytics applications. It doesn't return compliance check results, TVL figures, or token metadata. If your use case is building a dashboard or querying token state for reporting, you need a different layer. RedStone is the right answer to one specific question: "how do I price this RWA token correctly inside a smart contract?" Best for: DeFi protocols using RWA tokens as collateral (lending markets, vaults, derivatives), any on-chain use case that needs NAV-accurate pricing for institutional tokenized assets. 5. Ondo Finance API — best for integrating directly with the largest tokenized treasury issuer Type: Issuer REST API · Language: REST / OpenAPI · License: Proprietary · Link: docs.ondo.finance/api-reference/overview What it is: The official developer API from Ondo Finance — the largest tokenized treasury issuer by TVL, with over $1B in USDY and OUSG combined. The API covers pricing, quote generation, token lifecycle, and token contract metadata for Ondo's full product line, including Global Markets (tokenized US stocks and ETFs). The full OpenAPI specification is available at docs.ondo.finance/openapi.json for use with code generators. A typical pricing call returns authoritative NAV data directly from Ondo's system — not inferred from DEX pools. What it gets right: This is the authoritative source for Ondo token data. Where the rwa-sdk queries Ondo's on-chain oracle contracts directly via eth_call, the Ondo API gives you the same NAV data via REST with additional context: quote generation for mint/redeem flows, token metadata, and round information. For any application that needs to integrate mint or redemption flows — not just read token state — the API is the required layer. What it misses: Ondo-only coverage. The API doesn't know about Maple, Backed, BUIDL, or Centrifuge. If your use case spans multiple issuers, you still need a multi-protocol tool alongside it. Best for: Applications building directly on top of Ondo tokens — mint/redeem integrations, portfolio apps focused on USDY/OUSG, fintech products that need authoritative NAV data from the source. 6. The Graph — best for event-indexed historical data from private credit protocols Type: On-chain event indexing (GraphQL) · Language: GraphQL / AssemblyScript · License: MIT · Link: thegraph.com What it is: A decentralized indexing protocol that allows developers to query blockchain data via GraphQL using protocol-specific "subgraphs." Several major RWA protocols have published and maintained subgraphs on The Graph network. Centrifuge's subgraph indexes pool-level data: asset originators, tranche structures, NAV updates, and loan performance. Maple Finance's subgraph covers pool deposits, withdrawals, loan originations, and repayments. Goldfinch has a similar subgraph for its credit pools. For private credit protocols where the interesting data is in events rather than current state, subgraphs are the right query layer. A basic Centrifuge query: { pools(first: 10, orderBy: totalReserve, orderDirection: desc) { id name totalReserve totalBorrowed currency { symbol } } } What it gets right: Historical event data at any granularity. If you need to know how a Centrifuge pool's NAV evolved over the past six months, or track Maple withdrawal requests over time, subgraphs are the most efficient access layer. The GraphQL interface is clean and composable. What it misses: Subgraph coverage is uneven. Ondo Finance does not have a maintained subgraph on The Graph network — its oracle data requires direct eth_call. Securitize BUIDL data is similarly not indexed. For the tokenized treasury segment (which dominates RWA TVL), The Graph provides limited coverage. Subgraph data is also indexed, not real-time. There's indexing lag — typically seconds to minutes — which matters for compliance checks or live pricing. Best for: Historical analysis of private credit protocols, portfolio performance reporting on Centrifuge and Maple pools, event-driven data pipelines for Goldfinch. 7. DeFiLlama API — best for TVL aggregation and protocol-level benchmarking Type: Protocol TVL aggregation · Language: REST / JSON · License: MIT · Link: defillama.com/docs/api What it is: An open, free API for protocol TVL data across DeFi and RWA. DeFiLlama tracks tokenized treasury products, private credit protocols, and gold tokens, aggregating TVL from on-chain data into clean REST endpoints. For a developer who needs market context — which protocols are growing, how Maple's TVL compares to Centrifuge's, where BUIDL sits relative to USDY — DeFiLlama is the fastest free option. The API requires no authentication and returns structured JSON. curl "https://api.llama.fi/protocol/ondo-finance" What it gets right: Zero cost, zero auth, clean API. For market context, competitive benchmarking, or populating a dashboard with protocol-level TVL data, DeFiLlama is unmatched in terms of access friction. Coverage extends to 8,000+ protocols; RWA-specific filtering works via category and chain parameters. What it misses: TVL is DeFiLlama's output — everything else (token price, compliance data, yield type, holder counts) requires another tool. Protocol-level TVL is also a coarser metric than token-level NAV. DeFiLlama's BUIDL TVL includes all BUIDL variants across chains; the rwa-sdk lets you query each deployment independently. Best for: Market research, protocol comparison, dashboard widgets showing RWA market size, any use case where TVL context is the primary requirement. How to choose the right tool The decision tree is simpler than the tool count suggests. If you need protocol-accurate, on-chain data (NAV, yield, compliance): Start with the Chainstack rwa-sdk. It covers 90%+ of on-chain RWA value with normalized output and a clean compliance interface. Add a custom adapter for any protocol not yet supported. If you need market-wide issuer and analytics data: RWA.xyz API sits above the chain layer and provides coverage and context that on-chain tools can't match — 400+ assets, historical flows, issuer metadata. If you're pricing RWA tokens inside smart contracts: RedStone or DIA. Both are oracle networks, but RedStone is the official Securitize partner and purpose-built for NAV-accurate pricing of institutional assets like BUIDL and ACRED. DIA covers a broader range of RWA protocols. If your collateral includes Securitize-issued assets, RedStone is the more reliable feed source. If you're building directly on Ondo tokens: The Ondo Finance API is the authoritative source for NAV, quotes, and mint/redeem flows — use it instead of inferring prices from DEX data or third-party aggregators. If you need private credit pool data (Centrifuge): The Centrifuge API is the right first stop — free, public, no auth, with pool-level tranche data and historical snapshots that no other tool provides. For Maple or Goldfinch, The Graph subgraphs are the fallback. If you need TVL benchmarks and market context: DeFiLlama for free, RWA.xyz for depth. Comparison at a glance ToolData sourceRWA-specificCompliance checksHistorical dataCostChainstack rwa-sdkOn-chain (eth_call)YesYesWith archive nodeFree (OSS)RWA.xyz APIIndexed/off-chainYesNoYesFreemiumCentrifuge APIIndexed/off-chainYes (private credit)NoYesFreeRedStoneOracle networkYes (NAV-focused)NoYesFreemiumOndo Finance APIIssuer (off-chain)Yes (Ondo only)NoNoProprietaryThe GraphOn-chain (indexed)PartialNoYesFreemiumDeFiLlama APIAggregatedNoNoYesFree Infrastructure requirements for production RWA querying The tools above share a dependency: any workflow making on-chain calls needs a reliable RPC endpoint. Public Ethereum endpoints cap at 100 requests per minute and are shared across all users. A production app polling NAV for 20 RWA tokens every 30 seconds makes 40 requests per minute on the read side alone — before compliance checks, balance queries, or any additional chain state. Two users will start competing for quota immediately. For RWA-specific workloads, infrastructure requirements are somewhat different from DeFi trading bots. NAV updates for tokenized treasuries 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 can become untradable until the state is corrected. Archive node access is also relevant. Historical NAV reads — needed for performance reporting, audit trails, and reconciliation — require querying state at specific historical block numbers. Full nodes only store recent state; archive nodes store everything from genesis. Chainstack provides both full and archive Ethereum nodes with geo-balanced global endpoints, no shared rate limits on dedicated plans, and SOC 2 Type II certification for teams operating in regulated environments. from rwa_sdk import RWAChain # Production setup with Chainstack rwa = RWAChain( rpc_url="https://ethereum-mainnet.core.chainstack.com/YOUR_KEY" ) # All tokens, live prices, compliance-ready for token in rwa.all_tokens(): print(f"{token.symbol}: ${token.price:.4f} | TVL ${token.tvl:,.0f}") Start querying RWA tokens with a Chainstack node → Conclusion Querying RWA tokens requires navigating a fragmented landscape: four compliance models, three yield patterns, and no standard oracle interface across the five largest issuers. General-purpose ERC-20 tools return partial data; building protocol-specific logic from scratch means maintaining five separate ABI files and parsing five different response formats. The Chainstack rwa-sdk exists because this problem keeps appearing in every project that touches tokenized finance. A single rwa.all_tokens() call returns normalized data for the protocols that hold the majority of on-chain RWA value, with a unified compliance interface across all of them. For market context and research, pair it with RWA.xyz. For private credit pool data, the Centrifuge API. For on-chain pricing in smart contracts, RedStone for institutional assets, The Graph for Maple and Goldfinch event history. These tools cover different layers of the same stack — use the right one for each layer. FAQ What RPC method does the Chainstack rwa-sdk use internally? All data reads use eth_call — the standard EVM method for calling view functions without creating a transaction. No indexer, no API key beyond the RPC endpoint, no database. The SDK ships bundled JSON ABIs for every contract it queries, so there's no runtime ABI fetching. Can I query BUIDL on Arbitrum and Polygon, not just Ethereum? Yes. BlackRock BUIDL via Securitize is deployed on Ethereum, Arbitrum, Polygon, and Avalanche. With the rwa-sdk, instantiate a separate RWAChain per network and pass the appropriate RPC URL for each chain. Chainstack provides nodes for all four networks. What's the difference between NAV and market price for tokenized treasuries? NAV (Net Asset Value) is the authoritative price set by the protocol's oracle or pricing mechanism — what the token is worth for redemption. Market price is what someone will pay for it on a DEX, which can deviate due to thin liquidity. For compliance-sensitive applications (audits, regulatory reporting, fund accounting), always use NAV from the protocol's oracle. The rwa-sdk queries NAV by default. Do I need an archive node to use the rwa-sdk? Not for current-state queries. rwa.all_tokens() and can_transfer() query current blockchain state and work with any full node. For historical queries — what was OUSG's price at block 19,000,000, or what was BUIDL's TVL three months ago — you need an archive node. Chainstack offers archive access on dedicated node plans. What compliance models does the rwa-sdk handle? Five: blocklist (Ondo USDY/rUSDY), KYC registry (Ondo OUSG/rOUSG), Chainalysis sanctions screening (Backed), bitmap permission manager (Maple syrupUSDC), and DS Protocol pre-transfer check (Securitize BUIDL). All are exposed through the same can_transfer() interface, returning a ComplianceCheck object with can_transfer, method, restriction_message, and blocking_party. How does the rwa-sdk handle tokens where Chainstack isn't the data source? The rwa-sdk is entirely RPC-based. "Chainstack" in this context is the RPC node provider, not a data layer. You can use the SDK with any Ethereum-compatible RPC endpoint — public or private. The Chainstack RPC is recommended for production because it removes rate limit constraints and adds archive access, but the SDK itself works with any provider. #### Top 7 trading bots on Hyperliquid in 2026 Most Hyperliquid trading bots fail not because of strategy logic, but because the data pipeline underneath them can't keep up. The exchange's fully on-chain CLOB processes 200,000 orders per second, settlement events bunch into millisecond windows, and public endpoints cap at around 100 requests per minute. A bot that works fine in testing starts missing fills, stale-quoting, or throwing rate-limit errors the moment real market activity shows up. This guide covers the top seven trading bots for Hyperliquid in 2026 — spanning open-source developer frameworks, backtested strategy tools, no-code retail automation, and social/copy trading. For each one, you'll find what strategy it runs, who it's actually built for, and what infrastructure it requires to run in production. Why Hyperliquid bot development is different Before ranking tools, it helps to understand what makes Hyperliquid an unusual venue for automated trading. Hyperliquid runs a fully on-chain central limit order book. There's no off-chain matching engine, no centralized custody, and no API key linked to a custodial account. Orders are signed transactions broadcast to the network — which means every cancel, fill, and price update is a chain event, not a database write. For bots, this has three concrete consequences: Order placement is slower than CEX. On Binance, a REST order placement round-trip takes 10–50 ms. On Hyperliquid, a signed order needs to reach the network and clear consensus, typically 200–500 ms on HyperCore. Strategies that rely on sub-100ms execution need to run close to a Hyperliquid node, not a generic cloud server. WebSocket feed quality determines everything. Hyperliquid's WebSocket API emits real-time order book updates, user fills, and position changes. A bot using HTTP polling misses fills, accumulates stale position data, and risks double-submitting orders. Every production bot in this list uses WebSockets. If yours doesn't, fix that before anything else. The public RPC is a shared resource. At ~100 requests/minute on the public endpoint, two concurrent users with active bots will start competing for quota. The moment you add any volume or complexity — grid rebalancing, HIP-4 settlement tracking, multi-asset positioning — you need a dedicated Hyperliquid RPC node on Chainstack with private rate limits and no noisy neighbors. With that context established, here are the seven bots worth your attention. The 7 best Hyperliquid trading bots 1. Chainstack hyperliquid-trading-bot — Best open-source grid bot for builders Type: Grid trading (perpetuals)Language: PythonLicense: Apache 2.0Link: github.com/chainstacklabs/hyperliquid-trading-bot This is the most complete open-source starting point for anyone building on Hyperliquid. The repo ships a working grid bot with real risk controls, a conservative BTC preset, and a learning_examples/ directory that doubles as an unofficial Hyperliquid Python SDK tutorial. The grid strategy places a ladder of buy and sell orders inside a configurable price band. When price drifts outside the range, the bot rebalances — cancels stale orders and re-centers the grid. The default btc_conservative.yaml config runs 10 grid levels, a ±5% auto-range, and caps at 10% of account allocation. You can clone this config, swap the asset and grid width, and have a working bot on testnet in under an hour. What makes it production-ready: Stop-loss (1–20%), take-profit (5–100%), max drawdown (5–50%), and max position size are all configurable per bot, not hardcoded --validate flag lets you dry-run config parsing and connection checks before any orders go live HYPERLIQUID_TESTNET=true environment variable routes all activity to testnet by default — you have to explicitly switch to mainnet The learning_examples/ tree covers authentication, market data, account state, order placement, cancellation, WebSocket streaming, and copy trading — usable as a standalone reference independent of the bot Who it's for: Python developers who want a clean, forkable baseline to extend. Not a SaaS product — you own the code, you control the keys. The learning examples make this the best starting point even if you don't intend to run a grid strategy. Infrastructure note: The bot connects to Hyperliquid's public API by default. For anything beyond testnet experimentation or very low-frequency strategies, you'll want a private Chainstack Hyperliquid endpoint — the public rate limits are too aggressive for production grid operations. 2. Hummingbot — Best market-making framework Type: Market making, arbitrage, cross-exchange strategiesLanguage: Python (Cython hot paths)License: Apache 2.0Link: github.com/hummingbot/hummingbot Hummingbot is the standard framework for professional market making across crypto venues, and Hyperliquid is now a sponsoring exchange of the Hummingbot Foundation. Both hyperliquid and hyperliquid_perpetual connectors are maintained in the core repo, supporting both Arbitrum wallet + private key auth and API-key auth. The framework's native Hyperliquid Vault integration is the standout feature. You can run a Hummingbot strategy directly as a Vault leader — your bot's P&L is automatically shared with depositors, and you earn 10% on profitable withdrawals. It converts a self-contained algorithmic strategy into a structured product without building any additional infrastructure. Key strategies for Hyperliquid: Pure market making (PMM): Place symmetric limit orders around mid-price, collect spread. The most common Hummingbot strategy on Hyperliquid. Cross-exchange market making (XEMM): Quote Hyperliquid based on prices from a CEX hedge venue — useful when Hyperliquid spreads lag centralized markets. Funding-rate arbitrage: Go long on the venue with negative funding, short on the venue with positive funding. The Foundation has published a Hyperliquid-specific guide for this. AMM arbitrage: Profit from divergence between Hyperliquid perp prices and AMM spot prices on the same assets. Who it's for: Algo traders and market makers who need a battle-tested framework with proper order-state management, not a hand-rolled script. Hummingbot has a real learning curve — expect 2–4 hours to configure your first strategy from scratch. But the framework depth is unmatched in open source. 3. Freqtrade — Best multi-strategy bot with backtesting Type: Signal-based directional strategies, backtestedLanguage: PythonLicense: GPL-3.0Link: github.com/freqtrade/freqtrade Freqtrade connects to Hyperliquid through CCXT (added in 4.5.20) and is the only bot in this list with a first-class backtesting workflow. You write a Python IStrategy class that defines entry/exit signals, then run freqtrade backtesting against historical data before deploying. That workflow — research, backtest, optimize, deploy — is standard in quantitative trading but rare among Hyperliquid-native bots. The FreqAI module adds ML-based signal generation. It trains models against historical OHLCV data, feeds predictions into your strategy, and retrains on a rolling basis as new data arrives. For traders who want data-driven edge without building a full ML pipeline from scratch, this is the fastest path. Key features: Dry-run and paper-trading mode before going live Telegram and Web UI for monitoring active positions Hyperopt for automated parameter search across strategy configs Whitelists, blacklists, and dynamic pair lists — useful for filtering Hyperliquid's growing perp listing Supports leverage on Hyperliquid perp positions Who it's for: Python-comfortable traders and small quant teams who want to research before risking capital. If you're the type who wants to see a backtest before trading, Freqtrade is the only Hyperliquid-compatible tool that takes backtesting seriously. Caveat: HIP-3 builder-deployed equity perps (e.g., XYZ-TSLA/USDC:USDC) use a non-standard ticker format. CCXT support for these is tracked in open issues and partially implemented. Confirm your target instruments work before building a strategy around them. 4. HyperLiquidAlgoBot — Best indicator-based HFT reference in JavaScript Type: Indicator-driven mean-reversion / momentumLanguage: JavaScript (Node.js)License: MITLink: github.com/SimSimButDifferent/HyperLiquidAlgoBot Nearly every open-source Hyperliquid bot is written in Python. This one isn't — and that matters if your team runs Node.js services, your infrastructure is JavaScript-native, or you simply don't want to context-switch between ecosystems. The core strategy combines Bollinger Bands, RSI, and ADX on 15-minute candles or shorter timeframes. When bands are tight (low volatility), RSI shows oversold/overbought conditions, and ADX confirms trend strength, the bot enters a position in the signal direction. It's a classic technical-analysis recipe, but the implementation includes real risk management: a RiskManager.js module handles position sizing, stop placement, and drawdown limits. What makes it worth including: Modular architecture — src/application/, src/backtesting/, src/hyperliquid/, src/strategy/ are cleanly separated and forkable independently Backtester.js engine with a historical data folder — you can run strategy tests before deploying MLEnhancedStrategy.js module adds an ML layer on top of the base indicator signals Visualization output for reviewing backtest results Who it's for: JavaScript developers who want a working HFT-style reference with backtesting built in. Not as mature as Freqtrade or Hummingbot in terms of community and documentation, but the only serious JS option for Hyperliquid. 5. Chainstack hyperliquid-hip-4 — Best reference for HIP-4 prediction-market bots Type: Passive market making on outcome (YES/NO) booksLanguage: PythonLicense: Apache 2.0Link: github.com/chainstacklabs/hyperliquid-hip-4 HIP-4 trading bots: what's different HIP-4 is Hyperliquid's binary prediction-market primitive. It went live on mainnet May 2, 2026, with a daily BTC binary as the inaugural market. Outcome contracts settle to 0 or 1 in USDH, are fully collateralized, charge zero fee to open, and — critically — share the same CLOB and unified margin account as Hyperliquid perps and spot. That last point is the commercial insight. You can hedge a BTC perp position with a BTC binary in the same margin account. No capital transfer, no separate venue, no additional settlement risk. That cross-product hedge doesn't exist on Polymarket or Kalshi. The hyperliquid-hip-4 repo is currently the only public open-source reference for trading these markets. It covers: #N-style coin notation specific to HIP-4 (outcome contracts use a different ticker format than perps) outcomeMeta discovery — how to find available markets and parse their description-encoded contract specs Merged YES/NO order books with price-side-time priority USDH collateral routing and settlement-aware position handling A passive market-maker bot that quotes both sides of an outcome book Who it's for: Advanced developers and prop teams who want to be early on HIP-4 before the market matures. This is a starter kit, not a turnkey product. The HIP-4 ecosystem is still in its first weeks — liquidity is thin and pricing models are unproven. That's a risk and an opportunity simultaneously. Infrastructure note: HIP-4 settlement events create concentrated burst load. When a market resolves, the chain emits position closures, USDH transfers, and order-book state updates in a millisecond window. Public endpoints will miss these. A private Chainstack node with WebSocket support is non-negotiable for any real HIP-4 trading operation. New to Hyperliquid testnet? Grab free HYPE testnet tokens from the Chainstack Hyperliquid faucet to test your HIP-4 bot without risking real funds. 6. goodcryptoX — Best no-code retail bot suite Type: Grid, DCA, Infinity Trailing, TradingView webhooksPlatform: Web, iOS, Android (closed source)Link: goodcrypto.app/hyperliquid-trading-bot goodcryptoX fills the gap between Hyperliquid's native UI (which offers no automated strategies) and professional frameworks like Hummingbot (which require engineering investment). It's a non-custodial app that connects to your Hyperliquid account via an API wallet — one that can place orders but cannot withdraw — and adds a layer of CEX-grade automation on top. The standout features are things Hyperliquid's own interface doesn't offer: trailing stop orders, multi-target take-profits, and on-chart order visualization. For retail traders used to running bots on Binance or Bybit, the experience translates directly. Strategies available: Grid bot: Place a ladder of orders in a price range. Long grid, short grid, or neutral grid. One of the few no-code grid implementations on Hyperliquid. DCA bot: Average into a position on time-based or price-based triggers. Infinity Trailing: A trending variant of the grid that shifts the range as price moves — useful in strong directional markets where a fixed grid gets left behind. TradingView webhooks: Route TradingView alerts directly to order execution, without writing code. Who it's for: Retail traders who want systematic automation without writing Python. Especially useful if you already run strategies on CEXs and want the same tooling on Hyperliquid. Not suitable for developers who want to customize execution logic — the strategy layer is locked behind the product UI. 7. Hyperliquid Copy Trader — Best automated copy trading bot Type: Copy trading (wallet mirroring)Language: PythonLicense: MITLink: github.com/MaxIsOntoSomething/Hyperliquid_Copy_Trader Copy trading on Hyperliquid usually means manually watching a wallet and repeating trades by hand. This bot automates the entire loop: it monitors a target wallet via WebSocket in real time, detects position changes the moment they happen, and mirrors them to your account with proportional sizing — no manual intervention required. The position sizing logic is the key technical detail. The bot calculates your trade size as a ratio of your account balance to the leader's balance. If the leader has $100k and opens a 1% position, and you have $10k, the bot opens a 0.1 BTC equivalent — not a flat copy. This prevents the most common copy trading failure mode where a large leader's position size blows out a small follower's account. Key features: Dry mode (default): Tracks and logs what trades would be executed without placing any real orders — essential for validating the leader wallet before committing capital Proportional position sizing — automatically scaled to your account balance vs the leader's Blocked assets list — exclude specific coins from copying, case-insensitive (BTC, btc, Btc all work) Leverage cap — automatically rounded to integers and capped at Hyperliquid's per-asset maximums Linux shell scripts — start.sh, stop.sh, logs.sh for straightforward process management Who it's for: Traders who want to follow a specific on-chain wallet programmatically — a known alpha trader, a Hyperliquid Vault leader, or your own second account for strategy mirroring. Requires basic Python setup but no strategy coding. The dry mode makes it safe to evaluate before going live. Caveat: Hyperliquid enforces a $10 minimum notional per order. If your balance is significantly smaller than the leader's, small fills will be skipped when the proportional size falls below that threshold. Size your account accordingly or adjust the POSITION_SIZE_MULTIPLIER in config. Quick comparison table BotStrategy typeWho it's forOpen sourceBacktestingHIP-4 supportChainstack trading botGrid (perps)Python developers✅❌❌HummingbotPMM / XEMM / arbitragePro market makers✅✅❌FreqtradeIndicator / signal-basedQuant researchers✅✅❌HyperLiquidAlgoBotIndicator HFTJS developers✅✅❌Chainstack HIP-4 botMarket making (outcomes)Advanced builders✅❌✅goodcryptoXGrid / DCA / TrailingRetail, no-code❌❌❌Hyperliquid Copy TraderCopy trading (wallet mirror)Python traders✅❌❌ How to choose You're a developer who wants to start today: Clone chainstacklabs/hyperliquid-trading-bot. Run uv run src/run_bot.py --validate on testnet with the default btc_conservative.yaml config. Don't customize strategy logic yet — first confirm your data pipeline is stable for 48 hours with no API errors, no precision rejections, and no missed WebSocket messages. Only then extend. You want to trade HIP-4 outcome markets: Use chainstacklabs/hyperliquid-hip-4 as your reference. Read the outcomeMeta discovery examples before touching the market-maker bot. Phase 1 markets are curated by the Hyperliquid team — you're trading existing markets, not deploying your own. Plan for burst load on settlement: your endpoint needs to handle the resolution spike cleanly. You're a market maker or professional algo trader: Hummingbot is the framework. The Vault integration converts your strategy into a yield product for depositors, which changes the economics significantly — your successful algo generates fee income even at modest capital levels. You need to backtest before committing capital: Freqtrade. Nothing else in this list takes historical simulation as seriously. Configure HYPERLIQUID_TESTNET=true in CCXT, run hyperopt across your strategy parameters, then move to paper trading before going live. You're a retail trader who doesn't code: goodcryptoX for systematic strategies (grid in ranging markets, DCA in trends). For copy trading, run Hyperliquid Copy Trader in dry mode first — evaluate the leader wallet for a week before committing capital. Getting a Chainstack Hyperliquid endpoint Sign up at Chainstack, create a project, and deploy a Hyperliquid node in under two minutes: Navigate to Add node → Hyperliquid → Mainnet (or Testnet) Choose Global Nodes for instant setup or Dedicated Nodes for isolated production throughput Copy your HTTPS endpoint and WebSocket URL from the node dashboard Replace the public URL in your bot's .env — then re-run --validate to confirm For testnet work, the Chainstack Hyperliquid faucet gives you free HYPE testnet tokens to fund your dev wallet without touching mainnet funds. Before going live, confirm four things: WebSockets are used for fills (not HTTP polling), your endpoint won't rate-limit under normal load, a stop-loss and max-drawdown are set and tested, and your API wallet has order-only permissions — no withdrawal access. Run on testnet for 48 hours without errors before touching mainnet funds. 📖 For a full walkthrough of building a Hyperliquid trading bot from scratch — including authenticated order placement, WebSocket integration, and risk-control configuration — see How to build a Hyperliquid trading bot on the Chainstack blog. Conclusion Here's what this list proves that isn't obvious upfront: on Hyperliquid, your bot category determines your infrastructure tier more than your strategy complexity does. A Hyperliquid Copy Trader user following one wallet and a Hummingbot market maker quoting 50 pairs can both tolerate the public endpoint — one trades infrequently, the other runs on dedicated hardware anyway. The bots that actually break on public infrastructure are the ones in the middle: grid bots rebalancing every few minutes, and HIP-4 market makers that need to survive settlement spikes. Those two categories have structurally different endpoint requirements not because their strategies are sophisticated, but because their event patterns are — steady high-frequency ticks for grids, burst load for HIP-4 resolution. That's the practical framework: social and directional bots are relatively forgiving on infrastructure; grid and outcome-market bots are not. Size your endpoint before you size your position. Chainstack's Hyperliquid infrastructure covers all three tiers — shared Global Nodes for getting started, Dedicated Nodes for grid and market-making workloads that need guaranteed throughput, and WebSocket support across both for the real-time fill tracking every production bot depends on. Deploy a Hyperliquid node on Chainstack → FAQ What's the best trading bot for Hyperliquid in 2026? It depends on your profile. For Python developers who want a clean, forkable foundation: the Chainstack hyperliquid-trading-bot is the best open-source starting point. For no-code retail traders: goodcryptoX. For professional market makers: Hummingbot with its native Hyperliquid Vault integration. There's no single "best" — the right answer depends on whether you write code, what strategy you want to run, and how much infrastructure you're willing to manage. What is HIP-4 and why does it matter for trading bots? HIP-4 is Hyperliquid's binary prediction-market primitive, launched on mainnet May 2, 2026. Outcome contracts settle to 0 or 1 (fully collateralized in USDH), charge zero fee to open, and share Hyperliquid's CLOB and unified margin with perps and spot. The key insight for bot builders: you can hedge a perps position with a binary event contract in the same margin account, on the same chain. This cross-product hedge doesn't exist on Polymarket or Kalshi. The Chainstack hyperliquid-hip-4 repo is the only public open-source reference for building HIP-4 trading bots. Can I run a trading bot on Hyperliquid without an API key? Yes. Hyperliquid doesn't use traditional API keys — bots interact by signing transactions with a private key (or an API wallet derived from your main key). An API wallet can place and cancel orders but cannot withdraw funds, making it safer to use in automated systems. All seven bots in this list support this pattern. What's the difference between using the public Hyperliquid endpoint and a private RPC? The public endpoint is rate-limited to approximately 100 requests per minute and is shared infrastructure. A private Chainstack node gives you dedicated throughput, no rate-limit competition, WebSocket support, and archive access. For testnet experimentation, the public endpoint is fine. For production bots — especially grid bots that rebalance frequently or market makers that quote continuously — you need a dedicated node. You can get one at chainstack.com/build-better-with-hyperliquid. Is it safe to run a Hyperliquid trading bot? No automated trading system is "safe" in the sense of guaranteed profit or zero risk of loss. Specific risks on Hyperliquid include: position liquidation from adverse price moves, API errors causing missed cancel orders, precision-rejection errors that leave stale orders on the book, and strategy logic bugs. Mitigate these by: always setting stop-loss orders, using an API wallet (not your main wallet) for bot operations, testing thoroughly on testnet before mainnet, and starting with a small allocation (10% or less of account) until you've validated live performance. Does Freqtrade support Hyperliquid perps? Yes, via CCXT. Standard perps are supported. HIP-3 builder-deployed equity perps (e.g., Tesla, Apple shares tokenized as Hyperliquid perpetuals) use a non-standard ticker format and are partially supported in CCXT — check the CCXT issue tracker before building a strategy that depends on them. How do I get testnet HYPE to test my bot without real funds? Use the Chainstack Hyperliquid testnet faucet. It dispenses free HYPE testnet tokens to your development wallet. Set HYPERLIQUID_TESTNET=true in your bot's environment variables, run the --validate flag first, and confirm the testnet connection is stable before writing any strategy logic. Additional resources How to build a Hyperliquid trading bot Hyperliquid HIP-4 vs Polymarket: outcome markets compared What is Hyperliquid? Get a Hyperliquid RPC endpoint Chainstack Hyperliquid testnet faucet chainstacklabs/hyperliquid-trading-bot chainstacklabs/hyperliquid-hip-4 #### TradFi, CeFi, and DeFi: Bridging the new frontier of the FinTech revolution on towards the stars In this era of fast-paced advancements, change is the only constant. Nowhere is this change more apparent than in the sphere of finance. We see indelible shifts in structures and practices of financial transactions, as we move from traditional financing to embracing decentralized systems, marking a new epoch of finance. Decentralized Finance, commonly known as DeFi, is pegged to be a revolutionary concept, charting an innovative course in the financial world. Whereas its counter-concept, Centralized Finance, or CeFi, provides a reminiscence of our traditional financial systems, acting as a necessary bridge. This blog post will delve deep into understanding these systems, comparing them, addressing the challenges they currently face, and exploring their future potential. What is Traditional Finance (TradFi) Traditional finance, also known as TradFi, serves as the backbone of our global financial ecosystem. It is the conventional financial system that has stood the test of time, since the dawn of civilization. Originating centuries ago and evolving continually to meet the shifting needs of society, TradFi sets the groundwork for our understanding of finance. And being the original configurations of banking, lending, investment, and more, TradFi has shaped the economy as we know it. As the oldest form of the financial system, its systems are centralized, with primary control in the hands of various institutions that follow the regulatory frameworks per their jurisdiction. Dominated by intermediaries like banks, stock exchanges, payment operators, and insurance companies, TradFi is heavily regulated by government bodies and institutions, leading to different regulatory frameworks across jurisdictions. The traditional sector encompasses some of the world's largest markets, including foreign exchange, real estate, equities, derivatives, and commodities. How TradFi works TradFi functions within a highly centralized framework. Despite the digital solutions in place, core financial assets like balance sheets, order books, and transactions, are all managed by centralized entities or intermediaries. Most transactions happen under the control of these intermediaries with users having little to no control over their funds and assets. There are limited peer-to-peer interactions, with most transactions being managed by intermediaries. As a result, users are often in a predicament where they need to trust these intermediaries with their assets and funds. Additionally, the rules are set forth by regulations, with intermediaries facilitating compliance. The banking sector's reliance on the fractional reserve system, allowing them to lend much more than their held deposits, exemplifies this rule-dictated operation. Under the TradFi paradigm, financial intermediaries act as bridges between investors and borrowers. They channel funds from areas of surplus to areas of deficit and, in doing so, create a system that impacts the entire economy. These institutions—banks, insurance companies, funds, etc.—determine the flow of credit through interest rates, using centralized systems to offer traditional services like loans, mortgages, and investments. Security within TradFi is upheld via regulatory bodies and governmental oversight, minimizing systemic risk while providing consumers with a sense of trust in the institution handling their financial transactions: this control also reinforces compliance with rules and standards, enhancing stability in the global economy. What is Centralized Finance (CeFi) Centralized Finance, or CeFi, emerged out of the need for interaction with cryptocurrencies. Satoshi Nakamoto's introduction of Bitcoin in 2009 as a decentralized money system, the first of its kind, revolutionized the financial ecosystem. Gradually, as Bitcoin and other altcoins gained traction, the need for a platform to exchange these digital assets led to the appearance of centralized exchanges (CeFI). CeFi leverages traditional finance theories while incorporating digital assets like cryptocurrencies. Such platforms operate similarly to banks, serving as intermediaries between investors and borrowers but allowing transactions using both fiat and digital currencies. Through these platforms, users can access a myriad of services, such as interest accounts, loans, and exchange currencies. These platforms provide an entry into the innovative world of cryptocurrency while maintaining the familiar comforts of traditional, centralized financial services. How CeFi works CeFi services function similarly to how traditional finance does—they're managed by centralized intermediaries like exchange platforms. CeFi essentially brings traditional finance's features to digital assets. Users need to place trust in crypto service providers and often end up relinquishing ownership of their crypto by holding the funds in hot wallets hosted by exchanges. CeFi acts as a bridge linking the older world of TradFi with the emerging crypto markets, under a regulated framework by incorporating digital assets into the customary financial structure. Institutions in CeFi issue loans, facilitate crypto trading and allow users to earn interest on their assets. However, the control still remains central. This means that unlike DeFi, user assets are not in their control, but in the custody of centralized platforms. This allows operations including crypto-to-fiat and/or crypto-to-crypto transactions, loan services, interest accounts, and staking, making CeFi an integral part of modern financial systems. CeFi, while simplifying processes such as crypto wallet management and key protection, takes in the role of a custodian, furthering the narrative of centralized control. What is Decentralized Finance (DeFi) Decentralized finance, known as DeFi, appeared with the promise of decentralization. While the first DeFi concepts were proposed around 2013, but it wasn't until 2020 that DeFi witnessed explosive growth. Adhering to the true principles of decentralization, DeFi positions power back into the hands of the user, emphasizing peer-to-peer collaboration. Booming in the year 2020, DeFi gained the attention of traditional finance entities, realizing the potential to eliminate intermediaries and transferring control from centralized entities to communities. Despite its infancy, DeFi holds significant promise as a major disruptive force in the financial world. DeFi marks a radical departure from its predecessors. It leverages blockchain's distributed ledger technology and cryptocurrencies like Ethereum, with smart contracts automating financial transactions without middlemen. Emerging as an alternative to CeFi, DeFi promotes a more open and non-custodial financial system. It offers services similar to those in TradFi and CeFi, like loans, interest accounts, and insurance, but without the need for intermediaries. The key attraction of DeFi lies in its decentralization—control lies with the user, not an institution. Figure 1: U.S. Decentralized Finance Market; Source: Grand View Research How DeFi works DeFi differs drastically from traditional financial systems in the sense that it's a system built entirely on blockchain, facilitating crypto-economic protocols. Devised for interoperability, DeFi is based on public blockchains, allowing global access. At its core, DeFi leverages cryptography, blockchain technology, and tokenomics to create an open and transparent financial system that is accessible to anyone with a smartphone and an internet connection. As a network of decentralized applications (DApps), DeFi aims to re-create and improve existing financial systems' functions, such as lending and borrowing, insurance, asset trading, and more. The DeFi ecosystem employs mechanisms unique to the world of finance, such as yield farming, liquidity mining, staking, and flash loans. It functions over Automated Market Makers (AMMs), lending protocols, yield farming, and DEXs—creating a comprehensive financial ecosystem without the need for intermediaries. Figure 2: Aave decentralized money markets secured by Chainlink; Source: Chainlink From an operational perspective, DeFi platforms function with less friction compared to traditional and centralized finance. By disintermediating financial transactions, it creates a permissionless ecosystem where anyone, regardless of geographical location or economic status, can access and participate in global finance. Algorithms govern DeFi ecosystems, and the smart contracts guaranteeing transactions' integrity are open-source, leading to a community-driven decision-making process. Users retain full custody of their assets and interact directly with the protocols. DeFi services span decentralized exchanges (DEXs), lending and borrowing platforms, yield farming, and more—all while offering users remain in absolute control of their assets. TradFi vs CeFi vs DeFi TradFi, CeFi, and DeFi each possess unique characteristics that distinguish them in their operation, risk levels, and yields. From a broad perspective, the main distinguishing factor among TradFi, CeFi, and DeFi is centralization and control. Each has its benefits and limitations; thus, a balance between them seems viable for a sustainable future. In TradFi and CeFi, transactions are controlled by intermediary entities, be it banks or private firms. CeFi acts as a bridge between traditional finance and decentralized finance, providing features to transact with digital assets while retaining the structure of TradFi. Conversely, DeFi eliminates the need for middlemen, relying on blockchain technology and smart contracts to facilitate transactions. TradFi, dictated by established financial institutions, offers security and a sense of familiarity but falls short of inclusivity and adaptability. On the other hand, CeFi tries to merge the best of both worlds, providing an amicable solution for those cautious yet intrigued by the brave new world of crypto. DeFi, while nascent, poses a radical shift by democratizing access to financial services and enabling self-custody of assets, forging a pathway for a truly decentralized economic system. It provides users with full control of their assets and transactions, catering to the ethos of blockchain and crypto about decentralization and user control. Figure 3: Centralized vs decentralized transactions; Source: Chainlink It leverages blockchain technology and smart contracts to ensure transparency and inclusivity. However, it also exposes users to risks synonymous with smart contracts and requires a certain level of technical knowledge to navigate. While TradFi and CeFi pose an issue with intermediary dependence, DeFi provides an advantage, allowing open and transparent transactions. Comparatively, TradFi is highly regulated, ensuring consumer protection but potentially hindering innovation and accessibility. CeFi provides some regulatory safety but has been criticized for lack of transparency. On the other hand, DeFi is considered the Wild West of finance, given its minimal regulation, making it ripe for innovative solutions but also for potential scams and rogue players. Figure 4: TradFi vs CeFi vs DeFi; Source: tastycrypto The Risks of DeFi and CeFi To paint a clearer picture, let's delve into some risks associated with DeFi and CeFi. Both DeFi and CeFi present unique risks alongside their benefits. For DeFi, challenges arise from its nascent nature. The most prominent risks include smart contract vulnerabilities, liquidation risks, and composability risks. Interoperability of different DeFi protocols might lead to a domino effect if one protocol fails. Furthermore, the high volatility and steep learning curve of using DeFi protocols can potentially lead to significant financial losses. Figure 5: Cryptocurrency stolen in hacks by victim platform type, 2016-2023; Source: Chainanalysis In contrast, CeFi, though appearing more secure, also comes with risks, albeit more traditional, like credit risk, regulatory risk, and operational risk (cyber threats and other security issues). Your assets are held in trust by a centralized authority susceptible to internal fraud, hacking, and regulatory issues. This form of custodianship requires a great deal of trust from the user as opposed to the self-custody model in DeFi. But as more people embrace blockchain technology, DeFi has the potential to deliver a truly global, open, and transparent financial system. Figure 6: Chainlink oracles connecting DeFi smart contracts; Source: Chainlink Solving global challenges with a DeFi and TradFi synergy Despite their differences, the fusion of DeFi and TradFi could offer significant benefits to address global financial challenges. Bridging the gap between these two systems could enable accessibility, affordability, and speed in financial transactions globally. In essence, we could see a fusion of the best of both systems, fostering a global financial ecosystem that is inclusive, equitable, and resilient. DeFi and TradFi can work together to tackle global financial hurdles. DeFi's global accessibility and democratized decision-making meet TradFi's regulated environment and reliability, promising a financial ecosystem that is inclusive, globally accessible, transparent yet secure, and efficient. Figure 7: DeFi powered by Chainlink ecosystem; Source: Chainlink Financial inclusion is a key area. Billions of people worldwide lack access to basic financial services. Here, DeFi could play a huge role in providing universal access to financial services, thus bridging the financial divide. However, DeFi is alone insufficient. TradFi, with its years of expertise in risk management, customer service, regulatory compliance, and more, can contribute significantly to this mission, thus establishing a synergy with DeFi. Transactions could be executed more seamlessly due to the blockchain, even reaching unbanked and underbanked populations, driving financial inclusion. Furthermore, DeFi can enhance TradFi by embedding transparency, offering higher returns to stakeholders, and reducing the overall cost of operations due to its decentralized nature. Regulatory challenges and solutions for DeFi and CeFi Regulating DeFi and CeFi is complex due to their global reach, anonymized user base, and fast-paced technical changes. Regulations need to be precisely tailored to protect consumers and ensure market integrity, without stifling innovation. Global cooperation between regulatory authorities can help create a uniform framework that caters to these different parameters. Operating in an avant-garde space where traditional regulatory frameworks often struggle to catch up, both DeFi and CeFi face significant challenges. DeFi, especially, with its decentralization and anonymity, presents a complex web for regulators to untangle. Emerging issues around market integrity, investor protection, and cybersecurity become increasingly critical in this new domain. However, solutions are burgeoning. Hybrid models that combine the compelling features of DeFi with the regulatory reassurances of CeFi are increasingly common. Cross-industry collaborations can develop regulatory technology solutions, while international harmonization and cooperation among regulators globally could support the balanced growth of this field. Rethinking crypto regulation for DeFi The surge and evolution of cryptocurrencies and DeFi has underscored the need to rethink our approach toward regulation. Current regulatory frameworks are primarily designed for centralized systems and have trouble grappling with the decentralized nature of crypto. Considering the unique nature of DeFi, and its potential, the need for a touch of regulation is inevitable. Rather than imposing traditional financial regulations, regulators must rethink their approach. This includes creating new models that promote transparency, security, and market integrity, while also encouraging innovation. There has to be a shift from regulating institutions to regulating activities and behaviors. As we move towards a more decentralized financial infrastructure, regulators need to focus on decentralization's potential risks and benefits. This includes developing mechanisms for transparency, protecting users from fraud, enforcing security measures, and ensuring tax compliance. Striking a balance in DeFi regulation While the regulatory challenge posed by the rise of cryptocurrencies and DeFi is considerable, it is crucial to strike a balance. On one hand, an overly lax regulatory environment can foster illicit activities and undermine global efforts to maintain financial stability. On the other hand, excessively strict regulation can stifle innovation and the potential economic benefits that these innovative technologies can deliver. This balance can potentially be achieved by applying existing financial regulations where appropriate and developing new regulations to address the unique challenges that crypto and DeFi present. Moreover, it further underscores the need for regulatory bodies worldwide to work together in understanding and managing this rapidly developing space. It will be a balancing act to adequately regulate without hindering the very benefits that crypto and DeFi promise, such as the democratization of finance and financial inclusion. This will require open dialogue between regulators, technologists, academics, and the industry to meet these challenges. Bringing it all together Through this exploration, we traced the diverse terrains of TradFi, CeFi, and DeFi, each embodying unique financial philosophies and methodologies. As we stand at the crossroads of a rapidly evolving monetary environment, we're challenged to adapt. We're witnessing history in the making—a shift from familiar centralized frameworks to a world of unexplored decentralized possibilities. As these currently isolated systems blend, we anticipate a future that borrows from the tried-and-true reliability of established systems and exciting prospects of emerging technologies. The future of finance beckons—a future that's increasingly inclusive, transparent, and decentralized. Are we ready for the paradigm shift? Power-boost your project on Chainstack #### Trading bot update: Full Mayhem Mode support for Pump.fun We're excited to announce a critical update to our Pump.fun trading bot on Solana that ensures uninterrupted operation as the platform rolls out its new Mayhem Mode infrastructure. While other bots may struggle or stop working entirely, our solution is already future-proofed and ready. What's Changing on Pump.fun? Pump.fun has introduced a new token creation instruction called create_v2, which uses the Token2022 program instead of the legacy Metaplex standard. This represents a fundamental shift in how tokens are launched on the platform, particularly with the introduction of Mayhem Mode: an experimental feature where an autonomous AI trading agent actively places trades on eligible coins for their first 24 hours of existence. The Technical Challenge The platform now supports two methods of token creation: Legacy create instruction: Uses the traditional token program and Metaplex metadata New create_v2 instruction: Leverages Token2022 program with native metadata support While the original create instruction remains active, Pump.fun has indicated it will be deprecated at a later time. This creates a transitional period where both instruction types coexist on the platform. Why This Matters for Your Bot Bots that only recognize the legacy create instruction will miss tokens launched with create_v2—and eventually, they'll stop working altogether when Pump.fun deprecates the old method. During this transition, you could be missing out on: New tokens launched with Mayhem Mode enabled All future token launches once the migration is complete Critical trading opportunities in the first seconds of a token's life The risk is real: Once Pump.fun fully transitions to create_v2 and disables the legacy instruction, outdated bots will simply stop detecting new tokens. Our Solution: Dual-Instruction Detection Our updated bot now features comprehensive support for both token creation methods, ensuring seamless operation regardless of which instruction is used. Check Pump.fun bot GitHub Key Features ✓ Dual Instruction SupportThe bot actively monitors both create and create_v2 instructions, detecting tokens launched through either method without any gaps in coverage. ✓ Mayhem Mode CompatibilityFull support for Mayhem Mode tokens, including proper handling of the modified fee recipient requirements and Token2022 program interactions. ✓ Automatic Token Program DetectionIntelligently identifies whether a token uses the legacy token program or Token2022, adjusting its transaction construction accordingly. ✓ Future-Proof ArchitectureWhen Pump.fun eventually deprecates the create instruction, your bot will continue operating without requiring any manual intervention or additional updates. Technical Implementation Our bot handles several critical distinctions between the two instruction types: Token Program Recognition Legacy tokens: Standard SPL Token Program New tokens: Token2022 Program with extended functionality Account Derivation The associated bonding curve account is now owned by the Token2022 program rather than the legacy token program, and user token accounts must also be derived accordingly. Mayhem Mode Fee Recipients For tokens launched with Mayhem Mode enabled, the bot correctly identifies and uses the appropriate fee recipient addresses, ensuring transactions don't fail due to incorrect account configurations. What This Means for You Uninterrupted Service: Your bot continues detecting and trading new tokens throughout the entire transition period and beyond. Competitive Advantage: While other traders troubleshoot broken bots, you're already positioned to capture opportunities from both legacy and new token launches. Zero Downtime: No action required on your end—the update handles everything automatically. Mayhem Mode Ready: When Mayhem Mode goes live for your trading strategy, your bot is already equipped to handle the increased volatility and unique trading patterns of these tokens. The Bigger Picture: Mayhem Mode Mayhem Mode aims to increase the number of good projects in the pump.fun ecosystem by making coin projects more appealing to engage in at early stages where they typically might fail. By understanding this feature, you can better position your trading strategies: Mayhem Mode tokens launch with 2 billion tokens instead of the standard 1 billion The AI agent introduces price volatility through randomized buying and selling The mode operates only during the first 24 hours after token creation After the period ends, unsold agent-held tokens are burned Competitive Landscape As this update rolls out across the ecosystem, bot operators face a critical decision point. Those who adapt quickly will maintain their edge, while those who delay risk: Missing new token launches entirely Losing market share to better-prepared competitors Experiencing unexpected downtime when the legacy instruction is finally disabled Scrambling to implement emergency fixes under pressure Our proactive approach means you're already ahead of this curve. Frequently Asked Questions Q: Do I need to do anything to enable this update?A: No. The update is automatic and requires no configuration changes on your end. Q: Will this affect my bot's performance?A: Not negatively. The bot maintains the same speed and efficiency while adding new detection capabilities. Q: What happens to tokens created with the old instruction?A: The bot continues to detect and trade them normally. Full backward compatibility is maintained. Q: When will Pump.fun disable the legacy instruction?A: The timeline hasn't been officially announced, but our bot is ready regardless of when it happens. Q: Does this support Mayhem Mode tokens specifically?A: Yes. The bot properly handles all Mayhem Mode-specific requirements, including modified fee structures and Token2022 interactions. Looking Ahead This update represents our commitment to staying ahead of platform changes and ensuring your trading operations remain uninterrupted. As Pump.fun continues to evolve with features like Mayhem Mode and the broader Token2022 migration, you can trust that our bot will adapt accordingly. The transition to create_v2 is just the beginning. Token2022 opens the door for new features like transfer fees, confidential transfers, and permanent delegates—capabilities that may reshape how trading bots interact with the platform. We're already monitoring these developments to ensure your bot remains at the cutting edge. 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. #### Trava.Finance on Chainstack: Optimizing data processing with access to multiple blockchain networks Trava.Finance is a cross-chain lending protocol that offers unique functions, including pool creation, credit score evaluation, NFTs-collateralized, and data analysis built on a semantic knowledge graph. What does Trava.Finance do? Trava.Finance’s cross-chain lending marketplace is where users can create and manage their own lending pools. This multiple-pool model allows lending pool owners and their members to flexibly adapt their investment strategies to the volatility of the crypto market and earn greater returns. There are currently over 361 lending pool owners with a TVL of over $22 million. Initially deployed on the BNB Smart Chain, the platform allowed users to start lending immediately with BNB Smart Chain tokens, and subsequently released support for cross-chain lending with various tokens on Ethereum and other blockchain networks. The lending marketplace model has helped promote the growth of cryptocurrency liquidity and accelerate the growth of the entire DeFi ecosystem. Trava.Finance’s lending marketplace is built upon a semantic cross-chain knowledge graph; a distributed ledger that holds the data collected from multiple blockchain networks in the form of entities and their inter-connections. Starting with pool creation, Trava.Finance offers a flexible mechanism in which users can create and manage their own lending pools to start the lending business. Pool owners are supported with recommended optimal parameters that are generated to reduce lending risks based on statistical data analysis on the cross-chain knowledge graph and other data sources. The data analysis identifies any unusual transactions and gives greater insights to help users maintain their liquidity pool. Trava.Finance developed a pioneering solution for credit score evaluation within blockchain lending that uses a cross-chain knowledge graph to evaluate credit scores for users and their digital assets. In addition, Trava.Finance aims to increase the overall market liquidity of special assets such as NFT, stock tokens, or smart contracts, allowing users to use all these asset types as collaterals. Utilizing a cross-chain identification protocol that identifies all wallet addresses of the same user on different networks, users can use a combination of all types of cryptocurrencies and crypto assets they have as collateral for a larger loan, in a single transaction. How did Trava.Finance come across Chainstack? The team at Trava.Finance started with building and managing their own blockchain node infrastructure and eventually faced many technical problems to effectively operate and maintain the blockchain nodes. Trava.Finance tested many different node providers in search for a better solution and access to Binance Smart Chain. Looking to optimize and analyze transactions on the public blockchain networks, such as Ethereum, Polygon and BNB Smart Chain, Trava.Finance eventually found Chainstack’s managed blockchain platform to be the perfect solution. Chainstack out-performed and was the perfect choice for better API stability across different blockchain networks with best-in-class priority support. How does the Chainstack offer match Trava.Finance needs? Chainstack supports Trava.Finance’s blockchain data analysis by providing stable and reliable blockchain nodes that can easily handle the requirements for a huge number of requests in querying both the transaction data and the state data. Chainstack provides accessibility to the old and the newest state of a node, allowing for queries to be performed on both full nodes and archive nodes on Ethereum, Polygon and BNB Smart Chain. The ability to make an unlimited number of requests to nodes is a crucial advantage for Trava.Finance. Outcome Chainstack fulfilled all the requirements by helping the entire lending marketplace system to run smoothly, efficiently, and steadily. This allowed Trava.Finance to focus on optimizing data processing and building new, innovative products for the end users. Supporting over 2,656 unique holders and addresses, Chainstack’s stable network infrastructure has helped Trava.Finance to accelerate growth, processing over 44,513 transactions on the platform. The collaborative partnership with Chainstack brought ease in deploying and maintaining blockchain nodes, coupled with timely support from a knowledgeable and reliable team at Chainstack. With an ever-changing DeFi and web3 landscape, Trava.Finance can continuously depend on Chainstack to deliver new protocol support and services for cross-chain use. What does Trava.Finance like about Chainstack? Relying on an innovative model of multiple lending pools created by users, Trava.Finance is the world's first decentralized lending marketplace. We perform blockchain data analysis to optimize pool parameters and calculate credit scores for users to reduce risks. To this end, we need to listen to and analyze a huge amount of data from different blockchain networks at the same time. This requires a large number of stable nodes on multiple chains, which can be fulfilled with ease by using Chainstack services. The cooperation between Trava.Finance and Chainstack is a fruitful collaboration. Our services are able to run with the highest performance and stability so that we can provide the best services for our customers. Chainstack can also benefit from the partnership with Trava.Finance as they can approach the large number of our users in the DeFi domain. Dr. Minh Nguyen, CEO & Co-founder, Trava.Finance What does Chainstack like about Trava.Finance? Trava.Finance was created with the goal of promoting the DeFi ecosystem by improving liquidity markets and did so by pioneering some of the best products within the lending space. This project has shown immense potential for new, interoperable, and innovative products that is cross-chain, multi-protocol. Projects like Trava.Finance accelerate Web3 in its entirety, not only promoting liquidity in DeFi markets, but also building innovative products that help bring Web3 and DeFi projects closer together. Chainstack is perfect for builders and developers to run multiple protocol networks, access archive data and let you focus on building innovative solutions catered to a wider group of users on multiple networks. Eugene Aseev CTO & Founder, Chainstack Cross-chain projects have accelerated the need for better support so that developers and builders can focus on solutions that could operate on different network protocols. Chainstack was built to support this with an all-in-one platform to easily access various blockchain networks, deploy and manage blockchain nodes. Power-boost your project on Chainstack #### TRON RPC for USDT-TRC20: infrastructure guide for stablecoin operations The powerhouse duo: TRON and USDT-TRC20 TRON hosts over 45% of all circulating USDT, roughly $89 billion, processed across more than 13 million daily transactions. Blocks confirm every 3 seconds via 27 elected Super Representatives, the network sustains 2,000+ TPS, and the bandwidth-and-energy fee model keeps transfer costs at fractions of a cent. This combination is why payment processors and exchanges often prefer TRON for stablecoin infrastructure over traditional EVM chains. Source: April Stablecoin TRON MCap by DefiLlama That speed also creates pressure on every layer of the stack, particularly the RPC layer. A 3-second block time means state changes fast, and a node that falls behind starts serving stale data. In a high-velocity settlement environment, stale reads translate directly into missed or misreported transactions. Getting the infrastructure right starts with understanding what TRON demands from the RPC interface sitting between your application and the chain. Understanding the TRON RPC interface That stale data risk starts at the API layer. TRON exposes three interfaces and picking the wrong one for a given operation causes real problems in production. /wallet talks to the Full Node and returns the latest chain state, so it's what you use for transaction submission and real-time reads. /walletsolidity only returns confirmed, finalized data, making it the right choice for payment verification and balance checks. The most common cause of "missing transaction" errors is using /wallet where /walletsolidity is needed. A transaction that's been broadcast but not yet finalized shows up in one and not the other. /jsonrpc is a limited EVM-compatible interface for teams bringing Ethereum tooling to TRON, though write operations aren't supported through it. Protocol choice is mostly a throughput question. HTTP REST is fine for simple dApp queries or one-off tasks. For high-frequency indexing and exchange backends, gRPC with Protocol Buffers is worth the setup: it cuts serialization overhead by 30-50% compared to JSON and keeps connections persistent via HTTP/2, which matters when you're making thousands of calls per second. Getting the interface right keeps your data fresh. Getting the resource model right keeps your transactions from failing silently. 📖 For a full walkthrough of all four TRON API interfaces including gRPC, see the TRON tooling guide. Managing bandwidth and energy TRON's resource model replaces conventional gas with two separate resources: bandwidth, consumed by every transaction, and energy, consumed by smart contract execution. Staking TRX to acquire both enables near-zero fee USDT transfers, but at high volumes the economics require careful modeling. The three options are staking TRX directly, renting energy from marketplace providers, or paying per transaction in TRX, and most production operations end up blending all three depending on load patterns. Chainstack's guide on mastering energy and bandwidth with Python covers programmatic resource management for production workloads. Before broadcasting any contract call, wallet/estimateenergy lets you pre-flight the energy cost and avoid submitting transactions that will fail mid-execution. That estimate should never go into fee_limit as-is though. Network congestion can push actual energy consumption above the pre-flight figure, so building in a 10% buffer is the difference between a transaction that completes and one that runs out of energy on-chain having already spent the resources. With the resource model handled, the next layer is making sure each individual operation against the USDT contract is called correctly and verified fully. Core RPC methods for USDT-TRC20 operations For reading USDT state, triggerConstantContract handles balanceOf and decimals calls as the local database reads against the node. They never propagate to the p2p network, consume no bandwidth or energy, and are safe to poll aggressively for balance displays or pre-transfer checks. Here's how to check a USDT balance using TronWeb.js with your Chainstack endpoint: const { TronWeb } = require('tronweb'); const tronWeb = new TronWeb({ fullHost: 'YOUR_CHAINSTACK_ENDPOINT' }); const USDT_CONTRACT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t'; const WALLET_ADDRESS = 'YOUR_WALLET_ADDRESS'; async function getUSDTBalance() { try { const contract = await tronWeb.contract().at(USDT_CONTRACT); const balance = await contract.balanceOf(WALLET_ADDRESS).call(); console.log(`USDT Balance: ${balance / 1e6}`); // USDT has 6 decimals } catch (error) { console.error('Error getting balance:', error); } } getUSDTBalance(); Writes follow a strict sequence: Build the transaction with triggerSmartContract Sign it locally Broadcast with broadcastTransaction Verify finality by checking contract_ret on /walletsolidity A "result": true from broadcast means one thing, that the transaction hit the mempool, nothing more. Checking contract_ret is what tells you whether execution actually succeeded, since a transaction can land on-chain and still fail at the contract level due to insufficient energy. Here's how to send a USDT transfer: const { TronWeb } = require('tronweb'); const tronWeb = new TronWeb({ fullHost: 'YOUR_CHAINSTACK_ENDPOINT', privateKey: 'YOUR_PRIVATE_KEY' }); const USDT_CONTRACT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t'; const RECIPIENT = 'RECIPIENT_WALLET_ADDRESS'; const AMOUNT = 10 * 1e6; // 10 USDT (6 decimals) async function sendUSDT() { try { const contract = await tronWeb.contract().at(USDT_CONTRACT); const txid = await contract.transfer(RECIPIENT, AMOUNT).send({ feeLimit: 30_000_000 }); console.log('Transaction ID:', txid); } catch (error) { console.error('Transfer error:', error); } } sendUSDT(); Note: Replace YOUR_CHAINSTACK_ENDPOINT with your TRON node endpoint. For full code examples including gRPC and Python, see the TRON tooling docs. TRON has no native subscription or event push model, so monitoring incoming USDT transfers requires a polling architecture. The reliable approach is calling getblockbynum sequentially and filtering internal_transactions for the USDT contract address (TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) and method ID a9059cbb, the transfer function selector. That's all you need for a complete, durable record of every USDT movement.  Choosing a reliable TRON RPC provider As USDT-TRC20 volume grows, the architecture of your RPC layer needs to match the workload profile. For user-facing applications, geo-balanced nodes that route across US, EU, and APAC regions keep read latency low regardless of where your users are. For high-throughput payment settlement and exchange backends in particular, dedicated single-tenant compute matters more. On shared infrastructure, a traffic spike from another tenant can degrade your latency precisely when market volatility is driving your own volume up. Dedicated nodes eliminate that risk entirely. The polling architecture described earlier also has a direct cost implication. Since TRON has no native event subscription model, production monitoring requires continuous calls to getblockbynum, and that request volume adds up fast. Providers with uncapped request tiers, Chainstack's Unlimited plan being one option, let your polling loop run at whatever frequency your infrastructure demands without rate-limit failures or unexpected overages during high-activity periods. Security rounds out the picture. Open RPC endpoints are actively scanned by drainer scripts, so JWT or basic auth, IP whitelisting, and SOC 2 Type II compliant infrastructure aren't optional hardening steps for integrations handling live USDT flows. They are the starting point. 📖 For a detailed comparison of TRON RPC providers — including pricing, gRPC support, and SOC 2 compliance — see our Best TRON RPC Providers in 2026 guide. USDT transfer comparison: TRON vs Ethereum vs BSC TRON (TRC-20)Ethereum (ERC-20)BSC (BEP-20)Avg transfer fee<$0.50$2–10+<$0.10Confirmation time~3 sec~12 sec~3 secUSDT supply hosted~$86B (~46%)~$75B (~44%)~$5B (~3%)Daily transactions~10.7M~1.2M~4.5MFee modelBandwidth + EnergyGas (Gwei)Gas (Gwei)RPC interfaceHTTP + gRPCJSON-RPCJSON-RPC Conclusion  Every recommendation in this piece traces back to the same underlying risk. A TRON infrastructure that falls behind, miscounts energy, or misreads finality doesn't just degrade. It loses money. Getting it right means treating node type selection, energy pre-estimation, finality verification, block polling, and endpoint security not as configuration details but as operational commitments. As USDT-TRC20 cements itself as the settlement layer for emerging market currencies, the RPC endpoint is no longer just an API. It is a financial gateway, and the gap between reliable infrastructure and a liability is largely operational. Deploy TRON RPC node → FAQ What is the USDT contract address on TRON? The TRC-20 USDT contract address is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. Use this address when calling triggerConstantContract for balance checks or triggerSmartContract for transfers. The transfer function selector is a9059cbb. How much does a USDT TRC-20 transfer cost? Fractions of a cent when the sender has staked TRX for energy and bandwidth. Without staked resources, transfers cost roughly $0.30–$1.00 in TRX burned for energy. Pre-flight every transaction with wallet/estimateenergy and add a 10% buffer to fee_limit. What is the difference between /wallet and /walletsolidity? /wallet returns the latest chain state including unconfirmed transactions — use it for broadcasting and real-time reads. /walletsolidity returns only finalized, confirmed data — use it for payment verification and balance checks. The most common "missing transaction" error comes from reading /wallet when you should be checking /walletsolidity. How do I monitor incoming USDT transfers on TRON? TRON has no native event subscription model. Poll getblockbynum sequentially and filter internal_transactions for the USDT contract address (TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) and method ID a9059cbb. This gives you a complete record of every USDT movement. USDT TRC-20 vs ERC-20: which is cheaper? TRC-20 is significantly cheaper. TRON USDT transfers cost under $0.50 with ~3 second confirmation. Ethereum ERC-20 USDT transfers cost $2–10+ depending on gas and take ~12 seconds. TRON hosts ~$86B in USDT (~46% of supply) vs Ethereum's ~$75B (~44%), and processes roughly 10x more daily USDT transactions. Related reading Best TRON RPC Providers in 2026 — pricing, gRPC support, and enterprise compliance compared How to get a TRON RPC node — public endpoint URLs, setup guide, and tooling TRON: Mastering Energy & Bandwidth with Python — programmatic resource management Stablecoins in cross-border settlements — USDT and USDC adoption trends TRON tooling docs — full code examples for TronWeb.js, gRPC, web3.py, and Hardhat #### Trust raises ROI by up to 400% with custom Chainstack gateway Streamlining high-volume transaction handling for seamless user experiences. Chainstack's custom gateway and Global Nodes have made a stellar impact on our operational efficiency, allowing us to push our ROI higher by roughly 400%. Together, we're driving remarkable advances in decentralized technology. The Trust team As we reflect on our journey at Chainstack, we're constantly reminded of the partnerships that have significantly shaped our path and catalyzed our growth. One such collaboration that stands out is our work with Trust. Trust wallet is a leader in the world of crypto transactions, boasting a user base tens of millions strong and supporting over several million assets across all major, and some not-so major, protocols. Our shared vision and mutual commitment to redefining the crypto experience presented us with a unique challenge—to manage high-volume transactions without compromising the precision, reliability, and security Trust users have come to expect. To do this, we set out to design a custom gateway that would successfully handle the transaction load and also guarantee clear communication for Trust’s users. By focusing on both technicality and user experience, we transformed Trust wallet operations, setting a milestone in the way the wallet interacts with decentralized technology. Let’s delve into this journey and find out how Chainstack was able to empower Trust in achieving its goals. Why Trust chose Chainstack as its infrastructure partner In the vast landscape of crypto services, Trust had already cemented its reputation. The challenge for Chainstack was not just to be another service provider but to distinctly stand out among the myriad of infrastructure solutions Trust Wallet had previously explored. Our promise of consolidating service providers, enhancing infrastructure robustness, and delivering cost-effective solutions had initially piqued Trust wallet's interest, especially given the positive feedback they had gathered from other Web3 developers in the community. Recognizing the unique challenges Trust faced, particularly in managing a multitude of providers to cover an extensive list of chains, we saw an opportunity to deliver unparalleled value. Our extensive support for over 25 protocols, combined with our globally-distributed geo-load-balanced Global Nodes and scalable solutions, set us apart. But what resonated the most with Trust’s developer-centric vision was our transparent and predictable pricing model. Our commitment to simplifying the complexities of blockchain infrastructure, coupled with our transparent pricing, made Chainstack a match made in Heaven for Trust Wallet. Facilitating interactions with a custom Chainstack gateway One of the pivotal moments in our partnership was when Trust presented us with a unique challenge. They needed a solution that would not only handle their high-volume crypto transactions but also ensure clear communication for their users. Rising to the occasion, we designed a dedicated gateway that not only met the technical requirements but also enhanced the user experience. Our solution delivers intuitive error messages when request rates are exceeded, guiding users on when to retry, ensuring seamless interactions even during peak times. Through our partnership with Trust, the results have been nothing short of impactful. Trust has realized substantial cost savings, achieving an impressive 80% reduction compared to an on-premise setup and a 44% to 57% savings against other service providers. With their consistent consumption of an average 2.5B RUs monthly on the Chainstack platform, the satisfaction Trust Wallet has expressed is a clear indicator of the mutual success we've achieved together. Trust on Chainstack in numbers Trust truly makes the most of Chainstack’s capabilities, presently running 34 Global Nodes to bolster their comprehensive wallet’s offerings. Our multifaceted protocol support enabled Trust Wallet to seamlessly manage operations across an extensive range of 18 chains, including Aptos, Arbitrum, Aurora, Avalanche, Bitcoin, BNB Smart Chain, Ethereum, Fantom, Gnosis, NEAR, Optimism, Polygon, Polygon zkEVM, Solana, Starknet, Tezos, and zkSync Era. Trust’s extensive use of our platform at Chainstack is a testament to the trust they place in our services. Our full nodes impressively managed 12.82B requests, while our archive nodes adeptly handled a significant 4.11B. At Chainstack, we pride ourselves on transparency, and these statistics only bolster Trust Wallet's confidence in our capabilities. Chainstack's global reach with Trust is evident in our request delivery across various regions. Leading the way is Ashburn with 7.41B requests, followed by the EU at 2.55B, Southeast Asia with 2.33B, Amsterdam at 1.04B, London with 0.39B, and Dallas managing 0.24B. We stand as a comprehensive solution catering to Trust wallet's worldwide needs. In terms of specific protocol usage, Ethereum took the lead with a massive 10.48B requests. This was followed by Arbitrum at 2.25B, Solana with 2.05B, zkSync Era at 0.67B, BNB Smart Chain with 0.58B, Polygon zkEVM at 0.24B, and Gnosis protocol registering 0.15B. Trust’s diverse protocol interactions highlight their comprehensive approach to blockchain technologies. These impressive figures paint a vivid picture of the foundational role Chainstack plays in Trust’s ongoing journey. From scalability to unparalleled support, Chainstack anchors Trust wallet's operations, underpinning their objective of offering efficient and seamless services to their extensive user base. We view these statistics as milestones, symbolizing our unwavering commitment and dedication to propelling Trust’s continued growth and success in the dynamic world of cryptocurrencies. What is Trust? Trust wallet is a powerful and secure platform for conducting crypto transactions, boasting a user base exceeding 60M. From managing multi-chain support and executing crypto transactions to staking, accommodating NFTs, and even fostering a thriving environment for developers, Trust is indeed a virtuoso in the crypto space. The platform is designed with scalability and performance at its core, crafted to handle high volumes of transactions and users without faltering. This reliability is backed by top-notch security measures, safeguarding users with advanced encryption and comprehensive security protocols. Taking a deeper look, Trust supports over 4.5M assets and 70 chains, exemplifying its impressive compatibility and interoperability. The platform’s extensive ability to accommodate a wide range of decentralized technologies is no small feat. It speaks not only to Trust Wallet's flexible architecture but also to its dedication to staying one step ahead in the rapidly evolving world of cryptocurrencies. Figure 1: Some of Trust’s supported assets; Source: Trust What makes Trust special? While staking can typically be a complicated process requiring technical expertise, Trust wallet has revolutionized the experience. They've transformed this intricate operation into a user-centric approach, enabling everyday users to participate effortlessly. Trust Wallet's overarching mission is to demystify the blockchain realm, making it more approachable for the average individual. Their staking feature stands as a testament to this commitment. In the ever-evolving crypto landscape, Trust remains agile, as evidenced by their robust support for NFTs. Recognizing the uniqueness of each NFT and the intricate smart contract requirements, especially for ERC721 and ERC1155 tokens, Trust adeptly manages these complexities. This proficiency empowers users to navigate the burgeoning world of digital collectibles with unwavering confidence. Further enhancing the user experience, Trust wallet's integrated DApp browser offers a seamless gateway to decentralized technology. It simplifies interactions with smart contracts across a multitude of chains, allowing users to immerse themselves in the crypto ecosystem without the usual technical barriers. Figure 2: Trust wallet security features; Source: Trust Complementing this is Trust wallet's browser extension, which brings the platform's full capabilities to web browsers. It supports a diverse range of chains and facilitates secure interactions with various blockchains. This extension underscores Trust’s commitment to user-centric design, extending its reach beyond just the mobile application and offering unparalleled flexibility. Bringing it all together Viewing this journey retrospectively, our collaboration with Trust has been both successful and rewarding. At Chainstack, we helped Trust wallet tackle their challenges head-on. Through our consolidated services and robust support for a plethora of blockchains and protocols, they could considerably cut down on resource and time requirements. Our journey together has been a testament to our shared values, commitment, and dedication to rendering superior crypto services to millions of users worldwide. Trust’s extended commitment and positive feedback are evidence of the trust they placed in Chainstack's platform, services, and capabilities. The surge in usage statistics and broadened reach underline the efficacy and scalability we brought to their operations. Trust’s transition into consolidating their services onto Chainstack has led to substantial improvements in their operations' efficiency and efficacy. By offering a clear and forecastable pricing structure, we ensured they could budget effectively and stay on top of their expenses. This led to a major 80% cost-reduction against running an on-premise setup and a significant 44% to 57%, when compared with other service providers. And overall, when it came to ROI, this meant a staggering uplift of 400% for Trust wallet. At Chainstack, we aim to personalize our services to the unique needs of each client. With Trust Wallet, we not only delivered on their needs but also, through cooperation and shared experience, set a new standard for their services. Being a part of Trust wallet's journey has been an honor for us, witnessing their continued growth and having the opportunity to be a part of it is indeed rewarding. Trust and Chainstack, together, we make a better crypto world for millions. Power-boost your project on Chainstack #### Trust yourself—final part of the trust trilogy By Laurent Dedenis In part 2 of the Trust Trilogy, I ended with the promise of larger ecosystems and markets made possible through a simple mind-shift, where collaboration is the norm and the blockchain is the default trusted execution environment. What we didn’t touch upon were the numerous path-breaking blockchain projects that progressive companies have embarked on all over the world. So here they are, my selection of interesting projects that clearly demonstrates that the blockchain has arrived and its adoption, growing. This time, though, blockchain’s role in industry re-defining projects is minus the hype. Instead, these projects carry the kind of substance typical of fundamental and backbone technologies such as HTTP, TCP/IP, public key encryption, and the cloud, what I call the silent workhorses of our digital world. Let’s get started. The next step in the evolution of blockchains is the formation of industry networks. These create value by developing and operating shared industry infrastructures as well as shared processes and applications to be used by all its industry members. Source Smart cities. Key benefit: Efficiency The European Union has permitted the +CityxChange consortium and IOTA, a distributed ledger technology that uses the directed acyclic graph, to embark on realistic smart city projects in Limerick, Ireland, and Trondheim. These projects will then be replicated in Romania, Spain, Czech Republic, Bulgaria, and Estonia. Total funding as of publishing this article: EUR 30mn. The projects will be around the following themes: enabling a common energy market, creating connected communities, and recommendations for new policy interventions, market regulations, and business models. Best of all, this is not a water-tight public experiment. The seven cities are required to develop and test their solutions together with 11 large enterprises, 9 SMEs, 3 non-for-profit organizations, and 2 universities that span the entire value chain. A similar scene is expected to unfold in Singapore, a country that has already received recognition for its smart city initiatives and for its blockchain-friendly environment. A key aspect of smart cities is the widespread use of technology to cut down on red-tape and increase accessibility to various services. Any such initiative would rely on secure sharing of citizen data across a large number of government agencies, and, when permitted, with private players. The next phase of Singapore’s smart city initiatives has identified five areas as strategic national projects. And my hunch is that every one of those will possibly rely on a blockchain for secure sharing of data. Authenticity tracking. Key benefit: Assurance Authenticity tracking might well be the killer app of blockchains. In this case, the blockchain will be perfectly hidden from customers. So well hidden that while they won’t have to bother with hashes and consensus, they can rest assured that the Dior or Louis Vuitton in their possession is, beyond doubt, genuine. “So if you are a customer of a luxury brand, you are not going to see AURA; you are going to see the Louis Vuitton app or the app of another luxury brand.” About AURA-the blockchain powering LVMH’s authenticity tracking app. Source Sounds like a first-world problem? Not really, considering that the personal luxury goods market is a EUR260 billion industry with manufacturing bases and employees world over. Not surprisingly, moreover, the market for counterfeit luxury goods is huge, possibly larger. The point here is not to discuss the raison d'être of these counterfeit markets. What’s important is that a legitimate industry can fall prey to customer distrust. When unwitting customers trust a brand and end up with an inferior product, the chain of distrust can impact everything from new to second-hand sales. LVMH has recognized the power of blockchain to address this problem and, at the time of this article, is preparing to launch its authenticity-tracking solution soon. While the roll-out will be staggered, with almost 60 brands and $53 billion in revenues under its umbrella, there’s no denying there’s a lot of stake. What’s even better is that LVMH plans to donate its code to a non-profit third-party that even competitors can be part of. And with blockchain consensus algorithms and cryptography ensuring data privacy, true coopetition can finally start weaving its magic. Cross-border payments. Key benefit: Lower costs Cross-border payments are somewhat like multi-stopover flights. They take a long time, add up in terms of hidden expenses, and are not the first choice. Moreover, it was unavoidable. Until now. The reason for various inefficiencies is that this system still relies on the correspondent banking network, which is subject to counterparty risk, inefficient liquidity management, and cumbersome reconciliation. But blockchain is already changing that. AJIB, Jordan’s leading investment and commercial bank, has become one of the Middle East’s Blockchain success stories after a successful near instantaneous fund transfer between its headquarters in Amman, Jordan and its subsidiary in Cyprus. Compare that to a pre-blockchain scenario where such a fund transfer would take 2 to 3 days. On citing the far-reaching impact of real-time settlement of cross-border transactions, a joint report from IBM, OFX, and Stellar has this to say: “Consider the plight of migrant workers and expatriates who transfer money to their families back home. Currently, they are paying about seven percent per transaction and sometimes much more in emerging economies… The goal is to make these types of transactions frictionless, or at least reduce friction for the benefit of 1.7 billion adults who remain unbanked.” Source With the average cost for sending payments a whopping 7% of the total transaction, it is not surprising that IDC cites cross-border payment and settlements as one of the top three use cases of Blockchain in 2021. Deloitte has some compelling statistics too – stating that a blockchain-based payments system will be almost instant and result in a 40% to 80% reduction in costs. No wonder this space appears to be one the most promising with Stellar, Ripple, and WorldWire, among several others.  Education. Key benefit: Transparency, convenience Employers, educational institutions, government agencies - however advanced they might claim to be, there is no escaping the fact that they might demand to see your educational certificates as part of a verification process. And if they are dog-eared or lost, then getting a fresh one from the issuer (university, etc.) can be a painful or expensive process. As per Odem, a project addressing the credentials problem and more, major U.S. colleges can take up to four months to deliver a hardcopy diploma to a newly graduated student. Further, it can also take as many as six weeks and a US$150 fee to replace a diploma that’s been lost, stolen, or destroyed. Odem is using the Ethereum blockchain to give power back to the credential-holder, the student. Canada’s Southern Alberta Institute of Technology (SAIT) has already signed up to bring digital certificates and diplomas to over 4800 graduating students. The 2019 graduates will receive a cryptographic record of their certificate on the Ethereum blockchain along with their traditional parchment. Education is one of life’s most valuable assets... we believe that students should have control over their own records, and blockchain technology makes that possible. - Richard Maghul, CEO, Odem Source In Asia, GovTech from Singapore is doing something similar. Using the Ethereum blockchain, they developed OpenCerts, a platform for issuing and validating academic certificates that are tamper-resistant and permanent. OpenCerts has already gained significant traction amongst institutions in Singapore and is open for interest from institutions worldwide. Building and construction Construction is a complex, costly, and inefficient process that is typically over budget and over schedule. By its very nature, it is fragmented and requires extensive coordination among numerous stakeholders. It is often mismanaged and results in lost productivity and spiraling costs. Effective construction management boils down to supervision at a granular level. This is where blockchain technology can help. Blockchain can be applied throughout the lifecycle of an asset, from design to delivery to operation acting as a bridge among all stakeholders, allowing each party to track progress with the option to set up automatic payments for work completed. This technology can help to better manage construction progress as well as solve cash flow problems often experienced by companies. SiteSense is a step in that direction. “Applying blockchain technology to the built environment will change the way people interact and how the projects are procured and delivered.” Joan Zhong-Brisbois Project manager WSP USA Source There’s more that blockchain can contribute in this space. Building Information Modelling (BIM), for example, serves as a common vocabulary among architecture, engineering, and construction professionals. In the words of Blockchain and the Built Environment from Arup, the leading engineering services firm, “During the design phase, this (the blockchain) is useful for establishing ownership of models and tracking incremental improvements and changes. Once operational, a BIM blockchain-aided virtualization can be linked with its physical manifestation, with changes recorded internally... This will benefit stakeholders by reducing the opportunity for corruption, inefficiencies and contractual disputes.” Bimchain from France is already close to a market ready product that addresses the above. Among other things, its service offers the ability to create smart contracts that can ensure automated payments on stakeholders achieving their stated outcomes. Conclusion Several months ago, I started the Trust Trilogy as a series of articles exploring blockchain from inside out. I started from the concept of trust and collaboration, which is at the heart of this technology. I then proceeded to suggest blockchain-based collaboration for the enterprise as a next step. In this final piece, it’s been all about how blockchain is silently transforming every aspect of our lives. I am humbled by the fact that what I have presented is not even the tip of the iceberg. A blockchain-based transformation will not be overnight, nor will it be easy. As I have argued before, it requires a paradigm-shift in our thinking. But the numerous projects worldwide are ample evidence that it’s all happening. To me, this is most reassuring. What’s energizing is also the fact that as the CEO of Chainstack, I am seeing an increasing need for transparency, efficiency, collaboration, and cost reduction among stakeholders in enterprises and the government, and the blockchain is what all their research and insights is pointing them to. Here’s to a trust-filled 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. #### TrustPad on Chainstack: Fostering secure funding opportunities for web3 projects TrustPad is a decentralized platform that allows for the crowdfunding of projects. The platform is built to support a range of different blockchains, making sure that quality projects can get access to vital starting resources, regardless of protocol. As a result, TrustPad is quickly becoming the go-to platform for crowdfunding projects. What does TrustPad do? TrustPad provides a comprehensive ecosystem for project creators and investors to interact with one another and create a more efficient and trustworthy marketplace. It is unique in that it allows for the pledging of tokens to gain access to promising projects. This provides an added layer of security for early-stage investors, as they can be assured that they are getting priority access to potentially high-yield projects. The platform solves the problem of determining which projects are worth investing in by performing thorough due diligence on each applicant. In doing so, it protects investors from bad actors and unsuccessful launches, as the TrustPad community is always the priority. To date, TrustPad has successfully launched over 100 projects, raising over $20 million in the process. These projects have seen an average return on investment (ROI) of 286x, with some sales reaching more than 2000 participants. How did TrustPad come across Chainstack? TrustPad needed a reliable infrastructure provider that could support its resource-heavy operations on BNB Smart Chain. They had tried their best efforts to work with public BNB Smart Chain RPC nodes, which they proved to be too unstable for their use-case. With regular interruptions to TrustPad services and lag being a common occurrence, the TrustPad team needed a better alternative. So, they set out on a quest to find a robust infrastructure provider with the capability to support the demanding operations they were looking to perform. After trying out several alternatives for BNB Smart Chain node deployment, they discovered that Chainstack was the only option that could adhere to all their initial requirements and do that affordably at scale. How does the Chainstack offer match TrustPad needs? Facing an overwhelming flow of requests daily with regular interruption to their services and lag being common, TrustPad could only move forward with support from a dedicated managed setup. Such issues are critical for the effective performance of launchpad blockchain platforms, as they interfere with the fundraising process, leading to potential loss of funds for projects and users alike. So, primarily, TrustPad needed a reliable option for high volume and velocity read/write access to the network. This proved to be an interesting challenge for Chainstack, considering that every project listing on their platform generated a significant volume of requests to the blockchain, regardless of how well its operations are streamlined. This paved the way for TrustPad towards Chainstack’s robust and flexible BNB Smart Chain node service that was a perfect fit for their budget and demanding use-case. After giving the shared node offer a go for a few weeks, they discovered it offered both the stability and the capacity they were looking for to scale up their efforts. Outcome Following the promising trial results of the shared node service, TrustPad moved forward to leverage the extra performance the dedicated option provided. This was a welcome opportunity for their team, especially due to how accessible, transparent, and affordable the entire setup was for them. With Chainstack’s robust infrastructure to support their operations, TrustPad successfully began handling the 30M+ requests waiting to be processed daily. Our deployment offered the stability they were looking for while giving them the opportunity to monitor vital KPIs in real-time like usage, calls, and error reports. This meant that the special handlers they had built to requeue failing requests were no longer needed, allowing a smoother and more responsive experience when using the platform’s UI. Overall, TrustPad was able to reduce the number of dropped requests by a compelling margin between 300% and 500% and thus create a better environment for both projects and investors alike. What does TrustPad like about Chainstack? Our users are now able to consistently experience a smoothly running platform with fast loading times when using TrustPad. No more nasty surprises like funds going missing and transactions dragging out for unfathomable times. Thanks to Chainstack we have a pleasant and stable user experience – the most important thing for everyone involved by far." Double Trouble, TrustPad What does Chainstack like about TrustPad? By creating a transparent, secure, and accessible launchpad platform, TrustPad has become a valuable contributor to the development of the web3 landscape. Great ideas need equally impressive funding opportunities and TrustPad is there to welcome them with open arms. Eugene Aseev, CTO & Founder, Chainstack What is the most interesting engineering challenge in working together? One of the most significant challenges TrustPad encountered before coming to Chainstack was being able to handle the heavy load on infrastructure that is generated by the platform. Even a few failed requests could potentially cause interruptions in their service, from small-scale ones like UI errors to those of disastrous proportions, affecting the flow of purchases. These circumstances made the seamless management of calls a prime focus for Chainstack. That is why, when the TrustPad team was faced with an out-of-sync node that stopped replying, forcing them to revert to a backup shared node, we swiftly moved in to resolve the situation. With the issue out of the way, TrustPad could feel relieved, knowing their platform’s services were operating smoothly as intended once again. And most importantly, this time they did not have to face an ever-increasing mob of dissatisfied users and project representatives. Power-boost your project on Chainstack #### Unicrypt on Chainstack: Setting a stable foundation for incubating blockchain initiatives Unicrypt is a protocol for locking liquidity and incubating blockchain initiatives. The protocol is a vital player in helping projects launch tokens from the ground up in a secure manner by offering an opportunity to create flexible staking pools and farms according to the needs of the development teams. What does Unicrypt do? Since its launch in June 2020, Unicrypt has delivered an ever-growing palette of decentralized services. The main goal of the initiative is to create value within the Web3 space by developing a suite of disruptive, flexible, and audited technology that provides projects with a launchpad for rewarding their communities. Some of the main avenues Unicrypt is working on are liquidity locking for up-and-coming initiatives, token vesting for both project owners and early adopters, token minting, as well as ILO, farming, and staking opportunities. Altogether, this DeFi suite as a service provides a stable foundation for new projects to start their journey in the Web3 landscape. Up until now, this foundation has helped more than 14,000 projects successfully in their launch, generating over $500,000,000 in terms of TVL from over 1,200,000 users across their six services. In doing so, Unicrypt has become a vital player for on-chain analytics and security organizations, especially due to their exceptional security against liquidity theft and malicious actors. How did Unicrypt come across Chainstack? Powering such a large user base and doing so without significant interruptions brought forward a demanding set of requirements in terms of infrastructure. That is what kickstarted the Unicrypt search for a reliable partner that could successfully handle high volumes of traffic and do so with flexible pricing that is fit for their budget. Finding one was no easy task, however, as the protocol’s popularity directly translated into a major flow of requests in a short period of time, especially during ILO processes. Without a robust provider that could handle the load, Unicrypt would face regular interruptions to their service, creating much interference for users and damage to the project’s reputation. After conducting several trial runs with various alternatives, Unicrypt was still left facing sync issues and unsuitable billing plans. This eventually led them to discover Chainstack’s offering, which stood out from all the options in terms of flexible pricing and low downtime. How does Chainstack’s offer match Unicrypt needs? By comparing all the available options, Unicrypt found out that by working with Chainstack the team could reduce the cost of scaling multiple chains significantly. Unlike other alternatives, Chainstack offered a pricing structure based on the number of requests across multiple nodes, rather than per chain, or node, which was a perfect fit for their budget. Unicrypt’s team was happy to discover that Chainstack offered the utmost performance, even for less stable chains. This meant leaving block sync issues in the past when using websockets and the ability to launch additional chains swiftly, further speeding up the time-to-market for new Unicrypt products. Another welcome sight for Unicrypt was Chainstack’s consistent responsiveness that helped them resolve any challenges they faced quickly and effectively. With our help, their development team was able to deploy new nodes within days, significantly trimming down delivery times. Outcome With a reliable infrastructure provider supporting their efforts across the Web3 space, the Unicrypt team was able to resolve any performance bottlenecks they previously faced. Block synchronization was no longer an issue, even during the hectic processes that are a given with ILOs and community incentives, such as farming and staking. Seeing Chainstack nodes as the first to respond eliminated plenty of stress factors for Unicrypt, when it came to network stability. With consistent smooth performance that’s constantly improving their development team no longer needed to worry about desync issues and interruptions to their services. Not only that but thanks to the flexible and affordable pricing that comes with using our services, Unicrypt could also rest easy knowing they are getting their money’s worth for their budget. This helped their team significantly in supercharging their product offering and in giving them the ability to launch nodes quickly and effectively when the need arose. What does Unicrypt like about Chainstack? Chainstack has given us the tools to scale in some very flexible ways. We have been able to balance requests across multiple chains and spin up custom nodes in minutes without having to think about the bare metal. These features have allowed us to free up considerable time in development. Alex, Backend developer, Unicrypt What does Chainstack like about Unicrypt? Unicrypt provides a stable foundation for the launch of new blockchain initiatives and in doing so positions itself as a vital player in pushing the envelope for the entire landscape. We are happy to work together with the Unicrypt team in creating a better environment for the development and launch of new projects across Web3. Eugene Aseev, Founder & CTO, Chainstack What is the most interesting engineering challenge in working together? One of the major obstacles that the Unicrypt team faced in delivering an exceptional user experience was the node desynchronization that was a common occurrence on one of their supported chains. Considering the heavy loads that came with their use case, this created an interesting engineering challenge to resolve. Working side-by-side with our team, Unicrypt successfully managed to fine-tune its infrastructure stack to handle large volumes of requests and do so with the utmost stability and performance. Thanks to Chainstack’s robust technology, the Unicrypt development team saw an impactful improvement in terms of response time. In the end, this allowed them to free vital resources that were better put towards building value with their products. With network performance woes in the past, Unicrypt could easily offer the seamless user experience they desired and at the same time launch new nodes in a matter of seconds. Power-boost your project on Chainstack #### UniWhales on Chainstack: Real-time transaction data and alerts across networks Real-time transaction data and alerts UniWhales DAO is a web3 community curating on-chain, off-chain data, and research for the DeFi ecosystem. UniWhales helps bridge activities across multiple chains and layer 2s, building real-time dashboards, custom tracking bots and insightful data on DeFi and decentralized exchange activities across various markets including lending and NFTs. Launched in November 2020, UniWhales has over 10k free subscribers and a token-gated DAO with a growing number of over 300 hyperconnected traders, builders, and investors who help guide the direction of the project. What does UniWhales do? Bridging activities across multiple chains, UniWhales provides outstanding real time transaction data and alerts for Swaps, DEX Liquidity, NFTs, Bridges, and top wallets in Web3 and DeFi. Experience real time monitoring of tokens, whale addresses and their DeFi movements with the webapp dashboard, analyze whale data filtered by date, transaction size, token, or DEX using the purpose-built address filtering tool and get telegram alerts from the community channels for swaps, liquidity, and new tokens. Beyond being a cutting edge DeFi data analytics and research tool, UniWhales describes itself as a decentralized autonomous organization (DAO). An outstanding community of top traders and builders in crypto. UniWhales combines data alerts and dashboards with community driven, curation and content that supports discovery of latest trends in projects and data. A utility token ($UWL) is used to gain membership to the UniWhales analytics platform and access to the dynamic community. How did UniWhales come across Chainstack? Obtaining real-time data that is usable in blockchain requires infrastructure that can provide reliable access that is not only stable for transactions on the blockchain, but also with low latency allowing querying on-chain data that is highly accurate and timely. Chainstack was recommended to UniWhales by Valentin Mihov, ex CTO of Santiment and currently at Daedalus Angels, who invested in UniWhales during their seed round and have been first class in supporting the UniWhales team. With a growing user base and introducing new product features, the team experimented with a variety of blockchain node providers and managed hosting options before settling on Chainstack as the most cost-effective, dependable, and comprehensive solution that meets UniWhales' needs. How does the Chainstack offer match the UniWhales needs? UniWhales DeFi analytics community enables users, developers, and builders to see where capital flows in real time, allowing them to identify trends and market movements. In the DeFi and NFTs markets, things move swiftly, change and announcements happen frequently. Prices can change in a matter of seconds, and news of hacks are becoming increasingly common. Traders rely on data from UniWhales' tools and alerts to make educated decisions that might be the difference between generating tremendous gains or huge losses in a matter of seconds. Looking for a provider that can provide node infrastructure that can accurately provide real-time transaction data across multiple chains, Chainstack provided constant and dependable access to blockchain networks with a distributed network of shared nodes across various deployment locations. Compared to highly congested public access endpoints, Chainstack's fully managed shared network allows for better connectivity to various regions with fewer network and performance difficulties. With Chainstack, UniWhales received access to a highly supportive and dependable partner, allowing them to spend more time developing business solutions that provide value for their users while knowing that the nodes are closely monitored and maintained by a highly competent team. Outcome Chainstack's team made it simple, with an open and helpful support team that responded quickly to any questions the team had. The engineering problems of maintaining node access are greatly minimized, and any service faults are rapidly addressed and remedied. Chainstack's fully managed hosting solutions, which are capable of high-traffic, consistent transactions, have helped to improve latency and connectivity, leading to a better product experience for end-users. Chainstack was the apparent choice for a long-term infrastructure partner to effectively allocate resources and improve operational procedures, thanks to a fantastic collection of features that met all of UniWhales' objectives, including accessible and flexible pricing choices. UniWhales no longer have to worry about node maintenance or upgrades because they now have access to a dedicated and experienced team. UniWhales may now rely on Chainstack for resilient node infrastructure and as a vital partner in getting access to additional networks and protocol support in the ever-evolving DeFi space. Building a stronger analytics community, UniWhales can focus on developing new tools and features to monitor data with greater depth and scale across chains. What does UniWhales like about Chainstack? As UniWhales builds out real-time data analytics across DeFi and NFTs over multiple chains, we see Chainstack as a key partner along our journey. Chainstack's dedication to our collaboration is unwavering, allowing us to add new capabilities and focus on growing the analytics community. Chainstack has been a fantastic infrastructure partner for us as we progressed. Timur Mirzosharipov, Founder, UniWhales What does Chainstack like about UniWhales? UniWhales creates solutions and data analytics that provide Web 3.0 communities with the knowledge and resources they need to make better, more informed decisions. The complexity of the environment and skills gap within DeFi is always increasing as the blockchain and cryptocurrency sectors reach new adoption heights and advance with innovative technology. Market participants are becoming increasingly reliant on the expertise of communities that are fast to adapt. To win in DeFi marketplaces, knowledge becomes a weapon. Similarly, Chainstack's commitment to technical innovation, customer empowerment, and aspirations to educate a broader market aligns with UniWhales' goals of growing and strengthening the analytics community. Chainstack must select dependable, well-established partners with extensive market expertise, such as UniWhales. The coming together of two highly skilled service providers yields ground-breaking technical solutions that help all clients and stakeholders in the industry expand faster. Power-boost your project on Chainstack #### Unlimited Node for blockchain data: Scale your analytics without scaling your costs Data engineers know the pain of working with blockchain data: You’re not just pulling a few wallet balances—you’re scanning millions of records, querying deeply nested contracts, and backfilling months (or years) of history across multiple chains. And what’s standing in the way isn’t the tech. It’s the cost of access. The hidden cost of blockchain data retrieval When you're indexing blockchain data for dashboards, APIs, or internal models, the workload isn’t light: High-frequency polling Large batch archive lookups Deep debug_trace and eth_getLogs operations Cross-chain event tracking And with most RPC providers, the more valuable the method, the more you’re charged. Method, weightChainstackProvider 1Provider 2eth_call12026eth_getLogs12060eth_blockNumber12010eth_getFilterChanges12020Figure 1: Method multiplier comparison for common EVM methods; Source: Chainstack This pricing model creates constant friction: Incomplete datasets due to API caps Long ingestion cycles to avoid cost overruns Delayed delivery of insights and reports Time spent optimizing infra instead of pipelines Unlimited Node: The end of per-request pricing Unlimited Node is a new billing model designed to support large-scale, method-heavy workloads—exactly like blockchain analytics. It’s simple: You pick a requests-per-second (RPS) tier. You pay a flat monthly fee. Then you get unlimited usage within that tier across all methods and networks. No per-method multipliers. No credits. No cost spikes. Whether you’re running 1M+ archive queries per day, polling 20 chains in parallel, or live-tracing forensics across EVM, your bill remains flat. What makes Chainstack different for analytics Unlimited Node is part of a broader platform built for high-throughput data infrastructure: Flat, transparent pricing with no usage-based surprises High-performance archive access optimized for bulk methods Low-latency RPC endpoints across regions 99.99% uptime and monitoring Unified multi-chain access from a single console Use case: High-volume, cross-chain analytics Let’s say you're building a product that: Monitors smart contract security threats Indexes token transfer data across chains Feeds real-time DeFi metrics into dashboards With traditional infrastructure, every deep trace, every call to debug methods adds hidden costs that compound with growth. With Unlimited Node, your costs stay flat: Pick your RPS tier (from 25 to 1,000 RPS) Query real-time and historical data freely Build long-running pipelines with no throttling Plan spend and scale predictably How to get started Log in to the Chainstack console Deploy your node(s) for the chain(s) you support Apply the Unlimited Node add-on Choose the RPS tier that fits your data load Start building without counting requests Unlimited Node is available from the Growth plan. You can mix Unlimited and quota-based nodes for complete control. Power-boost your project on Chainstack #### Unlimited Node for multi-chain DApps: Build without bottlenecks Building a successful Web3 DApp isn’t just about product-market fit or UI polish—it’s about infrastructure that can keep up. From processing live on-chain data to broadcasting transactions across networks, your backend needs to be responsive, resilient, and ready to scale. But for many teams, the real problem isn’t performance. It’s the pricing model. When scaling starts breaking your budget As DApps grow—more users, more wallets, more chains—RPC usage spikes. And that’s where traditional infrastructure starts working against you. Most providers charge you based on opaque metrics: Credits Units Weights Multipliers Suddenly, basic actions like eth_call, getLogs, or estimateGas cost 10x–120x more than expected. What started as a promising MVP ends up burdened by backend complexity and billing unpredictability. Method, weightChainstackProvider 1Provider 2eth_call12026eth_getTransactionReceipt12020eth_getCode12020eth_getBalance12020eth_blockNumber12010eth_estimateGas12020eth_getLogs12060eth_gasPrice12020eth_getTransactionCount12020Figure 1: Method multiplier comparison for common EVM methods; Source: Chainstack Under traditional billing models, this leads to: Unpredictable infrastructure costs Dev teams throttling features to stay within usage caps Hours lost debugging infrastructure overages Inability to forecast spend during launches or token events These problems stem from pricing models built on: Per-request charges that escalate with traffic Method-based multipliers that inflate usage costs Usage spikes that generate billing surprises Complex unit pricing models that are hard to plan for Unlimited Node: RPC pricing reimagined Unlimited Node introduces a new billing model for Web3 infrastructure—one that actually scales with your application. Instead of counting requests or managing weighted methods, you pay a flat monthly fee based on your selected requests-per-second (RPS) tier. You get unlimited usage within that tier. No surprise fees. No request caps. No mental overhead. No hidden multipliers No billing spikes No overage charges Whether you're monitoring events, running bots, or backfilling data, you build unlimited—across all methods and supported chains. Why DApp teams choose Unlimited Node Unlimited Node is purpose-built for developers and founders who want infrastructure they can trust: Flat-rate pricing across 25–1,000 RPS tiers Unlimited RPC requests within your tier No method-based multipliers or usage penalties Supports all major protocols Built on our globally distributed infrastructure with 99.99% uptime Real-world flexibility for growing apps Whether you're building your MVP or scaling to millions of users, Unlimited Node simplifies the path forward: Stream live on-chain data Power a dashboard, backtest, or real-time product experience Expand to EVM + Solana without re-architecting infrastructure Scale usage without tracking every RPC call See how DApp teams build at scale. How to get started Log in to the Chainstack console Deploy your node on the chain(s) your app supports Apply the Unlimited Node add-on Choose your RPS tier Build and scale your DApp without worrying about infrastructure limits Unlimited Node is available from the Growth plan. You can mix and match Unlimited and quota-based nodes in the same project. Power-boost your project on Chainstack #### Unlimited Node for traders: Execute faster, scale smarter In trading, milliseconds matter. Every failed transaction. Every delayed confirmation. Every missed on-chain signal—it’s money left on the table. Trading infrastructure must be fast, accurate, and battle-tested. But more often than not, the biggest tradeoff isn’t latency. It’s the pricing model. What’s slowing down your edge? High-performance trading bots and strategy engines rely on a constant stream of on-chain data: Monitoring mempool events Watching liquidity pools Tracking token approvals Calculating slippage in real-time Executing transactions before price windows close But most RPC providers charge you based on how much you use—or worse, how “heavy” your methods are. Method, weightChainstackProvider 1Provider 2eth_call12026eth_getTransactionByHash12020eth_getBlockByNumber12020th_getLogs12060eth_blockNumber12010 Figure 1: Method multiplier comparison for common EVM methods; Source: Chainstack For trading systems, this creates real-world problems: Unpredictable infrastructure costs Method multipliers that penalize performance-sensitive logic Usage spikes during volatile markets that lead to billing surprises Extra complexity in managing infrastructure budgets This isn’t just inefficient—it’s risky. Unlimited Node: Built for trading-grade infrastructure Unlimited Node is Chainstack’s solution for trading systems that demand consistency, speed, and cost clarity. You get unlimited RPC usage within a chosen RPS (requests-per-second) tier—for a flat monthly fee. No matter how many eth_call, eth_getTransactionByHash, or eth_getBlockByNumber requests you fire. No method multipliers No per-request pricing No surprise billing at peak hours You select the throughput your strategy needs—starting at 25 RPS and up to 1,000 RPS—and your cost stays flat. Designed for live trading environments Chainstack infrastructure is built to deliver for latency-sensitive workloads: Geo load balanced nodes to minimize response times 99.99% uptime and multi-region global failover Supports all major trading-relevant chains, including Ethereum, Polygon, BNB Smart Chain, and Solana Transparent pricing for all use cases—no method weights or hidden costs See how teams scale high-performance workloads. How to get started Log in to the Chainstack console Deploy your node(s) across the chain(s) you trade on Apply the Unlimited Node add-on Choose an RPS tier based on your real-time data and tx load Build and execute at scale—without infrastructure drag Unlimited Node is available from the Growth plan. You can combine Unlimited and quota-based nodes in a single project to fine-tune usage. Power-boost your project on Chainstack #### Unlimited Node for Web3 wallets: Scale with confidence and ease Web3 wallets live and die by infrastructure performance. Whether it’s real-time balance updates, fast transaction broadcasting, or seamless multi-chain support—the backend must be fast, reliable, and scalable. But performance isn’t the only challenge. The real blocker is the pricing model. Most RPC providers still tie billing to per-request charges, method-based multipliers, and usage-based pricing that penalizes growth. The result? For Web3 wallets, infrastructure costs are always too complex to predict. The problem: RPC billing that punishes growth As your wallet scales, infrastructure usage grows fast. Every user interaction—account lookup, eth_call, gas estimate—turns into multiple RPC calls. Here’s what you’re actually paying for: Method-based multipliers (e.g., 10x–120x for eth_call, trace_*, or debug_*) API credits or compute units instead of real request counts PAYG pricing that fluctuates based on usage spikes Lack of visibility into what’s driving costs Every real-time token update. Every gas estimate. Every nonce check. It all adds up fast—especially during peak usage. Method, weightChainstackProvider 1Provider 2eth_getTransactionReceipt12020eth_call12026eth_getBalance12020eth_chainId120–eth_getBlockByNumber12020eth_blockNumber12010eth_getLogs12060eth_estimateGas12020Figure 1: Method multiplier comparison for common EVM methods; Source: Chainstack Under traditional billing models, scaling a wallet backend introduces friction at every stage: Unpredictable infrastructure costs that derail planning Usage caps that slow down feature rollouts Time lost tracking billing anomalies or debugging cost spikes Added complexity in monitoring and forecasting infrastructure spend These challenges stem from opaque billing structures, including: Per-request charges that escalate with traffic Method-based multipliers that inflate usage costs Usage spikes that generate billing surprises Complex unit pricing models that are hard to track Instead of focusing on product velocity, wallet teams end up firefighting infrastructure billing. The solution: Unlimited Node Unlimited Node is a new, transparent RPC billing model that replaces complexity with predictability. You get unlimited RPC usage within a selected requests-per-second (RPS) tier, for a flat monthly fee. Key benefits for Web3 wallet builders: Flat-rate pricing across clear RPS tiers (25 to 1,000 RPS) Unlimited usage within your tier—no per-call pricing No method multipliers or hidden costs Supports all Chainstack-supported protocols Built for high-throughput, production-grade workloads Learn more about Unlimited Node on Chainstack. How to get started Log in to the Chainstack console Deploy your node on the desired chain(s) Apply the Unlimited Node add-on Choose your RPS tier based on traffic needs Connect your backend and start building at scale Unlimited Node is available from the Growth plan. Mix and match with quota-based nodes as needed. Power-boost your project on Chainstack #### Unlock the Power of Dedicated Nodes We've supercharged Chainstack's Dedicated Nodes and optimized our infrastructure, making unlimited requests with ultra-high throughput available across more protocols! Throughout June, we're announcing a new chain available on the Dedicated Node each day. Stay tuned and contact us for the best Early Bird offer! See all chains Why Dedicated Node? Spreadsheets full of per-method multipliers and daily request caps drain focus from shipping code. Worse, they introduce cost surprises when traffic finally spikes. Chainstack's Dedicated Node eliminates that anxiety by providing a private RPC node instance with customization options, unlimited requests, and ultra-high throughput. From Ethereum and Solana to brand-new ecosystems, we power over 70 networks at Chainstack Cloud. Learn more about Dedicated Node Built for persistent reliability 99.99 %+ uptime backed by a rock-solid SLA. Deployed in a SOC 2-compliant Chainstack Cloud for enterprise-grade security. Fully managed by Chainstack, so you can focus on building, not babysitting infrastructure. Learn more about security Early-Bird advantage Jump in now and you’ll lock in a special Early Bird offer on any freshly onboarded chain. It’s the perfect moment to secure best-in-class performance for the best price. Follow us on social media, or better yet, reach out to our support or sales team to get your dedicated node. #### Unmasking DApp endpoint security: The Chainstack research results The rapid growth of decentralized applications (DApps) has unlocked new possibilities for a decentralized digital future. However, the security of these applications is just as much of a crucial factor in determining their success as their overall adoption is. That is why, we set out to explore the current state of the Web3 landscape in our recent study, specifically aiming at unmasking DApp endpoint security. We conducted the research over a data set of nearly 8 000 individual projects, uncovering a significant share of alarming results and major reasons for concern across multiple verticals and protocols. In this blog post, we will delve into the key findings of our study, shedding light on project activity, DApp integrity, common cloud service providers, RPC endpoint exposure, and the node provider it originates from, as well as endpoint sharing and whitelisting practices. And by raising awareness of the issues present in each category, we strive to foster a more secure and reliable decentralized landscape, ultimately building trust and ensuring the continued growth of the industry. You can find the full research paper available for download freely at the bottom of this post here. The Importance of endpoint security in decentralized applications As the DApp landscape grew, with a 50% increase in unique active wallet data from 2021 to 2022, security concerns, especially endpoint security, have escalated. Generally speaking, endpoints are vulnerable due to the variety of platforms and media they originate from, the vast number of devices using them, and the plethora of ways user interactions take place. Figure 1: Endpoint exploit attack vectors (Malwarebytes 2018) Studies have identified several attack vectors aimed at endpoints in the Web3 context, including vulnerabilities like Sybil attacks, private key leaks, mining malware, and cryptojacking. To address these concerns, experts suggest moving authentication, authorization, and policy enforcement closer to network edges and endpoints. Figure 2: Comprehensive blockchain security risk categories (Institute for Infocomm Research, A*STAR, Singapore, 2021) As the number of users and devices interacting with blockchain networks and decentralized applications increases, organizations must invest in robust, well-integrated security strategies to protect their assets and data. This involves focusing on endpoint security measures, staying informed about the latest trends and threats, and fostering a culture of security awareness and responsibility among employees. Collaboration between industry players, academia, and regulatory authorities is crucial for tackling endpoint security challenges in the DApp landscape. By sharing knowledge, resources, and best practices, stakeholders can work together to develop innovative solutions and create a more secure and resilient decentralized ecosystem. Investigating DApp endpoint security: Methodology and research questions In our study, we explored endpoint security vulnerabilities in decentralized applications by examining a diverse sample group using a custom-built data collection tool. Our research aimed to fill knowledge gaps by gathering concrete technical parameters and employing inductive analysis techniques to identify patterns to refine our theoretical framework. Our research questions targeted critical aspects of DApp endpoint security, including concerns and vulnerabilities across verticals and protocols, variations in endpoint exposure among different sectors, the prevalence of certain node and cloud service providers, as well as the presence of whitelisting practices to provide adequate recommendations for further security improvements. We addressed five main research questions: What is the current state of the DApp ecosystem, in terms of project activity and the overall technical integrity of the services being offered? What are the critical concerns and vulnerabilities associated with DApp endpoint security, across various verticals and protocols? How does the level of endpoint exposure vary among different verticals and protocols and which of them are most prone to poor security practices? Which are the most commonly used node and cloud service providers for DApp projects and the ones typically affected by poor endpoint security? How prevalent is the practice of whitelisting among fully exposed DApp endpoints and how does it differ across various protocols and verticals? We selected 8 157 DApps as data points for our research, representing various use case verticals, including Collectibles, DeFi, Gambling, Games, Marketplaces, Social, High-Risk, and Other. It is important to note this number amounts to 7 343 if you count multi-chain projects as a single entity. Our custom-built web scraper tool collected relevant data from these DApps by doing DNS as well as Autonomous System (AS) lookups while examining their network activity for Fetch/XHR requests to Web3 RPC endpoints. We then assessed the presence of additional security measures for these RPC endpoints by performing simple cURL requests to determine whether they had whitelisting enabled. The findings of this study are meant to serve as a foundation for further research while offering valuable insights for Web3 organizations interested in enhancing DApp security as well as individuals evaluating the safety of their assets. The data collection instrument itself also presented potential ideas for further academic investigation of the subject matter and related topics. Key findings from the study In this section, we will delve into the essential insights and notable trends brought to light by the comprehensive research we conducted on the decentralized application landscape. By sharing these findings, we strive to provide a better understanding to the general public of the current state of the DApps ecosystem, along with the implications of poor security on the industry’s future as a whole. Project activity: Mapping out the current DApp landscape Of the 8 157 DApps we analyzed, just over half (54%), or 4 424 to be exact, could be deemed active, which left a gaping hole of 3 733 inactive ones from the 46% that remained. This served to emphasise the importance of understanding the reasons for project inactivity across verticals and protocols. When we omitted DApps with multi-chain deployments, DeFi, High-Risk, and Games emerged as the leading verticals for the 7 343 unique projects. Consequently, they accounted for segments of 28%, 24%, and 17%, respectively, while the remaining verticals made up 31% of the total DApp tally. High-Risk and Gambling projects showed higher rates of inactive DApps, reflecting a possible lack of trust in these use cases. In contrast, Collectibles and Marketplaces, though smaller in numbers, had nearly 76% DApp activity rates, suggesting higher trust levels and long-term user engagement. Figure 3: DApp ecosystem project activity overview by vertical Binance Smart Chain (BNB) and Ethereum were the most widely used protocols for DApps, with 43% and 37% shares, respectively. Both had an inactive DApp rate of approximately 49%. DeFi, the most popular vertical overall, boasted a high rate of active DApps on Ethereum and Avalanche with 77%. BNB, on the other hand, featured a higher percentage of DApps in the High-Risk sector, possibly due to the lower cost barriers involved in developing a project on the protocol, while Ethereum hosted a smaller portion of High-Risk DApps but experienced a higher inactivity rate for them overall. Figure 4: DApp ecosystem project activity overview by protocol DApp integrity: Separating legitimate and disreputable projects Despite there being a real potential for fraudulent activity, our findings indicated that the actual prevalence of such activities was relatively minimal. Out of the 8,157 DApps analyzed, a mere 1.6% were classified as disreputable. When considering their proportion among active DApps instead of the total count, this figure rose only slightly, to just under 3%. This modest number indicated that disreputable projects were the exception rather than the norm, which is sure to put many at ease. Figure 5: DApp integrity overview A look into disreputable DApps across various verticals showed that DeFi was the most common one, with 2.5% of its active projects classified as such. High-Risk and Gambling verticals had the highest rates at 7% and 6.5%, respectively. In contrast, marketplace projects exhibited the lowest rate of 1.6%, while social projects ranked third highest at 3.7%. Other, Gaming and Collectibles displayed relatively low rates of 3.1%, 2.7%, and 2.2% in the same order. Figure 6: Disreputable DApps by vertical When evaluating disreputable DApps by protocol, BNB had the highest number and percentage (61 DApps for 3.5%), followed by Ethereum with 3.1% from 49 DApps. Polygon had 20 such projects for 2.5%, while Avalanche had only 0.7% from just 2. A deeper analysis of the data by both protocol and vertical revealed that High-Risk projects had the highest rates across BNB, Ethereum, and Polygon. Figure 7: Share of disreputable DApps by protocol and vertical Cloud service provision: An overview of common Web3 hosting options Cloudflare led the Web3 cloud service provider market with a 35% share, followed by Amazon Web Services (AWS) at 19%, and Vercel and Google Cloud Platform with approximately 10% each. Other providers, including Fastly, Namecheap, DigitalOcean, Hostinger, OVH, and Bodis, collectively accounted for 12% of active projects. Figure 8: Most common cloud service providers When examining cloud service provider preferences across various verticals and protocols, Cloudflare consistently ranked as the most popular choice. Regardless of the sector, the top four providers remained relatively consistent, with Cloudflare at the top, while AWS, Google, and Vercel contested over the remaining slots in the bracket. Figure 9: Cloud service providers by vertical In conclusion, while Cloudflare remained the market leader in the Web3 cloud service provider landscape, a closer examination revealed a more nuanced story. Providers such as Vercel, Amazon, and Google did seem to be gaining traction in specific verticals and protocols, with Vercel emerging as a popular choice for niche use cases in Web3. Overall RPC endpoint exposure: evaluating partial and full exposure Our study of 3 731 individual active DApps discovered that 1,385 (37%) have exposed RPC endpoints on the front-end. This number is quite significant, considering such vulnerabilities pose a significant risk for user data and interactions, as visible RPC endpoints can lead to loss of funds or unauthorized malicious actions. Despite many projects adhering to endpoint security best practices, the large share of exposed endpoints highlights the need for fundamental improvements in security across Web3. DeFi projects accounted for the highest segment of DApps with exposed endpoints with their 62.8%, followed by Ethereum with half this number, or 20.9% to be exact. When it came to BNB, it exhibited the largest share of 38.4%, while Polygon and Avalanche claimed 34% and 37.6%, respectively. This data underscores the urgency of security improvements for projects built on BNB, although other protocols need to address endpoint security too, particularly those with higher shares of exposure. Avalanche Collectibles, Polygon DeFi, and BNB Smart Chain DeFi had the most significant exposure shares of 64%, 52%, and 51%, respectively. This highlighted the necessity for swift resolution and increased user vigilance in these categories. Although certain sectors, such as Ethereum Gambling, High-Risk, Games, and Other, exhibited lower exposure shares, the need for better endpoint security is still there and must be a priority for all developers contributing to the DApp ecosystem. Figure 10: Projects with visible RPC endpoints by protocol and vertical Fully exposed RPC endpoints: Verticals and protocols with the highest vulnerabilities In our analysis, it was crucial to distinguish between DApps with partially exposed RPC endpoints and those with full exposure. This is so, as full endpoints allow unrestricted external access to their API, enabling anyone to execute commands unobstructed and exposing them just makes it all too easy. The good news was that out of 3 731 individual active projects, only 391 or roughly 10% had fully exposed endpoints. However, this context became more alarming when comparing partially exposed DApps with those with full exposure. Of 1 385 DApps with exposed RPC endpoints, 994 (72%) were not fully exposed, leaving a concerning 28% segment that is entirely open and publicly interactable. Figure 11: Share of DApps with fully exposed RPC endpoints by vertical Examining the data by verticals revealed that DeFi, Marketplaces, and Collectibles had the highest shares of projects with fully exposed endpoints, which is particularly concerning as these verticals carry the largest liabilities. In DeFi, these were 15.6%, while Marketplaces and Collectibles had shares of 14.8% and 13.5%, respectively. When analyzing the data by protocol, Ethereum stood out with the highest quantity and share of fully exposed RPC endpoints. From the tally of 276 DApps with fully exposed endpoints, Ethereum had a 17.5% share, nearly twice as much as Polygon’s 9.6%. When considering the share of fully exposed endpoints from active projects, Ethereum and Polygon were equally matched at 3% each. Investigating the data through a combined lens of protocol and vertical, Ethereum DeFi emerged as the category needing the most improvement, with a 31% share of DApps with fully exposed endpoints. Other Ethereum verticals such as Marketplaces, Social, and Collectibles exhibited lower shares at 19%, 16%, and 15%, respectively. Without Ethereum DeFi in the dataset, the results across all protocols would have been more balanced, fluctuating between 10% and 15%. Figure 12: Share of DApps with fully exposed RPC endpoints by protocol and vertical Node service provider prevalence among DApps with RPC endpoint exposure Keeping in mind the fact that some DApps made use of more than one provider, we didn’t explore this particular subject on an individual project basis. Instead, we took into consideration the entirety of the data set, without counting multiple exposed endpoints as a single one. Among the entire tally of 1 540 exposed RPC endpoints, a significant share of 51.6% were public endpoints, which was unsurprising, considering their cost-free nature and general availability. As a consequence, there was possibly less of an incentive to secure them, leading to higher exposure. Setting aside the public endpoints for a moment, we found that Ankr and Infura took the second and third spots, with 15.7% and 14.7% of the exposed endpoints, respectively. Alchemy came in fourth place, representing 8.9% of the total. Figure 13: Exposed RPC provider share The remaining providers, including Quicknode, Chainstack, Nodereal, Cloudflare, Pocket Network, and Moralis, did not offer statistically significant results for adequate analysis on their own. When aggregated, they approached the figures held by the fourth-place contender, Alchemy. When we took a closer look at the data by verticals, we could see that High-Risk, Games, and Other had the largest share of exposed public endpoints at 65%, 52%, and 51% respectively. On the other hand, Infura and Ankr dominated Collectibles and Gambling with 31% and 26%, for non-public ones. The results varied when examining the data by protocol, as both BNB and Avalanche predominantly featured exposed Public endpoints at 88% and 86%, respectively. Ethereum and Polygon, however, showed a more balanced distribution with Infura and Ankr holding the largest segments at 52% each. Cross-project exposure: A pressing yet less prevalent concern When examining the data set of 41 DApps with shared exposed RPC endpoints, we found that High-Risk, Social, and Marketplaces verticals had the highest prevalence, claiming 20%, 20% again, and 14% shares respectively. In absolute terms, this translated to 4, 2, and 2 DApps in each category. But due to these low absolute values, the need for further investigation here was especially pronounced. Analyzing the data by protocol revealed that Avalanche and BNB Smart Chain exhibited the worst results in terms of cross-project RPC exposure, with 40% and 34% of their fully exposed endpoints respectively. However, due to the small sample sizes, especially for Avalanche, these findings could not be deemed statistically conclusive. Ethereum and Polygon protocols, on the other hand, had a lower share of fully exposed endpoints with cross-project exposure at 8% and 6% respectively. When examining the data by protocol and vertical, Ethereum emerged as the dominant protocol for cross-project RPC exposure, accounting for 56.1% of all shared fully exposed RPC endpoints. Within Ethereum, DeFi was the vertical with the highest share with 27%, followed by Collectibles at 12%. In turn, BNB Smart Chain had two on par with 10% segments - the High-Risk and DeFi verticals. Figure 14: DApps with cross-project RPC endpoint exposure by protocol and vertical Current state of whitelisting in the DApp ecosystem In an effort to understand the presence of the whitelisting security practice in the DApp ecosystem, we analyzed a sample of 422 fully exposed endpoints. Not even a quarter of these, or 92 to be exact were found to have implemented such policies, indicating that an incredibly large portion remained unprotected against potential malicious activities. When examining the data by vertical, we found that Marketplaces, DeFi, Gambling, and Other had the highest share of whitelisted fully exposed endpoints, with 32%, 28%, 25%, and 22% respectively. However, not all of these verticals had statistically significant sample sizes, with Gambling and Other having the least number of endpoints. While Marketplaces, Games, and High-Risk verticals had more endpoints in their samples, their whitelisted segments were just 15% and 6% respectively. When analyzing the data by protocol, Ethereum and Polygon had the largest and most statistically significant sample sizes, with 66 and 21 endpoints respectively. Both protocols had roughly a quarter of their fully exposed endpoints whitelisted (22% for Ethereum and 27% for Polygon). Conversely, BNB had a lower such share of just 9%, and given its larger overall sample size, BNB could be labeled as the least protected protocol in terms of whitelisting presence in fully exposed RPC endpoints. Figure 15: Whitelisted RPC endpoint share by protocol and vertical Conclusions and recommendations for further improvement Our study revealed several security concerns for the DApp ecosystem. A notable percentage of active projects had exposed RPC endpoints, whether partially or fully, with Ethereum, particularly its DeFi vertical, being the most vulnerable. That is why, we recommend that developers prioritize securing their DApps' RPC endpoints, especially in the DeFi, Marketplaces, and Collectibles sectors. Overall, users should exercise caution when interacting with projects that have fully exposed RPC endpoints. Additionally, our analysis found that Public endpoints made up a significant share of exposed RPC endpoints, with High-Risk, Games, and Other verticals having the largest share of exposed public endpoints. To improve security, we encourage raising awareness on public endpoint security, calling for node service providers to enhance their security measures, and conducting further research to help shed even more light on specific vulnerabilities within each vertical and protocol. Lastly, our investigation of endpoint access exposure revealed that only a small percentage of fully exposed DApp endpoints were whitelisted, indicating a significant need to implement better security practices. We encourage DApp developers to make use of whitelisting and avoid front-end visibility of their endpoints, especially in verticals with lower rates of adoption. Focus should also be given to projects deployed on protocols that tend to have less protected endpoints, such is the case for BNB. Building a secure and reliable decentralized infrastructure That being said, our comprehensive study of DApp endpoint security did uncover critical concerns and vulnerabilities across various verticals and protocols. With 10% of active DApps having fully exposed RPC endpoints, the potential risks to users and developers are significant, particularly in the DeFi, Marketplaces, and Collectibles sectors. Ethereum, as the protocol with the highest number of projects with fully exposed RPC endpoints, requires urgent attention, especially in its DeFi vertical. Cross-project exposure and the lack of whitelisting implementation in the DApp ecosystem further compounded the security challenges. High-Risk, Social, and Marketplaces verticals stood out as the ones with the highest shared endpoint exposure, while just about 22% of fully exposed ones overall employed whitelisting, a vital security practice. All of this highlighted the need for increased efforts in promoting and implementing endpoint security best practices further across the entire landscape. To ensure a more secure and reliable DApp experience, we propose preventive actions, including prioritizing the securing of RPC endpoints in critical sectors, enhancing and promoting existing node provider policies, as well as encouraging the adoption of whitelisting among DApp developers. By following these recommendations, we can foster trust and facilitate the ongoing growth and success of the decentralized applications landscape, benefiting users, developers, and service providers alike. Get the Endpoint secrets exposed study PDF Download the full Endpoint secrets exposed: A tale of 8000 DApps research paper for free: Download study Power-boost your project on Chainstack #### Unrivaled Infrastructure meets unbeatable pricing: Introducing Chainstack Global Nodes Since the launch of Chainstack in 2018, we have served over 80,000 developers, providing them with the tools to interact with blockchain technology and connect with the broader Web3 industry. We have constantly collaborated with our partners and clients, actively seeking feedback, and implementing improvements to enhance our platform’s capabilities and user experience. What are Chainstack Global Nodes? Designed to enhance performance and reliability, Chainstack Global Nodes are a key advancement to our architecture. Under the hood, Global Nodes utilize geo-load balancing technology which enables intelligent routing of requests to the nearest server, reducing latency and delivering maximum performance. By proactively monitoring node status, Global Nodes adapt to network conditions in real time providing instant failover to another node during network interruptions on a global scale. They also provide infinite scalability, reduce disconnection rates, and distribute workloads across multiple locations, resulting in enhanced performance and increased reliability for Web3 projects. Finally, it helps developers deliver an improved user experience as it ensures the end-users receive a fast and responsive application engagement regardless of their geographical location. Whether the user is accessing a DApp from New York or Tokyo, Global Elastic Nodes provide a global network of nodes ensuring consistent performance, making distance and location barriers virtually disappear. Prime benefits with Global Nodes Here’s what it means for your applications and projects: Global connectivity: Route requests to the closest server based on users’ geographic locations, which provides near-zero latency and best-in-class performance. Unparalleled scalability: Ensures the seamless handling of many requests simultaneously. By distributing traffic to other locations, we prevent network congestion and enable zero disruption to your application. Peak reliability: Re-routes operations in under 1 second the moment our infrastructure detects any network disruption or network congestion, ensuring 99.99%+ availability on both, WebSocket API and HTTP. Robust protection: Protection from Distributed Denial-of-Service (DDoS) attacks ensures secure encrypted communication between users and the services they access. By utilizing Chainstack Global Nodes, applications will always remain available, and even users on one side of the world can retain the same performance and latency even when they travel to the other side of the globe. A new billing system to simplify your costs and usage We’re also excited to introduce a new billing system after implementing feedback from our developer community. For the first time, we offer customers a unified monthly usage quota, combining the requests from Elastic Full and Archive Nodes, and Dedicated Subgraphs. To make this possible, we’ve designed Request Units or RUs, providing our users with complete flexibility and granular control to allocate resources according to their needs, while still maintaining the simplicity of offering all methods at the same cost. Request TypeCostElastic Full Node request1 RUElastic Archive Node request2 RUsDedicated Subgraphs20 RUs It is important to note that the different costs associated with Request Units only apply to the node itself. These rates apply to both, Global and Regional mode settings for your Elastic Nodes. Here’s what it means if a user dedicates their entire quota to making requests to an Archive Node: Growth: Up to 10 million archive requests Business: Up to 70 million archive requests Enterprise: Up to 200 million archive requests In short, users will receive up to 3x+ more archive requests compared to the included requests in the previous pricing scheme. And here are our new, combined usage quotas that provide you with unparalleled request volumes: PlanMonthly QuotaDeveloper3 million RUsGrowth20 million RUsBusiness140 million RUsEnterpriseCustom, starts at 400 million RUs Check out our Pricing page for more details. Final words With Chainstack Global Nodes, users can experience unprecedented performance and reliability, eliminating concerns about network disruptions or latency. Additionally, the introduction of Request Units has not only enhanced the accessibility of our core products and features but has also maintained the same level of simplicity as before. This means that all requests are still priced equally, ensuring a fair and straightforward experience for all users. Now users can confidently explore new tools and scale their projects knowing that the costs of their API requests align with their usage needs. Power-boost your project on Chainstack #### Unstoppable Web3 development with Chainstack Global Nodes The world relies on infrastructure that can keep up with the velocity of information. And Web3 demands solutions that not only survive in this fast-paced environment but also thrive and lead. At Chainstack, we've risen to this challenge with our award-winning Global Nodes. Part of our robust Web3 API solution, Chainstack Nodes push the boundaries of performance, reliability, and efficiency for decentralized infrastructure. So, fasten your seatbelts! We're about to voyage through this pioneering blockchain technology, brought to you by Chainstack. Chainstack Global Nodes today Since their debut in late June, Global Nodes have demonstrated remarkable efficacy. In just two short months, Chainstack Global Nodes managed to process an impressive tens of billions of monthly requests. But beyond these striking numbers, what's truly significant is their impact. Currently, they account for over 10% of our Global Nodes request usage. This increasing trend suggests that Global Nodes are rapidly becoming the preferred choice for developers, highlighting the growing reliance of the Web3 community on this state-of-the-art technology. The relevance of these figures goes beyond mere numerical achievements. They epitomize the efficiency and convenience Global Nodes introduce to the blockchain domain. These metrics are a testament to the stability and assurance Chainstack Global Nodes deliver to Web3 developers. Award-winning Global Nodes architecture As developers ourselves, we understand the significance of a robust foundation for any digital solution. That's exactly what we've engineered at Chainstack. Our award-winning Global architecture has already made stellar waves for its trusted groundbreaking design, making it more than just a useful tool—it's your reliable partner in building novel decentralized applications. This architecture design was first unveiled as the “Unstoppable RPC Endpoint” project submission at the ETH Belgrade hackathon, then further built upon for ETHGlobal Istanbul earlier this year. Winning several awards at each occasion it is at the heart of our Chainstack Global Nodes. Each node is a part of an advanced globally-distributed geo-load-balanced system designed to allocate the workload evenly across various nodes. Addressing traditional RPC endpoint challenges RPC endpoints are a critical component of any DApp, but they also come with challenges that can hinder development, such as poor performance, unreliability, and limited scalability. At Chainstack, we've identified these issues and tackled them head-on in our Unstoppable RPC Endpoint project, later culminating in our Global Nodes. Figure 1: What makes our Global architecture stand out; Source: ETHBelgrade hackathon slides Chainstack Global Nodes aggregate multiple RPC endpoints and intelligently redirect requests, a measure that ensures optimal performance and uptime, so your DApp remains responsive and reliable. We've designed our Global architecture to handle the complexities so that you can pay attention to what truly matters—building the future of Web3. A commitment to unparalleled uptime As Web3 developers ourselves, we know that every second of downtime can take a toll. Beyond the inconvenience, downtime can erode your users' trust, affect your application's reputation, and even result in potential loss of revenue. That's why we've made it our mission to deliver an unrivaled uptime of 99.9%. Figure 2: Unstoppable RPC Endpoint architecture; Source: ETHBelgrade hackathon repo We've built our Global Nodes to be sturdy and reliable, using geo-load-balanced architecture to ensure consistent performance. Our intelligent rerouting mechanism instantly shifts the load to the next most performant node in case of any network-health issues, creating a seamless fallback chain. This makes sure you can rely on smooth, efficient, and, most importantly, consistent operations, even if the world around you is burning. Your very own Global Archive Nodes time machine Accessing and leveraging historical data are crucial aspects in the development of sophisticated DApps, particularly for blockchain developers working with high throughput per second (TPS) blockchains like Solana, which now has data spanning multiple terabytes. In turn, this also means an exponential rise in costs for calls to Archive Nodes and consequently project running costs. Method multipliers can quickly deplete your quota, and often, by the time you notice, it's already too late—an overcharged invoice is already sitting in your inbox. That is why we took extra care in designing our Global Archive Nodes for maximum cost-efficiency. And it is not a rare sight to see a 2-3x difference when you put the infrastructure bills side-by-side. That is especially true for Debug & Trace methods, where costs can absolutely skyrocket, due to the complexity of each call. These APIs offer in-depth insights into transactions, block details, and the execution of smart contracts, greatly simplifying the process of pinpointing and fixing DApp issues. And Chainstack Archive Nodes shred the bill in half. Whether it's querying for certain patterns in past transactions or performing complex analytics, any Chainstack node you deploy is designed to handle the load. Our Global Archive Nodes offer an impressive 99.9% uptime too, ensuring consistent, uninterrupted access to vast historical records. Total control with customizable Global Nodes infrastructure As developers, we understand that one size doesn't fit all. Every DApp is unique and therefore has different requirements when it comes to infrastructure. Recognizing this, we've created a solution that gives you the control you need over your environment. Multi-chain Global Nodes by design We understand the importance of having the flexibility to navigate and innovate across a multitude of blockchain protocols. Whether you are developing DeFi applications on Ethereum, creating next-gen digital assets on Polygon, or exploring the synergies of interoperability on Binance Smart Chain, our nodes are designed to support it all: Regional nodes: Ethereum, Polygon, BNB, Base, Avalanche, Arbitrum, zkSync Era∎, Polygon zkEVM, Optimism, Oasis Sapphire, NEAR, Aurora, Solana, Aptos, Gnosis Chain, Cronos, Filecoin, Fantom, Starknet, Harmony, Tezos, Fuse, Scroll Global nodes: Ethereum, Polygon, BNB, Avalanche, Arbitrum, Solana, Scroll, Fantom With Chainstack, you get to focus on coding the future of the decentralized world, while we take care of providing the resilient, reliable, and robust infrastructure you need. Pick the cloud that suits you best When it comes to hosting your nodes, the choice is truly yours too. At Chainstack, we believe in providing you with the freedom to construct an environment that perfectly suits your requirements. You can build on the Chainstack Cloud, highly praised for its top-tier security and uptime, or you can opt for a managed cloud service—from AWS, GCP, Azure, and Virtuozzo to a bring-your-own-cloud setup. Here's a closer look at the hosting locations provided by each: Amazon Web Services: With AWS, you can host your nodes in North Virginia, Oregon, Singapore, or Tokyo, providing a range of options spanning the globe. Microsoft Azure: If Azure is your platform of choice, you can enjoy their managed services in London, taking advantage of their ubiquitous reliability and security features. Google Cloud Platform: Those choosing to go down the GCP route have the option to host in Singapore, where the power of Google's smart and secure cloud platform can be leveraged to full effect. Virtuozzo: If optimum virtualization is your target, you can opt for Virtuozzo, currently hosting nodes in Frankfurt, Amsterdam, or Dallas. Chainstack Cloud: Looking for our dedicated cloud services? We have you covered in Amsterdam and Ashburn, where we proudly offer our best-in-class security and uptime. Bring-your-own-cloud: Select from 20+ regions available on Amazon EKS via private hosting, broadening the range of customization and ensuring a near-perfect match for your specific needs. Don’t see what you’re looking for? Rest assured, we're always ready to expand our offerings to meet your needs. If you don't see the hosting provider or location you require, don't hesitate to reach out to us. Our team is committed to ensuring that your needs are catered to, allowing you to BUIDL your solutions on cloud services that you trust. Lightning-fast propagation with Warp Transactions Expect nothing less than warp speed when using our Global Nodes. We have geared our Global architecture to provide exceptionally fast transaction propagation via bloXroute, up to 2.5 times quicker than standard P2P transactions via Warp Transactions. For developers, this means your applications can deliver faster transaction experiences, which is particularly crucial in time-sensitive applications like DeFi, NFT minting, and gaming. With Chainstack, not only can you deliver more responsive applications, but you can also outpace your competitors and delight your end users. Transparent and unbeatable Global Nodes pricing Understanding your costs shouldn't be a complex equation. At Chainstack, we champion transparency, especially when it comes to pricing. We've set the table with a straightforward, competitive structure that comes with no hidden surprises. That is why we’ve made our pricing is competitive and accessible, ensuring that even developers with budget constraints don’t have to compromise on quality. There are no fees based on specific methods. For predictable monthly infrastructure costs, every API call to your node comes with a flat rate billed in Request Units (RU), regardless of the request type or the computational resources needed: Global Full Node request: 1 RU Global Archive Node request: 2 RUs We offer a range of affordable commitment tiers to suit different needs, whether you’re a solo developer just starting out or an established organization looking for a wide array of services. And the best thing about it? You can create custom usage profiles with the pricing calculator and see how well Chainstack delivers versus the competition. Our goal is to ease the toll of creating fantastic applications, not add to it. That means keeping costs down and value up while facilitating your ability to plan for and control your budget. By prioritizing accessibility and affordability, we aim to level the playing field, allowing developers of all sizes and budgets to bring their blockchain innovation to life. Creating the next big thing in Web3 shouldn't break the bank, and with Chainstack, it won't. How would your on-premise costs fare against ours? Find out in our dedicated article on self-hosted Ethereum archive node costs. Bringing it all together The path towards blockchain adoption is an uncharted one, laden with complex challenges and immense promise. As we navigate this journey, we at Chainstack remain committed to being a reliable guide and partner for developers around the world. Our Chainstack Global Nodes featuring geo-load balancing are just one aspect of our larger mission to demystify the world of blockchain and accelerate the shift towards Web3. By providing robust, scalable, and reliable infrastructure for decentralized applications, we're opening doors to limitless innovation. With promised 99.99% uptime, comprehensive multi-chain support, customizable infrastructure, transparent pricing, and a whole host of additional features, we offer tools designed to empower developers. On top of these, our commitment to enhancing Web3 usability and constantly innovating reflects our dedication to the cause. With these tools, the road ahead becomes clearer, and the challenges of developing on the blockchain become less daunting. As the landscape of Web3 continues to expand, you can count on Chainstack to be there with you every step of the way. With Chainstack, you don't just build on the blockchain. You shape the future of Web3. Power-boost your project on Chainstack #### Unveiling the Chainstack Compare Dashboard At Chainstack, we believe that transparency is key when it comes to blockchain infrastructure. Whether you're deploying smart contracts, querying blockchain data, or processing transactions, you need uninterrupted, reliable access to your network of choice. That’s why we’re excited to announce the launch of the Chainstack Compare Dashboard — a real-time window into the reliability and performance of Web3 infrastructure across multiple blockchains. What is the Chainstack Compare Dashboard? The Chainstack Compare Dashboard is a real-time monitoring tool that tracks API success rates, response times, and overall performance metrics for blockchain infrastructure providers. https://youtu.be/EqwWyZ1HhfM Updated every minute, the dashboard gives developers and enterprises instant visibility into how well different providers handle real-world traffic across major blockchains, including: Ethereum Base Solana TON Why we built this dashboard When you're building on Web3, choosing the right infrastructure partner can make or break your project. A single failed API call can mean lost transactions, degraded user experiences, and ultimately lost revenue. We built this dashboard to: Bring transparency to blockchain infrastructure performance. Help developers understand the importance of success rates, not just speed. Showcase real-world conditions instead of theoretical benchmarks. With data collected from multiple global regions, the dashboard reflects how infrastructure performs under actual network conditions—not just in a controlled test environment. How the dashboard works Each blockchain-region combination runs as a separate function instance. The dashboard updates in near real-time using the following process: Function instances (data collection) run at scheduled intervals for Ethereum, Base, Solana, and TON. Data collection involves querying blockchain state updates, retrieving key performance metrics, and pushing structured data to Grafana. Vercel blob storage acts as shared state storage with no direct function-to-function communication. It stores recent data on recent blocks and transactions. Grafana Cloud integration ensures all metrics are processed and displayed efficiently using Prometheus with an emphasis on reliability and accuracy. Figure 1: Chainstack Compare Dashboard workflow Key metrics on the dashboard The dashboard tracks critical performance indicators for Web3 infrastructure across different chains, including: 1. API success rates The percentage of API requests that succeed—ensuring your DApp avoids failed transactions and broken user flows. Metrics are aggregated for both recent and historical requests, using fallback mechanisms where necessary. 2. Response times Measures how quickly an RPC node responds to a request under real-world traffic loads. Includes recent and historical data to capture a full picture of API performance. 3. State update process Collects and maintains blockchain state by querying the latest block, transactions, and randomly offsetting block lookups for historical analysis. Uses retry logic for handling RPC errors, invalid data, and timeouts, ensuring robustness. 4. WebSocket metrics collection Measures latency using subscription-based WebSocket methods where available. Currently supported for Ethereum and Base networks. 5. Transaction landing metrics (Solana) Tracks how quickly transactions land on the blockchain. Sends memo transactions. Figure 2: Chainstack Compare Dashboard Grafana workflow Comprehensive provider benchmarking We monitor major infrastructure providers, including: ProviderEthereumBaseSolanaTONAlchemy✅✅✅❌Chainstack✅✅✅✅✅Helius❌❌✅✅❌Quicknode✅✅✅✅TonCenter❌❌❌✅ Chainstack and Helius support both default and enhanced endpoints (Warp and Staked respectively) for transaction sending, ensuring optimal performance. A new standard in Web3 transparency At Chainstack, we don’t just talk about reliability—we show it. The Chainstack Compare Dashboard is fully accessible to anyone, allowing developers to: Compare provider performance in real time. Validate the reliability of their infrastructure choices. See how different chains and methods perform across providers. Whether you're running a high-traffic DApp or deploying mission-critical infrastructure, this dashboard helps you make informed decisions about your RPC provider. The Chainstack Compare Dashboard is now live and available to everyone. See how infrastructure providers stack up in real time—and make sure you’re building on the most reliable foundation. Power-boost your project on Chainstack #### Using Chainlink data feeds with Foundry 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 in JavaScript. This is something a lot of Solidity developers have been looking forward to for a long time since this will allow people to write smart contracts as well as their corresponding tests without having to switch between languages. Moreover, this would save people time and effort by them no longer needing to learn JavaScript as well as Solidity. If you're familiar with Hardhat, we have an article that covers the main differences between the two in both performance and developer experience. You can give that a read over here. A chainstack article comparing Hardhat and Foundry Installing 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: foundryup command in the Terminal 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 from here. 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. Setting up remappings To make it easier to work with Solidity files within VS Code, you need to install an extension that supports solidity within the workspace. Go to extensions in VS Code and install any Solidity extension. I am using the one by ‘Juan Blanco’. Next, go to settings and search for ‘solidity’. Scroll down to where you define the local path where your contracts and dependencies are stored. Foundry by default stores them under ‘src’ and ‘lib’ respectively. That is what you need to enter, and then save the settings and close the tab. This will tell VS Code exactly where to look for our contracts and dependencies. Settings in VS code Overview of Chainlink’s data feeds Chainlink is often described as a decentralized oracle network. What that means in practice is that a lot of independent node operators come together and inject data from the real world into blockchain smart contracts. We can use Chainlink’s data feeds to connect our smart contracts to the prices of real-world assets.We could theoretically use centralized data feeds just as well, but with that comes a risk of the single data source being compromised. Many DeFi protocols in the past have been attacked because of their oracle network being manipulated. This is much more difficult to do in the case of a decentralized oracle network where no single malicious node operator could impact the price of an asset in a major way. Latest price vs historical price Chainlink is most commonly used to retrieve the latest prices for cryptocurrencies, but the V3 interface also allows us to query older prices of supported tokens by using a previous roundID. So what is a roundID? Data in Chainlink’s data feeds are updated in terms of rounds. This means that every time the price of a token is updated, the round ID associated with the value also updates. We can use this unique value to allow our smart contract to fetch older prices of supported tokens from Chainlink. This older data is referred to as a ‘historical price’. Please note that not all numbers are valid round IDs, and the round IDs don’t necessarily increase linearly. They are a mathematical combination of two underlying values and can change dramatically when either of those values changes. In the next section, we will learn how to incorporate Chainlink’s data feeds into our smart contracts. Most popular Chainlink data feeds ETH / USD | Network: Ethereum Mainnet | Contract address: 0x5f4ec3df9cbd43714fe2740f5e3616155c5b8419 BTC / USD | Network: Ethereum Mainnet | Contract address: 0xf4030086522a5beea4988f8ca5b36dbc97bee88c ETH / USD | Network: Polygon Mainnet | Contract address: 0xf9680d99d6c9589e2a93a78a04a279e509205945 AVAX / USD | Network: Avalanche Mainnet | Contract address: 0x0a77230d17318075983913bc2145db16c7366156 BNB / USD | Network: BNB Chain Mainnet | Contract address: 0x0567f2323251f0aab15c8dfb1967e4e8a7d42aee Check all Chainlink data feeds available at https://data.chain.link/ Writing the Smart Contract Inside the src folder, create two new files: chainlinkInterface.solpriceFeeds.sol Inside chainlinkInterface.sol, paste the following code: // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; interface AggregatorV3Interface { function decimals() external view returns (uint8); function description() external view returns (string memory); function version() external view returns (uint256); function getRoundData(uint80 _roundId) external view returns ( uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound ); function latestRoundData() external view returns ( uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound ); } If you look carefully, this code is slightly unusual. We haven’t declared any of the variables we are using in our function declarations, nor are we actually defining our functions. They are just function declarations containing no code. Moreover, we have declared an ‘interface’ at the top of the code, instead of a ‘contract’. So what’s happening here? Interfaces in Solidity are different from contracts. An interface in Solidity is basically a list of functions with no definition. They are all of type external, meant to be inherited by a child contract. To use Chainlink’s data feed services, one must reference the AggregatorV3Interface. We will be using v-0.8 of the AggregatorV3Interface, which is the latest at the time of writing. This will help us know which functions to call in the actual contract. Speaking of the actual contract, open the newly created ‘priceFeeds.sol’ file. Inside, paste the following code- // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "./chainlinkInterface.sol"; contract PriceConsumerV3 { AggregatorV3Interface internal BTCpriceFeed; AggregatorV3Interface internal ETHpriceFeed; AggregatorV3Interface internal LinkpriceFeed; /** * Network: Goerli Testnet * BTC/USD Address: 0xA39434A63A52E749F02807ae27335515BA4b07F7 * ETH/USD Address: 0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e * LINK/USD Address:0x48731cF7e84dc94C5f84577882c14Be11a5B7456 */ constructor() { BTCpriceFeed = AggregatorV3Interface(0xA39434A63A52E749F02807ae27335515BA4b07F7); ETHpriceFeed = AggregatorV3Interface(0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e); LinkpriceFeed = AggregatorV3Interface(0x48731cF7e84dc94C5f84577882c14Be11a5B7456); } /** * Returns the latest prices */ function LatestBTCprice() public view returns (uint80,int) { ( uint80 roundID, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = BTCpriceFeed.latestRoundData(); return (roundID,price); } function LatestETHprice() public view returns (uint80,int) { ( uint80 roundID, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = ETHpriceFeed.latestRoundData(); return (roundID,price); } function LatestLinkprice() public view returns (uint80,int) { ( uint80 roundID, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = LinkpriceFeed.latestRoundData(); return (roundID,price); } /** * roundId is NOT incremental. A random number is not guaranteed to be a valid round ID. * You must know a valid roundId before consuming historical data. * * Two valid Round values: 18446744073709554683, 18446744073709555477 */ function ETHHistoricalPrice(uint80 roundId) public view returns (int256) { ( uint80 id, int price, uint startedAt, uint timeStamp, uint80 answeredInRound ) = ETHpriceFeed.getRoundData(roundId); require(timeStamp > 0, "Round not complete"); return price; } } Chainlink consists of multiple independent node operators that regularly update the real-world prices of assets like BTC and ETH. Each of the various data feeds have their own on-chain address. Any contract deployed on the blockchain can read the latest prices from these addresses. Same data feeds existing on different blockchains will have different addresses. Hence, it is important to note down the correct address of the data feed you want to use, according to the blockchain network on which the contract will be deployed. In our case, we will be fetching the latest price of BTC, ETH, and LINK in terms of US Dollars from Chainlink’s data feeds on the Goerli Testnet. To get the correct contract addresses, we need to go to Chainlink’s Ethereum data feeds page, and scroll down to the Goerli Testnet section.This is what it should look like: Chainlink Goerli Data Feeds All the blockchain networks, mainnets, or testnets have their own sections in Chainlink’s documentation. You can use that to incorporate the prices of any of the assets from those networks by referencing the correct proxy address on the correct chains.Here are some key concepts to understand- Heartbeat—The heartbeat of a data feed tells us how frequently the feed is updated. The lower the heartbeat, the more frequently it is updated.Deviation—Deviation percentage refers to the percentage shift in the price of the listed asset since the last time it was updated. For feeds that have a non-zero value listed as their deviation threshold, Chainlink will update the data feed as soon as the price shifts more than the listed percentage from its last updated value, even if it means updating the feed at a higher frequency than its heartbeat.Decimals—It is not very safe to directly work with decimals in solidity, for reasons that are beyond the scope of this article. Chainlink, therefore, returns to us an integer value for each of the data feeds. The decimal number tells us by how many numbers to the left must we shift the decimal point to get the correct result. Now that we understand the key concepts, let us quickly go over the ‘priceConsumerV3’ contract. We first import the all-important ‘AggregatorV3Interface’, which we stored in ‘chainlinkInterface.sol’. It is very important to import this file correctly since this is what enables us to conveniently use all the external functions implemented by data feeds. We then initialize three new objects of the AggregatorV3Interface, each of them specifically connecting to an already deployed aggregator contract. We get these addresses from Chainlink’s official documentation as explained above. We then create three functions to fetch three different prices from Chainlink, and we return two of the five values that are given to us by Chainlink. The ‘roundId’ is a unique value that changes every time a price feed is updated. We need the roundId of a particular price update to fetch the historical price from a price feed.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. You will probably receive a bunch of warning from Foundry since we don’t return most of the values in our LatestPrice functions. Foundry sometimes takes a while to resolve the chainlinkInterface import into the priceFeeds file. Hence, the forge build command may give an error the first couple of times.If that happens, wait for a couple of minutes, and run the command again. Scripting in Foundry Once our contracts have been successfully compiled, we need to create a simple script to deploy our contract. Under the scripts folder, create a new file by the name of ‘priceFeedsScript.s.sol’.Inside the file, paste the following code- // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.0; import "forge-std/Script.sol"; import {PriceConsumerV3} from "src/priceFeeds.sol"; contract ChainlinkScript is Script { function setUp() public {} function run() public { vm.startBroadcast(); PriceConsumerV3 prices = new PriceConsumerV3(); 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 Foundy. Secondly, we import our smart contract. Scripts are by default executed within the function run(). The broadcast functions record any transactions happening between the two calls and record them to a special file.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 the dotenv File To correctly deploy our smart contract on the blockchain, we need to pass some environment variables to Foundry. This can be done directly through the command line while deploying the actual contract, but it is better to do so through a dotenv file.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 you can use 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. You can get started for free here.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 one of your accounts that have 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 like this- GOERLI_RPC_URL=https://mc-12.p123yippy.com/12ase525c5012 PRIVATE_KEY=dlhj12342kjh4eslkh1pq4h1324kqwrekhwe ETHERSCAN_KEY=SDJKASL232KJ3SLKJDSALKJ234G2CAEWYND 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/priceFeedsScript.s.sol:ChainlinkScript --rpc-url $GOERLI_RPC_URL --private-key $PRIVATE_KEY --broadcast --verify --etherscan-api-key $ETHERSCAN_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- Contract deployed and verified through Foundry Open the goerli.etherscan URL, and open the contracts page. You will see that your contract has been already verified, and that you can call your functions directly from the contracts page. Your browser should look something like this- The verified contract on Etherscan Conclusion In this tutorial, we used Foundry to compile and deploy a smart contract to the Goerli Testnet. The contract I deployed can be found here. Feel free to check out Chainstack’s official blog for some other cool tutorials.Happy coding! #### Web3 appchains, the future of DApps As Web3 attracts more users across the globe, one thing is certain—increased demand for network resources leads to lower performance and higher transaction fees on the network. This can be evidenced by the many expensive and failed transactions that occur during a popular NFT drop, or on a DEX in a bull market. And while as much as we embrace Web3 and its potential, this is one aspect of it that we would prefer to do without. Modern problems require modern solutions, and appchains aim to be just that. The limitations of using a public blockchain as its base layer for DApps can now be mitigated with their own dedicated chains. As we progress further into Web3 territory, appchains are becoming the thing that could take us to the next stage of adoption. Here at Chainstack, we are excited to offer this product to all the BUIDLers out there. What are appchains? With Web3 on the rise, developers need a streamlined method to create applications that will shape the digital future. However, without dev-friendly tools and infrastructure for their projects, these revolutionary ideas remain out of reach. Developers need access to specialized resources so they can unleash their full creativity with every innovative idea. Appchains are another step forward in Web3 allowing developers to BUIDL and scale DApps on application-specific blockchains. Each application operates as its own specialized blockchain, providing a strong foundation with improved security and scalability. With other factors, they can also provide interoperability with established infrastructure. Transactions on appchains are processed out of their individual mempool, and gas fees for transactions can be as low as the developer decides them to be. These two factors enable appchains with the ability to process transactions much faster than any L1 can. These advantages in speed and costs with DApps built on appchains have the potential to bring in the next wave of Web3 users. Appchains provide a powerful platform for DApps, allowing dedicated resources for individual applications that maximize efficiency and performance. With each app having its own autonomy on an independent chain, there's no need to battle over shared computational or storage resources on the network—freeing up developers to focus solely on delivering the best possible user experience. Architecture of appchains The architecture of an appchain is flexible and modular in its design, as it gives developers the freedom to customize the chain and have total control over its mechanics. What this means is that the appchain’s economics, governance models, and consensus mechanisms are all determined by the developer—it is possible to create a chain for virtually any use-case scenario. The appchain’s architecture can be broken down into several layers: The Network Layer handles communication between different components ensuring secure transactions across nodes present in a peer-to-peer (P2P) network along with other networking technologies used by them. The Application Layer provides an interface to interact with the chain through libraries like web3.js and ether.js, SDKs, or APIs while also providing users access to data stored by it via databases or indexing systems within its Data Layer. The Data Layer allows for efficient storing and management of information. It contains databases, data storage solutions, as well as specialized indexing systems to ensure optimized access and organization. The Consensus Layer ensures all participants in the appchain agree on its state using consensus algorithms such as proof-of-work or proof-of-stake. The Smart Contract Layer contains smart contracts to define rules and logic for a specific application while also executing business logic on it. Figure 1: The architecture of an appchain Why use appchains? Appchains have a modular and decoupled architecture. This offers a variety of advantages that make them an attractive choice to consider when exploring blockchain solutions. From scalability and interoperable features to lower risk of vulnerabilities, appchain technology is revolutionizing the way we utilize distributed ledger technologies. Scalability Unlike traditional blockchains, which may become congested and slow due to heavy traffic, appchains are designed to be highly scalable with increased transaction volume and faster processing speeds per second—providing more efficient access for a larger number of individuals simultaneously. Flexible fees Appchains provide a more cost-efficient way to conduct transactions. With flexible fees, these chains provide businesses and individuals with new ways to manage digital transactions more cost-effectively. This means that everybody can now use digital payment services for everyday purchases in an easy and economical way. Through the convenience of appchains, users can quickly and conveniently send and receive funds with ultimate flexibility. Customization Appchains offer a new level of functionality to conduct secure and reliable transactions in Web3 by creating individual, purpose-built chains for different types of activities—such as supply chain management or identity verification. This opens up previously unimaginable opportunities in many industries across the world. Security Appchains offer a robust security solution for blockchain networks and help organizations keep sensitive information secure by managing it on separate chains. This not only helps preserve the integrity of information but also adds an extra layer of security to the network to defend from malicious threats. Privacy Appchains provide users with extra security and privacy when making transactions. By operating on a private chain, these transactions are kept out of sight from the rest of the network. This helps keep sensitive information secure and personally collated. No block or associated data needs to be broadcast onto the network—ensuring transferred data remains between the user and the network. This creates an extra layer of discretion that further promotes user privacy and data ownership. When it comes to Web3, appchains provide developers with numerous advantages over public L1 networks. This makes them a great alternative for developing powerful applications. They offer developers the enhanced ability to create applications on customized networks tailored specifically to their needs—and with dedicated access at a fraction of the cost. This improves accessibility and user-experience amongst all users. How can appchains be used? As technology improves and Web3 solutions become widely available, the ways in which they can improve business and lifestyle have countless possibilities. We have only scratched the surface with this technology, and some of those possibilities are rapidly becoming realities. There are already various use cases driven by Web3 innovation on the horizon, along with solutions to help bring new and innovative possibilities to life. Some of the traditional Web3 uses would be gaming, NFT marketplaces, DeFi, and metaverse projects, but here are some use-case scenarios for more traditional industries. Financial systems Appchains enable a new form of highly secure and resilient financial applications. These innovative tools make it possible to build cryptocurrency exchanges, peer-to-peer lending platforms, and a myriad of other secure applications with reduced risks and high potential returns. Businesses of all sizes can leverage this cutting-edge technology to venture away from traditional banking models toward the benefits of blockchain technology. Such exciting new advancements have incredible potential for transactions, asset tracking, micropayments, and more. The following are some use cases where blockchain technology can be adopted in the banking and financial industries: Stock exchange and share trading Crowdfunding and investing Syndicated loans Credit reports Accounting, bookkeeping, and auditing Insurance Supply chain management Appchains are a powerful tool to create more efficient and transparent supply chain management systems. With improved visibility, these solutions can track the journey of goods from their origin to their destination. It enables real-time tracking of this critical information throughout the entire system. This results in greater control and oversight for businesses in multiple segments. Enterprises are thus able to gain visibility into their operations that may have been previously out of reach. Appchain technology has become the go-to solution for organizations looking to increase transparency and accuracy along the supply chain. With access to oversight throughout various steps, appchain solutions offer increased security and reliability from source to destination. Here are some use cases of blockchain on the rise in supply chain management: Synchronize logistics data Track shipments Automate payments Verify source of materials Protect from tampering Identity verification Appchains provide the underlying technology for decentralized identity and credential verification, revolutionizing how organizations securely protect and access, validate, and exchange data. Leveraging an immutable ledger system, entities can be verified without any third-party interference. These verifications can have a multitude of applications that simplify data governance and enhance security in numerous scenarios. The blockchain can provide some solutions in identity verification such as: Digital credentials Digital health pass Immutable documentation Trustless background checks Fraud prevention Voting systems Appchains provide a secure and transparent platform for voting systems. This technology is highly dispersed, making it resistant to tampering and fraud. Utilizing the principles of blockchain technology, appchains allow for more confident votes with greater assurances of security and accuracy. With this platform, elections can be organized with unprecedented reliability thanks to blockchain's capacity to verify credentials and securely manage digital assets. These are some ways we can see voting systems impacted by the blockchain: Digital voting systems Real time votes and polls Fast, secure, and secret ballots Automatic total vote calculations Predictive markets Appchains can be used to develop decentralized platforms for prediction markets. These complex platforms offer users the ability to buy and sell predictions about potential future events. An array of predictions from different markets can provide a comprehensive overview of hypothetical outcomes. With appchains, it's possible to get a unique insight into what might transpire in the future. The following are some ways blockchain can facilitate in predictive markets: Determining odds of an event Collecting pool of funds Paying out the winnings Which appchains to use Next, we'll take a look at four popular appchains—Avalanche Subnets, Polygon Supernets, and StarkEx Apps—and compare how they work and what they offer. Avalanche Subnets Avalanche Subnets are sovereign networks of validators that work together to reach consensus on the state of one or more blockchains. The Primary Network is a special Subnet that houses Avalanche’s three built-in chains: Platform Chain (P-Chain), Contract Chain (C-Chain), and Exchange Chain (X-Chain). Network security is at the subnet level and can consist of multiple VMs. Each Subnet validator must also validate a node on the Avalanche Primary Network. VMs on Avalanche make it easy for developers to create application-level logic without having to worry about networking or consensus protocols. With the power of the Avalanche Virtual Machine and the EVM compatibility of the C-chain, Subnets provide a range of advantages including independent token economics, compliance requirements for validators, application-specific requirements for validators, support for private blockchains, separation of concerns between different blockchain networks, and incentives provided by subnets owners to attract Avalanche validators. Figure 2: The Primary Network is a special Subnet; Source Avalanche Polygon Supernets Polygon Supernets is a blockchain stack designed to simplify and accelerate blockchain development. It utilizes the Istanbul Byzantine Fault Tolerant (IBFT) consensus mechanism supported in two methods as proof-of-authority (PoA) and proof-of-stake (PoS). Validators are vetted by Polygon and must stake Matic tokens on the mainnet before they can validate the network. They are instantly penalized with the staked amount for misbehavior. This is to achieve maximum network security and protect against malicious activities by any dishonest nodes in the network. Supernets have built-in EVM compatibility using Polygon Edge, which allows Ethereum developers to easily port their smart contracts. There is a plug-and-play compatibility with existing Web3 tools such as Solidity, Hardhat, ether.js, etc. This provides developers with a smooth integration into the network without modifications. Additionally, this provides interoperability with other EVM compatible blockchains. Figure 3: The architecture of a Supernet; Source Polygon Figure 4: The modular Edge architecture; Source Polygon StarkEx Apps StarkEx is an L2 scaling solution on the Ethereum network, and delivers ultra-fast performance and lower transaction fees. It’s designed for creating DEXs and DeFi applications that need to be built quickly with unparalleled scalability. It harnesses the power of zk-rollups, an advanced zero-knowledge proof technology that allows for multiple transactions to be packed into a single one; and reduces bottlenecks caused by excessive demand. This expedites network throughput and keeps gas fees low, allowing users to enjoy faster than ever transaction confirmation times. StarkEx is an ideal platform for businesses and investors, providing a secure and decentralized environment to trade both fungible and non-fungible tokens (NFTs). Using Ethereum blockchain, all transactions are fully auditable. In addition, advanced financial instruments can be created using smart contracts capabilities—enabling automated trading strategies or complex price mechanisms with ease. Figure 5: StarkEx high-level overview; Source Starkware Figure 7 High-level application architecture; Source Starkware The aim of leveraging scalability solutions for blockchain networks is to improve performance and transaction speed at a lower cost. Solutions such as subnets, sidechains, and specialized networks have been devised with this goal in mind. They all serve to facilitate efficient transfers between users on distributed systems. Are appchains the future? Trends in general can be difficult to predict, and Web3 is impossible to predict. However, the internet is an evolving lifeform, and Web3 is its next phase of progression. That said, for Web3 to be more accessible and easy-to-use for average daily users (like in Web2), there needs to be more done to make transacting on the network faster and cheaper. Until now, Web3 developer options have been limited to using public chains where resources are scarce in times of high activity. But now with appchains, their flexibility and power make them a game changer moving forward. With blazing-fast and low-cost transactions, DApps built on appchains offer the user experience that we envision when we think of Web3 and its potential. When you can control every aspect of your chain, then there is no limit to what you can BUIDL—Chainstack has everything you need to get started now! Power-boost your project on Chainstack #### Web3 DApps: From architecture to interaction Introduction In this article, we'll dive into the Web3 Decentralized Applications, or DApps, architecture, and you will also get to build one with a bonus tutorial at the end. By now, you’ve likely heard of Web3 and its potential to revolutionize the internet as we know it. The demand for Web3 DApps is continuously increasing over time. A thorough understanding of Web3 applications and how they work will undoubtedly be helpful for developers as they build the internet of the future. DApps run on the blockchain as part of a distributed or decentralized peer-to-peer network. The network participants, also known as nodes, are connected in public and often open-source, aiming to reduce the influence of centralized control over the network. Three main components The internet that has shaped our modern lives for better or for worse until the arrival of blockchain technology is known as Web2. It is commonly referred to as the read-and-write web, and its architecture consists of three main components:  Frontend – The user interface (UI) of an application. It consists of elements such as navigation menus, sidebars, and other elements visible to the end user. The front end of an application can be written in HTML, CSS, and JavaScript, or any other such frameworks like React, Vue, and Angular. Backend – Where the underlying application logic is defined. It is used to perform tasks such as authentication, notifications, and pretty much any form of automation you can imagine. The application backend is typically written in Python, Go, or Ruby. Database – A storage place for all your data. This is where the application keeps and fetches user information and other relevant operational data from. You will find MongoDB, SQL, and MariaDB as some of the go-to database choices. The Web3 architecture DApps, in contrast, however, have an entirely different architecture which consists of a wider range of elements. And by the time you finish this article, you should have gained a much deeper understanding of Web3 applications and how they work. So, let’s start with the frontend component. DAPPs' frontend Both Web2 and Web3 frontends share similar characteristics. Typically, developers use the same web languages (HTML, CSS, and JavaScript) and frameworks (React, Angular, etc.) to build a DApp’s frontend as they would for a standard web app. Even so, there are other aspects that differ when it comes to functionality. As you move forward with this article, you will gain deeper insight into just how these components work.  Figure 1: DApp interaction process Blockchain  Unlike their Web3 counterparts, Web2 applications do rely on centralized servers or databases to store data. These can be, for example, AWS, Google Cloud Platform, and Microsoft Azure as some of the most notable alternatives. Instead of centralized networks, blockchain technology is used to create apps on a distributed or decentralized state machine. The successful operation of such a machine is supported by the very same nodes that participate within the network. But unlike typical Web2 networks, there is a greater degree of anonymity and decentralization to be found here. A blockchain is a data structure that stores a particular state, such as wallet balance and transaction data. Since the level of decentralization is much higher in a blockchain structure, the integrity of the network is better protected from hostile actions, as there is no central point of failure that holds the keys to the kingdom. This provides an extra layer of security that renders activities such as hacking or altering data mostly unfeasible. Additionally, the network’s users typically have a greater say in chain governance, as they maintain some level of ownership instead of a single entity doing so.  As mentioned above, you can store data on the blockchain but cannot alter or remove any data from it in general.  Some of the most notable blockchain protocols are Ethereum, Polygon, and Optimism, among many.  Figure 2: blockchain interaction process Smart contracts for DApps Smart contracts provide the functionality to Web3 DApps. They are programs defined by business logic that run on the blockchain. They respond to data and execute when a specific set of conditions is met. The potential use cases for smart contracts are robust, and they are an integral part of Web3 applications. Solidity, Vyper, and Rust are common languages for smart contracts. The following code shows the example of a simple "Hello World" smart contract in Solidity. // SPDX-License-Identifier: MIT pragma solidity 0.8.13; contract HelloWorld { // This function can be called by anyone, does not change the state of the blockchain, and returns a string. function sayHelloWorld() public pure returns (string memory) { return "Hello World"; } } EVM (Ethereum Virtual Machine)  The Ethereum Virtual Machine (EVM) is the Ethereum smart contract runtime environment. Its purpose is to execute code like a typical program but simultaneously across a wide range of network participants. In doing so, it essentially becomes a global computer that uses nodes as hardware and smart contracts as its software. High-level programming languages, such as Solidity and Vyper, are used to write the executable code that runs on the EVM. And while Solidity code is human-readable, it turns into bytecode during interactions, so the machine that reads it can process it more efficiently. The Ethereum ecosystem owes its entire success to the EVM, which brought the concept of programmable money to the greater public.  You can learn more about the EVM and Ethereum clients by exploring our dedicated article on the Geth and Erigon clients. Figure 3: EVM within a blockchain interaction process Communication between frontend and smart contract  Unlike many Web2 apps, the front end must interact with a node to communicate with the smart contract instead of using REST APIs or GraphQL. The term "Node" refers to a computer that runs Ethereum software and interconnects with other nodes in a peer-to-peer network to help secure it. Find a deep dive into what nodes are by exploring our Blockchain node providers: What, how, and why guide. Setting up a node on your own can be a very complex, time-consuming, and expensive process. Because of this, blockchain node providers such as Chainstack play an important role in alleviating the burdens of taking care of everything yourself.  Chainstack provides fast and scalable nodes as a service, which allows you to set up a node within minutes and stop worrying about its maintenance. This is also one of the primary reasons why many notable DApps choose to run their services on platforms like Chainstack.  You can deploy a node and access your RPC endpoint in three simple steps:  Sign up on Chainstack and set up an account Deploy a node on Chainstack Add the new Chainstack node endpoint to your MetaMask Figure 4: node provider within a blockchain interaction process  Providers supply Remote Procedure Call (RPC) and WebSocket (WSS) endpoints. Users can access data on the blockchain and submit transactions to various networks. An RPC is the most user-friendly API to communicate with servers and run programs remotely. In addition, DApps require RPC nodes to interact with the blockchain, making them a critical piece of technology.   As mentioned above, you can read data from the blockchain using RPC, but you need to sign a message to store any data on the blockchain. This means that users must use their private key to perform such an operation. Herein lies the role of an externally owned account, or EOA, such as the MetaMask wallet. It is one of the most widely used blockchain wallets, making it easy for users to interact with DApps, access vital key management tools, and sign transactions.  Usually, DAPPs interact via ‘Web3 libraries.’ These tools allow you to use languages like JavaScript and Python to communicate with a node and retrieve data, interact with smart contract methods, and send transactions. Using these libraries is the most efficient way to implement your DApp logic while being able to create user-friendly interfaces.  The most common JavaScript libraries are web3.js and ethers.js, while the web3.py library does so for Python.  Figure 5: wallet within a blockchain interaction process  Storage  Storage also plays a vital role in DApps. However, since storing images, videos, or any other kind of file in a blockchain is not ideal as it is expensive and not scalable, many users use decentralized storage services like IPFS, Arweave, and others instead.   IPFS is a decentralized file system for storing and accessing data. The IPFS protocol distributes and stores data in a peer-to-peer network rather than doing so within a centralized database.   On the other hand, Arweave enables the creation of an immutable decentralized database, allowing anybody to assess and debate the data's validity. Moreover, it permanently stores files on a vast network of machines.  Figure 6: storage within a blockchain interaction process Although most decentralized applications utilize this architecture because it is adequate when your application grows, it is difficult for blockchains like Bitcoin and Ethereum to execute thousands of transactions per second, which makes them slow and expensive. This is where layer 2 solutions are helpful; they assist in scaling the already existing blockchain.  Scaling The phrase "Layer 2", or L2, refers to a protocol based on an existing blockchain and addresses the scaling issues of Layer 1 (L1) blockchains. Many scaling solutions – layer 2 chains like Polygon, Optimism, and Arbitrum exist and can serve as an extension to Ethereum to ease its network load and make transactions both faster and cheaper.   Although layer 2 chains would do most of the work this way, layer 1 still serves as the main chain and offers additional security. In contrast, layer 2 offers quick transactions, low transaction fees, and the ability to process thousands of transactions per second.  Figure 7: layer 2 within a blockchain interaction process Build simple DApps  Now that you have a good understanding of the DApps structure, it’s time to build one, so you can get some hands-on experience. This time you will create one using “vanilla” tools like HTML and CSS for the front end. The DApp interacts with the smart contract using a JavaScript file via the ethers library.  The DApp you’ll be building leverages the powerful data-storing capabilities of blockchain technology, and although this will be a simple project, it will help you practice the fundamentals.     We'll build an application that allows users to connect their MetaMask wallet to the page, input a string in a text box, which can be a word, number, or sentence, and save it in the smart contract as a variable using MetaMask to sign the transaction. After that, only that same address can retrieve the saved string, which is displayed on the screen as an alert box.  You can find the full code base with explanations in this GitHub repository.   Requirements Before starting, you must consider some basic requirements for the webpage.   To serve the page, you can use a simple Node.js server. So, let's start by installing Node.js and the lite-server library to see the page.   Follow these instructions:   Install Node.js (download and instructions) Install lite-server (with NPM in a terminal/command prompt) npm install -g lite-server Now, you have the tools to serve a webpage on localhost.  Create a new project directory, clone the repository, or create each file separately and paste the code manually Serve the webpage via terminal/command prompt from the directory that has index.html in it and run:   lite-server Now, your webpage will be available on http://127.0.0.1:3000/, and you can view and use it from your browser.  As a development environment, I recommend using Visual Studio Code. The smart contract It’s finally time to dive into the code. Let’s start with the smart contract. The logic is simple:  A mapping associates the address saving the string with it A function named saveString takes a string as the parameter and saves the string into the mapping associating it to the address calling the function A function named getString that allows retrieving the saved string // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract SaveString { // This mapping allows to associate an address with a string mapping(address => string) public savedStrings; // Function to save a string into the mapping with the address calling the function function saveString(string memory _string) public { savedStrings[msg.sender] = _string; } // Function to retrieve a string from the mapping, based on what address is calling it function getString() public view returns(string memory) { return savedStrings[msg.sender]; } } Create a file named SaveString.sol in the project’s directory. To keep it simple, you can test and deploy the smart contract using the Remix IDE. You will find a section dedicated to this in the repository. In a more advanced setting, you can use a smart contract developing a framework like Foundry or Hardhat, Brownie, or Ape.  If you don’t want to deploy a new contract, you can use the smart contract that we already deployed and verified on the Fantom testnet.   To interact with it, you’ll need some Fantom testnet tokens (FTM); you can get some from the Fantom faucet.  The front end  Once you set up the smart contract, we can go ahead and build the front end. As I mentioned, we’ll build it with the basic tools.  Start by creating an HTML file named index.html and paste the following code into it.  <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <link rel="stylesheet" type="text/css" href="./style.css" /> <script src="https://cdn.ethers.io/lib/ethers-5.2.umd.min.js" type="application/javascript"></script> <script src="script.js"></script> <title>Save a string on the blockchain</title> </head> <body> <div class="parent"> <div class="div1"> <h1 class="center">Save a word on the blockchain</h1> <h2 class="center">This DApp allows you to save a word, a sentence, or a code on the blockchain.</h2> <p>Blockchain technology is more than just DeFi applications, the possibilities are endless, and this website was created to demonstrate that. Blockchains are a great system to store information.</p> <p>The smart contract linked to this website allows an address to store a sentence, can be a word, a code, or anything else you would like to save. And only that same address can retrieve and read that information.</p> <p class="center">Smart contract address <a href="https://testnet.ftmscan.com/address/0x0287f57a1a17a725428689dfd9e65eca01d82510#code" target="_blank">0x0287f57A1a17a725428689dfD9E65ECA01d82510</a>, on the Fantom Testnet</p> <p class="center">Get some test FTM here: <a href="https://faucet.fantom.network/" target="_blank">Test FTM faucet</a></p> <h3 class="center">Warning!</h3> <p><b>Keep in mind that this DApp is created for educational purposes, it is not designed with any security measure, and because of the blockchain's nature, everyone can see the information you pass through the functions. You should avoid storing actual sensitive information, the idea is just to show a use case.</b></p> <p class="center">Any time you save a new string from the same address, the previous one is overwritten!</p> <p class="center">The areas to interact with are divided by very distinct colors.</p> </div> <div class="div2"> <h3>Click the button to connect MetaMask to the website</h3> <button onclick="connect()">Connect Wallet</button> </div> <div class="div3"><label>Input sentence to save </label> <input type="text" id="input" /><br> <button onclick="saveString()">Save Sentence</button> </div> <div class="div4"> <label>Get your sentence back</label> <button onclick="getString()">Retrieve Sentence</button><br> </div> </div> </div> </body> </html> If you look in the <head> section, you will notice this line:  <script src="https://cdn.ethers.io/lib/ethers-5.2.umd.min.js" type="application/javascript"></script> This injects the ethers.js library directly into the browser without installing extra dependencies. Note that this is good for our testing/learning environment. Still, it is not recommended to do so in production environments as it could expose some security risks. We also import the script.js file and the style.css file, which we’ll build next. <script src="script.js"></script> <link rel="stylesheet" type="text/css" href="./style.css" /> The <body> of the HTML file holds the page's structure. This example is simple overall; it has a few paragraphs explaining the DApp, an input field, and three buttons. The styling The front end would already be entirely functional, so this part is technically optional, but we can add some styling to make it more organized. Please note that my styling is the opposite of fancy. This is on purpose as I want to mainly highlight the different sections. In the project’s directory, create a file named style.css and paste the following: body { text-align: left; font-family: Arial, Helvetica, sans-serif; } .center { text-align: center; } .parent { display: grid; grid-template-columns: repeat(2, 1fr); } .div1 { grid-area: 1 / 1 / 2 / 3; } .div2 { grid-area: 2 / 1 / 3 / 3; background-color: #FFD700; height: 120px; display: flex; justify-content: center; align-items: center; flex-direction: column; } .div3 { grid-area: 3 / 1 / 4 / 2; background-color: DodgerBlue; height: 150px; display: flex; justify-content: center; align-items: center; flex-direction: column; } .div4 { grid-area: 3 / 2 / 4 / 3; background-color: Tomato; height: 150px; display: flex; justify-content: center; align-items: center; flex-direction: column; } button { width: 150px; padding: 8px; border-radius: 10px; } label { padding: 20px; } This will apply the styling to the page, and if you try to run it in your browser the page will look like this. Front end appearance You can serve it in the browser by running lite-server in the terminal. The JavaScript logic Now it's time for the important part, so far, we have a working front end, but all these nice buttons don’t do anything yet. Let’s fix that. Create a file named script.js and paste this code: // Smart contract address const contractAddress = "0x0287f57a1a17a725428689dfd9e65eca01d82510"; // Smart contract ABI const contractABI = [{ "inputs": [{ "internalType": "string", "name": "_string", "type": "string" }], "name": "saveString", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "getString", "outputs": [{ "internalType": "string", "name": "", "type": "string" }], "stateMutability": "view", "type": "function" }, { "inputs": [{ "internalType": "address", "name": "", "type": "address" }], "name": "savedStrings", "outputs": [{ "internalType": "string", "name": "", "type": "string" }], "stateMutability": "view", "type": "function" } ] // Identify the accounts and connect MetaMask to the website. async function connect() { const provider = new ethers.providers.Web3Provider(window.ethereum, "any"); // Prompt user for account connection await provider.send("eth_requestAccounts", []); // define the address signing the transactions (account selected) const signer = provider.getSigner(); console.log("Account:", await signer.getAddress()); // create smart contract instance usinf address and ABI smartContract = new ethers.Contract( contractAddress, contractABI, signer); } // call the saveString function from the smart contract, use the input field as parameter async function saveString() { const string = document.getElementById("input").value; smartContract.saveString(string); } // call the getString function from the smart contract async function getString() { const getSPromise = smartContract.getString(); const string = await getSPromise; alert("Your saved string is: " + string); } Note that the smart contract address here is the same as the contract we already deployed on the Fantom testnet. So, replace it with the address of your smart contract if you re-deployed it. Here you will use the ethers.js library to “connect” the smart contract to your front end. The first section initializes the contract address and ABI. ABI stands for Application binary interface, and you need it to be able to interact with a smart contract. The ABI describes variables and functions in the contract, so the ethers library knows what to do with your instructions. You can find the ABI in Remix if you used it to compile the contract. If you used a framework like Hardhat, it would have generated an ABI file when you compiled the smart contract. ABI location within the Remix IDE The first function allows the page to connect to MetaMask and use it to interact with the smart contract. In this case, it injects a provider called ‘window.ethereum’ in the browser so you can use MetaMask. Then you have the two functions to save the string on-chain and retrieve it. Again, the repository has a deeper explanation of how those functions work. This was the last step! Now your project structure should look something like this: Project’s directory | |_ index.html |_ style.css |_ script.js |_ SaveString.sol Note that the smart contract file does not need to be in the directory, but all the other files do. Now serve the page with lite-server and play with your new creation. Click Connect Wallet and follow the instructions on MetaMask Input the piece of information that you want to save in the smart contract, which can be a word, a number, or a sentence Click Save Sentence and complete the transaction from MetaMask Click Retrieve Sentence to show an alert on the screen containing the word you saved from that address Try to save multiple words from different addresses, so you can see how each piece of info saved is based on the address!  Note that if you use the smart contract already deployed, you'll need to use the Fantom testnet and ensure that your wallet has the Fantom testnet selected. Conclusion This is it for this article. I hope that you now have a good understanding of Web3 applications and how they work. You also spent some time building a real DApp using a basic structure.    The next step would be to learn more about building DApps using tools like React and Next.js!  👋 Thanks for reading; see you next time.  Power-boost your project on Chainstack #### Web3 stack - a rookie Web3 developer's guide As a rookie developer making your first steps into BUIDLing on Web3, navigating the space can be quite a tough nut to crack. With decentralization being paramount across the landscape, there is a degree of fragmentation that also comes with it. And it is exactly this fragmentation that turns your humble beginnings into an absolute nightmare, tossing you into the deeps with no map to guide you: What node do I need to deploy? Which blockchain protocol should I go for? How can I scale my blockchain operations? What is the best tool for Web3 developers? These are just some of the tough questions you will be left answering on your own, or at best what you will be sifting through search engine results, Stack Exchange and Stack Overflow posts. But we have good news for you—you can forget about all the endless digging for the resolution of your queries. Just tag along with us, as we take a closer look into the Web3 stack and do so with accessible language anyone can understand. That being said, let’s dig into the details: Defining the Web3 stack In its essence, the Web3 stack is composed of five main layers in the following order from bottom to top: Hardware and infrastructure, where nodes and virtual machines are; Data, which holds the keys, hashes, and transactions; Network, supporting the peer-to-peer (p2p) interaction; Consensus, determining how agreement between nodes is reached; Presentation and application, housing all BUIDLing tools and decentralized applications (DApps). These refer to the architecture itself above anything else and what makes things tough for many is that the same Web3 stack can also be commonly seen arranged in a different set of layers–Layer 0 (L0), which makes blockchain a reality, Layer 1 (L1), also known as the foundation layer, Layer 2 (L2), or supporting technology, and Layer 3 (L3), where DApps live. And even if we are just in the beginning, these tongue-twister lists of layers can already cause great confusion. That is why to keep things relatively simple and easy to digest, we will be referring to both sets of layers, so you don’t get lost along the way. That being said, let’s do a quick recap with the table below, and wait patiently for a more detailed review of the examples in the segments to come: Figure 1: Web3 layers 0 to 3 examples  Layer 0: Hardware and infrastructure for Web3 This is the layer that makes everything Web3 possible. Here you will find all technical factors, responsible for having blockchain technology available in the first place. These include internet, network adapters, such as WAN, LAN, and Ethernet, nodes, and the various connection protocols like TCP/IP, RPC, WebSocket, and others. While most other members of this layer are out of the scope of this guide, nodes are not. The nodes in a blockchain network serve the purpose of communicating messages between devices in order to share resources and achieve a common goal. These can be, for example, updating your wallet’s balance, validating the hash of new blocks, and other such operations. In this category, Node-as-a-Service (NaaS) providers can also be found. They are responsible for running distributed node clients behind the scenes for you, so you don't have to. These can be very handy, especially considering just how difficult running your own node(s) successfully can be. Want to learn more about nodes, and NaaS providers? Check out our detailed article on the topic here: Overcoming infrastructure challenges One of the biggest challenges for BUIDLing on Web3, especially for rookie developers is far from being down in the list. Rather it is at the start of the stack—on L0 and is related to infrastructure above anything else. If you have had the chance to take a closer look at the article mentioned above, you will already have the understanding that running a node, and specifically a set of them can be quite a cumbersome process that can drain the absolute life of you. Just in case, here’s the TL;DR: The synchronization process that is a must for every node deployment takes days or weeks. To have a healthy node, you will need to perform regular maintenance (also takes ages). Issues, such as node desync and timeout happen often and put a stop to everything. The more nodes you run, the harder it gets to keep them healthy. The more traffic your network serves, the more these issues compound. That is why, as part of an effective BUIDLing process, it is imperative to shift this enormous responsibility and time-sink to someone whose sole purpose is doing it—NaaS providers. Unless you are ready and willing to invest in a large DevOps team that can administer your setup proactively and a set of powerful servers to support the nodes themselves, there is little point in doing it all yourself. Fortunately for you, starting out with a node provider is a piece of cake. Don’t know how? Check out our quick start guide for the Chainstack platform: Layer 1: Blockchain data, network, and consensus Layer 1 is typically what you’d imagine when you hear the word “blockchain.” Here you will find all technology and its application to make the foundational networks like Bitcoin and Ethereum. But there’s more to it than that, as L1 also holds the full range of factors that make these networks possible. That is why it is not uncommon to see the various hashing algorithms, authentication methods, and Merkle tree implementations in this layer just as well. Examples of hashing algorithms include SHA-256, responsible for Bitcoin’s hashes, and Keccak-256 that is behind the algorithm of Ethereum. Figure 2: Web3 Layer 1 - Network Additionally, you can find consensus mechanisms here as well, such as PoW that powers Bitcoin and the current Ethereum network, PoS securing the upcoming Ethereum 2.0 after the Merge, Polygon, or Tezos, as well as Byzantine-Fault Tolerance variants (BFT), Proof-of-Authority (PoA) propagating the Fantom, Quorum, Multichain, and BNB Smart Chain among others. EVM vs non-EVM chains This is the time to ask yourself the big question—what blockchain protocol do I want to build upon? A popular choice among the large majority of developers out there is Ethereum. The reasons? It is one of the oldest protocols, supports smart contracts with no strings attached, and has a significant knowledge base, as well as community. What more could you ask for? But say you want to go off the beaten path and try something else. What options are there? To put it simply, there are two—Ethereum Virtual Machine (EVM)-compatible chains and non-EVM ones. As the name suggests, Ethereum is an EVM-compatible chain, but so are plenty others, like BNB, Avalanche, Polygon, and Fantom. So even if you want to stick to EVM, you don’t necessarily have to BUIDL on top of Ethereum. On the other hand, there are also non-EVM-compatible chains, such as Solana, and NEAR. Such protocols aim to break the constraints of EVM chains and do that by means of novel blockchain structures. The benefits here are that such chains are usually shipped with scalability in mind, which makes them perfect for BUIDLing products that tend to generate a high throughput of transaction volume, measured in Transactions Per Second (TPS). Only issue with this, however, is that you will be unable to use your non-EVM assets on an EVM chain. But why not have your cake and eat it too? Turn this into reality with our tutorial on creating a bridge between the two: Layer 2: Chain extension & scalability Now, this is where things get tricky. While L1 deals with foundational networks, L2 aims to build on top of that layer to introduce relevant improvements to the overall operation of the chain it is placed upon. This can be anything from offering scalability solutions to extending the basic functionalities of a particular blockchain network. These L2 technologies can be, for example, nested chains, as is the case with Avalanche’s subnets, state channels, like that of the Bitcoin Lightning Network, sidechains, such as those with Klaytn, as well as rollups, which can be optimistic—those that assume transactions are legitimate by default (e.g., Optimism & Arbitrum) and zero-knowledge (zk) ones, performing computations off-chain, while maintaining absolute privacy (e.g. StarkNet). Figure 3: Web3 Layer 2 - Extension As you can see already, the application of L2 solutions can be quite varied, but much of the debate on the topic is focused on scalability. That is so because L1 networks are in general quite inefficient and require a significant portion of resources, whether that be in the form of validation rewards (i.e., transaction fees), or hardware. And for blockchain technology to be able to reach centralized legacy finance systems, like Visa for example, in terms of TPS, much work needs to be done in this avenue. The blockchain scalability trilemma Also known as the consistency, availability, and partition tolerance (CAP), the scalability trilemma is a dire question across the Web3 landscape. In layman’s terms, it simply means that no network can be all three at the same time. But while it does claim itself to be an unquestionable truth, there are plenty of L2 solutions, whose primary goal is proving it wrong. That being said, let’s walk through two of the most popular applications of L2 that can make your dev life a real pleasure. When it comes to expanding functionalities, few can rival a protocol, like Avalanche. This EVM-compatible protocol allows you to essentially deploy your own chain as part of a subnet. Subnets offer absolute flexibility and come at a fraction of the costs involved in creating your own protocol from the ground up. Curious to know more? Check out our tutorial series on Avalanche subnets and get started in no time: And if you’re more inclined to seek solutions for scalability, look at StarkNet. StarkNet is also an EVM-compatible protocol and supports zk-rollups out-of-the-box. It offers a major improvement to transaction processing, both in terms of resources and speed, by bundling transactions together, as all rollups do. At the same time, however, it does so with complete anonymity, thanks to its zk implementation. Want to dig further into StarkNet? Try our introductory guide: Layer 3: Web3 applications & presentation The last layer on our list is where all the latest cool implementations can be found—smart contracts, dApps, and NFTs. And while application is pretty straightforward, the term presentation is not so much. However, in reality, it only refers to the supporting tools a Web3 developer can use to BUIDL, like libraries, environments, and means of storage. To put it simply, all projects that facilitate the interaction with a blockchain protocol in improving accessibility can be effectively deemed L3 solutions. Figure 4: Web3 Layer 3 - Application  That is why, DEXs, such as Uniswap, PancakeSwap, and OpenSea are essentially part of the application L3. But so are creditors and yield aggregators, as is the case of Compound, Bancor, and Yearn. And let’s not forget about oracles, like Chainlink, that make interaction with real-world data possible, as well as the Ethereum Name Service (ENS), which is a decentralized version of the classic Domain Name Service (DNS). Wallet providers, like everyone’s favourite—MetaMask are too part of the application layer. That is so because MetaMask facilitates the interaction between user and protocol with the help of its UI. And when you look deeper into it, it becomes apparent—your wallet balance is nothing more than a recorded state, while transactions are basically changes in that state. Curious to learn more about the subject? Explore further with our article on MetaMask transactions here: But changes in state are far from being the only purpose of your MetaMask wallet. Would you be surprised to realize that it also serves as a means of authentication, allowing you to connect securely to various DApps, just as well? To do that, MetaMask takes the responsibility of a cryptographic account manager, while overseeing the creation and management of your account’s keys. So, don’t wait up and dive straight into the magic of MetaMask with an in-depth look under the hood: And to top it all off, as part of L3, you can find priceless tools to support your blockchain development operations too. Such is the case of file storage protocols, like the Interplanetary File System (IPFS), and Arweave. More so, popular libraries, as are Ethers.js and Web3.js, make their way here just as well, in addition to development environments, like Hardhat, Truffle, Foundry, and Brownie to make the list complete. Figure 5: Web3 Layer 3 - Presentation Which Web3 library should I use? And speaking about libraries and environments, here comes the burning question—which one should I use? Let’s start with the libraries, which serve as your go-to method for creating Web3 interactions. On one hand, there is Ethers.js—a lightweight and accessible implementation that also comes with extensive documentation. Ethers.js is the weapon of choice for plenty of rookie and seasoned BUIDLers alike and also serves as the default library for Hardhat projects. The only downside of Ethers.js is the handful of developers actively maintaining it. On the other hand, Web3.js is the more actively developed and used option of the two. And while it is quite popular among those looking to spin their own version of it, it does lack in the completeness of its documentation. This makes it the more difficult alternative to pick up, as a starting developer. But even so, if you are not afraid to try it out, it might just be right for you. Figure 6: Ethers.js vs Web3.js What is the best Web3 dev environment? With libraries, out of the way, let’s take a closer look at development environments. When it comes to such for Web3, your choice is basically one of four—Hardhat, Truffle, Brownie, and Foundry. Both Hardhat and Truffle are JavaScript-based, so if that is your programming language of choice, then you can skip on Brownie, as it is for Python developers. But what is the difference between the two? Hardhat Hardhat is a comprehensive development environment that sports the full set of functions you’d normally be looking for your Web3 needs. It allows you to compile, deploy, debug, and test all Ethereum-based codebases. The key benefit of Hardhat is that it offers flexibility when it comes to plugins and add-ons that can truly supercharge your entire development process. It also ships with an extensive knowledge base that will truly be a lifesaver while debugging and troubleshooting errors. Foundry Meet the new kid on the dev environment block—Foundry. It is an exceptionally fast, portable, and modular take on the subject that focuses on the Rust language instead. Much like Truffle, Foundry is also an entire suite of Web3 developer tools, rather than a single solution. Within it, Forge claims responsibility for the testing framework, Cast serves as the primary means of interacting with the EVM, while Anvil enables local node deployment. Want a more detailed comparison between Foundry and Hardhat? Explore further in our dedicated article below: Truffle As mentioned already, Truffle is not one tool, but rather a complementing set of three—Truffle, Ganache, and Drizzle. The suite allows you to perform compilations, deployment, and testing of EVM-compatible code. At the same time, it offers the means to build the frontend of dApps, just as well. When it comes to each individual module, Truffle serves as the primary environment, deployment pipeline, and framework for testing. Then there is Ganache, which helps you deploy a local chain swiftly, while Drizzle is the collection of libraries that enable the BUIDLing of frontend interfaces. Brownie Last on our list is Brownie—the perfect solution for Python-lovers that want to work with Web3. It comes with an extensive set of dev tools, mostly based on the Web3.py library, and can be used for the deployment, compilation, and testing of dApps. Brownie relies on pytest to provide a powerful debugging framework, which includes property-based, and stateful testing, as well as the classic tracebacks that all python developers know and love. Dig into the details behind Brownie with our tutorial on the subject: How can I store files on a blockchain? Blockchain technology is in its essence a resource-heavy and expensive database. This also makes storing files of pretty much any size on it extremely expensive and difficult. Simply put, you can forget about putting dank memes, GIFs, and high-res images on-chain. But what if your use case necessitates the storage of such files? Then decentralized storage protocols are the perfect fit for you! One of the most popular such solutions is IPFS, and because of its monolithic name, paired with a handy first-comer advantage, has become the file protocol of choice for plenty of creators behind NFT assets, among many. An alternative to IPFS is the Arweave protocol, which offers an interesting take on the storage question at hand. Instead of requiring significant computational resources, Arweave miners offer hard drive space for users, and in return are rewarded with tokens accordingly. How to use real-world data on-chain? Interacting with real-world data is once again, one of the direst questions in Web3. The fact of the matter is that without any additions, a blockchain has absolutely no way of shaking hands with real-world data—from simple weather APIs to more complex interactions, like financial instruments. This is called the oracle problem. And come to think of it, how did the entire DeFi boom come to be, if no chain has the capability to even interact with price feeds that are essential for its existence? The secret lies in a decentralized oracle implementation, called Chainlink that is to date responsible for powering the large majority of DeFi protocols currently in operation. Oracle networks, like Chainlink and the Uniswap oracle, essentially serve as the bridge between blockchains and real-world data. To do that, they take the role of authenticating information received from relevant APIs in various ways and then parse what they determine to be the correct state to be written on-chain. So, should your use case rely on API data, look no further than an oracle network to solve this challenge for you. Bringing all the layers together That being said, we can put a definitive end to our overview of the Web3 stack. From L0 infrastructure, through the foundational networks on L1, and their L2 extensions, all the way to the libraries, environments, storage, and oracles of L3, there is always something interesting for you to start BUIDLing. And what better way to do a curtain’s call than with another quick recap. This time, however, with one that offers a complete bird’s eye view of the Web3 stack and some of its most notable projects: Figure 7: The Web3 landscape from Layer 1 to Layer 3 Power-boost your project on Chainstack #### WebSocket support for Warp transactions: Supercharging high-speed trading We’re excited to announce the launch of WebSocket support for Warp transactions—a highly requested feature that caters to the needs of high-speed traders and those who require ultra-low latency in their blockchain operations. What are Warp transactions? In the dynamic and ever-evolving world of blockchain technology, speed and efficiency are of the utmost importance. Recognizing this need, Chainstack introduced a powerful new feature known as Warp transactions. This innovative solution leverages the high-speed bloXroute transaction relay network to expedite your transactions, ensuring they are picked up and processed by validators more quickly than ever before. Using this method, your transactions will be distributed into the protocol's mempool using this high-speed network. The effect of this is that your transaction becomes available for validators to pick up and include in the block at a significantly faster rate compared to standard mempool propagation. Essentially, Warp transactions are designed to cut down on transaction times, ensuring that your transactions get to where they need to go in the most efficient way possible. What is WebSocket Secure? WSS, or WebSocket Secure support refers to the implementation of the WebSocket protocol, which enables full-duplex communication channels over a single, long-lived connection between a client and a server. This technology has become a popular choice for real-time applications, such as online games, chat applications, and financial trading platforms. Why WebSocket? WSS offers numerous advantages over traditional HTTP connections, making it a preferred choice for real-time applications and systems that require low latency and high performance. This feature update comes in response to the increasing demand from our community. We understand that every millisecond of latency is crucial for traders, and our goal is to provide the best possible performance to help them stay competitive. WebSocket enables full-duplex communication, which means that both the client and the server can send and receive data simultaneously without having to establish a new connection. In contrast, HTTP is a half-duplex protocol, where the client initiates a request, and the server sends a response, requiring a new connection for each interaction. WebSocket connections are persistent, eliminating the need to repeatedly establish, and close connections for each interaction. This results in significantly lower latency as data can be transmitted instantly without the overhead of connection setup and teardown. HTTP connections, on the other hand, involve more overhead due to the need for establishing new connections for each request-response cycle. High-speed trading with real-time updates WebSocket connections reduce the amount of data transferred between the client and server by avoiding the need for HTTP headers and minimizing the overhead of connection establishment. This results in more efficient use of network resources and lower bandwidth consumption compared to HTTP. WSS allows for real-time updates and notifications, as the server can push data to the client as soon as it becomes available. In contrast, HTTP relies on the client to request updates, which can lead to delays and inefficiencies. WSS is designed to handle a large number of simultaneous connections with minimal overhead, making it suitable for applications that require high levels of concurrency and real-time communication. HTTP, on the other hand, can struggle with handling a high volume of connections due to its connection-oriented nature. Building with WebSocket By implementing WSS support Warp transactions, developers and users can enjoy faster and more efficient interactions with the blockchain network, which is especially valuable for high-speed trading and other time-sensitive applications. With WebSocket support, Warp transactions become the forefront of high-speed blockchain interactions, akin to a sports car with a top-notch pit crew. Developers can leverage the benefits of WSS in their applications, such as bidirectional communication, lower latency, efficient use of resources, real-time updates, and scalability. This enables the creation of more responsive and efficient applications that cater to the needs of users who demand high performance and low latency. In summary, WebSocket support for Warp transactions allows developers to harness the full potential of real-time communication, providing a seamless and efficient experience for users across various applications, especially those that require high-speed trading and time-sensitive operations. Pricing We are pleased to announce that WebSocket support for Chainstack Warp transactions comes at no additional charge, making it even more accessible for developers and users to take advantage of this powerful feature. When using Warp transactions via WSS, you will be billed according to your chosen subscription plan and any applicable usage-based fees. This ensures that you only pay for the resources and services you use while enjoying the benefits of WSS without incurring extra costs. To review the detailed pricing information for Chainstack’s infrastructure and services, please visit our pricing page. Feature highlights We are excited to release this highly anticipated feature designed to cater to the needs of high-speed traders and those who require ultra-low latency in their blockchain operations. This update offers a range of advantages, including full-duplex communication, persistent connections, real-time updates, and scalability. With WebSocket support, Chainstack’s Warp transactions are set to revolutionize the way users and developers interact with the blockchain network, especially for time-sensitive applications: Full-duplex communication: WSS enables simultaneous data transmission between the client and server without the need to establish a new connection. Persistent connections: WebSocket connections stay open for the duration of client-server interaction, resulting in lower latency and more efficient communication compared to HTTP. Real-time updates and notifications: WebSocket allows servers to push data to clients instantly as it becomes available, offering real-time updates and faster response times. Exceptional scalability: WSS can handle a large number of simultaneous connections with minimal overhead, making it ideal for applications requiring high concurrency and real-time communication. Improved efficiency and lower bandwidth consumption: WSS reduces the amount of data transferred by avoiding HTTP headers and minimizing connection establishment overhead. Enhanced application performance: Leverage WSS to build more responsive and efficient applications, catering to users who demand high performance and low latency. No additional charge for WSS support: Chainstack offers WebSocket support for Warp transactions at no extra cost making it accessible to all developers and users. In conclusion, the addition of WebSocket support for Chainstack’s Warp transactions empowers developers and users with faster, more efficient interactions in the blockchain ecosystem. This enhancement brings new possibilities for building responsive, high-performance applications that cater to a wide range of use cases, especially for high-speed trading and time-sensitive operations. We are confident that this will significantly improve the overall Web3 user experience and contribute to the continued growth and innovation within the blockchain space. Experience the power of WSS with Chainstack’s Warp transactions and unlock the full potential of real-time communication today. Power-boost your project on Chainstack #### What are digital wallets? Digital wallets have become an essential tool for managing and using digital currencies like Bitcoin and Ethereum. These wallets allow users to store, send, and receive digital assets, as well as interact with decentralized applications (DApps) on the blockchain. In this post, we'll take a look at some of the different types of digital wallets available, including a deep dive into the popular Ethereum wallet, Metamask. Intro: Digital wallets are software programs that enable users to manage their digital assets, such as cryptocurrencies and NFTs. They provide a secure way to store, send, and receive digital currencies, and often offer additional features like the ability to interact with DApps and manage multiple accounts. Digital wallets can be accessed from a variety of devices, including desktop computers, laptops, and mobile phones, and are often used in conjunction with cryptocurrency exchanges to enable users to buy, sell, and hold digital assets. Different types of digital wallets: There are several types of digital wallets available, including cold wallets (hardware wallets), software wallets, and hot wallets (online wallets). Hardware wallets are physical devices that store digital assets offline, providing an extra layer of security. These wallets are typically small and portable, making them convenient for users who want to take their assets with them on the go. However, they can be more expensive than other types of wallets. Software wallets are software programs that are installed on a device, such as a computer or a smartphone. These wallets can be downloaded for free and offer a range of features, including the ability to manage multiple accounts and interact with DApps. Online wallets or hot wallets are web-based wallets that are accessed through a web browser. These wallets offer the convenience of being able to access your assets from any device with an internet connection, but they are also less secure because they are connected to the internet. The most popular digital wallet - Metamask Metamask is a digital wallet that was specifically designed for use with the Ethereum blockchain and it also supports EVM-compatible blockchains like BNB, Avalanche, Polygon, etc. It allows users to manage their Ethereum assets, interact with DApps on the Ethereum network, and even sign and send transactions from their web browser. In addition to its wallet function, Metamask also serves as a bridge between the Ethereum network and web-based applications, allowing users to access DApps directly from their web browser without the need for a separate Ethereum client. Setting up a Metamask Wallet Setting up a Metamask wallet is quick and easy. First, visit the Metamask website (https://metamask.io/) and click on the "Download" button. This will download the Metamask extension to your web browser. Once the download is complete, click on the Metamask icon in the top right corner of your browser to open the extension. Next, click on the "Create a Wallet" button to begin the setup process. You'll be prompted to create a password for your wallet and to agree to the terms of service. After you've entered your password and accepted the terms, Metamask will generate a recovery phrase for you. It's important to write down this recovery phrase and keep it in a safe place, as it will be used to restore access to your wallet if you forget your password or lose access to your device. Create MetaMask wallet Once your recovery phrase has been created, you'll be taken to the main dashboard of your Metamask wallet. From here, you can manage your Ethereum assets, view your transaction history, and interact with DApps on the Ethereum network. Making Transactions with Metamask Using Metamask to make transactions is straightforward. First, click on the "Send" button on the main dashboard of your wallet. You will need to provide the address where you want to send the funds and also the amount. You'll also have the option to choose which Ethereum account you wish to use to make the transaction. Send Metamask transaction Insert address Input amount and click next Once you've entered the necessary information, click on the "Next" button to review the details of the transaction. If everything looks good, click on the "Confirm" button to submit the transaction. It's important to note that Ethereum transactions require a small amount of gas, which is the fuel that powers the Ethereum network. Gas is paid for in Ethereum, the native cryptocurrency of the Ethereum blockchain. When making a transaction with Metamask, you'll need to have enough Ether in your wallet to cover the cost of the gas. If you don't have enough Ether, you'll need to purchase some before you can complete the transaction. Other Digital Wallets In addition to Metamask, there are many other digital wallets available that support a variety of digital assets. For example, Phantom is a digital wallet for the Solana blockchain. It offers a simple and user-friendly interface for managing and interacting with Solana-based assets and DApps and it works in a similar fashion to Metamask. If you are asking yourself - Why do I need a digital wallet? Here are 5 reasons for it Convenience: Digital wallets allow you to make payments and manage your assets from anywhere, at any time, using your mobile device or computer. Security: Digital wallets use advanced security measures, such as encryption and multi-factor authentication, to protect your assets from unauthorized access. Control: Digital wallets give you full control over your assets, allowing you to manage them yourself without the need for a bank or other financial institution. Speed: Digital transactions can be processed much faster than traditional financial transactions, which can be especially useful for international payments. Lower fees: Digital wallets often charge lower fees for transactions compared to traditional financial institutions. Overall, digital wallets provide a convenient, secure, and cost-effective way to manage and use digital currency and other digital assets. Conclusion: Digital wallets are useful because they allow you to store and manage your digital currency and other digital assets in a convenient and secure way. With a digital wallet, you can easily and securely send and receive payments, track your transactions, and manage your assets without having to rely on a central authority or intermediaries. Whether you're using a hardware wallet, software wallet, or online wallet, it's important to choose a wallet that meets your needs and offers the level of security and convenience you require. Build with Chainstack #### What are Flashblocks? Faster confirmations for L2 rollups TL;DR Ethereum's rollup-centric roadmap has made enormous strides in throughput and cost reduction. But one problem has proven stubborn: latency. Even on L2s, users wait 2 seconds for a transaction to confirm. That might sound fast compared to Ethereum mainnet's 12-second block time, but it falls short for the applications blockchain infrastructure is increasingly being asked to support, from high-frequency DeFi to responsive on-chain gaming to real-time payment flows. Flashblocks gets that as low as 200 milliseconds by streaming partial blocks to nodes every 200ms while keeping the 2-second block structure intact underneath. The expensive parts of block production, state root calculation and consensus, still happen once per full block. Users just stop waiting for them. Introduction: the L2 latency problem L2s like Base inherit their block time from the OP Stack sequencer, which produces blocks every 2 seconds. This is already a significant improvement over Ethereum mainnet, but it still creates friction for latency-sensitive applications. The obvious fix is to reduce the block time. The problem is that doing so naively is not sustainable. Producing a block requires calculating the state root, a cryptographic commitment to the entire resulting chain state. Doing this every 200ms imposes severe computational overhead on every node in the network, making syncing progressively slower as chain state grows. Sub-second block times also require significant modifications to Geth or Reth that harm EVM equivalence. Maintaining 1:1 compatibility with anything built on Ethereum while minimizing protocol complexity is a core OP Stack design goal, and naively fast blocks put that at risk.   What are Flashblocks? Flashblocks are ephemeral sub-blocks streamed every 200ms within a standard 2-second block window. Rather than producing a new full block at each interval, the sequencer produces lightweight partial blocks and streams them to nodes in real time. At the end of the 2-second window, all accumulated Flashblocks are committed into a single finalized block. The key is deferred computation. State root calculation and consensus happen only once per full block rather than once per Flashblock. Each 200ms interval gives users a transaction preconfirmation, confirming that their transaction has been ordered and executed without waiting for the full block to be sealed. On Base, each 2-second block is composed of 10 Flashblocks, each with its own transaction ordering. The sequencer streams these over WebSocket to nodes with the Flashblocks module enabled. The approach draws inspiration from Solana's shreds and Celestia's data squares, both mechanisms for streaming partial block data to network participants before finalization, enabling incremental execution rather than batch delivery. Flashblocks applies the same idea while staying within EVM equivalence and the 2-second block structure the OP Stack depends on. The team behind the infrastructure Flashblocks is developed by Flashbots, the organization originally known for productizing MEV on Ethereum through MEV-Boost, co-designed with Uniswap Labs and OP Labs. They open-sourced two components that power the system: op-rbuilder, a Rust-based block builder that separates transaction execution from state commitment, and Rollup-Boost, the sequencer sidecar that plugs into an existing OP Stack sequencer without requiring changes to the core protocol. Architecture: how Flashblocks work The implementation is two-sided. On the sequencer side, Rollup-Boost runs as a sidecar that continuously builds and streams partial blocks every 200ms over WebSocket. On the node side, the Flashblocks module on Base's Reth fork receives those streams and updates local state at each interval rather than waiting for a full block.   Architecture before Flashblocks (Source: Base Blog: Flashblocks Deep Dive) Flashblock state is surfaced via standard Ethereum JSON-RPC methods using the pending tag. The key distinction from a finalized block is visible in one field: stateRoot is zeroed out, reflecting that the chain state has not yet been committed. Once the full block is sealed, the state root is calculated and the block is finalized. Because Flashblocks piggybacks on the existing pending tag rather than introducing new methods, existing dApps can support it with minimal code changes. Example request: ```bash curl -sS -X POST "$YOUR_CHAINSTACK_BASE_RPC_URL" \ -H "Content-Type: application/json" \ --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["pending",false]}' Calling eth_getBlockByNumber with pending on a Flashblocks-enabled endpoint returns the block as it is being built, not only after final sealing. A zeroed stateRoot indicates preconfirmation. // Flashblock preconfirmation (~200ms, illustrative) { "stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000", "receiptsRoot": "0x5f2dd9fbe32e2c22e47d84edbe6a300e75a004495191ff9f6228ce5de8f7c6f8", "hash": "0x61792b40d824cb6e99ad07de112c823e0f86995063c00486e8dd3ef9667b40fc" } // Finalized 2s block (illustrative) { "stateRoot": "0x16a1375def73d111a7dcfcd39acbcdbe935acf011e645c8f37af2a05af72af71", "receiptsRoot": "0x26dc0c64a01f87aecf3e112fa92c06845757dbc72b708bf783c97b425828cdb5", "hash": "0xb09354e0fd87cd9c379c456ab41ea9b4ff1c684bea7705e19bb237f621b588f0" } 📖 For implementation details, see Chainstack documentation: Flashblocks on Base. Base has also contributed a Flashblocks WebSocket Proxy, a Rust-based service sitting between the sequencer and downstream nodes. It subscribes to the Flashblocks stream and fans out to multiple nodes, protecting the sequencer from direct connection load and implementing rate limiting via Redis with an in-memory fallback.   Architecture before Flashblocks (Source: Base Blog: Flashblocks Deep Dive) On OP Mainnet, Optimism runs a similar setup with one additional layer: op-conductor, which manages sequencer orchestration and ensures only the active leader forwards Flashblocks downstream, guarding against split-brain scenarios where multiple builders might emit conflicting streams simultaneously. Node state propagation: the trust tradeoff When a node receives a Flashblock, it needs to update its local state. There are three ways to do this, each at a different point on the trust spectrum. Re-execution: The node independently re-executes all transactions in the Flashblock to compute the resulting state itself. No new trust assumptions, but more compute on the node side. Direct state acceptance: The node accepts the resulting state from the sequencer directly, without re-executing. More efficient, but it requires trusting the sequencer to have the state computed correctly. Verified state acceptance: The node receives the resulting state alongside a proof, either a ZK proof or TEE (Trusted Execution Environment) attestation, verifying the state was reached legitimately. This is the most robust option and where the roadmap points. The endgame is nodes serving verified early Flashblock execution state via RPC, making Flashblocks indistinguishable from full blocks at the application layer. A user swapping tokens would get a wallet confirmation with updated balances within 200ms. TEE attestations for Flashblock validity are on the roadmap but not yet available in the public rbuilder implementation. Impact on L2 UX and application design On a standard Base endpoint, confirmation times average around 2000ms. On a Flashblocks-enabled endpoint, real-world latency drops to roughly 300 to 500ms, accounting for the 200ms Flashblock interval plus network travel time. That gap is small in absolute terms but significant in practice. For DeFi, the effects show up in market structure. Faster blocks shrink the window during which stale prices can be arbitraged against liquidity providers, lowering adverse selection costs and tightening spreads. Research suggests LPs on L2s with faster block times achieve around 20% higher fee returns and 75% more concentrated liquidity around the midmarket price compared to Ethereum mainnet. Unichain leans into this directly, pairing Flashblocks with verifiable priority ordering to reduce adverse selection costs and make on-chain trading more competitive with centralized exchanges. The implications extend further though. Responsive payment interfaces and on-chain applications that need to react to user input all become more viable when confirmation is measured in hundreds of milliseconds rather than seconds. Much of what feels native to Web2 but out of reach on-chain today comes down to latency, and Flashblocks chips away at that gap. Flashblocks vs. alternative approaches Arbitrum's Direct Block Approach Arbitrum achieves fast confirmations by producing full blocks every 250ms. The user-facing speed is comparable, but the method differs. Full blocks at 250ms require a state root calculation at each interval, carrying significant computational overhead and introducing EVM equivalence issues from modifying core execution clients. The sustainability of this approach becomes a concern as chain state grows. Flashblocks sidesteps that by amortizing the expensive computation across the full 2-second window, achieving similar confirmation speeds with substantially lower overhead per interval. 📖 Learn more: Transaction lifecycle on Arbitrum. Timeboost Arbitrum's Timeboost targets a different problem. Rather than focusing on raw latency for everyone, it addresses MEV and ordering fairness. It is a time-based priority auction where transactions pay a fee to receive a time boost of up to 500ms, moving their effective timestamp earlier in the queue. The important distinction is that Timeboost does not reduce latency universally. It increases baseline transaction delay by introducing the auction mechanism, then selectively reduces it for users who pay. The system captures MEV value for the protocol and addresses latency-racing in first-come-first-served systems, but it is solving an adjacent problem to the one Flashblocks targets. 📖 Learn more: Timeboost. Conclusion Flashblocks is designed to be chain-agnostic within the OP Stack. While the technology is already live on Base (at 200ms) and OP Mainnet (at 250ms), infrastructure availability is rolling out in phases. Chainstack currently provides Flashblocks-enabled endpoints for Base, with Optimism support to follow. The broader Rollup-Boost roadmap extends further. An encrypted mempool would keep transactions private throughout their entire lifecycle, visible only within secure TEE hardware. TEE validity proofs would use a multi-prover approach to help rollups qualify as Stage 2, where two separate proving systems must agree before the system proceeds, with a fast and cheap TEE prover acting as the second alongside a more expensive ZK prover. TEE coprocessing goes further still, enabling private computation running alongside the EVM that would let smart contracts interact with Web2 systems and store private state, opening up application categories that are currently out of reach on-chain. Combined with OP Succinct's ZK-based fast finality and native Reth support, Flashblocks is one part of a larger push to make the OP Stack competitive across every dimension, balancing speed, security, and developer experience. 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. Start building with Chainstack → FAQ What are Flashblocks? Flashblocks are partial blocks streamed every ~200ms within a standard rollup block interval, allowing transactions to appear confirmed much faster. How do Flashblocks reduce latency? They stream incremental transaction execution updates before the full block is finalized. Do Flashblocks change block time? No. The underlying block time remains the same (for example, 2 seconds on many OP Stack rollups). Where are Flashblocks available? Flashblocks are live on rollups such as Base and OP Mainnet. On Chainstack, Flashblocks-enabled endpoints are currently available for Base, with Optimism support coming soon. How many Flashblocks are in a block? On Base, each 2-second block contains about 10 Flashblocks, streamed roughly every 200ms. Do dApps need to change code to support Flashblocks? Usually not. Flashblocks are exposed through the standard Ethereum RPC pending state, so most applications work with minimal or no changes. Related articles Flashblocks on Base: 200ms preconfirmations via Chainstack RPC Best Base RPC providers for on-chain applications in 2026 Ethereum without L2: Charting the impact of rollups on network performance zkEVM and zkRollups Explained #### What is a Stablecoin: types, trade-offs, and how they run in 2026 Stablecoins peg to fiat, most often the US dollar. They move trillions a month now and sit underneath payments, trading, and cross-border payouts. If you build on-chain, you need to know how they’re designed and where the trade-offs are. Stablecoins are crypto’s closest thing to digital cash. They’re tokens pegged to currencies like the U.S. dollar, designed to cut out price swings. In 2026,  there’s more than $250B in circulation and over $2T moved each month. That’s a bigger flow than PayPal and close to legacy rails like ACH. What started as “stable dollars for trading” has become core internet money. Visa, Stripe, PayPal, and JPMorgan now plug stablecoins into payments and settlement. On-chain, they backstop lending markets, power payrolls, and handle cross-border payouts at scale. If you’re building crypto infrastructure, you’ll end up touching them — whether that means minting, redeeming, or just moving tokens across networks. Stablecoin-based applications are highly sensitive to latency, reliability, and predictable execution.For these workloads, purpose-built blockchains such as Tempo are often a better fit than general-purpose networks. What is Stablecoin? A stablecoin is a type of cryptocurrency that aims to hold a steady price. Most are pegged to the U.S. dollar. Instead of moving like Bitcoin or Ether, they track one unit of a reference asset such as dollars, euros, or commodities, which makes them usable as digital money. Most stablecoins are backed by reserves such as cash, short-term U.S. treasuries, or on-chain collateral. Others use algorithmic or hybrid designs to manage supply. Whatever the design, the purpose is to stay stable enough to move money on-chain, making it the base unit for exchanges, lending markets, and settlement flows. Source: Messari 2025. Difference between Stablecoins and cryptocurrency Most cryptocurrencies swing in price. Stablecoins are built to hold steady by tracking fiat currencies like the U.S. dollar. That design changes how they’re used, how they’re redeemed, and who integrates them. StablecoinsOther CryptocurrenciesPegged to fiat (usually USD) to reduce price fluctuationsFloat freely, often highly volatileBacked by reserves or collateral; redemption rights through an issuerNo reserves, no redemption; price set only by supply and demandTreated as digital money for payments, cross-border transfers, and settlementTreated as speculative assets for upside or store of valueIntegrated by financial institutions and payment firms; tied into AML and regulatory frameworksListed on crypto exchanges with fewer compliance layersSome contracts allow freeze/blacklist controls and multi-chain mint/redeemNo issuer controls; immutable once minted Many people still ask is Bitcoin a Stablecoin? It isn’t. Bitcoin moves with market demand and has no peg or reserves. A stablecoin is different: it’s issued to track the dollar or another currency, backed by cash or collateral, and meant to hold steady so it can be used like digital cash on-chain. How does a Stablecoin work to maintain value? Stablecoins hold their peg with different mechanisms: Fiat-backed coins use bank reserves in cash and short-term treasuries. Users can mint by depositing dollars and redeem near 1:1, which keeps the token trading close to its peg. Crypto-collateralized designs lock excess crypto into smart contracts. If collateral value drops, liquidations restore balance. Algorithmic models adjust token supply using oracles and circuit breakers, though many add collateral after past depegs. The common thread is redemption and arbitrage. If a stablecoin trades off-peg, traders can mint or redeem to close the gap. Reserves, oracles, and clear redemption rules make the difference between a stable peg and sudden price fluctuations. Why Stablecoins matter: benefits, risks, and trade-offs Stablecoins are the closest thing to digital money that crypto has. They move across blockchains without banking hours, give traders a steady unit of account, and cut friction in cross border payments. That’s why they now handle trillions each month. But every design comes with trade-offs, from depeg risk to the policies that issuers and regulators enforce. BenefitsRisks/ConsFast settlement across time zones and chainsRegulatory framework still shifting; rules differ by regionLower costs for cross border payments compared to wires or cardsOn/off-ramp access tied to your bank account and jurisdictionPegged value avoids the swings of other types of cryptocurrencyPrice fluctuations can still happen if reserves or oracles failWorks with wallets, crypto exchanges, and enterprise payoutsSmart-contract or governance bugs can break mint/burn logicIntegrated by financial institutions as settlement railsSome stablecoin issuers disclose more than others; trust varies24/7 transfer rails and composable DeFi flowsFreeze/blacklist features and anti-money laundering controls can halt funds How Stablecoins work under the hood Stablecoins hold their peg through a loop of mint, reserve, and redemption. New tokens are minted when dollars or collateral flow in, and burned when users redeem back out. Fiat-backed stablecoins like USDC and USDT keep cash and short-term treasuries with custodians; issuers publish attestations to show backing. DAI is the template for crypto-collateralized stablecoins. You lock in more ETH than you borrow. If the price of ETH dives, the system sells it off to keep the peg. Oracles call the shots on pricing, and some protocols wire in circuit breakers or freezes for stress events. Three things keep stablecoins near $1: Redemption rights — issuers mint and burn to match inflows and outflows. Collateral — cash, treasuries, or crypto locked against supply. Market arbitrage — traders close small gaps on crypto exchanges. Algorithmic models have tried to manage supply without reserves, but most failed to hold parity. Types of Stablecoins There are a few types of stablecoins. Each holds a peg in a different way, which changes risk, disclosure, and how you build on it. Source: Messari 2025 Fiat-backed stablecoins: Backed by cash and short-term U.S. treasuries held with custodians. You can redeem near $1 through an issuer. Low drift and fast settlement. (Examples: USDC, USDT on Plasma chain, PYUSD.) Crypto-collateralized: Backed by on-chain collateral with overcollateralization and liquidations. Transparent and programmable. (Example: DAI.) Algorithmic stablecoins: Aim to hold parity with supply rules or swap mechanics. Capital-light on paper. Hybrids / PSM models: Mix fiat and crypto backing or use a price stability module to keep swaps around $1. Flexible design. Stablecoin list 2026: top tokens and supported networks Most stablecoin supply concentrates on a few networks. That’s where the liquidity and transfers concentrate. StablecoinPegMain NetworkUSDT (Tether)USDTron, Ethereum, BNB Chain, Solana, EVM L2sUSDC (Circle)USDEthereum, Solana, Base, Arbitrum, Avalanche, PolygonDAI (MakerDAO)USDEthereum (bridged to L2s)PYUSD (PayPal)USDEthereum, SolanaEURC (Circle)EUREthereum, SolanaFDUSD (First Digital)USDBNB Chain, Ethereum USDT dominates on Tron and Ethereum. USDC spans EVM chains and Solana with CCTP for native moves. DAI stays on Ethereum, backed by on-chain collateral. Newer entrants like PYUSD and EURC are tied to payments and euro rails. Stablecoin use cases For builders, the main use cases break down into four areas: Payments and remittance — Fast, cheap cross border payments without bank hours or FX drag. Trading and settlement — the unit of account on exchanges and DeFi pools. On-chain treasury and payouts — payrolls, reserves, and contractor pay now run in tokens. AI and agents — Early pilots use stablecoins as programmable money for bots and automated services. Stablecoin infrastructure with Chainstack For stablecoins, you need infrastructure that holds steady under load. With Chainstack, you get 99.99% uptime to reach 70+ blockchain protocols through Global Nodes and Dedicated Nodes, including purpose-built chains like Tempo optimized for stablecoin workloads, keeping flows for USDT, USDC, DAI, PYUSD, EURC, and FDUSD consistent across networks. On top of that, you get the controls and speed required to run in production. Access rules let you gate keys, methods, and IPs. While Trader Nodes provide low-latency execution over HTTP and WebSocket, and on Solana, the Geyser plugin streams transfers in real time. As for data, with Chainstack, you also get Subgraphs to index balances, holders, supply snapshots, and redemption events into a single source for dashboards, audits, and monitoring. With this stack, you can launch, scale, and operate stablecoin apps without worrying about downtime or missing anything. Start building on Chainstack Wrapping up You’ve now seen how stablecoins actually work: mint and burn, reserves, redemptions, oracles, and the trade-offs between models. They’ve grown into the default money layer on-chain, which means every builder ends up touching them: for payouts, treasuries, or settlement. If you’re ready to take that into production, run it on Chainstack. You’ll get reliable nodes, archive history, live streams, and controls across 70+ networks. And if you’re still comparing RPC vendors, here’s a guide to six free tools that benchmark top node providers. Power-boost your project on Chainstack FAQ What is a stablecoin? A stablecoin is a crypto token designed to hold a steady price, usually pegged 1:1 to the U.S. dollar. Reserves, collateral, or supply controls keep it near the peg so it can be used as digital money instead of a speculative asset. How do Stablecoins work? Stablecoins work through minting, burning, and redemption. Fiat-backed models hold cash and treasuries with custodians, while crypto-backed models lock excess collateral in smart contracts and liquidate when coverage slips. What are the two types of Stablecoins? The two main types are fiat-backed stablecoins (like USDC, USDT, PYUSD) and crypto-collateralized stablecoins (like DAI). Algorithmic or hybrid models exist but have struggled to hold their peg. What is the difference between Bitcoin and Stablecoin? Bitcoin is not a stablecoin. It has no peg, no reserves, and its price moves with market demand. Stablecoins track fiat currencies like the U.S. dollar and are used for payments, trading, and settlement. How to create a Stablecoin? To create a stablecoin on Ethereum, you design a contract (often ERC-20), define mint and burn functions, and connect reserves to back the supply. With Chainstack you can run Ethereum nodes, apply Access rules for admin calls, and scale the same setup across 70+ networks. What are Stablecoins used for? They are used for cross border payments, trading collateral, on-chain treasuries, and embedded finance. Most crypto exchanges settle trades in stablecoins, and institutions use them for fast international payouts. #### What is Firedancer on Solana? Architecture guide Introduction  Solana has always been fast, but fast and resilient are different things. For most of its history, Solana has relied heavily on a dominant validator client, Agave, which meant the network had limited client diversity and shared similar failure modes. Firedancer, the new high-performance client built by Jump Crypto, changes that. There's a second benefit that's easy to overlook. Solana's historical weakness wasn't just outages, it was spam. When transaction fees are low and throughput is constrained, flooding the network with junk is a cheap and effective attack. Firedancer’s raw performance raises that cost significantly. Higher throughput makes spam-based denial-of-service attacks more expensive and less effective, which strengthens the network’s security posture. Frankendancer to Firedancer 1.0 Before Firedancer shipped in full, there was Frankendancer. A hybrid client that grafted Firedancer's C-based networking layer onto Agave's Rust execution engine, giving validators an intermediate path before the full client was ready. It was a deliberate stepping stone, letting validators begin adopting parts of Firedancer's architecture without waiting for the complete rewrite. But the performance ceiling was always going to be limited by whichever half was slower, and that was Agave's execution layer. Firedancer’s headline throughput claims depend on the fully integrated client, rather than the hybrid Frankendancer setup. The 33% stake-weight threshold is where client diversity stops being theoretical. Below it, Agave still holds a superminority, meaning a consensus failure there could halt the chain with nothing to counteract it. Once Firedancer clears that mark, no single client can do that alone. The Architectural shift from monolith to tiles Agave runs as a single process. Everything, networking, execution, consensus, shares the same memory space and competes for the same resources. Firedancer scraps that design entirely. Instead, Firedancer breaks work into isolated tiles, each responsible for a narrow task and mapped to dedicated CPU resources to reduce contention.   Memory is handled the same way. Rather than relying on standard heap allocation, which introduces non-deterministic latency every time the allocator has to find and return memory, Firedancer pre-allocates everything upfront in hugepages. Memory is pre-allocated up front, which helps avoid the latency spikes that can come from runtime allocation. Core assignment follows the same logic, with tiles placed based on physical proximity to the NIC to minimise cross-socket memory access and keep the hot path as short as possible. The goal throughout is to eliminate every source of unpredictable latency at the architectural level, not patch it after the fact. The networking layer: bypassing the kernel Every packet Agave processes takes a round-trip through the Linux kernel's networking stack. That overhead is manageable at moderate throughput and punishing at scale. Firedancer minimizes kernel overhead using technologies such as AF_XDP and eBPF to move packet handling closer to userspace and the NIC. The throughput ceiling becomes the hardware itself, not the software sitting in front of it. Signature verification gets the same treatment. Ed25519 verification is expensive at scale, and Firedancer uses SIMD-accelerated signature verification to process signatures in parallel batches rather than sequentially. For a network where every transaction carries a signature that needs verifying, this is one of the more consequential performance decisions in the entire stack. What this means for infrastructure operators Firedancer's architecture only delivers on its promises if the environment underneath it is configured to match. The tile model assumes uncontested access to hardware, and that assumption breaks the moment the OS starts interfering. In practice, running Firedancer well means disabling hyperthreading, isolating cores from the kernel scheduler, and setting CPU affinity so each tile owns its assigned core without interruption. These aren't optional performance tweaks.   The more interesting question is what the efficiency gains actually mean economically. Two outcomes are possible and they have different implications. If Firedancer lowers the hardware floor so operators can hit the same performance targets on cheaper infrastructure, it could reduce the cost of running a competitive node and broaden validator participation. If it instead raises the ceiling on what high-end hardware can do without improving the economics at the lower end, the gains accrue primarily to well-capitalised operators. Which of those plays out in practice will matter more for network decentralisation than the TPS headline ever will. The signal to watch is mid-tier validator hardware. If operators running commodity infrastructure start hitting performance targets that previously required high-end nodes, the floor is moving. If the gains stay concentrated at the top end, the ceiling is. Chainstack's managed nodes sit in a useful position here, abstracting the hardware question for teams who need reliable RPC access without committing to a validator setup while that plays out. Observability gets a significant upgrade regardless. Firedancer’s monitoring and GUI surfaces tile-level operational data that gives operators a much clearer view of where the node is slowing down. Instead of relying only on broad node-wide signals, you can inspect the specific tile or processing stage that is backing up, which makes performance troubleshooting far more precise. In practice, that means bottlenecks can be identified directly rather than inferred from aggregate CPU load or other coarse metrics.   Source: firedancer.fun The RPC layer still matters  Firedancer raises the throughput ceiling at the validator layer. But that ceiling isn't what application developers run into day to day — they work through RPC endpoints, and the properties that matter there are different: consistent latency under load, predictable response times when the network is busy, stability when block production is fast and irregular. Here's the counterintuitive part: as Firedancer pushes throughput higher and Alpenglow compresses block times, the gap between a well-managed RPC endpoint and a noisy one gets wider, not smaller. More blocks per second means more state changes per second, more concurrent requests, more pressure on the infrastructure sitting between your application and the chain. A faster validator layer doesn't absorb that pressure — it increases it. That's where Chainstack's Solana RPC comes in. Not as an afterthought to the validator client discussion, but as the layer that actually determines what developers experience when the underlying network changes beneath them. Firedancer and the broader Solana roadmap Firedancer doesn't exist in isolation. Alpenglow, Solana's proposed consensus overhaul, introduces Rotor as its broadcast layer and targets sub-second finality. Those goals are much easier to pursue with a client that can keep up. Firedancer’s throughput and latency profile complements Alpenglow and helps make its targets more realistic. Without a client capable of sustaining that performance under real network conditions, the finality targets stay theoretical. For application developers, sub-second finality changes what's buildable. Onchain interactions that currently require optimistic UI updates to feel responsive become genuinely low-latency. Confirmation times stop being a UX constraint you design around. The implications sharpen when you look at SIMD-0370, an actively debated proposal that would remove the block-level compute cap. The discussion is ongoing and contested, with objections raised around validator economics, self-throttling, and centralization risk, but if passed, it would reduce one of the fixed software ceilings on how much work the network can do per block. What replaces it is Firedancer's parallel execution capacity, which means the fee market's actual governor shifts from a hardcoded rule to the physical limits of the hardware validators are running. That's a meaningful change in how the network's constraints are defined. A software cap can be raised or lowered by governance vote. A hardware-defined limit is determined by what the infrastructure can actually sustain, which ties network economics directly to the performance characteristics of the validator set in a way they haven't been before. Quantum readiness: Falcon comes to Firedancer Firedancer's architecture also positions Solana well for a challenge that isn't immediate but isn't distant either: quantum computing. In April 2026, Anza and Firedancer both independently concluded that protocol-level quantum readiness should be built in before it’s needed. Both teams landed on Falcon, a post-quantum signature scheme selected by NIST, with Firedancer's team noting that its compact signature size makes it a natural fit for a high-throughput network. The transition is not expected to meaningfully affect throughput, which says something about how the architecture was built from the start. Conclusion  The 1M TPS number gets the attention, but it's the wrong thing to focus on. No application needs a million transactions per second today, and benchmarks run under controlled conditions tell you less than you'd think about how a system behaves under adversarial load or network partitions that actually stress production infrastructure.  Firedancer is a ground-up rewrite built on different assumptions. Isolated processes, pre-allocated memory, kernel bypass networking, SIMD signature verification, hardware-aware tile placement. None of these are optimisations bolted onto an existing design and they reflect a different starting point by taking hardware seriously.  The more consequential changes are structural. If SIMD-0370 passes and removes the compute cap, the fee market will be governed by what validators can physically process, and that makes the performance gap between clients an economic variable, not just an operational one. Alpenglow's finality targets assume a client underneath them that can sustain the throughput. And the 33% threshold, once crossed, changes what a single-client failure can actually do to the network. Firedancer looks less like the conclusion of Solana’s infrastructure work and more like the foundation that makes the rest of the roadmap more achievable. 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. Building on Solana? Deploy your Solana node on Chainstack → FAQ What is Firedancer on Solana? Firedancer is a high-performance Solana validator client built from scratch in C by Jump Trading. Unlike Agave, which is the dominant Rust-based client, Firedancer uses an isolated tile architecture, kernel-bypass networking, and pre-allocated memory to minimize latency and maximize throughput. It runs independently of Agave, which increases client diversity on the network. What is the difference between Firedancer and Agave? Agave runs as a monolithic process — networking, execution, and consensus share the same memory space. Firedancer separates work into isolated tiles, each mapped to dedicated CPU resources. Firedancer also bypasses the Linux kernel for packet processing using AF_XDP and eBPF, and handles Ed25519 What is Frankendancer? Frankendancer is a hybrid validator client that combines Firedancer's C-based networking layer with Agave's Rust execution engine. It was released as an intermediate step before the full Firedancer client was ready, giving validators a way to adopt parts of Firedancer's architecture without waiting for the complete rewrite. Its performance ceiling is limited by Agave's execution layer, unlike the fully integrated Firedancer client. Is Firedancer live on Solana mainnet? Yes. Firedancer reached Solana mainnet in 2025. The full client — not the Frankendancer hybrid — is now available for validators to run. The key threshold to watch is whether Firedancer's stake weight crosses 33%, at which point no single client can halt the network alone. Does running Firedancer require different hardware? Firedancer's tile architecture assumes uncontested access to CPU cores, which means standard cloud configurations may not deliver the expected gains without tuning. In practice, running Firedancer well requires disabling hyperthreading, isolating cores from the kernel scheduler, and configuring CPU affinity so each tile owns its assigned core. These are requirements, not optional tweaks. Related reading Solana node types: validator, RPC, and trader nodes Solana trading infrastructure 2026: MEV, nodes, latency Enterprise Solana infrastructure: What matters in 2026 How to build a Solana trading bot Best Solana RPC providers for fast and reliable production in 2026 #### What is Hyperliquid? RPC, API, and trading infrastructure Hyperliquid was built for speed and trading first, everything else second. An on-chain order book, a validator set tuned for latency, and an EVM layer for contracts. The rest of this guide shows how to plug in: RPC endpoints, APIs, and reliable node access. Most chains start from smart contracts and tack trading on later. Hyperliquid flips that order. It’s built first for speed, with a validator set tuned for low-latency confirms and an on-chain order book that runs perpetuals like a native feature, not a dApp. Blocks close in under a second, and every match is final. At the same time, Hyperliquid ships an EVM environment that runs standard Solidity contracts against the same ledger. That mix — trading engine + general compute — shapes how developers connect through RPC and API. Before getting into endpoints and tooling, let’s break down the chain itself. What is Hyperliquid? Hyperliquid runs its own Layer-1 protocol designed for trading. It uses Proof-of-Stake with a custom algorithm called HyperBFT, adapted from Meta’s LibraBFT. The consensus layer is optimized for low-latency transactions: blocks finalize in about 0.2 seconds on median, and even at the 99th percentile, confirmations land under a second. The speed comes from a Tendermint-based Byzantine Fault Tolerant engine and a deliberately small validator set. Only a few dozen validators take part today, which keeps latency low but trades off the scale of larger networks. On top of this, Hyperliquid runs a dual execution environment under one state and consensus: HyperCore – the trading engine. It manages the perpetual futures and spot order book directly on-chain. Orders, cancels, and liquidations all finalize in a single block. The state machine is purpose-built for exchange operations. HyperEVM – an Ethereum-compatible environment secured by HyperBFT and the same validator set. It lets developers deploy Solidity smart contracts that can interact with the trading state. For a deeper look at how HyperCore and HyperEVM operate under one consensus layer, see our guide on Hyperliquid infrastructure and RPC architecture. The chain is built for high throughput. It handles more than 200,000 transactions per second compared to Ethereum’s ~15. Gas fees are negligible — usually less than a tenth of a cent per trade. All market activity, including advanced order types like limit or conditional, is written to the chain order book, and nothing is hidden off chain. The result is decentralized trading with the speed and user experience of a centralized exchange. What Hyperliquid is built for Hyperliquid’s first focus is derivatives. The chain runs a perpetual futures exchange with up to 50× leverage on major assets. All trades are matched on-chain and settle straight to wallets. The bigger play is infra for low-latency DeFi. Because HyperEVM sits next to the book, contracts can hook into live trading data. A lending app can liquidate against the chain’s own price feed. Stablecoins and AMMs can use the same liquidity instead of splitting it across pools. So Hyperliquid isn’t just a DEX. It’s both a trading platform and a base layer for financial apps that need real-time settlement and high throughput. Building on Hyperliquid: SDKs, APIs, and testnet With Hyperliquid, you get a growing stack of trading tools to work with, including: SDKs and libraries Official client SDKs are available in Python and Rust. They expose trading functions, market data, and account management programmatically, so you don’t have to work with raw API calls. The SDKs simplify building bots or integrating Hyperliquid markets into apps — fetching order book depth, placing orders, or managing positions can all be done in a few lines. APIs (JSON-RPC and REST) Hyperliquid exposes two main API surfaces: JSON-RPC and REST. JSON-RPC runs on HyperEVM. It covers block, transaction, and contract queries, which means existing Ethereum tooling — Web3 libraries, ethers.js, MetaMask — can connect to a Hyperliquid node like it would to any other EVM chain. REST API is aimed at trading. Endpoints handle order submission, cancels, fills, and streaming market data. For real-time performance, you can subscribe to WebSocket feeds that push updates on order book changes and executions. This way, you get both sides of the chain: compatibility with EVM smart contracts and direct hooks into HyperCore’s trading engine. Explorers and dashboards You can use explorers to monitor activity + debug contracts. The main options available are: HypurrScan — shows blocks, transactions, and chain order book stats in real time. It also tracks auction prices, TWAPs (time-weighted average prices), transaction history, and token data on Hyperliquid’s L1. HyperEVMScan — focused on the smart contract side. Works like Etherscan, letting you search contract transactions and wallet addresses. Useful for debugging and tracking usage on HyperEVM. Third-party dashboards — platforms like Dune, or custom builds, can ingest Hyperliquid data to visualize trading volume, open interest, latency, and other metrics over time. Docs, testnet, and HYPE faucet Hyperliquid keeps docs in the GitBook and API references. They cover both sides of the chain — HyperCore and HyperEVM — and there’s a public testnet where you can deploy contracts or try trading setups without risk. It’s the usual entry point if you just want to get a feel for the chain before going live. Public faucets are often slow, rate-limited, or require verifications. That's why on Chainstack, we run our own Hyperliquid testnet faucet so you can grab HYPE tokens instantly and focus on building. With a funded wallet, you can deploy Solidity contracts on HyperEVM or test perpetual futures bots straight away. Claim HYPE testnet tokens → How to run a Hyperliquid node To build on Hyperliquid, you need to connect through RPC. Running your own node is possible, but heavy. The HyperEVM client has to be compiled, and the chain’s order book synced from genesis — requiring serious compute and storage. Most teams decide to skip that overhead and use a managed RPC. A good endpoint gives you full access to HyperEVM and HyperCore without worrying about uptime or latency. For trading, missing a price feed or a cancel is costly, so stability matters more here than on most chains. If you want to skip the overhead of running your own node, on Chainstack, you can get ready-to-use HTTPS and WebSocket endpoints. The nodes are fully synced, patched, and served from our global network with 99.9%+ uptime SLA. That means your trading bot or dApp connects to a stable, low-latency endpoint instead of a public node that might stall under load. Set up a Hyperliquid 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 Hyperliquid as the network and choose mainnet or testnet. Deploy a node configured for RPC access. Once deployed, your private RPC URLs — including /evm and /info endpoints — are available in the node dashboard. With both JSON-RPC and trading-specific endpoints exposed, you can run smart contracts and real-time trading logic from the same connection. Building on Hyperliquid? Deploy your Hyperliquid node on Chainstack → Wrapping up If you’re building on Hyperliquid, Chainstack is the easiest way in. We run the full stack end-to-end so you don’t have to piece things together. Everything you need to go from first deploy to production is in one place: Spin up your own Hyperliquid node on Chainstack and connect through private RPC. Use the Chainstack faucet to grab HYPE test tokens and fund your dev wallet. Check the HyperEVM method availability table for a live view of 100+ RPC methods and their support status. Run archive nodes and WebSockets on Hyperliquid HyperEVM mainnet for both historical lookups and realtime streams. Browse the Hyperliquid API reference for details on endpoints and payloads. And if you’re testing bots, there’s a ready-to-clone trading bot repo on GitHub. Power-boost your project on Chainstack FAQ What is Hyperliquid? Hyperliquid is a Layer-1 blockchain built for high performance trading. It runs a native order book at the protocol level with sub-second finality, and also includes HyperEVM for Ethereum-compatible smart contracts. How do I get Hyperliquid RPC endpoints? You can create a node in the Chainstack console, choose mainnet or testnet, and deploy it. Once live, your HTTPS and WebSocket RPC URLs — including /evm and /info — are available in the node dashboard. Does Hyperliquid support smart contracts? Yes. HyperEVM is an Ethereum-compatible environment where developers can deploy Solidity smart contracts. These contracts can interact directly with the on-chain order book and trading data. How do I connect a trading bot to Hyperliquid RPC? Deploy a Hyperliquid node on Chainstack and copy the private RPC URLs. Add them to your bot configuration so it can read order book data and submit transactions through a stable endpoint. What is the Hyperliquid API used for? Hyperliquid exposes both JSON-RPC and REST APIs. JSON-RPC supports standard EVM queries such as blocks, transactions, and contract state. The REST API covers trading actions like submitting or canceling orders and streaming market data. Where can I get HYPE test tokens for Hyperliquid? Chainstack provides a Hyperliquid faucet where you can instantly claim free HYPE tokens for testnet. With these tokens, you can deploy contracts on HyperEVM or simulate trading strategies without using real assets. Does Hyperliquid have archive nodes and WebSockets? Yes. Archive nodes and WebSockets are available on Hyperliquid HyperEVM mainnet. Archive nodes let you query full historical state, while WebSockets provide real-time trading and contract data streams. #### What Is MegaETH? Architecture, RPC, throughput guide Introduction: a different kind of L2 Most Ethereum Layer 2s are built around a single premise: make transactions cheaper. MegaETH starts from a different assumption entirely. It is an Ethereum-compatible L2 that targets 100,000 transactions per second with blocks produced every 10 milliseconds, not to reduce costs but to eliminate latency. At that cadence, the category of applications worth building changes. Real-time trading, on-chain gaming, and high-frequency state updates stop being theoretical and start being tractable. It also changes what becomes hard to build. On a slower chain, a mediocre RPC provider or a naive polling loop is an inconvenience. On MegaETH, those same choices become immediate failure modes. When a new block arrives every 10 milliseconds, infrastructure that was never designed for that cadence breaks in ways that are difficult to anticipate and easy to misdiagnose. This is why building on MegaETH feels less like conventional blockchain development and more like low-latency systems engineering. The RPC provider you choose, the subscription method you use, the transport layer you default to all carry consequences that simply do not appear on slower chains. MegaETH architecture: how it actually works MegaETH is built on the OP Stack and settles to Ethereum L1, which means it inherits Ethereum's security model and its familiar JSON-RPC interface. But the execution layer above that foundation works differently from any other OP Stack chain. Source: A node comparison of MegaETH to traditional blockchain networks Standard EVM block headers were not designed for 100 blocks per second. Mini-blocks solve this by stripping the format down to what real-time streaming actually needs. Transactions, receipts, and state changes, produced every 10 milliseconds. EVM blocks follow every second, in the standard Ethereum format that existing wallets, indexers, and tooling already understand. Every transaction appears in both. The mini-block gets you the result fast. The EVM block packages it into something the rest of the ecosystem can read. For most developers, EVM blocks are invisible in the sense that existing tooling works without modification. Where the distinction becomes a design decision is in event-driven architecture. If your application subscribes to new block headers and reacts to on-chain state, what it actually receives depends on what the RPC layer exposes. A provider that only surfaces EVM blocks gives you one event per second regardless of how fast the chain moves. A provider that exposes mini-block subscriptions gives you one event every 10 milliseconds. For a trading system or game backend, those are not equivalent choices. The other assumption MegaETH breaks is around gas estimation. The chain uses a multidimensional gas model that tracks multiple resource dimensions rather than collapsing everything into a single gas number. Local EVM simulation, the approach most Ethereum tooling defaults to, does not correctly model this. Developers who rely on Hardhat or Foundry for gas estimates and carry those numbers into production will encounter failures that do not appear in testing. Gas estimation on MegaETH needs to go through the RPC, not local simulation. It is a small change in practice but one that catches teams off guard consistently enough to be worth treating as a first principle. Throughput at 100K TPS: what it means in practice The 100,000 TPS figure is real, but it is not the number that should drive your infrastructure decisions. The number that matters is how many RPC requests your application generates as a consequence of that throughput. At 10ms block cadence, an application polling for new blocks needs to fire at least 100 requests per second just to stay current. One that subscribes to events and processes logs on each block handles 100 subscription notifications per second at steady state. One that tracks transaction confirmations is doing so against a chain that has already advanced several blocks by the time each response arrives. These are not edge cases. They are the baseline operating conditions for any application built to take full advantage of MegaETH's speed. This is why raw TPS is a misleading starting point for capacity planning. A more useful frame is request multiplication: for every transaction your application processes, how many RPC calls does it generate, and at what frequency? On slower chains that ratio is forgiving enough that most providers absorb it without issue. On MegaETH it gets large fast, and the provider's ability to sustain that load without rate limiting, increased latency, or dropped subscriptions becomes the real constraint. Ethereum MainnetMegaETH (EVM blocks)MegaETH (mini-blocks)Block interval~12 seconds~1 second~10 millisecondsBlocks per minute~5~60~6,000newHeads events per minute~5~60~6,000Poll frequency needed to stay currentonce per 12sonce per second100x per secondConfirmation tracking round tripslowmoderatevery high The Realtime API: MegaETH's hidden unlock On a standard EVM chain, the transaction confirmation flow is a two-step process. You submit a transaction with eth_sendRawTransaction, get a transaction hash back, and then poll eth_getTransactionReceipt in a loop until the receipt appears. On Ethereum mainnet, where blocks arrive every 12 seconds, this is tolerable. On MegaETH, where a transaction is packaged into a mini-block within 10 milliseconds of arrival, the polling loop becomes the bottleneck. You are introducing artificial latency into a system specifically engineered to eliminate it. MegaETH's Realtime API addresses this directly. The key method is realtime_sendRawTransaction, which submits a transaction and blocks until the receipt is available, returning it in a single round-trip. No polling, no receipt loop, no managing the gap between submission and confirmation. The sequencer processes the transaction, packages it into a mini-block, and the method returns with the full receipt. The entire flow collapses from two steps into one. const { ethers } = require("ethers"); const provider = new ethers.JsonRpcProvider("YOUR_CHAINSTACK_ENDPOINT"); const wallet = new ethers.Wallet("YOUR_PRIVATE_KEY", provider); async function sendWithRealtime() {   const tx = await wallet.populateTransaction({     to: "0xRecipientAddress",     value: ethers.parseEther("0.01"),   });   const signedTx = await wallet.signTransaction(tx);   // Single call returns the receipt directly -- no polling required   const receipt = await provider.send("realtime_sendRawTransaction", [signedTx]);   console.log("Confirmed in mini-block:", receipt.blockNumber);   console.log("Gas used:", receipt.gasUsed); } sendWithRealtime(); The Realtime API also extends eth_subscribe to expose mini-block level events. Subscribing to miniBlocks over WebSocket delivers each mini-block's full set of transactions, receipts, and state changes as soon as it is produced, rather than waiting for the next EVM block to be sealed. const { WebSocket } = require("ws"); const ws = new WebSocket("YOUR_CHAINSTACK_WSS_ENDPOINT"); ws.on("open", () => {   ws.send(JSON.stringify({     jsonrpc: "2.0",     id: 1,     method: "eth_subscribe",     params: ["miniBlocks"],   })); }); ws.on("message", (data) => {   const message = JSON.parse(data);   if (message.method === "eth_subscription") {     const miniBlock = message.params.result;     console.log("Mini-block number:", miniBlock.mini_block_number);     console.log("Transactions:", miniBlock.transactions.length);     console.log("Timestamp (microseconds):", miniBlock.mini_block_timestamp);   } }); There is also eth_callAfter, which solves a specific problem that comes up frequently in DeFi workflows. If you send an approval transaction and then immediately want to simulate the follow-up swap, a standard eth_call might execute before the approval has been confirmed, producing a misleading result. eth_callAfter waits until the sender's nonce reaches a target value before executing the call, eliminating the race condition entirely. What makes the Realtime API the first thing to check when evaluating any provider is that it is not part of the standard Ethereum JSON-RPC specification. Providers have to explicitly implement it, and many have not. Chainstack documents Realtime API support for MegaETH, but regardless of which provider you use, confirming this before you build is not optional. A provider that only exposes eth_sendRawTransaction is not wrong, but it is leaving MegaETH's core speed advantage unreachable. Any application built around confirmation latency, real-time event delivery, or dependent transaction flows will be running at a fraction of what the chain can actually offer.  RPC on MegaETH: where standard assumptions break Moving to MegaETH with an Ethereum mindset will break your application in three specific places, and none of them are obvious until something goes wrong in production. newHeads subscriptions A provider can pass every standard compliance check and still silently cap your application at 1-second block resolution if it only exposes newHeads at the EVM block level rather than the mini-block level. Your event-driven logic fires, your code looks correct, but the 10ms advantage the chain was built for never reaches your application. Gas estimation MegaETH's multidimensional gas model means local simulation through Hardhat or Foundry will frequently undercount gas, producing "intrinsic gas too low" errors in production that never appeared in testing. Gas estimation has to go through eth_estimateGas on the RPC itself, not local tooling. Debug and trace access MegaETH's public endpoint does not expose debug_* or trace_* methods. Teams building transaction simulators, analytics pipelines, or operational tooling that depends on execution traces will hit a wall on public infrastructure and need a managed provider that explicitly documents debug and trace coverage for MegaETH. What makes these failure modes particularly costly is that none of them announce themselves clearly. A newHeads subscription works, gas transactions go through most of the time, and the public RPC responds correctly to standard calls. The degradation is silent. Your application runs, but it runs slower than it should, fails under load it should handle, or simply cannot support the use cases you are building toward. On a slower chain, the gap between a good provider and a mediocre one is a performance difference. On MegaETH, it is a product difference. Choosing infrastructure for production Supporting MegaETH and handling MegaETH well are not the same thing. A provider that lists MegaETH in its supported chains has cleared a low bar. What actually matters for production is a narrower set of questions: does it expose mini-block subscriptions, does it support realtime_sendRawTransaction, does it offer full debug_* and trace_* coverage, and can it sustain the request volume that a 10ms block chain generates without rate limiting or latency degradation?  Shared infrastructure is a reasonable starting point but it has a ceiling. On slower chains, shared RPC can carry production workloads indefinitely because the request volume stays manageable. On MegaETH, a high-throughput application, a trading bot running confirmation loops, a game backend tracking state on every mini-block, or a consumer app spiking during a viral moment, will eventually saturate shared infrastructure in ways that are hard to predict and harder to debug. Dedicated nodes remove that ceiling. They give you isolated compute, predictable latency, and the ability to run sustained burst traffic without competing against other tenants. The right time to move is before you need to. Pricing model is also worth thinking through carefully at this scale. Credit and compute unit models that work fine on Ethereum become difficult to forecast on MegaETH because request volume is so much higher. A method-weighted pricing model that charges differently for eth_call, debug_traceTransaction, and standard reads can produce bills that are genuinely hard to predict when you are generating hundreds of requests per second. Flat-rate or request-unit models are easier to budget against at high throughput. The predictability of the pricing structure matters almost as much as the headline price. Criteria What to checkMini-block Provider exposes miniBlocks via WebSocket, not just newHeads at EVM block levelRealtime API supportProvider implements realtime_sendRawTransaction and eth_callAfter, not just standard eth_sendRawTransactionDebug and trace access Provider explicitly documents debug_* and trace_* method coverage for MegaETHGas estimation Provider supports eth_estimateGas correctly against MegaETH's multidimensional gas modelThroughput capacity Provider can sustain 100+ requests per second without rate limiting, latency degradation, or dropped subscriptionsInfrastructure tier  Dedicated nodes available for production workloads, not just shared infrastructurePricing modelFlat-rate or request-unit pricing rather than method-weighted compute units, which become unpredictable at high request volumes Production readiness: what to get right before launch MegaETH surfaces infrastructure problems as application bugs. A confirmation loop that polls every 500ms works fine on Ethereum and falls apart on a chain where the relevant mini-block has come and gone before the first poll fires. A WebSocket connection without reconnect logic survives occasional drops on a quiet chain and breaks under the sustained pressure of mini-block subscriptions. The monitoring signals that matter most before launch are p95 and p99 RPC latency rather than averages, WebSocket reconnect frequency as a direct measure of subscription stability, 429 response rates as an early warning on provider tier limits, and block lag as the clearest sign that your infrastructure is falling behind the chain. The public MegaETH endpoint is the right place to start. It handles prototyping and contract validation well. The mistake is staying on it too long. Providers take time to evaluate, dedicated nodes take time to provision, and finding out your infrastructure cannot keep up during a traffic spike is a worse outcome than migrating early. Build on the public endpoint, but treat the move to managed infrastructure as part of the launch plan rather than something to figure out later. Conclusion MegaETH is genuinely new infrastructure. A different execution environment with different failure modes, different tooling requirements, and a different relationship between infrastructure quality and application capability. Treating it like a drop-in Ethereum replacement means leaving most of what it offers unreachable.  The developers who get the most out of it will be the ones who verify Realtime API support before committing to a provider, route gas estimation through the RPC rather than local tooling, and treat the move to dedicated infrastructure as part of the launch plan rather than an afterthought. Get started with MegaETH on Chainstack. Start building on Chainstack → FAQ Do I need to rewrite my Ethereum code for MegaETH? Not entirely. Existing tooling works, but gas estimation and event subscriptions need to be updated — local simulation breaks, and newHeads subscriptions must expose mini-blocks to get full speed. Why does gas estimation fail with Hardhat or Foundry? MegaETH uses a multidimensional gas model that local simulators don't model correctly. Route all gas estimation through eth_estimateGas on the RPC instead. What is the difference between mini-blocks and EVM blocks? Mini-blocks are produced every 10ms and carry transactions, receipts, and state changes. EVM blocks follow every second in standard Ethereum format. Every transaction appears in both. How do I know if my RPC provider supports the Realtime API? Check explicitly in their documentation for realtime_sendRawTransaction and miniBlocks subscription support. If it's not documented, assume it's not supported. When should I move from the public endpoint to a dedicated node? Before launch, not after. Shared infrastructure has a ceiling on MegaETH — evaluate providers early, dedicated nodes take time to provision. How do I monitor if my app is keeping up with block speed? Track p95/p99 RPC latency, WebSocket reconnect frequency, 429 response rates, and block lag. Averages will hide problems that p99 makes visible. Additional resources MegaETH methods MegaETH Chainstack tooling How to get a MegaETH RPC endpoint Best MegaETH RPC providers for high-throughput apps #### What is MEV and how does Solana solve its MEV issues Introduction MEV, or “maximal extractable value”, “miner’s extractable value”, and “maximum extractable value”, is a unique word in the blockchain space. Despite several variants of the term, nowadays MEV usually refers to extracting the value from transaction ordering on the chain. In this article, we will take a look into MEV: how people do it; the scale of this problem, and how blockchains like Solana deal with it. Below is a brief outline of this article: The evolution of MEV The impact of MEV on Ethereum The differences between Solana and Ethereum The common types of MEV activities From MEV (miner extractable value) to MEV (maximal extractable value), the evolution of blockchain You may come across MEV many times, but most likely in different forms: Maximal extractable value Maximum extractable value Miner extractable value And you are wondering if they mean different things. Well, the short answer is no. They are referring to the same thing. Let us start with Ethereum because that is where it all began. When Ethereum was proof-of-work, miners packed transactions into a block, and they were able to decide to include or exclude certain transactions or rearrange the order of these transactions. This gave the miners an advantage over regular users. For example, this is Derp and Derp wants to buy an NFT: Figure 1: MEV frontrunning an NFT purchase That was an oversimplified illustration of NFT frontrunning, which is one type of MEV. When a miner decides to play around with the system, there is no effective mechanism to protect regular users from the attack. And the worst part is, that Derp even must pay the miner gas fee for validating his transaction. And that is why MEV was called “miner extractable value” initially. Because in theory, only the miner can decide the ordering of transactions in a block. In practice, however, a large portion of MEV is extracted by independent network participants, who were referred to as "searchers". This is because: On Ethereum, pending transaction information is transparent to all users through a node’s mempool. The order of transactions depends mostly on the amount of gas fee included in each transaction. Taking Derp as an example. Derp wants to buy another NFT. This time, he makes sure that his miner is not a malintent miner. Derp sends his transaction request paying a 0.1 ETH gas fee. Derpina sees Derp’s transaction and decides to front-run this transaction. So, she sends a duplicate transaction, but with a higher gas fee. The miner packages Derpina's transaction first because the gas fee is higher. As a result, Derp’s transaction fails, and Derpina gets the NFT. Poor Derp lost his gas fee too. This was also an oversimplified example. In the real world, MEV activities are far more complicated and diversified. Searchers run complex algorithms on blockchain data to detect profitable MEV opportunities and have bots to automatically submit those profitable transactions to the network. Since MEV is no longer limited to miners, MEV eventually becomes the common abbreviation of “maximal extractable value” instead of “miner extractable value”. But people still use them interchangeably. The endless debate around MEV Some people see MEV as a threat to the ecosystem for example Vitalik Buterin. Figure 2: Vitalik Buterin's tweet on frontrunning back in 2020 But there are also many people who believe that banning MEV will eventually lead to corruption of the “decentralization” aspect of a blockchain. Initially, on Ethereum, MEV was brought to people’s attention as early as 2018. Since then, millions of dollars have been spent to battle against MEV activities. However, there has not been one concrete solution to it yet. According to a BIS report, the amount of MEV has increased exponentially since 2019. in 2022, the total MEV on Ethereum has amounted to an estimated USD 550–650 millions, which is 5 times the amount two years ago. Figure 3: Measures of miner extractable value are accumulating over time; Source: BIS(https://www.bis.org/publ/bisbull58.pdf) Being a completely different type of blockchain, Solana has MEV issues just as Ethereum. In this article, we will take a closer look into MEV on Solana. Differences between Solana and Ethereum Solana is a very different blockchain. Some characteristics of Solana make it not suitable for certain MEV activities. First, let us look at how Solana and Ethereum are different. Solana is a proof-of-stake (PoS) chain. In a PoS chain, instead of miners, validators finalize transactions. Each validator node is staked with a large number of tokens, which serves as a security deposit to ensure the performance and reliability of a validator. On Ethereum as of proof-of-work, there was no effective mechanism to penalize a faulty miner. However, this is not hold true after the merge. Solana validators are grouped into clusters. to finalize a transaction, all validators in a cluster vote to decide if the transaction is valid.At each point in time, one cluster has one leader. The leader decides only the order of transactions to be voted, but not the finality of the transaction. Each validator takes turns acting as the leader validator.This ensures its safety will not be compromised by a single bad actor. Unlike Ethereum, Solana nodes do not have a mempool, which means searchers can’t target individual transactions unless they are a validator. Solana has a standardized gas fee, which means searchers can’t front-run or back-run any transaction. (We will talk about front-running and back-running later). Non-leader validator nodes vote for transactions in FIFO (first in first out) order, which limits the possibility that any malintent validator holds certain transactions indefinitely. All these make some MEV techniques from Ethereum not viable on Solana. However, Solana nurtures its own MEV issue, which will be discussed below. Technical requirement Nowadays many MEV strategies are around DeFi platforms. To analyze the current MEV situation on Solana, we choose Raydium for our research. Raydium is one of the biggest Automated Market Maker (AMM) exchanges on Solana. According to DefiLlama, it has $218M TVL (total value locked) at the time of writing (August 2022). Figure 4. Total value locked in Raydium from DefiLlama Here is an online Python script to extract and analyze data from Raydium. It is hosted on Google Colab. It is a notebook script—you can either run it in your browser or download the file and run it with a local Jupyter notebook. The detail of this Python script can be found in this article. In order to run the script, you will need a Solana endpoint. The sample code is developed and tested with a Chainstack Solana node endpoint—it is highly recommended for the following reasons: No limits on the request rate. Free Solana node endpoint with 3 million free requests. Fast node deployment. MEV on Solana Types of MEV techniques - DEX arbitrage How does it work? Decentralized exchange (DEX) arbitrage is likely to be the most common MEV activity. Imagine two DEX on Solana, Raydium, and Orca, each has its own liquidity pool. At one point in time, they are offering SOL and USDC swap pairs at different exchange rates. Arbitrage traders seek opportunities like this. They will make two swap transactions to Raydium and Orca, earning profit from counter swapping SOL -> USDC -> Sol. Simple as that. Figure 5. Counterswapping SOL/USDC Case study Below is an example of a profitable arbitrage transaction where a searcher turned 8.2452 USDC into 8.2682 USDC by taking advantage of different pricing on Raydium and Orca. https://solscan.io/tx/dr1SYktYnvC2gGmTboznf28q1CDrXJzwBELmPi2CG1cqJ3iwR9Nbv9nqjQPkvuJ62yaPr6V2qbHh89wkhg9zmjC https://solscan.io/tx/5DoA8mdhb1GQFGKbdsR8zsJbNHoMDPWwJXStn4haCtWLUCPFwh841GUn11F9hjzvfWiyPWJ9GncJjx14SM6f7D7C Arbitrage on Solana In a stable market, arbitrage trading is usually profit guaranteed and relatively simple to set up. So there are many arbitrage bots running on Solana. Arbitrage trading is very competitive. Of all transactions on Raydium, about 80% are failed or invalid arbitrage transactions. In the Solana community, the opinion on arbitrage is diversified. Some people think arbitrage is bad because it congests the network and is wasting computation resources. Others treat arbitrage as a market corrector. It ensures the DEXes have a uniform exchange rate across platforms, even across chains. Analysis The profitability of arbitrage is co-related to the volatility of the crypto market. It is because the only time arbitrage works are when there is a significant exchange rate mismatch between two liquidity pools. In a volatile market, for example (an extreme one though) during Terra’s collapse, when every holder of Luna tries to escape at any cost, the exchange rate of Luna and USDC falls almost 100%. That is when an arbitrage opportunity arises. Types of MEV techniques—sandwich trading, front-running, and back-running Sandwich trading is another type of MEV extraction technique. Sandwich trading is sometimes referred to as a sandwich attack because it happens around a target transaction, and a successful sandwich trading will result in an increase How does 🥪 trading work? To sandwich, a searcher will watch the mempool for large DEX trades. For instance, suppose Derp wants to exchange 10k SOL for USDC on Sushi swap. Figure 6. Exchange rate before a large swap A trade of this magnitude will significantly reduce the amount of SOL in the liquidity pool. Resulting in a significant increase in the price of USDC. Figure 7. Exchange rate after a large swap This is an ideal target for sandwich trading. A searcher can measure the approximate price change, and decide to front-run, back-run, or sandwich attack Derp’s transaction. Sandwich trading in a nutshell: Searcher buys 40000 USDC before Derp’s transaction with 1000 SOL (front-run). Derp’s transaction makes USDC cheaper, the exchange rate is now 1:38. Searcher sells the 40000 USDC for 1052.6 SOL. Making a 5% profit. Finding sandwich trading on Solana After carefully examining 600K transactions in Raydium, no evidence of a sandwich attack was found. A typical sandwich trading has 3 parts: A "victim" transaction; a front-run and a back-run transaction that contains the same trading pair as the victim transaction. A successful sandwich attack should have the following characteristics: The attacker exchange X amount of tokens in the front-run transaction and immediately swap back the same amount in the back-run transaction. There is a potential "victim" transaction that contains the same token pair between the front-run transaction and the back-run transaction. The front-run transaction and the back-run transaction are executed relatively close, usually within a few seconds. After examining all the transactions from Raydium, there is no transaction that matches the above characteristics. So, why is the Solana sandwich attack free? On Ethereum, there are several features that are necessary for sandwich trading. One of the primary features is its mempool design. On Ethereum, everyone has access to the mempool and anyone can examine the transactions before they get finalized. In contradiction, Solana is a mempool-less chain. Theoretically only validators, in fact, only the leader validator has access to the transactions. But in a PoS chain like Solana, the suspicious activity may cause the validator to lose its deposit/stake, which ensures the reliability of the network. Types of MEV techniques—NFT bot MEV in the NFT space is an emerging phenomenon, especially on Solana. For example, if there's a popular NFT launch and a searcher sees that as a profitable opportunity. Figure 8. MEV NFT opportunity NFT bots will swarm the NFT minting program with mint requests, trying to get as many tokens as possible in a short period of time and resell them immediately. Figure 9. NFT bots spamming mint requests during NFT launch NFT bot wasn't considered a threat until people realized that it not only damage the NFT market but also congests the network as no other MEV bot does. Battling with NFT bots One solution to the MEV bot is adjusting the transaction gas fee, which increases the cost of sending spam requests on Solana. That is also the reason why the NFT MEV bots are less significant of a problem on other blockchains like Ethereum. Another solution from Solana’s primary NFT minting program Metaplex is imposing a “tax” for invalid transactions. Which also increases the cost of sending invalid requests. Metaplex also introduces Dynamic pricing Mint. Basically, the more popular an NFT is, the higher the launch price will be. Which disincentivized bots from swarming an NFT launch. Both initiatives are announced recently, hoping to solve Solana’s botting problem. Conclusion There is always a lot to explore in MEV, especially with the latest Ethereum transition to proof-of-stake. If you want to experiment with MEV, you can do so with our MEV API on the Ethereum Mainnet and the Ethereum Goerli Testnet. In this article, we talked about: What is MEV and how it has evolved over time. The differences between Solana and Ethereum. What are the MEV activities on Solana and how do people tackle the issues. Hope you find it useful and enjoy reading it. For any questions, feel free to ping me on Twitter/Telegram/Discord. Happy coding. Cheers. #### What is Nethermind? Ethereum execution client (2026) A node is any computer or server that runs software to connect to the Ethereum network, including an execution client and consensus client. An Ethereum execution client is software that processes transactions, executes smart contracts, and maintains the blockchain’s current state. The consensus enables nodes to reach agreement using validated data from the execution client. The Ethereum community maintains five major open-source execution clients: Nethermind, Geth (also known as Go-Ethereum), Reth, Besu, and Erigon. Each one runs the same protocol, validates the same blocks, and serves the same JSON-RPC interface, but is built using different programming languages and different approaches. Ethereum maintains its decentralization in part due to the diverse set of clients. Nethermind is the second-most popular execution client and the only major Ethereum execution client written in C# on the .NET runtime, enabling enterprise–grade speed and modular flexibility. This article examines what an execution client does, what Nethermind is, and what separates Nethermind from the other five major clients, including how Nethermind utilizes zero-knowledge proofs. What is an execution client? An execution client is the software that processes transactions on Ethereum. It runs and maintains the blockchain state, validates new blocks, and serves data through JSON-RPC. Every Ethereum node operator runs one execution client paired with one consensus client. The consensus client handles the proof-of-stake consensus agreement algorithm, while the execution client handles all transaction logic. The Ethereum community currently maintains and actively uses five core execution clients on the mainnet, with one in beta: Geth Nethermind Besu Erigon Reth EthereumJS (beta) Each client varies in its programming language and data synchronization methods, including how it downloads, verifies, and updates to the latest blockchain data, as shown in this graph. A table comparing the five major production-based Ethereum execution clients. Source: Ethereum Foundation Geth is the most popular with a 36% market share, followed by Nethermind at 23%. The rest are further behind: Reth (13.9%), Besu (11.9%), and Erigon (4.5%).  The distribution of Ethereum execution clients by market share. Source: Ethernodes.org Ethereum is decentralized in part by its client diversity. Client diversity reduces the risk of a single point of failure, as mentioned in the Ethereum documentation: Multiple, independently developed and maintained clients exist because client diversity makes the network more resilient to attacks and bugs. Multiple clients are a strength unique to Ethereum - other blockchains rely on the infallibility of a single client. Tomasz K. Stańczak, Founder of Nethermind, recently explained how AI agents need infrastructure that minimizes single points of failure, which is why Ethereum is a compelling choice for blockchain integration. https://twitter.com/Nethermind/status/2055256491901235579 What is Nethermind? Nethermind is an Ethereum execution client built in C# on the .NET runtime with an architecture that enables measurable performance gains over other clients. Nethermind is the second-most popular execution client, with over 1,383 of 5,991 nodes using it. A diagram illustrating the distribution of nodes among the top four major execution clients. Source: Ethernodes Unlike most managed runtimes, a .NET runtime gives Nethermind access to low-level optimization tools normally associated with systems languages, enabling better, enterprise-grade performance. In their open-source GigaGas benchmark, which reproduced identical Ethereum mainnet blocks across clients on the same hardware, Nethermind achieved a mean throughput of 697 million gas units per second (MGas/s), outperforming Geth, Besu, and Reth.  A diagram showing block-by-block throughput across clients. Source: Nethermind During stress tests that merged 100 consecutive mainnet blocks, Nethermind maintained a 2x to 10x throughput advantage, while Reth saw roughly 2x performance degradation. Nethermind maxed out at 1.08 gigagas per second (GGas/s), while others maxed out at 0.3-0.33 GGas/s. A diagram of GGas/s recorded during stress tests that merged 100 consecutive mainnet blocks across clients. Source: Nethermind Other benchmarks include processing 165,000 transactions per second in maximum-throughput tests, processing over 1 GigaGas per second on Base mainnet, and syncing to the chain tip in under 20 minutes.  Its default snapshot sync mode (generating state from relatively recent block and syncs from there to the head of the chain) syncs data 10x faster than a traditional fast sync (generating state by executing every block since genesis). A snapshot sync on Nethermind is the fastest among syncs on other execution clients. Nethermind uses C# and .NET features that enhance performance and close any gaps with systems that use languages such as Rust or Go, for critical EVM features, such as: NativeAOT compilation Managed runtimes normally translate code into machine instructions while the program runs, which adds a delay. Nethermind uses a fork of NativeAOT, a .NET deployment model that compiles the entire C# codebase ahead of time into a standalone machine-code binary.  Hardware intrinsics for accelerated bitwise operations. Bitwise operations are the low-level math that the EVM constantly performs on raw data bits, such as AND, OR, XOR, and shifts. Modern CPUs include specialized SIMD instructions that perform these operations on many bits in parallel rather than one at a time. Nethermind uses the .NET hardware intrinsics API across the client to call these CPU instructions directly, which makes heavy bitwise workloads run several times faster than they would in plain code. Nethermind vs. other clients Though clients operate similarly at a high level, they can choose to add unique features. Compared to other clients, Nethermind differs in runtime, operator tooling, and extensibility model, prioritizing execution performance and operator experience. Nethermind is the only major execution client built on .NET, while Geth and Erigon use Go, Besu uses Java, and Reth uses Rust. As mentioned earlier, the .NET runtime gives Nethermind direct access to a large enterprise development ecosystem and the C# language, which enables better performance. However, it does present engineering challenges that no other client faces, such as making .NET work in specialized environments like zkVMs. Nethermind is the only execution client to launch a native browser interface for monitoring node-related data, including sync status and execution logs. Operators of other clients must set up and host their third-party data tools for similar data views. A screenshot of Nethermind UI, a native browser interface for monitoring nodes using Nethermind Nethermind supports custom plugins, allowing node operators to extend the client with new features. For example, a JSON-RPC handler plugin adds a custom RPC method that returns any data that the operator chooses to a production Nethermind node. In this case, operators can expose business-specific queries, custom analytics, or proprietary node behaviors directly from Nethermind without maintaining a fork, rebuilding from source, or running a separate service in front of the node. Using zero-knowledge proofs in execution clients Nethermind is the only execution client that extends a production client to use zero-knowledge proofs, enabling a validator to verify the correctness of an Ethereum block by checking a single cryptographic proof rather than re-executing all transactions.  In other words, it aims for the execution client to compile to a zkVM, an Ethereum virtual machine that executes smart contracts in a way compatible with zero-knowledge proof computation. The Nethermind team describes the shift as moving from redoing every calculation by hand to instantly verifying the result with a mathematical guarantee, which results in faster, cheaper, and more trustworthy block verification across Ethereum. Direct examples include:  rollups achieving faster finality sequencers no longer needing to trust their hardware The zkReadiness roadmap on Nethermind. Source: Nethermind Five milestones on the path to full ZK readiness are already complete: Execution Witness is a compact data file that the client produces for any block, containing every piece of state that block touched. With the witness, any computer can replay the block and arrive at the exact same result, without needing a copy of the full Ethereum state. Stateless Executor is a command-line tool that takes a block and its witness file and replays the block from scratch, without touching disk or network. It demonstrates that witness-based execution works in practice and is foundational to other technical upgrades for zk readiness. Minimal EVM Binary is a stripped-down version of Nethermind's EVM that contains only the code needed to process a block from a witness. Networking, peer discovery, consensus logic, and every other runtime feature that a zkVM does not need have been removed. The smaller the binary, the cheaper and faster it is to prove inside a zkVM. RISC-V64 Compilation rebuilds the Nethermind client to run on RISC-V64, the instruction set used by most zkVMs. The result is a fully static, zkVM-friendly binary that runs at native speed through .NET's NativeAOT compiler. The team also added soft-float support so the client works on zkVMs that lack hardware floating-point math, and extended beyond .NET's minimal "Zero" library to a broader set of standard classes so real workloads function. For sequencers, this means execution speed will not be a bottleneck during proof generation. Zisk Integration connects the minimal EVM binary to Zisk, a zkVM built on RISC-V64, through custom linker scripts that wire the binary into Zisk's entry points and memory layout. As of April 2026, Nethermind is running real Ethereum mainnet blocks through Zisk with execution and validation confirmed. The next step is producing the first end-to-end zero-knowledge proof of an Ethereum block from a production execution client. An overview of the upcoming steps for zkVM integration shared on the Nethermind X account Two milestones remain on the roadmap. RISC0 and SP1 integration will add adapters so Nethermind's witness and executor outputs plug directly into the two most widely used zkVM proving systems in the industry.  Broader RISC-V compatibility will keep Nethermind aligned with whichever RISC-V targets dominate production zkVMs in the future, with the long-term goal of supporting any zkVM that emerges, including custom instruction sets. Conclusion The Ethereum community has five main execution clients, but Nethermind stands out, especially for teams seeking enterprise-grade performance and continuous technical advancements. As the second most-popular Ethereum execution client, it has a reputation within the Ethereum community for its stellar performance, operator tooling, and customization. It is the only major built on .NET and C#, meant to deliver performance that competes with systems languages like Rust and Go. This technical foundation is demonstrated by several critical benchmarks: Nethermind achieved a mean throughput of 697 million gas units per second, outperforming other execution clients like Geth, Besu, and Reth. In a 100-block stress test, Nethermind maintained a 2x to 10x throughput advantage. The team also sets the standard for natively built tools compared to other execution clients. It is the only client that offers a native browser interface for monitoring data, allowing operators to view client status and logs without a third-party tool. It provides a custom plugin system that allows operators to develop custom tooling.  Most recently, Nethermind is leading the implementation of zero-knowledge proofs to verify Ethereum blocks instead of re-executing them. Using zk-proofs for Ethereum execution makes block verification faster, cheaper, and more trustworthy across Ethereum. For teams prioritizing enterprise-grade performance, Nethermind is one of the strongest execution client choices. 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 your Ethereum node on Chainstack → FAQ What is an Ethereum execution client? An execution client is the software that processes transactions on Ethereum, maintains the blockchain state, validates new blocks, and serves data via JSON-RPC. Every Ethereum node operator runs one execution client paired with one consensus client. How many Ethereum execution clients are there? The Ethereum community currently maintains and actively uses five core execution clients on the mainnet: Geth, Nethermind, Besu, Erigon, and Reth. EthereumJS is in beta. Why does Ethereum need multiple execution clients? Client diversity reduces the risk of a single point of failure and makes the network more resilient to attacks and bugs. Multiple, independently developed and maintained clients are a strength unique to Ethereum. What programming language is Nethermind written in? Nethermind is built in C# on the .NET runtime. It is the only major Ethereum execution client written in C# on the .NET runtime. Is Nethermind faster than other Ethereum clients? Yes. In Nethermind's open-source GigaGas benchmark, which reproduced identical Ethereum mainnet blocks across clients on the same hardware, Nethermind outperformed Geth, Besu, and Reth and maintained a 2x to 10x throughput advantage under stress tests. Does Nethermind generate zero-knowledge proofs? Nethermind is the only execution client that extends a production client to use zero-knowledge proofs. As of April 2026, Nethermind is running real Ethereum mainnet blocks through Zisk, with execution and validation confirmed; the next step is to produce the first end-to-end zero-knowledge proof of an Ethereum block from a production execution client. Can I extend Nethermind with custom features? Yes. Nethermind supports custom plugins, allowing node operators to extend the client with new features, including custom JSON-RPC methods, without maintaining a fork, rebuilding from source, or running a separate service in front of the node. Which blockchains does Nethermind support? Nethermind supports the Ethereum mainnet and Ethereum-compatible chains. Resources Nethermind GitHub Nethermind Client Ethernodes Node client documentation on Ethereum Erigon vs Geth: choosing the right Ethereum client Ethereum roadmap 2026: Impact on nodes & validators #### What Is the Aptos Blockchain? Architecture & Ecosystem In recent months, Aptos has been gaining increasing attention across the Web3 ecosystem. Developer activity is rising, new applications are launching, and the network’s stablecoin market capitalization continues to grow—positioning Aptos as an emerging settlement and execution layer. But what exactly is Aptos, and why is it attracting renewed interest from builders, institutions, and infrastructure providers? Aptos is a Layer 1 blockchain designed for high throughput, low latency, and safe upgrades. Its core design combines parallel transaction execution, the Move programming language, and formal verification to support production-scale applications. This guide covers: Architecture: How parallel execution, pipelined processing, and Move-based resource semantics enable scalable and safe execution Transaction model: The five stages from submission to finality (see Lifecycle of a Transaction) Performance: 22k+ TPS sustained, $1.07M peak daily revenue, $1.7B in stablecoins, and 99.99% uptime Ecosystem: DEXs, liquid staking, RWAs, gaming, and Aptos' trajectory toward becoming a global trading engine Developer tools: Move Prover, Aptos CLI, SDKs, wallets, and modern onboarding infrastructure Let's explore how Aptos' architectural choices enable production-ready applications while differentiating it from earlier Layer 1 networks. What is Aptos? Aptos is a Layer 1 blockchain designed with scalability, safety, reliability, and upgradeability as core architectural principles developed by former Meta (Facebook) employees Avery Ching and Mo Shaikh, drawing directly from their experience working on Meta’s Diem (formerly Libra) blockchain initiative. The Aptos blockchain is built to address fundamental limitations observed in earlier blockchain systems, particularly around execution bottlenecks, state management, and long-term protocol evolution. Many of its design decisions reflect lessons learned during the development of Diem, a project that prioritized security, formal verification, and performance at global scale. At the protocol level, Aptos introduces a high-performance execution model built around the following core concepts: Core ConceptDescriptionParallel executionAptos uses a high-performance execution model that processes independent transactions concurrently rather than sequentially, significantly increasing throughput and reducing latency under high network load.Move languageAptos natively integrates the Move programming language, originally developed for the Diem project, enabling fast and secure transaction execution. Move enforces strict resource ownership and asset semantics at the language level, preventing common smart contract vulnerabilities by design.Formal verificationThe Move Prover allows developers to formally verify smart contracts by proving correctness of logic and invariants, adding an additional layer of security against unintended or malicious behavior.Pipelined processingAptos employs a modular, pipelined architecture in which transaction dissemination, ordering, execution, storage, and ledger certification operate concurrently, maximizing hardware efficiency and system throughput.Atomic executionThe network supports fully atomic parallel execution without requiring developers to specify read/write sets in advance, enabling complex transactions to execute efficiently while preserving correctness.Flexible dataAptos introduces an advanced data model that enables flexible key management, hybrid custodial options, and transaction transparency prior to signing, improving user safety and trust.Continuous upgradesA modular protocol design and embedded on-chain change management allow Aptos to deploy frequent, non-disruptive upgrades without requiring hard forks or network downtime.APT tokenThe APT token is used for transaction fees, staking, and governance, aligning economic incentives across validators and ecosystem participants. The name “Aptos” comes from the Ohlone language and means “The People”. This reflects the project’s broader goal of building resilient, high-performance blockchain infrastructure that serves a global, user-centric decentralized economy. Aptos Blockchain Architecture The Aptos blockchain leverages a proof-of-stake (PoS) consensus mechanism and is powered by a network of validators which process transactions and update the system. Its design enables complex operations to run efficiently while maintaining safety and upgradeability. Understanding Aptos requires looking at the types of nodes in the network, the components within validator nodes, and how transactions flow through the system. Node Types Aptos supports multiple types of nodes, each serving distinct roles in the network. Validator Nodes Validators are responsible for executing transactions, participating in consensus, and maintaining the integrity of the blockchain. Their operations include proposing and committing blocks, executing transactions, and updating the global state. Fullnodes Fullnodes provide access points for clients to interact with the blockchain. They validate and relay transactions, serve historical blockchain data, and act as intermediaries between clients and validators. Fullnodes can truncate historical data to optimize storage and performance while still maintaining correctness. Light Clients Light clients maintain only the current validator set and a minimal portion of the blockchain state. They are optimized for efficiency and resource-constrained environments, enabling faster queries without processing the full transaction history. The Aptos-core software can be configured to run as a validator node or as a fullnode, depending on whether the node will participate in consensus or primarily serve client requests. Validator Node Components Validator nodes are modular and consist of several key components that interact to process transactions efficiently. REST Service Entry point for clients submitting transactions or querying blockchain state. Forwards submitted transactions to the mempool and relays read requests directly to storage. Mempool Temporary buffer for transactions waiting to be executed, but not yet agreed upon. Shares transactions with other validators via the shared-mempool protocol. Performs initial validation such as sequence number checks before transactions are considered for consensus to protect against DoS attacks. Consensus Orders transactions into blocks and coordinates agreement across validators. Pulls transactions from the mempool, proposes blocks, executes them speculatively, and commits results once quorum agreement is reached. Execution Coordinates the execution of transactions using the Move Virtual Machine (VM). Maintains a transient “scratchpad” state to compute block execution results prior to committing. Supports atomic and parallel execution of transactions while ensuring correctness. Virtual Machine (VM) Validates and executes transaction scripts written in Move bytecode. Performs signature verification, sequence number checks, balance validation, and ensures transaction integrity. Storage Persists committed transactions, execution results, and account state. Receives inputs from both execution and the VM for read and write operations. Supports efficient pruning of temporary or obsolete data to optimize resource usage. Lifecycle of a Transaction A transaction in Aptos passes through a clear, five-stage lifecycle: Accepting The client submits a signed transaction to a fullnode’s REST service. The REST service forwards the transaction to the mempool for validation (sequence numbers, signatures, balances). Sharing The mempool shares transactions with other validators through the shared-mempool protocol. Incoming transactions from other validators are also validated before being added to the local mempool. Proposing A leader validator selects a batch of transactions from its mempool and proposes a block to other validators via the consensus component. Executing & Consensus Transactions are executed speculatively in the execution component using the VM. The execution results are submitted to consensus, which coordinates agreement with other validators. Once a quorum agrees, the block is marked ready to commit. Committing Execution writes the finalized transaction results to storage. Account sequence numbers and balances are updated. The block becomes part of the permanent blockchain ledger. Accounts Accounts on Aptos represent access control over a set of assets, including tokens and NFTs, which are modeled as Move resources. Each account is identified by a 32-byte address, derived from the authentication key, and can be created explicitly or implicitly by transferring APT tokens. Unlike some blockchains, Aptos accounts are explicit, enabling advanced features such as key rotation and native multisig. Authentication & Keys: Multiple authentication schemes: Supports Ed25519, Secp256k1 ECDSA, and K-of-N multisig for flexible single or multi-key account management. Aptos keyless accounts: Uses ZK proofs hide the link between Google/Apple/etc. logins with on-chain accounts and make self-custody usable for real people. Key rotation: Accounts can rotate authentication keys, replacing potentially compromised keys without changing the account address. Authentication key vs account address: The authentication key may change, while the account address remains fixed, ensuring continuity. Explicit Account Types: Standard accounts: Typical user accounts with public/private key pairs. Resource accounts: Autonomous accounts without private keys, used to store resources or publish modules. Objects: Collections of resources representing a single logical entity. Resources Aptos organizes on-chain state using Move modules and resources, stored within accounts. This differs from Ethereum, where each smart contract maintains its own storage. Resources vs Instances: Struct definitions in Move modules define abilities like key or store. Resources are struct instances with the key ability, stored under accounts. Stored instances with the store ability can exist inside resources. APT Coin Storage /// A holder of a specific coin type and associated event handles. struct CoinStore<phantom CoinType> has key { coin: Coin<CoinType>, } /// Main structure representing a coin/token in an account's custody. struct Coin<phantom CoinType> has store { value: u64, } /// Custom resource example struct CustomCoinBox<phantom CoinType> has key { coin: Coin<CoinType>, } CoinStore is a resource under an account; Coin is the transferable instance. Instances can be stored in other resources if the definition allows, providing flexibility for custom logic. Resource Organization & Permissions: Resources are defined within modules deployed at specific addresses, e.g., 0x1234::coin::CoinStore<0x1234::coin::SomeCoin>. Modules dictate permissions: access, modification, and removal of instances require authorization via the module. Ownership is tied to storing a resource in an account or module logic. Efficiency & Parallel Execution: Storing data under individual accounts reduces read/write conflicts and enables parallel execution of transactions, improving throughput and performance. Resources can be queried via Aptos Explorer or fullnode APIs, supporting lightweight access and verifiable state. To stay up to date with the latest developments and improvement proposals in Aptos, refer to the Aptos Governance for voting and Aptos Improvement Proposals (AIPs) repository for documentation of all AIPs. Performance and Scalability Aptos is engineered for real-world scale, prioritizing consistent performance, low latency, fast finality, predictable fees, and high reliability all intentionally aligned with mainstream user expectations. Applications built on Aptos can feel responsive and intuitive, closer to traditional web experiences, without sacrificing decentralization or security. https://twitter.com/AptosLabs/status/2011547635698794713?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E2011547635698794713%7Ctwgr%5E3631c9db40e416832aa41124e785007634ed91af%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2FIntroduction-to-the-Aptos-Ecosystem-Performance-Tools-and-Use-Cases-2eab408bc9a28012983cdfaa6ecfe721%3Fpvs%3D21 Network Health Aptos has maintained 99.99% uptime since mainnet launch in October 2022, reflecting a strong emphasis on operational stability and fault tolerance. Record transactions in 24 hours: 533 million Peak daily application revenue: $1.07M https://twitter.com/Aptos/status/2011241936821387295 Sustained throughput: 22,000+ transactions per second on mainnet Theoretical throughput ceiling: ~250,000 TPS Median block time: ~44 milliseconds Growing daily active accounts across DeFi, payments, gaming, social applications and more Active Nodes: ~129 validators spread across the world The Nakamoto Coefficient measures the minimum number of validators required to disrupt consensus. A higher number indicates stronger decentralization and security. User Experience Aptos is designed to deliver a consistent and affordable user experience regardless of network demand. Transaction fees remain predictable and low, making the network suitable for payments, gaming, social applications, and high-frequency DeFi activity. Transaction TypeNetwork FeeSimple transfer~$0.0001DEX swap~$0.001 – $0.005Complex DeFi transaction~$0.01 – $0.05 Low and stable fees eliminate the need for users to time transactions around congestion, significantly improving usability for non-technical users and consumer applications. Stablecoins Aptos has over $1.7 billion in stablecoin market cap, positioning it as a viable settlement layer for payments, trading, and on-chain financial infrastructure. Native and integrated stablecoins include: USDT: Native issuance by Tether USDC: Native issuance by Circle, CCTP enabled USD1: Issued by World Liberty Financial USDe: Synthetic dollar via Ethena In short, Aptos is optimized not just to scale technically, but to scale usage, supporting millions of users and high-volume applications on a single, unified Layer 1 designed for the masses. Use Cases Since its mainnet launch in October 2022, Aptos has attracted sustained interest from developers, enterprises, and institutional participants. Backed by Andreessen Horowitz (a16z), Multicoin Capital, and Yzi Labs (ex-Binance Labs), Aptos has evolved into a network supporting institutional finance, consumer applications, and high-throughput on-chain systems. What sets Aptos apart today is not just what exists, but what can be built on it right now from institutional assets to high-volume consumer apps. Wallets Native account abstractions reduce reliance on smart-contract wallets, simplifying onboarding to support consumer-scale. Petra Wallet: Browser and mobile wallet built for Aptos, with Gmail/Apple login Aptos Connect: OAuth-based onboarding that allows users to create and use Aptos accounts via Google, Twitter, or Facebook, reducing friction for mainstream users DEXs Aptos hosts a diverse trading ecosystem, ranging from on-chain trading engines, derivatives, and AMM/CLOB systems to orderbook-based and perpetual DEXs. Thala: AMM and liquidity hub Panora: Aggregates liquidity for optimized trading. Hyperion: Deep liquidity for stablecoins and BTCFi assets Tapp: Modular DEX with composable hooks for custom trading logic Decibel: Fully on-chain perpetual CLOB (currently on devnet) Merkle Trade: Perpetuals and leveraged trading Bitnomial: First regulated Aptos-based futures in the U.S Aptos is evolving into a high-throughput execution layer for both retail and institutional markets. Lending, Yield & Staking Aptos supports a growing set of lending markets, yield aggregators, and liquid staking protocols. Echo Protocol: Cross-chain asset protocol enabling BTC exposure on Aptos via aBTC, currently the largest BTC asset on the network. Aries Markets: Core lending and borrowing protocol supporting leverage and margin strategies. Amnis Finance: Pioneering liquid staking protocol with 42M+ TVL, issuing stAPT and amAPT so users can earn staking yield while retaining liquidity. Kofi Finance: A next-generation liquid staking protocol, enabling users to stake APT and receive kAPT, with enhanced rewards available through stkAPT. These protocols benefit from fast liquidation cycles and low-cost execution. Real World Assets (RWA) Aptos is already being used as infrastructure for institutional-grade asset issuance and settlement. Securitize: Tokenized securities platform running BlackRock’s BUIDL (USD Institutional Digital Liquidity Fund). Ondo Finance: Issuing USDY, a yield-bearing U.S. dollar token These deployments demonstrate Aptos’ suitability for large-scale, regulated asset issuance and settlement. On-Chain Media, Entertainment & Gaming Aptos is increasingly used for high-volume consumer and entertainment applications that require frequent state updates and low fees. NBCUniversal × Aptos Labs Backlot Club: On-chain fan engagement platform Playground Drops: Collectibles and community engagement for creators getSTANapp: Gaming and creator platform with 30M+ users, handling high-volume collectibles and AI-powered engagement What’s Next Based on current adoption patterns, Aptos is increasingly positioned for: Global trading engine and liquidity infrastructure Tokenized ETFs and structured financial products Institutional settlement and hot storage infrastructure High-throughput consumer and gaming platforms A full list of ecosystem projects can be found in the official Aptos Ecosystem Directory: https://aptosnetwork.com/ecosystem/directory Builder Tools for Aptos Development Aptos provides a rich and growing developer ecosystem with tools that make building, testing, and deploying applications faster and safer. From smart contract development to node operation, the tooling stack supports both professional teams and independent developers. Development & Smart Contract Tools Move Language & Move Prover: Secure, resource-oriented smart contract language with formal verification Move On Aptos book: Complete guide to get started with Move language maintained by @aptos-labs Move VS Code Plugin: IDE integration for syntax highlighting, error checking, and smart contract analysis. Maintained by the Move core team (source code) Aptos CLI: Deploy modules, interact with accounts, submit transactions, and manage local testnets Aptos SDKs (JavaScript, Python, Rust):** Build frontends, backend services, and on-chain logic Move Playground: Test Move contracts online with instant feedback and state visualization AptosFaucet: Provides free APT for testing and development These tools let developers quickly build, test, and verify contracts before deploying to mainnet. Wallets & Onboarding Tools Petra Wallet: Browser/mobile wallet for end-users Aptos Connect: OAuth-style Web3 login integration Aptos Wallet Adapter: Modular adapter for building wallet integrations with dApps Wallet Adapter by Pontem: React/Vue wallet provider supporting multiple Aptos wallets Aptos Name Service: Human-readable account addresses for simpler UX With these tools, developers can onboard users seamlessly and connect apps to multiple wallets. Conclusion Aptos represents a modern approach to Layer 1 blockchain design, combining a resource-oriented programming model, parallel execution, fast finality, and a production-ready ecosystem. From its Diem-inspired foundations and Move-based architecture to its growing DeFi, stablecoin, and institutional adoption, Aptos is built to support high-throughput, real-world applications without sacrificing safety or upgradeability. With mature developer tooling, native account abstractions, and reliable infrastructure, builders can focus on shipping products rather than working around protocol limitations. Whether you’re building consumer apps, financial infrastructure, or high-performance on-chain systems, Aptos provides a scalable and developer-friendly foundation that is designed for the masses. Now you have the context to start building on the Aptos ecosystem and with a reliable RPC provider like Chainstack, you can deploy and scale your first Aptos application with confidence. Start for free, connect your app to a reliable Aptos RPC endpoint, and experience how easy it is to build and scale on Aptos with Chainstack – one of the best Aptos RPC providers. #### What is Unichain: Choosing Unichain RPC for production Familiar EVM surface, different failure modes. We map where Unichain helps and where Unichain RPC choices across requests, WebSockets, and rate limits decide whether trades land on time. Unichain is an Ethereum Layer-2 from Uniswap Labs, built to scale DeFi without changing how Ethereum developers work. It is an Optimism OP Stack rollup, meaning it runs as a separate chain anchored to Ethereum but inherits Ethereum security via optimistic fault proofs. “the home for DeFi and liquidity across chains” - Uniswap Labs Unichain architecture differs in several innovations. First — by moving execution to L2 while still preserving Ethereum’s decentralized security model — it achieves low transaction costs (≈ 95% cheaper fees than Ethereum mainnet). Second, it delivers high throughput and fast blocks. Launched with 1-second block times, it introduces 200–250 millisecond “sub-blocks” for near-instant confirmations. Another key component is Unichain’s provable block building. Block production is handled by a Trusted Execution Environment (TEE) based sequencer co-developed with Flashbots. This TEE sequencer enforces fair transaction ordering and even filters out failing ones, which improves UX (no more paying gas for reverted trades) and mitigates malicious MEV strategies. In addition, Unichain will soon activate the Unichain Validation Network (UVN) – a decentralized set of validators who stake UNI tokens and independently verify each L2 block. The UVN will provide faster economic finality and further decentralize the chain beyond a single sequencer. In short, its design is optimized for on-chain markets. It’s EVM-equivalent (fully Solidity and Ethereum tooling compatible), built on the Optimism Superchain framework for native cross-chain interoperability, and open source so that its technical advancements (like the TEE builder and UVN) can be adopted by other rollups. Why Unichain is built for DeFi Unichain’s role is to act as a high-performance DeFi hub. Uniswap Labs frames it as “the home for DeFi and liquidity across chains,” a response to Ethereum’s limits on cost and speed. In practice, the chain is tuned for trading and liquidity work: cheaper transactions, faster confirmations, and a design that helps pull liquidity into one place instead of scattering it across networks. Where Unichain improves on Ethereum L1 High fees on Ethereum L1: Unichain cuts costs by ~95%, so swaps and multi-step interactions stay viable at scale. Cheaper txs also make higher-frequency and micro flows practical on-chain. Slow confirmation times: With one-second blocks and planned ~200 ms sub-block confirmations, pending times shrink. Quotes go stale less often and front ends stay in sync with chain state. Fragmented liquidity across chains: As part of the Optimism Superchain, Unichain supports native cross-chain messaging and ERC-7683 intents. You get single-click swaps between Unichain and other chains without manual bridging. MEV and unfair trading: A TEE-based sequencer with attestable ordering cuts front-running and paid reverts by enforcing ordering rules and catching obvious failures early. The Unichain Validation Network adds independent checks and faster economic finality. Essentially, Unichain is a high-speed, low-cost venue for trading and liquidity. It targets CEX-like responsiveness while keeping Ethereum’s security and open access. For builders, that means cheaper transactions, short confirmation targets, and an execution path tuned for on-chain markets. On testnet, it processed ~95 million transactions and 14+ million contract deployments in under four months. Around mainnet launch, roughly 100 projects were building or deploying, including exchanges, stablecoin issuers, yield protocols, and Uniswap. Incentives are user-aligned, with 65% of sequencer revenue allocated to community validators. Therefore, you get cheaper swaps and quicker settlement while staying on a network built for open, on-chain finance. Developer tooling on Unichain Developers coming from Ethereum won’t need a new toolbox. Unichain is EVM-compatible, so your usual stack works once you point it at a Unichain RPC endpoint and set the network in your config. Development frameworks and libraries: Set Unichain RPC and chain ID in Hardhat/Foundry and deploy as usual; Truffle/Remix follow suit. OpenZeppelin (Uniswap v4 Hooks included) works out of the box, and Thirdweb supports Unichain. Same Solidity/Vyper — switch networks, don’t rewrite. Block explorers: Unichain is indexed by explorers such as Blockscout and Uniscan. You can search addresses and tx hashes, verify source, and trace L1↔L2 activity—handy for debugging deploys, following event emissions, and sharing reproducible links with teammates. Wallets: MetaMask works once you add the Unichain RPC URL and chain ID. Many wallets include Unichain out of the box, so the connect flow doesn’t change. Teams with custody requirements can wire Unichain into enterprise wallets and keep standard WalletConnect paths in their apps. Data indexing and analytics: The Graph supports Unichain, so you can build subgraphs, index events, and query them over GraphQL for dashboards or app state. Other indexers (e.g., SubQuery, Goldsky, GhostGraph) offer alternative pipelines. On the analytics side, Dune includes Unichain datasets for querying trades, pools, and usage and for publishing public dashboards. How to choose Unichain RPC Public Unichain RPC is fine for quick tests. It’s rate-limited and HTTP-only, so it won’t carry a trading front end or a bot that needs live state. For production, use managed Unichain RPC you can treat as core infra. With Chainstack, you can get a fully managed Unichain RPC node in a minute and skip the overhead of maintaining your own. Endpoints come ready to use, and you get features that matter when traffic grows: Global Nodes keep latency steady with geo routing, so reads and writes don’t jitter when users move or load shifts. WebSockets enable event and new-block subscriptions instead of blind polling, which helps UIs and bots stay current. The platform handles growth behind a stable endpoint so you can scale without rewrites. 1 request = 1 Request Unit. If you want to stop watching counters, Unlimited Node is a flat subscription for unlimited requests. Access rules allowlist by IP or Origin to lock down your endpoint in production. Create a project, add a Unichain node in Console, copy HTTPS and (where available) WSS, and ship. Docs cover ethers.js/web3.js reads, event subs, and Hardhat/Foundry deploys. Create Unichain node Wrapping up Unichain covers speed and cost; you decide reliability. Point your stack at Unichain RPC you can treat as core infra, subscribe to new blocks and events where it helps, and keep the rest simple. If you want a fast start, create a node on Chainstack and get back to trading logic. FAQ What is Unichain? Unichain is an Ethereum layer 2 from Uniswap Labs, built on the Optimism OP Stack and tuned for low-cost, fast DeFi. Is Unichain EVM-equivalent? Yes. Your Solidity or Vyper contracts and the usual Ethereum tooling work on Unichain with a network config and a Unichain RPC endpoint. How do I connect to Unichain RPC? Point your client to a Unichain RPC URL and set the chain ID. Use the public endpoint for quick checks, then move to managed Unichain RPC for production. Is the public Unichain RPC suitable for production? No. It is rate-limited and HTTP only, so it is fine for tests but not for apps that need live state or consistency under load. Which explorers can I use on Unichain? Blockscout and Uniscan index Unichain. You can look up addresses and transactions, verify source, and trace L1 to L2 activity. What should I look for in a Unichain RPC provider? Stable latency, WSS for subscriptions, clear limits, and controls to secure your endpoint. You should be able to treat the endpoint as core infra. #### What problems does blockchain solve? Blockchain is no silver bullet, but here is a snapshot of three real-world challenges common to most businesses and how blockchain technology addresses them Problem: Auditing & compliance Example Business systems generate vast amounts of log data which needs to be securely stored for audit, compliance, and reconciliation purposes. The integrity of the stored logs is paramount in maintaining trust in such systems, as well as for satisfying regulatory and reconciliation requirements. Current solution Logs are stored in a centralized and, possibly, mirrored database. The system relies on trustworthy human administrators to maintain the integrity of the stored logs. Blockchain solution An immutable and distributed data store of cryptographic signatures guaranteeing integrity, while being highly available in the face of multiple infrastructure failures. External parties such as auditors are provided with permissioned read access to the blockchain to facilitate efficient reconciliation across multiple parties. Value proposition Improved regulatory posture Efficient data reconciliation Removal of trust from possibly fallible human administrators Blockchain deployment model As a private, single-owned distributed ledger Permissioned read-write access to intra-business units and permissioned read access to external units Business units run one or more nodes on the blockchain network. Problem: Storage & availability of sensitive data Photo by Mika Baumeister on Unsplash Example Critical IT systems such as firewalls and key servers are configured via highly sensitive and confidential configuration files. Maintaining the integrity, traceability, and availability of these files are crucial to continued, uninterrupted, business operations. Current solution Stored as text files or as entries in a traditional and, possibly, mirrored database. The system relies on trustworthy human administrators to maintain the integrity of the stored configurations. Version control is achieved via traditional mechanisms such as software versioning tools. Blockchain solution An immutable, versioned, and distributed data store for data configuration offering cryptographic storage, guaranteeing integrity, and being highly available in the face of multiple infrastructure failures. Value proposition Removal of trust from possibly fallible human administrators Immutable data store Distributed validation Blockchain deployment model As a private, single-owned distributed ledger Permissioned read-write access to intra-business units Business units run one or more nodes of the blockchain network. Problem: Information sharing across organizations Photo by rawpixel on Unsplash Example Customer on-boarding generates KYC data, which is siloed and not easily accessible to units within and between businesses . Current solution Businesses, as well as the units within a business, duplicate the KYC process leading to redundancy, inefficiency, and a lack of transparency in the on-boarding process. Blockchain solution A consortium-driven, distributed data store that is shared securely among multiple pertinent business entities and/or among business units. Value proposition Increased transparency Streamlined workflow De-duplication. Blockchain deployment model As a multi-entity, consortium-owned distributed ledger Permissioned read-write access to intra-business units and permissioned read access to external units, which could include members of the public Entities in the consortium and business units within such entities run one or more nodes on the blockchain network The network operates without explicit consensus (as in a public blockchain consensus) but under strict a priori legal agreements among the consortium members Members verify and validate new data on the blockchain typically based on a Proof of Authority (PoA) model. At Chainstack, we are helping businesses accelerate their blockchain adoption journey. Understanding where and how blockchain fits in the current scheme of business processes is one thing; but getting blockchain to work amidst a complex set of technical moving parts is another. Our platform as a service helps businesses to build a consortium, specify an appropriate governance model, and, finally, deploy and manage their blockchain networks regardless of cloud or protocol preferences, while our ultimate blockchain control panel makes set up and configuration a breeze . In essence, we handle the complex parts of blockchain deployment and management so that businesses can focus on developing new ways of making blockchain technology work for them - just like the ones we have explored in this post. Interested to learn more about Chainstack? Stay in touch for occasional technical and business updates via our newsletter! 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. #### When will the blockchain rubber meet the adoption road? By Laurent Dedenis Let me start by thanking IMDA and the engaging participants at this month’s Blockchain Discovery Day in Singapore. In a field that is moving at a blistering pace, and a world where everything real-time is the norm, starting a post with reference to an event that took place more than a week ago might seem like one’s late to the party. But that’s exactly the point of this post… Over the past 2 years, I have been interacting globally with a highly curious and passionate set of people in governments and across industries around the theme of Blockchain adoption. As the founder of Chainstack, I have had the opportunity to gain several insights from these conversations. I often find myself among enthusiasts, who believe that Blockchain technology is a panacea, which I don’t think it is, despite its incredible potential. I also find myself among skeptics fixated on the overwhelming number of failures in Blockchain experiments and the lack of real use cases. To me, this early recurring state of yin-and-yang is a healthy sign of a truly revolutionary technology. After the web, mobile, and cloud cycles, it seemed like the march of truly novel and useful technology had finally come to a pause. But the feeling that now ‘there is nothing new under the sun’ has been replaced by a paradigm that, I believe, will unlock value from myriad nooks and crannies of organizations. These days, it is a delight to exchange ideas with both believers and skeptics, and, equally, ‘wanting to know more’ individuals. Over the last few months, many new Blockchain platforms were announced. Add to that the multitude of underlying Blockchain protocols, and you’ll find yourself with a sophisticated matrix of choices, allowing every enterprise to address many scenarios you can possibly consider as part of a more decentralized world. At Chainstack, our amazing team is working towards making the complex task of trying out several Blockchain technologies a breeze. Some members of our team are busy building the nuts and bolts of, what we call, an ultimate control panel for enterprise Blockchain. And some others are constantly educating organizations across all strata on how best to navigate the Blockchain maze. Photo by Sergei Akulich on Unsplash We find ourselves committed to the art and science of making Blockchain accessible. And we expect this journey to be a long and adventurous one, with its pitfalls, nonetheless, but with success eventually. Not all rubber will meet the road of course. But when the proverbial Blockchain rubber does meet the adoption road, whether it’s in an enterprise or at a non-profit, there will be eureka moments. These will open doors to a completely new way of doing business and make possible radical transparency, collaboration, and efficiency. And in the short arc of IT and business history, participating in this is truly exciting. 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. #### Why Defined trusts Chainstack for its Web3 data services Redefining blockchain data access with real-time token and NFT pricing charts. Our collaboration with Chainstack plays a vital role in our quest to democratize access to blockchain data. Their unwavering reliability has been pivotal in helping us manage over 2M tokens, 800M NFTs and empowers us to innovate relentlessly in the ever-evolving blockchain landscape. The Defined team As a blockchain managed services provider, we at Chainstack have continually strived to tether reliability and scalability into the rapidly evolving world of blockchain and cryptocurrency. One such journey has been along Defined—a leader in providing enriched blockchain data. Defined operates on 46 networks offering real-time data for over 2M tokens and 800M NFTs. Serving millions of traders worldwide with our robust Web3 infrastructure—including pricing and chart data, indexing, and custom APIs, we have been at the forefront, powering their mission to democratize access to cryptocurrency data. Let’s shed light on how we have been enabling Defined in its industry-leading blockchain data efforts. Why Defined chose Chainstack as its infrastructure partner Initially, as we at Chainstack ventured into a collaborative arrangement with Defined, we recognized their unique place within the blockchain data landscape. The platform’s requirement for robust and reliable service, capable of handling mammoth request loads and ensuring minimal downtime, was seen as a challenge ready to be conquered. Defined was juggling multiple providers and seeking a more streamlined approach. They wrestled with the complexity and potential inefficiency of managing multiple relationships and contracts with different providers, all the while ensuring continuous service, especially when their existing provider lineup faltered. Our first impression of Defined was of a platform that was both demanding and promising—exactly the kind of challenge we were equipped to handle. The need for us to integrate seamlessly into their existing setup, act as a reliable safety net, support high request volumes, and provide steady service even at peak times formed the crux of our focus. The "light bulb" moment came when we stepped in during one of the critical times when one of Defined's providers was experiencing downtime. Our ability to offer a dependable service, stand in the gap and ensure the continuity of their operations even during such trying times, highlighted the importance of Chainstack in their infrastructure. No incentives or customizations drive the decision—just the sheer reliability and performance of our services. The ultimate value we deliver is the peace of mind that comes from knowing that when it comes to blockchain data, they're backed by a provider that's consistent and reliable. Defined on Chainstack in numbers When we talk about our partnership with Defined, it is essential to go beyond stories and understand the impact we made in numbers. Defined has seven active elastic nodes running on protocols such as Arbitrum, Avalanche, BNB Smart Chain, Cronos, Ethereum, and Polygon. This usage has led to 76.7M archive node requests and 6.1M full node requests. Different regions have also shown the fruits of our collaboration. The Dallas region saw the largest share of requests with 70.7M , while EU3 and London reaped 6.1M and 5.8M requests, respectively. Meanwhile, when it came to protocols, Arbitrum saw 66.1M requests, while the Cronos and Ethereum trailed closely behind with 6.1M and 6M requests, respectively. Our partnership with Defined underscores our dedication to offering Web3 developers robust and cost-effective blockchain infrastructure. In the last quarter, we've proficiently handled 11.5M eth_call, 7.8M eth_getBlockByNumber, and 7.8M debug_traceBlockByNumber requests on archive nodes, along with 3.1M eth_blockNumber, 1.1M eth_getBlockByNumber, and 0.9M eth_getLogs requests on full nodes, thereby ensuring maximum value for Defined with every interaction. Figure 1: Defined node RU allocation OCT-JAN Our Business plan, competitively priced at $499, offers significant savings, demonstrating our commitment to cost efficiency. When compared to Alchemy's Scale plan at $3,785 and QuickNode's Business plan at $2,027 monthly, our solution stands out as substantially more affordable. With Chainstack, Defined saves 91% compared to Alchemy and significantly more than QuickNode, emphasizing our dedication to providing high-quality services at scale and at a fraction of the cost. Figure 2: Defined data profile price comparison; Source: Chainstack Delving into these figures drives home the importance of Chainstack in the overall operations of Defined. It's not just about being an alternative choice; it's about ensuring the continuity of service, providing robust request handling capacity, and above all, maintaining an unbroken trust in our reliability. What is Defined? Defined is a leader in enriched blockchain data, operating throughout a whopping 46 networks to provide real-time data on over 2M tokens and 800M NFTs. Trusted by millions of traders worldwide, industry-leading companies use Defined's data and infrastructure for a wide variety of needs, including pricing or chart data, indexing, custom APIs, and more. Figure 3: Defined supported networks; Source: Defined But where Defined truly stands apart is in the breadth of its offerings. Whether it's the powerful token and NFT data, available in under three seconds, the crypto industry's most popular chat-based price bot, the crypto search engine with powerful filters, or the enhanced data features, Defined brings a vast trove of tools under one roof. The enhanced data includes real-time aggregates with volume, liquidity, unique wallets, and more available instantly for multiple timeframes. The platform also offers the exact value of every real-time or historical on-chain transaction in USD pricing, structuring and typing the data to make it simple to understand, accessible, and stable. And it doesn't stop there. Defined offers several delivery options. You can have almost instant, real-time access to the on-chain data, live stream data over unbroken connections using websockets, or get alerted when anything happens on-chain through webhooks. The platform makes it incredibly easy to find any token or NFT in under half a second. And when a new asset is created, it becomes available on the platform almost immediately after creation through automatic indexing. So, whether you're a trader, a developer, or a company in need of reliable, timely, and rich blockchain data, Defined is the platform you'd want to turn to. Bringing it all together Reflecting on our journey with Defined, it’s clear that it’s not just about the technology or the services—it’s about reliability, about providing a partnership that you can trust, especially when things get challenging. Defined is not just a leader in providing enriched blockchain data. They're an emblem of what you can achieve with the right support—speed, reliability, and a vast scale of operations. As Chainstack, we're proud not only to provide robust, scalable blockchain services to companies like Defined but also to learn from them—their goals, their commitment, and their determination to deliver the best for their users. It’s been our privilege to support such a vibrant, dynamic, and forward-thinking team. Being more than just a provider, but a partner has allowed us to expand our vision, strengthen our capabilities, and set higher goals. As we continue to grow together, changing the way businesses view blockchain data, we look forward to exploring even greater depths of this transformative digital landscape. Power-boost your project on Chainstack #### Why online learning is so successful Introduction In the evolving landscape of education, online learning has emerged as an integral part of modern academia. Due to the digital revolution and the onset of the global COVID-19 pandemic, this learning methodology has witnessed unprecedented growth and adoption, fostering successful learning outcomes for millions worldwide. But what is it about online learning that makes it so successful? Accessibility and flexibility Arguably, the most significant aspect contributing to online learning's success is its accessibility and flexibility. Online learning eliminates geographical boundaries, providing global access to quality education. Individuals in remote areas, developing countries, or simply those who cannot afford to travel can now access resources from world-class universities at their fingertips. For many people, the ease of access to knowledge and learning opportunities that appeared with the spread of the Internet is something obvious - they simply never had the opportunity to function in times when the world looked a little different. As it happens, I have lived long enough to remember what things looked like before. I'm talking about times when acquiring knowledge on a subject of interest to us required either finding someone who had the knowledge we needed or visiting the library and if the literature we needed was there, it required - most often independent - long-term study. Of course, there was also school, which tried to convey knowledge defined by the curriculum, to varying degrees of success. Add to this the television, which offered educational programs - in my private opinion, these were much higher in content quality then than their counterparts now. What is missing in this picture when we compare it with the present time? To learn something, you need to know that it exists at all - where to get a plan for the field of interest to us? In the case of more specific, or more detailed areas, the aforementioned sources might not contain what we needed. For example, in my childhood, in the place where I had grown up, access to information about computers and programming was severely limited - there were industry magazines, available irregularly, and that was basically it. Moreover, online learning platforms offer flexibility in time management. Learners can access material at any time, allowing them to schedule learning around their daily routines, work commitments, and family obligations. This convenience and control over personal learning pace contribute significantly to online learning's successful model. A wide range of courses The extensive range of available courses also contributes to the success of online learning. From languages and humanities to science and technology, online platforms offer an array of subjects for all learning levels. This vast range empowers students to learn about topics that they may not have had the opportunity to explore in traditional educational systems. This diversity of available courses is both a blessing and a curse, something I experience myself on many occasions, because after all, the day lasts 24 hours for all of us, and if someone likes to learn new things, they can do it virtually without limitations. Of course, in the real world, these limitations will occur, so it's worth knowing that: you can't learn everything (yes, I know, it's an obvious fact), you need to know what your goal is, and in this case, it's up to us to define it and later monitor how we are progressing towards achieving it. Of course, in this case, online learning once again shows its advantage, as we often have elaborate mechanisms for measuring and reporting our progress. The cost factor Online learning often costs less than traditional education. It eliminates many of the ancillary expenses associated with in-person schooling, such as commuting, housing, and textbooks. Some platforms even offer free courses from renowned institutions, making education more affordable and inclusive. Personalized learning Online learning platforms leverage advanced analytics and artificial intelligence to offer personalized learning experiences. These technologies identify students' strengths and weaknesses, tailoring content accordingly to enhance learning outcomes. This personalization is particularly useful for students who might struggle in a traditional classroom setting, providing them with targeted resources and strategies to excel. As human beings, we tend to start something full of enthusiasm, only to soon become bored and either abandon the thing completely or not devote enough attention to it. Who among us doesn't remember instances from school when we listened to the teacher's words with (to put it mildly) insufficient engagement? In the case of online training, we usually choose the field we intend to explore - so the boredom resulting from following a program that has been imposed on us, and which we carry out by necessity, is eliminated. Thus, our motivation is already greater from the start. Additionally, remote learning platforms use the same mechanisms that make us forget about the surrounding world when playing computer games. Various gamification mechanisms make it much easier for us to maintain engagement, and virtual rewards make us feel the need to continue the learning process we have started, right up to the very end. The blend of synchronous and asynchronous learning The blend of synchronous (live) and asynchronous (recorded or self-paced) learning is another feature that adds to the success of online learning. Synchronous sessions provide real-time interaction, fostering a sense of community, while asynchronous materials allow students to revisit content at their convenience. This blend caters to different learning styles and preferences, enhancing student engagement and success. Learning innovation Technological advancements have allowed online learning to provide engaging and interactive content. With the use of videos, infographics, games, and simulations, online courses can deliver information in various engaging ways. This innovative approach boosts learners' motivation, leading to a deeper understanding of the content. The advent of AI models like ChatGPT represents a seismic shift in the world of online education, transforming how students learn and teachers teach. This transformation introduces several profound benefits. One of the most notable benefits is the creation of personalized learning paths. ChatGPT can provide tailored experiences that identify individual strengths and weaknesses, offering appropriate materials and making the learning journey more engaging and effective. This personal touch caters to the unique needs of each student, providing a more bespoke education. In terms of engagement, ChatGPT's ability to interact with students conversationally introduces an exciting dynamic to education. By answering questions, providing explanations, and even quizzing students, learning becomes more interactive and engaging. ChatGPT's integration into online education represents a revolutionary advancement. By making education more personalized, accessible, engaging, and cost-effective, ChatGPT enhances both the learning experience for students and the teaching process for educators. Its dynamic, adaptive, and interactive qualities offer a promising glimpse into the future of modern education. Conclusion The success of online learning is an amalgamation of various factors, including flexibility, accessibility, affordability, personalization, and innovation. The ability to break down barriers and cater to individual needs and preferences has revolutionized the learning landscape, enabling online learning platforms to provide quality education to a global audience. As technology continues to advance, online learning is set to become even more successful, shaping the future of education in ways we are only just beginning to imagine.In the dynamic world of programming, Hyperskill shines as a beacon of effective online learning. Unlike ordinary platforms, Hyperskill's distinctive approach blends self-paced learning with an extensive curriculum encompassing various programming languages and technologies.  Hyperskill's allure lies in its practicality. It doesn't just teach theories or shows you some videos; it fosters application through hands-on projects. This transforms learners into skilled programmers, adept in languages like Python, Java, Kotlin or C#. In essence, Hyperskill's triumph stems from its unique blend of self-paced learning, diverse programming languages, and a project-centric approach. It's a launchpad for aspiring coders to achieve expertise. Power-boost your project on Chainstack #### Why we are excited about 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. Several weeks ago, Hyperledger announced the general availability of Fabric version 2.0. Being the first of the Hyperledger projects to reach the 2.0 mark, the release was celebrated as a significant milestone throughout the enterprise blockchain ecosystem. Jerry Cuomo expressed how Fabric’s 2.0 release was an attestation of the contribution and growth of Fabric’s dedicated developer community—the largest across the enterprise blockchain space. Our recent report on enterprise blockchain developer activity revealed that Fabric developers represented 71% of the total number of developers that pushed code. What’s new in 2.0? Amongst a variety of performance improvements, Fabric 2.0 includes new features centered around heightened data privacy, more granular controls, and greater optimization for consortia network governance. Fabric 2.0 introduces greater flexibility in how participants operate on the network, particularly in how they write and run chaincode—the applications that make networks useful. At the same time, the new decentralized governance for smart contracts means that a network can be configured to require that every organization must agree to the parameters of the chaincode before it can become active. These are key and you can read the full announcement here. Why does it matter? The new features introduced have been based on the accumulation of iterations of feedback from enterprises that have developed on Fabric version 1.0 since its launch in 2017. It’s obvious why those building on Fabric are excited. Better, faster, easier-to-use technology makes it simpler for enterprises seeking to build on blockchain. For those outside the Fabric world, this milestone was also very positively received. Enterprise protocols are evolving rapidly Fabric is not the first enterprise blockchain to reach a major release. Last year, Corda 4.0 and MultiChain 2.0 also went live. After five years in development, PegaSys’ Enterprise Ethereum client, Pantheon, rebranded and premiered as Hyperledger’s first-ever public blockchain operable project—Hyperledger Besu, bridging the gap between public and private blockchains. History of major protocol releases Each major upgrade a major enterprise protocol goes through is a positive sign of growing maturity. As the protocols evolve to suit the requirements of enterprise use-cases, businesses are more able to leverage blockchain’s key benefits. This is likely to accelerate adoption. A key challenge inhibiting enterprise adoption cited by Gartner was the highly fragmented blockchain platform market with frequently overlapping offerings. For companies keen but new to DLT, the profusion of options can often be a source of confusion. Deciding on new infrastructure, particularly emerging technology, can be relatively daunting, given the general lack of technical familiarity and experience with the technology. IT decision-makers also lack references and performance measures that they can consult. Looking at a protocol’s technological maturity is a useful metric in assessing the viability of a protocol—a protocol that has undergone significant upgrades is likely to have had a substantial amount of engineering resources invested into developing its features and codebase. Upgrades are incredibly messy While upgrades are inevitable, constant changes to infrastructure platforms make them challenging to work with. Typically, re-training and retention of entire ecosystems require significant coordination and resources. Enterprises running systems on these distributed platforms must update their underlying infrastructure and migrate their existing systems each time a new upgrade is released. This is always going to be a very manual and cumbersome process involving a lot of downtime and a lot of troubleshooting. Migration is never a straightforward process, especially when working with relatively new technology. Today, the severe shortage of skilled blockchain talent means that companies struggle to keep up with the capacity required to run their blockchain initiatives. Constant upgrades can cause blockchain skills to be outdated at a rapid pace, making it difficult for the already small talent pool to keep up with these new changes. This also means that the already trained blockchain infrastructure engineers must constantly be retrained. In addition, the need to be able to cope with these changes also increases the workload for the already strained development teams, distracting them from higher-value tasks and making the need for highly proficient infrastructure engineers even more crucial. This is further exacerbated by the lack of proper documentation and dedicated support for general-purpose open-source blockchains with small developer communities, which make training and retraining difficult for aspiring blockchain developers. Due to the technical complexity of these upgrades, organizations must build a meticulous migration strategy to ensure that all components of their infrastructure are successfully upgraded in the order required. Often involving significant planning and risk management, these must take into account all applications, software, systems, and business processes that may be impacted during this process. Organizations working with blockchain should expect to face frequent upgrades. New tools to help weather the storm The development of increasingly sophisticated developer tools that simplify the blockchain developer experience is revolutionizing the way organizations can begin leveraging decentralized solutions. For instance, managed services can enable companies to leapfrog the complexities of the rapidly evolving blockchain infrastructure and help to mitigate the impact of significant infrastructure upgrades, helping companies brace for these changes. By reducing the need for the hard-to-find niche blockchain DevOps expertise, these platforms are drastically lowering the cost and resources required to access decentralized technologies. Lots to be excited about Granted, beyond the maturity of technology platforms, many other factors remain to be addressed. Think governance challenges, regulatory restrictions, an unwillingness to collaborate, incompatibility across networks, platforms or corporate systems, and the lack of open standards. I could come up with a non-exhaustive list, but you get the point. Many of these require deep collaboration involving technology providers, regulators, governments, and enterprises across industries. But signs show that the enterprise blockchain space continues to grow rapidly. Chainstack’s recent study revealed just how rapidly—the number of enterprise blockchain developers has increased 12-fold since 2015. The world’s largest enterprises are implementing decentralized technologies to improve processes and these numbers grow every day. And although there are conflicting estimates on when we will reach mass adoption (whatever that looks like, or whatever that even means), the recent developments within the enterprise blockchain space have left us fired up in anticipation of yet more good news to come. Hyperledger Fabric 2.0, we’re excited for the changes you are going to bring to the world. P.S. We will also be at the Hyperledger Global Forum next week (Booth SU6) where we will be making an exciting announcement! Come say hi. 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. #### Why Web3 businesses choose Chainstack Although Rome wasn’t built in a day, it was built with the most advanced tools of its time. Your business is your empire, and to thrive in Web3 you need to utilize the most cutting-edge technology available. It’s easy to get lost in the digital wilderness, that’s why we have engineered a robust infrastructure and toolset for you to forge your way forward. As you seek to grow and BUIDL great things, we are here to connect you with the resources that you need to make it happen. Today, Rome would be built on-chain one block at a time. And Chainstack provides the BUIDLing blocks for all your Web3 needs… High-performance Web3 infrastructure at the click of a button Do endless wait times when syncing nodes impede your workflow and progress? Would you like to save precious time and deploy a node in the time it takes to brew a fresh coffee? With Chainstack’s patented Bolt technology these possibilities are at your fingertips—just a couple clicks away. With data centers distributed worldwide, you can choose the nearest location and reap the benefits of enterprise-grade node performance with minimal latency from anywhere in the world. Claim your fair share of the cutting-edge infrastructure that can handle heavy network loads with ease and continue BUIDLing with minimal interruption to your services. Our high-performance infrastructure and world-class engineering mean that wherever you are, your network has a 99.9% uptime even under heavy duress—giving you smooth sailing to focus on what you do best; create value with your project. More time, less effort, and even better customer experience. Flexible node deployment and winning the speed race Do you have a niche use case? Perhaps one more demanding? Choose from the 20+ top protocols that we support and embrace the one that best fits your project. No need to pick only one, cross-chain support is just around the corner. BUIDL effectively, armed with a single seamless interface and the few clicks needed to deploy on any of the growing list of networks we support like: Ethereum (ETH) Polygon (MATIC) BNB Smart Chain (BNB) Avalanche (AVAX) Solana (SOL) And more Blockchain performance is defined by its speed in processing transactions per second (TPS), but sometimes quick is just not fast enough— which is why we give you the option to submit Warp Transactions that execute even swifter. Through a relay network, you can skip past the dreaded mempool queues and reach your target faster than you ever could before. Without an adequate Node-as-a-Service (NaaS) provider, your RPCs can stall on a congested public node or a poorly maintained in-house setup. So, don’t settle for less—squeeze the absolute last drop of node performance possible and secure the consistent performance that you need to excel in business. Zero effort maintenance and timely updates Node health is vital to its uptime, which is why you will find a convenient set of graphs and metrics available in the Chainstack console to identify potential problems, and proactively resolve them before they start—this helps reduce desync issues and service downtime. Our nodes are consistently kept updated, secured, and synchronized. When a service interruption occurs, we proactively work with you to eliminate the underlying issues, so you can get back to BUIDLing as soon as possible. Regardless of the protocol, you can always rely on consistent performance from the node infrastructure you deploy. As you scale, the number of nodes and usage increases, as well as the complexity of maintaining them–exponentially! That is why, it is our mission to lift this burden off your shoulders, so you can free up resources for more important things—like BUIDLing the applications that your customers want, while enjoying maximum uptime too. Blockchain infrastructure that scales with your business As your business expands, so does the demand for infrastructure. Without a scalable solution, you risk your entire operation grinding to a halt because of network overload. With Chainstack’s services, you can always claim the extra resources needed to maintain optimal performance. At Chainstack, we are no friends of artificial limits. That is why our globally-distributed network of nodes comes with zero rate-throttling and limiting. Flexible solutions give you the best of both worlds in terms of both speed and stability for your application. You get a highly scalable infrastructure to BUIDL and deploy your DApps, regardless of the use case or project size. Scaling is easy because our pricing is transparent and predictable because all requests are equal. We don't charge extra requests based on computation. This typically effects businesses scaling because it’s difficult to estimate the costs. Whether you scale at an incremental or exponential pace, our services follow suit ensuring a smooth transition. It matters little if you are a solo developer, a small team, or a giant enterprise, we can help you streamline business operations and deliver an exceptional customer experience. Comprehensive service stack for all your Web3 needs Our mission is to connect all developers with Web3. Therefore, we offer an entire suite of powerful tools designed to make BUIDLing more intuitive than ever. We are setting the cornerstone in Web3 space with both our infrastructure and services. Powerful hosting, cloud, and indexing solutions For the most demanding and resource-heavy projects, we created Chainstack Cloud—our own in-house cloud hosting solution designed by IT security professionals with decades of experience and built for Web3. It can deliver as much node performance as the hardware can support. With it, you can undertake the most intensive operations even during times of peak network activity. You can also choose between hybrid-hosting or self-hosting. Deploy our nodes on your infrastructure for your own autonomous operations—you decide how much you want to host and how much you want to leave to us. Additionally, you can use other cloud providers i.e. AWS, Microsoft Azure, GCP, etc. You can even run your own data center as you integrate with Chainstack services and embrace the power of our hosting solutions. With Dedicated Subgraphs you get a state-of-the-art blockchain indexing solution. Web3 projects, and developers can query real-time blockchain data across multiple protocols without expensive infrastructure or a dedicated backend engineer team. Developer APIs, marketplace, app-chains, and more We have a debug and trace API so you can inspect the chain state for debugging and logging data, and a MEV API to simulate transactions with access to Flashbots, giving you the space to experiment and run tests with throughout the development phase of your project. And if that still isn’t enough, you can browse around our marketplace and find the comprehensive tools that specialists use to help launch your project even further. Get real-world data on-chain with an oracle, improve security, or just find a better way to manage all your HODLings. BUIDL the next-gen DApp that your customers will so adore. Sometimes, all it takes is an explosive start with an efficient app-chain setup that is perfect for your needs: Avalanche Subnets Polygon Supernets BNB Application Sidechains StarkEx Apps To further enhance your development experience and keep you ahead of the curve, we offer you early access to some powerful upcoming features, including: Our IPFS Storage allows you to easily store and retrieve files on blockchain nodes. Nothing ruins the user experience for a DApp like a lagging management system that slows its functionality. You need the fastest content delivery network available. Here, your files are encrypted, stored, and distributed on a globally distributed network—with no single point of failure and 99.9% uptime; your DApps can access the data they need anytime at lightning speed. Whether you’re BUIDLing DeFi, GameFi, NFTs, or other DApps, our solutions got you covered. Affordable commitments fit for any budget The operational costs of securing blockchain networks are considerable (the engineering hours alone can easily be an $100,000 annual expenditure), but with the help of our exceptional engineering, maximizing both value and performance is well within reach. And with custom-tailored plans fit for every budget, sky-high ROI is that much more accessible to Web3 BUIDLers worldwide. Start your expedition into Web3 now with our commitment-free Developer plan for introduction-rate access to full elastic nodes. Take full advantage of the 3M requests included in the subscription. If your endeavors require more steam for the engine, rest assured that all of Chainstack’s pricing tiers are pay-as-you-grow to give you exactly that. You will get the best price-to-performance ratio, regardless of the size or stage of your project. Ready for your use, you will find 20M API requests available to you with the Growth plan. If you require more and opt for the Business plan, then you will receive 200M API requests plus no restrictions for dedicated nodes with this option and higher. The sky is not the limit, in fact there is no limit. If you need additional requests, we give them to you for as little as $5 per million API requests beyond the first 20M—if you don’t want to compute the costs in your head, then estimate the costs with the usage cost calculator here. Streamlined blockchain infrastructure for your Web3 journey to success The ability to transact and communicate at technology’s rapid pace is both a demanding task and a costly expenditure. Chainstack is equipped to handle that part for you. The resources that you save by offloading complex backend responsibilities to a dedicated team of IT engineers expedites your development process to get your products to the market. Business thrives on momentum, therefore you cannot afford anything that slows it, especially a congested network. Neither success nor failure can be guaranteed, but it is certain that fast and reliable platform operations help build trust in your product—this makes success much more imminent. Leverage the power of groundbreaking blockchain infrastructure to your advantage. Stand well above the competition with a firm, robust foundation for you to BUIDL on. And the key to cutting-edge technology that paves your way towards success across the digital wilderness is now within your reach. Web3 is an excellent opportunity for business and development, so don't venture out by yourself. Experience the hero's entrance into Web3 you rightly deserve and start BUIDLing swiftly as you break new ground moving forward in quest. Sign up for free to start BUIDLing now! Power-boost your project on Chainstack #### x402 on Solana: developer guide to micro-payments A hands-on deep dive into building autonomous micro-payment infrastructure with x402 on Solana, enabling Telegram bots to pay per API request with on-chain USDC settlement. ❓ Prefer diving straight into the code? Get the x402Bot on Utkarshini’s GitHub: https://github.com/utkarshiniarora/x402-bot TL;DR Modern AI systems are increasingly autonomous. Agents call APIs, fetch data, execute strategies, and coordinate across services without human intervention. What they lack is a native way to pay for the resources they consume. In this guide, we’ll build a Telegram bot that pays per API request using x402, settles on Solana, uses USDC via the Exact SVM scheme, integrates a PayAI facilitator, and runs on a reliable Chainstack RPC endpoint. The bot will automatically deduct funds from a wallet and pay for every request it makes to a protected API server. We will implement: A paid API server protected with x402 A client who automatically signs payments A Telegram bot interface Cron-based automated execution Wallet-based micro-deductions per request Solana settlement through Chainstack RPC By the end, you’ll understand how to build pay-per-request infrastructure for a telegram bot, without API keys, subscription dashboards, or centralized billing systems. 📖 Before jumping into this blog, you may read in detail about x402: x402 protocol: Architecture and payment flow for AI agents What is x402? ➡️ If you are already familiar with x402 and and ready to dive into coding, jump to "Build bot x402 on Solana step-by-step” section below. x402 is a protocol that revives the unused HTTP 402 Payment Required status code and turns it into a native web monetization primitive. Historically, HTTP 402 was reserved but never standardized. x402 gives it concrete meaning: A client requests a protected resource Server responds with 402 Payment Required The response includes payment instructions Client signs a payment The request is retried with proof of payment Server verifies and returns 200 OK Instead of API keys or subscription tokens, access is granted per request based on payment. Why micro-payments matter for AI Agents AI agents operate independently and execute tasks. An agent may: call a pricing API 10 times per minute, fetch a dataset once, execute a trade, or trigger a webhook. Traditional billing models are human-centric: API keys, monthly subscriptions, credit-based dashboards, and off-chain billing reconciliation. AI agents require deterministic cost per request, autonomous payment capability, stateless access control, and no human intervention. Micro-payments on Solana with x402 solve this. Instead of committing to a monthly subscription, agents pay per call. If an agent needs one request, it pays once. If it needs 1,000, it pays 1,000 times. Why Solana? ~400ms block times Low transaction fees High throughput USDC availability Mature RPC infrastructure With Solana, per-request settlement becomes economically viable. Why this matters for builders: you monetize APIs instantly, benefit from very low Solana transaction fees, no billing infrastructure required, revenue captured at the application layer, no API key leaks, fully programmatic access. This is foundational infrastructure for AI-native services. 🤖 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. Build bot x402 on Solana step-by-step We will use: A Chainstack account → Create your account for free @x402 libraries @payai/facilitator @solana/web3.js Telegram bot dotenv express Node.js Environment setup Set up Solana 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 Solana and then select “Solana Devnet” 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. Install dependencies: npm init -y npm install express dotenv npm install @x402/express @x402/fetch @x402/svm @payai/facilitator @scure/base @solana/kit @solana/web3.js npm install node-telegram-bot-api express : Minimal framework to create API routes. dotenv : Loads environment variables from .env. @x402/express : Provides paymentMiddleware to protect routes @x402/fetch : Provides wrapFetchWithPayment to auto-handle 402 responses @x402/svm : Provides ExactSvmScheme for Solana payments @payai/facilitator : Provides a facilitator to HTTPFacilitatorClient to verify payments @scure/base : Utility for base encoding/decoding @solana/kit : Helper utilities for Solana development @solana/web3.js : Official Solana SDK for blockchain interaction node-telegram-bot-api : build and connect to Telegram bots Create an .env file BOT_TOKEN= SVM_PRIVATE_KEY= SELLER_ADDRESS= SOLANA_RPC= SOLANA_RPC : The RPC endpoint URL obtained from Chainstack when the Solana node was deployed BOT_TOKEN : The token generated by BotFather for your Telegram bot SVM_PRIVATE_KEY : The Base58-encoded private key of the Solana wallet used to sign x402 payments SELLER_ADDRESS : The public Solana wallet address that receives payments for your API service ⚠️ Never commit .env. For best security practices use separate wallets for dev and production Build the x402 server ⚠️ If you do not wish to run a server , you can use x402 Echo https://x402.payai.network/ payai facilitator for testing purposes. All test payment will be instantly refunded. server.js is the payment-protected API layer Import the dependencies: import expressfrom"express"; import {paymentMiddleware,x402ResourceServer }from"@x402/express"; import {ExactSvmScheme }from"@x402/svm/exact/server"; import {HTTPFacilitatorClient }from"@x402/core/server"; import {facilitator }from"@payai/facilitator"; Initialize facilitator: constfacilitatorClient=newHTTPFacilitatorClient(facilitator); Create resource server: constresourceServer=newx402ResourceServer(facilitatorClient) .register( "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1", newExactSvmScheme() ); This registers the network, payment scheme and facilitator Protect Routes with paymentMiddleware Protected routes are /alpha and /track which will trigger a HTTP 402 USDC payment on Solana: app.use( paymentMiddleware( { "GET /alpha": { accepts: [ { scheme:"exact", price:"$0.001", network:"solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1", payTo:CONFIG.SELLER_ADDRESS, }, ], description:"Premium Solana news feed", mimeType:"application/json", }, "GET /track": { accepts: [ { scheme:"exact", price:"$0.001", network:"solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1", payTo:CONFIG.SELLER_ADDRESS, }, ], description:"Paid Solana price feed via Chainstack RPC", mimeType:"application/json", }, }, resourceServer ) ); Routes are declared payable. If unpaid: HTTP 402 Payment Required If paid: continue to the handler Run the server: node server.js Build the x402 client Now the Telegram bot must pay automatically. services.js defines utility functions: Solana Signer: This derives a signer from base58 private key asyncfunctiongetSigner() { returnawaitcreateKeyPairSignerFromBytes( base58.decode(CONFIG.SVM_PRIVATE_KEY) ); } Payment Logic : wrapFetchWithPayment expects fetch and client constclient=newx402Client(); client.register("solana:*",newExactSvmScheme(signer)); constfetchWithPayment=wrapFetchWithPayment(fetch,client); When calling endpoint: constresponse=awaitfetchWithPayment(url, { method:"GET", }); wrapFetchWithPayment: Detects 402, signs transaction, retries request & attaches PAYMENT-SIGNATURE Build the Telegram Bot bot.js initializes: exportfunctioninitBot(token) { constbot=newTelegramBot(token, { polling:true }); } On /start: Initializes subscription entry, explains pricing and lists commands On track: Pays $0.001, fetches Solana market data and returns structured market info On alpha: Cron-based auto-fetch of /alpha keep going on until stop or wallet balance below $10 Run a cron job: schedule("0 * * * * *",async () => { for (const [userId]ofsubscriptions) { awaitrunJob(userId); } }); Every minute: Check balance If < $10 → pause Call paid endpoint Deduct cost Send update You can set this to daily or trigger dynamically. This enables: Recurring payments Autonomous agent loops Wallet-based deductions Run client: node index.js Checking the bot execution Go to Telegram and send /start to the bot. Send command track to get latest insights on Solana Then send alpha to get latest news on Solana Cron job sends alpha when new news pops up Optionally, send stop to terminate the bot from giving alpha and auto deduct payments via x402. Security and production considerations When building autonomous micro-payment infrastructure, security and operational discipline are critical. Small mistakes can compound quickly when payments are triggered programmatically. Below are key safeguards to implement: Never expose private keys: Use .env and secure secret storage Protect RPC endpoints: Use IP whitelisting where possible Rate limit API endpoints: Prevent spam-triggered microtransactions Validate facilitator responses: Never assume settlement without verification Replay protection: Ensure nonce usage in the signature scheme Monitor cron frequency: Avoid accidental rapid-fire payment loops Separate dev and prod wallets: Never test with production funds Conclusion x402 on Solana turns HTTP 402 into a practical monetization layer for AI agents. With pay-per-request micro-payments, developers can build scalable API businesses without traditional billing complexity. In this guide, we built a complete pay-per-request architecture: a payment-protected resource server, an automated client that signs transactions, a Telegram bot interface, cron-based execution loops, and wallet-based micro-deductions settled on Solana using USDC. With a facilitator coordinating payments and reliable RPC infrastructure from Chainstack, the system operates without API keys, subscription dashboards, or centralized billing backends. Now you have the context and architectural blueprint to implement per-call monetization in your own stack, and with dependable infrastructure in place, you can deploy and scale your first x402-powered application with confidence. 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 → Related articles for reading ERC-8004: On-chain infrastructure for AI Agents on Ethereum Building a Web3 AI Trading Agent from Scratch Integrating Chainstack with OpenClaw Bot for Polymarket x402 protocol: Architecture and Payment Flow for AI Agents How to get Solana RPC endpoint 2026 #### x402 protocol: Architecture and payment flow for AI Agents TL;DR The x402 protocol formalizes how the HTTP 402 “Payment Required” status code can be used to enable native, programmatic payments across the internet. While HTTP 402 existed for decades as a reserved status code, it lacked a standardized implementation for real-world deployment. x402 defines the request–response structure, authorization format, verification logic, and settlement mechanisms required to make HTTP-level payments functional in production environments. By embedding stablecoin payment instructions directly into HTTP responses, x402 allows AI agents and applications to discover pricing, authorize transactions, and complete settlement without API keys, subscriptions, or centralized billing accounts. Instead of relying on prepaid credits or manual billing workflows, payment becomes part of the HTTP lifecycle itself. This article provides a technical breakdown of x402 architecture, payment flow, blockchain settlement, and infrastructure considerations for deploying x402 at scale. 🤖 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. What is x402 Protocol? At its core, x402 is an open internet-native payment protocol that leverages the HTTP 402 “Payment Required” code. It enables websites and APIs to programmatically request payment for access to data, content, or compute resources, allowing both applications and autonomous AI agents to complete transactions automatically. Payments are typically made in stablecoins and can be executed on any blockchain. By embedding payment directly into the HTTP request–response cycle, x402 eliminates the need for prepaid credits, API keys, know-your-customer (KYC) checks, or manual billing setups. Reduced fees and friction: Direct onchain payments without intermediaries, minimizing costs and eliminating manual setup. Transactions are near-instant and low-cost. Blockchain-agnostic design: Compatible with any blockchain that supports smart contracts, enabling flexible deployment across ecosystems through facilitators. Autonomous Payments: Supports granular, per-request or per-feature pricing through programmable pay-as-you-go flows, no API keys, subscriptions, or middlemen required, stateless. Machine-to-machine transactions: Enables AI agents to autonomously pay for and access services using stablecoins (e.g. USDC), each payment is transparent, verifiable, and stable, ideal for financial accountability in autonomous operations. The role of HTTP 402 in the x402 Protocol Historically, the web defined HTTP 402 “Payment Required” as a reserved status code intended for native web monetization. However, no standardized implementation emerged, and traditional payment systems were not designed for real-time, machine-to-machine transactions. As a result, HTTP 402 remained dormant. The x402 protocol builds on this reserved status code by defining a machine-readable payment schema, cryptographic authorization model, and settlement workflow. Instead of introducing a new transport layer, x402 extends HTTP itself, embedding payment semantics directly into the request–response cycle. In practice, a server returns HTTP 402 Payment Required along with structured payment metadata. The client authorizes payment and resubmits the request, allowing access to the protected resource once verification succeeds. The x402 standard, built by Coinbase, "fixing the internet's first mistake”, revives and extends HTTP 402 to enable pay-per-request transactions in stablecoins for both users and AI agents which lets any API endpoint request payment without prior account setup. Coinbase launched the new protocol in partnership with AWS (Amazon Web Services), stablecoin issuer Circle, AI company Anthropic and AI-focused proof-of-stake layer-1 blockchain Near Protocol. https://twitter.com/CoinbaseDev/status/1919784746881577239?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1919784746881577239%7Ctwgr%5E3551435e8e91e99f91abcf825eb0254c4f34fb20%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2FThe-Payment-Protocol-for-AI-Agents-Introduction-to-x402-s-Architecture-and-Ecosystem-305b408bc9a2807d85adf6ea89f60e73%3Fsource%3Dcopy_link Why x402 matters for AI Agents Artificial intelligence is evolving from content generation into autonomous digital agents capable of executing multi-step workflows. Modern AI agents can interpret objectives, call APIs, execute code, and adjust their actions based on results. However, most deployed agents face a structural limitation: they cannot transact natively on the internet. Instead, they rely on prepaid API keys, centralized billing systems, or human intervention for every payment. The x402 protocol addresses this limitation by enabling AI agents to pay programmatically at the HTTP layer. By embedding stablecoin payment logic into the request–response cycle, x402 removes the need for subscriptions or account setup and allows agents to access paid APIs and services autonomously. This shift transforms AI agents from tool users into economic actors capable of participating in decentralized, machine-to-machine markets. Why Solana dominates x402 payments While x402 is blockchain-agnostic, Solana has emerged as the dominant settlement layer, accounting for 50-80% of all x402 transactions: Sub-second finality (~400ms): Payments confirm before the HTTP responsetimeout, enabling true real-time micropayments Ultra-low fees (~$0.00025): Makes $0.01 API calls economically viable—something impossible on Ethereum L1 High throughput: Handles burst traffic when agents make thousands ofsimultaneous requests Native stablecoin support: USDC-SPL is widely adopted and fast to settle This makes Solana the practical choice for production x402 deployments where speed and cost matter. x402 Protocol architecture x402 enables programmatic payments over HTTP using a structured request–response flow. Instead of managing accounts, API keys, or prepaid balances, payment is embedded directly into the lifecycle of an HTTP request. When a client requests a paid resource, the server responds with payment requirements, the client authorizes payment, and the server verifies and fulfills the request. Initial request (GET /api) : A client (application, backend service, or autonomous AI agent) sends a standard HTTP request (e.g. GET /api/market-data) to a protected endpoint on the resource server. 402 Payment Required returned : If the request does not include valid payment, the server responds with HTTP 402 Payment Required. The response contains structured JSON metadata describing the payment terms in a machine-readable format. Example 402 response payload: { "maxAmountRequired": "0.10", "resource": "/api/market-data", "description": "Access to real-time market data requires payment.", "payTo": "seFkxFkXEY9JGEpCyPfCWTuPZG9WK6ucf95zvKCfsRX", "asset": "4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU", "network": "solana-devnet" }maxAmountRequired : Maximum amount required (e.g. $0.10)resource : Requested endpointdescription (optional) : Payment explanationpayTo : Recipient’s Solana wallet addressasset : SPL token mint address (e.g. USDC-SPL)network : Blockchain network identifier (e.g. solana-mainnet)In standardized implementations, additional fields may include: assetType : e.g. SPL expiresAt : expiration timestamp nonce : replay protection paymentId : unique payment identifier Field names and values may vary depending on the target blockchain network and token standard, but the overall structure and semantics remain consistent across implementations. Client constructs payload : The client parses the 402 response and generates a cryptographically signed authorization message using its Solana wallet. The signed payload includes:All payment request fieldsThe actual payment amount (≤ maxAmountRequired)Authorization timestampWallet signatureOn Solana, signatures follow the native Ed25519 signature scheme. No EIP-712 configuration is required. Request retried with payment : The client resubmits the same GET /api request, now attaching a PAYMENT-SIGNATURE header. In x402 v2, PAYMENT-SIGNATURE contains a Base64-encoded JSON representation of the signed authorization payload, serving as cryptographic proof that the client approved the transaction. Server calls verification endpoint (/verify) : Upon receiving the retried request, the server validates the PAYMENT-SIGNATURE. This may be handled locally or by calling a facilitator’s /verify endpoint. Both PAYMENT-SIGNATURE and PAYMENT-RESPONSE headers must contain valid Base64-encoded JSON strings. Base64 encoding ensures compatibility across HTTP implementations and avoids parsing issues caused by special characters in raw JSON. Facilitators are optional but simplify verification, multi-network support, and transaction broadcasting. Servers can choose to integrate directly with supported blockchains if they prefer full control over validation and settlement. https://twitter.com/programmer/status/1995590252497670572 Verification response returned : If a facilitator is used, it verifies:Signature validityToken standard complianceNetwork correctnessNonce uniqueness (replay protection)Expiration constraintsThe facilitator then returns a verification result to the server. Server performs requested work: If verification succeeds, the server executes the requested operation (e.g. compute, data retrieval, API logic). If verification fails, the server returns another HTTP 402 Payment Required. Settlement initiated (/settle): After successful verification, the server initiates settlement. This may involve calling a facilitator’s /settle endpoint or preparing a Solana transaction directly. Settlement options may include direct on-chain settlement or batched settlements for multiple micropayments Transaction broadcast to blockchain: If handled by a facilitator, the signed transaction is submitted to the blockchain network (e.g. USDC ) for execution. Transaction confirmation: Solana network processes and confirms the transaction, typically within sub-second finality (~400ms). Settlement confirmation returned: Once confirmed, the facilitator returns a “settled” confirmation response to the server with ultra-low cost (~$0.00025 per transaction), making tiny per-request payments economical. Final response with payment proof (200 OK): The server responds with HTTP 200 OK, including: The requested resource in the response body A PAYMENT-RESPONSE header containing a Base64-encoded JSON settlement record confirming that the SPL token payment was verified and executed on-chain x402 v2 is out with improved devX, fiat support, and extensions. https://twitter.com/CFchangelog/status/2021630544577171674?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E2021630544577171674%7Ctwgr%5E1604471bdd21f3ad400659d8ae036d60d7a4a3d4%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2FThe-Payment-Protocol-for-AI-Agents-Introduction-to-x402-s-Architecture-and-Ecosystem-305b408bc9a2807d85adf6ea89f60e73 x402 in Production Performance metrics x402 is designed for high-frequency, low-cost payments, enabling AI agents to transact seamlessly and autonomously. It has already reached meaningful scale across the agent economy, demonstrating sustained real-world usage across multiple networks. All-Time Statistics Total Transactions: 161.25M Total Volume Settled: $43.55M Total Buyers: 415K+ Total Sellers: 83K Out of which, Solana now accounts for ~50% - 80% of x402 transactions. https://twitter.com/x402/status/2018394709731713515 Real-World use cases x402 is the payment engine of the AI‑native, machine‑to‑machine economy. It embeds stablecoin payments directly into HTTP so that users or developers via AI Agents can enable a wide range of monetization models without subscriptions, API key management, or heavy billing infrastructure Below are the core use cases shaping the next wave of decentralized commerce. Autonomous AI agent payments Enables AI agents to automatically discover, negotiate, and pay for services, compute, or data without human intervention, turning agents into first‑class economic actors. Google’s Agent Payments Protocol (AP2): Uses x402 to let agents pay one another in stablecoins for completing tasks such as data retrieval, compute jobs, and multi‑step workflows. Cloudflare Agent SDK + MCP: Developers can now build agents that pay via x402 for features exposed through Model Context Protocol (MCP) servers. Stripe x402 on Base: Stripe has launched support for x402 payments on Base, letting developers charge autonomous AI agents directly in USDC for API calls, compute, data access, or HTTP requests via Stripe’s PaymentIntents API. https://twitter.com/base/status/2021413560740721048?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E2021413560740721048%7Ctwgr%5E1604471bdd21f3ad400659d8ae036d60d7a4a3d4%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2FThe-Payment-Protocol-for-AI-Agents-Introduction-to-x402-s-Architecture-and-Ecosystem-305b408bc9a2807d85adf6ea89f60e73 Kite AI: A native Layer‑1 blockchain integrated with x402, designed for autonomous agent payments and settlement, processing billions of inference calls and enabling agents to transact independently. Micropayments tooling Third‑party facilitators and SDKs enable broader adoption by abstracting blockchain complexity for developers. PayAI Network: Solana‑first facilitator handling settlement and discovery of agent‑payable services. t54: t54’s x402‑Secure adds identity, verification, and risk management for agent payments, protecting against fraudulent or unwanted transactions by evaluating agent behavior before settlement x402scan: Tools for explorer dashboards, secure payment flows, and developer integration templates across Solana and Base. Awal: An AI‑native, agentic wallet designed specifically for autonomous agents to store, manage, and spend digital assets seamlessly. Pay‑per‑use API monetization Let's APIs charge per request with instant stablecoin settlement, removing subscriptions and API keys altogether. Corbits: Any API endpoint can become a paid resource that agents or apps call and pay for programmatically. CoinGecko x402 APIs: CoinGecko integrated x402 to let autonomous agents pay USDC per request for price and on‑chain data, creating programmatic access for bot‑based arbitrage or analytics. Browserbase: Lets users pay per minute for browser automation sessions using x402, an example of micropayments beyond just APIs. On-demand content Creators can monetize articles, images, video, research, datasets, or any digital content with micro‑payments, no accounts or digital wallets needed up front. Numbers Protocol: Numbers Protocol uses x402 for search → pay → license flows that let users instantly pay for verified digital assets and automatically receive on‑chain rights (e.g., Receipt NFTs), an economic model for the AI web. Independent builders have demos of pay‑per‑article or pay‑per‑dataset flows where agents and humans alike trigger micropayments in USDC for access. Cross‑chain payments Expands agentic payments beyond a single chain so networks like Ethereum L2s, Polygon, and MultiversX can support machine payments. Sei Network Integration: Sei is one of the first chains to support x402, positioning itself as “TCP/IP for value” in the agentic web and enabling cross‑platform settlement. (see x402 x MultiversX: enabling agentic payments with native tokens and low‑fee settlement. Bridges and payment facilitators expanding support to Polygon, BNB Chain, and more broadening the agentic economy’s rails. https://twitter.com/MultiversX/status/2016881621530791952 x402 turns every API, service, dataset, and agent interaction into a potential revenue model. It enables AI agents to behave like autonomous economic participants, developers to monetize services per use, and creators to earn instantly for digital assets, all built on a neutral, HTTP‑native payment standard that scales with the next internet. Building with x402 x402 is supported by a growing suite of developer tooling that makes integration straightforward across agents, APIs, and services. From documentation to SDKs and turnkey Solana templates, builders can quickly integrate pay-per-request monetization into their applications. Below are key tools supporting the ecosystem. Core documentation x402 Docs: Official GitBook documentation covering protocol architecture, request–response flows, verification, settlement, and implementation guides. x402 Whitepaper (PDF): Technical specification outlining the protocol architecture, verification flow, and settlement design. GitHub Repository: Issues, proposals, reference implementations, and ongoing protocol development. Frameworks & SDKs Faremeter: An open-source framework designed specifically for agentic payments, enabling developers to integrate structured pricing and autonomous settlement flows. x402Secure: A security-focused SDK that adds an additional protection layer to x402 transactions, including identity verification, behavioral checks, and fraud mitigation controls. Privy: Wallet infrastructure that allows developers to integrate x402 with embedded Privy wallets, simplifying user and agent onboarding. Payment & monetization tools PayAI: Infrastructure for selling services directly via x402, abstracting blockchain complexity and simplifying merchant-side integrations. Coinbase Hosted Facilitator (Base): Managed verification and settlement infrastructure with supported network integrations. MCP with x402: Enables developers to payment-gate Model Context Protocol (MCP) servers using x402, allowing AI agents to pay per tool invocation or data request. Developer resources Solana Templates: Pre-built templates for launching x402-enabled services on Solana, accelerating development with ready-to-deploy configurations Infrastructure for AI Agents AI agents require reliable blockchain infrastructure to interact with x402 payment flows. Unlike human users, agents can't manually retry failed requests or troubleshoot RPC errors—they need predictable, always-on access to verify balances, submit transactions, and confirm settlement. Chainstack: Enterprise-grade RPC infrastructure purpose-built for AI agent workloads. For x402 specifically: Solana RPC endpoints are designed to support low-latency verification and settlement workflows for x402 payments 99.99% uptime SLA: Critical for autonomous agents that can't handle manualintervention when RPC endpoints fail Request-based pricing: Aligns with x402's micropayment model—pay only for whatagents use, with no compute-unit complexity WebSocket support: Real-time transaction monitoring for agents that need to confirmsettlement before proceeding with workflows Archive node access: Historical payment verification for compliance, auditing, ordispute resolution Global endpoints: Low-latency access from wherever agents are deployed (US, EU,APAC) Traditional RPC providers charge by compute units or have unpredictable rate limits. Chainstack's transparent, request-based model makes it simple to budget agent infrastructure costs at scale. Get RPC for AI agents → Conclusion The future of AI agents depends not only on intelligence, but on the ability to transact autonomously within decentralized ecosystems. x402 fills this gap by enabling verifiable, programmatic payments at the API layer, allowing agents to pay for data, compute, and services seamlessly. To operate reliably in production, agents also require dependable blockchain infrastructure. Robust RPC access ensures high-frequency verification and settlement can occur without manual intervention. Infrastructure providers such as Chainstack deliver the uptime, low latency, and predictable performance needed to support agent-native payment flows at scale. Start building AI agents now → FAQ What is x402 protocol? x402 is an open protocol that enables AI agents and applications to pay for APIs, data, and compute resources programmatically using stablecoins over HTTP. It revives the HTTP 402 "Payment Required" status code with a standardized implementation for real-world use. Why does Solana dominate x402 payments? Solana accounts for 50-80% of x402 transactions due to its sub-second finality (~400ms), ultra-low fees (~$0.00025 per transaction), high throughput, and native USDC support. These characteristics make it ideal for real-time micropayments at scale. How do AI agents use x402 to pay for services? AI agents send HTTP requests to x402-enabled APIs. When payment is required, the server returns a 402 response with payment details. The agent cryptographically signs the payment, resubmits the request, and the server verifies and settles the transaction on-chain before providing access. What blockchain infrastructure do x402 agents need? x402 agents need reliable RPC endpoints to verify balances, submit transactions, and confirm settlements. Enterprise-grade infrastructure like Chainstack provides the 99.99% uptime, low latency, and predictable pricing required for production agent workloads. Can x402 work on blockchains other than Solana? Yes, x402 is blockchain-agnostic and works on any chain with smart contract support. Implementations exist on Base, MultiversX, Sei, and other networks. However, Solana's speed and low cost make it the dominant choice for production deployments. Related AI agent infrastructure articles ERC-8004: On-chain infrastructure for AI Agents on Ethereum Building a Web3 AI Trading Agent from Scratch Integrating Chainstack with OpenClaw Bot for Polymarket #### Yellowstone gRPC: more concurrent streams, same price We've increased the concurrent stream limits on the Yellowstone gRPC Geyser plugin add-on across two tiers: $49/month — 2 concurrent streams (up from 1) $149/month — 7 concurrent streams (up from 5) Why this matters Each concurrent stream is an independent subscription to the Solana validator event feed — accounts, transactions, slots, blocks. Indexing transactions for one program while tracking account state for another is two streams. Running a production feed alongside a staging environment for testing is two streams. Each subscription counts separately. Two streams at $49/month means you can keep a production feed running on one connection while developing, testing, or debugging on the second — no teardown, no shared state, no interference. At $149/month, seven streams gives you room to split workloads cleanly across production, analytics, indexing, and monitoring — rather than cramming them into 5 and multiplexing in application code. No action needed Updated limits apply automatically to existing subscriptions. Nothing changes in your code or configuration. New to Yellowstone gRPC on Chainstack? Yellowstone gRPC gives you a direct push-based feed from the Solana validator — accounts, transactions, blocks, and slot updates streamed over gRPC the moment they're processed. No polling, no getProgramAccounts hammering, no lag from repeated RPC round-trips. The add-on is available on Growth plans and above. To get started: deploy a Solana node in the Chainstack console, then add the Yellowstone gRPC plugin from the marketplace. View the Yellowstone gRPC docs → Additional reading Introducing real-time Solana streaming with Yellowstone gRPC Geyser How to use the Solana Geyser plugin to stream data with Yellowstone gRPC Best Yellowstone gRPC providers for Solana in 2026 #### Zeedex on Chainstack: Skyrocketing a DEX with no gas fees By offloading Ethereum infrastructure management to Chainstack, Zeedex launched their mainnet on time, achieved a 50% reduction in the total cost of ownership (TCO), and decreased DEX transaction latency by 35%. Zeedex is a decentralized exchange with off-chain matchmaking and on-chain settlements. Heavily inspired by projects like Uniswap and IDEX, Zeedex plans to provide the best of both worlds. https://www.youtube.com/watch?v=j05yr4ULhv0 What does Zeedex do? Zeedex is a decentralized exchange that provides depositless and non-custodial limit orders, while simultaneously reducing trading fees on both the Ethereum and BNB Smart Chain networks. Zeedex’s users benefit from off-chain matchmaking and on-chain settlements resulting in zero gas fees. How did Zeedex come across Chainstack? Looking for an efficient solution for an Ethereum node with a JSON interface, archive data, and a backend service watcher with the ability to settle hundreds of transactions per second, Zeedex’s team experimented with many managed blockchain service providers and, after careful evaluation, Chainstack was hands down the best provider of Ethereum nodes on the market. How does Chainstack's offer fit into Zeedex? Zeedex was looking at multiple infrastructure solutions to run the exchange that they built. They tried many products but were strapped by limitations like daily limits and heavy rates. After trying, experimenting, and almost giving up on finding a solution that fit them, Zeedex’s team came across Chainstack. According to Zeedex’s engineering team, Chainstack has been a perfect fit for Zeedex due to: Pay-per-use pricing model and competitive shared node pricing. Proven uptime and reliability track records that enhance the trust Zeedex users and community have towards the exchange. Reliable WebSocket and RPC endpoints. Simple transition from other Ethereum service providers. Highly responsive engineering support. Chainstack takes care of node operations from deployment to management and monitoring. Joining forces with Chainstack turned out to be the most optimal and cost-effective solution for Zeedex because their team could focus on core product development (decentralized exchange) without worrying about the underlying blockchain infrastructure operations. What does Zeedex like about Chainstack? Zeedex trusts Chainstack with critical parts of their infrastructure. Chainstack continues to prove itself as a reliable and trustworthy technical partner, being able to handle sensitive and complex deployment needs. Zeedex is delighted with the service and support from Chainstack, because the Chainstack support team went the extra mile to help in every step while launching Zeedex’s decentralized exchange. What is the most interesting engineering challenge in working together? On the day of Zeedex’s mainnet launch, an update was pushed to the decentralized exchange SDK, which was a part of the Zeedex wallet. This made the Zeedex team worried about being able to meet the launch target, as this update affected the existing authentication methods and could have caused a delay in the launch of the DEX. Looking for an immediate solution with only six hours to go to the launch of the mainnet, Zeedex didn’t expect any help, since “it usually takes other providers 24-48 hours to reply back”. The Chainstack support team quickly recognized the urgency of the request, and in a few hours the Zeedex team received a solution that made the launch target possible. “It was the Chainstack team that came through with a quick solution, and the launch went smoothly”, says Kyunghun Cheong, Zeedex founder. 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. #### zkEVM and zkRollups Explained As Ethereum became one of the most popular blockchains, its high adoption and use for currency exchanges and data interaction caused the network to reach its capacity (over 1 million transactions per day) and high demand for using it. This demand increased the gas fees that users are required to pay substantially. The problem of Scalability The popularly known blockchain trilemma involves being aware of providing a decentralized, secure and scalable network. However, to give decentralization and security, it must often sacrifice scalability. At its current state, the Ethereum mainnet is only able to process 15 transactions per second. Usually, the network becomes congested, thus leading to slower transactions, increasing transaction fees, and becoming unusable for those who cannot afford them. In this regard, the main goal of scalability is to increase transaction speed and throughput without sacrificing the other aspects of the trilemma: decentralization and security. Sharding, layer two and zk rollups The scalability problem is a known issue addressed by the Ethereum community and the foundation. A solution for this is sharding.   Commonly, sharding consists of splitting a database horizontally to spread its load. In the blockchain, this could reduce the congestion and increase the throughput by creating new chains known as “shards”. Also, validators will no longer be required to process all transactions on the network.  A layer two solution corresponds to a separate blockchain that takes advantage of Ethereum layer 1, extending its security and decentralization mechanisms. Usually, it communicates with the layer one solution submitting bundles of transactions as just one transaction. It takes the transaction load away from Ethereum and then submits proofs of the validated transactions back to layer 1. Learn more about layer two solutions and check how they work.   A rollup bundles many transactions that get verified outside layer one and submits them as a single transaction, thus distributing the load and fees across the transaction senders in the rollup. Currently, there are two approaches to rollups: optimistic and zero-knowledge. The main difference is how they validate the transaction submitted to layer one. As we will focus on zero knowledge, check this detailed explanation about optimistic rollups.  Zero-knowledge rollups and zkProofs A zk-rollup bundles up to thousands of transactions in a batch that gets executed off-chain. Instead of an optimistic rollup, it just needs to post a summary of all transactions rather than all transaction data on-chain, making them more scalable. The verification of these transactions comes in the form of a validity proof, which is used to update the zk-state and consists of cryptographical and mathematical calculation. This state is maintained by smart contracts on the Ethereum mainnet. A zero-knowledge proof consists of a prover (in this case, the VM off-chain) who proves that a statement (a transaction or bundle of transactions) is valid without revealing the intrinsic method that verifies the information. So, for example, I can tell you I own an email address by sending an email notifying you I’m the guy sending it, but without revealing my credentials for anyone to check it. zk-Snarks A zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a type of zero-knowledge proof that the proof itself is some data being verified without any interaction from the prover.In short terms, it generates proof that some prover knows a witness that satisfies some program (i.e., A transaction or expression). For example, the following diagram illustrates the process of a simple zk-SNARK. zero-knowledge EVM The Ethereum Virtual Machine (EVM) wasn’t designed to work with zk-proof-computation. There’s no possibility of executing complex transactions like smart contracts with zk-proof-computation. A zkEVM is an attempt to build an EVM-compatible for rollups with zk-proofs while preserving the EVM codes and the knowledge derived from it so far. The main drawback of trying to take advantage of EVM’s characteristics is that the EVM works as a stack of data and operations computed to transition into states. While a zkEVM would necessarily need to include the zk circuit to prove the correctness of transactions processed. The more straightforward approach considers adapting the low-level side of the virtual machine to have this circuit but losing the tools and infrastructure already provided for the EVM. Some methods believe this in much or lesser detail and the access from developers and builders to a new type of EVM that is more Ethereum-like and takes advantage of the zk-rollup scalability. In this regard, Vitalik Buterin, founder of Ethereum, and teams from projects working on zkEVM development described five types of zkEVM equivalences with the normal EVM. Type 1 zkEVM (Fully Ethereum-equivalent)  This type of zkEVMs does not change any part of the current Ethereum system. Therefore, its primary goal is to verify transactions, blocks, and data as they are being verified today.Its effect is to allow execution clients to be used as-is to generate and process rollup blocks.However, it can take many hours to produce current proofs times for Ethereum blocks. Type 2 (fully EVM-equivalent)  Type 2 zkEVMs look exactly like Ethereum but differ in ways, such as data structures and the state tree. Its main goal is to be compatible with existing applications today but modify Ethereum in some minor ways to ease development and increase the speed of proof generation. However, it still needs to improve in the prover time.One can solve some worst-case scenarios for proof generation by increasing gas costs on specific operations. However, it may break some applications and reduce the developer toolkit compatibility. This operation is addressed as Type 2.5 zkEVM. Type 3 (almost EVM-equivalent)  Type 3 zkEVMs sacrifice some features from the EVM to improve proof times. These features often belong to the precompiles smart contracts of Ethereum contracts; also the way they handle contract code, the VM memory, and its stack.In this case, most applications already built on the well-known EVM are considered to work, but some of them will need to be rewritten in case they are using some of the functionalities removed on this type of zkEVMs. Type 4 (high-level-language equivalent)  This type of zkEVM compiles a smart contract code written in a high-level language (e.g., Solidity) into a ZK-SNARK-friendly language. This could drastically reduce the costs of building a zkEVM, but most of the tools already developed wouldn’t work (e.g., Debugging an EVM bytecode). Also, contracts wouldn’t have the same address as bytecodes could change on transpilation from language to language. Conclusion Zk technology for blockchain is still early and has a lot of considerations, advantages, and drawbacks in its implementation. For example, proof validation uses circuits that can be very expensive to execute on each step of the computation of an EVM to transition to new states.  Despite its complexity, researchers and the community have taken advantage of zk-rollups in a native way and are addressing the scalability problem of Ethereum’s original mechanisms. Hopefully, more projects like Polygon zkEVM, Scroll, zkSync, and Applied ZKP will get into the ecosystem and come up with a complete solution that doesn’t necessarily need to make a tradeoff between compatibility and speed.  #### zkSync Faucet - Claim Free zkSync ETH Introducing the zkSync 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 zkSync Testnet Faucet, designed with Web3 developers like you in mind. Get zkSync ETH How to use the zkSync faucet Once you're registered ↗ and have an API key ↗ set up on the Chainstack platform, you can get up to 0.05 zkSync ETH every 24 hours. This ETH can be used to send transaction on the zkSync 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 zkSync faucet, watch the video demo below: https://www.youtube.com/watch?v=UQYNGzQGQ9E 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 zkSync ETH that you can request to a maximum of 0.05 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 zkSync testnet 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 zkSync nodes If you are looking for fast and reliable zkSync 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 protocol, every API, every tool that you’ll ever need to build any DApp at scale. Get zkSync 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 zkSync testnet ETH to test your smart contracts before pushing them to production. What is the zkSync testnet? According to zkSync themselves “zkSync is a Zero Knowledge (ZK) rollup that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of zkSync Era is that developers who have created EVM dApps can port to zkSync Era effortlessly and realize significantly lower gas fees and more transactions per second while inheriting Ethereum's security and decentralization.” The testnet is therefore a playground for developers, where you can test your DApps and make sure all the functions work as intended, 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.05 zkSync ETH daily. What are zkSync testnet Ethereum tokens? A zkSync testnet Ethereum token is the gas fee token for the zkSync 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 zkSync 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 ### Pages #### About URL: https://chainstack.com/about/ #### Agents URL: https://chainstack.com/agents/ #### Alchemy vs Ankr: End-to-End Comparison URL: https://chainstack.com/alchemy-vs-ankr-end-to-end-comparison/ #### Alchemy vs Quicknode: End-to-End Comparison URL: https://chainstack.com/alchemy-vs-quicknode-end-to-end-comparison-chainstack/ #### Ankr vs Quicknode: End-to-End Comparison URL: https://chainstack.com/ankr-vs-quicknode-end-to-end-comparison/ #### Apechain Protocols Apechain #### Aptos A public permissionless non-EVM Layer 1 network secured by proof-of-stake. #### Arbitrum A public permissionless L2 optimistic rollup to Ethereum with smart contract capabilities. #### Archive Blockchain Data URL: https://chainstack.com/archive-data/ #### Astar Protocols Astar #### Aurora URL: https://chainstack.com/protocols/aurora/ #### Avalanche URL: https://chainstack.com/protocols/avalanche/ #### Base A secure, affordable, and developer-friendly Ethereum L2 solution, powered by Optimism's open-source OP Stack, designed to democratize Ethereum access and onboard the next billion users. #### Berachain Protocols Berachain #### Bitcoin URL: https://chainstack.com/protocols/bitcoin/ #### Bitlayer Protocols Bitlayer #### Blast Protocols Blast #### Blockchain Data for AI Companies Blockchain Data for AI Companies AI products are only as good as the data behind them. Chainstack gives your agents and applications reliable, deep blockchain data across 70+ protocols — real-time state, full archive history, and native AI integrations to keep your products grounded in what’s actually happening on-chain. Get started for free Contact sales Built for AI workloads AI products that reference blockchain data need more than a basic API. They need infrastructure-grade access — real-time on-chain state for accurate responses, deep historical data for context, and predictable pricing that scales. Chainstack provides all three, across more chains than any other provider. Native AI integration Chainstack comes with a native MCP server that gives your AI agents full platform access and Chainstack's Web3 expertise — deploy nodes, manage infrastructure, and tap into years of blockchain knowledge, all through a single Streamable HTTP URL you add to any MCP-compatible client. Plus, AI-ready docs via llms.txt for seamless LLM integration. BREADTH 70+ protocols, one platform From Ethereum and Solana to Base, Hyperliquid, and Tempo — Chainstack supports over 70 blockchain protocols. Ground your AI products in the broadest multi-chain data available from a single provider. EVMs and non-EVMs alike. DEPTH Full archive and Debug & Trace Access complete historical blockchain data through archive nodes and low-level execution traces via Debug & Trace APIs. Critical for accurate on-chain context, forensic analysis, and building AI products that reflect the full picture. SPEED Real-time streaming Solana Geyser gRPC streaming for high-throughput, low-latency data pipelines. WebSocket subscriptions across all supported chains. Your agents get the data the moment it hits the chain — not seconds later. RELIABILITY Enterprise-grade infrastructure Global elastic node infrastructure with built-in health checks, automatic failover, and managed client upgrades. Your AI system’s data layer doesn’t go down because a node missed a fork. We handle all the updates. INTEGRATION Works with any model Compatible with any LLM — OpenAI GPT, Anthropic Claude, Google Gemini, DeepSeek, or compact local models. Standard native RPC APIs with comprehensive documentation. If it’s an LLM, it works with Chainstack. CONTROL Predictable, transparent pricing Simple request-based pricing: 1 RU per standard call, 2 RUs for archive or Debug & Trace. No compute units, no hidden multipliers. Set quotas, monitor usage in real time, and forecast costs as your AI scales. What you can build Give your AI products accurate, real-time blockchain context across 70+ chains. Power agents with live on-chain state so they respond with facts, not hallucinations. Build cross-chain analytics that span every major protocol. Feed DeFi intelligence into trading and risk systems. Run compliance and forensic analysis with complete execution traces. Ready to power your AI with blockchain data? Whether you’re building AI agents that operate on-chain, grounding LLM responses in real blockchain state, or providing blockchain intelligence to enterprise clients — Chainstack gives you the data infrastructure to move fast and scale. Start with a free plan. Scale to billions of requests. Talk to our team about enterprise needs. Full node request 1 RU Archive node request 2 RUs Debug & Trace APIs 2 RUs Geyser gRPC (Solana) Marketplace Ready to give your AI the best blockchain data? Get started for free #### blockchain infrastructure for fintech URL: https://chainstack.com/blockchain-infrastructure-for-fintech/ #### Blockchain infrastructure for RWA URL: https://chainstack.com/blockchain-infrastructure-for-rwa/ #### Blockchain Node Hosting Hosting #### Blockchain RPC Nodes Optimized for AI Agents Chainstack RPC endpoints use standard native APIs, making it straightforward for AI agents to call functions and get clear, well-documented responses for both successes and errors #### Blog URL: https://chainstack.com/blog/ #### BNB Smart Chain URL: https://chainstack.com/protocols/bnb-smart-chain/ #### Botanix Protocols Botanix #### Bsquared Protocols Bsquared #### Build Better With Apechain Nodes URL: https://chainstack.com/build-better-with-apechain/ #### Build better with Aptos nodes Run high-performing Aptos RPC nodes and APIs in minutes on a platform built for scale. #### Build better with Arbitrum nodes Run high-performing Arbitrum RPC nodes and APIs in minutes on a platform built for scale. #### Build Better With Astar Nodes URL: https://chainstack.com/build-better-with-astar/ #### Build better with Avalanche nodes Run high-performing Avalanche RPC nodes and APIs in minutes on a platform built for scale. #### Build Better with Base nodes URL: https://chainstack.com/build-better-with-base/ #### Build better with Berachain nodes URL: https://chainstack.com/build-better-with-berachain/ #### Build Better with Bitcoin nodes URL: https://chainstack.com/build-better-with-bitcoin/ #### Build Better With Bitlayer Nodes URL: https://chainstack.com/build-better-with-bitlayer/ #### Build better with Blast nodes URL: https://chainstack.com/build-better-with-blast/ #### Build Better With Botanix Nodes URL: https://chainstack.com/build-better-with-botanix/ #### Build Better With Bsquared Nodes URL: https://chainstack.com/build-better-with-bsquared/ #### Build Better With Cardano Nodes URL: https://chainstack.com/build-better-with-cardano/ #### Build better with Celo nodes URL: https://chainstack.com/build-better-with-celo/ #### Build Better With Centrifuge Nodes URL: https://chainstack.com/build-better-with-centrifuge/ #### Build Better With Core Nodes URL: https://chainstack.com/build-better-with-core/ #### Build Better With Corn Nodes URL: https://chainstack.com/build-better-with-corn/ #### Build better with Cronos nodes Run high-performing Cronos RPC nodes and APIs in minutes on a platform built for scale. #### Build better with Dogechain nodes URL: https://chainstack.com/build-better-with-dogechain/ #### Build Better With Dogecoin Nodes URL: https://chainstack.com/build-better-with-dogecoin/ #### Build better with Ethereum nodes Run high-performing Ethereum RPC nodes and APIs with wide geographical distribution, and build on a powerful infrastructure designed for scale. #### Build Better With Etherlink Nodes URL: https://chainstack.com/build-better-with-etherlink/ #### Build better with Fantom nodes Run high-performing Fantom RPC nodes and APIs in minutes on a platform built for scale. #### Build Better With Fraxtal Nodes URL: https://chainstack.com/build-better-with-fraxtal/ #### Build better with Gnosis Chain nodes Run high-performing Gnosis Chain RPC nodes and APIs in minutes on a platform built for scale. #### Build Better With Hashkey Nodes URL: https://chainstack.com/build-better-with-hashkey/ #### Build Better With Hyperliquid Nodes URL: https://chainstack.com/build-better-with-hyperliquid/ #### Build Better With Ink Nodes URL: https://chainstack.com/build-better-with-ink/ #### Build better with Kaia nodes URL: https://chainstack.com/build-better-with-kaia/ #### Build Better With Katana Nodes URL: https://chainstack.com/build-better-with-katana/ #### Build Better With Kroma Nodes URL: https://chainstack.com/build-better-with-kroma/ #### Build Better With Lens Nodes URL: https://chainstack.com/build-better-with-lens/ #### Build Better With Linea Nodes URL: https://chainstack.com/build-better-with-linea/ #### Build Better With Mantle Nodes URL: https://chainstack.com/build-better-with-mantle/ #### Build Better With MegaETH URL: https://chainstack.com/build-better-with-megaeth/ #### Build Better With Merlin Nodes URL: https://chainstack.com/build-better-with-merlin/ #### Build Better With Metis Nodes URL: https://chainstack.com/build-better-with-metis/ #### Build Better With Mind Nodes URL: https://chainstack.com/build-better-with-mind/ #### Build Better With Mint Nodes URL: https://chainstack.com/build-better-with-mint/ #### Build Better With Monad Nodes URL: https://chainstack.com/build-better-with-monad/ #### Build better with Moonbeam nodes URL: https://chainstack.com/build-better-with-moonbeam/ #### Build better with Oasis Sapphire nodes URL: https://chainstack.com/build-better-with-oasis-sapphire/ #### Build better with opBNB nodes Run high-performing opBNB nodes in minutes on a platform built for scale. #### Build better with Optimism nodes Run high-performing Optimism RPC nodes and APIs in minutes on a platform built for scale. #### Build Better With Plasma Nodes URL: https://chainstack.com/build-better-with-plasma/ #### Build better with Plume nodes URL: https://chainstack.com/build-better-with-plume/ #### Build Better With Polkadot Nodes URL: https://chainstack.com/build-better-with-polkadot/ #### Build better with Polygon nodes Run high-performing Polygon RPC nodes and APIs in minutes on a platform built for scale. #### Build Better with Polygon zkEVM nodes URL: https://chainstack.com/build-better-with-polygon-zkevm/ #### Build Better with Ronin nodes URL: https://chainstack.com/build-better-with-ronin/ #### Build Better with Scroll nodes URL: https://chainstack.com/build-better-with-scroll/ #### Build Better With Shibarium Nodes URL: https://chainstack.com/build-better-with-shibarium/ #### Build better with Solana nodes Keep your dapp fluid and frictionless with reliable, low-latency RPC infrastructure. #### Build Better With Soneium Nodes URL: https://chainstack.com/build-better-with-soneium/ #### Build better with Sonic nodes URL: https://chainstack.com/build-better-with-sonic/ #### Build better with Starknet nodes Run high-performing Starknet RPC nodes and APIs in minutes on a platform built for scale. #### Build better with Sui nodes URL: https://chainstack.com/build-better-with-sui/ #### Build better with Taiko nodes URL: https://chainstack.com/build-better-with-taiko/ #### Build Better With Tempo Nodes URL: https://chainstack.com/build-better-with-tempo/ #### Build better with TON nodes URL: https://chainstack.com/build-better-with-ton/ #### Build better with TRON nodes URL: https://chainstack.com/build-better-with-tron/ #### Build Better With Unichain Nodes URL: https://chainstack.com/build-better-with-unichain/ #### Build Better With WeMix Nodes URL: https://chainstack.com/build-better-with-wemix/ #### Build Better With XLayer Nodes URL: https://chainstack.com/build-better-with-xlayer/ #### Build Better With Zircuit Nodes URL: https://chainstack.com/build-better-with-zircuit/ #### Build Better With zkLink Nodes URL: https://chainstack.com/build-better-with-zklink/ #### Build better with zkSync Era∎ URL: https://chainstack.com/build-better-with-zksync-era/ #### Build Better With Zora Nodes URL: https://chainstack.com/build-better-with-zora/ #### Build on Chainstack URL: https://chainstack.com/developers/ #### California Privacy Notice California Privacy Notice This California Privacy Rights Notice (“California Privacy Notice“) explains privacy rights available to residents of the State of California as required by the California Consumer Privacy Act of 2018 (“CCPA”). If this California Privacy Notice and any provision in Chainstack Privacy Notice conflict, then this California Privacy Notice controls for the processing of Personal Information (as defined below) of residents of the State of California. In CCPA, California residents are referred as “consumers” and we refer to them in this California Privacy Notice as “California Consumers” and “Personal Information” means information that identifies, relates to, describes, is capable of being associated with or could reasonably be linked, directly or indirectly, with a particular California Consumer or household. The Chainstack website collects Personal Information. In the past 12 months we may have collected the following categories of Personal Information from California Consumers. CategoryExamplesPurposeIdentifiersName, postal address, email address, unique identifier, Internet Protocol address, account name, and similar identifiers.To provide you with information about the Services that you request from us; to provide and deliver our Services; to prevent fraudulent transactions.Commercial informationServices purchased, obtained, or considered; other purchasing or consuming histories or tendenciesTo analyze the way in which California Consumers are accessing and using our Services so that we can perform necessary marketing activities; to further improve our website and Services.Internet or other similar network activityBrowsing history; search history; unique personal identifier; online identifier; Internet Protocol address; information on a California Consumer’s interaction with a website, application, or advertisementTo analyze how our California Customers and users access and use our website and Services and to improve the consumer experience.Geolocation dataPhysical location or movementsTo ensure the proper website experience is delivered; to analyze web traffic so as to conduct marketing activities. In addition to the purposes stated above, we may use or disclose Personal Information obtained from you for one or more of the following business purposes: To fulfill or meet the reason you provided the Personal Information. For example, if you share your name and email address to receive information about our Services, we will use that Personal Information to respond to your inquiry. If you provide your Personal Information to purchase our Services, we will use that Personal Information to process your payment and provision the applicable Services that you purchased. To provide, support, personalize, improve, and develop our website, your interaction with our website or Services. To provide you with the information that you request from us. To create, maintain, customize, and secure your account or platform. To prevent transactional fraud. As necessary or appropriate to protect the rights, property or safety of us, our California Consumers or others. To provide you with support and to respond to your inquiries, including to investigate and address your concerns and monitor and improve our responses. To deliver targeted content and relevant offerings, including event registrations, alerts, offers, and ads delivered through our website and via email (with your consent, where required by law). For testing, research, and analysis of our website or Services. To respond to valid law enforcement requests and as required by applicable law, court order, or governmental regulations. As described to you when collecting your Personal Information or as otherwise set forth in the CCPA. As a California resident, you may have one or more of the following rights under the CCPA: the right to know: the categories of personal information we have collected;  the categories of sources used to collect the personal information;  the business or commercial purposes for collecting your personal information;  the categories of recipients with whom we share your personal information, including for cross-contextual behavioral advertising purposes; and  the specific pieces of personal information we have collected about you the right to request, on legitimate grounds, deletion of your personal information that we collected; the right to opt out of our sharing your personal information for the purpose of cross-contextual behavioral advertising the right, in certain circumstances, to correct the inaccurate personal information we collected about you; and the right not to be discriminated against for exercising any of these rights. #### Cardano Protocols Cardano #### Celo Protocols Celo #### Centrifuge Protocols Centrifuge #### Chainstack - Web3 Cloud hosting solution URL: https://chainstack.com/chainstack-cloud/ #### Chainstack Affiliate Terms Chainstack Affiliate Terms Last Updated: 24 June 2024 These Affiliate Terms constitute a binding agreement (the “Agreement”) between Chainstack Pte. Ltd. (“Chainstack”, “we”, “us”, “our”) and Affiliate (“Affiliate”, “you”) each, a “party”, or, collectively, “parties”). Affiliate accepts and agrees to be bound by the Agreement by signing an Acknowlegment Form for Chainstack Affiliate Terms. DEFINITIONS "Affiliate" or "you" means any person or legal entity, which signs and completes the Chainstack Affiliate Terms and becomes a participant of the Chainstack Affiliate Program. Participation in the Chainstack Affiliate Program is prohibited to individuals and entities who possess a voting or political interest in Chainstack, including Chainstack officers, directors, stockholders, and employees of Chainstack, and their immediate families. "Commission" means the reward you receive, according to the Offering Page for participating in Chainstack Affiliate Program; The sale occurs when an End User visits the Chainstack Website through a Reference Link and makes a payment for Chainstack Services and/or Subscription and usage or otherwise as described herein. "Commission Payment" refers to a reward on the terms, agreed on the Offering Page. "Cookie life period" unless otherwise stated herein, means 1 (One) year from the date of End User's first arrival on the Chainstack Website through Affiliate's Reference Link according to this Agreement. "End User" means the authorized actual new user of the Chainstack Service, who registers for a paid account on the Chainstack Website. "Reference Link" means a link that leads to the Chainstack Website and is your official affiliate link. You will receive your affiliate link only after becoming the participant of Chainstack Affiliate Program. "Chainstack Affiliate Program" is a reward program, developed by Chainstack that allows you, the Affiliate, to use marketing methods to promote our services and drive traffic to the Chainstack Website, pursuant to the provisions of this Agreement. "Chainstack Service" means the blockchain managed service platform, applications, and tools, that the users view or subscribe for, that are developed, maintained, operated by us, accessible via Chainstack Website. "Chainstack Subscription" means the subscription for the Chainstack Service specified on the Chainstack Website. "Chainstack Website" means chainstack.com. "Third Party" means any individual or legal entity, other than the party to this Agreement. "Your Website" or "Affiliate Website" means any website that you state during the signup to Chainstack Affiliate Program, which is owned or operated by you. AFFILIATE RIGHTS We grant you, subject to the limitations set forth below, a limited, non-exclusive, non-assignable, non-sublicensable, non-transferable, revocable right to: (i) demonstrate and promote the Chainstack Service to your prospects and customers, and (ii) to provide End Users access to use the Chainstack Service, in accordance with this Agreement and Chainstack terms and conditions, specified on the Chainstack Website, provided that End Users agreed to Chainstack terms and conditions, specified on the Chainstack Website. You may place banners or Reference Links within your newsletters, on Your Website, or within another web-related content. You can reach us by sending an email to affiliates@chainstack.com. AFFILIATE OBLIGATIONS You must provide yourtruthsful credentials including a valid email address and the payment instructions in order to complete the signup process on the Affiliate Program Website. You are solely responsible for all the information you provide in this Agreement and on Your Website. You will be solely responsible for the development, operation, and maintenance of Your Website and for all materials that appear on Your Website. You should ensure that materials posted on Your Website do not violate or infringe the rights of any Third Party (including, for example, copyrights, trademarks, privacy, or other personal or proprietary rights). You will be solely responsible for the accuracy, truthfulness, and appropriateness of materials posted on Your Website. We do not endorse or accept any responsibility for any links that lead from Your Website to any other website apart from the Chainstack Website and for any content that can be found by following these links to Third-Party websites. Affiliate warrants and guarantees on behalf of itself and its affiliates, subsidiaries, agents and subcontractors: (i) that all personal data, contained in the End User (if any) or any other data or material, provided to Chainstack according to this Agreement, were collected in accordance with all applicable laws, including but not limited to, applicable data protection laws; (ii) that the Affiliate is fully allowed to transfer personal data to Chainstack and that the Affiliate received all necessary permissions so that Chainstack could store and process such personal data, use it in marketing purposes and for offering its services. PROHIBITED USES You may not use the Chainstack Affiliate Program for any illegal or unauthorized purpose. While using the Chainstack Service and/or participating in the Chainstack Affiliate Program, you must not violate any laws in your area/state/country. You cannot promote Chainstack on any gambling websites, websites with adult/hate/violent/defamatory content or any other content that is considered offensive or inappropriate, and any websites that violate third-party rights and/or violate any applicable laws. Chainstack may or may not review all content on Your Website(s) or used by you in your promotional methods. Chainstack may require and you agree to provide us the information regarding traffic sources, promotional channels, and your promotional methods with regard to Chainstack Service. If your sources, channels, or methods with regard to Chainstack Service would be considered inappropriate or inconsistent with the terms of this Agreement, at Chainstack sole discretion, your agreement could be suspended, your use privileges could be revoked, and Commissions could be cancelled. You cannot use and/or mention in any way: (i) the Chainstack brand names as a keyword in your advertising campaigns across any search engines, including any misspellings in the brand name; (ii) the Chainstack brand names in the domain name of Your Website, including any misspellings of the brand name; (iii) brand names, trademarks, of other companies as a keyword in your advertising campaigns across any search engines, including any misspellings in the brand name, trademark. You may not modify the trademarks, banners, the content, or any of the images provided to you in any way, without our prior written consent. Fraud is a serious offense and will be treated as such. Fraud is defined as any action that intentionally attempts to create sales, leads, or click-throughs using robots, frames, iframes, scripts, or manually "refreshing" of pages, for the sole purpose of creating Commissions. Any attempted fraud or fraud or any harmful action will result in account cancelation and voided commissions. Affiliate must provide all the documents requested by us within 30 (thirty) days in case we notice any potentially fraudulent activities associated with Your Account or coming through your Reference Links. Otherwise, Your Account will be blocked, and the Commissions will be cancelled. You cannot spam. We will terminate Your Account on the first offense of spamming. Do not send emails to lists or groups that you do not have permission to send them to. We have the right to terminate this agreement on the first offense referring to this section. You will not receive Commissions for self-referrals and for Affiliates, who violate our Chainstack Affiliate Terms. You are also not allowed to refer the company you work for and receive Commissions for that. You cannot demonstrate and promote the services provided by the direct competitors of Chainstack. COMMISSION PAYMENT To be eligible to earn a Commission, the End User must purchase Chainstack Services and/or Subscription within the stated Cookie life period of coming to Chainstack Website through the Reference Link from Your Website, email, or other communications. If a sale occurs after Cookie life period expires and the End User has not returned through the Reference Link and purchased the Chainstack Services and/or Subscription, then no Commission shall occur. For avoidance of doubt, Commissions shall be paid only for purchases of brand-new referrals, that occur after the End User clicked on your specific reference Link(s), directly from the Chainstack Website. In other words, to be eligible for a Commission, the End User you referred shall be a new user for Chainstack, shall use your Reference Link to register and subsequently purchase an account and shall purchase Chainstack Services and/or Subscription directly from Chainstack Website. In case of purchase by the End User as described herein of any custom or discounted accounts, Affiliate receives a Comission as per terms set by the the Offering Page. We also draw your attention to the fact that the money credited to Your Account does not accrue interest. Commissions are only earned on paid accounts on the Chainstack Website. If the End User cancels or does not pay for Chainstack Subscription, asks for a refund, or uses limited free registration, no Commission will accrue. Commissions earned through fraudulent, illegal, or overly aggressive, questionable sales or marketing methods will be voided. Fraudulent activities will also result in immediate Agreement cancelation. All statistics are collected and calculated by Chainstack and will be the only valid statistics used for determining Commission. From time-to-time Chainstack may change Chainstack Subscription prices, therefore these changes may affect both the Commission you will earn and the truthfulness of the information you will provide. We cannot guarantee the availability of Chainstack Subscriptions at the prices that you list on Your Website if they are outdated. RECURRING COMMISSIONS AND COOKIE DURATION Unless otherwise stated herein, when an End User that uses your reference link, purchases a valid and qualifying Services and/or Subscription with Chainstack, you will receive a Commission set in the Offering Page, only for the first 12 months, as long as the End User maintains the Chainstack paid Services and/or Subscription on the Chainstack Website or until terminated by either party in accordance with these Chainstack Affiliate Terms, provided that you remain eligible to receive a Commission pursuant to Chainstack Affiliate Terms. If at any time the End User account is cancelled, suspended, or refunded, you will become ineligible to receive Commission on any future fees collected from that End User. TERMINATION AND MODIFICATIONS This Agreement starts on date of Acknowledgment Form Signature and continues until terminated by either party in accordance with these Chainstack Affiliate Terms. Either party may immediately terminate this Agreement at any time in its sole discretion with written notice to the other party. Notwithstanding the above, Chainstack reserves the right to terminate any User account for abusive or fraudulent activity, for failure to comply with this Agreement, or for any other reason in its sole discretion. Termination of this Agreement will result in the deactivation or deletion of Your Account, and the forfeiture and relinquishment of all potential or to-be-paid Commissions in Your Account if they were earned through fraudulent, illegal, or overly aggressive, questionable sales or marketing methods. Upon termination of this Agreement, all rights of the Affiliate specified in this Agreement shall terminate immediately. Upon any termination of this Agreement for any reason, all provisions regarding indemnification, warranty, liability and limits thereon, and confidentiality and protection of proprietary rights and trade secrets, and any provisions which expressly or by their nature are required to survive such termination in order to achieve their purpose shall so survive until it shall no longer be necessary for them to survive in order to achieve their purpose. Chainstack may modify these Affiliate Terms at any time, solely at its own discretion with prospective effect. If Chainstack modifies these Affiliate Terms it will publish such modifications on the company’s website. The Affliate at any time can access the copy of current versions of Affiliate Terms on the Chainstack website. If the Affiliate does not wish to accept such modifications, then the Affiliate may terminate this Agreement, subject to the terms of this Section 7. OWNERSHIP AND INTELLECTUAL PROPERTY; USE OF TRADEMARKS Affiliate acknowledges and agrees that all rights, title, and interest to, any and all intellectual property rights of all types or nature whatsoever, including, without limitation, patent, copyright, trademark, database rights as well as moral rights, know-how, and trade secrets (and any licenses in connection with any of the same), whether or not registered or capable of registration, and whether subsisting in any specific country or countries or any other part of the world, in Chainstack platform (technology, hardware, software, etc.), any code or software (SDK, API, etc.) which may be provided to Affiliate or End User under this Agreement and any work products created and/or delivered herein and related documentation are and will remain solely and exclusively our property and/or the property of Chainstack, Chainstack licensors or Chainstack affiliates. Affiliate's right to use Chainstack Website, participate in Chainstack Affiliate Program, and any part thereof is strictly limited to the provisions of this Agreement, and we reserve all rights not expressly granted herein. The Chainstack name and other marks, graphics, icons, names, and logos used or displayed on or through the Chainstack Website are marks ("Marks") of us and our affiliates and subsidiaries or otherwise are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by us and may be subject to such third parties' terms and conditions. Affiliates and End Users may not use any metatags or any other "hidden text" utilizing any of the aforementioned marks without our and the respective owner's prior written permission. Affiliate will accordingly change or remove such display of materials immediately upon request by us or the respective Mark owners or licensors. Affiliate acknowledges and agrees that Affiliate shall not contest the ownership of the Marks on Chainstack Website for any reason. Affiliate's use or display of Marks will terminate effective upon the termination of this Agreement, or upon notification by us or the respective owner or licensor to discontinue such use or display. Affiliate hereby grants us a worldwide, non-exclusive, unlimited, and royalty-free license to use Affiliate's brands, names, logos, trademarks, trade names, and service marks as used by Affiliate for informational and advertising purposes only. Chainstack hereby grants the Affiliate a worldwide, non-exclusive, unlimited, and royalty-free license to use Chainstack’s brands, names, logos, trademarks, trade names, and service marks as used by Chainstack for informational and advertising purposes only. Affiliates are under no obligation to give Chainstack any ideas, suggestions, comments, or other feedback related to the Chainstack Website, Chainstack Affiliate Program, or the business or operations of Chainstack. If any Affiliate shares ideas, suggestions, comments, or other feedback with Chainstack, Chainstack will own such idea, suggestion, comment, or feedback. Affiliate hereby assigns all of Affiliate's right, title, and interest in such idea, suggestion, comment, or feedback to Chainstack and agrees that Chainstack will be free to use and implement same, without restriction or obligation of any kind, without, however, any obligation to do so. INDEMNITY You agree to defend, indemnify and hold harmless Chainstack and its officers, directors, employees, and agents, from and against any and all claims, damages, obligations, losses, liabilities, costs or debt, and expenses (including but not limited to attorney's fees) arising from: (a) your use of and access to Affiliate Program Website and participation in Chainstack Affiliate Program; (b) your violation of any term of this Agreement or applicable law; or (c) your violation of any Third Party right, including without limitation any copyright, property, or privacy right. This defense and indemnification obligation will survive the termination of this Agreement and your use of the Chainstack Website and participation in the Chainstack Affiliate Program. AUTHORITY Each party represents and warrants to the other party as to itself that the person executing this Agreement is authorized to do so on such party's behalf. If you are an individual, you represent and warrant that you were at least 18 years of age on the effective date of this agreement. If you are under 18, please do not attempt to participate in Chainstack Affiliate Program or send any information about yourself to us, including your name, address, telephone number, or email address. If we learn that we have collected personal information from anyone under age 18 without verification of parental consent, we will delete that information as quickly as possible. NON-INFRINGEMENT WARRANTIES You represent and warrant that: (i) you have all appropriate authority to operate, and to post any and all content on Your Website(s); (ii) you have all appropriate rights to promote with any promotional method you may choose to use; (iii) Your Website(s) and your promotional methods do not and will not infringe a Third Party's or Chainstack's proprietary rights; and (iv) you shall remain solely responsible for any and all Your Website(s) and all of your promotional methods and/or campaigns and any consequences resulting therefrom. DISCLAIMER OF WARRANTIES Except where prohibited by law, Chainstack Affiliate Program is provided "as-is" and "as available" and we expressly disclaim any warranties and conditions of any kind, whether express or implied, including the warranties or conditions of merchantability, fitness for a particular purpose, title, quiet enjoyment, accuracy, or non-infringement. We make no warranty that the Chainstack Affiliate Program or the Chainstack Website (a) will meet your requirements and/or expectations; (b) will be available on an uninterrupted, timely, secure, or error-free basis; or (c) will be accurate, reliable, free of viruses or other harmful code, complete, legal, or safe. We further make no warranties or representations regarding the accuracy or completeness of the content on any sites linked to on the Chainstack Website. LIMITATION OF LIABILITIES In no event shall Chainstack, its officers, directors, employees, or agents, be liable to you or to any Third Party for any direct, indirect, incidental, special, punitive, or consequential damages whatsoever arising from or related to either this Agreement, or use of Chainstack Website or participation in Chainstack Affiliate Program. Our liability to you for any damages arising from or related to this Agreement, will at all times be limited to $50 (fifty USD). The existence of more than one claim will not enlarge this limit. The foregoing limitation of liability shall apply to the fullest extent permitted by law in the applicable jurisdiction. The Affiliate accepts that the operation of the Chainstack Affiliate Program, Reference Links, or Chainstack Website may not be completely free of interruption, errors, or omissions and Chainstack is not liable for the consequences of any interruptions or errors in the performance or content of the Chainstack Website or Reference Links. Chainstack does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by the Third Party through Chainstack Website, hyperlinked website or Reference Links or featured in any banner or other advertising, and Chainstack will not be a party to or in any way be responsible for monitoring any transaction between you and Third Party providers of products or services. We make no representations that Chainstack Affiliate Program or Chainstack Website are appropriate or available for use in all locations. Those who access or use Chainstack Website or participate in Chainstack Affiliate Program from jurisdictions prohibiting such use, do so at their own volition and are responsible for compliance with local law. We reserve the right to use Third-Party service providers in the provisions of all or part of the Agreement including, but not limited to, hosting providers, payment processing services, information and communication services, analytics services, internet advertising platforms, advertising service providers, and platforms. Where any of the aforementioned services are provided by third parties, the Affiliate may be subject to such Third Party's terms and conditions. We accept no responsibility for services provided by any Third Party. MISCELLANEOUS Assignment. This Agreement, any part thereof or any rights or obligations under it may not be novated, assigned, outsourced or transferred by you without our advance written consent, but may be assigned by us without restriction or limitations. Any assignment or transfer in violation of the aforementioned provisions shall be deemed null and void. Force Majeure. We shall not be liable for failing or delaying performance of our obligations resulting from any condition beyond our reasonable control, including but not limited to, use of third parties' equipment or services, communications failure, governmental action, war, acts of terrorism, earthquake, fire, flood or other acts of God, labour conditions, power failures, and Internet disturbances. Headings and References. Headings of Sections are for the convenience of reference only. Words indicated in quotes and capitalized signify an abbreviation or defined term for indicated words or terms, including those definitions contained in the opening paragraph. Choice of Law. This Agreement and all matters arising therefrom and any dispute arising between the parties in connection with this Agreement shall be governed and construed in accordance with the laws of the Republic of Singapore as applicable, shall have exclusive jurisdiction in any legal proceedings resulting or connected with this Agreement, and the Affiliate hereby irrevocably submits to such exclusive jurisdiction. However, this shall not prevent us from bringing any action in the court of any other jurisdiction for injunctive or similar relief. Tax Status and Obligations. Chainstack is not obligated to and shall not provide you with tax and/or legal advice. Chainstack undertakes no duty to investigate or research your tax status and/or obligations, and such research and investigation are solely your responsibility. You are obligated to independently assess and comply with all relevant tax and legal requirements, and you are solely responsible for your own sales tax collection, reporting, and any other obligation arising from Commission income. If Chainstack provides you with information, that information shall not be deemed tax or legal advice, and Chainstack shall not be responsible for the accuracy of such information. Entire Agreement. This Agreement shall constitute the entire agreement between you and Chainstack concerning your use of the Affiliate Program Website and participation in the Chainstack Affiliate Program. However, terms and conditions of some other Chainstack services and products may impose additional terms, which can be found in the terms and conditions for such services and products. Languages. This Agreement is in the English language, which prevails over any translations of it to other languages, made by us and provided to you for your convenience, as applicable. Chainstack Affiliate Program is designed in the English language and its translations into other languages may contain inaccuracies for which we shall not bear any responsibility; we suggest using the English version and resorting to versions in other languages only for references and at your own risk. You also agree to have all communications with us in English. No Waiver. No failure or delay by a party to exercise any right or remedy provided under this Agreement or by law shall constitute a waiver of that (or any other) right or remedy, nor preclude or restrict its further exercise. No single or partial exercise of such right or remedy shall preclude or restrict the further exercise of that (or any other) right or remedy; and will not be construed as a waiver of any subsequent breach or default under the same or any other provision of this Agreement. Severability. All the provisions of this Agreement are distinct and severable. If any provision of this Agreement (or part of any provision) is found by any court or other authority of competent jurisdiction to be invalid, unenforceable, or illegal, this shall not impair the operation of this Agreement or affect the other provisions which are valid. Marketing. You agree that Chainstack may identify you as a Chainstack Affiliate and may use your name and/or logo solely for such purpose in its marketing materials. Electronic Notices. You agree to receive communications from us in an electronic form. Electronic notices will be delivered via Telegram or to the email address you have provided, and it may be subsequently changed by you by written notice to us. All communications in electronic format will be considered to be "in writing" and to have been received on the day that we send them. We reserve the right, but assume no obligation, to provide communications in paper format. All notices, requests, claims, demands, and other communications regarding these Chainstack Affiliate Terms are welcomed and should be addressed to affiliates@chainstack.com. #### Chainstack Console Demo URL: https://chainstack.com/demo/ #### Chainstack Enterprise URL: https://chainstack.com/enterprise/ #### Chainstack faucets - Get Free Testnet Tokens URL: https://chainstack.com/faucets/ #### Chainstack MCP URL: https://chainstack.com/mcp/ #### Chainstack Referral Program URL: https://chainstack.com/referral/ #### Chainstack Self-Hosted Terms of Service Chainstack Self-Hosted Terms of Service Important Notice READ THESE TERMS OF SERVICE ("TERMS") CAREFULLY BEFORE INSTALLING, DEPLOYING, OR USING CHAINSTACK SELF-HOSTED. BY INSTALLING, DEPLOYING, OR USING THE SOFTWARE, YOU ACKNOWLEDGE THAT YOU HAVE READ THESE TERMS, UNDERSTAND THEM, AND AGREE TO BE BOUND BY THEM. IF YOU ARE ACCEPTING THESE TERMS ON BEHALF OF A COMPANY, ORGANIZATION, OR OTHER LEGAL ENTITY ("ENTITY"), YOU REPRESENT AND WARRANT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY TO THESE TERMS. REFERENCES TO "YOU" AND "USER" HEREIN REFER TO BOTH YOU AS AN INDIVIDUAL AND THE ENTITY ON WHOSE BEHALF YOU ARE ACCEPTING THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS, DO NOT INSTALL, DEPLOY, OR USE THE SOFTWARE. THE SOFTWARE IS LICENSED TO YOU, NOT SOLD. 1. Relationship with EULA and General Terms These Terms govern your use of the Software. The Software may be used: (a) without a License Key, in which case only these Terms apply; or (b) with a License Key, in which case your use of paid features is additionally governed by a separate End-User License Agreement ("EULA"). In the absence of a valid EULA, no paid features may be accessed or used. The general Chainstack Terms of Service available at https://chainstack.com/tos/ apply only to the extent that they are not inconsistent with these Terms. In the event of conflict: (a) these Terms shall prevail with respect to the Software; (b) the EULA shall prevail with respect to paid features and commercial terms; (c) the general Terms of Service shall apply only where not addressed in these Terms. 2. Definitions "Affiliate" means any entity controlling, controlled by, or under common control with a party, where "control" means ownership of more than fifty percent (50%) of the voting securities of such entity. "Chainstack" means Chainstack Pte. Ltd., a company incorporated in Singapore. "Customer Infrastructure" means the hardware, Kubernetes clusters, cloud environments, networks, and other infrastructure owned or operated by you on which the Software is deployed. "Documentation" means the user guides, installation instructions, release notes, and other technical documentation made available by Chainstack for the Software, as updated from time to time. "Installation" means a single deployed instance of the Software on a discrete Kubernetes cluster within your infrastructure. "License Key" means the unique digital credential issued by Chainstack that activates paid features of the Software and determines the capabilities available to the licensee. Use of the Software without a License Key is subject to these Terms; use with a License Key is additionally subject to the End-User License Agreement ("EULA"). "Node" means a blockchain node deployed and managed through the Software. "Snapshot Data" means blockchain state data obtained from third-party snapshot providers and made available through the Software to accelerate node deployment. "Software" means the Chainstack Self-Hosted application, including all components, tools, interfaces, and utilities distributed by Chainstack as part of the product, in machine-readable object code form only. "Supported Protocols" means the blockchain protocols for which the Software provides deployment and management capabilities, as described in the Documentation. "Telemetry Data" means anonymized technical and usage data collected by the Software, as described in Section 9. "Third-Party Components" means open-source software, blockchain clients, monitoring tools, and other third-party software components bundled with, embedded in, or required by the Software. 3. Scope 3.1. These Terms govern your use of the Software, regardless of whether you use the Software with or without a License Key, and regardless of whether you have a paid subscription. 3.2. If you purchase a License Key or subscribe to paid features of the Software, your use of those paid features is permitted only pursuant to a valid End-User License Agreement ("EULA"). In the absence of a valid EULA, no paid features may be accessed or used. 3.3. These Terms are supplementary to, and do not replace, the general Chainstack Terms of Service published at https://chainstack.com/tos/. Where a matter is not addressed in these Terms, the general Terms of Service shall apply. For clarity, the general Terms of Service primarily govern access to Chainstack-hosted services and accounts and do not modify these Terms except as expressly stated. In the event of conflict regarding the Software, these Terms shall prevail. 4. Right to Use 4.1. Grant Subject to the terms of these Terms, Chainstack grants you a limited, non-exclusive, non-transferable, non-sublicensable, revocable right to install and use the Software on your Customer Infrastructure for internal business purposes and not for the provision of services to third parties unless expressly permitted. 4.2. Use Without License Key You may install and use the Software without a License Key, subject to these Terms. When used without a License Key, the Software operates with the base feature set and limitations as described in the Documentation. No subscription fee is required for use without a License Key. 4.3. Use With License Key To access paid features, you must obtain a License Key and enter into a valid EULA. The EULA governs the license scope, feature entitlements, fees, and payment obligations associated with such use. 4.4. Authorized Users The Software may be used by your employees and contractors acting on your behalf, provided they are bound by terms no less restrictive than these Terms and use the Software solely for your internal business purposes. 5. Use Restrictions 5.1. Prohibited Conduct You shall not, and shall not permit any third party to: (a) use the Software for any unlawful, harmful, or abusive purpose, including but not limited to malware distribution, intellectual property infringement, or fraudulent activity; (b) reverse-engineer, decompile, disassemble, or otherwise attempt to derive the source code of the Software, except to the extent expressly permitted by applicable law that cannot be waived by contract; (c) modify, adapt, translate, or create derivative works based on the Software; (d) copy, redistribute, sublicense, rent, lease, or lend the Software or any portion thereof; (e) remove, alter, or obscure any proprietary notices, labels, or marks on the Software; (f) circumvent, disable, or interfere with any technical protection measures in the Software, including but not limited to License Key validation mechanisms, usage quotas, or feature restrictions; (g) use the Software to provide hosted or managed services to third parties, unless expressly authorized by Chainstack in a separate written agreement; (h) interfere with the normal operation, security, or integrity of the Software; or (i) benchmark, test, or evaluate the Software for the purpose of publishing comparative analyses unless such benchmarking is fair, accurate, reproducible, and does not misrepresent the Software. 6. Customer Infrastructure 6.1. Your Responsibility You are solely responsible for providing, maintaining, and securing the Customer Infrastructure on which the Software is deployed. This includes, without limitation, hardware, operating systems, Kubernetes clusters, networking, storage, internet connectivity, and cloud environments. 6.2. System Requirements The Software must be deployed on infrastructure that meets the minimum requirements specified in the Documentation. Chainstack makes no warranties regarding the performance, stability, or availability of the Software when deployed on infrastructure that does not meet these requirements. 6.3. Access and Security You are responsible for safeguarding all access credentials, administrative accounts, and security configurations associated with the Software and the Customer Infrastructure. 6.4. Network Connectivity Certain features of the Software require outbound network connectivity, including Telemetry Data transmission (Section 9), retrieval of Snapshot Data, software update checks, and, where applicable, License Key validation. You are responsible for ensuring adequate network connectivity as specified in the Documentation. 6.5. Configuration Responsibility You are solely responsible for all configurations, deployment parameters, and operational settings of the Software. Chainstack shall not be responsible for any issues arising from misconfiguration or improper use of the Software. 7. Third-Party Components and Snapshot Data 7.1. Third-Party Components The Software incorporates Third-Party Components, including open-source blockchain clients, monitoring tools, and other software. A list of Third-Party Components and their applicable licenses is provided in the NOTICES file distributed with the Software and available in the Documentation. 7.2. Third-Party Licenses Your use of Third-Party Components is subject to the applicable third-party license terms. In the event of conflict between these Terms and a third-party license with respect to a specific Third-Party Component, the third-party license shall prevail for that component. 7.3. Snapshot Data The Software may facilitate the retrieval of Snapshot Data from third-party providers to accelerate blockchain node deployment. Chainstack does not own, control, or guarantee the accuracy, completeness, integrity, or availability of Snapshot Data. You acknowledge that: (a) Snapshot Data is provided by independent third parties and is not warranted by Chainstack; (b) Chainstack is not liable for any losses, damages, or inaccuracies resulting from the use of Snapshot Data; and (c) availability of Snapshot Data for specific protocols or networks may change without notice. Chainstack does not verify, audit, or validate Snapshot Data for accuracy, security, or integrity and disclaims any responsibility for any malicious code, corrupted data, security vulnerabilities, or other harmful content contained therein. 8. Updates and Version Support 8.1. Availability Chainstack may, at its discretion, make updates, patches, and new releases of the Software available. The availability, frequency, and scope of updates may vary based on whether you hold a License Key and the terms of any applicable EULA. 8.2. Version Support Chainstack's version support policy is described in the Documentation. You acknowledge that Chainstack may limit support to a defined number of major versions and that running unsupported versions of the Software may result in reduced functionality, unresolved defects, and security vulnerabilities for which Chainstack bears no responsibility. 8.3. Update Responsibility You are responsible for applying updates and patches to the Software on your Customer Infrastructure. Chainstack is not liable for any issues arising from your failure to apply available updates within a reasonable timeframe, or from running unsupported versions of the Software. 8.4. Backward Compatibility Updates may modify, replace, or remove existing features and may not be backward compatible. 9. Intellectual Property 9.1. Chainstack Ownership The Software and all related technology, documentation, trademarks, and updates are and shall remain the exclusive property of Chainstack and its licensors. These Terms do not convey to you any rights of ownership in or to the Software, and are not a sale of any rights in the Software. 9.2. Feedback If you provide Chainstack with suggestions, ideas, enhancement requests, or other feedback relating to the Software ("Feedback"), you hereby grant Chainstack a non-exclusive, perpetual, irrevocable, royalty-free, worldwide license to use, reproduce, modify, and incorporate such Feedback into the Software or other Chainstack products without restriction or obligation to you. 9.3. Your Data You retain all ownership rights in the data, configurations, logs, and blockchain data you generate, store, or process through the Software ("Customer Data"). Chainstack claims no ownership of Customer Data. Customer Data stored on your Customer Infrastructure remains your property at all times, including after termination of these Terms. 10. Telemetry Data 10.1. Collection The Software collects Telemetry Data, which may include system performance metrics, feature usage statistics, error reports, installation configuration data, and protocol/node deployment information. Telemetry Data is anonymized and is not intended to include personally identifiable information, although certain infrastructure metadata may be processed. 10.2. Purpose Chainstack uses Telemetry Data to maintain, improve, and develop the Software, monitor aggregate usage patterns, identify and resolve defects, and plan product development. 10.3. Separation from License Validation Telemetry Data collection is technically and functionally separate from any License Key validation mechanism. Where applicable, License Key validation data is used solely to verify license compliance; Telemetry Data is used solely for product improvement purposes. 10.4. Data Processing To the extent Telemetry Data constitutes personal data under applicable law, Chainstack processes such data as a data controller for the purposes described in Chainstack's Privacy Policy. 10.5. Required Collection Telemetry Data collection may be required for operation of certain features of the Software. 11. Warranties and Disclaimers 11.1. Limited Warranty Chainstack warrants that the Software will perform substantially in accordance with the Documentation when deployed on Customer Infrastructure that meets the requirements specified in the Documentation. 11.2. Disclaimer Except as expressly set forth in Section 10.1, the Software is provided "as is" and "as available." Chainstack disclaims all other warranties, whether express, implied, statutory, or otherwise, including, without limitation, warranties of merchantability, fitness for a particular purpose, title, and non-infringement. 11.3. No Uptime Guarantee The Software is installed and operated on your Customer Infrastructure. Chainstack does not warrant or guarantee any level of uptime, availability, or performance of the Software. The availability and performance of the Software depend on your Customer Infrastructure, network connectivity, and operational practices, which are outside Chainstack’s control. 11.4. Third-Party Components and Snapshot Data Chainstack makes no warranties with respect to Third-Party Components or Snapshot Data. Such components and data are provided subject to their respective third-party terms and without warranty of any kind from Chainstack. 11.5. Unsupported Configurations Chainstack makes no warranties regarding the performance, security, or stability of the Software when deployed on infrastructure that does not meet the requirements in the Documentation, when running unsupported versions of the Software, or when used in configurations not described in the Documentation. 11.6. No Support Obligation Chainstack has no obligation to provide support, maintenance, updates, or services unless agreed separately in a written agreement. 11.7. No Infringement Guarantee Chainstack does not warrant that the Software, when used with Third-Party Components, blockchain protocols, or external systems, will be free from third-party intellectual property claims. 12. Limitation of Liability 12.1. Exclusion of Damages To the maximum extent permitted by applicable law, in no event shall Chainstack be liable for any indirect, incidental, special, consequential, or punitive damages, including, without limitation, loss of profits, loss of data, loss of business, business interruption, or cost of procurement of substitute services, arising out of or in connection with these Terms or the use or inability to use the Software, regardless of the cause of action or theory of liability, even if Chainstack has been advised of the possibility of such damages. 12.2. Liability Cap To the maximum extent permitted by applicable law, Chainstack’s total aggregate liability under these Terms shall not exceed one hundred Singapore dollars (SGD 100). 12.3. Blockchain Disclaimer You acknowledge that the Software facilitates the deployment and management of blockchain infrastructure and that blockchain networks are inherently decentralized and subject to risks including, without limitation, protocol-level bugs, consensus failures, network forks, and changes in third-party client software. Chainstack is not liable for any losses arising from the operation or behavior of blockchain networks, protocols, or third-party clients deployed through the Software. 12.4. Exceptions Nothing in these Terms shall exclude or limit liability to the extent such liability cannot be excluded or limited under applicable law, including liability for death or personal injury caused by negligence, fraud, or willful misconduct. 13. Term and Termination 13.1. Term These Terms are effective from the date you first install, deploy, or use the Software and remain in effect until terminated. 13.2. Termination by You You may terminate these Terms at any time by uninstalling the Software and destroying all copies in your possession or control. 13.3. Termination by Chainstack Chainstack may terminate these Terms immediately upon written notice if you breach any material term of these Terms and fail to cure such breach within thirty (30) days of receiving written notice of the breach. 13.4. Effect of Termination Upon termination of these Terms: (a) all rights granted to you under these Terms shall immediately cease; (b) you shall promptly uninstall the Software and destroy all copies in your possession or control; and (c) Sections 1, 6.3, 8, 9, 10, 11, 12.4, 12.5, 13, and 14 shall survive termination. 13.5. Customer Data Customer Data stored on your Customer Infrastructure remains your property after termination of these Terms. Chainstack has no obligation to maintain, migrate, or provide access to Customer Data after termination. 14. General Provisions 14.1. Governing Law These Terms shall be governed by and construed in accordance with the laws of Singapore, without regard to its conflict of laws principles. Any disputes arising out of or in connection with these Terms shall be submitted to the exclusive jurisdiction of the courts of Singapore. 14.2. Entire Agreement These Terms, together with any applicable EULA and the documents referenced herein, constitute the entire agreement between you and Chainstack with respect to the Software and supersede all prior or contemporaneous communications and proposals, whether oral or written, with respect to its subject matter. 14.3. Severability If any provision of these Terms is held to be unenforceable or invalid, such provision shall be modified to the minimum extent necessary to make it enforceable, and the remaining provisions shall continue in full force and effect. 14.4. No Waiver The failure of Chainstack to enforce any right or provision of these Terms shall not constitute a waiver of such right or provision. 14.5. Assignment You may not assign or transfer these Terms, or any rights or obligations hereunder, without Chainstack’s prior written consent. Chainstack may assign these Terms without restriction. Any attempted assignment in violation of this section shall be void. 14.6. Notices Notices under these Terms shall be in writing. Notices to Chainstack shall be sent to legal@chainstack.com. 14.7. Export Compliance You shall comply with all applicable export control and sanctions laws and regulations in connection with your use of the Software. You represent that you are not located in, organized under the laws of, or a resident of any country or territory subject to comprehensive trade sanctions, and that you are not listed on any applicable restricted party list. 15. Indemnification You agree to indemnify, defend, and hold harmless Chainstack, its affiliates, officers, directors, employees, and agents from and against any and all claims, demands, actions, proceedings, damages, losses, liabilities, costs, and expenses (including reasonable attorneys’ fees) arising out of or related to: (a) your use of the Software in violation of these Terms; (b) your violation of any applicable law, regulation, or third-party rights; (c) your use, deployment, or operation of the Software in connection with any services provided to third parties; or (d) any Customer Data, configurations, or materials processed, stored, or transmitted using the Software. Chainstack reserves the right, at its own expense, to assume the exclusive defense and control of any matter subject to indemnification by you, in which case you agree to cooperate with Chainstack in the defense of such claim. You shall not settle any claim that imposes any liability or obligation on Chainstack without Chainstack’s prior written consent, such consent not to be unreasonably withheld. #### Chainstack Subgraphs URL: https://chainstack.com/subgraphs/ #### Community projects Chainstack Labs #### Contact us URL: https://chainstack.com/contact/ #### Contact us for custom plan Get in touch Let’s talk about the best way for you to access and deploy Chainstack. #### Cookies Policy Cookie Policy Last updated: June 2025 Chainstack Pte. Ltd. 8 Temasek Boulevard #30 Suntec Tower Three Singapore 038988 1. Purpose This Cookies Policy explains how Chainstack Pte. Ltd. ("Chainstack", "we", "us", or "our") uses cookies and similar technologies on our website, https://chainstack.com ("Website"). This policy should be read alongside our Privacy Policy, which explains how we use personal information. 2. What are cookies Cookies are small text files placed on your device (computer, tablet, smartphone) when you visit a website. They are widely used to make websites work, enhance the user experience, and provide information to the website owners. Cookies set by the website owner are called “first-party cookies”. Third-party cookies enable third-party features or functionality to be provided on or through the website (e.g., advertising, interactive content, and analytics). 3. Why do we use cookies We use first- and third-party cookies for several reasons. Some cookies are required for technical reasons and are "essential" or "strictly necessary" cookies. Others help track and target user interests. Third parties also serve cookies for advertising, analytics, and more. 4. Types of cookies that we use Strictly Necessary/Essential Cookies Type: Session Cookies Administered by: Us Purpose: Enable core functionality such as security and access. Without them, services can't be provided. Functionality Cookies Type: Persistent Cookies Administered by: Us Purpose: Remember choices like login or language to personalize your experience. 5. Can I control cookies You can accept or reject cookies using the Cookie Consent Manager found in the banner or on the Website. Essential cookies cannot be disabled. You can also use browser settings to manage cookies. 6. Choices regarding cookies You may delete or refuse cookies using your browser: Chrome Internet Explorer Firefox Safari Other browsers: visit official help pages Ad networks also provide opt-outs: Digital Advertising Alliance DAA of Canada European Interactive DAA 7. Tracking technologies We may use web beacons or similar tools to monitor page visits, campaign effectiveness, and site performance. These often depend on cookies, so disabling cookies may impact their functionality. 8. Use of flash cookies or Local Shared Objects Flash Cookies (LSOs) may be used for site functionality. You can manage them through Adobe's storage settings panels. Disabling LSOs may affect features that rely on them. 9. Targeted advertising Third parties may serve ads based on your browsing. These cookies help display relevant ads and measure their performance. We and they do not collect identifiable personal information unless you provide it. 10. Cookie policy update We may update this Cookie Policy to reflect changes in our use of cookies or for legal reasons. Please check back regularly. 11. Contact us If you have questions about our use of cookies, contact: support@chainstack.com #### Core Protocols Core #### Corn Protocols Corn #### Cronos A public permissionless L1 EVM-compatible blockchain network built on Cosmos SDK. #### Customer stories URL: https://chainstack.com/customers/ #### Dedicated Node URL: https://chainstack.com/dedicated-nodes/ #### Dogechain Protocols Dogechain #### Dogecoin Protocols Dogecoin #### Download Eth2 Clients Development Report 2021 URL: https://chainstack.com/eth2-clients-development-report-2021/ #### Ethereum Protocols Ethereum #### Etherlink Protocols Etherlink #### Fantom A public permissionless blockchain platform with smart contract capabilities. #### Fraxtal Protocols Fraxtal #### Global Node URL: https://chainstack.com/global-nodes/ #### Global Nodes Interactive Demo URL: https://chainstack.com/global-nodes-standard-demo/ #### Gnosis Chain URL: https://chainstack.com/protocols/gnosis-chain/ #### Harmony A public permissionless blockchain platform with smart contract capabilities and shard chains. #### Hashkey Protocols Hashkey #### Hyperliquid Protocols Hyperliquid #### Ink Protocols Ink #### Kaia Protocols Kaia #### Katana Protocols Katana #### Kroma Protocols Kroma #### Learning URL: https://chainstack.com/learn/ #### Lens Protocols Lens #### Linea Protocols Linea #### Managed blockchain infrastructure URL: https://chainstack.com/solution/ #### Mantle Protocols Mantle #### MegaETH Protocols MegaETH #### Merlin Protocols Merlin #### Metis Protocols Metis #### Mind Protocols Mind #### Mint Protocols Mint #### Monad Protocols Monad #### Moonbeam Protocols Moonbeam #### MultiChain Protocols MultiChain #### Newsletter Subscribe to our newsletter #### Oasis Sapphire A public permissionless non-EVM Layer 1 network secured by proof-of-stake. #### opBNB Protocols opBNB #### Optimism URL: https://chainstack.com/protocols/optimism/ #### Partners URL: https://chainstack.com/partners/ #### Plasma Protocols Plasma #### Plume Protocols Plume #### Polkadot Protocols Polkadot #### Polygon PoS URL: https://chainstack.com/protocols/polygon/ #### Polygon zkEVM Polygon zkEVM is a decentralized Layer 2 scalability solution for Ethereum. It utilizes cryptographic zero-knowledge proofs to provide validity and fast finality to off-chain computations.   #### Press kit Download Chainstack’s brand assets and guidelines. #### Privacy notice PRIVACY NOTICE INCLUDING EU & UK Chainstack Pte. Ltd. (“Chainstack”) respects your privacy and will process any personal data only in accordance with applicable data protection laws. This Privacy Notice covers the information we collect about you when you use our website and our Services (as defined below) and how we process that personal data. The references to “you” or “your” in this Privacy Notice are to the individual who is visiting our website, is accessing, using or applying to use our Services (as defined below) either on your own account or on behalf of a business. This includes any other director and officer, shareholder, partner and beneficial owner of a Customer, as well as any user accessing or using the Services on behalf of a Customer. THE TYPES OF PERSONAL DATA WE MAY COLLECT We may collect data about you that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with you (“Personal Data“). Personal Data can be provided voluntarily by you or they can be collected automatically. This Privacy Notice applies to the Personal Data we process as a “data controller”, meaning, as the party that determines what data is collected and why. When you use our Services and website, we may collect Personal Data which includes: Information provided voluntarily We may ask you to provide your contact details to access our Services, additional resources and documentation, to register an account with us, to subscribe to marketing communications from us, and/or to submit enquiries to us. The Personal Data that you are asked to provide, and the reasons why you are asked to provide it may include: Contact information, such as your name, postal address and email address  (each whether associated with you in your personal or professional capacity); Authentication data, such as user name, password, password hints and other similar information used to verify the identity of our Customers; Commercial information, such as information about Services you subscribe to and payment information you provide in connection with these transactions (including billing address and payment card data); Preferences, such as how you prefer to communicate with us, Services that you are interested in, or other preferences you communicate to us; and Other information you provide, such as information in emails or other communications that you send to us or otherwise contribute. We will only send you electronic marketing communications where we have your prior consent, unless an exception applies under applicable law (such as for existing customers where permitted) and in accordance with applicable electronic communications laws. You can opt out of marketing communications at any time by using the unsubscribe link in our emails or by contacting us. Information that we collect automaticallyWhen you visit our website and/or use our Services, we may collect certain information automatically from your device (e.g., information like your IP address, broad geographic location (i.e., country or city-level location) and other technical information) through the use of cookies or similar tracking technology. Where required by applicable law (including in the EEA and UK), we will obtain your prior consent before placing any cookies or similar technologies on your device, except for those that are strictly necessary for the operation of our Services. We may also collect information about how your device has interacted with our website, including the pages accessed and links clicked. In some countries, including countries in the European Economic Area, this information may be considered Personal Data under applicable data protection laws. You can manage your preferences regarding cookies and similar technologies through our Cookie Consent Manager. For more information, please see our Cookie Policy. The Personal Data we may obtain through cookies includes: Unique identifiers, such as IP address, browser type, operating system, the pages you view, the pages you view immediately before and after you access the websites, and the search terms you enter on the websites, Internet or other electronic network activity information; General location data; and Inferences drawn from the above categories. Where required by applicable law, such data is collected only after obtaining your consent, except where the use of cookies is strictly necessary for the provision of our Services. Personal Data Chainstack does not seek to collect Chainstack does not need special categories of Personal Data (also known as “sensitive personal information or data”), as defined by the GDPR and UK GDPR, to provide its Services. Chainstack avoids collecting sensitive Personal Data from you through the Services or otherwise. Unless Chainstack specifically requests it, please do not provide sensitive Personal Data to us. In the rare circumstances in which Chainstack does seek to collect sensitive Personal Data, we will do so in accordance with the applicable data protection laws and/or ask for your consent. LEGAL BASIS FOR PROCESSING Where required by applicable data protection laws (including GDPR and UK GDPR), we rely on appropriate legal bases for processing your Personal Data for each specific processing activity. In particular, where required by law, including for the use of cookies and electronic marketing communications, we rely on your consent. INTERNATIONAL DATA TRANSFERS Use of our Services sometimes involves cross-border transfers of Personal Data. For cross-border transfers of Personal Data to jurisdictions not guaranteeing an adequate level of data protection, Chainstack uses appropriate safeguards, such as Standard Contractual Clauses or equivalent mechanisms, to guarantee that your Personal Data is protected in accordance with this Privacy Notice and applicable data protection laws. MEASURES TO KEEP YOUR DATA SAFE We maintain reasonable and appropriate technical and organizational security measures to protect Personal Data from loss, misuse, unauthorized access, disclosure, alteration, or destruction in light of the risks inherent in processing this information. We regularly review our security policies and procedures to ensure our systems are secure and protected. CONFIDENTIALITY OF COMMUNICATIONS We respect the confidentiality of communications transmitted through our Services. We do not access, monitor, or use the content of communications except where necessary to provide, secure, or maintain our Services, or where required by applicable law. Access to such data is strictly limited and subject to appropriate technical and organizational safeguards. DATA RETENTION We retain Personal Data we collect from you as long as we have an ongoing legitimate business need to do so, including retaining certain technical and usage data for limited periods where necessary to ensure the security, integrity, and performance of our Services (e.g., to provide you with a Service you have requested or to comply with applicable legal, tax or accounting requirements). When we have no ongoing legitimate business need to process your Personal Data, we will either delete or anonymise it or, if this is not possible (e.g., because your Personal Data has been stored in backup archives), then we will securely store your Personal Data and isolate it from any further processing until deletion is possible. EU & UK  Within the EU and the UK, the data controller (i.e., the person who or entity that determines the purpose and means of processing) for the Personal Data collected pursuant to this Privacy Notice is Chainstack Pte. Ltd., 8 Temasek Boulevard #30-01/02 Suntec Tower 3 Singapore 038988. Under the GDPR, UK GDPR and the Swiss Data Protection Act you have the following rights in relation to your Personal Data: Right of access: You have the right to know if and what Personal Data we process about you and may request a copy of that Personal Data (along with certain other details). If you require additional copies, we may need to charge a reasonable fee. Right to rectification: You are entitled to have incorrect or incomplete Personal Data about you corrected or completed. If we have shared your Personal Data with others, we will tell them about the rectification where possible. If you ask us, where possible and lawful to do so, we will also tell you with whom we shared your Personal Data so that you can contact them directly. Right to erasure: You may ask us to delete your Personal Data. Under some circumstances we might not be able to delete your Personal Data (e.g., in case we are required to keep your Personal Data by law). If we have shared your Personal Data with others, we will inform them about the erasure where possible. If you ask us, where possible and lawful to do so, we will also inform you with whom we shared your Personal Data so that you can contact them directly. Right to restrict processing: You may ask us to restrict or ‘block’ the processing of your Personal Data in certain circumstances, such as where you contest the accuracy of that Personal Data or object to the processing of it. We will tell you before we lift any restriction on processing. If we have shared your Personal Data with others, we will inform them about the restriction where possible. If you ask us, where possible and lawful to do so, we will also tell you with whom we shared your Personal Data so that you can contact them directly. Right to object: You may ask us at any time to stop processing your Personal Data, and we will do so: if we are relying on a legitimate interest to process your Personal Data - unless we demonstrate compelling legitimate grounds for the processing; or if we are processing your Personal Data for direct marketing purposes, including electronic marketing communications, in which case you have an absolute right to object.  Please note that the limitation or deletion of your Personal Data may mean that we will be unable to provide you our Services. Right to data portability: You also have the right to receive your Personal Data in a machine-readable format and have the data transferred to another party responsible for data processing. Rights in relation to automated decision-making and profiling: You have the right to be free from decisions based solely on the automated processing of your Personal Data, including profiling, unless such profiling is necessary for providing the Services or their performance. Right to withdraw consent: If we rely on your consent to process your Personal Data, you have the right to withdraw that consent at any time by sending a notice to the email address: legal@chainstack.com  Right to lodge for a complaint: If you have a concern about our privacy practices, including the way we have handled your Personal Data, you can report it to the competent data protection data protection authorized authority. #### Privacy policy PRIVACY POLICY Last Updated: 24 March 2026 Your privacy is critically important to us at Chainstack, and we are committed to protecting your personal data that you provide us. Chainstack Pte Ltd is a company incorporated in Singapore, and having its registered office at 8 Temasek Boulevard, #30-01, Suntec Tower 3, Singapore 038988 (hereinafter, “we”, “us”, “our”). It is our Privacy Policy (hereinafter, “Privacy Policy”) to respect your privacy regarding any information you may provide us while operating our website (https://chainstack.com and any subdomain of chainstack.com) or services (hereinafter, “Website” and “Services”). We have adopted this Privacy Policy to explain what information we collect when you use our Website or Services, how we process this information, what rights you may have with regard to your personal data, and under what circumstances we may disclose the information to third parties. This Privacy Policy does not apply to third parties’ websites or services. This Privacy Policy, together with the Terms and Conditions posted on our Website, set forth the general rules and policies governing your use of our Website and Services. Depending on your activities when visiting our Website and using our Services, you may be required to agree to additional terms and conditions. WHAT DATA WE PROCESS AND WHY Depending on the situation, we process various data, which may include data that may be treated as personal data in accordance with the laws of certain territories and countries. In general, “personal data” means any information relating to an identified or identifiable natural person (“data subject”). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, and so on. Visiting Our Website When you browse our Website, we process your IP address, browser type, language preference, referring site, and the date and time of each visitor request. Where such processing involves the use of cookies or similar technologies, we will obtain your prior consent where required by applicable law (including in the EEA and UK), except where such technologies are strictly necessary. We use this information to make sure you have a flawless experience when you visit our Website, as well as to improve future user scenarios. From time to time, Chainstack may release this information in an aggregated and depersonalized form, e.g., by publishing a report on trends in the usage of our Website. However, Chainstack does not disclose your personal data without your permission. Creating An Account To Use Our Services We welcome you to join our Services and to launch your decentralized networks and applications. For you to benefit from our Services we need to process your company name, email address and password to set up your account. Using Our Services We process certain personal data to provide you with the core functionality of our Services. Specifically, when you are Using the Chainstack Console, we process your name, surname, email address (your account identifier), organization name, IP address, all HTTP headers (most importantly User-Agent), cookies (used in accordance with our Cookie Policy and subject to your consent where required by applicable law); Using the Chainstack Blockchain infrastructure, we process nodes’ token stored in Chainstack Vault, IP address and HTTP headers, request body, API token in Chainstack Vault. We also process your inputs that you provide to us when you use our Services. Please do not upload any personal data to the Services unnecessarily. We use anonymized information, statistics and metadata associated with or generated by your use of our Services to improve the quality of our Services and technologies used in them. We assure you that such information does not contain any data that you have provided to us. We may also process other data, which we describe in the Terms of Service of the respective Services. Please read them carefully. You can also email us if you have questions using the address below. Subscribing To Our Newsletters We are eager to share our news, latest industry trends, product updates, and exclusive promotions with you. To do so, we need to process your email address. If you are a registered user of Chainstack platform and have supplied your email address, Chainstack may occasionally email you to tell you about new features, solicit your feedback, or just keep you up to date with what’s going on with Chainstack and our products, where permitted by applicable law and, where required, based on your prior consent. You can opt out of marketing communications at any time by using the unsubscribe link included in such communications. We primarily use our blog to communicate this type of information, so we expect to keep this type of email to a minimum. Getting In Touch With Us We need to process your name and email address to be able to answer your questions. Additionally, you may provide us with your last name and your company name so that we can answer you more personally and closely. If you send us a request (for example via a support email or via one of our feedback mechanisms), we reserve the right to publish it in order to help us clarify or respond to your request or to help us support other users. WHERE WE PROCESS YOUR DATA Chainstack hosts the Chainstack Console in Singapore, while the Chainstack Blockchain infrastructure is globally decentralized. We strive to hire only reliable ISPs to make sure your data is secure. Chainstack is an international team of passionate professionals who can only access your data through their job duties on a need-to-know basis. Needless to say, there is no access to your data from restricted or sanctioned countries and territories as defined by applicable legislation. WHEN WE SHARE YOUR DATA In some cases, we share your data with third party services to achieve the purposes of data processing. Please refer to the table below and acquaint yourself with privacy policies of third party services. Third Party Service and Its Privacy Policy What Data Is Shared? How Is The Shared Data Used? Stripe by Stripe, Inc.https://stripe.com/privacy Name, surname, credit card information (card number, expiry date, CVC code, ZIP code) Payment processing including fraud detection Google Analytics by Google LLChttps://marketingplatform.google.com/about/analytics/terms/us/ Device fingerprint and cookie Marketing analytics Twilio Segment by Twilio, Inc.https://www.twilio.com/legal/privacy Device fingerprint and cookie Marketing analytics Hubspot by Hubspot, Inc.https://legal.hubspot.com/privacy-policy Device fingerprint and cookie Marketing analytics Twilio Sendgrid by Twilio, Inc.https://sendgrid.com/policies/security/ Name, surname, company name, email address Sending emails to customers Slack by Slack Technologies, LLChttps://slack.com/trust/privacy/privacy-policy Name, surname, company name, email address Alerts and notifications about some customers’ activities Zendesk by Zendesk, Inc.https://www.zendesk.com/company/agreements-and-terms/privacy-notice/ Name, surname, company name, email address Sign up, sign in to customer support Sentry by Functional Software, Inc.https://sentry.io/privacy/ Name, surname, company name, email address Traceback logging and investigating errors as part of our customer support Third party offerings and applications from the Chainstack Marketplace Depends on an offering or an application Enabling interoperability with our Services Where third-party services listed above (including analytics and marketing tools such as Google Analytics, Segment, and HubSpot) rely on cookies, device identifiers, or similar tracking technologies, such technologies are used only with your prior consent where required by applicable law. Chainstack discloses personal data only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on Chainstack’s behalf or to provide Services, and (ii) that have agreed not to disclose it to others. Some of those employees, contractors and affiliated organizations may be located outside of your home country. Other than to its employees, contractors and affiliated organizations, as described above, Chainstack may disclose your personal data only in response to a subpoena, court order or other governmental request, or when Chainstack believes in good faith that disclosure is reasonably necessary to protect the property or rights of Chainstack, third parties or the public at large. RETENTION OF DATA We usually keep the data for as long as it is necessary to achieve the declared purposes, including retaining certain technical and usage data (such as logs, metadata, and security-related data) for limited periods where necessary to ensure the security, integrity, and performance of our Services. In some cases, data may be retained for a longer, but limited period of time for purposes of invoicing, fulfillment of contractual obligations, legal requirements or when there is a legitimate interest. LEGAL BASES FOR DATA PROCESSING THAT WE USE We use different legal bases for processing your personal data, depending on the type of data and the purposes of data processing: Consent – for example, in cases where we use your email address to send you newsletters, or where we use cookies, tracking technologies, or send electronic marketing communications where required by applicable law. Performance of a contract – for example, in cases where we provide you with the core functionality of our Services. Instructions – for example, in cases where we process data in accordance with instructions received from you. Compliance with a legal obligation – for example, in cases where we are obliged to keep certain data for tax purposes. Legitimate interests – for example, in cases where we use anonymized usage data, except for cases where such interests are overridden by the interests or fundamental rights and freedoms of data subjects. DATA SUBJECT RIGHTS You may be entitled to exercise certain rights in relation to your personal data processed by Chainstack, depending on the country where you reside: The right to obtain all your personal data we store (“Right of access”). In some cases, the right of access may be limited for technical reasons, including if the data has been anonymized and cannot be linked to any data subject. The right to completely delete your personal data (“Right to erasure / right to be forgotten”). The right to correct your personal data (“Right to rectification”). The right to impose restrictions on processing of your personal data (“Right to restriction”). The right to object to processing of your personal data (“Right to object”). The right to receive provided personal data in a structured, commonly used and machine-readable format and to transmit those data to another controller (“Right to data portability”). The right to withdraw consent where the data processing is based on consent. The right to lodge a complaint with a data protection authority. If you wish to exercise your rights with respect to your personal data, please email us at the address below. We may ask you to further confirm your identity and will respond to you within the time period specified by applicable data protection law. Please note that in certain cases stipulated by applicable data protection law, we may charge you a reasonable fee for processing your request or refuse your request. LGPD If you are located in Brazil, your personal data is processed in accordance with the Brazilian General Data Protection Law (Lei Geral de Proteção de Dados - LGPD). Under LGPD, you have the right to: confirmation of data processing. access to your personal data. correction of incomplete or inaccurate data. anonymization, blocking, or deletion of unnecessary or excessive data. data portability. information about data sharing. withdrawal of consent, where applicable. For users in Brazil, we process personal data based on the legal grounds defined under LGPD, including: consent of the data subject. compliance with legal or regulatory obligations. legitimate interests, where applicable. Brazilian users may submit requests to exercise their LGPD rights via the contact details provided below. We will respond in accordance with applicable Brazilian law. Where personal data of individuals in Brazil is transferred internationally, we ensure that such transfers comply with LGPD requirements, including appropriate safeguards. SECURITY AND PROTECTION OF YOUR PERSONAL DATA The security of your personal data is very important to us, and Chainstack takes all measures reasonably necessary to keep your personal data accurate and complete, and to protect against the unauthorized access, use, alteration or destruction of your personal data. Chainstack uses modern security solutions, strong encryption and role-based access control in order to protect customer data and mitigate any possible risks of data leak. CONFIDENTIALITY OF COMMUNICATIONS We respect the confidentiality of communications transmitted through our Services. We do not access, monitor, or use the content of communications except where necessary to provide, secure, or maintain our Services, or where required by applicable law. Access to such data is strictly limited and subject to appropriate technical and organizational safeguards. COOKIES We use cookies and similar technologies on our Website. Where required by applicable law (including in the EEA and UK), we will obtain your prior consent before placing any cookies or similar technologies on your device, except for strictly necessary cookies. You can manage your preferences through our Cookie Consent Manager. For more information, please see our Cookie Policy. WE DO NOT SELL PERSONAL DATA Chainstack will not rent or sell your personal data to anyone. WE DO NOT PROCESS CHILDREN'S DATA Our Website and Services are not intended for or positioned to be used by children under 16 years old. We do not deliberately or accidentally collect or process children's personal data. If you know that we have been provided with personal data of children under 16, please write to us at the address below so that we can delete such data. LINKS TO EXTERNAL SITES Our Service may contain links to external websites that are not operated by us. If you click on a third party link, you will be directed to that third party’s website. We strongly advise you to review a privacy policy and terms and conditions of every third party website you visit. We have no control over and assume no responsibility for the content, privacy policies or practices of any third party websites, products or services. PRIVACY POLICY CHANGES Chainstack may change this Privacy Policy from time to time, and in Chainstack’s sole discretion. Chainstack encourages visitors to frequently check this page for any changes to its Privacy Policy. CONTACT INFORMATION If you have any questions about this Privacy Policy, please contact us via legal@chainstack.com. #### Protocols Protocols Ethereum #### Quorum Protocols Quorum #### Reliable infrastructure for stablecoins Flat-fee, RPS-tier pricing for scalable RPC. Predictable costs, unlimited requests. #### Reth Experience unmatched speed and efficiency on dedicated nodes with Reth #### Ronin URL: https://chainstack.com/protocols/ronin/ #### Run your own ZK L2 with Polygon CDK URL: https://chainstack.com/polygon-cdk/ #### Run your own zkSync Hyperchains Harness the power of sovereignty and seamless connectivity in your blockchain projects with zkSync Hyperchains. #### Save on Web3 infrastructure cost URL: https://chainstack.com/how-to-save-on-infrastructure-cost/ #### Scale better with Harmony URL: https://chainstack.com/scale-better-with-harmony/ #### Scale your on-chain application with StarkEx Apps Deploy and run the StarkEx engine with Chainstack for your high-volume on-chain applications. Scale your DApp in transaction throughput and save your users in transaction costs. #### Scroll Scroll is a zkEVM-based zkRollup on Ethereum, offering expandability, efficiency, and security for building on Ethereum, powered by zero-knowledge proofs. #### Security URL: https://chainstack.com/security/ #### Self-hosted URL: https://chainstack.com/self-hosted/ #### Service Providers URL: https://chainstack.com/service-providers/ #### Shibarium Protocols Shibarium #### Ship faster with Hyperliquid MCP URL: https://chainstack.com/ship-faster-with-hyperliquid-mcp/ #### Shred the bill URL: https://chainstack.com/shred-the-bill/ #### Solana URL: https://chainstack.com/protocols/solana/ #### Solana Trader Node For traders, snipers, HFTs, and anyone in-between #### Soneium Protocols Soneium #### Sonic Protocols Sonic #### Starknet A public permissionless L2 ZK-Rollup tp Ethereum with smart contract capabilities. #### Sui Protocols Sui #### SUPPORT AND SERVICE LEVEL AGREEMENT CHAINSTACK ENTERPRISE SUPPORT AND SERVICE LEVEL AGREEMENT Last Updated: March 8, 2024 DEFINITIONS “Claim” means a claim submitted by Customer to Chainstack pursuant to these Terms. “Downtime” means the total number of hours in a billing month when all the running instances of Chainstack Service have no connectivity or cannot be operated. “Scheduled Downtime” means the periods of downtime relating to network, hardware, or service maintenance or upgrades. Chainstack will use reasonable commercial endeavors to provide written notice to the Customer prior to the commencement of Scheduled Downtime. “Emergency Downtime” is any unplanned outage for which Chainstack is unable to provide notice as Scheduled Downtime. There shall be no more than one instance of Emergency Downtime in any calendar month, with a duration not to exceed four hours in each instance. Calculating Downtime and Service Credits. Chainstack calculates downtime from the moment the Customer reports a service issue and that is confirmed by Chainstack until the issue is resolved. However, if the service is interrupted due to occurrences that are not within the control of Chainstack (including but not limited to natural disasters or third-party service interruptions), that is not deemed as downtime. Chainstack ultimate goal is to maintain an uptime of 99.9%, where in the period of consecutive three months it will be roughly 131,400 minutes, therefore expected downtime shall not increase 131 minutes of downtime. If Chainstack fails to meet that target, the Customer is entitled to claim service credits equal to 10% of paid amounts for the affected service in the course of these consecutive three months. Network Issues. Chainstack monitors nodes sending request to them every 30 seconds from 4 separate locations. If three locations confirm a response time of less than 30 seconds and one doesn't, it is considered a network issue, not the downtime. However, if it doesn’t count as downtime, Chainstack is always available to help Customer troubleshoot any local connectivity problems. “Recovery Point Objective” (RPO) is defined as the maximum period of time in which data may be lost from the Service due to a major incident. Recovery point is determined by the timestamp of the last backup or last database log file that is successfully restored. “Recovery Time Objective” (RTO) is defined as the maximum period of time in which the Service must be restored after a major incident. Recovery time is determined by the time elapsed between the declaration of an incident and restoration of Service. “SEV 1 Issue” means any Issue in which the Service is significantly impaired and unavailable causing critical disruption to business operations. “SEV 2 Issue” means any Issue in which major Service functionality does not work with critical time sensitivity, but with no massive or severe impact on business operations. “SEV 3 Issue” means any non-urgent Issue that, whilst potentially Service impacting, does not prevent the Customer’s use of the Service in any material way (e.g. minor bugs or reports of unexpected behavior). “SEV 4 Issue” means any general question related to Chainstack’s Products or Services. For example, purely informational requests, reports, usage questions, clarifications regarding documentation, or any feature enhancement suggestions. “Service Credit” is Customer’s sole and exclusive remedy for any violation of the Service Levels. "Service Levels” means the service level commitments set forth in Section 2 of these Terms, and any other standards that Chainstack chooses to adhere to and by which it measures the level of service provided to Customer. “Uptime” is the percentage of total possible minutes the applicable Chainstack Service was available in a given calendar quarter. SERVICE LEVEL COMMITMENT Uptime. Chainstack guarantees a 99.9% quarterly uptime commitment for the applicable Chainstack Service. If Chainstack does not meet the SLA, then the Customer will be entitled to a Service Credit to the Customer’s account. Guarantees. Chainstack commits to maintain at least 99.9% Uptime for the applicable Chainstack Service. The Uptime calculation for each Service Feature that may be included with the applicable Chainstack Service is described below (“Uptime Calculation”). If Chainstack does not meet the SLA, the Customer will be entitled to Service Credits based on the calculation below (“Service Credits Calculation”). Note, that Downtime does not affect every customer at the same time or in the same way. Service Feature Uptime Calculation Service Credits Calculation Management ConsoleNetwork ServicesPlatform API (Total minutes in a calendar quarter – Downtime) / Total minutes in a calendar quarter A Service Credits claim may be based on either (not both) of the following calculations: 10% of the amount Customer paid for a Service Feature in a calendar quarter where the Uptime for that Service Feature was less than or equal to 99.9%, but greater than 99.0%. OR 25% of the amount Customer paid for a Service Feature in a calendar quarter where the Uptime of that Service Feature was less than 99.0%. Scheduled Maintenance. Chainstack can perform Service upgrades and other maintenance tasks during the maintenance window. Customer will be notified at least 7 days in advance by e-mail sent to the registered e-mail address. It is possible that during this maintenance period one or more Service features are temporarily completely or partially out of use and are therefore not available to the Customer. A scheduled maintenance message will contain the following information: (i) Timeframe in which scheduled maintenance will take place; (ii) the Expected duration of scheduled maintenance; (iii) Service Features on which scheduled maintenance will be of influence. Scheduled maintenance is excluded from the availability calculations unless the period for the scheduled maintenance is exceeded and the service is therefore not available to the customer. Maintenance Window. Tuesday and Sunday from 06:00 AM to 10:00 AM UTC. Emergency Maintenance. Emergency maintenance may be required when conditions require immediate intervention. In such a situation, the customer is informed as soon as possible by e-mail to the registered e-mail address. Unavailability during emergency maintenance is included in the availability calculation. CUSTOMER SUPPORT Customer Support Options.   Community Support Standard Support Professional Support Premium Support Terms Included Included Subscription-based Subscription-based Pricing per month Complementary Complementary $100 $1,000 Response time - < 24 hours < 6 hours < 1 hour Availability 24 x 5 24 x 5 24 x 7 24 x 7 Support Method Community support on Discord and Telegram, knowledge base. Email, community support on Discord and Telegram, knowledge base. Email, community support on Discord and Telegram, knowledge base. Email and Private chats on Slack, Telegram and Discord. Scope of Customer Support. Chainstack will provide the Cust with the onboarding and technical support services for Service Features. Customer support does not include code development or the debugging of the Customer’s software. For security reasons, only Customer’s Users may submit Claims to Chainstack Customer Support Response Times and Availability. Chainstack’s initial response times (listed below) vary based on the customer support package purchased by the Customer and the severity of the Issue. Chainstack is committed to providing a response within the timeframes described below, as measured from Customer initiation of a Claim provided that the Customer's Claim contains all necessary details for proper processing and response by Chainstack. In case the Customer's Claim does not contain the necessary information, the time for providing the response starts to measure from the moment the Customer provides all the required information.   Applicable Services Issue Example Community Support Standard Support Professional Support Premium Support SEV 1 Network Services Customer’s nodes are not accessible. - > 24 hours < 2 hours < 1 hour SEV 2 Network Services, Management Console, Platform API Management Console is not accessible while Customer’s nodes are working properly. - > 24 hours < 4 hours < 1 hour SEV 3 Network Services, Management Console, Platform API Platform API returns an error response for a request that is supported. - > 24 hours < 6 hours < 1 hour SEV 4 Network Services, Management Console, Platform API Question on the interaction between the node and client software. - > 24 hours < 6 hours < 1 hour Resolved Claims. Following Chainstack’s initial response to a Claim, Chainstack will work with the Customer to identify and resolve any and all Issues. Chainstack will consider a Claim to be resolved if: (a) Customer agrees that the Issue is resolved; (b) The source of the Issue lies with a third party, in which case, Chainstack will continue to assist the Customer and act as a resource to Customer while Customer works with the third party to resolve such Issue; or (c) Customer does not respond to a query or request from Chainstack regarding an Issue after two (2) consecutive business days. Notwithstanding the foregoing, with respect to Section (c) above, Chainstack at its own discretion has a right to re-open the Issue if Customer contacts Chainstack up to 7 calendar days after the Issue was deemed closed by Chainstack to report that the Issue has not yet been resolved. EXCLUSIONS Excluded from the Uptime Calculation are Service Feature failures resulting from (i) Customer’s acts, omissions, or misuse of the applicable Chainstack Service including violations of the Agreement; (ii) failure of Customer’s internet connectivity; (iii) factors outside Chainstack’s reasonable control, including force majeure events; (iv) Customer’s equipment, services, or other technology; or (v) scheduled maintenance unless the period for the scheduled maintenance is exceeded and the service is therefore not available to Customer. SERVICE CREDITS REDEMPTION If Chainstack does not meet this SLA, the Customer may redeem Service Credits only by sending an email request to support@chainstack.com within thirty (30) days of the end of the calendar quarter. Written requests for Service Credits redemption should be sent to Chainstack Support [https://support.chainstack.com]. Service Credits may take the form of a refund or credit to Customer’s account, cannot be exchanged into a cash amount, are limited to a maximum of ninety (90) days of paid service per calendar quarter, require Customer to have paid any outstanding invoices, and expire upon termination of Customer’s agreement with Chainstack. LIMITATIONS Redemption Limitation. Customer will not be eligible to redeem any Service Credits if Customer is in breach under any provisions of the Chainstack Enterprise Subscription Agreement at the time the Service Feature failure occurred and will not be entitled to any Service Credit if Customer is in breach under any provisions of the Chainstack Enterprise Subscription Agreement at the time such Service Credit is requested by Customer until such breach is cured. Exclusive Remedy. This SLA provides the Customer's sole and exclusive remedies for any Chainstack Service interruptions, deficiencies, or failures of any kind. To clarify, such sole and exclusive remedies shall not apply to breaches of unrelated obligations under the Chainstack Enterprise Subscription Agreement such as infringement, confidentiality, intellectual property rights, etc. No Damages. For purposes of this clause, “loss” shall mean any loss, liability, claim, damage, action, fine, penalty, cost or expense (including reasonable legal fees and expenses). notwithstanding any other provision of this SLA, in no event shall Chainstack be liable to the customer for lost profit, lost revenue or any other form of direct or indirect, incidental, special consequential or punitive losses due to Chainstack service interruptions, deficiencies, or failures of any kind. CLOUD INFRASTRUCTURE Chainstack uses managed cloud infrastructure (compute, storage, database, and other components) that has at least a 99.95% monthly uptime percentage from leading cloud service providers. Chainstack follows cloud service providers’ best practices. BACKUP AND DISASTER RECOVERY Backup and Disaster Recovery. Chainstack is performing regular backups of its Services, including Customer’s Network Services. Chainstack is performing regular Disaster Recovery simulations to verify that the corresponding procedures meet the target RPO and RTO. RPO. Target RPO for Management Console and Platform API is 1 hour. Target RPO for Network Services is 4 hours. RTO. Target RTO for Management Console and Platform API is 2 hours. Target RTO for Network Services is 4 hours. MONITORING AND ALERTING Management Console and Cloud Infrastructure. The real-time status of the Management Console and Cloud Infrastructure can be found on the Chainstack Status Page [https://status.chainstack.com]. Customer can subscribe for the relevant alerts on the same page. Network Services. Network Services monitoring is done internally by Chainstack. Monitoring of Customer’s Network Services may be provided to the Customer. SECURITY Least privilege best practices are used. Each node application including processes and data is isolated. Transport Layer Security (TLS) is always used to secure communications between Customer’s systems and nodes deployed by Chainstack. Authentication is always required to access node and platform APIs. Multi-factor authentication is required for all employees who have any kind of access to Chainstack systems. Automated vulnerability assessment and patch management are applied across all Chainstack properties including codebase. DATA PROCESSING Data Processing by Chainstack. When handling Claims and Service Credits redemption requests Chainstack processes Customer’s data such as: name, surname, email, organization name, IP, HTTP headers, cookie, all and any of which may be considered as personally-identifying information under the laws on personal data protection of some countries and territories, in accordance with the terms and conditions set forth in the Chainstack Privacy Policy, https://chainstack.com/privacy/. Customer’s Responsibility. It is the sole responsibility of the Customer to acquaint themselves with the terms and conditions of data processing set forth in the Chainstack Privacy Policy and to determine whether such terms and conditions referenced therein comply with the Customer's requirements. Use of Anonymized Data. Chainstack may anonymize Customer’s data and use it in an anonymized form to improve the quality of Chainstack Services and to publish it to clarify or respond to Customer’s Claims or to support other customers. CONFIDENTIALITY Confidential Information. Customer when sending Claims or Service Credits redemption requests may disclose to Chainstack certain information regarding the Customer’s business, including without limitation, technical, marketing, financial, employee, planning, and other confidential or proprietary information whether disclosed orally, in writing or visually, that is either marked or designated as confidential or is identified in writing as confidential at the time of disclosure or which Chainstack knew or should have known, under the circumstances, was considered confidential or proprietary by Customer (“Confidential Information”). Use and Disclosure of Confidential Information. Chainstack shall use the Confidential Information solely for the purpose of this Agreement, and for no other purpose, and Chainstack shall keep the Confidential Information secret and confidential, and not disclose, communicate, or otherwise make known to any person any part of the Confidential Information without the prior written consent of Customer, which Customer may give or to decline to give in its discretion. Exception. If any Confidential Information is required to be disclosed by judicial or governmental order, Chainstack will promptly notify Customer and take reasonable steps to assist in contesting such order or in protecting Customer’s rights prior to disclosure. INTELLECTUAL PROPERTY Background Intellectual Property. The Parties shall retain all rights to intellectual property owned by the Parties before the conclusion of this Agreement. Grant of License. Customer agrees to grant Chainstack an irrevocable, perpetual, non-exclusive, royalty-free, worldwide right to use information from Customer’s Claims to improve the quality of Chainstack Services and to publish it, subject to restrictions related to Confidential Information, to clarify or respond to Customer’s Claims or to support other customers. CHANGES Chainstack reserves the right, as reasonably necessary or convenient for Chainstack’s own purposes, to: (a) improve the quality of service to the Customer; (b) change rules of operation, identification procedures, policies, types of equipment utilized by Chainstack at its cloud infrastructure, system interfaces, and operating and other system and network software and utilities upon thirty (30) days advance notice to the Customer; and (c) implement enhancements or updates to the Chainstack Service. MISCELLANEOUS Governing Law; Jurisdiction. This SLA and any action related thereto will be governed and interpreted by and under the laws of the Republic of Singapore. Each party hereby consents to the personal jurisdiction and venue in the courts of Singapore. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement. Entire Agreement. This SLA constitutes the entire understanding and agreement by and between the Parties with respect to the subject matter hereof and supersedes all prior written and oral and all contemporaneous oral agreements and understandings with respect to the subject matter hereof. #### Switch from Alchemy to Chainstack: 60% savings guaranteed URL: https://chainstack.com/switch-from-alchemy-to-chainstack/ #### Switch from Ankr to Chainstack URL: https://chainstack.com/switch-from-ankr-to-chainstack/ #### Switch from dRPC to Chainstack URL: https://chainstack.com/switch-from-drpc-to-chainstack/ #### Switch from Helius to Chainstack URL: https://chainstack.com/switch-from-helius-to-chainstack/ #### Switch from Quicknode to Chainstack URL: https://chainstack.com/switch-from-quicknode-to-chainstack/ #### Taiko Protocols Taiko #### Talent Acquisition Privacy Notice Talent Acquisition Privacy Notice Last Updated: 13 June 2023 At Chainstack, we are committed to protecting the privacy and confidentiality of personal data we collect during the Talent Acquisition process. This privacy notice explains how we collect, use, disclose, and store personal data related to job applicants in compliance with the General Data Protection Regulation (GDPR) and the Personal Data Protection Act (PDPA) of Singapore. This notice explains how Chainstack (referred to as "we" in this document) identified below collects, stores, uses, or otherwise processes the personal data of candidates (referred to as "you" in this document) in their recruitment activities. This outlines your rights if we are processing your personal data. Data Controller Chainstack Pte. Ltd., headquartered in Singapore, is responsible for determining how and why personal data is processed. 8 Temasek Boulevard#30-01/02 Suntec Tower 3Singapore 038988 During the Talent Acquisition process, we may collect and process the following categories of personal data: Personal contact information (name, address, email, phone number) Information is provided in the CV, cover letter, or similar documents Educational background and qualifications Employment history and references Skills, experience, and certifications Online professional profiles or work portfolios (e.g.: LinkedIn, GitHub, etc.) Other information is submitted through our online application system Content and metadata of communications with us (including emails exchanged with our People Team team) Any additional information included in the application or shared during interviews or assessments Results and information related to tests or assignments completed as part of the Talent Acquisition process Information provided by third-party placement firms, if applicable Recommendations and reference check details Other information is necessary to make an employment offer and facilitate employment with us, including relocation services, if applicable Why do we process your data and on what basis? We may process your data for the following purposes: Evaluating your qualifications and suitability for employment Managing the recruitment process, including updates on application status, interviews, assessments, background checks and potential employment offers, and finalisation of offers Sending updates about our open positions Maintaining recruitment records Analysing and improving our Talent Acquisition process Monitoring workplace diversity, equity, and inclusivity Other purposes required or permitted by applicable laws and regulations The legal basis for processing your data depends on the data in question and the context of the processing. In many cases, we process your data based on our legitimate interest in finding and securing talent. We may also process your data with your consent or as necessary to enter into or perform a contract with you. When required by law, we process your data to comply with our legal obligations. Where do we collect your data from? We collect data related to you from the following sources: Directly from you, such as when you submit information through our online application system, during the Talent Acquisition process, in other interactions with us (including at Talent Acquisition or industry events), or referrals Online services used for Talent Acquisition, networking, and sharing work portfolios Third-party placement firms, if you are introduced to Chainstack through them If permitted by applicable laws and regulations, we may also collect information from a third party to conduct a background check on you. Any background check will be performed only with your explicit consent, following the scope and manner determined by the relevant laws and regulations. Providing data to us is voluntary. However, if we have inadequate information about you, we may be unable to complete the Talent Acquisition process or consider you for a position. If you choose to provide data, please ensure that it is complete and accurate. Who do we share your data with? To fulfill the purposes outlined in this policy, we may share your data with the following types of recipients: Service providers: We use BambooHR, an HR Information System (HRIS) and an Applicant Tracking System (ATS) Legal requirements: Your data may be disclosed to competent governmental authorities, courts of law, or similar entities when we believe disclosure is required by applicable laws and regulations, or to exercise, establish, or defend our legal rights Business transactions: In the context of a planned or actual acquisition, merger, or business restructuring, your data may be shared with prospective or actual buyers and their agents or advisors Personal data may be transferred to countries outside the European Economic Area (EEA) and Singapore if necessary for Talent Acquisition purposes. We ensure that appropriate safeguards are in place to protect personal data during such transfers, such as using standard contractual clauses or relying on other lawful mechanisms recognised under the General Data Protection Regulation (GDPR) and the Personal Data Protection Act (PDPA) of Singapore. How long do we keep your data? We will retain your data for as long as necessary to fulfill the purpose(s) for which it was collected, including any legal, accounting, or reporting requirements. Regarding unsuccessful candidates, we will retain applicant data for two years from the date you were informed of the decision. If you are selected for a position, your data will be transferred to our employee records and retained according to our employee data retention policies. Please note that certain situations may require deviation from the aforementioned retention guidelines. After the applicable retention period, we may retain and use non-identifiable data (including aggregate data) for statistical purposes. How do we keep your data secure? We have implemented appropriate security measures to protect your data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access. The specific measures employed vary across services or systems buttypically include access controls, contractual safeguards with third parties, regular training for personnel involved in recruitment, procedures to handle security incidents, and modern encryption protocols. Your Rights If we are processing your data, you have the right to: Access, correct, or request the deletion of your data Request us to restrict our processing of your data Object to our processing of your data to the extent our processing is based on the legitimate interests of Chainstack or a third party, or Where technically feasible, request a copy of the personal data you have provided to us in a machine-readable format Where our processing of your data is based on your consent, you also have the right to withdraw your consent at any time. To exercise any of these rights, please contact our People Team. To fulfill your request, we need to confirm your identity to verify your right to make the request, which may involve requesting additional information from you. While we will usually not do so, we reserve the right to charge an appropriate fee from you for the exercise of your rights where permitted by applicable law or regulation. Changes We may update this notice from time to time, for example, due to changes in our operations or the legal obligations that apply to us. We will inform you of any changes made by means that are appropriate considering the significance of the changes. Contact Information Our People Team, in collaboration with the Security Team, is your primary contact for matters related to this notice. If you have any questions or concerns regarding the use of your data, you may reach out to us via email atpeople-team@chainstack.com. #### Tempo Protocols Tempo #### Terms of service CHAINSTACK SAAS TERMS OF SERVICE Last Updated: February 2026 These Terms of Service constitute a binding agreement (the “Agreement”) between Chainstack Pte. Ltd. (“Chainstack”, “we”, “us”, “our”) and Customer (each, a “party”, or, collectively, “parties”) under which Chainstack provides Customer access to Chainstack Managed Services. Customer accepts and agrees to be bound by the Agreement by executing an Order Form for Chainstack Services or by using Chainstack Services. If Customer does not accept and agree to be bound by the Agreement, Customer shall not execute the Order Form for Chainstack Services and/or use Chainstack Services. DEFINITIONS “User” means the employees and/or contractors of Customer for which Customer has purchased a User license to enable access and use of Chainstack Platform. “Access Credentials” mean login information, passwords, security protocols, and policies through which Users access and use Chainstack Services. “AI Tools” means any artificial intelligence, machine learning, deep learning, generative AI, large language models, automated decision-making systems, algorithms, or similar computational technologies (including any related models, software, APIs, systems, or tools), whether developed by Chainstack or provided by third parties, that are used in connection with the provision, support, maintenance, improvement, or operation of the Services, including for purposes such as automation, data analysis, optimization, monitoring, support interactions, or content generation. “Chainstack Platform” means the interface of Chainstack Services that Users are able to access and use for purposes of using the administrative functionality of Chainstack Services. “Chainstack Documentation” means text and/or graphical materials, whether in print or electronic form, that describe the features, functions, and use of Chainstack Services and which are made available to Customer. “Chainstack Services” means the version of the Chainstack software as a service offering made generally commercially available by Chainstack as of the Effective Date, and all Updates thereto made generally commercially available by Chainstack to its customers during the Term of this Agreement, including Chainstack Platform services and Chainstack API. “Chainstack System Analytics” means anonymized information, data, statistics, metadata, inferences, interrelationships, and/or associations generated or derived from the use of Chainstack Services and/or Technology, expressly excluding Customer Inputs, and which is used by Chainstack to provide and improve Chainstack Services and to improve the Chainstack Technology. “Chainstack Technology” means the computer software, computer code, scripts, neural networks, artificial intelligence, application programming interfaces, methodologies, processes, templates, reports, workflows, diagrams, tools, algorithms, formulas, user interfaces, know-how, trade secrets, techniques, designs, inventions, APIs, third-party services and other tangible or intangible technical material, information and works of authorship underlying or otherwise used to make available Chainstack Services, including, without limitation, all upgrades, enhancements, modifications, additions and improvements thereto and all derivative works thereof, and Intellectual Property Rights therein and thereto. “Chainstack API” means a collection of routines, classes, function parameters, protocols, webhooks, related libraries and other instructions provided in source code or object code form. “Chainstack Marketplace” means the site maintained by Chainstack where Chainstack provides information about third-party offerings for Customer to acquire and/or use Third Party Services. “Customer Inputs” means information, data, text, content, videos, images, audio clips, photos, graphics, and/or other types of content, information and/or data posted, provided and/or uploaded to Chainstack Services by Customer and/or its Users. “Intellectual Property Rights” mean any and all now known or hereafter existing (a) rights associated with works of authorship, including rights in and to writings, specifications, drawings, records, documentation, advertising, promotional materials, copyrights, mask work rights, and moral rights; (b) trademark or service mark rights (c) trade secret rights, rights in and to business, technical and know-how information, non-public information, proprietary information and confidential information; (d) rights in and to patentable ideas, inventions, discoveries, patents, patent rights, and industrial property rights; (e) layout design rights, design rights, and other proprietary rights of every kind and nature other than trademarks, service marks, trade dress, and similar rights; (f) rights in and to software, including algorithms, data files, source code, object code, application programming interfaces, databases and other software-related specifications and documentation; and (g) registrations, applications, renewals, extensions, or reissues of the foregoing, in each case, in any jurisdiction throughout the world. “Third Party Services” means any software, software-as-a-service, data sources or other products or services separately procured by Customer from a third party that are integrated with Chainstack Services by Customer or by Chainstack including without limitation through use of the Chainstack APIs. “Updates” mean all upgrades, enhancements, improvements, maintenance releases, additions, and modifications of Chainstack Services made generally commercially available as part of Chainstack Services during the Term of this Agreement. CHAINSTACK SERVICES Chainstack Services. Subject to and in accordance with this Agreement and the applicable Order Forms, including, without limitation, payment of all applicable fees, Chainstack will use reasonable commercial efforts to make Chainstack Services available to Customer. Customer Access. Customer acknowledges and agrees that Customer’s and its Users’ access and use of Chainstack Services is dependent upon Customer’s and its Users’ access to telecommunications and Internet services. Customer will be solely responsible for acquiring and maintaining all telecommunications and Internet services and other hardware and software required to access and use Chainstack Services, including, without limitation, all costs, fees, expenses, and taxes of any kind related to the foregoing. Chainstack will not be responsible for any loss or corruption of data, lost communications, or any other loss or damage of any kind arising from any such telecommunications or Internet services or any such hardware or software. Modifications to Chainstack Services. Chainstack reserves the right to modify Chainstack Services on a continuous basis and if any such modification materially and adversely reduces the functionality of Chainstack Services, Customer may terminate its subscription for Chainstack Services pursuant to Section 10.2(a). Chainstack may condition the implementation of new features, functionality or other modifications to Chainstack Services on Customer’s payment of additional fees provided that Chainstack generally charges other customers for such modifications. Trial Period. Developer free account. If Customer orders a trial subscription to Chainstack Services, Chainstack will make Chainstack Services available to Customer on a trial basis (the “Trial”) until the end of the trial period ordered by Customer set forth on the corresponding Order Form (“Trial Period”). During Trial Period, Customer may only use Chainstack Services to review, demonstrate, and evaluate Chainstack Services. Access to Chainstack Services will continue after the applicable Trial Period has expired and Customer will automatically be enrolled into a Developer plan subscription at the end of the Trial Period. Additional trial terms and conditions may appear on the Order Form for the Trial. Any such additional terms and conditions are incorporated into this Agreement by reference and are legally binding. During a Trial Period, Customer shall not use Chainstack Services for any purpose other than the sole purpose of determining whether to subscribe to Chainstack Services for a longer period of time. DURING A TRIAL PERIOD, THE CHAINSTACK SERVICES ARE PROVIDED “AS-IS” WITHOUT WARRANTY. ANY DATA CUSTOMER ENTERS INTO THE CHAINSTACK SERVICES, AND ANY CUSTOMIZATIONS MADE TO THE CHAINSTACK SERVICES BY OR FOR CUSTOMER, DURING A TRIAL PERIOD WILL BE PERMANENTLY LOST UNLESS CUSTOMER CONTINUE TO SUBSCRIBE TO CHAINSTACK FOR A SUBSCRIPTION TO THE SAME CHAINSTACK SERVICES AS THOSE COVERED BY THE TRIAL, PURCHASES APPLICABLE UPGRADED CHAINSTACK SERVICES, OR EXPORTS SUCH DATA, BEFORE THE END OF THE TRIAL PERIOD. If the Customer is offered a Free Developer plan, Chainstack at its sole discretion has a right at any time to suspend Services, including but not limited to blocking or deletion of any active nodes that are not in use. THE CUSTOMER FULLY ACKNOWLEDGES THAT ANY SERVICE FOR THE FREE DEVELOPER PLAN USERS ARE PROVIDED ON AS-IS BASIS, WITHOUT WARRANTY. Chainstack API Services. Abuse or excessively frequent requests to Chainstack Services via the Chainstack API may result in the temporary or permanent suspension of the User’s access to the Chainstack API. Chainstack, in our sole discretion, will determine abuse or excessive usage of the Chainstack API. We will make a reasonable attempt to warn the User via email prior to suspension. Users may not share Chainstack API keys to exceed Chainstack’s rate limitations. All use of the Chainstack API is subject to these Terms of Service and the Chainstack Privacy Policy. Chainstack may offer subscription-based access to Chainstack API for those Users who require high-throughput access or access that would result in resale of Chainstack’s Service. In the case of subscription-based access to Chainstack API, the use of Chainstack API, including rate limitations, will be governed by subscription terms. Platform abuse. Chainstack reserves the right to terminate and/or suspend any accounts that at its sole discretion are being used to abuse Chainstack platform, including but not limited to creating multiple accounts in order to bypass usage limits. Each Customer is allowed to create only one account. We require email verification for account creation, and each credit card can only be used for one account. We also reserve the right to unilaterally change the terms of our free of charge or trial plans at any time, which may include imposing new usage limits or requiring payments for certain features. IPFS Services. Chainstack provides access to Interplanetary File System (IPFS) services, allowing users to store and retrieve data in a decentralized manner. The use of our IPFS services is subject to the terms and conditions set herein. Users are solely responsible for the content they upload to the IPFS through our services. Users must ensure that the content uploaded does not violate any laws, infringe on any rights of third parties, or contravene any of the prohibitions outlined in Chainstack Acceptable Use Policy. While Chainstack is not actively monitoring the content uploaded to the IPFS, we reserve the right to investigate reports of misuse or allegations for illegal activity. If we determine, at our sole discretion, that user has uploaded illegal content or has otherwise violated these Terms, we reserve the right to remove such content from the IPFS and take further actions as necessary, including but not limited to banning the user's account. We may take such actions without notice and at our sole discretion. Users who encounter illegal content uploaded to the IPFS through Chainstack services are encouraged to report it to us immediately. We will investigate all reports and take appropriate actions, if needed. Chainstack reserves the right with immediate effect to modify or discontinue any of our IPFS services at any time, for any reason, without notice, unless otherwise directly outlined in these Terms. Use of AI Tools. Chainstack may, at its sole discretion, use AI Tools in providing the Services, including but not limited to data processing, automation, analysis, support interactions, optimization, and content generation. AI Tools may be developed by Chainstack, provided by third parties, or integrated via APIs or other technical mechanisms. Use of AI Tools is intended to enhance the quality, efficiency, and scalability of the Services. However, Chainstack makes no warranties or guarantees that any output or result produced by an AI Tool will be error-free, complete, suitable for a particular purpose, or free from bias. Chainstack does not guarantee uninterrupted or error-free operation of AI Tools and may modify, limit, suspend, or discontinue use of any such tools at any time. Customer acknowledges that outputs generated with the use of AI Tools may require review, verification, and validation by the Customer prior to use.
Customer remains responsible for all decisions and actions taken based on such outputs and agrees that the Company shall not be liable for any customer use of or reliance on AI-generated outputs except as expressly provided in these Terms. To the extent Chainstack uses third-party AI Tools in connection with the Services, Customer agrees that such use may be subject to additional terms and conditions imposed by those third parties. Chainstack is not responsible for the performance, availability, or content of third-party AI Tools and shall have no liability arising from or relating to such third-party tools. ACCESS GRANT; LICENSES; OWNERSHIP Access Grant. Subject to Customer’s compliance with the terms and conditions contained in this Agreement, the Chainstack Documentation, and each Order Form, Chainstack grants to Customer during the Term a non-exclusive, non-transferable, worldwide, revocable, non-sublicensable right to allow: (a) Users to access and use Chainstack Services for Customer’s internal business purposes. The rights set forth in Section 3.1(a) may be exercised by Customer’s third-party contractors and service providers that are not competitors of Chainstack and which perform services for or on behalf of Customer; provided, that (i) Customer requires such third parties to execute a written agreement with Customer that is at least as protective of Chainstack Services as this Agreement and which does not grant any greater rights than those granted to Customer in Section 3.1(a) and includes all restrictions set forth in Section 4 and (ii) Customer shall be responsible for any breach of this Agreement by any such third party. Customer Inputs. To enable Chainstack to provide Chainstack Services, Customer grants to Chainstack a non-exclusive, royalty-free, fully paid, worldwide license, under any and all of Customer’s Intellectual Property Rights, to host, use, serve, render, store, access, copy, test, analyze, and create derivative works of the Customer Inputs for the sole purpose of providing the Services, to transmit the Customer Inputs to third parties, whose Third Party Services the Customer acquired on the Chainstack Marketplace, for the sole purpose of ensuring the operation of such Third Party Services and Chainstack Services, and to anonymize the Customer Inputs for the sole purpose of improving and enhancing Chainstack Services. In addition, Customer agrees that Chainstack may use its third-party contractors and services providers to exercise the licenses granted to Chainstack in this Section to perform services for or on behalf of Chainstack. Customer owns all right, title and interest in and to the Customer Inputs and reserves all rights not expressly granted to Chainstack under this Agreement. Users. The number of Users who are permitted to access and use Chainstack Services are set forth in Term and services agreement. Chainstack will provide an individual appointed by Customer (which may be an employee or consultant of Customer or may be the Customer’s Chainstack account manager) in writing with administrative access to Customer’s account so that Customer can provide access to Chainstack Services to the Users and provision the number of Workflows assigned to each User. Customer will ensure that all its Users comply with the terms and conditions of this Agreement. Customer will promptly notify Chainstack of any suspected or alleged violation of the terms and conditions of this Agreement and will cooperate with Chainstack with respect to: (i) investigation by Chainstack of any suspected or alleged violation of this Agreement, and (ii) enforcement of this Agreement. Chainstack may suspend or terminate any User’s access to Chainstack Services upon notice to Customer in the event Chainstack reasonably determines that such User has violated any terms of this Agreement. Customer will at all times be responsible for all actions taken under a User’s account, whether such action was taken by a User, or by another party, and whether such action was authorized by a User. Service Level Agreement. The service levels applicable to Chainstack Services are set forth in the Service Level Agreement. Customer’s sole and exclusive remedy and Chainstack’s sole and exclusive obligation, for any failure to meet the service levels are as provided in the Service Level Agreement. Data Backup. (a) Chainstack will follow its standard archival procedures for storage of Customer Inputs. In the event of any loss or corruption of Customer Inputs, Chainstack will use commercially reasonable efforts to restore the lost or corrupted Customer Inputs from the latest backup of such Customer Inputs maintained by Chainstack or its third-party service provider in accordance with its archival procedures. (b) Chainstack will not be responsible for any loss, corruption, destruction, alteration, or unauthorized disclosure of or access to Customer Inputs directly or indirectly arising from acts or omissions of Customer, its Users or a third party. CHAINSTACK’S EFFORTS TO RESTORE LOST OR CORRUPTED CUSTOMER INPUTS PURSUANT TO THIS SECTION 3.5 WILL CONSTITUTE CHAINSTACK’S SOLE LIABILITY AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY IN THE EVENT OF ANY LOSS, CORRUPTION, DESTRUCTION, ALTERATION, OR UNAUTHORIZED DISCLOSURE OF OR ACCESS TO CUSTOMER INPUTS. Feedback. In the event Customer and/or its Users provides Chainstack any ideas, thoughts, criticisms, suggestions, enhancement requests, techniques, know-how, comments, feedback or other input related to the Services, Chainstack Services or the Chainstack Technology, (collectively “Feedback”), including without limitation in response to any product plans or roadmaps shared with Customer, unless otherwise agreed in writing prior to such disclosure, Customer grants to Chainstack a worldwide, royalty-free, fully paid, perpetual, irrevocable license to use, reproduce, modify, translate, distribute, perform, display, import, sell, license, offer for sale, make, have made and otherwise exploit the Feedback in any form, media, or technology, whether now known or hereafter developed, and to allow others to do the same without restriction or obligation of any kind, on account of confidential information, intellectual property rights or otherwise, and may incorporate into its services any service, product, technology, enhancement, documentation or other development (“ Improvement”) incorporating or derived from any Feedback with no obligation to license or to make available the Improvement to Customer or any other person or entity. Ownership. The Chainstack Services, the Chainstack Technology, the Chainstack System Analytics, the Chainstack Documentation, and the Chainstack Platform and all worldwide Intellectual Property Rights in each of the foregoing, are the exclusive property of Chainstack and its licensors. Except for the rights and licenses expressly granted herein, all rights in and to all of the foregoing are reserved by Chainstack and its licensors. Nothing in this Agreement will be deemed to grant to Customer any right to receive a copy of software platform underlying Chainstack Services, or any other Chainstack Technology, in either object or source code form. Marketing. Chainstack may publicly refer to Customer as a customer of Chainstack, including on Chainstack’s website and in sales presentations, and may use Customer’s logo for such purpose. Similarly, Customer may publicly refer to itself as a customer of Chainstack’s software as a service, including on Customer’s website and in sales presentations. Customer agrees that Chainstack may issue at its own expense a Customer-approved press release after the Effective Date regarding Customer’s use of Chainstack Services. The parties agree to cooperate in the development of a case study, the content of which will be directed by Chainstack and approved by Customer, and which will include an impact analysis and which Customer agrees that Chainstack may publish on its website or in its marketing materials. Chainstack will beforehand inform the Customer of any future publications or case studies, where in the absence of comments and/or replies within the period of 5 business days Customer’s approval will be deemed as duly granted. Customer shall publish on Customer’s website or other publicly available Customer’s information resource a “Powered by Chainstack” logo upon Chainstack’s request and in accordance with the recommendations provided by Chainstack. References. Customer agrees that Chainstack may provide Customer’s business contact information to third parties in order for third parties to obtain information from Customer about using Chainstack Services. Chainstack shall notify Customer 3 business days prior to providing the information to allow Customer to send objection to Chainstack, where in the absence of any reply approval will be deemed as received. CUSTOMER RESPONSIBILITIES Access Credentials. Customer will safeguard, and ensure that all Users safeguard the devices, computers, and networks used to access Chainstack Services and safeguard all Access Credentials. Customer will be responsible for all acts and omissions of Users. Customer agrees to: (1) keep its Access Credentials secure and confidential and not to allow any of Customer’s Users to provide their Access Credentials to anyone else; and (2) not permit others to use Customer’s Access Credentials. Customer will notify Chainstack immediately if it learns of any unauthorized use of any Access Credentials or any other known or suspected breach of security. Chainstack reserves the right, in its sole discretion and without liability to Customer or its Users, to take any action Chainstack deems necessary or reasonable to ensure the security of Chainstack Services and Customer’s Access Credentials and account, including terminating Customer’s access or the access of any of Customer’s Users to Chainstack Services, changing passwords, or requesting additional information to authorize activities related to Customer’s account. Use Guidelines. Customer shall comply with all applicable laws, rules, and regulations in its use of Chainstack Services. Customer shall, and shall ensure that its Users will, use Chainstack Services solely for Customer’s internal business purposes as contemplated by this Agreement and shall not: (i) license, sublicense, sell, resell, rent, lease, transfer, assign, distribute, time share or otherwise commercially exploit or make Chainstack Services available to any third party, other than as expressly permitted by this Agreement; (ii) interfere with or disrupt the integrity or performance of Chainstack Services, the Chainstack Technology or the data contained therein or disrupt any servers or networks connected to Chainstack Services, or disobey any requirements, procedures, policies or regulations of networks connected to Chainstack Services; (iii) attempt to gain unauthorized access to Chainstack Services or the Chainstack Technology or any related systems or networks; (iv) remove, alter or obscure any proprietary notices associated with Chainstack Services; (v) access or use Chainstack Services in a Singapore embargoed country or in violation of any applicable export law or regulation (including any Singapore export laws and regulations); (vi) use Chainstack Services in violation of any applicable, law, rule regulation or guideline; (vii) attempt to probe, scan, or test (including without limitation stress testing or penetration testing) the vulnerability of any system or network associated with Chainstack Services or breach any security or authentication measures; or (viii) utilize Chainstack Services in order to (a) send spam or otherwise duplicative or unsolicited messages in violation of applicable laws; (b) send or store infringing, obscene, threatening, libelous, or otherwise unlawful, unsafe, malicious, abusive or tortious material, including material harmful to children or violative of third party privacy rights; or (c) send or store material containing software viruses, worms, Trojan horses or other harmful computer code, files, scripts, agents or programs or plant malware on Chainstack’s computer systems, those systems of Chainstack’s third party service providers or vendors, or otherwise use Chainstack Services to attempt to upload and/or distribute malware. Restrictions. Customer will not: (a) adapt, alter, modify, improve, translate or create derivative works of Chainstack Services (or any part thereof including the Chainstack Technology); or (b) reverse engineer, decompile, disassemble or otherwise attempt to reconstruct or obtain the source code to all or any portion of Chainstack Services; or (c) provide, maintain access to, or use Chainstack Services in any manner inconsistent with this Agreement. Customer Inputs Restrictions. The Chainstack Services includes the ability for the Customer to upload Customer Inputs. The Customer is responsible for all Customer Inputs. Customer represents, warrants and covenants that the Customer and its Users have all rights and licenses necessary to upload the Customer Inputs, to grant the licenses granted hereunder and to enable each party to exercise its rights and perform its obligations under this Agreement. Customer represents, warrants and covenants that the Customer Inputs: i. will not and does not infringe the patent, copyright, trademark, trade secret, or other intellectual property or proprietary right of others; ii. will not and does not violate the privacy, publicity, or other rights of third parties or any other law, statute, ordinance or regulation, including applicable personal data protection laws; iii. is not and will not become unlawful, tortious, fraudulent, defamatory or harmful to minors, obscene, pornographic, or offensive as determined by Chainstack in its sole discretion; iv. will not and does not violate Customer’s own privacy policy or collect information from Users in any manner to which such Users have not consented; v. will not and does not misrepresent the source of the Customer Inputs; vi. will not and does not disclose or provide information protected under any law, agreement or fiduciary relationship, including but not limited to, proprietary or confidential information of others for which Customer does not have the right or license to use and provide Chainstack the rights granted hereunder; vii. will not and does not misrepresent the Customer’s identity in any way; viii. will not and does not contain any viruses, Trojan horses, spyware, malware, worms, time bombs, cancelbots, or other disabling devices or other harmful component intended to damage, detrimentally interfere with, surreptitiously intercept or expropriate any system, data or personal information; and ix. will not and does not advocate or encourage any illegal activity; and x. will not violate, or encourage any conduct that would violate, any applicable law or regulation or would give rise to civil liability. FEES AND PAYMENT Fees. In consideration for the rights granted hereunder, Customer will pay to Chainstack the usage fee and subscription fee according to the fees listed on Chainstack website [https://chainstack.com]. All subscription and usage fees of the platform are payable by Credit Card, or by Bank account transfer, or by Cryptocurrency payment at the time of purchase and at the end of each period. Except as expressly otherwise set forth herein, all fees including but not limited to the change of services and service level, change of selected plan, subscription extension with or without recurring payments, subscription cancellation are non-refundable and will be paid in U.S. dollars and exclude all applicable sales, use, and other taxes. Any fees that are not paid when due are subject to interest at one and one-half percent (1.5%) per month or the maximum rate permitted by applicable law, whichever is less, from the due date until paid. Taxes. In certain jurisdictions, prices listed for Chainstack Services include applicable local taxes, such as sales tax, value-added tax (VAT), goods and services tax (GST), or other similar taxes. The inclusion of these taxes in the price is determined based on the requirements of the local legislation where the Customer is located. Customers are responsible for any additional taxes or fees that may apply in their jurisdiction Customer will make all payments to Chainstack free and clear of, and without reduction for, any withholding taxes; any such taxes imposed on payments of fees to Chainstack will be Customer’s sole responsibility, and Customer will provide Chainstack with official receipts issued by the appropriate taxing authority, or such other evidence as Chainstack may reasonably request, to establish that such taxes have been paid. CONFIDENTIALITY Confidential Information. Each party (the “Disclosing Party”) may from time to time during the Term of this Agreement disclose to or learn from the other party (the “Receiving Party”) certain information regarding the Disclosing Party’s business, including without limitation, technical, marketing, financial, employee, planning, and other confidential or proprietary information whether disclosed orally, in writing or visually, that is either marked or designated as confidential or is identified in writing as confidential at the time of disclosure or which the Receiving Party knew or should have known, under the circumstances, was considered confidential or proprietary by the Disclosing Party (“Confidential Information”). For the avoidance of doubt, the Chainstack Blockchain Managed Services, Chainstack Technology, Chainstack API, and Chainstack Enterprise constitute the Confidential Information of Chainstack. Further, for the avoidance of doubt, the Customer Inputs constitute Confidential Information of Customer. Protection of Confidential Information. The Receiving Party will not use any Confidential Information of the Disclosing Party for any purpose not expressly permitted by this Agreement and will disclose the Confidential Information of the Disclosing Party only to the employees of the Receiving Party who have a need to know such Confidential Information for purposes of this Agreement and who are under a duty of confidentiality no less restrictive than the Receiving Party’s duty hereunder. The Receiving Party will (a) protect the Disclosing Party’s Confidential Information from unauthorized use, access, or disclosure in the same manner as the Receiving Party protects its own confidential or proprietary information of a similar nature and with no less than reasonable care; and (b) promptly advise the Disclosing Party upon becoming aware of any loss, disclosure, or duplication of the Confidential Information or of any breach of this Agreement, including, without limitation, the misappropriation of the Confidential Information. Both parties acknowledge and agree that the Disclosing Party may be irreparably harmed by any violation of Article 6 (Confidentiality) and that the use of the Confidential Information for any purpose other than that stated herein may, among other things, enable the Receiving Party or other third parties receiving such Confidential Information to compete unfairly with the Disclosing Party. Therefore, in the event of a breach or threatened breach, the disclosing party shall be entitled, in addition to all other rights and remedies available at law or in equity, to seek (i) an injunction restraining such breach, without being required to show any actual damage or to post security or other bond; or (ii) a decree for specific performance of the applicable provision of this Agreement. Notwithstanding the termination or expiration of this Agreement, the obligations of the Receiving Party, with respect to the Confidential Information of Disclosing Party, shall be in full force and effect as follows: (A) in the case of any information or materials that constitute a trade secret within the meaning of applicable law, for as long as such information and materials remain as a trade secret, or (B) in the case of any other information or materials, during the Term of this Agreement and for five (5) years following the termination or expiration of this Agreement. Exceptions. The Receiving Party’s obligations under this subsection will not apply to any portion of the Disclosing Party’s Confidential Information if the Receiving Party can document that such information: (a) was already lawfully known to the Receiving Party at the time of disclosure by the Disclosing Party; (b) is disclosed to the Receiving Party by a third party who had the right to make such disclosure without any confidentiality restrictions; (c) is, or through no fault of the Receiving Party has become, generally available to the public; or (d) was independently developed by the Receiving Party without use of or reference to the Disclosing Party’s Confidential Information. In addition, the Receiving Party will be allowed to disclose Confidential Information of the Disclosing Party to the extent that such disclosure is (i) approved in writing by the Disclosing Party, (ii) necessary for the Receiving Party to enforce its rights under this Agreement in connection with a legal proceeding; or (iii) required by law or by the order of a court or similar judicial or administrative body, provided that the Receiving Party notifies the Disclosing Party of such required disclosure promptly and in writing and cooperates with the Disclosing Party, at the Disclosing Party’s reasonable request and expense, in any lawful action to contest or limit the scope of such required disclosure. Return of Confidential Information. The Receiving Party will return to the Disclosing Party all Confidential Information of the Disclosing Party in the Receiving Party’s possession or control and permanently erase all electronic copies of such Confidential Information promptly upon the written request of the Disclosing Party or the expiration or termination of this Agreement, whichever comes first. At the Disclosing Party’s request, the Receiving Party will certify in writing signed by an officer of the Receiving Party that it has fully complied with its obligations under this subsection. WARRANTIES Warranties by Both Parties. Each party represents and warrants that: (a) it has full power and authority to enter into and perform this Agreement; (b) the person signing this Agreement on such party’s behalf has been duly authorized and empowered to enter into this Agreement; and (c) that it will perform its obligations or exercise its rights hereunder in conformance with all applicable laws, rules, regulations, and guidelines, including, without limitation, those related to privacy and data security. Chainstack Services Warranty. Chainstack represents, warrants and covenants that Chainstack Services will include the functionality provided in the Chainstack Documentation. Disclaimer of Warranty. EXCEPT FOR THE EXPRESS WARRANTIES IN THIS SECTION 7 (WARRANTIES), CHAINSTACK MAKES NO OTHER REPRESENTATIONS OR WARRANTIES, WHETHER, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING WITHOUT LIMITATION REGARDING THE CHAINSTACK SERVICES, THE CHAINSTACK DOCUMENTATION, THE CHAINSTACK TECHNOLOGY, THE PROFESSIONAL SERVICES, OR OTHERWISE WITH RESPECT TO THE SUBJECT MATTER OF THIS AGREEMENT AND EXPRESSLY DISCLAIMS THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON INFRINGEMENT OF THIRD-PARTY RIGHTS, AS WELL AS ANY WARRANTY, ARISING FROM COURSE OF DEALING OR USAGE OF TRADE. ALL THIRD-PARТY SERVICES AND OPEN SOURCE SOFTWARE ARE PROVIDED “AS IS”. CHAINSTACK DISCLAIMS ALL WARRANTIES AND LIABILITIES ARISING FROM OR RELATED ТО THIRD PARTY SERVICES OR OPEN SOURCE SOFTWARE. CHAINSTACK DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, RELATING TO USE OF AI TOOLS, INCLUDING ANY IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, CHAINSTACK’S LIABILITY UNDER ANY IMPLIED OR STATUTORY WARRANTY, CONDITION, TERM, REPRESENTATION, UNDERTAKING OR GUARANTY WHICH CANNOT BE LEGALLY EXCLUDED IS LIMITED IN RESPECT OF THE SERVICES TO SUPPLYING THE CHAINSTACK SERVICES AGAIN OR PAYING THE COST OF SUPPLYING THE CHAINSTACK SERVICES AGAIN. Chainstack shall not be responsible for ensuring and does not represent or warrant that: (i) Chainstack Services will meet Customer’s business requirements or fit for а particular Customer’s purpose; (ii) Chainstack Services will be error-free or uninterrupted or that the results obtained from its use will be accurate, high quality, suitable, complete, truthful, useful, effective or reliable; or (iii) all deficiencies in Chainstack Services can be found or corrected. Chainstack will not be responsible for: (a) any failure to meet Chainstack Services warranty of Section 7.2 caused by acts within the control of Customer or any User or interoperability of Customer infrastructure with Chainstack Services; (b) loss or corruption of data; (c) the inability of Customer to access or interact with any other service provider through the internet, other networks or users that comprise the internet or the informational or computing resources available through the internet; or (d) Force Majeure Events (as defined in Section 11.8 below). INDEMNIFICATION Chainstack Indemnity. Chainstack shall defend (at Chainstack’s expense), Customer and its officers, directors and employees from and against any third-party claims, suits, or proceedings (“Claims”) brought against Customer or its officers, directors or employees by a third party contending that Customer’s use of Chainstack Services in accordance with the Chainstack Documentation infringes any copyright or trade secret rights of a third party and shall pay all damages finally awarded by a court of competent jurisdiction or agreed to by Chainstack in settlement of the Claim. In the event that Chainstack Services or any part thereof is likely to, in Chainstack’s sole opinion, or do become the subject of an infringement related Claim, and Chainstack cannot, at its option and expense, procure for Customer the right to continue using Chainstack Services, or any part thereof, or modify Chainstack Services, or any part thereof, to make them non infringing, then Chainstack may terminate this Agreement with notice to Customer and will provide the Customer with a refund of any pre-paid fees for the unexpired portion of the remaining Subscription Term. Chainstack shall have no liability for any Claim or demand arising from (i) an allegation that does not state with specificity that Chainstack Services is the basis of the Claims; (ii) the use or combination of Chainstack Services or any part thereof with software, hardware, or other materials not developed by Chainstack if Chainstack Services or use thereof would not infringe without such combination; (iii) modification of Chainstack Services by a party other than Chainstack, if the use of unmodified Chainstack Services would not constitute infringement; (iv) a breach by Customer of any obligation under this Agreement or a use of Chainstack Services by Customer or any User in a manner outside the scope of any right granted herein or not in accordance with the Chainstack Documentation if the claim would not have arisen but for such breach or unauthorized use; (v) an allegation made against Customer arising out of or related to open source software, or Customer Inputs; or (vi) an allegation made against Customer prior to the execution of this Agreement or after expiration or termination of this Agreement or any allegation based upon any action by Customer prior to the execution of this Agreement or after expiration or termination of this Agreement. The foregoing states Chainstack’s entire liability and Customer’s exclusive remedy for intellectual property rights infringement. Customer Indemnity. Customer shall defend, indemnify and hold Chainstack, its affiliates, employees, officers, and directors harmless from and against any loss or damage (including reasonable attorneys’ fees) incurred in connection with Claims (i) made or brought against Chainstack by a third party alleging that the Customer Inputs infringes the intellectual property rights of, or has otherwise harmed, a third party, or privacy of a third party; (ii) based upon any User’s use of Chainstack Services not in accordance with the terms hereof or not in accordance with the Chainstack Documentation or violation of 4.2 (Use Guidelines), 4.3 (Restrictions) or 4.4 (Customer Inputs Restrictions); or (iii) based on any failure or alleged failure of the Customer to comply with any applicable law, rule or regulation in connection with its use of Chainstack Services for Customer’s business. Indemnification Process. The foregoing indemnification obligations are conditioned on the indemnified party: (a) notifying the indemnifying party promptly in writing of such action, (b) reasonably cooperating and assisting in such defence at the indemnifying party’s expense, and (c) giving sole control of the defence and any related settlement negotiations to the indemnifying party with the understanding that the indemnifying party may not settle any claim in a manner that admits guilt or otherwise prejudices the indemnified party, without the indemnified party’s prior written consent. LIMITATION OF LIABILITY Limitation of Liability. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL EITHER PARTY’S AGGREGATE LIABILITY ARISING OUT OF OR RELATED TO THIS AGREEMENT, WHETHER ARISING UNDER STATUTE, CONTRACT, TORT OR UNDER ANY OTHER THEORY OF LIABILITY, EXCEED THE AMOUNTS ACTUALLY PAID BY CUSTOMER UNDER THE APPLICABLE STATEMENT OF WORK OR THE APPLICABLE ORDER FORM UNDER WHICH THE CLAIM AROSE DURING THE TWELVE (12) MONTHS PRIOR TO THE DATE ON WHICH SUCH CLAIM OR CAUSE OF ACTION AROSE. THE FOREGOING LIMITATIONS ARE CUMULATIVE AND NOT PER INCIDENT AND SHALL APPLY EVEN IF THE NON-BREACHING PARTY’S REMEDIES UNDER THIS AGREEMENT FAIL OF THEIR ESSENTIAL PURPOSE. Exclusion of Consequential and Related Damages. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL EITHER PARTY HAVE ANY LIABILITY TO THE OTHER PARTY OR TO ANY THIRD PARTY FOR ANY LOSS OF ACTUAL OR ANTICIPATED PROFITS, LOSS OF BUSINESS, LOSS OF, DAMAGE TO, OR CORRUPTION OF, DATA, LOSS OF USE, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, SPECIAL, EXEMPLARY, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES HOWEVER CAUSED, WHETHER ARISING UNDER STATUTE, CONTRACT, TORT (INCLUDING NEGLIGENCE) OR UNDER ANY OTHER THEORY OF LIABILITY, WHETHER OR NOT THE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE OR WHETHER SUCH DAMAGE WAS FORESEEABLE OR IN THE CONTEMPLATION OF THE PARTIES. Exclusions. The foregoing limitations shall not apply to (i) amounts payable by Customer to Chainstack under an Order Form or Statement of Work, (ii) damages arising from a breach by Customer of Section 3.1, 3.2, 3.3, or 4, (iv) damages arising from misappropriation of Chainstack's Intellectual Property Rights by the Customer. Savings Clause. SOME JURISDICTIONS DO NOT ALLOW LIMITATIONS ON DURATION OR THE EXCLUSION OF AN IMPLIED WARRANTY, SO THE LIMITATIONS HEREIN MAY NOT APPLY. Neither party shall be responsible or liable for any loss, damage or inconvenience suffered by the other party or by any third person, to the extent that such loss, damage or inconvenience is caused by the failure of the other party to comply with its obligations under this Agreement. Limitation of Action. To the maximum extent permitted by applicable law and except for actions for non-payment or breach of Chainstack's Intellectual Property Rights, no action (regardless of form) arising out of this Agreement may be commenced by either party more than one (1) year after the cause of action has accrued. Allocation of Risk. Each party acknowledges that the fees set forth in this Agreement reflect the allocation of risk between the parties and that the other party would not enter into this Agreement without these limitations on its liability. TERM AND TERMINATION Term. The term of this Agreement will commence on the Effective Date and remain in effect as long as subscription and usage fee are paid (“Term”). Termination. (a) The termination of this Agreement can be requested by the User at any time, upon which the User will be asked to pay any outstanding amount owed, after which no further charges will be incurred by the User. (b) This Agreement may be terminated by Chainstack if Customer fails to timely make any payment due hereunder and fails to cure such default within fifteen (15) days after receiving notice in writing from Chainstack of such failure (whether or not Chainstack avails itself of its right to suspend Services pursuant to Section 10.3 hereof). Suspension of Services. At any time during the Term, Chainstack may, immediately upon notice to Customer, suspend its performance under this Agreement and any Order Form or may suspend any and all Users’ access to Chainstack Services, in Chainstack’s sole reasonable discretion, including, without limitation, for any of the following reasons: (a) a reasonable threat to the technical security or technical integrity of Chainstack Services exists as determined by Chainstack in its sole and absolute discretion; provided that Chainstack promptly recommences performance upon the cessation of the threat, or (b) if any amount due under this Agreement is not received by Chainstack within fifteen (15) days after it was due and Chainstack provided written notice of same. Outstanding Fees. Termination shall not relieve Customer of the obligation to pay any fees accrued or payable to Chainstack prior to the effective date of termination. In the event of termination by Chainstack pursuant to Section 10.2(a) or 10.2(b), all amounts payable by Customer under this Agreement will become immediately due and payable. Rights and Obligations Upon Expiration or Termination. Upon expiration or termination of this Agreement, User’s right to access and use Chainstack Services will immediately terminate, User will immediately cease all use of Chainstack Services, and each party will return and make no further use of any Confidential Information, materials, or other items (and all copies thereof) belonging to the other party. Upon expiration or termination of this Agreement, Chainstack will cease use of the Customer’s name, logo, and trademarks (“Customer Marks”); provided, however, that (a) Chainstack will have a reasonable time to remove the Customer Marks from promotional materials, and (b) Chainstack will not be required to remove any printed materials from circulation. GENERAL Governing Law; Jurisdiction. This Agreement and any action related thereto will be governed and interpreted by and under the laws of the Republic of Singapore. Each party hereby consents to the personal jurisdiction and venue in the courts of Singapore. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement. Export; Anti-Corruption. Each party shall comply with the export laws and regulations of Singapore and other applicable jurisdictions in providing and using Chainstack Services. Without limiting the foregoing, (i) each party represents that it is not named on any Singapore government list of persons or entities prohibited from receiving exports, and (ii) Customer shall not permit Users to access or use Chainstack Services in violation of any Singapore export embargo, prohibition or restriction. Customer represents that it has not received or been offered any illegal or improper bribe, kickback, payment, gift, or thing of value from any of Chainstack’s employees or agents in connection with this Agreement. Reasonable gifts and entertainment provided in the ordinary course of business do not violate the above restriction. If Customer learns of any violation of the above restriction, Customer will use reasonable efforts to promptly notify Chainstack. Severability. If any provision of this Agreement is, for any reason, held to be invalid or unenforceable, the other provisions of this Agreement will remain enforceable and the invalid or unenforceable provision will be deemed modified so that it is valid and enforceable to the maximum extent permitted by law. Waiver; Remedies. Any waiver or failure to enforce any provision of this Agreement on one occasion will not be deemed a waiver of any other provision or of such provision on any other occasion. Other than as expressly stated herein, the remedies provided herein are in addition to, and not exclusive of, any other remedies of a party at law or in equity. Entire Agreement. To the maximum extent permitted by applicable law, this Agreement, together with the documents referenced herein constitute the entire agreement between the parties as to its subject matter, and supersede all previous and contemporaneous agreements, (including without limitation any nondisclosure agreements previously executed by the parties), proposals or representations, written or oral, concerning the subject matter of this Agreement. No representation, undertaking or promise shall be taken to have been given or be implied from anything said or written in negotiations between the parties prior to this Agreement except as expressly stated in this Agreement. Neither party shall have any remedy in respect of any untrue statement made by the other upon which that party relied in entering into this Agreement (unless such untrue statement was made fraudulently) and that party’s only remedy in respect of any untrue statement shall be for breach of contract as provided in this Agreement. Customer acknowledges and agrees that its agreement hereunder is not contingent upon the delivery of any future functionality or features not specified herein or in an Order Form or dependent upon any oral or written, public or private comments made by Chainstack with respect to future functionality or features for Chainstack Services. In the event of any conflict between the provisions in this Agreement and any Order Form or Statement of Work, the terms of such Order Form or Statement of Work shall prevail. No terms or conditions stated in a Customer purchase order or in any other Customer order documentation shall be incorporated into or form any part of this Agreement, and all such terms or conditions shall be null and void. Attorney’s Fees. Customer shall pay on demand all of Chainstack’s reasonable attorney fees and other costs incurred by Chainstack to enforce this Agreement or to collect any fees or charges due to Chainstack under this Agreement following Customer’s breach of its payment obligations under this Agreement or any Order Form. Assignment. Chainstack at any time may assign, subcontract, delegate, or otherwise transfer this Agreement, or its rights and obligations herein, without obtaining the prior written consent of the Customer; Either party may assign this Agreement in connection with a merger, acquisition, reorganization or change of control, including without limitation a sale of all or substantially all of its assets, stock or business to which this Agreement relates. The terms of this Agreement will be binding upon the parties and their respective successors and permitted assigns. Force Majeure. Any delay in the performance of any duties or obligations of either party (except the payment of money owed) will not be considered a breach of this Agreement if such delay is caused by a labor dispute, shortage of materials, fire, earthquake, flood, or any other event beyond the control of such party (“Force Majeure Events”), provided that such party uses reasonable efforts, under the circumstances, to notify the other party of the cause of such delay and to resume performance as soon as possible. Independent Contractors. Chainstack’s relationship to Customer is that of an independent contractor, and neither party is an agent or partner of the other. Neither party will have, and will not represent to any third party that it has, any authority to act on behalf of the other. Notices. All notices under this Agreement shall be in writing. All notices shall be given by electronic mail to the address of the party specified in this Agreement or an Order Form. All notices shall be effective upon the second (2nd) day following sending by electronic mail. Each party may change its address for receipt of notice by giving notice of such change to the other party. Counterparts; Electronic Signatures. This Agreement may be executed in one or more counterparts, each of which will be deemed an original and all of which will be taken together and deemed to be one instrument. A manually or electronically signed copy of this Agreement, any Order Form or any Statement of Work delivered by facsimile, e-mail or other means of electronic transmission shall be deemed to have the same legal effect as delivery of an original signed copy of the Agreement, the Order Form or Statement of Work. Modifications. a. Chainstack may modify these Terms and the Service Level Agreement at any time, solely at its own discretion with prospective effect. If Chainstack modifies these Terms and the Service Level Agreement, it will publish such modifications on company’s website. Customer at any time can access the copy of current versions of Terms and the Service Level Agreement on Chainstack website. If Customer does not wish to accept such modifications, then Customer may terminate Customer’s subscription to the affected Chainstack Services, subject to the terms of this Section 11.12 (Modifications). b. If modifications will become effective upon commencement of a renewal Subscription Term, then the modifications will become effective for all Chainstack Services, as applicable, affected by the changes upon renewal of the applicable Subscription Term. Customer may avoid the applicability of the changes only by cancelling the renewal of the Subscription Term prior to the commencement of the renewal Subscription Term. c. If the modifications will become effective during the then-current Subscription Term, then Customer may terminate Customer’s subscription to the affected Chainstack Services as applicable, at any time. If Customer does not terminate the affected Chainstack Platform subscription as specified in this Section 11.12 (Modifications), then Customer will be bound by the modified terms. Construction. The titles of the sections of this Agreement are for convenience of reference only and are not to be considered in construing this Agreement. Unless the context of this Agreement clearly requires otherwise: (i) references to the plural include the singular, the singular the plural, and the part the whole, (ii) “or” has the inclusive meaning frequently identified with the phrase “and/or,” (iii) “including” has the inclusive meaning frequently identified with the phrase “including but not limited to” or “including without limitation,” and (iv) references to “hereunder,” “herein” or “hereof” relate to this Agreement as a whole. Any reference in this Agreement to any statute, rule, regulation or agreement, including this Agreement, shall be deemed to include such statute, rule, regulation or agreement as it may be modified, varied, amended or supplemented from time to time. The parties agree that this Agreement shall be fairly interpreted in accordance with its terms without any strict construction in favor of or against either party and that ambiguities shall not be interpreted against the drafting party. #### The builders survey report URL: https://chainstack.com/the-builders-survey-2023/ #### TON Protocols TON #### Trader Node URL: https://chainstack.com/trader-nodes/ #### Traders URL: https://chainstack.com/traders/ #### TRON Protocols TRON #### Unichain Protocols Unichain #### Unlimited Node Flat-fee, RPS-tier pricing for scalable RPC. Predictable costs, unlimited requests. #### Unlimited Node Demo URL: https://chainstack.com/unlimited-node-demo/ #### Use Case - gaming URL: https://chainstack.com/gaming/ #### We solve blockchain infra so that you don't have to URL: https://chainstack.com/ #### Web3 Builders URL: https://chainstack.com/web3-builders/ #### Web3 Certificate URL: https://chainstack.com/web3-certificate/ #### Welcome to our reading room Go ahead, download your pick, and stay updated for new protocol, DevOps-, and business-related content. #### WeMix Protocols WeMix #### Why switch to Chainstack URL: https://chainstack.com/why-switch-to-chainstack/ #### Your RPC endpoint to the BNB Smart Chain Start interacting and building on BNB Smart Chain in a few clicks. #### Zircuit Protocols Zircuit #### zkLink Protocols zkLink #### zkSync Era zkSync Era is a user-focused, EVM-compatible protocol secured by zero-knowledge proofs, offering scalable and cost-efficient solutions for large-scale applications. #### Zora Protocols Zora ### Marketplace #### Ape A Python-based framework to develop, test and deploy smart contracts on Ethereum and other networks.  #### bloXroute Gateway Blockchain Distribution Network utilizing a global network of servers optimized for network performance. #### Brownie A Python-based development and testing framework for smart contracts on Ethereum and Ethereum-based protocols. #### Chainlink Oracle service for Ethereum and Ethereum-based smart contracts. #### Chainstack Load Balancer Fault-tolerant load balancer for Ethereum and Bitcoin APIs. #### Forta Real-time detection network for security and operational monitoring of blockchain activity. #### Foundry Foundry is a fast, portable and modular toolkit for Ethereum and Ethereum-based application development written in Rust. #### Hardhat A development environment to develop, test, and deploy smart contracts on Ethereum and Ethereum-based protocols. #### Hypernative Hypernative stops hacks in real-time before they have a chance to do any damage. #### MatrixedLink MatrixedLink is a Chainlink Node Operator, offering Data Feeds, Proof of Reserve, and custom oracle integration services. #### MetaMask A crypto wallet and a gateway to the Ethereum and Ethereum-based DApps. #### MEV Protection Enable MEV protection on your nodes to prevent front-running, sandwich attacks, and other MEV exploits. #### The Graph Decentralized protocol for indexing and querying data from blockchains. #### Unlimited Node Flat monthly fee based on your chosen RPS (requests per second) capacity — no per-request charges, no surprises. #### Warp Transactions Send transactions through optimized routing for faster propagation and block inclusion on Ethereum, BNB Smart Chain, and Solana. #### Yellowstone gRPC Geyser Plugin Solana data streaming. Subscribe only to the events you care about—no RPC overhead, no gaps, no delays. ### Additional URLs #### Pricing.md URL: https://chainstack.com/pricing.md