Unaudited, unvetted, experimental. Do not use as a reference. AI-researched ratings that may be wrong; not advice or a statement of fact about any provider. Full disclaimer
Pending review. 1150 of 1150 ratings not yet checked by a human. Do not rely on unreviewed ratings.
Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: The vendor's docs repo (RequestNetwork/mintlify-docs@1845bc53) uses "USDC-base" as its example payment currency more than any other mainnet ID (15 occurrences vs 8 for USDC-mainnet), and Base is one of the 7 EVM chains in its supported-chains table (resources/supported-chains-and-currencies.mdx L19). Excluded: Ethereum, Arbitrum, Optimism, Polygon, BSC, Tron, about 20 SDK-only legacy chains, NEAR, and Gnosis Chain, which hosts request storage (described in notes, not scored onchain).
Offered everywhere, per the provider's code or documents. Checked 2026-10-09. Not scored.
Scored unit is the open protocol path. The fee proxies have no admin and no address or country check, and the SDK has no geoblock, so anyone can pay from anywhere. The hosted API, Secure Payment page and Dashboard are optional; their API terms (request.network/api-terms-and-conditions) and privacy policy name no countries, and the API's optional KYT screening (Hypernative) screens wallet addresses, including exposure to "Sanctioned Jurisdiction Exchanges", not users' countries. Product variant: the easy-invoice template's crypto-to-fiat flow offers a 40-country list in its compliance form (easy-invoice@42ad4d0e src/lib/constants/compliance.ts), which is an optional off-ramp, not the payment path. Judgment call: the closed API could gate by country without saying so; it is not required to pay.
Evidence (2)2 verified
Verified
transferFromWithReferenceAndFee is callable by anyone and checks only that the token transfers succeed; there is no caller, address or country restriction.
A search of every packages/*/src directory for sanction, OFAC, chainalysis, blocklist, denylist and geoblock finds only test mocks; the SDK has no country gate.
Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The core payment contracts, ERC20FeeProxy and EthereumFeeProxy, have no pause, freeze, blacklist, or admin of any kind. The conversion path, used for invoices denominated in fiat, does have one. The owner of Erc20ConversionProxy can swap the code it delegatecalls into, and an admin of ChainlinkConversionPath can change or remove price feeds. Either change halts conversion payments, and new code could be written to block chosen addresses. Both roles are held by a 3-of-7 Safe with no modules and no guard. There is no timelock, and the signers are not disclosed. The Safe is named as admin in the repo (Admin artifact, smart-contracts README L282). Judgment call: we score 1 and not 0. The anchor-1 case covers a multisig with no timelock and undisclosed signers. We read anchor 0's "target individual addresses" as a native blacklist function, and none exists. Payers on non-conversion requests can avoid this role entirely by calling ERC20FeeProxy, which on its own would score 3. Outside Base, the same Safe signer set (3-of-7) can remove the open hash submitter from the Gnosis RequestHashStorage whitelist, which would stop new requests being stored (see notes).
Evidence (5)5 verified
Verified
ERC20FeeProxy has no owner, role, pause, or blacklist; transferFromWithReferenceAndFee is external with no modifier. EthereumFeeProxy (L55-L74 of its file) is the same.
Erc20ConversionProxy delegatecalls into paymentProxy (L77) and the owner can replace paymentProxy and chainlinkConversionPath at any time (updateConversionProxyAddress L135, updateConversionPathAddress L127), with no delay.
owner() of Erc20ConversionProxy is 0xf735afF55745e00D85F30AFB01E1c042D0755628, a Safe 1.4.1; paymentProxy() currently points at ERC20FeeProxy 0x1892196E80C4c17ea5100Da765Ab48c1fE2Fb814.
Admin Safe threshold is 3 of 7 owners; getModulesPaginated(0x1,10) returns no modules and the guard slot is zero; no timelock sits between the Safe and the contracts.
isWhitelistAdmin(admin Safe) is true on ChainlinkConversionPath and false for the deployer 0x4E64C2d06d19D13061e62E291b2C4e9fe5679b93, which held it at construction; full role enumeration was not possible because public Base RPCs cap eth_getLogs at 500 blocks.
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
A payer can settle without Request Network. They compute the paymentReference from the request and call ERC20FeeProxy or EthereumFeeProxy directly. The ABI and Base address are in the repo and the npm package, and the docs describe the call. No provider signature, relayer, or API is involved, and the contract moves funds straight from payer to payee. We did not run a test payment of our own. A live transaction on Base shows a third-party contract calling the proxy directly.
Evidence (4)4 verified
Verified
transferFromWithReferenceAndFee(token, to, amount, paymentReference, feeAmount, feeAddress) is external, unpermissioned, and moves tokens from msg.sender straight to the payee.
Docs state the payer derives the paymentReference and calls the payment contract with token, to, amount and paymentReference; faq.mdx L40-L42 says the reference can be computed and paid before the request exists.
Deployed ERC20FeeProxy is a Sourcify exact_match to this source; tx 0x2580e807b575a321c20e3134eea8e18a0edba56ae97ca25b315215e0a7113d4e (block 52282170) shows a non-Request contract calling it and emitting TransferWithReferenceAndFee.
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
On the open path, the only required intermediary is a Request Node, which stores the request and needs IPFS and a Gnosis RPC. Its code, a README setup guide, Docker images, and a Helm chart are all public. The SDK configures no fallback node; the reference template falls back to Request's hosted Gnosis gateway. No relayer, paymaster, or bundler is needed. Request Network's current docs describe only its hosted API, which is closed and single-vendor and would score 0. Judgment call: we score the open protocol path, because a payment completes without the API. We score 2 and not 3, because the SDK itself sets no fallback. Storing a request on Gnosis also needs the open hash submitter to stay whitelisted by Request's Safe (see C1).
Evidence (3)3 verified
Verified
The SDK's default Request Node is http://localhost:3000, overridden by nodeConnectionConfig; no hosted gateway or fallback is configured in the SDK.
The Request Node README documents npm and source installation, joining the IPFS private network with the request-ipfs image, and optional TheGraph mode; request-helm-charts provides a Kubernetes deployment.
Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The settlement contracts do no address or geographic filtering, and neither do the public SDK, Request Node, and reference frontends. The one filter we found is opt-in KYT screening on Request's hosted Secure Payment page. It is disclosed in the versioned docs repo, its list providers are named, and a payer can bypass it with the direct contract call scored in C2. All required components on the open path are public. Request's hosted API and gateways are closed or of unknown build. We cannot rule out screening inside them, but neither is required to pay. No network trace was run.
Evidence (3)3 verified
Verified
A search of every packages/*/src directory (SDK, request-node, payment-detection), web-components, and invoicing-template for sanction, OFAC, chainalysis, TRM, blocklist, denylist, geoblock, and IP-geolocation calls finds only test mocks (BadERC20.sol); the settlement contracts contain no address or country checks.
The only filtering found is KYT wallet screening on the hosted Secure Payment page, merchant-enabled, disclosed in the versioned docs repo, and naming its list sources (Hypernative standard policy by default, Merkle Science optional).
The deployed ERC20FeeProxy bytecode is a Sourcify exact_match to source with no filtering logic, so a payer screened out by the hosted page can still call it directly (C2).
Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Tokens and chains are listed in code and on the supported-chains docs page. The docs then tell payees that freezing and seizure risks do not apply, although the main settlement assets, USDC and USDT, can be frozen by their issuers. Base, the primary chain, also runs on a single centralized sequencer, and the docs do not mention it. A search of the docs for freeze, blacklist, and sequencer found only the passage above. Judgment call: we score 0 and not 2. The enumeration in code would justify 2, but anchor 0 includes "misstated", and the docs misstate the freeze risk.
Evidence (2)2 verified
Verified
Supported tokens are enumerated per chain in the token list (USDC-base 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) and in packages/currency/src/chains/evm/data/base.ts.
Docs list "Exposure to fund freezing or seizure" as a processor risk and say that because Request never takes custody "none of these risks apply"; no docs page mentions issuer freeze powers or sequencer assumptions.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
All four settlement contracts are full matches on Sourcify and exact matches on Basescan. Their sources match the repo files at this commit, apart from a trailing newline. The repo's build config does not reproduce the deployed bytecode, because it now enables the optimizer and the deployments were compiled without it. Rebuilding would need the older config from git history, and we did not try. Judgment call: we score 2 and not 3, because anchor 3 needs a repo build script that reproduces the deployed bytecode.
Evidence (2)2 verified
Verified
Sourcify returns exact_match (creation and runtime) for Erc20ConversionProxy, and also for ERC20FeeProxy 0x1892196E80C4c17ea5100Da765Ab48c1fE2Fb814, EthereumFeeProxy 0xd9C3889eB8DA6ce449bfFE3cd194d08A436e96f2, and ChainlinkConversionPath 0x3dF89c727eaDF67eeD7b4d09EC4F2b41f8Dec2ca; Basescan shows all four "Source Code Verified (Exact Match)".
The repo's Hardhat config pins solc 0.8.9 with the optimizer enabled (runs 200), but Sourcify metadata for all four deployments shows optimizer disabled; the optimizer was switched on in commit 77006576 (2025-11-26), after the 2024 Base deployment.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Every part of the open protocol stack is public: contracts, deploy scripts, SDK, Request Node, both indexers, deployment tooling, and reference frontends. The product Request's docs now steer integrators to is the hosted API, and its backend, Secure Payment page, and Dashboard are closed. Their API schema is published only on a hosted site. Judgment call: we score 2 and not 3. The open path alone would reach 3, but the backend behind the vendor's recommended integration is closed, which matches anchor 2's "everything except the backend".
Evidence (2)2 verified
Verified
The monorepo contains the contracts with deploy scripts (scripts-create2), the SDK packages, and the request-node backend; separate public repos hold the payments and storage subgraphs, the Helm chart, the Docker images, and three reference frontends.
The FAQ says the recommended way to create a request is the Request Network API; no repo in the org contains the API, the Secure Payment page, or the Dashboard, and the API schema is published only as a hosted OpenAPI page (api.request.network/open-api).
Can a stranger reach a working deployment from the README? O3
1 Weak
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The documentation needed to self-host exists: Request Node setup, the IPFS swarm image, the storage subgraph, a Helm chart, and the template's env table. We did not attempt a reproduction, so under the brief the score is capped at 1. A self-hosted node also needs xDAI to pay the per-hash storage fee, which read 0.0999 xDAI on Gnosis at block 48631765.
Evidence (1)1 verified
Verified
The README covers installation, IPFS private-network setup, TheGraph mode, launch options, and the MNEMONIC wallet needed to pay Gnosis storage fees; contract addresses ship in @requestnetwork/smart-contracts.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The repo contains the ABIs, the event schemas, and a written spec of the Request Node API. Request data is stored as JSON under a public JSON Schema, so it is portable. The repo has no payee export feature. The hosted API's OpenAPI schema is not versioned in any repo. Judgment call: we treat the node API spec in the README as "or equivalent" to OpenAPI, which supports 2. We score 2 and not 3, because no export function exists.
Evidence (3)3 verified
Verified
ABI JSON and per-chain addresses are committed for every payment contract; event schemas are in source (ERC20FeeProxy.sol L10-L17) and in payments-subgraph/schema.graphql.
The Request Node HTTP API (persistTransaction, getTransactionsByChannelId, getChannelsByTopic) is specified in the repo with parameters, example bodies, and success and error responses.
Invoice content uses a published JSON Schema (rnf_invoice), and request data comes back from any node as JSON; neither the SDK nor the frontends provide an export function (CSV, ledger, or similar) for payees.
Does the license actually let a third party fork, modify, and run it?
2 PartialPillar rating: weakest of 3 3 of 3 Partial or better
What would raise this pillar
Open-source licences reaching Strong: OSI-approved license on every repo in repos.
Protection against relicensing reaching Strong: No CLA, or a CLA that does not permit unilateral relicensing, plus a written license-stability commitment in the repo.
No proprietary dependencies reaching Strong: A production deployment needs no proprietary plugin or hosted-only service.
Does every repository needed to run the product carry an OSI-approved license? F1
2 Partial
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Every repo needed for the open path carries an OSI-approved licence (MIT): the contracts, the SDK, the Request Node, both subgraphs, and the Helm chart. Two non-critical repos have no LICENSE file. The first is web-components, the optional invoice widgets; their npm packages declare MIT. The second is docker-images; the IPFS swarm image can be rebuilt from Kubo and the swarm key. The closed components (API, Secure Payment page, Request Finance) are not required. Judgment call: anchor 2 allows one unlicensed non-critical repo and we found two. We still score 2, because neither repo is needed to run a payment.
Evidence (2)2 verified
Verified
The monorepo (contracts, SDK, request-node) is MIT; every packages/*/package.json declares MIT; payments-subgraph, storage-subgraph, request-helm-charts, invoicing-template, and easy-invoice each carry an MIT LICENSE file (GitHub API license.spdx_id MIT).
web-components has no LICENSE file (its package.json files declare MIT, as do the published npm packages); docker-images, which holds the IPFS swarm image, has no LICENSE file at 325637188a3cb782ed28c9ae246ae907116fcd23.
Can the provider unilaterally relicense future versions, and has it committed not to? F2
2 Partial
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
There is no CLA, and the MIT licence has not changed since 2018. The repo makes no written commitment to keep the licence stable.
Evidence (1)1 verified
Verified
CONTRIBUTING.md has no CLA requirement, and .github contains no CLA bot config; git log -- LICENSE shows a single commit, 1da692fc (2018-01-12, MIT), so the licence has never changed.
Does a production deployment need a proprietary plugin or hosted-only service? F3
2 Partial
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
In code, the open path needs no proprietary plugin or hosted-only service. The node, IPFS, and indexer all run locally, and the SDK accepts any RPC. The proprietary pieces (Request API, Secure Payment page, KYT vendors, Pimlico, Request Finance) are optional. Judgment call: anchor 3 also fits the code, but we score 2. We made no O3 reproduction, so we have not shown a production deployment running free of hosted services.
Evidence (2)2 verified
Verified
Request Node defaults point to local services (Ethereum RPC localhost:8545, IPFS localhost:5001, Graph node localhost:8000); there is no hosted-only dependency or API key.
The SDK's default provider for Ethereum-family networks uses a built-in Infura project ID (RN_INFURA_KEY overrides it); Base defaults to the public https://mainnet.base.org (L55).
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The SDK ships no analytics or telemetry. Both reference frontends ship Google Tag Manager. With an ID configured, GTM runs full tag-manager analytics, which is opt-in and visible in code. Without an ID, the script tag still loads from googletagmanager.com on every page, so Google sees each visitor's IP and page. The README presents the GTM ID as optional, and nothing tells end users. Request's own hosted apps disclose analytics in the privacy policy. Judgment call: between 2 (opt-in) and 1 we take 1, because the template calls Google by default. No trace was run, so this cell cannot reach 3.
Evidence (4)3 verified · 1 documented
Verified
The template renders GoogleTagManager on every page with gtmId from NEXT_PUBLIC_GTM_ID; @next/third-parties 15.1.0 (lockfile) builds the script tag as googletagmanager.com/gtm.js?id=${gtmId} with no check for a missing ID. easy-invoice src/app/layout.tsx L45 does the same.
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The bare SDK asks only for settlement fields and makes invoice content optional, which on its own would score 2. The reference invoicing flow requires line items, and invites buyer and seller identity, beyond what settlement needs. Request's hosted services collect names, email, IP, usage data, and bank details. That collection is disclosed only in the privacy policy, and it serves analytics and marketing as well as legal duties. Judgment call: we score 1 and not 2, because the default flows go beyond settlement needs and the only disclosure is the policy.
Evidence (3)2 verified · 1 documented
Verified
In the SDK, a request needs requestInfo (payee, payer, currency, amount) and a signer; contentData is optional.
The invoice format used by the reference frontends requires invoiceNumber, creationDate, and invoiceItems (name, quantity, unitPrice, tax per item at L113), and has optional buyerInfo and sellerInfo with email, name, address, and tax ID.
For use of Request's hosted Services, the policy lists names, email, IP, clicks, OS, region, public keys, and bank details, used for analytics and marketing optimisation among other purposes.
What do calldata and events reveal about who paid whom for what? P3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Each payment event publishes the payee, amount, token, and a payment reference, and the token Transfer log names the payer. Request contents are unencrypted by default: payee, payer, amount, and in the invoicing flow line items and any buyer or seller contact details. They are stored in an IPFS swarm whose key is public. Their CIDs are anchored on Gnosis and indexed in plaintext by a public subgraph. Anyone can recompute the paymentReference from the stored requestId, salt, and address, and so join a Base payment to its invoice contents. Encryption (ECIES or Lit) exists, but it is opt-in. Judgment call: we score 0 and not 1. Order contents and optional emails are public by default via an onchain pointer, which matches anchor 0, even though the docs say storage is IPFS with optional encryption.
Evidence (4)4 verified
Verified
TransferWithReferenceAndFee emits token, payee, amount, indexed paymentReference, fee, and fee address; the paymentReference is last8Bytes(keccak(requestId + salt + payeeAddress)) (payment-detection/src/payment-reference-calculator.ts L11-L18).
The public storage subgraph indexes each stored transaction's plaintext data next to its channelId (requestId); the IPFS "private" swarm key is committed in docker-images/request-ipfs/swarm.key, so anyone can join it.
Which third parties see a request during a payment, and can they be swapped out? P4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
Third parties see payer and payee data during a payment. They are the indexer host (The Graph Studio in the SDK, Alchemy Subgraphs in the template), the RPC provider (Base's public RPC, or Infura on other chains), Request's hosted Request Node, and WalletConnect. Each is named in code, and all except WalletConnect can be swapped through SDK options or env vars. The template's always-on GTM tag is counted under P1. The hosted API path adds Pimlico, Li.Fi, and KYT vendors, but it is optional. No trace was run.
Evidence (3)3 verified
Verified
Payment detection queries Request's subgraph on The Graph Studio by default (L9-L10), or The Graph gateway when an API key is given; options.url overrides both (L157).
Default RPC goes through Infura with a built-in project ID for Ethereum-family networks, and through mainnet.base.org for Base; setProviderFactory (L123) and RN_WEB3_RPC_URL_* replace it.
The template sends Base payment lookups to an Alchemy Subgraphs (Satsuma) endpoint unless NEXT_PUBLIC_PAYMENTS_SUBGRAPH_URL_BASE is set; requests go to Request's Gnosis gateway; WalletConnect (Reown) and Lit Protocol are also wired in.
Can RPC and indexer URLs be changed, and is the indexer code public? P5
3 Strong
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
RPC, indexer, and Request Node URLs can all be set through SDK options, and the code for the indexer and the node is public. An integrator can keep payment detection and request storage inside their own infrastructure. The reference template exposes these settings only as env vars, and no UI offers them.
Evidence (3)3 verified
Verified
Indexer URL can be set per chain through the SDK's paymentOptions.getSubgraphClient or options.url (L157).
Public (MIT) subgraph manifest indexes ERC20FeeProxy 0x1892196E80C4c17ea5100Da765Ab48c1fE2Fb814 on Base from block 10827274; storage-subgraph and request-node are also public.
Who holds funds between payer and payee, and can the provider redirect them? S1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
For plain ERC-20 and native payments, funds move in one call straight from payer to payee, which on its own would score 3. Conversion payments run through Erc20ConversionProxy. Its owner, Request's Safe, can switch the delegatecall target with no delay. New code could redirect future conversion payments, or pull tokens from any wallet holding an open allowance to the proxy (see S3). The power is visible in verified source, and the Safe is named in the repo. Judgment call: we score 1 and not 0. We treat this as the "upgradeable, disclosed" case, because funds are never held between calls and the redirect needs a 3-of-7 Safe action.
Evidence (3)3 verified
Verified
ERC20FeeProxy calls token.transferFrom(payer, payee) and transferFrom(payer, feeAddress) in the same call; the contract never holds a balance. EthereumFeeProxy forwards msg.value and refunds the rest in the same call.
Conversion payments delegatecall paymentProxy in the context of the contract the payer approved; the owner can point paymentProxy at arbitrary code (L135).
Who can change the contract code, and with how much notice? S2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
The two fee proxies cannot be upgraded. Erc20ConversionProxy is not a proxy contract, but its owner can repoint the delegatecall target, which in effect replaces its code. That owner is a 3-of-7 Safe with no modules or guard, no timelock, undisclosed signers, and no notice channel. Judgment call: we treat the delegatecall-target setter as upgrade authority, so the cell scores 1 ("multisig admin, no timelock"). The core FeeProxy path alone would score 3.
Evidence (3)3 verified
Verified
The EIP-1967 implementation slot of ERC20FeeProxy reads zero, and so does EthereumFeeProxy's; neither has an admin function, so both are immutable.
The repo lists 0xf735afF55745e00D85F30AFB01E1c042D0755628 as the "RN Safe" administering contracts on Base; no signer list, timelock, or notice channel appears in the repo or docs.
How large an allowance does the SDK ask users to grant, and for how long? S3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
By default the SDK and the reference widget ask the payer for an unlimited allowance. The only disclosure is a JSDoc line ("with no limit") aimed at developers, and nothing tells the payer. An integrator can pass an exact amount. Unlimited approval to the immutable ERC20FeeProxy is limited by that contract's fixed code. Unlimited approval to Erc20ConversionProxy is exposed to whatever code its owner Safe later points it at (see S1, S2). We did not assess the hosted API's approval calldata.
Evidence (2)2 verified
Verified
approveErc20IfNeeded, approveErc20, prepareApproveErc20, and encodeApproveAnyErc20 all default amount to MAX_ALLOWANCE (2^256-1, utils.ts L16); prepareApproveErc20ForProxyConversion passes no amount, so it is unbounded too.
The reference payment widget calls approveErc20(requestData, signer) and approveErc20ForProxyConversion without an amount, granting unlimited allowance to ERC20FeeProxy or Erc20ConversionProxy.
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
This cell is derived from S1=1, C2=3, C3=2, and O3=1. Payees never leave funds with Request: payments land in their own wallets (S1), so nothing needs withdrawing if Request disappears. Settlement can continue by calling the immutable ERC20FeeProxy directly (C2). Request storage and detection can move to a self-hosted node and subgraph (C3), and a public frontend build exists. We did not reproduce a self-hosted deployment (O3=1), so the claim that settling continues through a public frontend is shown in code but not in a run. Judgment call: we score 2 and not 3 for that reason. S1's conversion-proxy risk only arises while the Safe is active.
Evidence (2)2 verified
Verified
ERC20FeeProxy is immutable (implementation slot zero, no admin) and an exact match to source that pays the payee directly.
Are secrets kept out of client bundles and are webhooks signed and verified? S5
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-07
No merchant secret reaches the browser. The open SDK path has no API key or webhook. The hosted API uses domain-scoped, revocable Client IDs on the client and signed webhooks, and the reference app verifies the signatures. There are two minor issues. The SDK bundles a shared Infura project ID. The reference verification uses a non-constant-time comparison on re-serialised JSON. Judgment call: we score 2 and not 3 because of these two issues.
Evidence (3)3 verified
Verified
The SDK ships a built-in Infura project ID (84842078…5213), which ends up in browser bundles; it authorises only RPC usage on Request's Infura quota, not merchant actions, and RN_INFURA_KEY replaces it.
The reference app verifies the x-request-network-signature HMAC-SHA256 with a server-side WEBHOOK_SECRET, but compares with !== (not constant-time) over re-serialised JSON instead of the raw body.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-07 12 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-07
We found no audit report, audited commit, or bug bounty for the deployed payment contracts. Payers are told the contracts are audited, but no report is linked anywhere we could find. The repo does run static analysis (Slither) and fuzzing (Echidna) in CI, which this criterion does not credit.
Evidence (2)1 verified · 1 claimed
Verified
No audit report, SECURITY.md, or bug-bounty scope exists in the monorepo or the org .github repo; a GitHub code search of the RequestNetwork org for "audit" finds no report; https://request.network/.well-known/security.txt returns 404. CI runs Slither and Echidna (.github/workflows/security-*.yml).
Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.
Request Network v1 smart contracts: Administrable, RequestCore, RequestEthereumCollect, RequestEthereum and three SafeMath libraries (packages/requestNetworkSmartContracts, branch audit-mainnet-0.0.3-verichains). at 4f10411553 Covers the 2018 v1 RequestCore contracts, which the current fee-proxy design replaced. The ERC20FeeProxy, EthereumFeeProxy, Erc20ConversionProxy and ChainlinkConversionPath deployed on Base are not in scope.
No
No major vulnerabilities reported; recommendations only.
Compiled from: The requestNetwork monorepo and the RequestNetwork org (GitHub code, commit, issue and PR searches for "audit"), the org .github repo, request.network/.well-known/security.txt (404), the mintlify docs repo, the requestNetwork-v1-archive repo, and auditor portfolios (Verichains public-audit-reports, Hacken, Nethermind, Trail of Bits, Spearbit). The Secure Payment page says the contract "is audited and valid" with no report linked. PR #1739 (2026-06) fixes a Medium finding from a Creed DAO audit of BatchConversionPayments and EthereumFeeProxy, and PRs #874/#878 (2022) fix escrow audit findings; neither report is published. Hacken's "Request Network | ERC20 | Apr2022" review covers the REQ token (Ethereum 0x8f8221af...a938a), not payment code, so it is not listed. 2018 commits name further v1 reviews (Kleros, an individual reviewer) with no published report. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.
Operational and procurement
Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.
Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 22 evidenced, 0 attested, 1 absent, 22 not applicable, 0 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.
Group A: operational facts
Fees
Evidenced
Component
Paid by
Amount
Basis
provider
payer
0.9% per transaction, capped at $500 (hosted API path)
Request Network pricing page; the docs say the rate can change, is not published there, and is returned per payment in metadata.protocolFee; the payer bears it by default.
provider
none
none in the contract (open protocol path)
ERC20FeeProxy takes no protocol fee; feeAmount and feeAddress are call parameters chosen by whoever builds the payment (for example an integrator's platform fee).
network
payer
gas included on EVM chains (hosted API path)
Pricing page; on Tron the payer pays a flat $3.99 per transaction.
network
payer
Base sample 2026-10-07, about 0.0000025 ETH (217,904 gas at 0.0116 gwei plus L1 fee)
Gas of one live payment on the open path (tx 0x2580…3d4e, block 52282170); that call also ran an Across fill, so a direct proxy call costs less. Varies with Base gas price.
network
payee
0.0999 xDAI per stored request (Gnosis storage fee, up to 1000 bytes)
RequestOpenHashSubmitter.getFeesAmount(1000) on Gnosis Chain; paid by whoever stores the request (usually the payee or its Request Node); the fee parameters are set by the Request admin Safe.
Two fee regimes. The open protocol path (the CROPS unit) charges no protocol fee in contract; the hosted API path charges 0.9% and includes gas. FX applies only to conversion payments, through Chainlink rates in ChainlinkConversionPath, and no FX margin is stated. No limits are published beyond the $500 fee cap and API rate limits.
Verified
transferFromWithReferenceAndFee moves _amount to the payee and _feeAmount to _feeAddress, both supplied by the caller; the contract has no fee of its own.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Custody model
Evidenced
Self-custody
Agrees with S1 (score 1). Funds move payer to payee in one call and are never held. The disclosed risk is that the 3-of-7 admin Safe can repoint Erc20ConversionProxy's delegatecall target and so redirect future conversion payments or open allowances; it does not hold funds.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Licences and registrations
Absent
Searched: the legal notice, API terms, privacy policy and pricing page (no licence or regulator named); the Swiss UID register entry; a finma.ch site search for "Request Network" (2 unrelated pages, no authorisation). Not searched: FINMA's authorised-institutions application and the Swiss AML self-regulatory organisations' member lists. Off-ramp flows on the hosted API run through Request Tech, whose licences were not looked up.
Documented
Legal notice names the Swiss foundation and its register number and cites no licence or regulator.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
API terms (last update 2025-12-22) state the foundation does not custody funds or process financial transactions; no licence is cited anywhere in the terms.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Cash-out options
N/A: falls to the institution
The optional Request Tech off-ramp is not recorded as a cash-out row because no first-party fee, limit or country terms were found for it.
On the open protocol path the payee receives the token in its own wallet; converting it to local currency is outside the protocol.
Verified
The hosted API offers an optional crypto-to-fiat flow through Request Tech off-ramp infrastructure, with payer KYC and a registered bank account; the docs give no fee, limit or country terms for it.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
First deployment
Evidenced
2024-02-20 (block 10827274): ERC20FeeProxy 0.2.0 on Base (tx 0x6db84f…0055, CREATE2). EthereumFeeProxy was deployed at 10827264 and Erc20ConversionProxy at 10827277, the same day.
This is the Base deployment, the unit of assessment. Request Network ran on Ethereum mainnet years earlier; that history is outside the unit.
Verified
Sourcify creation data gives transactionHash 0x6db84fa34fc60ad3217e532fc9cbe1b7514e2a1abf50e2b45bb21e3ba0220055, blockNumber 10827274, deployer 0x4E64C2d06d19D13061e62E291b2C4e9fe5679b93; the block timestamp is 2024-02-20 UTC.
The legal notice and API terms give a Baarerstrasse 82 c/o address; the UID register (last checked 2026-09-28) gives Gartenstrasse 5 c/o Coin Finance AG. The register is the primary source.
Documented
UID register entry, status active, legal form foundation (Stiftung), commercial-register reference CH-170.7.000.846-1, domicile c/o Coin Finance AG, Gartenstrasse 5, 6300 Zug.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Security incidents
Evidenced
Absence of a found incident is not evidence that none occurred.
Searched: GitHub security advisories for the monorepo, the docs repo release notes, the status page (status.request.network, history is client-rendered and was not read), and the CROPS S6 search (no audit, no bounty). No incident affecting the Base payment contracts was found. Third-party incident databases were not used.
Verified
The repository's published security advisories list is empty.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Product changes affecting users
Evidenced
2025-12-22: API terms and conditions updated (current version); they name the Swiss foundation as operator of the API and reserve the right to suspend access without notice. source
2026-07-01: Hosted API release notes add an orchestrator fee layer stacking on the protocol fee, Safe multisig payers, gasless approvals and Merkle Science KYT (docs commit 9152cc23). source
The Base payment contracts are immutable and unchanged since deployment. Release notes are labelled by quarter, so dates come from the docs commit.
Verified
2026-Q2 release note introducing orchestrators and the configurable orchestrator fee model; git log dates the docs change to 2026-07-01 (9152cc23).
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Volume transacted (verified only)
Unknown
not computed on 2026-10-19: eth_getLogs: request limit reached
Spec checked against the live log in tx 0x2580…3d4e (word 0 USDC, word 2 = 3000000). Not computed; the maintainer runs scripts/volumes.mjs.
UnreviewedAssessed by AI research agent (operational), 2026-10-09
Group B: institutional due diligence
Control
State
What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?
N/A: falls to the institution implied from the component list
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?
N/A: falls to the institution implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?
N/A: falls to the institution implied from the component list
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?
N/A: falls to the institution implied from the component list
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?
N/A: falls to the institution implied from the component list
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
N/A: falls to the institution implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?
Absent
none of 9 repo(s): RequestNetwork/requestNetwork ✗ no security policy file; RequestNetwork/payments-subgraph ✗ no security policy file; RequestNetwork/storage-subgraph ✗ no security policy file; RequestNetwork/request-helm-charts ✗ no security policy file; RequestNetwork/docker-images ✗ no security policy file; RequestNetwork/web-components ✗ no security policy file; RequestNetwork/invoicing-template ✗ no security policy file; RequestNetwork/easy-invoice ✗ no security policy file; RequestNetwork/mintlify-docs ✗ no security policy file source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?
N/A: falls to the institution
No closed component is required on the open protocol path, so patching the components an institution runs falls to it. For the optional hosted API, no patch timeline is published; the docs promise only security fixes for the previous API version for 6 months. source 1
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Evidenced
some of 9 repo(s): RequestNetwork/requestNetwork ✓ scanning step in a workflow; RequestNetwork/payments-subgraph ✗ no scanning config or workflow step found; RequestNetwork/storage-subgraph ✗ no scanning config or workflow step found; RequestNetwork/request-helm-charts ✗ no scanning config or workflow step found; RequestNetwork/docker-images ✗ no scanning config or workflow step found; RequestNetwork/web-components ✗ no scanning config or workflow step found; RequestNetwork/invoicing-template ✗ no scanning config or workflow step found; RequestNetwork/easy-invoice ✗ no scanning config or workflow step found; RequestNetwork/mintlify-docs ✗ no scanning config or workflow step found source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?
N/A: falls to the institution implied from the component list
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?
N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?
N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?
Evidenced
Status page at status.request.network for the hosted API; no post-mortem found. source 1 · source 2
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?
N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?
N/A: falls to the institution implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?
N/A: falls to the institution implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?
N/A: falls to the institution implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?
N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?
Evidenced
Browser calls to the hosted API use a static x-client-id plus the Origin header, scoped to allowed domains and revocable; no OAuth, OpenID Connect or JWT. Applies only to the optional hosted API; the open SDK path has no API. source 1 CROPS S5
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
Evidenced
Server calls use a static x-api-key header; webhooks are HMAC-SHA256 signed. No key scoping, expiry or rotation schedule is documented. source 1 CROPS S5 · CROPS S5
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?
N/A: falls to the institution implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
N/A: falls to the institution implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?
Evidenced
Privacy policy lists encryption in transit and at storage, two-factor and role-based authentication, continuous monitoring and restricted admin server access; no data classification or TLS version is stated. source 1
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?
N/A: falls to the institution implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?
Evidenced
Retention per purpose, from 2 years (account and service-use data, after last use if not closed) to 5 years (support requests); data stored in Europe. Termination of an API account is by email request; deletion on termination is not stated. source 1 · source 2 CROPS P2
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?
Evidenced
Request Network is controller for its sites and services and acts as processor for data handled on a customer's behalf (that processing is outside the policy). No DPIA is mentioned. source 1
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
N/A: falls to the institution implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
N/A: falls to the institution implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?
N/A: falls to the institution implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?
N/A: falls to the institution implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?
Evidenced
some of 9 repo(s): RequestNetwork/requestNetwork ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/payments-subgraph ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/storage-subgraph ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/request-helm-charts ✓ rules: pull_request, deletion, non_fast_forward; RequestNetwork/docker-images ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/web-components ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/invoicing-template ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/easy-invoice ✗ no branch rules visible (classic branch protection is not readable without push access); RequestNetwork/mintlify-docs ✗ no branch rules visible (classic branch protection is not readable without push access) source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
B9.3 Tests run in CI Do the CI workflows run the test suite?
Evidenced
some of 9 repo(s): RequestNetwork/requestNetwork ✓ test command in a workflow; RequestNetwork/payments-subgraph ✗ test command in a workflow; RequestNetwork/storage-subgraph ✓ test command in a workflow; RequestNetwork/request-helm-charts ✗ test command in a workflow; RequestNetwork/docker-images ✗ test command in a workflow; RequestNetwork/web-components ✗ test command in a workflow; RequestNetwork/invoicing-template ✗ test command in a workflow; RequestNetwork/easy-invoice ✗ test command in a workflow; RequestNetwork/mintlify-docs ✗ test command in a workflow source 1 · source 2 · source 3 · source 4 · source 5 · source 6 · source 7 · source 8 · source 9
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
Evidenced
Logical view (request lifecycle across IPFS, Gnosis storage and payment contracts) in the docs repo; integration and infrastructure for self-hosting in the Request Node README and Helm chart. No single architecture document covers all three views or the hosted API. source 1 CROPS C3 · CROPS O4
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
Request Network Stiftung (Request Network Foundation), Zug, Switzerland, CHE-422.666.391; API terms under Swiss law, courts of Zug. Only relevant to the optional hosted API; the open path needs no contract with anyone. source 1 · source 2
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Evidenced
Per-transaction protocol fee on hosted API payments (0.9%, capped at $500) collected by the foundation; the open fee proxies carry no fee. No annual report or treasury statement was found; the foundation's other funding (for example REQ token holdings) is not evidenced here. source 1
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
Either side can end API access; Request may suspend or revoke credentials without notice, and deactivates credentials unused for 12 months with one month's notice. Funds are never held, so termination does not affect funds. source 1 CROPS S1
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?
Evidenced
Optional automated wallet screening (Hypernative by default, Merkle Science optional) on the hosted Secure Payment page, enabled per destination; the docs describe it as rules and exposure thresholds, not a learned model. No automated decision in the open protocol path. source 1 CROPS C4 · CROPS C4
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
Evidenced
Screening categories, thresholds and a per-destination opt-out (override) are published; monitoring, validation, decommissioning and bias evaluation of the screening are not documented. source 1
Unit of assessment: the open Request Network protocol on Base. That means the SDK (request-client.js and payment-processor 0.63.0), a Request Node, and four settlement contracts: ERC20FeeProxy, EthereumFeeProxy, Erc20ConversionProxy, and ChainlinkConversionPath. Request's current docs describe only the hosted Request Network API. That API is closed; it is listed in components as not required, because a payment completes without it. Out of scope: batch, swap, recurring (pausable, AccessControl), escrow and commerce-escrow, SingleRequestProxy, EthConversionProxy (WhitelistAdminRole, the same pattern as Erc20ConversionProxy), cross-chain Li.Fi routes, Tron, and NEAR. Storage runs on Gnosis Chain. Requests are anchored through RequestOpenHashSubmitter 0x268C146Afb4790902Ee26A6D2d3aff968623Ec80, which writes to RequestHashStorage 0x2256938E8225a998C498bf86B43c1768EE14b90B. At Gnosis block 48631765, RequestHashStorage still whitelists the open submitter, and the storage fee is 0.0999 xDAI for 1000 bytes. The Gnosis admin Safe 0x8a4D2659f6d24312804BFA2f1F174A5498948037 is 3-of-7 with the same owners as the Base Safe, no modules, and no guard. Those reads are not recorded as evidence, because evidence must be on the primary chain. Base reads are pinned to block 52285354, and repo reads to requestNetwork@749b13070bcb88be4a10b8d59fcf3705339d43e0. No traces were run, and no self-host was attempted.
