Disclaimer

This disclaimer applies to the Request Network protocol, its smart contracts, and all interfaces, software and information made available in connection with it, including the Request Network website, the Request Network API and dashboard, SDKs and npm packages, documentation, GitHub repositories, developer resources, social media channels, forums, integrations and related communications (collectively, the “Materials”).

By accessing or using the Materials or interacting with the Request Network protocol, you acknowledge and agree to the terms of this disclaimer. In this disclaimer, “Request Network Foundation” means Request Network Stiftung, c/o Coin Finance AG, Gartenstrasse 5, 6300 Zug, Switzerland, together with its affiliates and contributors.

Definitions

In addition to the capitalised terms defined elsewhere in this disclaimer, the following capitalised terms have the meanings set forth below:

1. Informational purposes only

All Materials are provided solely for informational and educational purposes. Nothing contained in the Materials constitutes or should be construed as:

• financial, investment or trading advice;
• legal, tax, accounting or regulatory advice;
• an offer to sell, or a solicitation of an offer to buy, any financial instrument or digital asset, including the REQ token;
• a recommendation or endorsement of any digital asset, protocol, payment method, strategy or transaction.

Certain Materials have been obtained from third-party sources. While we strive for accuracy, we cannot guarantee that the data and information provided are precise or exhaustive; this content is provided on a best-effort basis. We make no representation about the continuing accuracy of the Materials or their suitability for any particular situation.

The Materials may contain forward-looking statements. These are inherently uncertain and are not guarantees of future performance or outcomes. Users should conduct their own independent research and consult qualified professional advisors before making any financial, legal or technological decision, and should not rely on the Materials as the basis for such decisions.

2. Nature of the Request Network protocol

The Request Network protocol is a set of open-source smart contracts deployed on public blockchain networks, together with open-source software for creating, storing and reconciling payment requests. These smart contracts operate autonomously and permissionlessly and may be interacted with by any user or application. This means that:

• any user, developer or third party may create requests to receive tokens, prepare and execute their own transactions, and interact directly with the Smart Contracts;
• new integrations, interfaces and applications may be built by independent actors;
• the protocol may be integrated into third-party software or applications without authorization.

The Request Network Foundation:

• does not operate, control or manage the blockchain networks or storage networks (such as IPFS) on which the protocol relies, and does not control how the protocol is used once deployed;
• does not process payments or initiate fund transfers, and does not monitor, authorise or verify the correctness or completeness of any transaction before an End User authorises it;
• does not take custody, control or possession of any fiat currency or crypto-asset, at any point in time;
• does not execute, authorise, sign or co-sign any transaction on behalf of any Payer, Operator, Recipient or End User;
• does not hold, control or have access to any private key, seed phrase or other credential controlling a Wallet;
• does not maintain End User balances, ledger entries or accounts representing claims on funds;
• does not act as a payment institution, electronic money institution, payment service provider, virtual asset service provider, money services business, custodian, fiduciary, trustee, broker, dealer, exchange, clearing house, market-maker, ICT third-party provider or investment adviser;
• does not provide any regulated financial service, or any service that would require it to obtain a licence, authorisation or registration under applicable law;
• does not decide which transactions, Payers, Operators, Recipients or counterparties may participate in any flow routed through the Request Protocols, all Compliance Rules being defined, maintained and applied by Integrators, Recipients or the Screening Providers they select.

All transactions made through the Request Protocols are: (1) initiated by an End User on its own account; (2) reviewed and approved by that End User; (3) signed by that End User using its own Wallet and credentials; and (4) executed directly from that End User’s Wallet to the relevant destination, without the Request Network Foundation having custody, control or signing authority at any point.

Use of the protocol, the Materials or any related software does not create any partnership, joint venture, agency, fiduciary or advisory relationship between users and the Request Network Foundation. Users interact with autonomous Smart Contracts and third-party software at their own initiative.

3. Request Network smart contracts

This disclaimer covers every smart contract forming part of the Request Network protocol, in all versions, on every network where it is or will be deployed, including those listed below. The authoritative list of contracts, versions and addresses is maintained in the @requestnetwork/smart-contracts package; testnet deployments and test contracts are also covered. Addresses below are taken from that package as of 29 October 2026; where several addresses appear for one network, each is a separate version and all are covered.

AuthCaptureEscrow, price-feed oracles (such as Chainlink), swap routers and token contracts referenced by the protocol are third-party contracts that the Request Network Foundation does not develop or control (see section 5).

4. No custody of digital assets

The Request Network smart contracts transfer funds directly from payer to payee (and, where applicable, to a fee recipient) in the same transaction. The Request Network Foundation does not hold, custody, manage or control users’ digital assets or funds at any time, including assets held in escrow contracts, single-request proxies or recurring-payment authorisations. Users interact with blockchain networks and smart contracts directly through their own wallets and private keys.

Accordingly:

• users remain solely responsible for safeguarding their private keys, wallets and assets;
• users are solely responsible for verifying the payee, amount, currency, network and payment reference before paying;
• the Request Network Foundation cannot reverse, refund or recover payments, lost private keys or assets.

Loss of private keys, or a payment sent to a wrong address, network or reference, may result in the permanent and irreversible loss of digital assets.

5. Third parties

Users may access the Request Network protocol through third-party websites, invoicing and payment applications, wallets, payment gateways, on-ramps, aggregators or other interfaces (“Interfaces”) developed and operated by independent entities (“Interface Providers”).

The Request Network Foundation:

• does not develop, operate or control these Interfaces;
• does not guarantee the security, reliability, availability or accuracy of any Interface;
• does not endorse or recommend any specific Interface Provider.

When interacting with the protocol through an Interface, users interact with software operated by the Interface Provider, and any terms of service or agreements applicable to that Interface are solely between the user and the Interface Provider. Use of an Interface creates no contractual, fiduciary or advisory relationship between users and the Request Network Foundation.

The ecosystem also includes independent participants such as Request Node operators, integrators and application developers, merchants and payees, fee recipients, liquidity and swap providers, price-feed (oracle) providers, indexing services (such as The Graph), storage providers (such as IPFS) and compliance or KYT providers. These participants act independently and are solely responsible for their activities, representations and services. The Request Network Foundation assumes no responsibility for their conduct, actions or omissions.

Third-party Interfaces or integrations may change how protocol information (including request status and payment detection) is displayed, or add functionality. The Request Network Foundation does not verify or guarantee the accuracy of such representations.

6. Risks associated with digital assets and blockchain payments

Interacting with blockchain-based protocols involves substantial risk, including but not limited to:

• price volatility of digital assets, including stablecoins losing their peg;
• smart-contract vulnerabilities or bugs (coding errors, unforeseen interactions with other protocols or tokens);
• blockchain network failures, congestion, reorganisations or forks;
• failure, delay or inaccuracy of price feeds (oracles) used for conversion payments;
• failure of swap routers or insufficient liquidity for swap payments;
• unavailability or data loss in storage networks (IPFS), Request Nodes or indexing services, affecting request data or payment detection;
• errors in payment references, addresses, networks or amounts;
• changes to protocol parameters or contracts by administrators;
• regulatory uncertainty.

Such risks may result in loss of digital assets, unexpected protocol behaviour and economic losses. Blockchain transactions are generally irreversible, and users may lose part or all of their digital assets. Users should assess their financial situation and risk tolerance before using the protocol. By interacting with the protocol or relying on the Materials, users acknowledge that they understand these risks and accept full responsibility for their actions.

7. Administration, governance and the REQ token

Most Request Network payment contracts are immutable once deployed. Certain contracts include administrative functions, such as maintaining price-feed paths, whitelisting hash submitters, setting storage fees, or managing swap routers and fee parameters, which are controlled by multisignature wallets. Changes made through these functions may alter the operation, risk profile or economics of the affected contracts. The Request Network Foundation does not guarantee that any such parameter will remain unchanged.

The REQ token (“REQ”) is a utility token that acts as an access token to the Request Network. Access relies on a proof-of-burn mechanism: a marginal amount of REQ is burned, meaning permanently and verifiably destroyed, as a fee for using the network. The burn increases the cost of attacking or spamming the network and so serves a security and anti-spam purpose. It is not intended to significantly affect the circulating supply of REQ or to influence its market price.

End Users do not need to hold REQ to use the Request Protocols. The protocol supports automatic currency conversion: fees can be paid in the End User’s currency of choice and are converted automatically, with the required REQ fee burned as part of the process.

REQ also allows its holder to vote on network governance issues and to support the operation of the network. Governance participants act independently and in their own capacity, and do not represent the Request Network Foundation unless explicitly stated. The Request Network Foundation does not control or guarantee governance outcomes, which may alter the operation, risk profile or economics of the protocol.

REQ does not give, or purport to give, any equity, debt, dividend, profit-sharing or other investor rights in the Request Network Foundation or any other entity. It is not backed by any asset, and no return is promised or can be earned from merely holding it. Where REQ is traded on secondary markets, its value fluctuates according to supply and demand and is unconnected with any earnings of the Request Network Foundation; holders should be prepared for significant price fluctuations, both down and up. Nothing in the Materials is an offer of, or a solicitation to buy, REQ. Users acquire, hold or use REQ at their own risk.

8. No warranty and limitation of liability

The Materials, the smart contracts and the protocol are provided “as is” and “as available”. To the fullest extent permitted by applicable law, the Request Network Foundation disclaims all warranties, express or implied, including but not limited to merchantability, fitness for a particular purpose, non-infringement, and uninterrupted or error-free operation. No representation is made that the protocol, the smart contracts or the Materials will be secure, accurate or free of defects, or that any security audit has identified all vulnerabilities.

To the maximum extent permitted by applicable law, in no event shall the Request Network Foundation or its contributors, officers, directors, employees, agents or affiliates be liable to any user or third party for any direct, indirect, incidental, consequential, special, punitive or exemplary loss or damage of any kind, whether in contract, tort (including negligence), strict liability or any other legal or equitable theory, and even if advised of the possibility of such damages, including but not limited to:

• loss of digital assets or any decrease in their value;
• loss of profits, anticipated profits or revenue;
• failed, delayed, duplicated, misdirected or undetected payments;
• conversion or swap losses arising from price-feed or liquidity issues;
• loss of data, including request data;
• other economic damages.

9. Regulatory considerations

The regulatory treatment of digital assets, stablecoin payments and decentralised protocols varies across jurisdictions and remains uncertain in many regions. Users, including merchants, payees and integrators, are solely responsible for ensuring that their use of the protocol complies with applicable laws and regulations in their jurisdiction, including tax, anti-money-laundering, sanctions and consumer-protection rules. Nothing in the Materials should be interpreted as:

• an offer of regulated financial, payment or money-transmission services;
• crypto-asset services, or the offer or marketing of crypto-assets to the public, within the meaning of the European Union Markets in Crypto-Assets Regulation (MiCA) or other applicable regulatory frameworks.

10. Payment value chain and allocation of roles

Where the Request Protocols are used through an Integration to make on-chain payments to Recipients, or on-chain payouts by Operators to Recipients, the value chain is as follows, and the allocation of roles set out in section 2 applies at every step.

Setup:

1. The Recipient defines a Payment Destination on the Request Protocols (chain and currency in which to receive funds) and, where it chooses, a Screening Provider and Screening Policy used to screen Payer and Recipient Wallets.
2. The Recipient grants a Connectivity Provider the right to create Transfer Preparation Links on its behalf by issuing a Client ID. Where the Connectivity Provider sets the Screening Policy for a Client ID, the Recipient accepts that choice by completing onboarding.

At every payment:

1. The Connectivity Provider creates a Transfer Preparation Link through the Request Network APIs, using the Client ID and the payment expectation provided by the Recipient (amount, Screening Policy, fees, transaction reference and payer reference).
2. The Payer is presented with the IPFS-hosted Payment Page to prepare its own transaction. Any fees of the Connectivity Provider and of the Request Protocols are included and routed atomically in the same transaction at the Smart Contract level.
3. Where screening is enabled, the selected Screening Provider screens the Payer and Recipient Wallets against the applicable Screening Policy (see section 11).
4. The Payer selects a payment method (currency and chain) consistent with the Payment Destination. Where needed, a third-party cross-chain provider (such as Li.Fi) is queried to surface the transaction details to the Payer.
5. The Payer signs and executes the payment from its own Wallet.
6. The Request Protocols index the resulting on-chain event, and a Webhook is dispatched to the Connectivity Provider and the Recipient.

The value chain for payouts is identical, save that the Operator replaces the Payer and screening is applied to the Recipient Wallet.

In this value chain, each Integrator and Connectivity Provider is solely responsible for the design, operation and support of its Integration, including the onboarding and authentication of its End Users, the definition and application of Compliance Rules, its contracts with Screening Providers or other compliance providers, all customer due diligence, transaction monitoring, sanctions screening, suspicious-activity reporting and recordkeeping obligations, determining the eligibility of End Users in any jurisdiction, consumer-facing disclosures, complaints handling and dispute resolution, and all communications with End Users and competent authorities. Cross-chain providers, Screening Providers and other Third Party Services are not controlled, operated or guaranteed by the Request Network Foundation, and their terms of use apply directly to the Integrator and, as applicable, to End Users.

Integrators must present this disclaimer, or a link to it, to End Users before their first interaction with the Request Protocols, and must not represent that their Integration is provided by a regulated entity by virtue of the Request Network Foundation’s involvement, or that the Request Network Foundation guarantees, backs or insures any End User’s funds or transactions.

11. Wallet screening (KYT)

The Request Protocols can be connected to third-party Screening Providers to offer optional blockchain wallet screening for incoming payments and outgoing payouts. When screening is enabled, Payer Wallets and Recipient Wallets are screened against the Screening Provider’s risk intelligence across supported blockchains before a transaction is authorised. The purpose of screening is to help reduce exposure to Wallets associated with sanctions, illicit finance activity, scams, ransomware, mixers, darknet activity, terrorism financing and other high-risk categories, and to help reduce the risk of frozen assets.

11.1 Standard and custom screening

Screening may be used in one of two ways:

• (a) Standard screening (Request Network API key). Screening runs through the Screening Provider account connected by the Request Network Foundation, using that provider’s standard Screening Policy (the Hypernative Standard policy or the Merkle Science standard rule, described below). The Request Network Foundation provides the technical connectivity and access to the provider’s standard rules only; it does not define, tune or approve those rules.
• (b) Custom screening (custom API key or custom policy). An Integrator or Recipient connects its own Screening Provider account or API key, or selects a custom Screening Policy. It then enters into a direct contractual relationship with that provider, is responsible for all fees and obligations owed to it, and is solely responsible for defining, maintaining and applying the resulting Compliance Rules. The Request Network Foundation provides the technical connectivity only.

In both cases, screening can be enabled at the Payment Destination level and, where supported, overridden at transaction creation, unless a Connectivity Provider has fixed the Screening Policy for a Client ID. Where a primary and a backup Screening Provider are configured, the backup is used only if the primary provider has a technical failure; a definitive rejection by the primary provider is not re-screened by the backup.

11.2 Hypernative Standard policy

Under the Hypernative Standard policy, incoming Payer Wallets identified as high risk may be prevented from transacting with the Recipient, and outgoing payouts to Wallets identified as high risk may be blocked when payout screening is enabled. The policy uses market-standard rules and exposure thresholds maintained and periodically updated by Hypernative, intended to provide a baseline level of automated wallet risk protection only.

Wallets directly associated with the following categories are classified as high risk: Sanctions, Phishing, Scam, Attacker Wallets, Mixing Services, Sanctioned Jurisdiction Exchanges, Terrorism Financing, CSAM, Darknet Marketplaces, Drugs Trade, Weapon Trade, Illicit Goods and Services, Special Measures, and Ransomware.

Indirect exposure may also trigger a high-risk classification when the following thresholds are exceeded:

The current version of this policy is published at Hypernative KYT Policy and may be updated by Hypernative from time to time.

11.3 Merkle Science standard rule

Where Merkle Science is selected with its standard rule, Payer and Recipient Wallets are screened against a standard compliance rule maintained and periodically updated by Merkle Science. Wallets the rule identifies as high risk may be prevented from transacting or receiving payouts in the same way as under section 11.2. The rule is a standard compliance rule run against Merkle Science’s risk intelligence; it provides a baseline level of automated wallet risk protection only and does not represent a guarantee of the absence of high-risk interactions.

11.4 Opt-out

Users may choose to opt out of screening. By disabling or bypassing screening, the user acknowledges and accepts the risks associated with transacting with unscreened Wallets.

11.5 No guarantee and allocation of responsibility

Neither the Request Network Foundation nor any Screening Provider provides compliance, legal, regulatory or risk-management services through this feature. Screening results, whether under a standard or a custom Screening Policy, do not constitute legal advice, a guarantee of Wallet safety, a guarantee of the absence of high-risk interactions, or a determination that funds are free from illicit exposure or regulatory risk. Screening Providers may produce false positives or false negatives, and their data, rules and thresholds may change without notice.

Users, Integrators and Recipients remain solely responsible for assessing the suitability of transactions, for any decision to allow or prevent a Wallet, Payer, Operator or Recipient from participating in a payment, and for complying with applicable laws, sanctions programmes, anti-money-laundering and counter-terrorist-financing obligations, and their internal compliance policies.

The Request Network Foundation acts solely as a technology provider facilitating access to third-party screening infrastructure. Each Screening Provider acts solely as a screening technology and data provider. Users requiring tailored Compliance Rules should contact the Request Network team to discuss custom screening configurations.

12. Applicable law and jurisdiction

This disclaimer, and any use of the Materials and the Request Protocols, are governed by the laws of Switzerland, and are subject to the exclusive jurisdiction of the competent courts of Zug, Switzerland.