How payments work
A walk through what happens between sending RQT and getting full access, and why the operator's server cannot spend the coins it receives.
The pieces
| Piece | Where | Role |
|---|---|---|
| The app | your device | shows the deposit address, the tier and the prices; never handles your coins |
| Access service | the operator's server | issues codes and connection profiles, hands out deposit addresses, credits payments |
| Requant node | next to the access service | watches the deposit addresses through its public API |
| Exit nodes | Finland and the Netherlands | carry the traffic; one listener for the free tier, one for full access |
| Deposit wallet | offline, with the operator | the only place that holds the keys to the deposits |
1. A deposit address for every code
Requant transfers have no memo field, so a payment is matched to a code by the address it arrives at. The operator generates thousands of addresses in advance on an offline machine:
requant-wallet newaddress deposits.wallet --count 5000 --out deposits.txt
Only deposits.txt, a list of addresses, goes to the server. When a code first opens the Full access block, the service assigns it the next free address. An address is given to one code and never reused.
2. Watching for payments
Every minute the access service asks its own Requant node for the history of the addresses in use, up to 25 at a time through the public API. A payment counts when it has 6 confirmations. Each (transaction, address) pair is credited once, so asking again never credits twice.
3. Turning coins into days
The balance plus the new payment buys the most whole days it covers at the discount table; the rest stays on the balance. The paid days are added to any days left, and the code is extended to the end of the paid days plus one free period.
4. Enforcing the tier
- Each exit node runs two Hysteria2 listeners: the free one, with the free tier's bandwidth limit, and a full-access one without the daily quota.
- When the app fetches its connection profile, a paid code receives the full-access endpoints.
- When a device connects, the node asks the access service whether that device may use that listener; the full-access listener admits paid codes only.
- Traffic totals from both listeners are reported together, so the free tier's daily quota stays accurate.
5. Collecting the coins
The operator moves the deposits to cold storage without bringing the keys online:
requant-wallet watchonly deposits.wallet watch.wallet # once, offline
requant-wallet prepare watch.wallet <cold address> all --out sweep.json
requant-wallet sign deposits.wallet sweep.json --out sweep.signed # offline
requant-wallet broadcast sweep.signed
The 24-word phrase restores every deposit address (restore --count 5000). See accepting payments for the general recipe.
What the operator can and cannot see
- Can: which code paid how much and when, as it can already see each code's traffic totals.
- Cannot: spend the deposits from the server, or see the sites you visit; the access service keeps no browsing history.
- Cannot be fooled by a lost connection: a payment is credited from the chain, not from the app, so it is credited even if the app was closed.
Running it yourself
Payments are off unless a deployment turns them on. A self-hosted MagnetGate, a private group with its own exits and the peer pilot have no payment code path at all; the apps hide the Full access block when a service does not offer it. See modes and self-hosting.