Reporting a Vulnerability
Do not exploit a suspected vulnerability against public networks, user assets, or third-party systems.
#Prepare a report
- Identify the affected source revision, contract, function, or route.
- Describe the preconditions and expected versus observed behavior.
- Include a minimal local or testnet reproduction that does not expose real assets.
- Estimate impact and explain whether funds, roles, signatures, or availability are affected.
- Remove private keys, seed phrases, API credentials, and personal data.
#Use a verified private channel
A dedicated public disclosure address is not configured in the repository. Do not trust a contact sent through direct messages. Use a verified repository security-advisory channel when one is published, and confirm the recipient before sharing exploit details.
#Protect users
Avoid public proof-of-concept details before maintainers can assess the issue. Do not move, lock, or test with another user’s assets. Keep exact timestamps and hashes for your own authorized test activity.
#Frontend and documentation issues
For non-sensitive copy, accessibility, broken-link, or display problems, a normal repository issue can be appropriate once a verified project repository URL is published. Security-sensitive address or transaction problems should remain private.
#Current phase
WeedSwap is not deployed and no security-response contact is presented as active. This limitation must be resolved before a public, value-bearing launch.