Terms and conditions

These terms and conditions govern access to the www.cowriepay.io website, to the dashboard and to the CowriePay application programming interface, operated under that trade name by COWRIEX, a Societe par Actions Simplifiee (SAS) with a share capital of 2,000,000 FCFA, registered with the Trade and Personal Property Credit Register of Abomey-Calavi under number RB/ABC/25 B 10127, tax identification number 3202583046288, with its registered office at Ilot 1678, Quartier Seme, Parcelle q, Maison YVES AOULOU, Abomey-Calavi, Benin (hereinafter "COWRIEX").

Together with the Acceptable use policy, the Risk disclosure and the Privacy policy, they form the entire agreement between the parties. In the event of a conflict, these terms prevail, unless expressly stated otherwise.

The service is reserved for persons acting for professional purposes, whether legal entities or natural persons duly registered as such. It is not intended for consumers, that is, persons acting for purposes outside their professional activity. Creating an account or using the API constitutes acceptance of the whole contractual set.

The version in force is the one published on this page. Each document carries a version number and a date of last update.

• The Client: the person, whether a legal entity or a natural person, acting for professional purposes, holding the account and party to this contract.
• Users: the individuals the Client authorises to access the dashboard or the API.
• End customers: the people to whom the Client provides its own services and for whom it uses CowriePay.
• Workspace: the Client's environment, comprising its wallets, balances, keys and settings.
• Digital assets: the supported assets and networks, listed in the dashboard and in the technical documentation.
• Sandbox: the test environment, run on test networks, whose assets have no value.
• Production: the live environment, run on the main networks.

Opening and verification

Opening an account requires accurate information, kept up to date. Access to production is subject to the completion of a business-verification procedure, including the identification of the Client's beneficial owners, directors and signatories, and the provision of the requested supporting documents.

Until that procedure has been completed, the Client has access to the Sandbox environment. We may refuse to open an account, request further material at any time, and make access to certain functions subject to additional checks.

Access security

The Client is responsible for the confidentiality of its Users' credentials, authentication factors and API keys, and for the actions carried out with them. It is for the Client to withdraw access promptly from people who leave its organisation and to notify us without delay of any suspected compromise.

Any duly authenticated transaction is deemed to come from the Client. We carry out the instructions we receive without having to assess whether they are appropriate.

CowriePay provides digital-asset custody and payment infrastructure:

• creation of multi-network deposit addresses, which can be attributed to the Client's end customers;
• detection of payments received at those addresses, their confirmation and their crediting to the workspace;
• issuance of outbound payments to destination addresses;
• reporting of transactions through the dashboard, the API and signed notifications.

Two environments are offered. The environment is determined by the API key used, not by a different address. The Sandbox runs on test networks and the assets circulating there have no value whatsoever: they can give rise to no claim. A test-asset dispenser is made available, within amount and frequency limits that we set.

Opening a given network is our decision. A network may be closed, temporarily or durably, in which case wallet creation and payment issuance on that network are refused. Transactions already under way continue.

COWRIEX holds the digital assets entrusted by the Client and takes responsibility for doing so. The Client retains ownership of its assets; we hold the technical means of dealing with them.

How assets are held

• Each end customer may be given a dedicated receiving address. Those addresses are receiving points: once an incoming payment is confirmed, the funds are consolidated into pooled accounts. No separate on-chain custody account is therefore maintained per Client or per end customer.
• Each Client's claim is identified at all times in an internal ledger, distinguishing available, pending and locked balances.
• Before any movement to our dormant reserve, an automatic control reserves the whole of the amounts owed to Clients, plus a safety margin. That control blocks the operation rather than allowing it where there is doubt.
• The keys allowing assets to be moved are isolated in a separate signing component that the main application cannot access. The dormant reserve is held offline.

What we do not do

We do not use Clients' assets for our own account. We do not lend them, pledge them, invest them or derive any yield from them. No interest or return is owed to the Client on the balances held.

CowriePay is not a bank, a payment institution or an electronic-money institution, and no deposit-guarantee scheme therefore covers digital assets.

COWRIEX must return to the Client, on request and subject to articles 11 and 13, the digital assets recorded in its balance. That obligation to return is an obligation of result.

The list of supported assets and networks appears in the dashboard and in the technical documentation. It changes. An asset is supported only on the networks indicated: the availability of an asset on one network says nothing about its availability on another.

Sending an unsupported asset, or sending a supported asset over an unsupported network, generally results in an unrecoverable loss. We are under no recovery obligation and, in most cases, have no technical means to do so. Any costs incurred at the Client's request in attempting a recovery are borne by the Client.

In the event of a network split, a free token distribution or a contract migration, we are not required to support the resulting chain, the distributed tokens or the new contract. No right, claim or privilege arises for the Client on that account.

We may cease to support an asset or a network, in particular for security, compliance or availability reasons. We inform the Client with reasonable notice, except where urgency or a legal obligation prevents it, and set out how the balances concerned may be withdrawn.

A payment received at a deposit address is credited after a number of confirmations specific to each network, and after the screening provided for in article 11.

Minimum amounts

A minimum amount applies per asset. A payment received below that amount is recorded but not moved to our accounts: it remains at the receiving address and is not added to the available balance until the amounts received at that address exceed the threshold. The applicable minimum amounts are published in the technical documentation.

Chain reorganisation

A network reorganisation may invalidate a payment that has already been credited. Our systems detect this and alert our team; the balance is corrected manually. The Client acknowledges that between detection and correction the displayed balance may not match the state of the chain, and undertakes not to deal with a balance it knows to arise from an invalidated transaction.

Payment errors

The Client is responsible for the instructions it gives its end customers, in particular the asset, network and address communicated. A payment received in error at another Client's address cannot give rise to any automatic restitution.

An outbound payment may be initiated from the dashboard or through the API. It is final once broadcast to the network: it cannot be cancelled or recalled.

Available controls

• Destination allowlist: once the workspace has been opened to production, payments may only be issued to previously registered addresses.
• Cooling-off period: a newly registered destination may only be used once a period has elapsed, set by default at twenty-four hours and configurable by the Client within a range we determine. Disabling the allowlist takes effect only once that same period has elapsed.
• Caps: a per-transaction cap and a rolling twenty-four-hour cap apply per asset. The Client may lower them itself; raising them above the default values requires our agreement.
• Second-person approval: this option, disabled by default, makes the issuance of a payment above a threshold set by the Client subject to approval by a second User, distinct from the initiator.
• Strong authentication: a payment initiated from the dashboard always requires a second factor. Any settings change that weakens one of the controls above also requires one.

The allowlist, the cooling-off period, the caps and second-person approval apply to the production environment and are not implemented in the Sandbox, whose assets have no value. The second-factor requirement for a payment initiated from the dashboard and the screening of destinations, by contrast, apply in both environments.

A point to note on API payments

A payment initiated through the API is authorised solely by the API key holding the corresponding scope: no second factor is required. Where second-person approval is enabled it also applies to those payments; the rule preventing an initiator from approving their own transaction cannot apply, however, since a payment initiated by an API key has no identified initiator. It is therefore for the Client to protect its keys, restrict their scope and, where appropriate, limit their use to the IP addresses of its systems.

Service fees

Our fees are communicated at onboarding and displayed in the dashboard. They comprise a commission on incoming payments, calculated as a percentage with a per-transaction minimum that varies by network, and a flat fee per outbound payment. They may vary by asset, network and volume.

Fee estimates provided by the API are indicative. The fees actually applied are those in force when the transaction settles, and may differ from an earlier estimate.

Network fees

The network fees required by blockchains are in principle borne by us: the Client does not need to hold a network's native asset in order to receive or send tokens on that network.

There is one exception, and it is expressly brought to the Client's attention here: for incoming payments denominated in a network's native asset, namely ETH on Ethereum and BNB on BNB Chain, a reserve corresponding to the network fees needed to move the funds to our accounts is deducted from the amount received, before the commission is applied. The amount credited to the Client is therefore lower than the amount received, by that reserve and by the commission. The reserve is estimated at the time of the transaction and varies with the state of the network.

Monthly minimum commitment

A monthly fee floor, known as a monthly minimum commitment, may be agreed with the Client in a negotiated contract. It cannot be taken out from the dashboard or through the application programming interface: it arises only from that agreement, whose terms it reflects. In the absence of such an agreement, no floor applies.

The commitment is assessed by calendar month, counted in coordinated universal time. The first and last months are prorated to the number of days the commitment covers, the day it takes effect and the day it ends both being counted; the prorated floor is rounded to six decimal places, to the nearest, a half unit being rounded up.

The monthly total compared with the floor is the sum of the service fees charged to the Client during the month. Excluded from it are: fees taken in a network's native asset, no conversion rate being applied; fees relating to the Sandbox environment, whose assets have no value; and the adjustments defined below, a floor not being able to feed on its own catch-up. Fees taken in a stablecoin count at face value.

Where that total is lower than the floor applicable to the month, a catch-up adjustment equal to the difference is due. An adjustment is drawn up for every closed month, including where the floor is met: it is then not due and no amount is payable. An adjustment that is due remains open until it has been settled in full; it is settled once it has been.

The adjustment is settled as provided for in the contract. The Client's available balance is debited automatically only where the contract expressly provides for it; failing such a stipulation, no debit is made. Where it is provided for, the debit is limited to the available balance in the agreed settlement asset: it can never make that balance negative, and any part not debited remains payable. The issuance of each adjustment is brought to the Client's attention: where the Client has configured the corresponding notification, it is sent to their systems as set out in article 10, and the adjustment remains available in the dashboard for as long as the commitment is in force.

Terms

Fees are deducted from the amounts processed; an adjustment due under a monthly minimum commitment is settled as described above. Any taxes due are borne by the Client. We may change our pricing on reasonable notice to the Client; a Client refusing a pricing change may terminate as set out in article 14.

API keys

• A key belongs to one workspace and one environment. The secret is disclosed once only, at creation, and cannot be retrieved afterwards: it is for the Client to keep it.
• Each key carries a scope limiting the operations it authorises. The Client must grant the narrowest possible scope.
• A key may be given a list of allowed IP addresses and an expiry date. Neither is imposed by default, and there is no automatic rotation mechanism: renewal is carried out by creating a new key and then revoking the old one.
• Requests are signed and timestamped; a request whose timestamp differs too much from server time is rejected, as is a replayed request.

Notifications

Notifications sent to the Client's systems are signed. The Client must verify that signature before processing a notification, and handle redeliveries idempotently. The same notification may be sent more than once.

On failure, delivery is retried a limited number of times, at increasing intervals, over roughly a quarter of an hour. After those attempts the notification is no longer resent automatically: it is for the Client to reconcile using the API. When a signing secret is renewed, notifications are signed with both the old and the new secret during an overlap period.

Usage limits

Rate limits apply to API calls. Exceeding them results in a temporary rejection. The Client must handle those rejections and must not circumvent them. We may adjust these limits, and change the API, informing the Client, as set out in article 12.

What we do

• The origin address of every incoming payment, and the destination address of every outbound payment and refund, are screened against a list of designated addresses before, respectively, any credit and any issuance.
• If screening cannot run, the transaction is held by default: funds are neither credited nor sent. That hold is deliberate.
• A match results in the transaction being held and reviewed by our authorised staff, who alone may release or reject it.
• Sensitive actions are recorded in an append-only register: entries can be read but can be neither amended nor deleted.

What the Client undertakes to do

• comply with the Acceptable use policy;
• verify the identity of its end customers in accordance with the regulation applicable to it, and not give access to the service to unverified third parties;
• respond to our requests for information, including on the origin of funds and the identity of beneficiaries, within a reasonable time;
• inform us without delay of any change affecting its shareholding, its beneficial owners, its activity or its regulatory situation.

The Client acknowledges that these obligations may lead us to hold, refuse or block a transaction, including a legitimate one, and that where the law prohibits us from disclosing the reason for a measure or the existence of a report, we comply with that prohibition.

The service is provided as is and as available. We endeavour to maintain high availability without guaranteeing uninterrupted access or the absence of errors. Interruptions may occur for maintenance, during an incident, or because of a third party or a network the service depends on.

We may change the service and the API. Changes incompatible with existing integrations are subject to reasonable notice and, where possible, a period during which the previous behaviour remains available. Security fixes may be deployed without notice.

We may suspend all or part of access to the service, without notice where circumstances require:

• on a breach of this contract or of the Acceptable use policy;
• on suspicion of fraud, compromise of an access or unauthorised use;
• to comply with a legal obligation, a legal request or a demand from a competent authority;
• on an established risk to the security of the service or to the assets held in it;
• on non-payment after a formal notice has gone unheeded.

A suspension of access is notified to the Client by email. It does not affect their balances, which remain owed to them; access to the service being cut, the Client can no longer initiate any operation for as long as it lasts.

A freeze may also be applied to the workspace, in which case outbound payments are refused while balances are unaffected. We inform the Client where the applicable law permits. The law may require us to disclose neither the measure nor its reason, in particular where a report to a competent authority is in progress; in that case the information is deferred until that constraint ends. We lift the measure as soon as its cause has gone.

The Client may terminate at any time, without cause, by informing us in writing. We may terminate on thirty days' notice, and without notice in the event of a serious breach, a legal obligation or an established risk.

On termination, the Client has a reasonable period, which may not be less than thirty days, to transfer its balances to addresses of its choosing, subject to the controls in article 8 and to the measures in articles 11 and 13. Fees due remain payable, including the last month's adjustment under a monthly minimum commitment, prorated as set out in article 9.

We cannot return assets subject to a blocking measure imposed by law or by a competent authority. Record-keeping obligations survive termination, as set out in the Privacy policy.

To the extent permitted by law, our total liability under this contract, on any basis whatsoever, is capped at the higher of the following two amounts: the total fees, commissions and reserves deducted from the Client during the twelve months preceding the event giving rise to the claim, or the value of the Client's digital assets held by us at the time of that event. The event giving rise to the claim means the date on which the damaging event occurred or, if later, the date on which the Client became aware of it.

Indirect damages are excluded, in particular loss of profit, loss of opportunity, loss of custom, reputational harm and loss of data, as are losses arising from:

• an erroneous instruction from the Client, in particular as to the asset, the network or the destination address;
• the compromise of the Client's credentials, authentication factors or API keys;
• a change in the value of a digital asset, including a stablecoin losing its peg;
• the conduct of an asset issuer, in particular the freezing or invalidation of tokens;
• an incident affecting a blockchain network;
• a measure taken under article 11 or article 13.

These limitations do not apply to fraud, to wilful misconduct, to gross negligence, to breach of the obligation to return assets set out in article 5, to misappropriation of Clients' assets or their commingling with our own, or to damages that cannot be excluded by law.

The Client indemnifies COWRIEX against any third-party claim, including from its end customers and from authorities, arising from its breach of this contract or of the Acceptable use policy, from unlawful use of the service, or from its breach of the regulation applicable to it. This indemnity covers reasonably incurred defence costs.

Each party undertakes not to disclose the other's confidential information, to use it only to perform the contract, and to protect it with the same care as its own confidential information. This undertaking survives for five years after the end of the contract.

Information is not confidential where it is public, already known without an obligation of confidence, independently developed, or where disclosure is required by law or by an authority, the party required to disclose informing the other where the law permits.

The processing of personal data is described in the Privacy policy, which sets out in particular the allocation of roles where the Client uses the service for its own end customers.

The Client warrants that it has a legal basis for passing us its end customers' data and for informing them of that processing. It must not enter personal data in clear text in free-reference fields, which must contain opaque identifiers.

The service, its components, its documentation and its trade marks remain the property of COWRIEX or of its licensors. For the term of the contract, the Client has a personal, non-exclusive, non-transferable and revocable right of use, limited to using the service in accordance with this contract.

The Client retains ownership of its own data and content. It authorises us to process them only so far as necessary to provide the service.

Neither party is liable for a failure resulting from an event beyond its reasonable control, in particular: natural disaster, epidemic, war, act of terrorism, general strike, major power failure, failure of a telecommunications network or of a critical provider, unavailability or malfunction of a blockchain network, and any act of a public authority such as a law, a decision, a sanction, an embargo, an asset freeze or a suspension of access.

We may amend this contract. Any amendment affecting the Client's rights or obligations is subject to reasonable notice, sent by email or displayed in the dashboard, and takes effect only once that notice has expired.

The version applying to the Client is the one they accepted, until an amendment notified to them takes effect at the end of its notice period; it then applies without a new acceptance. A version published on this page but whose notice has not been sent to the Client does not change their contract in progress. A Client accepting the contract for the first time is bound, with no notice period, by the version published on the date of their acceptance: the notice period protects a contract in progress against a unilateral amendment, it does not apply to the formation of a new contract.

The Client is deemed to have accepted the amendment unless they notify us of their refusal before its effective date. Continued use of the Service after that date constitutes acceptance of the version in force.

A Client refusing an amendment may terminate free of charge before it takes effect.

Only one amendment may be awaiting effect at a time for a given document. If we publish a new amendment affecting the Client's rights or obligations while a previous one has not yet taken effect, that previous one is abandoned and a full notice period runs on the final text.

Amendments with no effect on the Client's rights or obligations, in particular drafting corrections and clarifications, take effect on publication. Where an amendment is awaiting effect, they are folded into it without changing its effective date.

Communications relating to the contract are validly sent by email to the address provided by the Client, or by display in the dashboard. The Client accepts the use of electronic means and undertakes to keep its contacts' details up to date.

Legal notices to COWRIEX are to be sent to [email protected].

Any complaint may be sent to [email protected], or to [email protected] where it concerns the performance of the contract. We acknowledge receipt within five working days and respond within thirty days, stating where applicable the further time needed.

This contract is governed by the law of the Republic of Benin.

Any dispute arising out of or in connection with this contract shall first be the subject of an attempt at amicable settlement: the more diligent party shall send the other a written notice setting out the subject of the dispute, and the parties shall have thirty days from its receipt to resolve it.

Failing agreement within that period, the dispute shall be finally settled under the Rules of Arbitration of the Common Court of Justice and Arbitration of OHADA, by a sole arbitrator, the seat of the arbitration being Cotonou and the language of the arbitration being French.

By way of exception, and without this amounting to a waiver of this arbitration agreement or being subject to the attempt at amicable settlement above, each party retains the right to apply to any competent state court for urgent interim or protective measures, in particular judicial security and protective attachment.

In the event of any discrepancy between language versions, the French version prevails.

• Assignment: the Client may not assign the contract without our written consent. We may assign it to a company in our group or in the context of a corporate transaction, informing the Client.
• Severability: if a provision is held invalid, the others remain applicable and the invalid provision is replaced by the closest valid one.
• No waiver: failing to rely on a breach does not waive the right to rely on it later.
• Subcontracting: we may use providers to perform the service and remain responsible for their involvement within the limits of this contract.
• Entire agreement: this contractual set replaces any earlier agreement on the same subject.
• No partnership: the contract creates no partnership, agency or employment relationship between the parties.