DEV Community: Denis Angell

Smart Contracts on XRPL's AlphaNet

Denis Angell — Fri, 07 Nov 2025 17:06:33 +0000

The XRP Ledger Smart Contracts feature is now available for developers to explore and test on AlphaNet, a dedicated development network. This groundbreaking implementation brings native Layer 1 smart contract capabilities to the XRPL, combining the familiar design patterns of EVM-style contracts with the power of XRPL's native features and transactions.

Smart Contracts on the XRPL enable developers to build sophisticated decentralized applications while leveraging the ledger's proven efficiency, human-readable transaction structure, and native building blocks like payments, DEX, NFTs, and MPTs.

What Are XRPL Smart Contracts?

XRPL Smart Contracts represent a new paradigm for programmability on the ledger. Unlike traditional approaches, this design provides:

Permissionless deployment - No UNL approval required to deploy contracts
Native XRPL integration - Direct access to all XRPL features and primitives
Familiar development patterns - EVM-inspired design with functions and parameters
WebAssembly (WASM) runtime - Efficient execution with support for multiple programming languages On-chain ABIs - Human-readable interface definitions stored directly on the ledger
Event emission - Subscribe to contract events for real-time updates

Smart contracts live on pseudo-accounts and are triggered via the new ContractCall transaction type. Contracts can maintain their own state, interact with other XRPL features by submitting transactions, and emit events that applications can subscribe to.

Connect to AlphaNet

Developers can now connect to AlphaNet to begin testing Smart Contracts:

Network Details:

Name: AlphaNet
RPC URL: https://alphanet.rpc.nerdnest.xyz
WSS URL: wss://alphanet.nerdnest.xyz
Network identifier: 21465
Digital Asset: XRP
Explorer URL: https://explorer.xrplf.org/wss:alphanet.nerdnest.xyz
Faucet URL: https://alphanet.faucet.nerdnest.xyz/accounts
SDK: yarn add @transia/xrpl

Replit

An example testing the base on the contract on alphanet can be seen in this replit: https://replit.com/@DenisAngell/SmartContracts. Keep coming back for more updates.

Key Features

New Transaction Types

ContractCreate - Deploy a new smart contract with optional initialization (Transfer Funds, Transfer NFT, Authorize)
ContractCall - Execute a contract function with specified parameters
ContractModify - Update contract properties (if permitted)
ContractDelete - Remove a contract from the ledger
ContractUserDelete - (NOT IMPLEMENTED) Allow users to reclaim reserves from contract data
ContractClawback - (NOT IMPLEMENTED) Enable token issuers to claw back from contracts

New Ledger Entries

ContractSource - Stores contract bytecode (deduplicated across deployments)
Contract - Represents a deployed contract instance
ContractData - Stores contract-specific state data

Sample Use Cases

Smart Contracts on the XRPL unlock numerous possibilities:

Cross-chain bridges - Integration with new bridging protocols
DeFi protocols - Derivatives, perpetuals, and advanced trading systems
Token utilities - Staking rewards for issued tokens
Governance systems - On-chain voting and proposal mechanisms
Gaming - Decentralized game logic and asset management
Marketplace logic - Custom rules for NFT marketplaces

Contract Examples:

https://github.com/Transia-RnD/craft-toolkit-ts/tree/main/contracts

Architecture Overview

Smart Contracts follow a clear architectural model:

Deploy - Use ContractCreate to deploy WASM bytecode to a pseudo-account
Call - Trigger contract functions via ContractCall transactions
Interact - Contracts emit XRPL transactions to interact with native features
Monitor - Subscribe to events or query contract history via RPC

The pseudo-account model ensures contracts cannot be controlled by any private key, providing security and predictability.

Core Smart Contract Components

Smart Contracts on the XRPL are built around four fundamental components that provide flexibility and power to developers:

1. Parameters: Instance & Function

Instance Parameters
Instance parameters act like environment variables for your contract. They allow you to configure contract behavior without modifying the source code, making contracts more reusable and flexible.

Defined at the ContractSource level
Set during contract deployment via ContractCreate
Analogous to environment variables or configuration settings
Allow the same contract code to be deployed multiple times with different configurations
Example: API endpoints, fee percentages, admin addresses

Function Parameters
Function parameters define the inputs for each callable contract function, creating a strongly-typed interface.

All parameter types must be valid XRPL serialized types (STAmount, STAccount, STUInt32, etc.)
Maximum of 4 parameters per function (expandable in future versions)
All parameters are required - no optional parameters or overloading
Parameters (Instance & Function) can have special flags for moving funds:
- tfSendAmount - Automatically transfers the specified amount from caller to contract
- tfSendNFToken - Transfers an NFToken to the contract
- tfAuthorizeToken - Provides token authorization

The combination of instance and function parameters creates a clean, type-safe interface that's both human-readable and programmatically verifiable.

2. Data: Storage and State Management

Smart Contracts have powerful data storage capabilities with support for simple and complex data structures:

Basic Get/Set Operations
Store and retrieve simple key-value data for contract state management.

Nested Data Structures
Contracts can store and retrieve nested objects, enabling complex state management. For example, you can store user profiles with multiple nested properties, or maintain hierarchical data structures within your contract.

Array Operations
Full support for array-based storage with index-based access. Store ordered collections and access elements by their position, including support for nested arrays within your data structures.

Storage Types

Contract-level data - Global state accessible across all function calls
Per-user data - Isolated storage for each user interacting with the contract
Nested structures - Complex objects with multiple levels of nesting
Arrays - Ordered collections with index-based access

All data is stored using XRPL's native serialized types, ensuring efficiency and compatibility with the broader ledger ecosystem.

3. Emit: Transaction Emission

One of the most powerful features of XRPL Smart Contracts is the ability to emit XRPL transactions directly from contract code. This allows contracts to interact with all native XRPL features:

How It Works
Contracts can construct and submit transactions as if they were coming from the contract's pseudo-account. These transactions are validated and processed just like any other XRPL transaction.

Supported Transaction Types
Contracts can emit virtually any XRPL transaction:

Payment - Send XRP, tokens, or MPTs
TrustSet - Establish trust lines
OfferCreate - Create DEX orders
NFTokenMint - Create NFTs
EscrowCreate/EscrowFinish - Use escrow functionality
AccountSet - Modify account settings
And many more...

Example Use Cases

Automated Payments - Contract triggers payments based on conditions
DEX Integration - Create or cancel offers programmatically
Token Management - Mint or burn tokens in response to contract logic
Multi-step Operations - Chain multiple transactions together
Cross-feature Integration - Combine payments, escrows, and NFTs in complex workflows

Fee Handling
Fees for emitted transactions are included in the ContractCall transaction fee, making cost calculation transparent for users.

This emission model preserves the XRPL's human-readable transaction structure while giving contracts full access to the ledger's native capabilities.

4. Events: Event Emission and Subscriptions

Smart Contracts can emit custom events that applications and users can subscribe to, enabling real-time notifications and monitoring:

Event Emission
Contracts can emit events at any point during execution to signal important state changes or actions:

Custom event names and data payloads
Multiple events per contract call
Indexed for efficient querying
Stored in ledger history

Event Subscriptions
The new eventEmitted subscription allows applications to:

Listen for events from specific contracts
Filter by event type or parameters
Receive real-time notifications
Build reactive applications

Event History
The event_history RPC method provides:

Historical event queries
Filter by contract, time range, or event type
Pagination support for large result sets
Complete audit trail of contract activity

Common Use Cases

Price Updates - Oracles emit new price data
State Changes - Notify when important thresholds are crossed
User Actions - Track deposits, withdrawals, or trades
Governance - Signal proposal creation or voting completion
Monitoring - Alert systems can watch for specific conditions

Events make it easy to build responsive dApps that react to on-chain contract activity without constant polling, while maintaining a complete historical record.

Getting Started

Set up your development environment
- Access the Web IDE at https://ide.alphanet.nerdnest.xyz
- Or set up local development with the Rust toolchain and WASM target (https://github.com/Transia-RnD/xrpl-wasm-std/tree/main)
Fund your test account
- Use the AlphaNet faucet to receive test XRP
- Reserve requirements apply for contract deployment
Write your first contract
- Define contract functions with typed parameters
- Use the XRPL API to interact with ledger state
- Emit transactions to modify the ledger
Deploy and test
- Submit a ContractCreate transaction
- Call your contract functions via ContractCall
- Monitor events and transaction results

Example: Basic Contract Structure

#![cfg_attr(target_arch = "wasm32", no_std)]

use xrpl_wasm_std::host::trace::trace;
use xrpl_wasm_std::core::data::codec::{get_data, set_data};

#[unsafe(no_mangle)]
pub extern "C" fn my_function() -> i32 {
    // Your contract logic here
    let _ = trace("Function called");

    0 // Success
}

Resources and Support

XLS Specification: https://github.com/mvadari/XRPL-Standards/blob/06562e3faa2b4a51e4bcbaad6e582222b517da27/XLS-0101-smart-contracts/README.md
WasmSTD (Rust): https://github.com/ripple/xrpl-wasm-std
WasmSTD Building Guide: https://github.com/Transia-RnD/xrpl-wasm-std/blob/main/docs/comprehensive-guide.md
XRPL Developer Discord: https://discord.gg/fFmZ3Fd8

Join the Future of XRPL Development

Smart Contracts represent a major evolution for the XRP Ledger, enabling developers to build the next generation of decentralized applications while preserving everything that makes XRPL special: efficiency, reliability, and simplicity.

Start building today on AlphaNet and help shape the future of programmability on the XRPL. Your feedback and contributions during this testing phase are invaluable to ensuring a robust, production-ready implementation.

Connect. Build. Innovate.

Questions, feedback, or need help getting started? Join us in the XRPL Developer Discord or reach out directly. Let's build something amazing together.

XRPL Token Escrow: Features, Benefits, and Getting Started

Denis Angell — Wed, 25 Jun 2025 09:02:20 +0000

Token Escrow (XLS-85) is a new feature that will extend XRPL’s existing escrow functionality to support both Trustline-based tokens (IOUs) and Multi-Purpose Tokens (MPTs). It will enable XRPL to hold any token in escrow, meaning they can be locked up and released only when certain conditions are met.

This is important because currently, XRP is the only asset that can use the Escrow feature. Token Escrow will increase the versatility of token operations on XRPL, allowing for more complex and secure transactions involving different types of tokens while respecting issuer controls and maintaining the integrity of the Ledger.

Key Feature Highlights

Expanded Asset Support: Enables escrow functionality for both Trustline-based tokens (IOUs) and Multi-Purpose Tokens (MPTs), not just XRP.
Dedicated Transaction Modifications:
- EscrowCreate: Allows specifying the token type and amount (IOU or MPT) to be held.
- EscrowFinish: Facilitates the conditional release of the escrowed tokens to the designated recipient.
- EscrowCancel: Allows for the return of escrowed tokens to the sender if conditions for release are not met or the escrow expires.
Respect for Issuer Controls: Integrates with existing token issuer settings, such as:
- Authorization requirements (e.g., lsfRequireAuth for IOUs, tfMPTRequireAuth for MPTs).
- Freeze conditions for IOUs (lsfGlobalFreeze, lsfDefaultRipple) and Lock conditions for MPTs (lsfMPTokenLock).
- Transferability flags for MPTs (tfMPTCanTransfer, tfMPTCanEscrow).
Consistent Fee Handling: Captures and locks the TransferRate (for IOUs) or TransferFee (for MPTs) at the moment of escrow creation, ensuring predictability in the amount transferred upon settlement.
Ledger Object Update: Modifies the Escrow ledger object to store token-specific information like the token Amount, TransferRate/TransferFee, and IssuerNode (if applicable).

Benefits of Token Escrow

Enhanced Security for Token Transactions: Tokens are locked in an on-ledger escrow and released only upon fulfillment of predefined conditions (e.g., time-based condition).
Increased Versatility for XRPL Applications: Expands the range of programmable transactions possible with diverse token types, fostering more complex decentralized applications.
Predictable Outcomes: By locking the transfer rate or fee at the time of creation, both sender and receiver have clarity on the net amount to be transferred.
Maintained Issuer Autonomy: Upholds issuer-defined rules regarding token holding, authorization, and transferability.
Strengthened Ledger Integrity: Ensures that token escrows adhere to the fundamental rules and state management of XRPL.

Use Cases Unlocked by Token Escrow

Conditional Payments: Automated release of token payments upon completion of services or milestones.
Time-Locked Distributions: Secure vesting schedules for team tokens, grants, or airdrops, releasing them incrementally over time.
Decentralized Exchanges/Marketplaces: Temporary holding of various tokens as part of trade settlements or collateralization within decentralized finance (DeFi) applications.
Secure P2P Token Swaps: Facilitating trustless peer-to-peer exchanges of different tokens with conditional execution.
Digital Rights Management: Release of tokenized assets (e.g., MPTs representing licenses or collectibles) upon payment or agreement.

Get Started: Testing Token Escrow on Devnet

I have created a replit for TokenEscrow. You can see it live on the Devnet by going here and then using the command yarn run iou

What's Next and Call to Action

Explore on devnet and provide feedback.
Prepare for the amendment, update tooling, and participate in voting.
Amendment process (voting)
Prepare for integration

Exploring Experimental Feature Updates in Xahaud: A Performance Analysis

Denis Angell — Mon, 21 Oct 2024 13:15:58 +0000

In the ever-evolving landscape of blockchain technology, optimizing transaction throughput while maintaining system stability is a constant challenge. Xahaud is at the forefront of this endeavor, and today, we delve into two experimental feature updates aimed at enhancing transaction processing capabilities. These updates involve changes to the max_transactions and target_txn_in_ledger settings. Let's explore the impact of these changes on network performance and resource utilization.

Experimental Feature Updates

1. `max_transactions` Setting

The max_transactions setting, which determines the maximum number of transactions allowed in each ledger, has been increased from 250 to 1000. This change is designed to accommodate a higher volume of transactions per ledger, potentially increasing the overall throughput of the network.

2. `target_txn_in_ledger` Setting

Similarly, the target_txn_in_ledger setting, which specifies the target number of transactions per ledger, has been raised from 256 to 1000. This adjustment aims to align the target with the increased capacity, ensuring that the network can efficiently handle larger transaction batches.

Testing Environment

To evaluate the impact of these changes, we conducted tests using a network configuration consisting of six validator nodes and two submission nodes. Each node operates on its own Virtual Private Server (VPS) and is provisioned through Ansible. Additionally, each node is equipped with a lightweight server and listener to monitor ledger statistics, including memory, disk, I/O, and CPU usage.

The load testing involved sending XRP-XRP Payment (No Hook) transactions to both submission nodes using a script. We employed settings such as BATCH_COUNT and SEEDS_IN_GROUP to distribute the batch into groups. To ensure transactions were included in the ledger, we utilized the fee endpoint to adjust transaction fees based on the presence of a ledger queue.

Server Specifications

Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz (2x)
Proxmox virtualisation
12 cores each, "HOST" mode (so native architecture)
48GB mem each
Every VM is a dedicated SAS SSD storage device in "Unsafe" mode (write back)

Performance Analysis

Metric	Before	After	Change
TPS (avg)	161	260	🔼 61.49%
TPL (avg)	643	1039	🔼 61.59%
Secs (avg)	3.56	4.11	🔼 15.45%
Avg CPU (%)	16.20	20.49	🔼 26.48%
Avg Memory (GB)	1.49	2.41	🔼 61.74%

We conducted a series of performance tests to thoroughly understand the impact of the experimental feature updates. These tests were designed to measure key metrics such as transaction throughput, ledger processing efficiency, and resource utilization across the network. By comparing the network's performance with and without the experimental settings, we aimed to identify any significant changes and assess the trade-offs involved.

Baseline Performance (Without Experimental Settings)

Total Transactions: 31,000
Total Ledgers: 49
Transactions Per Second (TPS): 161
Transactions Per Ledger: 643
Average Close Time: 3.56 seconds

Node Resource Utilization:

Max CPU Usage: 24%
Average CPU Usage: 16%
Max Memory Used: 1.73 GB
Average Memory Used: 1.49 GB

Performance with Experimental Settings

Total Transactions: 39,000
Total Ledgers: 38
Transactions Per Second (TPS): 260
Transactions Per Ledger: 1039
Average Close Time: 4.11 seconds

Node Resource Utilization:

Max CPU Usage: 24%
Average CPU Usage: 20%
Max Memory Used: 2.62 GB
Average Memory Used: 2.41 GB

Management Summary:

The recent settings change has resulted in significant performance improvements for our system, albeit with increased resource utilization. Here are the key findings:

Transaction Processing Speed: We've seen a substantial increase in both Transactions Per Second (TPS) and Transactions Per Ledger (TPL), with both metrics improving by over 61%. This translates to a much higher throughput capacity for our system.
Processing Time: The average processing time per transaction (Secs) has increased by 15.45%. While this is a slight degradation, it's outweighed by the massive gains in overall throughput.

Resource Utilization: The new settings require more computational resources. We observed a 26.48% increase in average CPU usage and a 61.74% increase in average memory consumption. This higher resource utilization directly contributes to the improved performance.
Stability: The transaction submission graph in the "after" scenario shows a more consistent pattern, suggesting improved stability in transaction processing.
Node Performance: Individual node performance graphs indicate more uniform CPU usage across nodes after the change, which could contribute to better load distribution and overall system reliability.

In conclusion, the new settings have dramatically improved our system's transaction processing capabilities, with TPS and TPL both increasing by over 61%. This comes at the cost of increased resource utilization, but the trade-off appears favorable given the magnitude of performance improvement. The slight increase in per-transaction processing time is a minor concern that's overshadowed by the overall throughput gains.

Recommendation: Given the substantial performance improvements, we should consider maintaining these new settings. However, we should also closely monitor resource usage to ensure we have adequate capacity to sustain this higher performance level during peak loads. Additionally, we may want to investigate if further optimizations can reduce the slight increase in per-transaction processing time without sacrificing the throughput gains.

Batch (XLS-56) is Now Available for Testing and Development

Denis Angell — Thu, 08 Aug 2024 20:36:39 +0000

As of August 8, the Batch Amendment for the XRP Ledger is available on a new version of BatchNet (v1). This new version features a the ability to batch transactions using the XLS-56d specification and supports all transactions types with a limit of 8. The amendment also supports atomic swaps. Developers are encouraged to test the new functionality of Batch and report any issues to Denis Angell (dangell@transia.co).

Connect to the new version of the BatchNet here:

Name: BatchNet
RPC URL: https://s.devnet.rippletest.net:51234/
WSS URL: wss://s.devnet.rippletest.net:51233/
Network identifier: 3
Digital Asset: XRP
Explorer URL: https://explorer.xrplf.org/wss:s.devnet.rippletest.net:51233/
Faucet URL: https://xrpl.org/resources/dev-tools/xrp-faucets

const response = await client.fundWallet(null, {
  faucetHost: 'batch.faucet.nerdnest.xyz',
  faucetPath: '/accounts',
})
console.log(response)

There is a replit available here which includes helper functions and a fully functioning test examples for both basic batch and atomic swaps.

For support, updated documentation will become available at soon. Developers are also welcome to engage in the XRPL developer Discord, which has a dedicated Batch channel.

The Batch Amendment has no eta for going live on mainnet. Batch is dependent on the review of the source code, the proposal of the amendment, followed by at least 80% of the XRPL validator community accepting the proposal and holding their vote for at least two weeks.

XUMM PYTHON SDK: 5. Security & finishing touch 🎉

Denis Angell — Mon, 28 Feb 2022 17:48:28 +0000

Previous: 4. Verify the results ⛑ and push 🚀

If you have made it this far, you may want to actually build something (even if it's just a hobby project) using the XUMM SDK. If you do, please VERIFY THE PAYLOAD RESULT ON the XRP LEDGER.

You can use the XRPL-PY package, or use the sdk.get_transaction(txHash) method to do this by relying on the XUMM platform to fetch the on ledger transaction outcome for you, or, for example, by using the xrpl-py package to verify 'locally'.

By using the xrpl-py package, you can connect to one of the public XRP ledger nodes and verify the transaction. To do so, add the xrpl-py package to your project by entering this in the terminal: pip3 install xrpl-py. You can then verify a transaction as per the package documentation.

Pay special attention to the balanceChanges response.
❗ There are several reasons why you need to check. For example, a payment can yield a different result (eg. lower amount sent) than requested!

It is your responsibility to check the transaction outcome returned from the XRP ledger rather than relying on XUMM telling you that a transaction has been signed. For example if:

The user signed successfully in XUMM, but with a key that is no longer valid for a certain account (because multisign has been configured, an account has been rekeyed, etc.)
The user sent a Partial Payment (e.g., sending EUR to deliver XRP, while the owned amount of EUR was insufficient due to exchange rate slippage)
The user tried to trick you into accepting a testnet payment, by signing with a funded Testnet account Please take a look at this sample code implementing the xrpl-py package to verify on ledger balance changes for a signed XUMM payload.

That's it! You made it 🎉

Thank you for reading this tutorial! We hope you had fun! If you have questions, suggestions, something to share: our contact details are available at https://xrpl-labs.com :)

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app
Thank you XRP Community!

... For checking, correcting & testing the SDK & tutorial!
@technotip, @calvincs, @wenusch, @alloyxrp, @rippleitinnz, @Ubbah, @enclavia, @WormholeMech, @Chicles_, @3N0RYM, @XrpSpark, @devnullinator, @Vetjes, @kevinking64, @Kujistudios, @nodehash, @4thMadHatter, @Vkumzy, @CarpeDiemXRP, @Hex539, @xrplosion1, @chemical_realm, @RossMacFirdeen

XUMM PYTHON SDK: 4. Verify the results ⛑ and push 🚀

Denis Angell — Mon, 28 Feb 2022 17:48:04 +0000

Previous: 3. Your first payload 🔔

You have now sent a payload to the XUMM platform using the XUMM SDK and have now received a XUMM sign request.

You opened the next.always URL, scanned the QR code with your smartphone running XUMM (or from your smartphone and got redirected to the XUMM app) and you have signed your first request. Well done!

Before we move on we must first verify the payload outcome. As we discussed before, once signed, you would receive a user token to send your next payload using a Push notification.

Please note: this is where this tutorial gets more technical. Software developers will be able to follow this. If you've never coded before this will probably require some further time to learn and understand what is happening and how to achieve the desired end result.

In this part of the transaction we are not just creating a sign request by sending a payload, we are also subscribing to payload events. We will use the following methods in our code. sdk.payload.create() and sdk.payload.create_and_subscribe().

The create_and_subscribe method accepts the payload in the first argument (just like the create method), but the second argument is a function that gets invoked every time the XUMM platform asynchronously sends an update about the created payload.

The subscription for payload events will stay alive until something is returned by the function (second argument) that is passed to the create_and_subscribe method. Here is an example:

When you execute this code, you will immediately see the payload response containing the URL to open the payload. At the end of the code we console log the subscription.created object, containing the created payload data that we previously got directly from the create() method.

The other code only executes immediately after this, as the first payload events are fired once the SDK connects to the XUMM platform.

If the event data contains a signed property, depending on whether the payload has been signed, causes the callback function to print a message, and return either the event data (if signed) or a boolean false (if rejected). By returning something (anything), the subscription then ends.

Let's test this example. Open the created payload URL on your desktop, and while the SDK is waiting for status updates, try scanning the QR code with XUMM. You should now see the opened event live in your terminal 😎

When this is working successfully, we will then complete this by adding some code to wait for the signed: true event (signing the transaction was successful) so we can get our long awaited user token to deliver our future sign requests with a Push notification.

When we run this code, open the payload URL on our smartphone, sign it with XUMM, your terminal should look like this. Note the User Token at the end 🎉

The user token is a unique token for your XUMM app in combination with the specific XUMM user. To use the token to deliver a sign requst per Push notification, let's adjust our first (minimal) sample payload to include the user token:

{
  "TransactionType": "Payment",
  "Destination": "rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ",
  "Amount": "10000"
}

Please change the destination account to an account that you own (remember to use your destination tag if this is required), or if you wish, you can test by sending a small amount of XRP to the XRPL Labs team by using the account in the example.

This payload only contains the XRP ledger specific transaction template. Because we are now going to send XUMM platform specific information as well, we need to wrap the XRP ledger transaction template in an object called txjson. We can then add XUMM platform specific information to the payload as well, like options, custom_meta and the user_token.

Wrapping the XRP ledger transaction template in a txjson object, and adding the user_token property, our payload should now look like this:

{
  "txjson": {
    "TransactionType": "Payment",
    "Destination": "rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ",
    "Amount": "10000"
  },
  "user_token": "..."
}

If we use the user token we received from our previously signed payload and use that in our code, you will see your sign request popping up on your smartphone. Well done!

Now we will run the code, keeping an eye on our smartphone:

When using this in applications, it would make sense to check the pushed property of a created payload. If False, the Push notification could not be sent (e.g., if permissions were revoked by the user) then your application should fall back to the QR method. If pushed is True, it makes sense to show the end user a button to show the QR code anyway if they didn't receive the push notification (eg. changed devices / other device).

Next:

5. Security & finishing touch 🎉

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app

XUMM PYTHON SDK: 3. Your first payload 🔔

Denis Angell — Mon, 28 Feb 2022 17:47:40 +0000

Previous: 2. Prepare your project and start coding 🔨

Now that we have established a connection to the XUMM platform using the XUMM SDK, it is time to actually send something that we can sign. We will send a "transaction template" to the XUMM platform, called a Payload. The lifecycle of a payload is explained in more detail in the XUMM API documentation.

Some things to consider:

A payload (sign request) sent to the XUMM platform should be formatted as per XRP ledger transaction specificaftions, but some fields may be omitted as XUMM will automatically fill them in if able to do so.
Usually, a payload sent to the XUMM platform will be signed by the end user (e.g., for a sign in, subscription, payment, ...). For this tutorial, you will be the initiator and the end user, either signing or rejecting the payload.
The first sign request from a specific XUMM app will always have to be scanned using a QR code on the desktop or redirected in the case of a smartphone. Once an end user trusts your application, by signing your request, your application can obtain a user specific user token to deliver future sign requests using push notifications.
This tutorial is running on your own computer, from the terminal so we will need to copy then paste a sign request URL to our browser. In a real life application, a nicer flow for end users can be created with redirects / live status updates / push and fallback QR codes, etc.

Our first payload will be a Payment transaction type. A basic Payment payload you can send to the XUMM platform would be as per the following example:

If, like in the minimal example above, no amount is entered, the end user will be able to select the currency and amount to send in XUMM after opening the sign request. You could also add more details to your payload, as per the following example:

This sample specifies an amount in Drops (one XRP is one million Drops, the featured ten thousand drops represents 0.01 XRP) and a Memo (HEX encoded string). We will use this example in our code.

We are going to use the sdk.payload.create() code to do this. We will provide two arguments to the sdk.payload.create(..., ...) code.

The first argument will be our payload (like in our previous example above) and in the second argument we will provide a flag (boolean, True) telling the code to return an error, if one occurs.

Our code now looks like this:

Let's run the code. In the terminal panel, type the previously issued command to run our code: python3 playground.py. This should get you your very first XUMM sign request 🎉

Next:

4. Verify the results ⛑ and push 🚀

5. Security & finishing touch 🎉

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app

XUMM PYTHON SDK: 1. Get your XUMM API credentials 🔑

Denis Angell — Mon, 28 Feb 2022 17:46:32 +0000

series: [The XUMM SDK in Python]

Previous: » Intro "XRP ledger payment requests"

Visit the XUMM Developer Console by navigating to https://apps.xumm.dev. If this is your first time using the XUMM Developer Console, you will need to register an account OR sign in with your Github account, if you have one.

After logging in to the XUMM Developer Console, create a new application by clicking the Create new application button. Enter a title and description for your app and upload an icon or picture if desired. If you are only going to be playing and testing with the API, the app title and description do not matter.

For this tutorial entering a Webhook URL is not required.

After creating your new XUMM API application, you will be taken to a page showing your API Key and API Secret.

Example credentials and where to find them.
New App credentials

❗ Keep these credentials SAFE!
You can always find your API Key in the XUMM Developer Console however, your API Secret will be displayed only once. You can always generate a new one if required, but doing so will require updating the API Secret in all your applications.

❗ NEVER share or publish your app credentials!
Your API Secret is for backend use only. Never use these credentials in the frontend of a client side project. If you think your API Secret has been compromised, please regenerate a new secret in the XUMM Developer Console.

Congratulations, you have now registered your first (?) XUMM App. Let's get started!

2. Prepare your project and start coding 🔨

3. Your first payload 🔔
4. Verify the results ⛑ and push 🚀
5. Security & finishing touch 🎉

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app

The XUMM SDK in Python - XRP ledger payment requests

Denis Angell — Mon, 28 Feb 2022 17:45:39 +0000

The XUMM API allows developers to deliver sign requests (payloads) to app users. A payload is a JSON formatted transaction template for a transaction on the XRP ledger.

XUMM app users can scan a QR code or receive a push notification to open the sign request for a transaction. A user views the sign request and either authorizes XUMM to sign it or rejects it. If authorized, the sign request will be signed locally via XUMM, if rejected the sign request is destroyed and the transaction does not happen.

If authorized the transaction can then be sent directly to the XRP ledger. The initiating application will get realtime status updates and after signing, the end user will be returned to the initiating platform.

To make it simple to interact with the XUMM API, and to help build intuitive flows for end users to sign their transactions, we have released the XUMM SDK (pypi) for Python environments.

Pre-requisite

Before beginning this XUMM SDK tutorial, we assume that you are ready to code with your code environment already set up for python. This includes Visual Studio Code (IDE), python, git & virtualenv.

This tutorial consists of five chapters:

1. Get your XUMM API credentials 🔑

2. Prepare your project and start coding 🔨
3. Your first payload 🔔
4. Verify the results ⛑ and push 🚀
5. Security & finishing touch 🎉

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app
Thank you XRP Community!

... For checking, correcting & testing the SDK & tutorial!
@wietse, @technotip, @calvincs, @wenusch, @alloyxrp, @rippleitinnz, @Ubbah, @enclavia, @WormholeMech, @Chicles_, @3N0RYM, @XrpSpark, @devnullinator, @Vetjes, @kevinking64, @Kujistudios, @nodehash, @4thMadHatter, @Vkumzy, @CarpeDiemXRP, @Hex539, @xrplosion1, @chemical_realm, @RossMacFirdeen

XUMM PYTHON SDK: 2. Prepare your project and start coding 🔨

Denis Angell — Wed, 26 Jan 2022 22:33:05 +0000

Previous: 1. Get your XUMM API credentials 🔑

For this example we will use a Python (pip) environment.

Open Visual Studio Code, or your prefrred code editor, and create a new file - File » New file
Save your new file - File » Save in a new folder for your project e.g., xumm-sdk-tutorial and in this folder were using playground.py
Make a new virtual environment to manage your project. mkvirtualenv xumm-sdk-tutorial. If you don't have virtualenv installed please visit the Get Started Tutorial
Install the XUMM SDK (PY) in your project using the 'pip package manager'. Open the terminal - Terminal » New terminal and at the prompt enter pip install -i https://test.pypi.org/simple/ xumm-sdk-py-dangell7
Copy then paste the following boilerplate code into your playground.py file:

import xumm

sdk = xumm.XummSdk('Your-API-Id', 'Your-API-Secret')

def main():
  print("Hi! This is where we'll be writing some code")

main()

Please replace Your-API-Id and Your-API-Secret in the code with the credentials obtained from the XUMM Developer Console when you registered your app.

What does this code actually do?

First, we 'import' the XUMM SDK that we installed using pip into our code - step 3 above. We are using the xumm package, and we are calling it XummSdk in our code.
We then initialize a new instance of the SDK, which we call sdk. We will use this one later in the project as we don't interact with the XUMM SDK just yet. While not needed yet in the project the dummy API Key and API Secret need to be inserted here.
In the function we have just created, we then tell the code to output a message to the terminal, using the print method.
Lastly, we call our main function so the code will actually run.

Now let's run this code. In the terminal panel, type:

python3 playground.py

This will tell python to run all code in your playground.py file. You should receive the message Hi! This is where we'll be writing some code in your terminal and be back at the prompt awaiting further instruction.

If you have your API Key and API Secret in place (see placeholder values in code above) you can check if everything is working by asking the XUMM Platform to return your registered XUMM app name.

Replace the line of code containing print(...) with a ping request to the XUMM platform:

app_info = sdk.ping()

This line of code calls the ping method of the XUMM SDK. We await the results, as it may take a brief moment to connect to the XUMM platform and get a response. When we get a response, we are making the results accessible under the name app_info.

Now let us return the application name we retrieved from the XUMM platform to the console by using print once again. When you start typing, Visual Studio Code will suggest available properties:

Code autocomplete

Our main code should now look like this:

def main():
  app_info = sdk.ping()
  print(app_info.application.name)

Let's test the code:

It looks like we are able to reach the XUMM platform 🎉 😎

Next:

3. Your first payload 🔔
4. Verify the results ⛑ and push 🚀
5. Security & finishing touch 🎉

Resources 📚

If you want to learn more about the XUMM SDK PY, platform, documentation, etc., make sure to check out:

The XUMM SDK (PY) readme
The XUMM SDK (PY) source code
The XUMM API documentation & API reference
XUMM (end user) support docs
In case of questions: support@xumm.app

DEV Community: Denis Angell

Smart Contracts on XRPL's AlphaNet

What Are XRPL Smart Contracts?

Connect to AlphaNet

Replit

Key Features

New Transaction Types

New Ledger Entries

Sample Use Cases

Contract Examples:

Architecture Overview

Core Smart Contract Components

1. Parameters: Instance & Function

2. Data: Storage and State Management

3. Emit: Transaction Emission

4. Events: Event Emission and Subscriptions

Getting Started

Example: Basic Contract Structure

Resources and Support

Join the Future of XRPL Development

XRPL Token Escrow: Features, Benefits, and Getting Started

Key Feature Highlights

Benefits of Token Escrow

Use Cases Unlocked by Token Escrow

Get Started: Testing Token Escrow on Devnet

What's Next and Call to Action

Exploring Experimental Feature Updates in Xahaud: A Performance Analysis

Experimental Feature Updates

1. max_transactions Setting

2. target_txn_in_ledger Setting

Testing Environment

Server Specifications

Performance Analysis

Baseline Performance (Without Experimental Settings)

Performance with Experimental Settings

Management Summary:

Batch (XLS-56) is Now Available for Testing and Development

XUMM PYTHON SDK: 5. Security & finishing touch 🎉

That's it! You made it 🎉

Resources 📚

XUMM PYTHON SDK: 4. Verify the results ⛑ and push 🚀

Resources 📚

XUMM PYTHON SDK: 3. Your first payload 🔔

Resources 📚

XUMM PYTHON SDK: 1. Get your XUMM API credentials 🔑

Resources 📚

The XUMM SDK in Python - XRP ledger payment requests

Resources 📚

XUMM PYTHON SDK: 2. Prepare your project and start coding 🔨

Resources 📚

1. `max_transactions` Setting

2. `target_txn_in_ledger` Setting