XRP Ledger 1.2.0 added censorship alerts and prepared three amendments

Ripple released version 1.2.0 of `rippled`, the reference server software for the XRP Ledger, on February 13, 2019. The upgrade added automated warnings for transactions that appeared to be omitted repeatedly during consensus and introduced code for three proposed amendments affecting multisignature accounts and the ledger’s built-in decentralized exchange.

The release mattered because it combined an immediately available operational upgrade with protocol changes that still required validator approval. Installing version 1.2.0 did not, by itself, activate the amendments or prove that censorship had occurred. It gave server operators new monitoring capabilities and prepared compatible nodes for rules that could take effect later.

A detector, not proof of censorship

The new censorship-detection feature tracked transactions that a server had included in its initial consensus proposal. If one of those transactions remained absent from validated ledgers over several consensus rounds, the server could issue warnings of increasing severity.

That distinction is important. A warning identified behavior that warranted investigation; it did not establish malicious suppression. Network desynchronization, inconsistent transaction relay or software differences could also produce an apparent omission. The feature therefore improved observability around consensus without guaranteeing that every alert represented an attack.

The published change log also included an enhanced server-crawl endpoint, a new shard-crawl command, support for Ed25519 seeds encoded through `ripple-lib`, configuration changes and several memory, validation-list and error-handling fixes.

Three amendments awaited consensus

The most visible proposed change, `MultiSignReserve`, reduced the XRP reserve burden associated with maintaining a signer list. That could make multisignature security less costly for accounts using multiple authorized signers, although the release announcement did not claim a particular adoption rate or quantify aggregate savings.

Two other amendments addressed offer processing in the XRP Ledger’s decentralized exchange. `fixTakerDryOfferRemoval` targeted “dry” offers that were not removed correctly during autobridging. `fix1578` changed how certain unsuccessful offer and payment transactions were handled, allowing specified failures to remove an offer rather than leaving it on the ledger.

These were proposed consensus rules, not active rules on February 13, 2019. Ripple said they were expected to become eligible for activation no earlier than February 27, 2019. Operators running older software could become amendment-blocked if the network later enabled an unsupported amendment, leaving their servers unable to validate ledgers, process transactions or participate in consensus.

An operational deadline

Ripple instructed operators to upgrade by February 27, 2019. Its technical operations team also planned to begin deploying version 1.2.0 to Ripple-controlled servers and private clusters at 2:00 p.m. Pacific time on February 13, with completion expected within four hours and no anticipated outage. The announcement documented that deployment plan; it did not independently verify completion across every server or validator on the network.

The source history identified commit `7779dcdda00ea61a976cf5f387bc1f3bb4ebbfdd` as setting the software version to 1.2.0. Ripple also published SHA-256 checksums for its binary and source RPM packages, giving operators a way to verify downloaded artifacts.

Market response was inconclusive

Kraken’s February 13 daily report listed XRP at $0.3002, down 1.25%, with $4.14 million traded in the exchange’s XRP markets. The same report showed $62.9 million of total activity across Kraken’s listed markets.

Those figures describe one venue’s daily report, not the global XRP market. Kraken did not establish in that report that the software release caused the price change, and the release supplied no adoption or transaction data from which to calculate an immediate economic effect. The defensible event-day conclusion was narrower: version 1.2.0 materially changed node software and prepared consensus amendments, while its network-wide consequences remained conditional on operator upgrades and validator support.