Terms of Service

1. Operator

“Sluzen” is the service. This agreement is entered into by the Operator and you.

• Legal name: Guido Alejandro Morales Araque
• RUC: 1718131236001
• Contact: [email protected]

The Operator reserves the right to assign, transfer, or delegate this agreement and all rights and obligations hereunder to any affiliated entity, including a future incorporated company (e.g., SAS), without prior consent from the Issuer, by providing notice via the Sluzen platform or email.

2. The service

Sluzen is a payment rail for an HTTP API. This section is the default proxy. An unpaid protected route gets an HTTP 402 challenge from Sluzen. Sluzen accepts a payment the agent has already signed, submits that transaction to the XRP Ledger, and, after the ledger confirms, forwards the request to the issuer’s origin. The issuer sets the request price. The destination of that price is the issuer’s classic XRPL address, not the Operator. A facilitator resource and a settle-after-origin route are section 2.1. They need the separate acceptance named there. Issuers who only use the default proxy stay on the 14 September 2026 terms.

2.1 Facilitator and settle-after-origin

These options need a separate acceptance dated 2026-10-14. Accepting them does not replace the 14 September 2026 terms, and issuers who only use the default proxy do not have to accept them.

A facilitator resource stays on the issuer’s own https URL. The issuer asks Sluzen for the 402 challenge, may ask Sluzen to verify a signed payment without submitting it, runs the handler, and asks Sluzen to settle only if that handler succeeded. The issuer must not return the resource before that settle confirms. If the issuer never settles, the caller is not charged. Sluzen does not see the resource and does not refund a payment the ledger already confirmed.

A proxy route marked settle-after-origin calls the issuer’s origin before Sluzen submits the signed payment. A response outside 2xx is not charged. The body of a 2xx response is returned only after the ledger confirms. If the origin already changed state and the submit then fails, that work stays unpaid. There is no second payment to undo it.

The Operator provides exclusively technical software and message-routing infrastructure.

2.2 Unilateral Origin Assertions and Blind Passthrough Metadata

Blind Passthrough and Technical Opacity. The Operator may enable an optional data field within the API and settlement schema allowing the Issuer or Facilitator to attach an alphanumeric string, cryptographic digest, or external receipt reference (an "Origin Assertion") to a settlement record. The Operator processes, transmits, and logs any Origin Assertion strictly on a blind, automated, and 100% passive passthrough basis. The Operator does not inspect, verify, validate, authenticate, or audit the content of any Origin Assertion, the mathematical validity of any external cryptographic signature, the underlying HTTP response payload, or the uptime and accuracy of any third-party verification endpoint.

Zero Co-Certification or Delivery Warranty. Any Origin Assertion injected into the platform constitutes a strictly unilateral commercial declaration made solely by the Issuer or Facilitator. The logging or display of an Origin Assertion within a Sluzen settlement record does not constitute, and shall not be represented or construed as, a co-certification, notarization, endorsement, representation, or warranty by the Operator that the underlying API resource, data, or service was effectively delivered, accurate, complete, non-infringing, or fit for any particular purpose.

Strict Limitation of Role and Settlement Finality. The Operator provides exclusively technical software and message-routing infrastructure. Under no circumstances shall the availability or logging of an Origin Assertion render the Operator a Merchant of Record (MoR), escrow agent, fiduciary, custodian, notary, or commercial arbitrator. The presence, absence, or subsequent dispute of an Origin Assertion does not alter the absolute finality of a settled XRPL transaction (tesSUCCESS) and creates no obligation for the Operator to process refunds, reverse on-chain payments, withhold credits, or mediate, adjudicate, or participate in billing or delivery disputes between the Issuer/Facilitator and any calling agent or third party.

Exclusive Liability and Indemnification. The Issuer or Facilitator assumes sole and exclusive legal, financial, and technical liability for the accuracy, truthfulness, and legal compliance of any Origin Assertion and the delivery of the underlying service. The Issuer or Facilitator agrees to defend, indemnify, and hold harmless the Operator (Guido Alejandro Morales Araque, RUC 1718131236001, and any successor or assignee entity) from and against any and all claims, demands, disputes, losses, regulatory penalties, or expenses (including reasonable attorneys' fees) initiated by any calling agent, end-user, or third party arising out of or relating to an Origin Assertion or any alleged failure, defect, or non-delivery of the Issuer's or Facilitator's service.

2.3 XRPL Unidirectional Payment Channels

These options need acceptance under the rail terms dated 2026-10-21. Accepting them does not replace the 14 September 2026 terms or the 2026-10-14 rail clauses in sections 2.1 and 2.2. Product label: Unidirectional XRPL L1 Payment Channel verification (Agent-to-Issuer).

(i) The Operator verifies off-chain Payment Channel claim signatures in read-only mode. The Operator does not guarantee channel solvency, Expiration/CancelAfter, SettleDelay, or that the Agent will not close or expire the channel.

(ii) The Issuer alone is responsible for signing and submitting PaymentChannelClaim (or having the Agent submit) before channel expiry. The Operator at most performs submitAndWait of an already-signed Claim blob. The Operator does not hold issuer or agent seeds, RegularKey, or SignerList authority for that purpose.

(iii) Channel Source = Agent classic address (r…). Destination = Issuer merchantReceiveAddress (r…). The Operator treasury is never Source or Destination. The Operator never holds RegularKey or SignerList for the Issuer or the Agent.

(iv) Off-chain claim acceptance does not create escrow, refund, Merchant of Record, custody, or dispute-judge duties. Ledger tesSUCCESS of Claim governs on-chain settle finality for the channel. Platform fee finality for prepaid take follows the locked SPEC rule: the Operator's verification and message-routing service accrues when an off-chain claim increment is accepted, even if the Issuer never presents Claim on-chain before Expiration/CancelAfter. Prepaid take remains consume-only XRP credits.

(v) Forbidden marketing terms: "deposit-in-Sluzen", "margin account", "session wallet", "custody".

2.4 XRPL Issued Currency (RLUSD allowlist)

These options need acceptance under the rail terms dated 2026-10-22. Accepting them does not replace the 14 September 2026 terms, the 2026-10-14 rail clauses in sections 2.1 and 2.2, or the 2026-10-21 Payment Channel clauses in section 2.3. Product label: Allowlisted XRPL Issued Currency Payment (RLUSD).

(i) Product Payment may be an XRPL IOU on a closed Operator allowlist (initially the official RLUSD issuer address only). The Agent signs a Payment whose Amount is that IOU to Destination = Issuer merchantReceiveAddress (r…). The Operator only submitAndWaits an already-signed blob.

(ii) Operator prepaid credits and the 0.8% debit remain native XRP drops only. The Operator treasury does not open TrustLines or receive IOUs.

(iii) The Operator disclaims: missing TrustLine / tecNO_LINE / tecPATH_DRY; Individual or Global Freeze; Clawback (XLS-39d); depeg or issuer insolvency. The Operator is not the issuer, redeemer, or 1:1 guarantor of any IOU.

(iv) RLUSD / allowlisted IOU is not Ecuador legal tender and is not bank USD.

(v) There is no Operator-managed DEX pathfinding or auto-bridging for the caller.

2.5 Base canonical USDC (non-custodial verification and raw relay)

These options need acceptance under the rail terms dated 2026-10-23. Accepting them does not replace the 14 September 2026 terms, the 2026-10-14 rail clauses in sections 2.1 and 2.2, the 2026-10-21 Payment Channel clauses in section 2.3, or the 2026-10-22 RLUSD clauses in section 2.4. Product label: HTTP 402 settlement verification on Base for canonical USDC.

(i) The Operator does not operate a gas-relay wallet, does not hold agent or issuer EVM keys, does not pay ETH gas, and does not deploy or operate escrow, splitter, or session-key contracts. The Operator does not execute EIP-3009 transferWithAuthorization or Permit2.

(ii) Product price on this rail is a transfer of canonical Circle USDC on Base to the Issuer merchantReceiveEvmAddress (0x…). The Agent pays the gas. The Operator either reads a public transaction receipt or broadcasts a raw transaction the Agent already signed. The Operator treasury is never the recipient.

(iii) USDC on Base is not Ecuador legal tender and is not bank USD. The Issuer alone accepts freeze, blacklist, or pause by the token issuer, L2 sequencer failure or reorganization, and the correctness of the Issuer's 0x… address.

(iv) A Base confirmation (status success) is final. The Operator does not refund, reverse, or mediate a delivery dispute after that confirmation.

(v) The 0.8% platform fee is computed on the settled USDC amount and debited only from the Issuer's prepaid XRP credit balance. The Operator does not accept USDC or ETH as prepaid credits.

(vi) Forbidden marketing terms: "USDC rail by Sluzen", "Sluzen Base Network", "bridge", "cross-chain swap", "gasless", "sponsored gas", "paymaster", "custody", "escrow", "wallet", "deposit", "legal tender", and any affiliation or logo of Coinbase, Base, Circle, Optimism, or the x402 Foundation.

3. What this is not

The service is not a wallet, exchange, broker, bank, electronic-money institution, deposit-taker, marketplace, or custodian of the request price. The Operator is not the merchant of record for the issuer’s resource. XRP is not government-issued legal tender. Nothing here is an offer of securities or a promise to redeem credits for cash.

4. Agents

Agents do not need an account on this site. On the default proxy they call a route on Sluzen, read the 402, sign locally, and ingest the payload. On a facilitator resource they call the issuer’s https URL. The issuer obtains the challenge from Sluzen and returns the body only after settle confirms. The Operator does not hold agent seeds. Never paste a seed into sluzen.network. The agent pays the request price plus the network fee for that rail (XRP Ledger dust on XRPL routes; ETH gas on Base USDC routes under section 2.5). The 0.8% share is not added to the 402 amount. Automated interaction with the API, including an unpaid HTTP 402 challenge, constitutes acceptance of these terms.

5. Issuers

Issuers keep their own origin. They register a route, a request price, and a receive address. Default: price in XRP drops to a classic XRPL address. Without a valid classic receive address there is no XRP or allowlisted RLUSD sale. Opt-in product Amounts under sections 2.4 and 2.5 use the receive address rules in those clauses (classic r… for RLUSD; EIP-55 0x… for canonical Base USDC). Issuer API keys and non-refundable API fee credits (prepaid SaaS consumption credits) are provisioned out-of-band, not via public signup. The issuer is responsible for the legality of the upstream resource and for the address that receives the request price.

6. API fee credits and fees

On mainnet Split the issuer pays, from non-refundable API fee credits, 0.8% of settled request-price GMV from call 1. Testnet does not levy. Insufficient credits → the rail may refuse traffic (HTTP 429). Those credits are a non-refundable platform allocation. They buy platform capacity only. They are not redeemable for XRP or dollars unless the Operator agrees in writing.

Promotional Fee Waiver (Introductory Window). The Operator may, at its sole discretion, grant newly onboarded Issuers a one-time promotional fee waiver of one hundred percent (100%) on the standard 0.8% platform fee for mainnet settlements, up to a maximum cumulative waived fee equivalent to 1 XRP or for a period of thirty (30) calendar days from onboarding, whichever occurs first (the "Introductory Waiver"). During the applicability of the Introductory Waiver, the effective platform fee for qualifying settlements shall be zero (0.00 XRP / USD $0.00), and no platform fee debt or receivable shall accrue against the Issuer. Upon expiration or exhaustion of the Introductory Waiver, any subsequent mainnet settlement shall require a positive balance of non-refundable prepaid platform credits and shall accrue the standard 0.8% platform fee. Any XRP transferred by the Issuer to the Operator's treasury during or after the Introductory Waiver shall be credited solely toward future platform fee consumption and shall not retroactively charge or offset fees previously waived under this section. The Introductory Waiver is limited to one allocation per legal entity and settlement address, carries no cash value, does not constitute a line of credit or deposit account, and cannot be withdrawn, refunded, or transferred.

Issuers who activate a receive address in the first commercial window keep the 0.8% take for 12 months from activation. After that window the Operator may change the take for new activations.

7. Lawful funds

The Issuer declares and warrants that any virtual assets used to fund non-refundable API fee credits originate from lawful activity. The Issuer indemnifies the Operator against civil or criminal claims arising from the origin of those assets. This declaration does not limit the Operator's right to refuse a counterparty, a top-up, or service.

API fee credits are consume-only. They are non-refundable, non-transferable, not a deposit, and not redeemable. They are accepted only from the XRPL address on the issuer file. The Operator may refuse top-ups from any other address.

8. Prohibited use

Do not use the rail for unlawful content, fraud, sanctions evasion, malware, or to imply the Operator is the seller of the issuer’s resource. The Operator may suspend routes or keys.

9. Availability and liability

The rail is provided as available. Ledger congestion, upstream failure, and hosting limits are outside the Operator’s control. Liability is limited to the platform fees actually paid to the Operator in the 12 months before a claim, except where Ecuadorian law forbids the limit. The Operator is not liable for the issuer’s resource or for XRP price movement.

10. Privacy

Personal data is handled as described in the Privacy Policy.

11. Changes

Material changes will be posted on this page with a new effective date. Continued use after that date is acceptance. The How Sluzen works page describes the product; it does not replace these terms.

12. Governing law

These terms are governed by the laws of the Republic of Ecuador, without prejudice to mandatory consumer rules that apply to you. Courts of Ecuador have jurisdiction, unless a mandatory forum applies.

Contact: [email protected].