2025 Algorand Relay Program

Introduction

As Algorand progresses towards implementing a peer-to-peer gossip protocol, the Relay Program is undergoing a significant directional shift. Traditionally, Algorand nodes require relays for intercommunication, embodying a classic hub and spoke model. The forthcoming peer-to-peer architecture, however, will facilitate direct communication between nodes, rendering the use of relays less critical, though they will remain operational for specific use cases.

Future Role of Relays

While relays will continue to play a role, their usage is expected to diminish. They will be particularly vital for users prioritising speed, functioning akin to an express pass. Anticipating the reduced demand post peer-to-peer implementation, the number of relays will accordingly be adjusted.

Request for Proposals (RFP) for Program Participation

We are initiating the RFP process for potential participants, focusing on two types of node providers:

Non-archival Relays:

  • 16vCPU
  • 32GB RAM
  • 256 GB NVMe SSD disk
  • 100 TB/month egress
  • 1 Gbps low-latency connection

Archival Non-Relay Nodes (gossip services disabled):

  • 8vCPU
  • 16GB RAM
  • 4TB SSD disk (for blocks and catchpoint storage, referred to as “ColdDataDir” in our configuration)
  • 100 GB NVMe SSD disk (for “hot, performance-critical data”)
  • 10 TB/month egress
  • 1 Gbps low-latency connection

The term of the program would be beginning the 1st of April 2025 lasting to 31st of March 2026.

Selection Criteria

In evaluating proposals for the Algorand Relay Program, the Foundation will prioritise the following key factors:

Cost Efficiency: Proposals will be assessed for their cost-effectiveness, ensuring optimal utilisation of resources.

Geographical Distribution: The geographical location of nodes is critical. A globally distributed network of nodes is sought to enhance the resilience and reliability of the network.

Hosting Provider Preferences: A preference is given to self-hosted setups or smaller cloud providers and data centers. This approach is intended to reduce dependence on major cloud service providers like AWS, Azure, and GCP, thereby mitigating potential risks from policy changes that could affect network operations.

Payment in ALGO Tokens: The Foundation favours arrangements where providers accept payments in ALGO tokens, calculated based on a 30-day trailing average. While this is preferred, it is understood that such an arrangement may not be feasible with all providers.

The Foundation is committed to fostering a robust and decentralised network, and these criteria are designed to ensure the selection of partners who align with this vision and can contribute effectively to the network’s stability and growth.

Quality and Performance Expectations

Node quality and performance should consistently meet our specified requirements. The contractual agreement will outline minimum operational expectations. Failure to adhere to these standards may result in expulsion from the program.

Submission Guidelines

Prospective participants are hereby invited to submit detailed proposals outlining the cost structure for each relay node, segmented by region. Submissions should comprehensively detail the financial implications, including any potential discounts for managing multiple relay nodes.

Submission Process

Proposals may be submitted via the designated Google Form or, alternatively, directly via email to shane.mcgovern@algorand.foundation. We encourage early submissions to facilitate thorough evaluation and allow time for any necessary clarifications or inquiries regarding the proposals.

Deadline for Submissions

The final date for accepting submissions will be February 24th, 2025. Prompt submissions are encouraged to ensure adequate time for review and discussion.

3 Likes

Id love to host a relay node except the whole threat of an expulsion looming, what if most relays get expelled, will you be allowing new relays to start up? How often would the relay count change and be brought back to standard?
Any figures for the amount of relays needed to make this possible, including back ups?

1 Like

Expulsion from the program is rare but it’s something that can happen with poor performance. However , most individuals we accept would have a professional level of service offered.

what if most relays get expelled, will you be allowing new relays to start up?

It would be a bizarre scenario but in that case we’d either reach back out to participants who didn’t get selected or amend contracts for existing people to increase the relay count.

How often would the relay count change and be brought back to standard?

It’s very static with rare changes , I think you’re vastly over estimating the churn of participants

How often would the relay count change and be brought back to standard?

Numbers for last year were roughly 75 relays and 20 archival nodes for mainnet. No absolute figures have been decided for this year yet but we’re cautious of decreasing it too much.

3 Likes

Vital for speed in what, inclusion into a block first or getting txns to all nodes quickly. Does it p2p txns won’t get into blocks as quickly as relayed txns