Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 15 additions & 28 deletions faq.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,61 +4,57 @@ description: "Frequently Asked Questions and Common Misconceptions"

---

<Warning>
**AI-Generated Content** – This page was generated with AI assistance and may contain inaccuracies. While likely close to accurate, please verify critical details with the [stable documentation](https://docs.request.network) or [contact support](https://github.com/orgs/RequestNetwork/discussions).
</Warning>

<Info>
If your question is not answered below, please consider posting it to the [Request Network Discussions](https://github.com/orgs/RequestNetwork/discussions) page on Github.
</Info>

<AccordionGroup>
<Accordion title="Is Request Network a blockchain, smart contract platform, or L2 scaling solution?">
No. Request Network is not a blockchain, smart contract platform, or scaling solution. Rather, it's a protocol for storing payment requests, facilitating onchain payments, and reconciling those payments with the requests. It stores payment requests in [IPFS](https://www.ipfs.com/) and CID hashes on [Gnosis Chain](https://www.gnosis.io/). It uses [The Graph](https://thegraph.com/) for onchain event indexing. It processes payments across a variety of [supported payment chains](https://docs.request.network/get-started/supported-chains).
No. Request Network is not a blockchain, smart contract platform, or scaling solution. Rather, it's a protocol for storing payment requests, facilitating onchain payments, and reconciling those payments with the requests. It stores payment requests in [IPFS](https://www.ipfs.com/) and CID hashes on [Gnosis Chain](https://www.gnosis.io/). It uses [The Graph](https://thegraph.com/) for onchain event indexing. It processes payments across a variety of [supported payment chains](/resources/supported-chains-and-currencies).
</Accordion>

<Accordion title="What is the difference between Request Network and Request Finance?">
Request Network is an open-source protocol. Request Finance is a product built on top of Request Network. Request Finance has spun off from Request Network, and they are now two separate teams.
</Accordion>

<Accordion title="Do I need to create a request on the same chain that I want to receive payment?">
No. Requests are created on Gnosis Chain (or Sepolia for testing), even if the payment will happen on a different chain. Payment(s) can occur on any of our [supported payment chains](https://docs.request.network/get-started/supported-chains#payments).
No. Requests are created on Gnosis Chain (or Sepolia for testing), even if the payment will happen on a different chain. Payment(s) can occur on any of our [supported payment chains](/resources/supported-chains-and-currencies).

To help builders get started quickly, the Request Network Foundation operates [Request Node Gateways](https://docs.request.network/get-started/request-node-gateways) that are free for anyone to use. These gateways offer endpoints for creating and retrieving requests.
To help builders get started quickly, the Request Network Foundation operates Request Node Gateways that are free for anyone to use. These gateways offer endpoints for creating and retrieving requests.

Requests created on Gnosis Chain are "real" and will exist forever. Requests created on Sepolia are "test" requests and will exist only as long as Sepolia continues to operate.
</Accordion>

<Accordion title="Is the address that creates a request the same address that receives the payment?">
It can be, but not necessarily. The [Signer Identity](https://docs.request.network/glossary#signer-identity) that signs to create a request is defined by the `signer` parameter. This is separate from the [Payment Recipient](https://docs.request.network/glossary#payment-recipient) which is defined by the `paymentNetwork.parameters.paymentAddress` parameter. They can be the same or different.
It can be, but not necessarily. The [Signer Identity](/glossary#signer-identity) that signs to create a request is defined by the `signer` parameter. This is separate from the [Payment Recipient](/glossary#payment-recipient) which is defined by the `paymentNetwork.parameters.paymentAddress` parameter. They can be the same or different.

This design allows for a single payee identity to have potentially multiple payment recipient addresses.

See [Parties of a Request](https://docs.request.network/glossary#parties-of-a-request) for details.
See [Parties of a Request](/glossary#parties-of-a-request) for details.
</Accordion>

<Accordion title="Are requests in Request Network stored fully onchain?">
No. Request Network is a hybrid onchain/offchain protocol storing the majority of request contents in IPFS. Only the content-addressable ID (CID) is stored onchain, on Gnosis Chain.
</Accordion>

<Accordion title="Can I make a payment before creating a request?">
Yes. Payments are linked to requests via a [Payment Reference](https://docs.request.network/advanced/request-network-sdk/sdk-guides/request-client/payment-reference) derived from the request contents. Therefore, it is possible to calculate the `paymentReference` and execute a payment *before* creating the corresponding request.
Yes. Payments are linked to requests via a [Payment Reference](/glossary#payment-reference) derived from the request contents. Therefore, it is possible to calculate the `paymentReference` and execute a payment *before* creating the corresponding request.
</Accordion>

<Accordion title="Does Request Network support requests for fiat currency?">
Yes and No.

Requests can be *denominated* in fiat currencies like USD, EUR, etc. ([ISO 4217 currencies](https://en.wikipedia.org/wiki/ISO_4217)) but our payment smart contracts only support payments in cryptocurrencies. We call these [Conversion Payment](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/conversion-request)s, in which the requested fiat amount is converted to the appropriate cryptocurrency amount using onchain price feeds at the moment of payment.
Requests can be *denominated* in fiat currencies like USD, EUR, etc. ([ISO 4217 currencies](https://en.wikipedia.org/wiki/ISO_4217)) but our payment smart contracts only support payments in cryptocurrencies. We call these [Conversion Payment](/glossary#conversion-payment)s, in which the requested fiat amount is converted to the appropriate cryptocurrency amount using onchain price feeds at the moment of payment.

It is possible to implement fiat payments using Declarative Requests, where the payer declares that the payment was sent and the payee declares that the payment was received.
</Accordion>

<Accordion title="Does Request Network support crypto-to-fiat (off-ramp) or fiat-to-crypto (on-ramp) payments?">
Not currently, but we're working on it.
Crypto-to-fiat payments are supported via the Request Network API. See [Crypto-to-fiat Payments](/api-features/crypto-to-fiat-payments).
</Accordion>
Comment on lines 52 to 54
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On-ramp (fiat-to-crypto) part of question left unanswered

The accordion title explicitly asks about both "crypto-to-fiat (off-ramp) or fiat-to-crypto (on-ramp) payments", but the answer only addresses the crypto-to-fiat direction. A reader looking for on-ramp information will find no answer here.

Recommendation: Add a brief sentence clarifying the status of on-ramp support. For example: "Fiat-to-crypto on-ramp payments are not currently supported via the API." This ensures the answer fully addresses the question asked.


<Accordion title="Does Request Network support crypto payments from centralized exchanges (CEX) or custodians?">
Yes. See [Single Request Forwarder](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/single-request-forwarder)
Yes. See [Single Request Forwarder](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/single-request-forwarder).
</Accordion>

<Accordion title="Can a Request Node modify a request's contents before persisting it to IPFS and onchain?">
Expand All @@ -68,15 +64,6 @@ If your question is not answered below, please consider posting it to the [Reque
<Accordion title="Can I create a request via the Request Network SDK without using a Request Node?">
No. Today, a Request Node is required to interact with the Request Network IPFS Network. That said, it is possible to make the end-user pay the protocol fee when creating a request instead of the Request Node. To do this, inject an `HttpMetaMaskDataAccess` into the frontend `RequestNetwork` instance.

<Warning>
⚠️ **Security Warning**: The code example below uses `process.env.PRIVATE_KEY` for demonstration purposes only. **Never expose private keys in client-side code or commit them to version control.**

**For production applications, use one of these secure alternatives:**
1. **Web3 wallet signature providers** (MetaMask, WalletConnect) - Let users sign with their own wallets
2. **Server-side signing** - Keep private keys on your backend and expose a signing API
3. **Hardware wallet integration** - Use Ledger or Trezor for key management
</Warning>

```javascript
const requestNetwork = new RequestNetworkBase({
dataAccess: new HttpMetaMaskDataAccess({
Expand All @@ -92,7 +79,7 @@ If your question is not answered below, please consider posting it to the [Reque
</Accordion>

<Accordion title="Can I access a user's historical invoices created via Request Finance?">
Yes. It is possible to request access to a user's Request Finance invoices using the [`add-stakeholder` web component](https://docs.request.network/learn-request-network/components/add-stakeholder) which is just a thin wrapper around the [Request Finance Add Stakeholders API](https://docs.request.finance/faq#i-am-integrating-the-request-network.-can-i-get-access-to-users-data-on-request-finance). They display a dialog that prompts the end-user to grant access to 1 invoice at a time.
Yes. It is possible to request access to a user's Request Finance invoices using the add-stakeholder web component which is just a thin wrapper around the [Request Finance Add Stakeholders API](https://docs.request.finance/faq#i-am-integrating-the-request-network.-can-i-get-access-to-users-data-on-request-finance). They display a dialog that prompts the end-user to grant access to 1 invoice at a time.

Details:

Expand All @@ -103,18 +90,18 @@ If your question is not answered below, please consider posting it to the [Reque
<Accordion title="Does Request Network support crosschain payments where the payer sends funds on one chain and the payee receives funds on a different chain?">
Yes, via the **Request Network API only**. Crosschain payments are not supported by the Request Network SDK or protocol directly. When using the API, payers can fund requests using assets on different chains and tokens, and the payee receives the requested asset on the request's chain. For example, you can pay a USDC-on-Base request using USDT from Optimism.

See <Card title="Crosschain Payments" icon="link" href="/api-features/crosschain-payments">Learn how to implement crosschain payment flows</Card> for implementation details.
See [Crosschain Payments](/api-features/crosschain-payments) for implementation details.
</Accordion>

<Accordion title="Does Request Network support private requests?">
Yes. See:

- [Private Requests using Encryption](https://docs.request.network/advanced/protocol-overview/private-requests-using-encryption)
- [Encrypt with a wallet signature using Lit Protocol](https://docs.request.network/advanced/request-network-sdk/sdk-guides/encryption-and-decryption/handle-encryption-with-a-web3-wallet)
- [Handle Encryption with a Web3 Wallet](https://docs.request.network/advanced/request-network-sdk/sdk-guides/encryption-and-decryption/handle-encryption-with-a-web3-wallet)
</Accordion>

<Accordion title="Does Request Network support private payments?">
Yes. See [Hinkal Private Payments](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/hinkal-private-payments)
Yes. See [Hinkal Private Payments](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/hinkal-private-payments).
</Accordion>

<Accordion title="Can I create a request via a smart contract call?">
Expand All @@ -124,6 +111,6 @@ If your question is not answered below, please consider posting it to the [Reque
</Accordion>

<Accordion title="Can I use Request Network requests even if I have my own payment infrastructure?">
Yes. See [Single Request Forwarder](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/single-request-forwarder)
Yes. See [Single Request Forwarder](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/single-request-forwarder).
</Accordion>
</AccordionGroup>
</AccordionGroup>
16 changes: 6 additions & 10 deletions glossary.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -2,11 +2,7 @@
title: "Glossary"
---

<Warning>
**AI-Generated Content** – This page was generated with AI assistance and may contain inaccuracies. While likely close to accurate, please verify critical details with the [stable documentation](https://docs.request.network) or [contact support](https://github.com/orgs/RequestNetwork/discussions).
</Warning>

## Parties of a Request
## Parties of a Request

### Payee Identity

Expand Down Expand Up @@ -104,19 +100,19 @@ A payment network is generally related to one currency, but it's not always the

### Payment Reference

In the Reference-based Payment Networks, Payments are linked to Requests via a `paymentReference` which is derived from the `requestId` and payment recipient address. For details see [Payment Reference](https://docs.request.network/advanced/request-network-sdk/sdk-guides/request-client/payment-reference)
In the Reference-based Payment Networks, Payments are linked to Requests via a `paymentReference` which is derived from the `requestId` and payment recipient address. For details see [SDK (Legacy)](/sdk-legacy/overview).

### Conversion Payment

A "conversion" request is denominated in one currency but paid in another currency. This is facilitated by on-chain price feeds provided by oracles. The typical use case is to denominate a request in fiat like USD and pay the request in stablecoins like USDC or DAI. For details see [Conversion Payment](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/conversion-request)
A "conversion" request is denominated in one currency but paid in another currency. This is facilitated by on-chain price feeds provided by oracles. The typical use case is to denominate a request in fiat like USD and pay the request in stablecoins like USDC or DAI. For details see [Conversion Payments](/api-features/conversion-payments).

### Swap-to-pay Payment

A "swap-to-pay" payment is where the payment sender sends one currency but the payment recipient receives a different currency. For details see [Swap-to-Pay Payment](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/swap-to-pay-request)
A "swap-to-pay" payment is where the payment sender sends one currency but the payment recipient receives a different currency. For details see [SDK (Legacy)](/sdk-legacy/overview).

### Swap-to-Conversion Payment

A "swap-to-conversion" payment is where the request is denominated in currency A, the payer sends currency B and the payee receives currency C. For details see [Swap-to-Conversion Payment](https://docs.request.network/advanced/request-network-sdk/sdk-guides/payment/swap-to-conversion-request)
A "swap-to-conversion" payment is where the request is denominated in currency A, the payer sends currency B and the payee receives currency C. For details see [SDK (Legacy)](/sdk-legacy/overview).
Comment on lines 101 to +115
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three glossary "For details" links changed from specific guides to generic overview

Three glossary entries were updated to link to the generic /sdk-legacy/overview instead of their original specific guide pages:

  • Payment Reference (line 103): was payment-reference guide
  • Swap-to-pay Payment (line 111): was swap-to-pay-request guide
  • Swap-to-Conversion Payment (line 115): was swap-to-conversion-request guide

The "For details see" text now points readers to a generic overview rather than documentation specific to each concept, reducing the usefulness of these reference links.

Recommendation: If the specific SDK guide pages still exist (even under sdk-legacy/), consider linking to them directly for more targeted documentation. If those pages have been removed, update the prose to reflect that detailed documentation is unavailable rather than implying the overview provides concept-specific details.


## Ecosystem

Expand Down Expand Up @@ -154,4 +150,4 @@ Multi-signature (multisig) wallets allow multiple parties to require more than o

### Private Key

A private key is a large number that allows you to sign or decrypt messages. Private keys can be thought of as a password; private keys must never be revealed to anyone but you, as they allow you to spend the funds from your wallet through a cryptographic signature.
A private key is a large number that allows you to sign or decrypt messages. Private keys can be thought of as a password; private keys must never be revealed to anyone but you, as they allow you to spend the funds from your wallet through a cryptographic signature.