Skip to main content

xrpl-mpp-client

Buyer-side XRPL signer and one-retry httpx transport for MPP 0.2.

pip install xrpl-mpp-client

XRPLPaymentSigner builds one-time charge transaction/hash credentials and PaymentChannel open/voucher/close credentials. It supports named networks, canonical currencies, source DIDs, InvoiceID binding, tags, memos, and local recipient/amount/currency policy. When rpc_url is omitted, its JSON-RPC endpoint follows the selected mainnet, testnet, or devnet network. Autofilled charge and channel-create transactions cap LastLedgerSequence to the authenticated challenge expiry; an existing tighter ledger bound is kept. RPC endpoints must use HTTPS. Plaintext RPC is accepted only for an exact localhost or loopback address when allow_insecure_rpc=True is explicitly set. The signer also refuses a final autofilled transaction fee above max_fee_drops (1,000 drops by default), and explicit fee, sequence, and last_ledger_sequence inputs remain authoritative through autofill.

Issued-currency payments remain direct and set SendMax equal to Amount by default, so an RPC cannot silently choose a different source asset or increase wallet spend. Transfer-fee headroom and cross-currency paths require an explicit source-side policy:

from xrpl_mpp_client import XRPLIOUPathfindingPolicy, XRPLPaymentSigner

signer = XRPLPaymentSigner(
    wallet,
    network="testnet",
    iou_pathfinding_policy=XRPLIOUPathfindingPolicy(
        source_currency="XRP",
        max_source_amount="1005000",  # absolute XRP drops ceiling
        slippage_bps=50,              # 0.5%; allowed range is 0-1000
    ),
)

The signer gives ripple_path_find only that source currency, validates the returned source amount and protocol path bounds, applies the bounded slippage, and refuses any route above max_source_amount. Amount remains the exact challenge amount and tfPartialPayment is never enabled. Automatic holdings enumeration, MPT pathfinding, unbounded SendMax, and caller-supplied arbitrary path sets are deliberately unsupported.

XRPLPaymentTransport sends Accept-Payment, selects from multiple challenges, uses the exact credential header chosen by the server, preserves ordinary bearer auth, requires HTTPS, and retries once. Plaintext loopback development requires the explicit allow_insecure_localhost=True opt-in. Automatic signing fails closed unless a complete XRPLPaymentPolicy is passed to the transport or the signer was configured with all three constructor guardrails: expected_recipient, max_amount, and allowed_currencies. Before signing, the transport also buffers replayable request bytes and verifies any challenge digest against the exact body that both attempts send. A paid charge receipt is accepted only when its core reference is the exact hash of the signed transaction (or the supplied push hash); optional XRPL receipt extensions must also match the challenge and credential.

from xrpl_mpp_client import XRPLPaymentPolicy, wrap_httpx_with_mpp_payment

policy = XRPLPaymentPolicy(
    expected_recipients="rMerchantAddress...",
    max_amount="10000",
    allowed_currencies=["XRP"],
    max_challenge_validity_seconds=300,
)
client = wrap_httpx_with_mpp_payment(signer, payment_policy=policy)

Known PaymentChannels are registered by channel ID and cumulative high-water amount. Channel opening uses a caller-supplied signed PaymentChannelCreate blob. The signer derives its real channel ID, binds its payer, recipient, claim key, and funding, and supports a nonzero initial cumulative claim up to that funding. A close credential is a final cumulative voucher; it does not submit the funder's XRPL tfClose transaction or refund unused XRP. The 0.2 transport does not store a server-issued session credential.

Direct signer methods remain available for interactive or externally approved flows. Treat every challenge as untrusted until it passes local spend, recipient, currency, network, and expiry policy. Automatic policy requires an expires value and rejects a remaining validity window longer than its configured limit (300 seconds by default).

Documentation: https://lgcarrier.github.io/xrpl-mpp-stack/packages/client/

Metadata

Release files for xrpl-mpp-client 0.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for xrpl-mpp-client 0.2.0
File Size Uploaded Provenance Actions
xrpl_mpp_client-0.2.0.tar.gz 20.0 kB With provenance Details for xrpl_mpp_client-0.2.0.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for xrpl-mpp-client 0.2.0
File Interpreter ABI Platform Actions
xrpl_mpp_client-0.2.0-py3-none-any.whl Python 3 none any Details for xrpl_mpp_client-0.2.0-py3-none-any.whl

Total release size: 43.0 kB

Release files / xrpl_mpp_client-0.2.0.tar.gz

Download URL xrpl_mpp_client-0.2.0.tar.gz
Size 20.0 kB
Tags Source
SHA-256 checksum
How to use checksums
df8252870a808efb35f9315b43337b94aa755cfa689fef81b5a2b7a73dcf2c8b
BLAKE2b-256 checksum
How to use checksums
c568b1bf50d7417084a9ea1eca56e42cf6f5f664580cc4582dd36771080fdbec
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

Release files / xrpl_mpp_client-0.2.0-py3-none-any.whl

Download URL xrpl_mpp_client-0.2.0-py3-none-any.whl
Size 22.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
ffc85a00d02386c29202287491128421d972ab1a120f122bcf3fae47985ad99d
BLAKE2b-256 checksum
How to use checksums
4a839581e0b513bca32e36a27fbb6b48b4fd99eee877706fd982dafcf2a2ed09
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

Security for xrpl-mpp-client 0.2.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for xrpl_mpp_client-0.2.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 3, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page