A company that provides a payment interface is not necessarily a company that holds customer funds. RICE Pay is designed as a non-custodial workflow that prepares and relays USDC payments authorized by the customer from the customer's smart account.
The decisive questions are not who built the screen, but where the funds are held and whose authority the smart account requires before executing a payment.
1. Customer funds are not held in a RICE Pay corporate wallet
USDC balances and ownership are recorded onchain at the customer's smart-account address. RICE Pay is not designed to record customer deposits on an internal ledger and pay from those deposits on the customer's behalf.
The RICE Pay corporate wallet and each customer smart account are separate addresses. A service interruption does not, by itself, turn customer funds into RICE Pay corporate assets.
Particle Network — Security (MPC-TSS) ↗Ethereum Improvement Proposals — ERC-4337 Account Abstraction ↗
2. Moving funds requires customer authorization
Particle Network's MPC-TSS documentation says the private key is split into shares, the full key never exists in one place, and only the user can initiate signing.
Displaying a recipient, amount and fee does not produce a valid payment. The customer must approve it using the authority recognized by the account. Login gives access to the account experience; approving a payment is a separate exercise of transaction authority.
3. Preparing and relaying a transaction is not signing it
RICE Pay's server may construct a payment request, calculate fees and relay a customer-approved operation to a bundler. A paymaster may also sponsor the network fee.
Under ERC-4337, a UserOperation contains the requested action and signature data, and the smart account validates its authority. A bundler packages valid operations for submission; it cannot manufacture customer authority that is not present.
- Construct a transaction draft
- Display recipient, amount and fees
- Submit an operation approved by the customer
- Sponsor the network fee
Particle Network — Account Abstraction ↗Ethereum Improvement Proposals — ERC-4337 Account Abstraction ↗
4. Smart-account rules—not the RICE Pay database—decide authority
A click recorded in the RICE Pay interface does not move USDC by itself. The smart account's onchain validation logic must accept the signature, nonce and other required conditions before execution.
RICE Pay therefore should be unable to withdraw a customer's balance merely by changing an internal record or calling an API. This property must be verified against the owners and validation modules of the deployed account.
Ethereum Improvement Proposals — ERC-4337 Account Abstraction ↗
5. Receiving a disclosed fee does not mean holding the payment amount
Receiving a RICE Pay service fee is different from holding the customer's full payment amount. The fee should move to the RICE Pay corporate wallet only as an explicit output of a transaction in which the customer reviews and authorizes the recipient, payment and applicable cost.
Receiving that approved fee does not grant RICE Pay authority over the remaining balance. An unlimited token allowance would create a separate spending risk, however, so it should be avoided or tightly constrained.
The exact scope of ‘RICE Pay does not control funds’
It means RICE Pay does not custody customer funds and cannot execute a payment from the customer's smart account using RICE Pay's authority alone. It does not mean that no external party can ever affect the asset.
The wallet provider, smart-account implementation, conversion partner and USDC issuer can have separate technical, contractual or regulatory powers. Circle's terms, for example, describe circumstances in which USDC addresses may be blocked or frozen.
- KYB, AML reviews and transaction restrictions by the conversion partner
- Freeze or block authority of the USDC issuer
- Recovery and upgrade policies of the smart-account implementation
- Network outages and smart-contract risk
- Irreversibility when a customer approves the wrong address
Non-custodial means RICE Pay lacks authority to move customer funds without customer approval—not that every third party lacks influence over the asset.
Circle — USDC Terms ↗Particle Network — Account Abstraction ↗
What RICE Pay can do—and must be unable to do alone
Separating service functions from control of funds makes the non-custodial model easier to understand.
| Function | What RICE Pay can do | What RICE Pay alone must not be able to do |
|---|---|---|
| Payment preparation | Construct a request showing recipient, amount and fees | Secretly approve a different payment |
| Transaction submission | Relay an operation signed by the customer | Execute an unsigned payment as valid |
| Gas fee | Sponsor network costs | Acquire ownership because it paid gas |
| Records | Provide status, alerts and receipts | Withdraw an onchain balance by changing an internal record |
| Fee collection | Receive a fee explicitly approved by the customer | Transfer the customer's remaining balance at will |
RICE Pay's intended customer-authorized, non-custodial design provides the middle-column functions without possessing the powers in the final column.
Put these advantages to work with RICE Pay
A product statement cannot prove that funds are beyond RICE Pay's control. The deployed smart account and application permissions should be checked against the following criteria, with material changes disclosed.
- RICE Pay is not an owner or co-signer of the customer account
- RICE Pay holds no broad session key or silent-signing authority
- RICE Pay cannot install or upgrade a module that permits arbitrary withdrawal
- The RICE Pay corporate wallet has no unlimited USDC allowance
- Recovery cannot let RICE Pay unilaterally replace account ownership
Conclusion: convenience and authority over funds must remain separate
RICE Pay can organize payment details, disclose fees and relay a customer-approved transaction. Final authority to send USDC from the customer's smart account must remain with a valid customer authorization.
Only when this principle is reflected in actual owners, modules, session keys and token permissions can RICE Pay accurately say that it does not custody or control customer funds.
A good non-custodial payment service does not move money instead of the customer. It helps the customer move its own money with greater clarity and convenience.
See what RICE Pay can improve in your supplier payments.
Share the amount, frequency, funding currency and supplier country. We will compare your current route with a clear, trackable RICE Pay workflow—no bank account numbers required for the first review.
Review my supplier-payment routeThis explanation is true only when production is deployed as described below. If RICE Pay holds an owner, administrator, recovery, unrestricted session-key or token-spending permission, the claim that it cannot control funds would not be valid.
Smart-account implementations and partner policies can change. Review current terms, deployed permissions and the transaction screen before use.