Risk Disclosure

Cryptocurrency payments carry risks that are different from traditional payment systems. Several of these risks are fundamental properties of the networks themselves rather than weaknesses of our software.

We have written this in plain language and in some detail because we would rather you understand the trade-offs upfront than be surprised later. By using NoHoldPay you confirm that you have read this disclosure.

If anything here is unclear, Contact us.

---

1. Volatility

Cryptocurrency prices fluctuate. The amount of crypto a customer pays is calculated at payment-creation time from a snapshot of fiat-to-crypto exchange rates. By the time the payment is confirmed, the value of the crypto in your local currency may be higher or lower.

We do not hedge this exposure for you. If you need price certainty in fiat terms, you should:

• Settle crypto to fiat promptly through your own custody / off-ramp.
• Charge for crypto volatility in your pricing (a "crypto convenience fee").
• Use only supported fiat-pegged stablecoins where your jurisdiction permits.

Stablecoins themselves carry depeg risk - the issuer's reserves, regulatory status, and operational integrity all bear on whether a stablecoin continues to hold its intended peg. We do not endorse any specific stablecoin or issuer.

---

2. Irreversibility

Confirmed blockchain transactions generally cannot be reversed by us or by the sender. There is no chargeback mechanism. Some networks, tokens, or issuers may have their own administrator controls, including freezes, pauses, blacklists, or clawbacks, but those controls are outside NoHoldPay's control. If your customer pays the wrong amount, pays the wrong address, or is the victim of a wallet compromise, we cannot undo the transaction.

Refunds happen only if you decide to send funds back from your wallet. See the Refund and Dispute Policy.

---

3. Reorganizations ("reorgs")

Public blockchains can briefly disagree about which blocks are canonical. A transaction that appeared confirmed can be reverted if the block that contained it falls out of the chain. This is normal for most chains and the reason every chain has a notion of finality - the point past which a transaction is treated as permanent.

Each chain we support has its own finality model. Confirmation depth requirements and finality signals are loaded from chain configuration and may be changed by platform administration. The platform supports these finality mechanisms:

If required finality configuration is missing or malformed, the platform is designed to leave the payment pending rather than silently treating a transaction as final.

When a per-chain "reorg-grace window" is configured, we continue to monitor after confirmation, so that a confirm-then-reorg event can move the payment to expired_reorged (if past expiry) or back to a pending state.

You should treat a payment as final only when our dashboard shows confirmed or your webhook receives payment.confirmed. Do not deliver goods or services on the strength of payment.detected alone for chains with non-trivial reorg risk.

---

4. Underpayment

Customers can underpay - for example, if the price moves between rendering the QR code and broadcasting, or if the customer transposes a digit. Dashboard state and webhook events can show when the cumulative received amount changes but remains below the requested amount, so you can decide:

• Accept the underpayment where allowed by configured shortfall limits - the payment is confirmed at the actually received amount.
• Refund the partial amount from your wallet back to the customer's wallet.
• Wait for the customer to top up - they can complete the payment by sending the remainder to the same payment instructions, and our watcher will count cumulative receipts where supported.

You set the policy. We provide the controls and signals.

---

5. Expiry and late-grace revival

Each payment has a configured expiration window. If the customer does not pay before expiry, the payment is moved to expired (no funds received) or expired_underpaid (partial funds received).

We honor a late-grace window after expiry - a transaction that arrives slightly late can still revive the payment. The grace window is per-chain, and revived payments are handled under the applicable chain and payment rules.

---

6. Non-custodial responsibility

Because NoHoldPay does not hold your funds, you carry the responsibility for key custody.

• The wallet identifiers, public keys, addresses, and Monero view key we receive do not let us spend funds. If you lose the corresponding seed, spend key, or private key, NoHoldPay cannot regenerate it or move funds for you. We never see those spending keys.
• For CREATE2 / PDA forwarder modes, the control key you authorize is used for treasury-management and recovery operations. If your control key is compromised, settlement or recovery paths may be affected. Treat the control key with similar care to an online signing key.

Download and securely back up your recovery kit. It contains recovery information that can help re-derive forwarder addresses where supported if NoHoldPay is unavailable. It does not guarantee that funds can be moved; recovery may still depend on the chain, token, contract or program state, issuer restrictions, and the keys you control.

---

7. Smart contract risk

For EVM CREATE2 forwarder, TRON CREATE2 forwarder, and Solana PDA forwarder payments, funds may interact with deployed settlement contracts, chain programs, or forwarder addresses. While we apply multiple layers of defense - design review, automated testing, deployment checks, monitoring, and external review where appropriate - no contract or chain program is guaranteed to be free of bugs.

Depending on the chain and rollout stage, we use automated testing, manual review, deployment checks, and external review where appropriate. Audit status may be published in our documentation.

To bound blast radius, we apply a configured per-merchant in-flight USD cap on CREATE2 / PDA modes. New forwarder payments can be rejected when confirmed-but-unswept exposure plus the new payment would exceed the effective cap. This is not insurance. It is a guardrail against a hypothetical worst case.

For modes still in staged rollout, platform administration may keep caps low or disable a mode for a chain. You may see chain options unavailable, or a 409 INFLIGHT_CAP_EXCEEDED error when you would otherwise expect a payment to be creatable.

---

8. Broadcast infrastructure risk

For payment modes where we broadcast transactions on your behalf, we operate signing and relay infrastructure for those specific features. This infrastructure is separate from your receiving wallets and does not give us access to your treasury keys, but it can affect whether automated sweeps, sponsored transactions, or relays proceed on schedule.

We protect this infrastructure with security controls, access controls, monitoring, and controls that pause affected features when a serious issue is detected.

If this infrastructure is unavailable or compromised despite these defenses, automated sweeps and relays may pause. Your customer-facing payment flow may require merchant-signed recovery, self-recovery tooling for supported forwarder modes, or another supported recovery path. We may notify affected merchants where appropriate and practical.

---

9. Gap-filler events (HD wallets)

Supported HD UTXO wallets use a gap limit - the wallet stops scanning new addresses after a configurable number of unused ones in a row. When NoHoldPay generates a new payment address for you, that address is unused on your wallet's view. If we issue many payments faster than your wallet scans, your wallet's gap limit can be exceeded, and your wallet stops "seeing" the newest addresses.

For supported HD UTXO chains (BTC, BTC testnet, LTC, LTC testnet, BCH, BCH testnet, DOGE, and DOGE testnet), the gap-filler can issue small payments to unused derived addresses so compatible wallet software keeps scanning far enough to see later paid addresses. Gap-filler is not used for static EVM, TRON, Solana, XRP, Stellar/XLM, or Monero wallets.

Two flavors are available:

• Self-serve gap filler. We produce a gap-filler plan; you sign and broadcast the required transaction with your own wallet tooling.
• Platform-paid gap filler. You opt in. We sign and broadcast from a platform-operated funding source; the dust + miner fee + a small platform fee is deducted from your prepaid balance.

Gap-filler broadcasts and recorded events appear in your dashboard with status details and, when available, a transaction hash.

---

10. Stuck sweeps

For CREATE2 / PDA forwarder modes, an automated sweep can fail. Common causes include exhausted automated retries, token issuer restrictions, treasury addresses that cannot receive funds, on-chain reverts, temporary fee or energy-provider shortages, required factory / program migrations, or contract / program defects.

For recoverable sweep failures, funds remain at the forwarder address and may be movable through one of the recovery paths below. Some failures, including issuer freezes, unsupported tokens, or contract / program defects, may not have an on-chain recovery path under the affected deployment.

• Use the manual-sweep flow in your dashboard where supported, with your own wallet signing the recovery transaction.
• Use offline recovery tooling with your recovery kit where supported.

If a settlement issue occurs, we may investigate, pause the affected mode, retry settlement, or provide supported recovery information where technically available. These are support measures only. They are not a guarantee of recovery, and NoHoldPay does not insure, replace, repay, or make you whole for funds affected by smart-contract, chain-program, relay, or settlement-infrastructure issues.

---

11. Factory migrations

If we ever need to redeploy a CREATE2 factory or Solana program (for an audit fix, a security patch, or other operational reason), new payments use the new factory or program. In-flight payments continue to be handled through the version that created them, and pre-migration forwarder addresses are designed to remain recoverable where technically possible.

For payments that get stuck during a forced migration, we may provide support-coordinated recovery information or supported merchant-signed recovery where available.

Where the dashboard offers a migration opt-out, opting out retires the affected wallet at the end of the migration window; you must rotate to a new wallet before then. See the in-dashboard migration UI when one is in progress.

---

12. Third-party provider risk

Some of our functionality depends on third parties. If they fail or change their interface unexpectedly, you may see:

• Stale exchange rates (rate providers down).
• Delayed payment detection (RPC providers down).
• Delayed webhook deliveries (network issues between us and your endpoint).
• Delayed Monero payment detection (Monero scanning infrastructure or node availability).
• Failed TRON CREATE2 forwarder sweeps under sustained Energy-marketplace outage.
• Delayed or unavailable TRON platform-paid sweeps if Energy providers are unreachable or unavailable.

Where practical, we use fallback providers, retries, or alternate routes. Not every dependency has an equivalent fallback, and we cannot guarantee third-party availability.

---

13. Monero view-key trust boundary

This deserves its own section because it is unusual.

Monero is a privacy-preserving blockchain. No service can detect incoming Monero payments without your view key. This is true of every non-custodial Monero processor, including NoHoldPay.

When you create a Monero wallet on NoHoldPay you must paste:

• Your primary address (public).
• Your private view key (sensitive).

You retain your spend key in your own wallet (Feather, Cake, Monero GUI, etc.). We cannot move your funds. But:

• We can see incoming payments and wallet activity needed to detect and reconcile payments for that wallet for as long as the view key remains valid.
• The view key may reveal more wallet history and balance information than the individual checkout payments you create through NoHoldPay.
• We cannot see the spend key, cannot sign spends, and cannot move funds.

We store the view key encrypted and use it only as needed to detect and reconcile payments. The view key is not sent to public Monero remote nodes.

If you are not comfortable with this trade-off, do not enable Monero on your account. The merchant wallet creation flow includes a mandatory acknowledgement checkbox covering exactly this point.

For a full discussion, see Monero merchant wallet privacy.

---

14. Regulatory risk

The regulatory treatment of cryptocurrency, stablecoins, sanctions, taxes, reporting, and payment processing varies by jurisdiction and can change.

NoHoldPay does not provide legal, tax, accounting, sanctions, or compliance advice. We do not determine whether your use of the service is lawful for your business, customers, assets, networks, or jurisdictions.

You are solely responsible for understanding and meeting any licensing, registration, tax, reporting, sanctions-screening, travel-rule, consumer-protection, or other obligations that apply to your activity. Any controls we apply for our own risk management or Acceptable Use Policy do not satisfy your obligations.

---

15. No insurance

There is no government deposit insurance for cryptocurrency held in your own wallet. There is no FDIC, no FSCS, no equivalent. If your wallet is compromised, funds may be lost permanently. If a stablecoin issuer collapses, the tokens may become worthless. If a token issuer freezes or blacklists an address, NoHoldPay cannot unfreeze the asset or force the issuer to release it. If a contract or chain program has a bug, funds may be drained, delayed, or permanently stuck.

NoHoldPay does not insure, replace, repay, or make you whole for these scenarios except to the limited extent expressly required by the Terms of Service or applicable law.

---

16. Bottom line

NoHoldPay can help automate crypto payment acceptance and reduce integration work. We cannot make crypto payments risk-free. The risks here are real. They are the price of holding your own funds and operating on public networks and issuer-controlled tokens that NoHoldPay does not control.

---

17. Changes

We may update this document. Material changes will be announced via email and/or via the dashboard at least 14 days before they take effect when reasonably practical. Changes required for legal, security, risk, chain-support, or urgent operational reasons may take effect sooner. The header of this document reflects the current version.

---

18. Contact

Questions may be submitted through the contact page.