Terms of Service

Sargo | Website and Kenya Services

Version 5.4 | Effective 24 September 2026

About these Terms. These Terms set the rules for the Sargo website and, when made available to you, the Kenya Services. Sargo Ltd operates the website. A Kenya transaction agreement is formed only with the Kenyan service provider identified in the Service Details presented before you activate or use a regulated Kenya Service. Merely browsing the website, reading product information or connecting a wallet does not itself create a trade or authorise a transfer. Current service availability, including any temporary suspension, is displayed in the Sargo website or application and does not need to be restated in these Terms.

Important for customers. Stablecoins are virtual assets, not guaranteed cash or bank deposits. Their value can fall, and payment, wallet and smart-contract failures can cause loss. Read the order confirmation, fees, deadlines and risk disclosures before authorising a transaction. Never share your private key, recovery phrase, banking password, PIN or one-time password with a merchant or Sargo support.

1. Who provides the services

1.1 Website operator and TopCo. Sargo Ltd is a company registered in England and Wales, company number 15206415, with its registered office at 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom. Sargo Ltd operates the Sargo website and may provide group technology, software, administrative or support services. In these Terms it is referred to as the Technology Company. Its incorporation is not a financial-services authorisation, and it is not the provider of a regulated Kenya Service unless the Service Details expressly and lawfully identify it as such.

1.2 Kenya Service Provider. When a regulated Kenya Service is made available, the contractual provider is the Kenyan incorporated company expressly identified in the Service Details presented to you before account activation or use of that Service. The Service Details state its registered name and number, address, customer contact, relevant regulatory authority, licence or other permission, permitted service scope and effective date. The Kenyan company is referred to as the Kenya Provider. No regulated Kenya Service is offered under these Terms unless the Service Details identify the provider and the permission required for that Service.

1.3 Responsibility follows the service. “We”, “us” and “Sargo” mean the entity providing the relevant service under clauses 1.1 and 1.2, not an unidentified group. Each entity remains responsible for its own acts and legal obligations. Outsourcing software, support, verification or another operational function does not remove the Kenya Provider’s responsibility for its regulated service. A merchant, bank, mobile-money provider, token issuer, wallet provider or other third party is not the Kenya Provider merely because it participates in a Sargo transaction.

1.4 Regulatory status. The Service Details state the regulatory status that actually applies to each regulated Kenya Service, including the relevant authority, licence category and number, permitted scope, material conditions and effective date where applicable. We do not describe an intended licence route, an application, a discussion with an authority, a no-objection communication or group-company incorporation as a licence. If required regulatory details are absent, expired, suspended or no longer cover the Service, that regulated Service is not offered under these Terms.

1.5 Scope. These Terms cover the Sargo website and, when enabled and identified in the Service Details, account services, stablecoin/Kenyan shilling payment-processing and transaction coordination, merchant participation, connected wallets, payment verification, support and order disputes. They may apply across an authorised web application, approved messaging or mini-app channel, and an approved business integration. Separate partner services remain subject to their own identified provider’s terms. A reference to a feature does not make an unavailable, geographically restricted or unauthorised feature available.

1.6 Availability and territory. The website or application displays whether a Service is currently available and any eligibility or geographic restriction. We may suspend, restrict or discontinue a Service where reasonably required by law, regulation, regulatory direction, security, sanctions, financial-crime controls, maintenance, service-provider failure or other circumstances described in these Terms. A suspension does not retrospectively amend completed orders or waive accrued rights, complaints or privacy obligations. Unless the Service Details expressly identify a lawful route for doing so, the Kenya Services are not offered to persons located in the United Kingdom.

2. Your agreement and the documents you receive

2.1 Acceptance and contract formation. Before account activation or first use of a Kenya Service, we present these Terms, the completed Service Details, the Privacy Policy and relevant risk notices in a form you can read, save and reproduce, and obtain an affirmative acceptance action where required. Together, those documents form the standard consumer service agreement for the enabled Service, supplemented by each confirmed order. Simply browsing the website, receiving a message, connecting a wallet or starting an application does not itself authorise a trade, give consent to optional processing or transfer assets. Where applicable law requires an express opportunity to accept or decline, correct errors or receive a durable copy, we provide it.

2.2 Orders. An individual order is subject to the order summary you confirm and the acceptance/funding steps described in that summary. You must be given a reasonable opportunity to identify and correct input errors. Selecting a merchant offer or starting an order is not itself a completed transaction; acceptance is not proof of payment; an on-screen estimate is not a guaranteed executable quote.

2.3 Priority. Mandatory law prevails. These Terms govern the relationship, supplemented by the completed Service Details and the confirmed order’s specific economic and operational terms. An order cannot silently remove protections in these Terms. A separately signed business addendum prevails only for the provisions it expressly varies and only where lawful. The Privacy Policy explains processing; acknowledging receipt of it is not blanket consent. Blog articles, demonstrations and support messages do not vary a contract or override mandatory rights. We remain responsible for legally binding representations and cannot erase a misleading statement by labelling it marketing.

2.4 Records and language. We provide or make available a durable copy of the accepted version and transaction receipt. The contract language is English. We explain essential information in an accessible form and provide available language assistance on request. Where a translation is provided, it must not mislead or narrow mandatory rights; a dispute over wording is resolved under applicable law, not automatically against the customer.

2.5 Data disclosure, retention and transfer. The Privacy Policy and any Service-specific Privacy Details explain the personal-data disclosures, recipients, retention periods or criteria, international transfers and safeguards applicable to the Service. Those notices form part of the information supplied with this agreement but do not create a waiver of data-protection rights. Where a regulatory or transaction record must be retained for a fixed legal period, that requirement is distinguished from optional or shorter-lived data.

3. Eligibility, business use and account maintenance

3.1 Eligibility. You must be at least 18, legally capable of entering this agreement, located in an enabled jurisdiction and permitted to use the service. We may request evidence proportionate to age, identity, residence and risk. Do not evade restrictions through false information, a borrowed account or a disguised location.

3.2 Businesses. An individual accepting for an organisation confirms that they have authority to bind it. We identify the legal entity, authorised representatives, beneficial owners and relevant controlling persons. Access must use approved individual permissions rather than shared credentials. A business is responsible for instructions its properly authorised representatives actually give, subject to our own duties to prevent and address unauthorised access. An individual does not lose consumer protections merely because the interface calls them a merchant or professional.

3.3 Verification and customer due diligence. Where required, customer due diligence is completed before onboarding or enabling the relevant Service. We may require identity and contact information, ownership of a wallet or payment account, business documents, source of funds or wealth where justified, sanctions or other screening, and ongoing due-diligence updates. A request will state what is needed and, where permitted, why. Identity checks do not guarantee that another user is honest, solvent or suitable. We do not require you to disclose banking passwords, PINs, recovery phrases or private keys to our support team.

3.4 Sensitive verification. Any biometric or other sensitive-data step requires the separate information, legal conditions and safeguards described in the Privacy Policy. Consent to these Terms is not biometric consent. The relevant feature must not operate before its lawful verification route and required notices are in place. Refusing an optional method is not proof of fraud; we explain available alternatives and whether necessary verification can otherwise be completed.

3.5 Limits and maintenance. Applicable transaction, daily and monthly limits, supported assets and payment rails are shown before you commit. Changes must have an objective operational, risk or legal basis. We explain a material reduction where permitted and do not use it to confiscate assets or defeat an existing entitlement. You must keep material account information accurate and promptly report changes in authority or compromise. Multiple wallets or business users may be permitted within approved account arrangements; duplicate identities and evasion of limits are prohibited.

4. What the transaction service does

4.1 Buying and selling. You may request to buy a supported stablecoin using Kenyan shillings, or sell a supported stablecoin for Kenyan shillings. A participating merchant or other disclosed counterparty supplies the other side. The order identifies which party sends each asset, to whom, on which rail and network, and the amount each party should receive.

4.2 Customer-selected merchant model. Participating merchants may make offers showing the stablecoin, Kenyan shilling consideration, supported payment method and other relevant order terms. You select the merchant and review the terms before funding. The merchant deals as principal using its own liquidity and sets its own rate. Sargo does not set the merchant’s exchange rate and does not become the buyer or seller of the stablecoin merely because it arranges the order.

4.3 Functions excluded from the Kenya Service. The Kenya Service does not automatically allocate a customer request to a merchant and does not operate first-accept allocation, a central order book, central matching of competing orders, coordinated splitting across merchants, wallets or orders, clearing or netting of participant obligations, customer-to-customer orders, or Sargo own-account dealing. Each order settles separately and whole with the merchant selected by the customer. An order above an applicable limit is refused rather than divided. Sargo does not earn an exchange-rate spread. Any later expansion into one of these functions would require prior regulatory assessment, any necessary permission, updated Service Details and appropriate customer notice before being offered.

4.4 Asset and network identification. Only the exact asset, token contract and network listed on the order are supported. A matching ticker does not establish that two tokens are the same. Base, Celo, USDT, USDC or a legacy token is enabled only when the Service Details and transaction controls support that specific route. Do not send assets on another network or use a bridged token unless expressly instructed. Wallet gas, token approvals and a deposit into the specified smart contract are separate authorisations.

4.5 No implied financial products. Unless separately and lawfully contracted, Sargo does not provide a savings account, lending, staking, an investment mandate, guaranteed yield, insurance, a stablecoin issuance/redemption facility or discretionary management of your assets. Educational content is not personalised investment or tax advice. A merchant may earn its disclosed commercial margin through the rate it independently offers. Sargo does not earn an exchange-rate spread. Merchant compensation is not interest for merely holding a stablecoin.

5. Quotes, fees and payment instructions

5.1 Before confirmation. The order must show the trade direction; token and network; amount payable and receivable; price and its units; whether that price is fixed or indicative; quote expiry; merchant identity or verified trading identifier; beneficiary details; the merchant-set rate; Sargo processing fees; disclosed merchant charges; reasonably knowable payment-rail and network charges; and the applicable deadlines. Where a third-party charge is not known in advance, its calculation or uncertainty must be explained. No hidden charge may be added after commitment. Under the proposed Kenya model, Sargo’s disclosed processing fee is borne by the customer and deducted from the stablecoin leg on successful settlement; Sargo does not earn an exchange-rate spread and does not charge on the Kenyan shilling leg. The current rate and fee incidence must be stated in the Service Details and confirmed order before you commit.

5.2 Estimates and demonstrations. Marketing calculators, simulated liquidity, illustrative settlement animations and merchant earnings examples are not live market data or evidence of transactions. They must be identified as illustrations at the point of display. The binding amount is the amount in the confirmed order, not a changing marketing animation. A demonstrably erroneous quote may be corrected before acceptance; an accepted order is not retrospectively repriced merely because market prices moved. Any cancellation for an obvious error must be lawful, explained and accompanied by appropriate restitution.

5.3 Fiat leg. In the disclosed bilateral order flow, Kenyan shillings move between the payer’s authorised payment account and the beneficiary identified in the order through the named bank or mobile-money provider, such as M-Pesa where that rail is shown as enabled. Follow that provider’s terms as well as the order. Do not pay an altered beneficiary supplied only by chat, pay after an order has expired, split payment without permission, or pay an unapproved third party. Approved corporate treasury and Paybill arrangements must identify the actual payer and beneficiary rather than masquerading as personal accounts. Sargo does not receive the Kenyan shillings, maintain a standing Kenyan shilling balance for you, or have a mandate to operate either party’s bank or mobile-money account.

5.4 Receipts and errors. Keep the order ID and genuine transaction reference. Check actual credited funds in your payment account; a screenshot, SMS, “paid” button or debit notification alone does not establish that the intended beneficiary received cleared funds. Report a wrong amount, duplicate, reversal or wrong beneficiary promptly through the order’s support route. Where an error is ours, we take responsibility under clause 14; reporting promptly is not an absolute contractual forfeiture deadline.

6. Wallets, smart-contract escrow and control

6.1 Wallets. The core Kenya Service is designed for customer- and merchant-controlled self-hosted wallets connected to Sargo, including compatible browser, mobile or WalletConnect-style wallets. Connecting a wallet allows the wallet holder to authenticate and sign permitted instructions; it does not give Sargo the wallet’s private key or general control of its assets. Sargo does not provide a custodial, hosted or embedded wallet as part of the core Kenya Service. Any future Sargo-provided wallet service would require separate regulatory assessment, any necessary permission, updated terms and privacy information before activation. Never send Sargo support or a merchant a plaintext private key, recovery phrase, banking password, PIN or one-time code.

6.2 Smart-contract escrow. An order that uses smart-contract escrow must identify the network, token and escrow contract or an authoritative route to those details before funding. For a customer purchase, the selected merchant funds the agreed stablecoin amount into the order escrow; for a customer sale, the customer funds the agreed stablecoin amount. The deposit can then be released or returned only according to the contract logic and the order terms. Fiat normally moves separately through the disclosed bank or mobile-money rail. Funding a smart contract is not the same thing as depositing money in a bank account, and the token issuer and blockchain remain separate third parties.

6.3 Production escrow control model. A Kenya Service enabled after licensing must use the production control model identified in the Control Notice. Under Sargo’s proposed model, a funded order-specific escrow does not give Sargo a discretionary key to release, divert, split, freeze or refund the funded stablecoin, change its destination, extend its deadlines or upgrade the rules governing that funded order. Movement of a funded deposit is limited to the outcomes prescribed in the deployed contract, such as the parties’ permitted confirmation or mutual-cancellation actions, a valid configured payment-proof outcome, or a defined expiry outcome. The Control Notice identifies the live contract address, permitted actions, any signer or selector arrangements for future versions, and any regulator-required lawful-order control. No new version, new-order pause or administrative change may alter the rules of an already funded order unless applicable law and the disclosed regulator-approved design expressly require otherwise.

6.4 Administrative controls outside funded escrow. Sargo may control customer and merchant enrolment, screening, offer removal, supported assets, transaction limits and whether new orders can be opened. Those controls do not authorise Sargo to use funded stablecoins for proprietary trading, lending, security or another customer’s obligations. Where applicable law requires safeguarding, segregation, freezing, seizure or other customer-asset controls, the Kenya Provider will implement the regulator-approved mechanism and disclose the material effect before the affected Service is enabled. A technical label such as “non-custodial” does not override those legal requirements.

6.5 Release and confirmation. Funding, fiat payment, receipt confirmation, proof generation, approval and blockchain settlement are distinct events. The production escrow releases or returns an order only when the contract conditions are met, including the required party confirmation, configured proof outcome or defined expiry/cancellation path. Before confirming receipt or signing an approval, check the actual payment. A counterparty’s “paid” message, screenshot or silence is not by itself conclusive evidence of cleared funds. Any automatic or time-based mechanism must be disclosed before funding.

6.6 Finality and recovery. A confirmed blockchain transfer may be technically irreversible. That does not extinguish a claim for fraud, erroneous execution, breach of duty or another remedy required by law. Sargo can use only the technical powers actually available in the deployed contracts and wallets; it cannot promise to reverse an independent blockchain or access a key it does not control. A contract upgrade or administrative intervention does not retrospectively remove accrued customer rights.

7. Timing, cancellation, whole-order settlement and reversals

7.1 Production deadlines and clock starts. Under the proposed licensed Kenya Service, unless the Service Details identify a regulator-approved variation for a particular payment rail, the operational windows are: 30 minutes for an M-Pesa payment, or 60 minutes for a bank transfer, measured from the time a funded order becomes ready for the fiat payment to be made and marked as paid; 3 hours for the recipient to confirm receipt, measured from the valid payment-marked event; and 12 hours for the merchant to provide any required cryptographic payment proof, measured from the time the order enters the proof stage and the merchant is notified, or the proof request is otherwise made available through the agreed order interface. The order record must store the applicable deadline for each phase. The interface must show the relevant deadline and consequence before commitment and during the phase. A countdown is informational; the authoritative deadline is the timestamp recorded for the order. We will not retroactively shorten an accepted order’s deadline.

7.2 Before payment is marked. Once an order has been funded, ordinary cancellation before payment is marked requires the mutual cancellation action prescribed for that order unless the order terms lawfully provide another safe-unwind route. If the applicable payment window expires without payment being validly marked, the funded stablecoin is returned in full to the party that funded the escrow. A payment made but not validly marked before the payment deadline may fall outside the automatic settlement path; that does not permit the other party to keep both the fiat payment and returned stablecoin, and the parties remain subject to the dispute, restitution and legal-remedy provisions of these Terms.

7.3 After payment is marked. Once payment has been validly marked, there is no ordinary unilateral cancellation of the funded order. The recipient must confirm genuine receipt or use the disclosed dispute route. If receipt is confirmed within the confirmation window, the escrow applies the successful-settlement outcome disclosed for the order. If receipt is not confirmed and the order enters the proof stage, the proof rules in clause 8 apply.

7.4 Reversals. Banks and mobile-money providers may reverse or restrict payments. You must not request a dishonest chargeback or obtain double recovery. Genuine fraud or statutory payment rights remain available. Where a real reversal occurs, parties must cooperate in establishing the facts and any repayment obligation; Sargo cannot create an unrestricted right to debit unrelated wallet assets or payment accounts.

7.5 Refunds and fees. An agreed refund should ordinarily return to the verified original source or other lawful verified destination. Any change requires security checks. We explain the asset, amount, fees, method and expected time. A full return of the funded stablecoin under the proposed Kenya model carries no Sargo settlement fee. Other undelivered service fees are refunded where required by law or where the service failure makes retention unjustified. An irrecoverable third-party gas charge is distinct from a Sargo fee; responsibility for a charge caused by our error remains subject to clause 14.

7.6 Whole-order settlement and excluded splitting. Each Kenya Service order settles separately and whole with the merchant selected by the customer. Sargo does not split an order across merchants, wallets or orders and does not pool or net customer or merchant obligations. An order above an applicable limit is refused rather than divided. A single-chain order does not authorise a bridge, another token or another network. Any separately proposed third-party funding route or cross-chain feature is outside the core Kenya Service unless the Service Details expressly identify the required regulatory clearance and the feature has been technically validated before use.

7.7 Statutory cancellation and withdrawal. Any statutory right to cancel, withdraw from a distance agreement or obtain a refund remains available. Before you agree, we explain any applicable right, its deadline, how to exercise it and any lawful exception for the particular service. Where immediate performance requires your express request or acknowledgement, we obtain it separately before starting. Price movements or blockchain finality do not create a blanket exemption from every statutory right.

8. Payment evidence, cryptographic proofs and order disputes

8.1 Reporting and preservation. Use the dispute control for the order or contact support with the order ID promptly after discovering a problem. Do not post credentials, bank-session data, identity documents or full statements in a public group. We preserve the relevant order and dispute record and take reasonable steps within our actual technical control to avoid an inappropriate release while a timely genuine dispute is handled under the prescribed production rules. Any technical limitation is explained rather than concealed.

8.2 Merchant-generated payment proof. Where a payment rail is identified as proof-enabled, the proposed production model requires the merchant to generate the technical payment proof from the merchant’s own supported, verified payment account. For a customer purchase, the merchant may be required to prove receipt of the matching Kenyan shilling payment or, only where the Service Details and proof notice identify a supported complete-record method, prove that no matching payment was received during the defined period. For a customer sale, the merchant may be required to prove the matching outgoing Kenyan shilling payment to the customer. The customer does not ordinarily need to provide the merchant with the customer’s bank credentials or banking session for this merchant-generated proof. A valid proof establishes only the facts that the configured source, attestor and verification logic actually checked. It is not proof that every source system is infallible or that a payment cannot later be reversed.

8.3 Authenticated bank-session processing. A proof flow may capture authenticated session material, such as session cookies or authorisation headers, in the merchant’s browser extension or other approved client and encrypt that material before transmission to a designated attestation environment so the attestor can replay a narrowly scoped bank request and inspect the resulting source record. This is different from saying that no session credential ever leaves the device. The feature notice must explain the participating attestation service, the scope and duration of access, what source response is processed, what is retained, and any international transfer. Sargo support, customers and merchants must never ask another person for a banking password, PIN, one-time password or unencrypted session credential.

8.4 Non-receipt proofs. An automated non-receipt outcome may be used only where the applicable Service Details and proof notice identify a validated method that can examine the complete defined source records needed to establish non-receipt for the relevant period. The absence of a transaction from a partial page, selected result, incomplete query or unsupported proof flow is not sufficient. If a reliable complete-record non-receipt proof is not enabled for a payment rail, Sargo must disclose the alternative dispute process for that rail and must not present an automated non-receipt proof as available.

8.5 On-chain proof registration. Where enabled, Sargo’s proof verifier can register a proof on a public blockchain. The verifier contract stores registration state and proof counts, but the registration transaction can include the proof’s parameters and context in transaction call data. Those strings can contain extracted payment or account fields and can therefore be publicly retrievable even if the contract does not separately store the strings in contract state. Before any such registration is enabled for a customer flow, the interface must clearly identify the fields that will be submitted, minimise them to what is necessary, explain the irreversible public-disclosure risk, and obtain any legally required affirmative choice. Direct identity images, passwords, PINs, one-time codes and raw bank statements must not be published as part of a Sargo proof.

8.6 Proof deadline, availability and non-response. The production proof window is 12 hours from the proof-stage timestamp described in clause 7.1. A merchant using a proof-enabled rail must act promptly enough to complete the required proof within that window. If the merchant does not provide a valid required proof before the proof deadline for reasons attributable to the merchant, the no-proof outcome in clause 8.7 applies. If a merchant makes a timely genuine attempt but the Sargo proof service, designated attestation environment or supported payment source is unavailable or malfunctioning for reasons not attributable to the merchant and that failure prevents completion, the no-proof outcome must not be triggered solely because of that outage. The system must record the unavailable state and apply the objectively disclosed pause, extension or alternative route. The merchant must resume the proof promptly when the route becomes available. An outage exception does not create an indefinite extension or excuse a merchant’s own unsupported account, lost credentials, deliberate delay or failure to maintain access to the verified payment account required for an enabled rail.

8.7 Prescribed proof and no-proof outcomes. The following rules apply to the proposed licensed production model where the relevant proof path is enabled and disclosed for the order:

The no-proof outcome is a contractual escrow default for the prescribed order flow; it is not by itself a finding that the merchant acted dishonestly. A technical settlement does not remove complaints, restitution, fraud remedies or other rights required by law.

8.8 Human review and other remedies. Where a proof satisfies the disclosed production verifier, the prescribed contract outcome may occur automatically without a discretionary Sargo reviewer allocating the funded escrow. A customer or merchant may nevertheless challenge a significant proof-assisted outcome on grounds such as a configuration error, compromised source, duplicate or replayed event, mistaken beneficiary, reversal, outage or other credible inconsistency. Human review must be capable of correcting off-chain records, restricting future activity, arranging a lawful remedy or escalating a technical defect; it cannot promise to redirect an immutable funded escrow contrary to the prescribed production contract. Technical settlement and legal entitlement remain distinct: an on-chain outcome does not prevent a court, regulator or Sargo from providing another lawful remedy where required.

8.9 Proof-enabled and other payment rails. The Service Details identify which payment methods and directions are proof-enabled. A merchant must not be subjected to the no-proof default merely because Sargo offered a rail for which the required proof capability was not enabled or reasonably available. A non-proof-enabled rail must have its alternative evidence and dispute route disclosed before the merchant accepts orders on that rail.

9. Merchant and business participation

9.1 Independent activity. Merchants transact for themselves or their disclosed business unless an expressly approved agency arrangement says otherwise. They are not Sargo employees or agents merely by participating. They must hold any permission required for their own activity; a Sargo authorisation does not automatically extend to them. Sargo retains its own selection, monitoring, consumer-protection and regulatory obligations.

9.2 Merchant duties and proof capability. A merchant must provide accurate identity and beneficiary information, quote honestly, maintain the capacity advertised, accept only orders it can perform, comply with agreed payment deadlines, handle customer information lawfully, keep reliable transaction records and cooperate with genuine disputes and lawful checks. If the merchant accepts orders on a payment rail designated as proof-enabled, it must maintain the supported verified payment account and practical access needed to generate the required proof, initiate any requested proof promptly, and complete it within the applicable proof window unless clause 8.6 applies. By accepting an order on a proof-enabled rail, the merchant accepts the disclosed proof and no-proof settlement rules for that order. A merchant must not fabricate liquidity, create sham activity, manipulate ranking, collude on prices, publish false reviews, fabricate or reuse a proof, or pressure a customer to release before genuine receipt.

9.3 Counterparty information. A merchant may use customer details only to perform the order, meet its own identified legal obligations, prevent fraud or resolve a genuine dispute. It must not sell them, build unrelated marketing lists, contact customers for unrelated promotions or post them in public groups. It is responsible for its own controller obligations where it determines those purposes. An integration processing only on another party’s instructions requires the appropriate separate data-processing terms.

9.4 Earnings and incentives. Turnover, utilisation, merchant margins, earnings and response-time examples are illustrations, not promised income. Liquidity and costs vary, and losses are possible. Any fee rebate, referral reward, loyalty scheme or promotional payment requires separate clear rules covering eligibility, amount, timing, limits, taxes and fair anti-abuse controls. We do not retroactively remove an earned entitlement through an undisclosed rule. No incentive may be used to evade restrictions on interest or unlawful promotions.

9.5 Integrations and messaging. API credentials and integration permissions must be scoped and kept secure. Automated agents and bots may submit only instructions within a verified mandate and applicable rate limits. Merchant-facing notifications and interfaces must minimise personal data and disclose customer payment information only where the customer has selected that merchant or the merchant is otherwise entitled to act on the specific order. An integration may not silently appoint Sargo to act as principal or move assets beyond the agreed mandate.

10. Security, anti-circumvention and prohibited conduct

Use reasonable care with your device, passwords, wallet permissions, payment accounts and recovery material. Verify the official service address, network, token, beneficiary and order details. Report a suspected compromise promptly through support and use your wallet or payment provider’s own security controls where appropriate. A valid credential, device session or blockchain signature is evidence of an instruction, but is not an irrebuttable conclusion that every action was authorised where credible compromise evidence exists.

Do not use the service for money laundering, terrorism or proliferation financing, sanctions evasion, fraud, stolen funds, impersonation, illicit goods or services, harassment, unlawful surveillance or infringement. Do not submit false verification material, reuse another person’s proof, exploit another customer’s data, manipulate prices, interfere with proof systems, attack service availability or attempt to bypass technical or regulatory controls. Legitimate security research should be reported responsibly without accessing another user’s information or moving their assets. Nothing here prevents lawful reporting to an authority.

Do not move an active Sargo order, payment instruction or settlement off-platform, substitute a beneficiary through chat, or arrange a side settlement in order to bypass Sargo’s security, compliance, dispute, fee or recordkeeping controls. This does not prevent parties from making the fiat payment through the bank or mobile-money rail expressly identified in the order, or from communicating information that the authorised Sargo flow expressly requires.

A breach may justify proportionate restriction, but does not entitle Sargo to impose an arbitrary fine, confiscate unrelated assets or retain money without a lawful basis.

11. Restrictions, compulsory orders and service interruption

11.1 Proportionate restrictions. We may refuse a new instruction or restrict a feature where reasonably necessary to comply with law, protect security, investigate credible fraud, complete required verification, enforce a material breach or deal with operational failure. We consider less restrictive measures and review continuing restrictions. We give reasons and a review route unless prohibited or likely to prejudice a lawful investigation. We may not disclose suspicious-activity reporting where doing so is unlawful.

11.2 Freezing and seizure. We comply with valid orders and other compulsory legal requirements directed to us, preserve relevant records and cooperate with competent authorities. The Control Notice describes what can actually be restricted or transferred and by whom. These Terms do not invent a private-key capability or excuse a statutory obligation because the design is described as non-custodial. Any gap between a required control and the deployed architecture must be resolved before the affected service is enabled. A restriction is not a forfeiture or determination of guilt.

11.3 Continuity. We take reasonable steps to maintain and restore the service, communicate material incidents, protect pending orders and provide available alternative support. We do not promise uninterrupted operation. Maintenance or delisting must be managed fairly, with reasonable notice and an orderly exit where possible; urgent security or legal action may require less notice. We will not force an undisclosed new asset conversion simply because a token or network is being discontinued.

11.4 Force majeure / events outside reasonable control. A party is not responsible for delay to the extent it is directly caused by an event beyond its reasonable control that it could not reasonably prevent or overcome. It must notify the other party where practicable and mitigate the effect. This does not excuse poor security, inadequate preparation, payment already owed, an accrued refund or other non-excludable duty. Where continued performance becomes impossible, unperformed obligations and assets are unwound fairly and lawfully.

12. Closure, inactivity, death and incapacity

12.1 Your closure request. You may stop creating orders and ask to close your account through support. Closure does not itself cancel an existing paid or funded order, erase required records or affect an accrued claim. We explain outstanding obligations, relevant retention and any lawful restriction. There is no account-closure penalty merely for exercising a legal right.

12.2 Our termination. Except for justified urgent restrictions, we give reasonable notice, normally at least 30 days, of ending ongoing access. We identify how open orders will settle or unwind and how to obtain records and recover entitlements through available lawful mechanisms. Fees for undelivered services are handled under clause 7.4. A new fee cannot be imposed solely to recover assets on exit unless lawfully agreed and proportionate.

12.3 Dormant accounts. We may mark an account inactive after 12 months without account activity and notify its recorded contact. This is an account-security measure, not a transfer of ownership or a statutory definition of abandoned property. Re-activation may require verification. We do not charge an undisclosed inactivity fee, appropriate wallet assets or sweep an escrow solely because an account is inactive. Any unclaimed-asset obligation is handled under applicable law with records and notices required by that law.

12.4 Death or incapacity. An authorised personal representative, executor, administrator, attorney or guardian should contact support. We verify identity and legal authority, restrict misuse where justified and cooperate in identifying and administering the relevant contractual entitlements under applicable succession or capacity law. We do not ask representatives to impersonate the customer or guarantee recovery of a self-custodied wallet whose keys nobody can access. Personal-data disclosures are limited to what is lawful and necessary. A verified entitlement is not forfeited merely because the original holder has died.

12.5 Business wind-down. Insolvency or cessation does not convert customer assets into Sargo’s own property. We follow applicable safeguarding, insolvency and regulatory requirements and provide information about pending orders, records and available recovery routes. Segregation is a safeguard, not an unconditional promise that recovery will be instant or free of insolvency risk.

13. Risk information

Stablecoins can lose their reference value; an issuer can fail, freeze a token or restrict redemption. Sargo does not guarantee issuer reserves or a right to redeem with an issuer. Network congestion, forks, outages, bridges, smart-contract flaws, compromised administrators, wallet errors and malicious approvals can delay, misdirect or permanently lose assets. A correctly executed blockchain transaction does not prove that the fiat leg is final.

Fiat providers can delay, reject, reverse or freeze payments. Merchants can default or act fraudulently despite verification. Liquidity and prices can change; a quote may expire before acceptance. Public wallet activity can expose transaction relationships and permit profiling. Changes in law, authorisation or token eligibility can affect availability. A bank, wallet, network or token name does not imply an endorsement or partnership.

Do not treat a Sargo transaction as a protected bank deposit or assume deposit insurance, an investor-compensation scheme, an ombudsman award or commercial insurance will reimburse it. Any applicable protection must be identified accurately for the particular service. These warnings do not transfer to you losses for which Sargo is legally responsible.

14. Our responsibilities, service commitments, warranties and liability

14.1 Service commitment and warranties. We will provide our service with reasonable care and skill, in accordance with this agreement and applicable law. Any express warranty stated in the confirmed order or Service Details applies according to its terms; we do not create a guarantee of stablecoin value, merchant performance or uninterrupted blockchain availability unless expressly and lawfully stated. We remain accountable for duties that cannot lawfully be delegated to a merchant, software vendor or verifier. We take reasonable steps to correct our errors and provide legally required remedies. A “beta”, “as available” or technology label does not remove these obligations.

14.2 Responsibility for loss. We are responsible for loss to the extent caused by our breach, negligence or other legal responsibility, subject to applicable rules of causation, foreseeability and mitigation. We do not automatically accept a counterparty’s debt merely because it uses the service, but we cannot disclaim loss caused by our own selection, security, execution, safeguarding or dispute-handling failures. Your genuine and reasonably foreseeable loss of transaction funds is not automatically excluded as indirect loss.

14.3 Non-excludable matters. Nothing excludes or restricts liability for fraud or fraudulent misrepresentation; death or personal injury caused by negligence; deliberate wrongdoing; misuse or misappropriation of customer assets; a liability or remedy that cannot lawfully be excluded; or your statutory consumer, payment-service or data-protection rights. These Terms do not impose a low fixed or fee-only liability cap that would defeat a mandatory remedy. Nor is our monetary responsibility determined solely by whether a network transfer can be reversed.

14.4 Business losses. For genuine business customers, and only so far as lawful, we do not assume liability for speculative profits or losses too remote to be recoverable under applicable law. This is not an exclusion of direct lost funds, accrued payments, reasonable remediation costs or any matter in clause 14.3. Any separately negotiated commercial cap must be expressly agreed and legally valid; none is silently incorporated from marketing or another customer’s contract.

14.5 Your responsibility and indemnity. Consumers do not give a general indemnity against all claims connected with their use. They remain responsible for their own fraud and other conduct to the extent the law provides. A business customer must reimburse the relevant Sargo entity for a third-party claim directly caused by that business’s fraud, wilful unlawful conduct or knowing infringement in content it supplied, but only to the extent fairly attributable to that conduct. The claimant must give reasonable notice, mitigate loss, allow the business reasonable participation in the defence and not admit liability or agree a settlement binding on the business without its consent, not unreasonably withheld. This does not cover Sargo’s own fault or shift a non-transferable regulatory duty or penalty.

15. Complaints and escalation

15.1 Contact. Contact support@sargo.io, the in-application support route, or the postal contact of the relevant provider in the Service Details. Mark an urgent payment or security problem clearly and include an order ID, not passwords or full identity documents. The provider must maintain functioning, monitored contacts. You do not need a lawyer, a payment or a completed trade to raise a complaint.

15.2 Process. We aim to acknowledge a complaint within two working days, investigate without undue delay and provide a reasoned outcome, usually within 30 calendar days. For complaints about the licensed Kenya Services, we provide a progress update no later than 21 calendar days after receipt and at intervals no longer than 21 days while unresolved. These service commitments do not extend a shorter statutory deadline. Where more time is justified, we explain the outstanding issues and expected next step rather than postponing the investigation until a target date.

15.3 Outcome, records and review. Our response explains the findings, any restitution or corrective action, and available internal review and external routes. A person not responsible for the disputed initial decision should conduct a review where practicable. For the licensed Kenya Services, we maintain the complaint register and records of complaints and action taken for at least seven years, or any longer period lawfully required. We use substantiated issues to improve controls. Privacy complaints and rights requests also have the specific procedures in the Privacy Policy.

15.4 External rights. You may contact the regulator with jurisdiction over the service, the Office of the Data Protection Commissioner for Kenyan data matters, the Information Commissioner’s Office where UK data law applies, a competent consumer authority or a court. The Service Details identify the financial regulator and current route appropriate to the permission actually held. Internal complaints and voluntary mediation do not suspend a limitation period unless law or a valid agreement says so, and are not a mandatory barrier to urgent relief or a statutory complaint.

16. Intellectual property and communications

We or our licensors retain rights in Sargo software, branding and website material. You receive a limited right to use the service lawfully; this does not transfer our intellectual property. You retain rights in material you provide and grant only the permissions reasonably needed to operate, protect and document the service. We do not acquire ownership of your personal data or your wallet’s contents. Do not publish private counterparty information when posting a review. Honest criticism, lawful reporting and evidence for a claim are not prohibited.

Service notices are sent through the approved contact methods in your account and remain accessible where practicable. An unauthenticated social-media post or forwarded group message is not an instruction to change a beneficiary or release funds. Optional marketing is separate from necessary service messages. We do not regard a notification as conclusively delivered merely because our system attempted to send it.

17. Changes and transfer of the business

We may change these Terms for a genuine legal, security, product or operational reason, which we explain. We normally give at least 30 days’ advance notice of a material adverse change, supply the revised text and effective date, and allow you to stop new use and close without a new penalty. A shorter period is used only where justified, such as urgent law or security needs. Changes do not retrospectively alter completed orders, accrued rights or a dispute. Where fresh acceptance is required, we obtain it; silence is not consent to unrelated sensitive processing.

A transfer of a service, contract or customer relationship between Sargo group companies is not automatic merely because they share a brand. We identify the new legal entity and its responsibilities, obtain any necessary regulatory approval and customer consent or novation, give appropriate privacy information, and preserve accrued claims and open complaints. A transfer cannot reduce your mandatory rights. You may not transfer your account to another person without approved verification and any necessary agreement.

Version history. Version 5.4 replaces the Terms of Service dated 12 June 2026 previously published on sargo.io. We retain prior versions needed to establish which terms applied to an earlier order or period and make an applicable prior version available on reasonable request.

18. Governing law and courts

Kenyan law governs the Kenya Services. The website-only and separately allocated Technology Company services are governed by the laws of England and Wales, unless a signed service-specific agreement states otherwise. This allocation does not remove mandatory protection that applies to you under another applicable law, including mandatory UK consumer protection where relevant.

The courts of Kenya have non-exclusive jurisdiction over Kenya Services disputes; the courts of England and Wales have non-exclusive jurisdiction over Technology Company service disputes. A consumer retains any right to bring proceedings in, or be sued only in, a court designated by applicable consumer-jurisdiction law. There is no compulsory arbitration, class-action waiver or mandatory 30-day standstill in these Terms. Voluntary mediation is available only by agreement and does not prevent urgent legal action.

If a provision is unenforceable, the remainder continues only insofar as it can operate fairly and lawfully without it. A court’s invalidation is not an invitation to rewrite an unfair provision automatically to the maximum restriction permitted. Failure to enforce once is not a permanent waiver. Nothing in an entire-agreement clause excludes fraud, legally binding pre-contract information or mandatory rights. Provisions necessary to settle open orders, preserve lawful records and resolve accrued claims survive closure to that extent.

Getting ready for what’s next

Platform is
paused.

The proposed Kenya service is subject to the required permissions and service details before activation.

You can still explore how Sargo works and register your interest in becoming a merchant ahead of launch.

Register merchant interest

Stay tuned. For launch enquiries, email support@sargo.io.