Terms of Service

The agreement between you and Zuuppa for using the API, the dashboard and the SDKs. Written to be read, and written to be accurate about a product still in beta: what we do, what we hold, what can go wrong, and who carries it when it does.

Last updated 16 August 2026

This agreement

These terms are a binding contract between you and Zuuppa Inc., a Delaware corporation (“Zuuppa”, “we”, “us”). They govern your use of the Zuuppa API, dashboard, mobile app, SDKs and documentation (together, the “Service”). They took effect on 16 August 2026.

You accept them by requesting access, signing in, or making a call to the API, whichever happens first. If you don't accept them, don't use the Service.

If you're accepting on behalf of a company or other organisation, you represent that you have authority to bind it, and “you” means that organisation as well as you personally.

The Privacy Policy forms part of these terms. Two clauses deserve reading before the rest: We hold your funds while they're in flight and Dispute resolution, arbitration and class waiver, which requires most disputes to go to individual arbitration and waives your right to a jury and to participate in a class action.

Definitions

Service
The Zuuppa API, dashboard, mobile app, SDKs, documentation and this website.
You / Merchant
The party that holds a Zuuppa account and uses the Service to take payments.
Buyer
A person who pays you through the Service. A Buyer has no Zuuppa account and is not a party to these terms.
Payment Intent
A single expected payment, created by your server, priced in US dollars, with its own newly derived Deposit Address and a fixed window in which it can be paid.
Deposit Address
The Solana address a Buyer sends funds to for one Payment Intent. Derived by us, for that intent, and not reused. We control the private key to it. See We hold your funds while they're in flight.
Destination Wallet
The address you configure as the place settled funds are sent. You control its keys; we never have them.
In-Flight Funds
Funds that have reached a Deposit Address but have not yet been swept to your Destination Wallet or returned to the sender. This is the only period in which we hold anything.
Settlement / Sweep
The on-chain transaction that moves funds from a Deposit Address to your Destination Wallet, net of our fee.
Return
An on-chain transfer of funds from a Deposit Address back to the address they came from. Not the same thing as a refund to your customer; see below.

Beta, and who can use this

Zuuppa is in invite-only beta. Access is granted and withdrawn at our discretion, and being invited creates no entitlement to continued access.

To use the Service you confirm that:

  • you are at least 18 and have capacity to enter a contract;
  • you are using the Service for business purposes, not as a consumer;
  • you are not located in, ordinarily resident in, or organised under the laws of a country or territory subject to comprehensive United States sanctions, and you are not a person with whom United States persons are prohibited from dealing;
  • your use of the Service is lawful where you are and where your Buyers are, and you hold any licence or registration that use requires.

We perform no identity verification, sanctions screening or anti-money-laundering checks on you or on your Buyers. Those confirmations are yours, and we rely on them. If any of them stops being true, stop using the Service and tell us.

What the Service does

Zuuppa is payment infrastructure for Solana. When your server creates a Payment Intent, we derive a Deposit Address for that single payment, price it in US dollars, watch the chain for the transfer, confirm it, sweep the funds to your Destination Wallet net of our fee, and notify your backend. Concretely, we:

  • derive a fresh Deposit Address per Payment Intent, never reused across intents;
  • convert your USD price into an amount of the asset the Buyer selects, at a rate we source at that moment, and hold that amount fixed for the payment window;
  • detect the incoming transfer on-chain and treat the intent as paid only once the transfer is confirmed;
  • sweep the funds to your Destination Wallet, deducting our fee in the same transaction;
  • emit signed webhook events for each state transition, and expose the same state for polling.

To do that, we hold the private key to every Deposit Address, which means that for the period between a Buyer paying and the funds reaching your wallet, we hold your funds. We hold your funds while they're in flight sets out exactly what that means and what it risks; please read it rather than assuming this is a non-custodial product.

What the Service is not

Zuuppa is not a bank, a deposit-taking institution, an exchange, a broker, a wallet provider, an investment service or an insurer. We do not issue a token. We do not hold a balance for you between payments, extend credit, or provide price exposure to any asset. Nothing about the Service is insured by any government deposit-insurance scheme, because there is no deposit account.

We hold your funds while they're in flight

We hold In-Flight Funds as a short-term escrow, for one purpose: so the Service can confirm what actually arrived and settle it to the right place. In normal operation that period is very short, typically under a minute, and When settlement happens explains why we still can't promise a deadline.

What follows from this

  • You are exposed to us. While funds are in flight, their safety depends on our systems and our operational security, not only on yours. A compromise of our keys, a defect in our code, or a mistake by our staff could result in the loss of In-Flight Funds.
  • The keys are concentrated. Deposit Addresses derive from a shared master key rather than one independent key per address, so a compromise of that key would not be limited to a single payment. Reducing this concentration is on our pre-general-availability list.
  • We are not a trustee. We hold In-Flight Funds as a service provider performing settlement, and nothing here creates a trust, an escrow agency, a fiduciary duty or a debtor-creditor relationship; see No advice, no fiduciary duty.
  • In-Flight Funds are not segregated per merchant in the sense a regulated custodian would mean. We can attribute every payment to the intent that created it, but the underlying key material is not partitioned by account.
  • If we became insolvent, the treatment of In-Flight Funds has not been tested and we make no representation about it. This is one more reason not to hold value in flight longer than a payment needs.
  • Once funds reach your Destination Wallet, we cannot reach them, reverse them or claw them back. Custody ends there and yours begins.

You accept this arrangement, and the risks named above, as a condition of using the Service. Limitation of liability limits what we owe you if In-Flight Funds are lost, and it applies to this clause as it does to every other.

Practical consequence, and we mean it as advice rather than boilerplate: settle promptly and keep balances moving. The Service is designed to hold funds for seconds, and the less value sitting in flight at any moment, the less either of us is exposed.

When settlement happens

Our settlement process runs continuously and picks up confirmed payments within seconds. That is how it behaves, and it is not a commitment.

We do not promise any settlement time. A sweep can be delayed or can fail, and when it does we retry with an increasing delay between attempts. If the retries are exhausted the payment is flagged for us to handle by hand, and manual handling has no committed timeframe at all. Causes include Solana congestion or an outage, an RPC provider failing, insufficient network fee, a rejected or dropped transaction, a defect in our software, or a Destination Wallet that cannot receive the asset.

You'll see this as a status on the payment, and, if you use webhooks, as an event. Do not build a flow that assumes settlement is instantaneous or that it is certain; treat a payment as settled when the Service says it is settled, and design for the case where that takes longer than you expected or needs our intervention.

Delayed settlement, failed settlement, and the consequences of either, including a Buyer who has paid and a fulfilment you have already performed, are subject to Disclaimer of warranties and Limitation of liability.

The payment window

Every Payment Intent is payable for 10 minutes from the moment it is created. The window is fixed by us and is the same for every merchant; if the API accepts a field that looks like it sets a different duration, that field has no effect today.

When the window closes, the intent stops being payable and the quoted amount stops being honoured. Funds that arrive at a Deposit Address after the window has closed are handled under Overpayments, underpayments and the wrong asset, which in some cases means manual handling rather than an automatic return.

A Buyer who pays close to the deadline may have their transfer confirm after it. Whether such a payment is honoured, returned or held for review depends on the asset and the amount, and is described in Overpayments, underpayments and the wrong asset.

Prices, conversion and what the buyer owes

You set a price in US dollars and list the assets you'll accept. When a Buyer chooses one, we convert your price into an amount of that asset using a rate we obtain from a third-party price source at that moment, and we hold that amount fixed for the payment window.

  • The rate is a rate, not the best rate. We don't warrant that a price we source is the best available anywhere, or that it matches any particular exchange or index at any moment.
  • Between the quote and the payment, the asset's market value can move. The Buyer owes the quoted amount of the asset, so that movement lands on you, on your Buyer, or on both, not on us. For volatile assets in a ten-minute window this is a real amount of money.
  • If a price source is unavailable or returns something we can't use, we may decline to create or to quote an intent rather than guess.
  • You are responsible for the price you set, for what you say about it to your Buyer, and for any tax you have to charge or remit on the sale.

Your account, your keys, your API keys

Sign-in runs through our identity provider, using the email address or phone number we invited. Keeping access to that mailbox or number secure is your responsibility, because access to it is access to your account and to the setting that decides where your money goes. The dashboard does not yet offer two-factor authentication; adding it is on our pre-general-availability list, and until then the security of your email account is the security of your Zuuppa account.

API keys authenticate as you. Anything done with your key is treated as done by you, and we have no way to distinguish an authorised call from an authorised-looking one.

  • Keep keys server-side. Never ship one in a mobile app, a browser bundle, a public repository or a client-side config.
  • We store keys hashed, so we cannot show you a key again after you first see it. We can only revoke it and issue a new one.
  • Rotate a key in the dashboard the moment you suspect exposure, and tell us promptly so we can help.
  • You are responsible for all activity under your account and keys, including activity by your staff and contractors, and including a loss caused by a leaked key.

Your destination wallet

You set the Destination Wallet that settlements are swept to. Its private keys are yours alone: we never hold them, never see them and cannot recover them. This is the one part of the flow that genuinely is in your control, and it has a sharp edge.

  • If you configure the wrong address, funds settle to that address. We cannot reverse an on-chain transfer, and neither can you or the Buyer. That loss is permanent and it is yours.
  • If the address can't hold the asset (no associated token account, an address on a different chain, a contract that rejects the transfer), settlement fails, and the funds stay in flight until we handle it manually.
  • If you lose the keys to your Destination Wallet, funds already settled there are gone. We cannot restore access.
  • Keeping the address current, and verifying it after every change, is your responsibility. So is the security of the wallet itself.

After changing your Destination Wallet, confirm it with a small test payment before sending real volume through it. It costs a few cents and it is the only check that actually proves the address works.

Webhooks and your integration

If you configure an endpoint, we POST an event to it on each state transition. Events are signed with an HMAC over the raw request body, and each carries a stable event id. The event types are:

  • intent.paid
  • intent.overpaid
  • intent.underpaid
  • intent.swept
  • intent.refunded
  • intent.expired
  • intent.settle_failed

Your obligations, and they are conditions of relying on webhooks at all:

  • Verify the signature on every event before acting on it, and reject anything that fails. If you act on an unverified body, the consequences are yours.
  • Deduplicate on the event id. We retry, so the same event can arrive more than once, and a retry after a slow response can arrive before you've finished handling the first delivery.
  • Expect delivery to be at-least-once and out-of-order, not exactly-once. We attempt delivery up to 12 times with an increasing delay, and then stop. If your endpoint is down for that whole period, those events are not delivered later.
  • Treat webhooks as a notification, not as the record. The authoritative state of a payment is what the API returns when you ask it. Where the two ever disagree, the API wins.
  • Poll for anything you cannot afford to miss. Not every state change emits an event (an intent you cancel yourself does not), so a system that only listens will eventually be wrong.
  • Keep your endpoint reachable, reasonably fast, and idempotent. We are not responsible for events your endpoint didn't accept.

Your integration is yours. You are responsible for what your code does with our data, for the correctness of your fulfilment logic, and for testing before you take real money. We do not review, approve or warrant any integration, and sample code in our documentation is illustrative only.

Fees

We charge 1% of the settled value of each payment. It is deducted in the same transaction as the sweep and reported on every payment, so what you netted is never a figure you have to reconstruct.

  • No monthly fee, no setup fee, no minimum volume.
  • The Solana network fee applies in addition. It is a fraction of a cent per transaction. On SOL payments it comes out of the amount swept; on token payments we pay it ourselves, so you receive the full token amount.
  • Nothing is withheld as a chargeback reserve, because an on-chain payment cannot be reversed by the payer.
  • We charge nothing on a payment that never settles to you, including one that is returned to the sender.
  • Our fee is charged on revenue only and is never taken out of an amount being returned to a Buyer.
  • Fees are exclusive of any tax. If a tax applies to our fee, it's added.

We may change our fees. If we do, we'll give you at least 30 days' notice by email to the address on your account, and the new fee applies only to payments created after it takes effect. If you don't accept a fee change, stop using the Service before it does.

Overpayments, underpayments and the wrong asset

Payments don't always arrive as expected. What happens next depends on the asset, and it is not always automatic. This is how the Service actually behaves today:

Overpayment in SOL
The expected amount is swept to you and the excess is returned to the sending address, automatically.
Overpayment in a token
The entire balance is swept to you and the excess is not returned automatically. If a Buyer overpays in a token, you have received their excess, and returning it is between you and them.
Underpayment, then expiry, in SOL
The partial amount is returned to the sending address, automatically.
Underpayment, then expiry, in a token
The funds are held for manual handling. They are not returned automatically and there is no committed timeframe for resolving them.
A token you didn't list as accepted
Returned to the sending address automatically, on a separate track from the intent, and reported separately.
SOL sent to an intent expecting a token
Held for manual review. Not returned automatically.
Nothing arrives
The intent expires at the end of its window. There is nothing to sweep or return.

Two limits apply to every Return:

  • A Return goes to the address the funds came from, less the network fee needed to send it. We cannot choose a different destination, and we cannot ask the sender where they'd like it.
  • We cannot reliably return funds sent from an address that can't receive them (an exchange deposit address or a custodial account is the common case), and we usually cannot tell in advance that this is the situation. Funds sent from such an address may be unrecoverable. Neither we nor you can fix that after the fact.

Where this clause says funds are held for manual handling, they remain In-Flight Funds and We hold your funds while they're in flight continues to apply to them. Tell your Buyers to pay the exact amount, in the exact asset, from a wallet they control. It avoids every row of the table above.

Refunds to your customers

Refunding a customer for a commercial reason (a returned order, a cancelled subscription, a goodwill gesture, a dispute about what you sold) is between you and them. Zuuppa has no mechanism to claw back a settled payment from your Destination Wallet, so you make those refunds yourself, from your own wallet.

You are solely responsible for having a refund policy, for honouring it, and for complying with any consumer-protection or distance-selling law that requires you to refund a customer. We are not a party to your sale and we don't arbitrate disputes about it. Do not tell a Buyer that Zuuppa will refund them; we can't.

Your obligations

You own your relationship with your customers: what you sell, what you promise, what you deliver, your own terms and refund policy, your prices, your taxes and your customer service. We are infrastructure between your checkout and your wallet, and we are not a party to your sales.

Compliance

Zuuppa performs no identity verification, sanctions screening or transaction monitoring, and it holds no licence on your behalf. That does not exempt you from anything. You are responsible for your own licensing and registration, sanctions and anti-money-laundering compliance, tax collection and reporting, consumer-protection obligations, and for the legality of what you sell in each place you sell it. If your business requires a money-transmission, e-money or virtual-asset-service licence, getting one is on you.

Your Buyers

You are responsible for telling your Buyers, truthfully, what they are paying for and who they are paying, that payment is in crypto and is irreversible, and that a third-party processor is involved. Where you collect a Buyer's personal details through our SDK, you are responsible for having a lawful basis to collect them and for your own privacy notice; see Who is responsible for what.

Your integration and your data

  • Keep your account details, destination wallet and webhook endpoint accurate and current.
  • Don't put personal data, card numbers or secrets in a payment's reference or metadata field. Those fields are stored with the payment and are included in our error reports, so anything you put there travels further than the payment record.
  • Reconcile. Check what settled against what you expected, and tell us promptly about a discrepancy: the sooner we hear, the more likely it is fixable.
  • Test in a way that doesn't rely on us being correct. During beta, that's not a courtesy, it's the sensible engineering position.

Prohibited use

You may not use the Service to:

  • take payment for anything illegal where you are, where your Buyer is, or where the goods or services are delivered, including stolen goods and stolen data, controlled substances, weapons or their components where prohibited, child sexual abuse material, human trafficking, and fraud of any kind;
  • launder money, conceal the source of funds, evade sanctions, or transact with a sanctioned person, entity or jurisdiction;
  • misrepresent what a Buyer is paying for, who they are paying, or what they will receive;
  • operate a scheme whose returns to earlier participants depend on payments from later ones, or any other offering that is fraudulent on its face;
  • infringe someone else's intellectual property, or sell access to content you have no right to sell;
  • probe, overload, reverse-engineer or circumvent the Service's rate limits, authentication, or the isolation between accounts; attempt to access another account's data; or use automated means to place load on the Service beyond ordinary use;
  • resell, white-label or wrap the Service as your own payment product, or provide payment services to third parties through your account, without a written agreement with us.

You'll also comply with the documentation and with any rate limit or technical requirement we publish.

Breach of this clause is a material breach. We may suspend or terminate your access immediately and without notice, and where a specific payment is implicated we may act on it under When we move funds or intervene. We may also report unlawful activity to the authorities, and we'll comply with a valid legal order without notifying you if the order forbids it.

When we move funds or intervene

You authorise us to take the following actions on In-Flight Funds and on your account, at our discretion, without prior notice where notice isn't practical:

  • return funds to the sending address instead of settling them to you, for example where an intent is disputed, where a payment appears connected to fraud or to a breach of the prohibited-use clause, where the law requires it, or where settlement has failed repeatedly;
  • settle, re-attempt or complete a payment by hand where the automated process could not, including using a different transaction, fee or timing than the automated path would have used;
  • move funds out of a Deposit Address to resolve a stuck, orphaned or unattributable balance, or to recover funds sent to an address in a way the Service does not support;
  • decline to create or to settle a payment;
  • suspend settlement to a Destination Wallet we have reason to believe is wrong, compromised or under someone else's control;
  • suspend or terminate your access, and freeze in-flight settlement, where we reasonably believe it's necessary to prevent loss, fraud or a breach of law.

We'll act in good faith and proportionately, and we'll tell you what we did and why as soon as we reasonably can. We do not commit to acting in any particular case: nothing here obliges us to intervene, to recover funds, or to compensate you for a payment we chose not to settle. Taking one of these actions is not an admission that we were obliged to.

These powers exist because we hold the keys; see We hold your funds while they're in flight. Any action we take under this clause is subject to Limitation of liability.

Blockchain risk

The Service settles on a public blockchain we do not operate and cannot control. You accept the following, and you accept that we are not responsible for any of it:

  • Irreversibility. A confirmed on-chain transfer cannot be reversed, cancelled or amended by us, by you, by the sender or by anyone else. There is no chargeback, no recall and no dispute process.
  • Finality is probabilistic. A block can be reorganised, and a transaction that looked confirmed can be dropped or replaced. We wait for confirmation before treating a payment as paid, which reduces this risk without eliminating it.
  • Network conditions. Congestion, an outage, a validator issue, a fee spike or a halt can delay or prevent detection, settlement or return, for as long as the condition lasts.
  • Protocol change. A fork, an upgrade, a change in consensus rules or a change to a token program can break assumptions the Service relies on, including assumptions about an asset you accept.
  • Asset risk. A token can lose its value, lose its peg, be frozen or blocklisted by its issuer, have transfer fees or hooks that change what actually arrives, be re-minted, or turn out to be worthless or fraudulent. You choose which assets to accept, and you carry that choice.
  • Address risk. Funds sent to a wrong, mistyped or unsupported address, or sent on a different chain, are generally unrecoverable.
  • Public visibility. Every payment is permanently public. See the on-chain clause of the Privacy Policy.

Crypto assets are volatile and the regulatory position around them is unsettled and changing. A change in law could require us to change or withdraw the Service, in a jurisdiction or entirely.

Third-party dependencies and force majeure

The Service depends on third parties: Solana RPC providers, price sources, our authentication and database provider, our hosting providers, and the notification and error-reporting services listed in the Privacy Policy. A failure, outage, rate limit, price change, data error or discontinuation at any of them can degrade or interrupt the Service, and we don't control any of them.

Neither party is liable for a failure to perform caused by something outside its reasonable control, including a natural disaster, war, terrorism, civil unrest, epidemic, labour action, act of government, a change in law, a failure of the internet or of a utility, a failure or fork of the Solana network, a cyberattack, or the failure of a third-party provider. This doesn't excuse an obligation to pay amounts already owed.

No advice, no fiduciary duty

Nothing we provide is financial, investment, tax, accounting or legal advice, and nothing in the Service or the documentation is a recommendation to buy, hold or accept any asset. Our documentation and this website are technical material, not advice on which you should rely in place of a professional.

We act as your service provider and nothing here makes us your fiduciary, trustee, agent, partner, joint venturer or employee. We owe you the obligations written in these terms and no others, and no fiduciary duty arises from our holding In-Flight Funds.

Availability, support and changes

We aim to keep the Service up and settlement prompt. There is no service level agreement, uptime commitment, uptime credit or support response time during beta. Maintenance may be unannounced. Individual features may be unavailable, and the Service may be unavailable entirely for a period.

We may change the Service at any time, including changing, deprecating or removing a feature or an API. During beta we may make breaking API changes. For a change that would break a working integration we'll give you as much notice as we reasonably can, by email and in the documentation, but we can't promise a fixed notice period for an API change while we're in beta. Keeping your integration current is your responsibility.

Support is best-effort, by email and through the dashboard's support form. We'll help where we can, and prioritising anything involving someone's money is our practice rather than a contractual promise.

Beta terms

Zuuppa is beta software handling real money. That combination deserves a plain statement rather than a footnote, so here it is:

  • The Service has bugs we haven't found yet. Some of them will involve payments.
  • Settlement can be delayed, can fail, and can need a human at our end. Some cases in the exceptions clause above are handled by hand today.
  • Data can be wrong. A status, an amount or a report can be incorrect, and a webhook can be missed, duplicated or delivered late.
  • Features can change or disappear, and an API change during beta can break your integration.
  • In the worst case, a defect or a security failure on our side could result in the loss of funds while they are in flight.

By using the Service during beta you accept these risks knowingly, and you accept that they are the reason the Service is offered without warranty and with the liability limit in Limitation of liability. That limit is what makes it possible for a company at this stage to offer the Service at all; if you need a different allocation of risk, we're the wrong provider today, and we'd rather tell you that now.

Two things we ask, in your own interest: reconcile what settles against what you expected, and tell us quickly when something looks wrong. Nearly every payment problem is easier to fix in the hour it happens than in the week after.

None of this reduces our own commitment. We take custody of your funds seriously, we investigate every discrepancy we hear about, and where we get something wrong we'll say so.

Intellectual property and feedback

We keep all rights in the Service, including the API, the dashboard, the SDKs, the documentation, and the Zuuppa name, logo and marks. Subject to these terms, you get a limited, non-exclusive, non-transferable, revocable right to use the Service to take payments, and to use our SDKs in your own application, for as long as these terms are in force. You get no other licence, by implication or otherwise.

Your data, your code, your content and your customer relationships stay yours. We claim no rights over them beyond what we need to run the Service and to meet our obligations under the Privacy Policy.

If you send us feedback, a bug report or a suggestion, you grant us a perpetual, irrevocable, worldwide, royalty-free licence to use it without restriction and without obligation to you. We'd rather have the feedback than the formality, and this clause is only here so a good idea doesn't become a dispute.

You may say that you accept crypto payments through Zuuppa. Please don't use our marks in a way that implies we endorse, vet, underwrite or take responsibility for what you sell, and don't register a domain, app name or mark confusingly similar to ours.

Confidentiality

Each party may learn non-public information about the other: your API keys, your volumes and your integration on our side; our non-public features, pricing and technical detail on yours. Each party will keep the other's non-public information confidential, use it only for the purposes of these terms, protect it with at least reasonable care, and not disclose it except to people who need it and are under a similar obligation.

This doesn't apply to information that is public without a breach, was already known, is independently developed, or is received from someone free to share it. Either party may disclose what the law requires it to disclose, giving the other notice where it lawfully can. These obligations continue after these terms end.

Personal data is governed by the Privacy Policy rather than by this clause.

Data protection

The Privacy Policy sets out what we collect and why, and forms part of these terms. Two points belong here because they are your obligations, not ours.

Buyer data is yours. If you use our SDK to collect a Buyer's name, email or address, we store those details attached to the payment and we act on your instructions in doing so. You decide which fields to collect; all of them are off unless you turn them on. You are the controller of that data: you need a lawful basis for collecting it, your own privacy notice covering it, and you handle any request a Buyer makes about it. See Who is responsible for what and Buyer data.

We don't yet offer a data processing agreement with standard contractual clauses. If your compliance position requires one, tell us and we'll work with you; publishing one is on our pre-general-availability list. Until it exists, these terms and the Privacy Policy are the whole of what governs our handling of your data, and you should decide with that in mind.

Don't send us personal data we haven't asked for. In particular, don't put it in a payment's reference or metadata field, which is stored with the payment and included in our error reports.

Disclaimer of warranties

The Service is provided “as is” and “as available”, with all faults and without warranty of any kind. To the fullest extent permitted by law, we disclaim all warranties, express, implied and statutory, including any implied warranty of merchantability, fitness for a particular purpose, title, non-infringement, accuracy, and any warranty arising from course of dealing or usage of trade.

Specifically, and without limiting the above, we do not warrant that:

  • the Service will be uninterrupted, timely, secure or error-free;
  • any payment will be detected, settled or returned at all, or within any period;
  • In-Flight Funds will be safe from loss, theft, or a failure of our systems, our keys or our staff (we hold them, and holding them is a risk we disclose rather than a risk we insure);
  • any data the Service reports (a status, an amount, a fee, a report or a webhook) is accurate, complete or current;
  • a price we source is the best available, or accurate at any moment;
  • defects will be corrected, or that the Service is free of harmful components;
  • the Service will meet your requirements, satisfy any legal or regulatory obligation of yours, or continue to be offered.

We are not responsible for the value or behaviour of any asset, for the Solana network, for a third-party provider, for your Buyers, for your own keys or configuration, or for a Buyer paying in a way the documentation describes as unsupported.

No advice or information from us, written or oral, creates a warranty not stated here. Where the law doesn't allow a warranty to be excluded, the exclusion applies to the fullest extent it does allow, and any warranty that cannot be excluded is limited to the shortest period the law permits.

Limitation of liability

To the fullest extent permitted by law, neither party is liable for indirect, incidental, special, consequential, exemplary or punitive damages, or for lost profits, lost revenue, lost or corrupted data, lost business, loss of goodwill, or the cost of substitute services, however caused and on any theory of liability, even if the party was told the loss was possible.

To the fullest extent permitted by law, our total aggregate liability arising out of or relating to these terms or the Service, in contract, tort, negligence, strict liability, statute or otherwise, is limited to the greater of the total fees you paid us in the 12 months before the event giving rise to the claim, or $500.

This cap applies to everything, and we want to be plain about the case that matters most: it applies to the loss of funds, including In-Flight Funds we were holding, funds lost to a defect in our software, funds swept to the wrong place, funds we failed to return, and funds lost through a security failure on our side. It applies whether the loss is ours to blame or not, and it may be far less than what you lose. That is the deal being offered, and Beta terms explains why.

Nothing in these terms limits liability that cannot be limited by law, including liability for fraud, fraudulent misrepresentation, wilful misconduct, gross negligence where the law does not permit its exclusion, or death or personal injury caused by negligence.

Any claim must be brought within 12 months after it arose, or it is permanently waived, unless a longer period is required by law. The parties agree that the disclaimers and the limits in this clause are an essential part of the bargain between them, and that they apply even if a limited remedy is found to have failed its essential purpose.

Indemnity

You'll defend, indemnify and hold harmless Zuuppa Inc. and its officers, directors, employees, contractors and agents from and against any third-party claim, demand, action, investigation or proceeding, and any resulting loss, damage, liability, fine, penalty, settlement, cost and reasonable legal fee, arising out of or relating to:

  • what you sell, how you sell it, and your relationship with your Buyers, including any claim that you failed to deliver, misdescribed something, or owed a refund;
  • your breach of these terms, including the prohibited-use clause;
  • your violation of any law, or of anyone's intellectual property, privacy or other rights, including your handling of a Buyer's personal data;
  • your integration, your code, your content, your configuration, and anything done under your account or with your API keys, whether or not you authorised it;
  • any tax, duty or levy you were responsible for and didn't pay;
  • your Destination Wallet, including funds sent to an address you configured incorrectly.

We'll notify you promptly of a claim we want indemnified, and you'll control the defence and settlement, except that you may not settle in a way that admits fault on our part, imposes an obligation on us, or fails to release us fully, without our written consent. We may participate in the defence with our own counsel at our own cost. Your failure to notify us promptly of something you know about doesn't relieve you of this clause.

Term and termination

These terms run from your first use of the Service until either side ends them.

You may stop using the Service at any time, and close your account from the dashboard or by writing to support@zuuppa.com.

We may suspend or terminate your access, or stop offering the Service, at our discretion. Where the reason is a breach, a legal requirement, or a risk of loss to someone, we may do it immediately and without notice. Otherwise we'll give you as much notice as we reasonably can.

On termination:

  • your right to use the Service ends immediately, and we may disable your API keys;
  • we'll make a reasonable effort to let payments already in flight finish settling to your Destination Wallet, or to return them to the sender, unless a breach or the law makes that impossible. Keep your Destination Wallet reachable until in-flight payments have resolved;
  • fees already incurred stay payable;
  • we keep records for as long as the Privacy Policy says, including after your account is closed;
  • the clauses listed in the survival clause below continue to apply.

Closing your account does not delete your payment history from our systems. See Retention, which is honest about how long that is.

Dispute resolution, arbitration and class waiver

Please read this clause carefully. It affects how any dispute between us is resolved, and it gives up rights you would otherwise have.

Talk to us first

Before starting a formal proceeding, you agree to write to us at support@zuuppa.com describing the dispute and what you want, and to give us 30 days to resolve it. We'll do the same before starting one against you. Nearly everything is faster to fix than to litigate, and this step is a condition of the ones below.

Binding individual arbitration

If we can't resolve it, any dispute arising out of or relating to these terms or the Service will be settled by binding arbitration administered by the American Arbitration Association under its commercial arbitration rules, before a single arbitrator, in English. The seat is the State of Delaware, United States, and the arbitrator may conduct proceedings remotely. Judgment on the award may be entered in any court with jurisdiction. The arbitrator decides questions about the scope, enforceability and arbitrability of this clause, except as stated below.

Class action and jury waiver

Disputes will be brought only in an individual capacity. Both parties waive any right to bring or participate in a class, collective, consolidated or representative action, and to have a dispute decided by a jury. The arbitrator may not consolidate claims or preside over any form of representative proceeding, and may award relief only in favour of the individual party seeking it and only to the extent necessary to provide relief on that party's own claim.

If this class-waiver paragraph is found unenforceable as to a particular claim or a particular request for relief, that claim or request is severed from the arbitration and heard in the courts identified in Governing law, while the rest of the dispute stays in arbitration. A court, not the arbitrator, decides whether this paragraph is enforceable.

Exceptions

  • Either party may bring an individual claim in a small-claims court that has jurisdiction, instead of arbitrating.
  • Either party may ask a court for an injunction or other equitable relief to protect its intellectual property or confidential information, or to stop unauthorised access to the Service, without first arbitrating.

Costs

Filing, administration and arbitrator fees are governed by the administrator's rules. Each party bears its own legal fees unless the arbitrator awards otherwise under applicable law.

Governing law

These terms, and any dispute arising out of them or out of the Service, are governed by the laws of the State of Delaware, United States, without regard to its conflict-of-laws rules. The United Nations Convention on Contracts for the International Sale of Goods does not apply.

For any dispute not subject to arbitration under Dispute resolution, arbitration and class waiver, the state and federal courts located in the State of Delaware, United States have exclusive jurisdiction, and both parties consent to that venue and waive any objection to it.

Changes to these terms

We may change these terms. For a material change, meaning one that meaningfully affects your rights or obligations, we'll email the address on your account and update the date at the top of this page at least 30 days before it takes effect. Continuing to use the Service after it takes effect is acceptance. If you don't accept it, stop using the Service and close your account before then.

Corrections that don't change anyone's rights, and changes required by law with immediate effect, apply when published. A change to Dispute resolution, arbitration and class waiver never applies retroactively to a dispute we already knew about.

We don't currently keep a public archive of previous versions. Keeping your own copy of the version you agreed to is a reasonable precaution while we're in beta.

General

  • Entire agreement. These terms and the Privacy Policy are the whole agreement between us about the Service, and replace anything said before. Nothing in a purchase order or a form of yours adds to them unless we've signed it.
  • Severability. If a provision is unenforceable, it's limited or severed to the minimum extent needed, and everything else stays in force.
  • No waiver. Not enforcing something isn't a waiver of it, and a waiver has to be in writing to count.
  • Assignment. You may not assign or transfer these terms without our written consent. We may assign them to an affiliate, or in connection with a merger, financing, or sale of all or substantially all of our assets.
  • No third-party beneficiaries. Nobody other than you and us has rights under these terms; in particular, your Buyers do not.
  • Independent parties. Nothing here makes either party the other's agent, partner, joint venturer or employee.
  • Notices. We'll reach you at the email address on your account, and it's your job to keep it current. You reach us at the address in the contact clause. Email counts as written notice for both of us.
  • Interpretation. "Including" means "including without limitation", and headings are for convenience only.
  • Language. These terms are drafted in English, and the English version governs.
  • Export and sanctions. You'll comply with applicable export-control and sanctions laws, and you won't make the Service available to anyone those laws prohibit.
  • US government. The Service is a commercial item; no government-specific rights are granted beyond these terms.

What survives

When these terms end, for any reason, the following clauses continue to apply, together with any other provision that by its nature should survive:

Fees already incurred also stay payable, and our retention of records continues as described in the Privacy Policy.

Contact

Questions about these terms, a dispute notice, or anything else legal go to support@zuuppa.com. If you already have an account, the support form reaches us with your account details attached, which is usually faster.

Zuuppa Inc. is a Delaware corporation. We don't publish a postal address for notices yet; until we do, email to the address above is effective notice under these terms, and we'll provide a postal address on request.