XRPL Smart Escrow Devnet Reaches Ninth Test Release

XRPL Smart Escrow Devnet has reached its ninth release, bringing a new test-network address and changes to the WebAssembly runtime used to evaluate conditional escrow logic. The update gives developers another build to test, but it does not mean that programmable escrows are live on the XRP Ledger mainnet. The team says review, testing, and hardening are continuing, and the related XLS-0100 specification is still a draft.

In her ninth-release announcement, RippleX engineer Mayukha Vadari described the endpoint move, a migration of the WebAssembly integration from C++ to Rust, and a reported 30% to 50% speedup on host-function calls. The announcement also asks developers to move away from a deprecated all-in-one library and test with the newer package split.

For teams already working on Smart Escrow, the immediate task is a migration and retest, not a production rollout. For everyone else, the distinction is important: a more mature Devnet can help expose implementation problems, while a draft proposal still needs review and a formal route to mainnet.

Key Takeaways

• Smart Escrow Devnet has reached release nine and moved to new infrastructure; the earlier Devnet endpoints are retired.
• The update moves the WebAssembly integration from C++ to Rust and reports faster host-function calls, not a measured increase in XRP Ledger payment throughput.
• XLS-0100 proposes code-defined escrow release conditions, but the specification remains a draft and the feature is not live on mainnet.
• The draft requires a cancellation time for bytecode-based escrows, giving locked funds an expiry path if a condition cannot be met.

What release nine changes

The Smart Escrow Devnet has moved to a new host, wasm-devnet.dev.ripplex.io, while the older wasm.devnet.rippletest.net endpoints have been retired. A changed endpoint can sound like a small operational detail, but it matters to anyone running a test application: wallet configuration, node connections, scripts, and continuous-integration jobs may still point to the old address. Developers need to update their settings and confirm that their test transactions reach the new environment.

Endpoint migration is not a ledger upgrade

The address change applies to the Smart Escrow testing environment. It does not by itself alter the production XRP Ledger or activate a new transaction type on mainnet. That difference helps prevent a common misreading of developer-network announcements: new infrastructure can make experiments easier to run without changing what ordinary XRP holders or payment users can do on the live network.

Vadari’s release note says that the project remains in review and testing while the framework and code are hardened. That wording places release nine in the development process, where compatibility issues, runtime behavior, and developer tooling can still change. The new Devnet is a shared place to test those components together; it is not proof that every proposed feature has passed an independent audit or a mainnet vote.

A runtime change with a narrow performance claim

The release moves the WebAssembly integration from C++ to Rust and brings gas accounting, error handling, and validation checks through a single entry point. Vadari reports a 30% to 50% speedup on host-function calls. That is a specific implementation measurement. It should not be rewritten as a 30% to 50% increase in total network capacity, faster XRP transfers, or lower fees for all users. The announcement does not make those broader claims.

The changelog also lists renamed host functions and fields, a new floating-point format, an upgrade to Wasmi 2.0, and additional fixes. Taken together, the list signals ongoing engineering work inside the test runtime. Developers should treat the release number as a version marker for testing, not as a guarantee that an application compiled against an earlier build will behave identically on the new one.

What XRPL Smart Escrow proposes

XRPL escrows already support release rules such as a specified time or a cryptographic condition. XLS-0100 proposes adding a small WebAssembly program to an escrow so that the program can evaluate a custom rule when someone tries to finish it. The bytecode would be attached when an escrow is created and executed as part of an escrow-finish transaction.

That model could support use cases where a basic time lock or hash condition is not expressive enough. A developer might want a release to depend on a named approval, a verified milestone, or several checks that must all succeed. The draft describes examples including notary approval, compliance holds, milestone rewards, and oracle-driven arrangements. Those are proposed applications, not evidence that the feature is already available for public XRPL transactions.

The specification also makes an important distinction between combining conditions and choosing among them. When multiple finish conditions are present, the draft says they must all be true. This is an AND-style rule, not a menu where any one condition can independently release the funds. Applications therefore need to encode the intended logic carefully and test both successful and unsuccessful paths.

Release detail	What the update says	What it does not establish
Devnet status	Release nine is in review, testing, and hardening.	It does not mean Smart Escrow is active on mainnet.
Network address	The Devnet moved to a new host and the old endpoints were retired.	It is a test-environment migration, not a production-ledger upgrade.
WebAssembly runtime	The integration moved from C++ to Rust; host-function calls are reported 30% to 50% faster.	It is not a claim about overall transaction throughput or user fees.
Developer libraries	The all-in-one package is deprecated in favor of separate common and escrow-focused libraries.	Apps still need migration work and retesting against the new Devnet.

Guardrails and fund safety

Programmable conditions touch funds, so the safety model matters as much as the feature list. The draft describes a restricted execution environment with limits on computation and data. It is designed so that validators can reach a consistent result, while the bytecode cannot freely write to unrelated ledger objects or emit new transactions. These restrictions aim to keep the program narrow: decide whether the specified escrow may finish, rather than behave like an unrestricted application running on the ledger.

One explicit safeguard in XLS-0100 is a required CancelAfter time for an escrow that contains bytecode. If the release condition never becomes true, a counterparty stops responding, or a program has an error, the expiration gives the escrow a way to be cancelled under the ledger’s rules. The draft says this requirement is intended to protect users in an initial release; any future relaxation would be a separate design decision.

The specification’s security section says implementation testing and security audits are expected. That is a statement about work that must be done, not confirmation that all audits are complete. Likewise, a successful test on Devnet can reveal bugs and improve confidence, but cannot eliminate the risks of code, changing specifications, or user error. Developers should test expiry behavior, rejected finishes, insufficient gas, and malformed inputs, rather than only demonstrating the happy path.

What developers should test

Release nine changes both the environment and parts of the toolchain. The developer note says the former all-in-one xrpl-wasm-stdlib package is deprecated and that the libraries are now separated into xrpl-escrow-stdlib and xrpl-common-stdlib. Teams should update dependencies, rebuild their bytecode, and check that their transaction tooling understands the current Devnet format. A program that compiles locally still has to match the network’s accepted fields, host functions, and runtime behavior.

A practical migration checklist

• Replace retired Devnet endpoints in local configuration, scripts, and automated tests.
• Move off deprecated library packages and review the split between escrow-specific and shared helpers.
• Run tests for both a permitted escrow finish and a rejected finish, including error and gas-limit cases.
• Verify that expiration and cancellation work when custom conditions are not met.
• Compare results across repeated runs to catch nondeterministic behavior or assumptions about the former runtime.

These checks matter because release nine includes changes to function names, validation paths, and runtime integration. Retesting is not just a formality after a package rename; it helps reveal whether the application, compiled code, transaction builder, and shared network agree on the same rules.

Why mainnet status is still open

XLS-0100 is labeled Draft and describes Smart Escrow as an amendment proposal. Its text says the feature would require a formal amendment. That means the route to a live feature includes more than publishing a Devnet build: the proposal, implementation, security work, and community or validator process would still need to advance. The available release note does not announce a mainnet activation date.

The careful way to read the milestone is therefore two-part. The test environment is becoming more usable for developers, and some runtime work has produced measurable improvements in host-function calls. At the same time, Smart Escrow remains a proposal whose final rules, review outcome, and mainnet path may change. Anyone describing the feature should keep those two facts together instead of treating Devnet progress as a public launch.

For users who are not building on the test network, there is no new Smart Escrow action to take on mainnet based on this release alone. For developers, the value is earlier feedback: they can test custom release logic and find problems before any possible activation decision. Whether the proposal moves forward will depend on the quality of that testing and the broader amendment process, not just on a higher Devnet release number.

Frequently asked questions

Is Smart Escrow live on the XRP Ledger mainnet?

No. Release nine updates a developer test network. XLS-0100 is still marked Draft, and the proposal says a formal amendment would be required for a live feature.

What is new in the ninth Smart Escrow Devnet release?

The release moves the Devnet to new infrastructure, retires its old endpoints, migrates the WebAssembly integration from C++ to Rust, and updates the developer libraries. The release note reports a 30% to 50% speedup on host-function calls.

Does the speedup mean XRP payments are 30% to 50% faster?

No. The reported figure concerns host-function calls in the Smart Escrow runtime. It is not a measurement of overall XRP Ledger payment speed, network capacity, or fees.

What happens if a Smart Escrow condition is never met?

Under the draft, a bytecode-based escrow must include a CancelAfter time. This gives the escrow an expiration path if the custom release condition does not succeed. The feature and its details remain subject to change before any possible mainnet activation.

Do developers need to update their test applications?

Yes, if they depend on the retired endpoints or the deprecated all-in-one library. The release note asks developers to move to the newer package split and retest their applications against the updated Devnet.

Conclusion

Smart Escrow Devnet’s ninth release is a meaningful engineering step for teams testing code-controlled escrow conditions. It brings a new endpoint, a Rust-based WebAssembly integration, updated libraries, and a reported improvement in host-function-call speed. The strongest reading is also the most limited: these are Devnet changes, not a mainnet launch or a claim about faster payments.

XLS-0100 remains a draft proposal, and its mandatory cancellation time reflects one of the central user-safety questions for programmable locks. Developers can use the new environment to test migration, execution, and failure cases, while users should wait for formal protocol progress before treating Smart Escrow as a live XRPL feature.

Read More News

Follow more digital-asset and market coverage on the VORTFLUX News homepage.

Disclaimer

This VORTFLUX article provides general information, not personalized financial, investment, legal, or tax advice. Crypto prices can change quickly, and you could lose all invested funds. Facts reflect the material available when published and may change. Check important information independently and consult a qualified professional when needed. Mentioning an asset, company, or service is not an endorsement.