XRP Ledger Batch Transactions Move Toward Validator Vote Within Two Weeks

• Vet said XRPL feature amendments could reach validator voting in roughly two weeks.
• Proposed features include confidential transfers, sponsored costs, and permission delegation.
• Node upgrades could reduce memory use by 10% to 40% and lower synchronization risks.

XRP Ledger validators could soon consider a broad package of protocol changes, including Batch transactions and confidential transfers. XRPL validator Vet said voting may begin in roughly two weeks if development proceeds as planned.

Proposed amendments also cover sponsored fees and reserves, permission delegation, dynamic MPT functionality, and a bundled software fix. The vet also reported memory reductions and changes designed to help nodes stay synchronized.

XRP Ledger Amendments Move Toward Voting

The vet said the proposed features could reach XRP Ledger voting within about two weeks. Each amendment still requires validator support before activation.

XRPL’s amendment process requires more than 80% support from trusted validators for two consecutive weeks. Activation timing therefore depends on validator decisions after voting opens.

Confidential transfers would hide individual multi-purpose token balances and transfer amounts. Validators could still verify issuance limits without viewing confidential account balances. Sponsored Fees and Reserves would allow one account to cover another account’s transaction fees or reserve requirements. Sponsors could co-sign transactions or pre-fund selected costs.

Permission delegation would let account owners assign selected transaction rights to another account. Owners could separate tasks without sharing control of their primary keys. Dynamic MPT would allow issuers to update selected token fields after creation. Issuers must mark those fields as changeable when creating the token.

The vet also listed performance changes for node operators. Memory use could fall by 40% on some machines under best-case conditions. He placed expected reductions at between 10% and 15% on other systems. Additional changes aim to reduce synchronization failures for nodes and validators.

Batch Transactions Combine Eight Operations

Notably, Batch transactions package up to eight operations inside one outer transaction. Users can include transactions from one account or several accounts. XRPL processes each batch through one of four modes. ALLORNOTHING requires every inner transaction to succeed before any operation applies.

ONLYONE accepts the first successful transaction while rejecting or skipping the others. UNTILFAILURE processes transactions until the first unsuccessful operation. 

INDEPENDENT processes every inner transaction, even when some operations fail. Each mode gives developers a different execution structure. Developers could mint an NFT and create its sale offer through one ALLORNOTHING batch. Failure during offer creation would also reverse the mint.

Users could submit several offers with different slippage levels through ONLYONE mode. Only the first valid offer would complete.

Other uses include bundled platform fees, multi-account token swaps, NFT exchanges, and withdrawals from alternative accounts. Batch processing combines these actions within one submitted package.

Related: Bitget Partners With Siebly.io to Simplify Algorithmic Trading Development

Batch Fees and Signatures Require Extra Checks

Meanwhile, Inner transactions carry zero fees and no separate signatures. Relevant parties instead authorize the full collection through the outer Batch transaction. Multi-account batches require approval from every account represented inside the package. This prevents one participant from changing the agreed inner transactions.

Outer fees include twice the base fee, all inner transaction costs, and charges for additional signatures. XRPL calculates fee escalation using the complete batch cost. committed inner transaction receives separate ledger metadata. A ParentBatchID field connects each inner operation to its outer transaction.

Even so, Outer transactions can return teSUCCESS even when an inner transaction fails. Wallets and applications must inspect each inner result separately. XRPL also rejects inner transactions submitted outside its batch wrapper. The tfInnerBatchTxn flag identifies unsigned inner operations and blocks normal submission.