Transparency

Open the canister on the ICP Dashboard to see its current module hash, controller list and cycle balance straight from the network — not from this page.

ICPay is custodial. Your ICP does not sit at your own principal; it sits in a subaccount of the ICPay canister, and that subaccount is derived deterministically from your principal.

Nothing is pooled or commingled at the accounting layer: your subaccount address is a pure function of your identity, so your balance is separately addressable and independently readable on the public ledger. You can look it up without asking ICPay anything.

The trade-off is honest and worth stating plainly: because the canister owns the account, the canister's code is what authorises a spend. That is the price of paying a username instead of a 63-character address.

These are not promises; they are consequences of the interface the canister exposes, which you can read in the source.

• Move your funds. Every transfer and withdrawal derives its source account from the caller's own principal. There is no parameter for a source account, so no call can be constructed that spends from someone else's balance.
• Transfer on your behalf. No admin, owner or operator endpoint exists for it.
• Reverse or seize a transfer. Once the ledger confirms, nothing in the interface can undo it.
• Read your Internet Identity key. ICPay never receives one.
• Delete your records. No erase endpoint exists, for the operator or anyone else.

The entire administrative surface is two functions: reserving and releasing a username, so handles matching well-known brands can be held back. Neither touches money.

Overstating decentralisation is how trust pages mislead. So: ICPay is controlled by a single principal, listed above. It is not under an SNS or a DAO, and it is not blackholed.

• Upgrade the canister to different code — including code that behaves differently from what is described here.
• Stop the canister, making the app unavailable until it is started again.
• Read the canister's stored state.

The backend is fully on-chain: accounts, usernames, balances and history live in the canister's stable memory on the Internet Computer, with no external database and no server holding user data.

This interface is published to an asset canister as well, listed above, so it can be served entirely from the Internet Computer at 63dke-waaaa-aaaan-q6mvq-cai.icp0.io. The same build is also hosted on Vercel, which is what most visitors reach; loading it there exposes your IP address to a conventional host even though every action still goes to the chain.

The on-chain copy is the one to prefer if you want the whole path verifiable, and it may lag the Vercel copy between deployments. Either way, a frontend can only misrepresent — it cannot move funds — which is why the addresses above are worth checking against the dashboard rather than trusted from this page.

• Read the source at github.com/prasangapokharel/ICPay. The fund-moving logic is in the backend's transfer and withdraw services.
• Inspect the live canister with dfx canister --network ic info 6vbhm-nqaaa-aaaan-q6muq-cai to read its controller and module hash directly from the network.
• Query your own deposit address from the app, then look it up on the ICP Dashboard to confirm the balance the app shows you matches the ledger.
• Follow the block link on any receipt to see the transaction on the public ledger, independent of ICPay.

Report vulnerabilities at GitHub issues. There is no bug bounty and no private disclosure channel — if a finding would put user funds at immediate risk, please consider that an issue is public before you file.

ICPay has not been formally audited. Nobody independent has reviewed this code for security.