XRPL Smart Escrow SDK Preview Adds WASM Fields, but XLS-100 Is Still a Draft

What the August 12 pre-release actually changes

Direct answer: XRPLF's August 12, 2026 xrpl@5.1.0-smartescrow.1 pre-release moves Smart Escrow closer to a testable JavaScript client path by carrying proposed WASM bytecode, escrow data, gas, and execution-result fields. It does not activate XLS-100, create a stable xrpld release, open validator voting, or show production use on XRP Ledger Mainnet.

Confirmed fact: the official XRPLF release is explicitly marked Pre-release. Its published record is dated August 12, 2026, and it points to commit 3dc0ad5, which regenerates definitions from a ripple/se/supported server-definitions artifact and bumps the beta package version for the next Smart Escrow release. That makes the record a useful implementation milestone, not a network-status announcement.

The branch changes are concrete. The typed Escrow ledger model and EscrowCreate transaction model carry Bytecode and Data. EscrowFinish carries Gas, while transaction metadata models include GasUsed and VMReturnCode. The same generated definitions also expose Smart Escrow related result codes, including temBAD_WASM, tecOUT_OF_GAS, tefNO_BYTECODE, and tefBYTECODE_NOT_INCLUDED. These fields give a client library a vocabulary for a proposed execution path.

That vocabulary matters because developers need to serialize transactions and interpret failures before an application can test a new protocol feature. It does not prove that every field is accepted by a public server, that a validator can vote on the amendment today, or that a wallet can safely send a Smart Escrow transaction on Mainnet. The package label and release channel keep the evidence bounded.

Bounded inference: this is the clearest current public signal that Smart Escrow work is being carried into an XRPL client release path. Unresolved uncertainty: the release record does not state a launch date, final protocol parameters, audit completion, or an amendment activation plan. Those questions require separate primary records.

Section sources[1][2][3][4][5]

What XLS-100 would add to XRP Ledger escrow

XLS-100 describes Smart Escrows as escrows with a custom release function written in WebAssembly. Under the draft design, the code is attached when the escrow is created and runs when someone submits EscrowFinish. A positive return value would allow the finish operation, while a zero or negative return value would reject it. That is a programmable release condition layered onto an existing escrow lifecycle.

The draft also gives the code a narrowly defined data surface. A Smart Escrow function can read ledger objects and the transaction context, but it cannot write arbitrary ledger objects or emit another transaction. The attached Escrow Data field is the specified place for mutable state associated with that escrow. This distinction is important for safety and for application design: a release function is not a general-purpose smart contract.

Expiration remains a hard safety boundary. The XLS says a bytecode escrow must include CancelAfter so funds have a route back to the sender if the custom condition never succeeds. The design therefore combines three controls: code decides whether a finish is acceptable, gas bounds the work, and expiry limits how long funds can remain locked. The proposed shape is more specific than the phrase programmable escrow suggests.

The fee settings in the draft are parameters, not live Mainnet terms. XLS-100 proposes an initial GasLimit of 100,000, a BytecodeSizeLimit of 100,000 bytes, and a GasPrice of 1,000 micro-drops. Those values could change before implementation or activation. Readers should not turn them into a quoted production fee schedule.

The records reviewed show three different status layers rather than one launch switch:

Section sources[6][7][12][11][14][13]

Mainnet status: in development, not voting

The official Known Amendments page currently places SmartEscrow in the In Development section and links it to the XLS-100 documentation. The page says an amendment can become open for Mainnet voting if it is included in a stable server release. That condition has not been established by the August 12 JavaScript pre-release, which is explicitly labeled beta and pre-release.

I also checked the public s1.ripple.com JSON-RPC endpoint on August 16, 2026 at 11:06 UTC. Its server_info response identified rippled 3.3.0, Clio 2.7.1, and ledger 106331874. A feature response returned TokenEscrow as enabled and supported, but no SmartEscrow entry appeared in the filtered result. This is a dated node snapshot, not a universal census of the network.

The amendment process adds another gate. XRPL documentation says an amendment needs more than 80 percent validator support for two weeks after it is available in a stable server release before it can become enabled. A proposal, a generated client model, and a stable server release are therefore separate milestones. Calling the pre-release a Mainnet launch would collapse those distinctions.

Testing guidance points developers toward devnet, standalone networks, and private networks for amendment testing. A feature working on one of those networks would demonstrate testability, not production activation. The same rule applies to a local rippled build or a client package that can serialize fields: code availability is not consensus availability.

Independent context also helps prevent a naming error. XRPL Commons has used Smart Escrow in connection with the token escrow work associated with XLS-85, while XLS-100 defines a different WASM-based programmable escrow path. The shared label makes the feature identifier and source document more important than a headline that simply says Smart Escrow is live.

Section sources[8][11][9][10][14][13]

The security design is the product constraint

Smart Escrow's value depends on making a custom release rule useful without turning every escrow into an opaque program with unbounded cost. Ripple's prerelease documentation describes deterministic gas limits: when execution reaches the limit, the function stops and the transaction fails. The sender sets a maximum gas allowance, and the documentation says gas is translated to XRP and destroyed. The exact economics remain subject to the draft and implementation state.

The execution sandbox is deliberately narrow. The XLS-100 draft describes read access to ledger objects and transaction context, with no arbitrary ledger writes and no transaction emission. That limits side effects, but it also means an application cannot assume that a Smart Escrow function can perform the same actions as a general contract. Builders need to model the escrow state and any off-ledger orchestration around those boundaries.

The cancellation path is equally important. A condition that cannot be met should not leave XRP locked indefinitely, so the draft makes CancelAfter mandatory for bytecode escrows. In practical terms, expiry is not a decorative parameter. It is the recovery mechanism that defines what happens when code rejects every finish attempt, an oracle is unavailable, or an application disappears.

Failure reporting is part of the developer experience. The proposed model exposes distinct cases for missing bytecode, omitted bytecode on a finish, invalid WASM, rejected bytecode, and out-of-gas execution. GasUsed and VMReturnCode can help applications distinguish a user condition that returned false from an execution path that failed before the condition completed. That separation will matter for wallets, monitoring, and support tools.

RippleX Developers wrote in a December 18, 2025 security post that sandboxing, testing, and multiple audits were part of the Smart Escrow work at that publication date. That is useful supporting context, but it is not an audit certificate or a current security sign-off. Confirmed safety claims should wait for dated audit records, stable implementation notes, and reproducible test results.

Section sources[7][6][15][4][12]

Implications for developers, operators, and XRP holders

For XRPL developers, the immediate opportunity is test integration. The pre-release gives typed JavaScript consumers a place to represent Bytecode, Data, Gas, GasUsed, and VMReturnCode. A useful next step is to pin the exact beta version, build against the matching server definitions, and test rejection paths on a non-Mainnet network. The package should be treated as an experimental dependency, not silently promoted into a production wallet.

For application operators, the operational work is larger than adding one transaction field. A Smart Escrow service would need bytecode provenance, deterministic build records, expiry monitoring, gas budgeting, failure telemetry, and a recovery process for rejected finishes. Operators should also record the server version and amendment state used by each test. A successful local test without those controls would provide weak evidence about production readiness.

For XRP holders, this record does not establish an immediate change to XRP utility, demand, or price. Smart Escrow could eventually support more expressive settlement rules, but the sources reviewed do not report Mainnet activation, user counts, transaction growth, or a market outcome. The defensible conclusion is narrower: the protocol work has moved into a visible client preview while the network status remains developmental.

For token issuers and custody teams, the naming split matters. TokenEscrow and SmartEscrow can describe different protocol paths, with different prerequisites and risk assumptions. A product specification should cite XLS-85 or XLS-100 directly, state whether it needs XRP or issued-asset escrow, and avoid using a generic Smart Escrow label as proof that a particular feature is enabled.

For readers evaluating XRP Ledger infrastructure announcements, the lesson is to follow the evidence chain. Start with the server or standards record, check the amendment status, inspect the actual network feature response, and then look for independent reporting or security evidence. That method keeps a promising developer milestone from becoming an unsupported adoption or investment claim.

Section sources[1][2][10][8][12]

Uncertainty label: confirmed facts, bounded inference, unresolved questions

Confirmed facts: XRPLF published the xrpl@5.1.0-smartescrow.1 record as a pre-release on August 12, 2026. The linked commit updated generated definitions and beta versions, and the tagged models contain the Smart Escrow fields described above. XLS-100 is a draft, and the Known Amendments page lists SmartEscrow as In Development.

Bounded inference: the client-model changes indicate that developers are being given a more complete interface for testing the proposal. They do not, by themselves, prove that a stable rippled implementation is ready, that validators are voting, or that applications are using the feature in production.

Unresolved questions: the records reviewed do not establish a final gas schedule, final bytecode limits, a completed audit, a stable server release, a Mainnet amendment vote, or a live application deployment. The August 16 feature response is also one public node snapshot. Those gaps are not evidence of failure, but they are reasons to keep the headline and product claims conditional.

Section sources[1][2][6][8][11][13]

What to watch next

First, watch the official xrpl.js and rippled release records for a stable version that carries the corresponding definitions. A later beta is not enough by itself. The meaningful transition is a stable server release with clear Smart Escrow implementation notes and test coverage.

Second, watch the Known Amendments page and validator-facing amendment records for SmartEscrow to move from In Development into a voting state. If that happens, the amendment documentation will provide the relevant support threshold and activation window. Until then, a client preview remains a development signal.

Third, watch for dated audit reports, devnet or standalone test results, final parameter changes, and independent reports of real deployments. Those records would answer the remaining questions about code safety, cost, operational recovery, and actual usage more directly than a package changelog can.

Section sources[8][9][10][6][15][13]