Activating an amendment on XRPL is not an isolated event occurring on a single node. It is a complex coordination process involving hundreds of geographically distributed nodes, dozens of independent validators, and numerous operators who must synchronize their actions.
This coordination is essential to ensure the network remains consistent and functional during the transition. Failed coordination could lead to network partition, incompatible ledgers, or temporary loss of consensus.
In this section, we explore the coordination mechanisms, communication strategies, deployment plans, and contingency protocols that allow XRPL to activate amendments safely and in a coordinated manner.
Communication via the Overlay Network
Validation Propagation
The primary coordination mechanism for amendments is the propagation of validations across the overlay network.
Network structure:
┌─────────┐ ┌─────────┐ ┌─────────┐
│Validator│◄───────►│ Node │◄───────►│Validator│
│ A │ │ Relay │ │ B │
└─────────┘ └─────────┘ └─────────┘
│ │ │
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Node │ │Validator│ │ Node │
│ API │ │ C │ │ Full │
└─────────┘ └─────────┘ └─────────┘
Propagation flow:
A validator publishes a validation containing its list of supported amendments
The validation is broadcast to all connected peers
Each peer propagates the validation to its own peers (flood protocol)
Within seconds, all nodes in the network have received the validation
Each node extracts the amendment list and updates its counters
Validation Broadcast Protocol
Validations are broadcast via XRPL's Peer Protocol:
TMValidation Message:
Processing by receiving node:
Squelching and Optimization
To avoid message flooding, the overlay network uses a squelching mechanism:
Principle: A node only propagates a message if it hasn't seen it yet
Entry expiration: Squelching entries expire after a few minutes to free memory.
Deployment Strategies
Phase 1: Pre-Release Communication
6-8 weeks before release: Public announcement of the proposed amendment
Publication of an XLS (XRPL Standard) detailing the amendment
Public code review on GitHub
Discussions on community forums
Technical webinars and presentations
Communication channels:
XRPL.org blog
GitHub (XLS repository)
XRPL Dev Forum
Discord XRPL Developers
Official Twitter/X
Phase 2: Code Release
Objective: Distribute code before voting begins
Typical timeline:
T+0: Release of rippled with the new amendment (e.g., 1.12.0)
T+1 week: First non-validator nodes update
T+2 weeks: ~30% of nodes updated
T+4 weeks: ~60% of nodes updated
Progressive deployment strategy:
Phase 3: Vote Activation
Communication to validators:
Validators receive notifications to activate their vote:
void PeerImp::onValidation(
std::shared_ptr<protocol::TMValidation> const& m)
{
// Deserialize the validation
auto validation = std::make_shared<STValidation>(
SerialIter{m->validation().data(), m->validation().size()},
[](PublicKey const& pk) { return calcNodeID(pk); });
// Verify signature
if (!validation->isValid())
return;
// Extract amendments
auto const amendments = validation->getAmendments();
// Pass to validation handler
app_.getValidations().addValidation(validation);
// Relay to other peers (except sender)
overlay_.relay(m, validation->getNodeID());
}
bool Overlay::relay(
std::shared_ptr<Message> const& m,
NodeID const& source)
{
// Calculate message hash
auto const hash = sha512Half(m->SerializeAsString());
std::lock_guard lock(squelchMutex_);
// Check if already seen
if (squelchedMessages_.count(hash))
return false; // Don't propagate
// Mark as seen
squelchedMessages_.insert(hash);
// Propagate to all peers except source
for (auto const& peer : peers_) {
if (peer->getNodeID() != source)
peer->send(m);
}
return true;
}
┌──────────────────────────────────────────────────────────┐
│ Week 1: Testnet and internal nodes │
│ ✓ Validation on Testnet/Devnet │
│ ✓ Internal test nodes │
└──────────────────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Week 2-3: API and non-validator nodes │
│ ✓ Fullhistory nodes │
│ ✓ Public API nodes │
│ ✓ Exchanges and wallets (infrastructure) │
└──────────────────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Week 4-6: Validators │
│ ✓ Validators begin voting │
│ ✓ Intensive monitoring │
└──────────────────────────────────────────────────────────┘
# Email/notification to validator operators
Subject: Ready to vote for Subscriptions amendment
The Subscriptions amendment (XLS-0078) is ready for voting.
Release: rippled 1.12.0
Amendment hash: 7B73B9E8D8E6E8E8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8
To activate your vote:
rippled feature 7B73B9E8D8E6E8E8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8 accept
Or add to rippled.cfg:
[amendments]
7B73B9E8D8E6E8E8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8A8B8C8D8E8F8
[WARNING] Amendment 7B73B9E8... (Subscriptions) has reached majority.
It will activate in approximately 14 days (on 2025-05-04 14:32:15 UTC).
If your node does not support this amendment, please upgrade to rippled 1.12.0 or later immediately.
Current version: 1.11.0
Amendment support: NO
Upgrade urgency: CRITICAL
void NetworkOPsImp::checkAmendmentStatus() {
auto const expected = app_.getAmendmentTable().firstUnsupportedExpected();
if (expected) {
auto const now = app_.timeKeeper().closeTime();
auto const timeUntil = *expected - now;
if (timeUntil < 24h) {
// CRITICAL: Less than 24h
JLOG(j_.fatal())
<< "CRITICAL: Unsupported amendment will activate in "
<< timeUntil.count() << " seconds. UPGRADE NOW!";
// Send alert to operator
sendOperatorAlert("CRITICAL_AMENDMENT_WARNING");
}
else if (timeUntil < 7days) {
// ERROR: Less than a week
JLOG(j_.error())
<< "ERROR: Unsupported amendment will activate in "
<< std::chrono::duration_cast<std::chrono::days>(timeUntil).count()
<< " days. Please upgrade soon.";
}
else if (timeUntil < 14days) {
// WARNING: In majority window
JLOG(j_.warn())
<< "WARNING: Unsupported amendment will activate in "
<< std::chrono::duration_cast<std::chrono::days>(timeUntil).count()
<< " days.";
}
}
}
// Option 1: Withdraw vote to delay activation
rippled feature 7B73B9E8... reject
// Option 2: Temporarily withdraw from UNL
// (requires coordination with other validators)
[URGENT] Issue detected with Subscriptions amendment.
Potential impact: [description]
Recommendation: All validators please REJECT the amendment immediately.
Command:
rippled feature 7B73B9E8... reject
// In doApply(), add temporary guard
TER RecurringPaymentClaim::doApply() {
// EMERGENCY FIX: Disable temporarily until proper fix
if (view().info().seq < EMERGENCY_DISABLE_LEDGER) {
return tecDISABLED;
}
// Normal logic...
}
# Version 2.8.0
class TransactionType(str, Enum):
# ... existing types
SUBSCRIPTION_SET = "SubscriptionSet"
SUBSCRIPTION_CLAIM = "SubscriptionClaim"
SUBSCRIPTION_CANCEL = "SubscriptionCancel"
# Subscriptions Amendment Activated
Date: 2025-05-04 14:32:15 UTC
Ledger: 86652345
The Subscriptions amendment (XLS-0078) has been successfully activated on the XRPL Mainnet.
## What's New:
- New transaction types: SubscriptionSet, SubscriptionClaim, SubscriptionCancel
- New ledger object: ltSUBSCRIPTION (0x0055)
- Programmable recurring payment subscriptions with XRP, IOUs, and MPTs
## For Developers:
- Update to rippled 1.12.0+
- Update xrpl.js to 2.12.0+
- Update xrpl-py to 2.8.0+
## Documentation:
- [Subscriptions Standard (XLS-0078)](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0078-subscriptions)
- [API Reference](https://xrpl.org/api-reference.html)
