Security Disclosure
How to report a vulnerability, what we commit to in return, and the current state of external review.
External audit status
Section titled “External audit status”No third-party security audit has been completed.
That is the first fact on this page because it is the one most easily buried. Nothing on this site should be read as implying otherwise.
What exists instead:
| Custody model | Keys are not designed to reach a server. That limits what a server compromise can do; it is not an audit of contracts you trade against |
| On-chain addresses | Published at Contracts so a wallet prompt can be checked |
| Known gaps | Published at Limitations rather than held privately |
None of that is a substitute for an audit.
An audit will be commissioned before any contract we author holds material value. The result — including findings — will be published here whether or not it is flattering.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Report privately, before disclosing publicly.
Channel: see Contact. A dedicated reporting address has not been published. Do not send findings to a mailbox you found somewhere else with this name on it.
Useful reports include: the affected surface, the conditions required to trigger it, what an attacker gains, and a reproduction if you have one. A rough report of a real issue is worth more than a polished report of a theoretical one.
What we commit to
Section titled “What we commit to”| Acknowledgement | Within 3 business days of a report that reaches an official channel |
| First assessment | Within 10 business days — severity, whether we can reproduce it, and an intended timeline |
| Fix and disclosure | Coordinated with you. We publish the mechanism once a fix has shipped, not before |
| Credit | Named, anonymous, or unattributed, at your choice |
Safe harbor. For research conducted within the scope below and reported privately, we will not pursue legal action and will not ask a third party to. This covers the research. It does not license access to other people’s accounts or funds.
In scope: the web application at rtp.fun (landing, documentation, and terminal), and any smart contract we publish on Contracts.
Out of scope, and why:
| Third-party venues and chains | pump.fun, flap.sh, Bags, four.meme, Raydium, Meteora, wallet providers, and the chains themselves. Report those to their maintainers |
| Findings that require a compromised user device | The key is on the device; a compromised device is outside what this design can defend |
| Rate limiting and denial of service | Report it. Volumetric testing against production is not authorized |
| Missing hardening headers with no demonstrated impact | Send them; they are worth fixing; they are not vulnerabilities on their own |
| Social engineering of the team or users | Out of scope |
What we ask you not to do
Section titled “What we ask you not to do”Do not access, modify, or exfiltrate data belonging to anyone else. Do not run denial-of-service tests against production. Do not use a finding to move funds that are not yours — a proof of concept that stops short of theft is sufficient, and one that does not is theft.
If you find yourself holding someone else’s data or funds, tell us immediately. Handled that way, it stays a disclosure.
Machine-readable
Section titled “Machine-readable”A security.txt file per RFC 9116 will be published at /.well-known/security.txt when a reporting address exists. It is not published today, because an empty or unmonitored address is worse than none.
History
Section titled “History”No vulnerability reports have been received to date. As they are received, resolved, and disclosed, they will be recorded here — including the ones we found ourselves.
An empty history is a statement about the product’s age, not about its security.