## Overview\\n\\nAs [Pagoda winds down its services](https://docs.near.org/blog/2024-08-13-pagoda-services) and critical infrastructure, there is a need to transition the management and development of the near.org RPC service, which is being used as a public good in the ecosystem, with a clear service level agreement for the chosen vendor.\\n\\nnear.org RPC currently operates as a high-capacity NEAR RPC service, entirely subsidized by the NEAR Foundation. It is used by countless applications and wallets, including some of the most popular NEAR applications. However, we recognize that, by being hosted on near.org and offered at no cost to developers, the service contributes to unwanted centralization of the NEAR ecosystem.  \\n\\nNear.org RPC will become a heavily rate-limited \\u{201c}free tier\\u{201d} or demo-only service, maintaining backward compatibility with existing dev tooling and low-traffic applications.  High-traffic applications will be responsible for migrating their RPC usage to an alternative provider.  As part of this RFP, the new operator for this rate-limited near.org RPC service will be allowed to advertise their related commercial offering to these users, with the limits described below.\\n\\n## Technical Overview\\n\\nThe Infrastructure Committee (IC) seeks a new operator for these four URLs during or after the transformation into a free-tier-only service:\\n\\n* [https://rpc.mainnet.near.org](https://rpc.mainnet.near.org)\\n* [https://rpc.testnet.near.org](https://rpc.testnet.near.org)\\n* [https://archival-rpc.mainnet.near.org](https://archival-rpc.mainnet.near.org)\\n* [https://archival-rpc.testnet.near.org](https://archival-rpc.testnet.near.org)\\n\\nThe current implementation of near.org RPC relies primarily on [Read-RPC](https://github.com/near/read-rpc/), a specially optimized backend server, and a ScyllaDB database built to handle NEAR RPC queries at scale. Some requests are routed to a scaled fleet of standard or archival [NEAR RPC nodes](https://near-nodes.io/rpc) running on Google Cloud. All underlying systems conform to the [NEAR RPC API regardless of where a request is routed](https://docs.near.org/api/rpc/introduction).\\n\\nThe new operator is welcome to use any or all of the current setups or their own. However, they must establish new relationships with the necessary cloud service providers.\\n\\n### Current Rate Limits\\n\\nThese are the existing rate limits applied by Pagoda (current maintainers).\\n\\n* RPC\\n  * 9000 requests/10s (27000 requests/30s) per IP (mainnet)\\n  * 2000 requests/30s per IP (testnet)\\n* Archival-RPC\\n  * 1000 requests/30s per IP (mainnet)\\n  * 2000 requests/30s per IP (testnet)\\n\\nNote: There is no authentication on these RPC endpoints.\\n\\nA few NEAR Foundation partners (dApps) are exempt from the rate limits above, consume a high load of RPC services, and receive white glove service provided by the Pagoda SRE team. They\\u{2019}re identified by using special Referrer headers in their requests. These partners have been notified that this level of service will be ending, and they have been encouraged to move out to alternative RPC providers that meet their production demands. After 01-Feb-2025, if they choose to remain on near.org RPC, they will be subject to the same rate limits as everyone else.\\n\\n### Transformation into Demo Environment\\n\\nAs mentioned above, we seek to turn near.org RPC into a free-tier / demo environment only by gradually lowering rate limits until the beginning of February.\\n\\nPagoda will execute this transformation according to the schedule below until the new operator takes over; at this point, they will be expected to continue that transformation. The Infrastructure Committee will prioritize proposals for an earlier transition to the new operator instead of waiting for the Pagoda team to finish lowering the rate limits.\\n\\nThis RFP aims to ensure that the special partners using near.org RPC for high-traffic loads are not adversely affected during and after this transition period. Near Foundation will work with the Pagoda SRE team and the new operator to ensure that their workload seamlessly migrates to the new RPC provider of their choice.\\n\\nOctober 15th:\\n\\n* **RPC Mainnet:** 15000 requests/30s per IP\\n* **RPC Testnet:** 1500 requests/30s per IP\\n* **Archival-RPC Mainnet:** 800 requests/30s per IP\\n* **Archival-RPC Testnet:** 1500 requests/30s per IP\\n\\nNovember 1st\\n\\n* **RPC Mainnet**: 5000 requests/30s per IP **or referrer**\\n* **RPC Testnet**: 1200 requests/30s per IP **or referrer**\\n* **Archival-RPC Mainnet**: 400 requests/30s per IP **or referrer**\\n* **Archival-RPC Testnet**: 800 requests/30s per IP **or referrer**\\n\\nDecember 1st\\n\\n* **RPC Mainnet**: 2000 requests/30s per IP or referrer\\n* **RPC Testnet**: 900 requests/30s per IP or referrer\\n* **Archival-RPC Mainnet**: 200 requests/30s IP or referrer\\n* **Archival-RPC Testnet**: 400 requests/30s per IP or referrer\\n\\nJanuary 1:\\n\\n* **RPC Mainnet**: 500 requests/30s per IP or referrer\\n* **RPC Testnet**: 600 requests/30s per IP or referrer\\n* **Archival-RPC Mainnet**: 100 requests/30s per IP or referrer\\n* **Archival-RPC Testnet**: 200 requests/30s per IP or referrer\\n\\nFebruary 1st\\n\\n* **RPC Mainnet**: 150 req/30s per IP or referrer\\n* **RPC Testnet**: 300 requests/30s per IP or referrer\\n* **Archival-RPC Mainnet**: 20 requests/30s per IP or referrer\\n* **Archival-RPC Testnet**: 100 requests/30s per IP or referrer\\n\\nNote: Rate limits will be applied by IP or by the HTTP \\u{201c}Referer\\u{201d} header, whichever hits first. Frontend applications will likely be rate-limited by the referrer, while backend applications will likely be rate-limited by the IP address.\\n\\n## Requirements\\n\\nThe maintenance requirements of this RPC service are listed below:\\n\\n* Collaborate with Pagoda SRE for any knowledge transfer and handover of the current endpoints\\n  * The current load balancer maintained by the Pagoda SRE team allows for a gradual transition. This will help ensure a smoother transition and better downtime management during the transition phase.\\n  * 100% target date before 01-Feb-2025, but we encourage an earlier transition during the rate limit decrease (as mentioned above), especially for overflow business\\n* Timely nearcore upgrades. There is a five-day time frame for deploying the latest [nearcore releases](https://github.com/near/nearcore/releases).\\n* Maintain monitoring and alerting system, showing the health of RPC systems\\n* Maintain external-facing status page (for example, [Helius Network](https://helius.statuspage.io/)) showing incidents and uptimes, and communicate across company social platforms and relevant partners.\\n\\n### Security\\n\\n* Proposals must include a comprehensive security plan, including DDoS protection measures, IP whitelisting capabilities, and detailed logging and monitoring strategies.\\n* Vendors must provide a detailed disaster recovery and business continuity plan, including regular backup procedures and a strategy for quick service restoration in case of major outages.\\n\\n### Service Level Agreement\\n\\n1. **Availability**\\n    * **Uptime Guarantee**: 99.9% monthly uptime\\n    * **Downtime Allowance**: Up to 44 minutes of downtime per month\\n\\n2. **Performance**\\n    * These are tracked internally and shared with the Infrastructure Committee (IC)**\\n    * **Response Time**:\\n    * **Mainnet RPC**: Average response time of \\u{2264} 1 second\\n    * **Testnet RPC**: Average response time of \\u{2264} 1.5 seconds\\n    * **Archival-RPC**: Average response time of \\u{2264} 2 seconds\\n    * **Rate Limiting**:\\n    * 150 req/30s\\n    * **Rate Limit Enforcement**: Strict enforcement with immediate rate limit application once thresholds are reached\\n    * Note: It would be good to have an external dashboard with these stats and historical data for the last 30 days.\\n\\n3. **Pricing**\\n    * The new RPC service provider must not accept payments for RPC services on near.org. However, it can advertise its service as a separate paid RPC with higher rate limits, as described below.\\n\\n4. **Advertising**\\n    * If you serve GET requests or a homepage at any of the RPC URLs above, that page can advertise your associated services, but it must:\\n    * Make it clear in postings or advertisements that your services are not directly affiliated with or operated by NEAR or the NEAR Foundation.\\n    * Include a prominent link to [https://docs.near.org/api/rpc/providers](https://docs.near.org/api/rpc/providers).  \\n\\n5. When a user is rate-limited, you must return an HTTP 429 response.\\n    * The response body is up to you and can also be used to advertise your associated services.  But if you do so, that response body must also contain the URL [https://docs.near.org/api/rpc/providers](https://docs.near.org/api/rpc/providers).\\n        * For instance, an acceptable response body is `{\\\"jsonrpc\\\": \\\"2.0\\\", \\\"error\\\": {\\\"code\\\": -429, \\\"message\\\": \\\"Rate limits exceeded. For higher rate limits, try [http://myrpcprovider.example](http://myrpcprovider.example) or other RPC providers at [https://docs.near.org/api/rpc/providers](https://docs.near.org/api/rpc/providers).\\\"}, \\\"id\\\": \\\"1\\\"}`.\\n\\n6. The Infrastructure Committee may from time to time evaluate any advertising on the near.org RPC service and demand changes within reason to conform to the guidelines above.\\n\\n7. **Support**\\n    * **Support Availability**: Community-based support only (e.g., through online help desk, forums, GitHub issues, or a developer community Slack/Telegram/Discord channel)\\n    * **Response Time**: No guaranteed response time, but best-effort responses within 24-48 hours for generic services.\\n\\n8. **Data Integrity**\\n    * **Data Consistency**: Standard (non-archival) RPC nodes must always serve five-time epochs. Both RPC and Archival nodes track all NEAR shards.\\n\\n9. **Updates and Changes**\\n    * **Notice for Breaking Changes**: At least seven days\\\' notice for any breaking changes in the API or infrastructure\\n\\n10. **Limitations**\\n    * **Compensation for Outages:** There are no financial credits or compensation for outages or performance issues for free public good services. However, if there are partners who utilize your paid service, they should agree on separate customized SLAs with the RPC provider directly.\\n    * **Fair Use Policy**: Provide Explicit statements about the intended use for development and the prohibition of production workloads\\n\\n11. **Termination Rights**: The right to suspend or terminate the service for users who exceed fair use or misuse the service. IC must be informed about these.\\n\\n12. **Failure to Perform:** If vendor RPC services fall below the performance benchmarks mentioned above, the Infrastructure Committee has the right to transition this public good to another vendor. The current maintainer will be required to facilitate the transition.\\n\\n### Technology Guidelines\\n\\nPreferences\\n\\n* Proposers are encouraged to use current technology (load balancers, readrpc, nodes) and optimize performance to save on costs.\\n* Preference (not requirement) to decentralized RPC\\n\\n### Expertise Guidelines\\n\\n* Already operating current NEAR RPC nodes\\n* Preference (not requirement) Pagoda ex-employees, including SREs that previously maintained this infrastructure or other existing NEAR ecosystem partners\\n\\n## Transition steps for the selected vendor\\n\\n1. Set up necessary access and permissions for the new team for DNS records and any other associated infrastructure related to DNS service (for example - load balancers)\\n2. Conduct knowledge transfer sessions with the current Pagoda team, including one on [ReadRPC,](https://github.com/near/read-rpc) in case the vendor wants to inherit that tech.\\n3. Implement and test any necessary changes or improvements to the infrastructure.\\n4. Perform thorough testing to ensure data integrity and system performance.\\n5. Gain access to relevant documentation.\\n6. Establish new support channels and processes.\\n7. Conduct a final review and handover with the Infrastructure Committee.\\n8. Conduct official communications on your channels and with the NEAR Developer ecosystems and relevant stakeholders.\\n\\n### Budget Guidelines\\n\\n#### Budget\\n\\nProposals should outline a detailed budget with a clear breakdown of costs, including development, testing, documentation, maintenance and support, infrastructure, third-party services, and external API costs. Maintenance costs should be calculated accurately based on provided usage information and existing software costs. Properly assessing a budget based on usage is a significant factor in qualifying legitimate entities.\\n\\n#### Milestones\\n\\nPlease highlight the details of the various milestones in your development plan and the relevant budgets attached to each milestone. Any metrics around the milestone\\\'s success (acceptance criterion) should also be included. Milestone examples include signing the agreement, the official transition, a 6-month or 12-month billing period, etc.\\n\\n#### Contingency\\n\\nInclude a contingency plan for potential overruns or unexpected expenses. Suppose expenses for providing free services or public goods to the NEAR ecosystem exceed previous budgets. In that case, a clear policy should be to report expenses incurred by NEAR usage to cover additional costs and prove that costs exceeded previous budgets.\\n\\n## Current Usage\\n\\nBelow are some of the statistics related to the current usage of RPC services provided by the Pagoda SRE team:\\n\\n* RPC Mainnet - 6k requests/s\\n* RPC-Archival Mainnet - 2k requests/s\\n* RPC Testnet - 400 requests/s\\n* RPC-Archival Testnet - 150 requests/s\\n\\nRequests have been stagnant, fluctuating from a steady 10k RPS to peaks of 25k RPS.\\n\\n## Evaluation Criteria\\n\\n### Technical Expertise and Experience\\n\\n* Demonstrated expertise in building and maintaining high-performance RPC infrastructure for blockchain networks\\n* Minimum two years of experience working with blockchain RPC systems\\n* Strong understanding of NEAR protocol architecture and technical specifications\\n* Proven track record of handling high transaction volumes and ensuring low latency\\n* Experience with scalable and fault-tolerant distributed systems\\n\\n### Past Performance\\n\\n* Completed at least one similar RPC infrastructure project for blockchain networks\\n* Positive references from previous blockchain clients or projects\\n* Demonstrated ability to meet or exceed service level agreements (SLAs) for uptime and performance\\n\\n### Pricing Structure\\n\\n* A clear breakdown of costs for implementation, maintenance, and scaling\\n* Willingness to consider performance-based pricing incentives\\n\\n### Alignment with Web3 and NEAR Values\\n\\n* Commitment to decentralization and open-source principles\\n* Demonstrated support for blockchain interoperability and cross-chain communication\\n* Alignment with NEAR\\\'s vision of empowering developers and users\\n* Commitment to privacy and data protection in line with Web3 ethos\\n\\n### Governance Structure\\n\\n* Clear and transparent decision-making processes within the organization\\n* Defined roles and responsibilities for project management and technical leadership\\n* Commitment to regular communication and reporting to NEAR stakeholders\\n* Willingness to participate in NEAR\\\'s governance processes and community discussions\\n\\n## Resources\\n\\nImportant - All NEAR-related RPC information can be found at [https://docs.near.org/api/rpc/providers](https://docs.near.org/api/rpc/providers) (it is also important to note that many of these providers also offer free RPC service)\\n\\n## Process\\n\\n[//]: # (Boilerplate)\\n\\n**[Proposal Process](https://docs.google.com/document/d/1F7iAT9tWngik9JPS_GadCCEB5nZtA2AiL2yWZoBGMFM/pub)**\\n\\nYou should submit a proposal in response to this RFP on the Infrastructure Committee Portal. [Here](https://docs.google.com/document/d/1TVvPXPJhZfaFwfA2UMW6c3pO2kis45SJ1Np1XOkkhnA/edit?usp=sharing) is a standard (+ [markup](https://docs.google.com/document/d/1UZRfOE1JAOhsnSmp-RmL2hY7KPJbpBImKZVvPV4YJmA/edit?usp=sharing)) template you can use as a starting point.\\n\\nMarketing materials, presentations, and images can be attached as needed as external links. An easy way to do this is to start a discussion under the Proposals category on the Infrastructure Working Group GitHub repository [here](https://github.com/near/Infrastructure-Working-Group/discussions/categories/proposals), publish, edit the post, and finally copy the links generated for the files you uploaded.\\n\\n### Proposal Submission Dates\\n\\nThe deadline for proposal submission is **Tuesday, October 15th** (giving applicants approximately three weeks), with a Q&A period on the proposal itself. We will accept submissions after this date, however, on-time proposals will take priority.\\n\\n### Selection Process\\n\\nAfter reviewing the proposals, the committee will vote on the best one. Generally, this process takes two working weeks to complete and will be discussed and voted on at the regular bi-weekly meeting.\\n\\n### Voting Dates\\n\\nThe estimate for voting completion is **two weeks** after the proposal submission date.\\n\\n### Transition Process\\n\\nThe estimated transition time is one week, not considering any KYC or KYB blockers.  \\n\\n### Funding Process\\n\\nThe Infrastructure Committee governs funding with assistance from the NEAR Foundation. If selected, your proposal enters the funding pipeline. You are required to:\\n\\n* Complete the KYC/B process conducted by the NEAR Foundation, including verification by IDVerify.\\n* Sign a legal agreement regarding the work as outlined in the proposal conducted by the NEAR Foundation.\\n* Submit an invoice to NEAR Foundation Finance outlining how you want funds disbursed, to what wallets or banks, and in the agreed-upon amounts.\\n* Complete a test transaction to verify target wallets (when requesting funds in cryptocurrency).\\n\\n### Funding Dates\\n\\nThe funding process is generally completed in one working week if the proposal does not require clarifications in the budget, work approach, legal agreement, or invoicing terms.\\n\\n### Communication\\n\\nPlease direct all communications to the thread where the RFP started beneath the submitted proposal. Please direct confidential or sensitive communications to the Telegram group set up between the committee and the organization/entity/team. If you don\\\'t have a private Telegram group between your team and the Infrastructure Committee, please request one in this thread.\\n

New Operator for near.org RPC Service

As [Pagoda winds down its services](https://docs.near.org/blog/2024-08-13-pagoda-services) and critical infrastructure, there is a need to transition the management and development of the near.org RPC service, which is being used as a public good in the ecosystem, with a clear service level agreement for the chosen vendor.

	Receipt	Action	Method	From		To	Value	Gas Limit

Detail Transaksi

Overview

Execution Plan

Enhanced Plan

Tree Plan

Receipt Summary

Comments