Skip to main content
On networks where compliance is enabled (mainnet today), every route is screened against sanctions and risk data before its funds move. Screening is automatic and enforced on-chain — as a builder you do not run, attach, or sign anything to “pass” it. This page covers the two things you do need to account for: the screening fee and the verification window (plus what happens on a denial).
You take no action to pass screening. The MultiHopper keeper screens the route and submits the on-chain verification for you. The only builder-facing impacts are funding the screening fee and tolerating a short verification delay before hops execute.

​
What gets screened

When the gate is on, the route’s origin (the sourceOwner / funding wallet) and every recipient in the route — including the final recipientWallet and all intermediate hops — are screened together. The set is cryptographically bound to the route, so funds cannot be screened against one set of addresses and then moved to another.

​
The screening fee

PropertyValue
AmountA flat per-deploy fee — currently 0.002 SOL on mainnet (a configured value, subject to change)
Paid bysourceOwner (the signing wallet)
Charged whenAt deploy, inside the /prepare transaction bundle
Charged if flagged?Yes — the fee is collected regardless of the screening outcome
Refunded?Yes for a clean (verified) route — the deposit is returned to sourceOwner on verification
In /estimate?No — you must add it on top of the estimate yourself
The fee is a refundable anti-abuse deposit, not a fixed protocol constant: a clean route gets it back when screening verifies, while a flagged route forfeits it. The amount is configured per network and may change, so treat 0.002 SOL as the current mainnet value rather than a guarantee.
The fee is not returned by /estimate, but it is charged by /prepare. Ensure the sourceOwner wallet holds transfer amount + protocol fees + account rent + keeper funding + 0.002 SOL before signing, or the deploy can fail for insufficient lamports. This is the most common reason a route fails to deploy on mainnet.

​
Lifecycle

create → prepare → sign + broadcast → confirm-broadcast
                                            │
                                            ▼
                              (route deployed, fee charged)
                                            │
                            keeper screens + verifies on-chain
                                            │
                        ┌───────────────────┴───────────────────┐
                        ▼                                        ▼
                   verified                                   flagged
                hops execute                          principal refunded,
              status → completed                       fee retained,
                                                      status → refunded
After your final confirm-broadcast, the transfer sits in processing while the keeper screens the route and submits the on-chain verification. This typically takes a few seconds. Once verified, hops begin executing and the transfer proceeds to completed as normal. Keep polling GET /transfers/{id} — no action is required during this window.

​
When a wallet is flagged

If any screened address is flagged, the route is not executed:
  • The principal is refunded to the sourceOwner.
  • The screening fee is retained.
  • The transfer ends in refunded status.
  • For privacy and legal reasons, the specific reason for a flag is not disclosed.

​
Enforced on-chain — not by the API

Compliance is a property of the deployed smart contract, not the API server or keeper. The required compliance account is mandatory on every fund-moving instruction, and the program refuses to move funds for a route that has not been verified while the gate is on. This means a route cannot be constructed to bypass screening, whether it is built through this API or by hand. See the Security Model for the underlying guarantees.

​
Networks

  • Mainnet — the gate is on. Screening and the fee apply as described above.
  • Test mode (mh_test_* keys) — use test-mode keys to integrate against the lifecycle without moving real value. Verify that your wallet budgets for the fee and that your code keeps polling through the verification window.