Custody and Security
The platform’s servers do not hold, receive, or have any means of decrypting user private keys. This page says what that means, what it costs, and what it does not protect against.
Sign-in is not configured in this build, so there is currently no key on the device either. The statements below are the custody model the product is built on, not a claim that you can sign today.
Where the private key is
Section titled “Where the private key is”On your device. Not on ours.
Concretely:
- Transactions are constructed and signed in your browser
- The server is designed to receive signed transaction bytes and forward them
- There is no interface that exchanges a key for a signature
One verifiable property follows: even if every platform server were compromised, an attacker could not move user funds, because no signing material exists on the servers.
This is not a policy we could flip. It is the architecture.
Comparison with custodial tools
Section titled “Comparison with custodial tools”The industry alternative is server-side custody of decryptable keys. The extra click it removes is real.
| Custodial | rtp.fun | |
|---|---|---|
| Private key | Decryptable on a server | User’s device |
| Initiation | Server signs | Browser signs |
| Unattended operation | Supported | Requires an open page |
| Server compromise | Wallets can be drained | Funds cannot be moved from our side |
| Steps per operation | One fewer | One more |
Custodial design is not treated here as immoral. In a market where custodial platforms fail regularly, this trade-off is the one we accept.
The market currently votes the other way on volume. Non-custody is a reason to survive, not a growth story.
The costs
Section titled “The costs”| Cost | In practice |
|---|---|
| One extra confirmation | Messaging bots, if they exist, will not sign. They will open the app with the action prepared |
| Unattended operation is limited | Scheduled tasks require the page to stay open |
| Tasks stop | On disconnect they should mark stalled, not go quiet |
The third item is deliberate. A task that silently stops is worse than one that never starts.
Three outcomes for a transaction
Section titled “Three outcomes for a transaction”A transaction has three possible outcomes, not two:
| State | Meaning |
|---|---|
| Confirmed on-chain | A node confirmed inclusion and no revert |
| Failed | A node confirmed inclusion with a revert, with an on-chain reason |
| Indeterminate | No node could provide a conclusion |
Indeterminate is never displayed as failed.
The two states call for opposite actions: the first should be checked on a block explorer; the second can be retried. Reporting the first as the second causes duplicate orders.
When execution is enabled, a definitive on-chain error from any honest node is accepted immediately — a revert proves inclusion. A timeout is not a revert.
Platform fee
Section titled “Platform fee”The platform fee, when a recipient is published, is a transfer instruction in the same transaction, succeeding or failing with the trade. There is no state in which the trade succeeded and the fee did not, or the reverse.
When no recipient is configured, no fee is charged. See Fees.
What this model does not protect against
Section titled “What this model does not protect against”- Transactions you sign. We cannot revoke, freeze, or recover them.
- The token contracts you interact with. A token can do anything. We encode your intent; we do not audit the counterparty.
- Market risk. You can lose the entire principal.
- Your device. The key lives there. Device security is yours.
- Phishing. Check the domain. No channel we operate will ask for a private key or a seed phrase.
Security is not a paid add-on
Section titled “Security is not a paid add-on”Honest confirmation states and slippage bounds belong to correctness. They will not be placed behind a paid tier. Paid tiers, if they exist, sell speed and convenience only.
No third-party security audit has been completed. See Security Disclosure.