Vulnerability Disclosure Policy

1. Our commitment

paySwapr holds customer funds in escrow. We take reports of security vulnerabilities seriously, and we would rather hear about a problem from you than from an attacker.

This policy explains what you may test, how to report what you find, and what we commit to in return. If you follow it, we will treat your research as authorised and will not pursue legal action against you.

This policy covers security vulnerabilities only. For a broken page, a display problem or a question about your account, please use the bug reporter or contact support instead — those reach the right team faster.

2. Safe harbour

When you conduct security research in good faith and in accordance with this policy, we will:

Consider your research authorised under applicable computer misuse and anti-hacking laws, and not initiate or support legal action against you for it.
Consider it authorised under any applicable anti-circumvention law, and waive any claim against you for circumventing technical measures for the limited purpose of this research.
Waive the provisions of our Terms of Service that would otherwise prohibit this activity, to the limited extent of the research permitted here.
Make this authorisation known if a third party brings action against you for research conducted under this policy.

If you are unsure whether a specific action is authorised, stop and ask us first. We would much rather answer a question than receive an apology. Safe harbour does not apply where you breach this policy — in particular the rules in section 5. support@payswapr.com

3. What is in scope

This programme covers the live production service:

We are most interested in issues that could lead to loss of customer funds, unauthorised access to an account, escrow or trade manipulation, exposure of identity documents or personal data, or privilege escalation into administrative functions.

payswapr.com and the subdomains serving the production platform
The production API under payswapr.com/api/v1
The installable web app (PWA) served from the same origin

Because this is the production platform, real customer funds and real identity documents are present. The rules in section 5 are not formalities — they are the conditions of your authorisation.

4. What is out of scope

The following are not eligible under this policy:

Denial of service of any kind — volumetric attacks, stress or load testing, resource exhaustion, or anything intended to degrade availability.
Social engineering of our staff, our support team, our users or our suppliers, including phishing, vishing and pretexting.
Physical attacks against offices, hardware or personnel.
Attacks requiring credentials obtained elsewhere, including credential stuffing and password-reuse testing against real accounts.
Automated scanner output submitted without a working proof of concept and a described impact.
Missing security headers, TLS configuration preferences, SPF/DMARC observations and similar best-practice findings with no demonstrated exploit path.
Self-XSS, and clickjacking on pages that carry no sensitive action.
Issues that only affect users running an unsupported or heavily outdated browser.
Rate-limiting thresholds you consider too generous, absent a concrete attack.
Third-party services we do not operate — our blockchain, email, hosting and CDN providers. Report those to the provider under their own policy.
Vulnerabilities in a user's own device, browser extensions or wallet software.

5. Rules of engagement

Testing takes place against a live financial platform. These rules exist so that your research does not harm the people using it.

Use only accounts you own. Register your own accounts for testing. Do not access, or attempt to access, any account that is not yours.
Never touch funds that are not yours. Do not move, withdraw, release, dispute or attempt to redirect another person's balance, trade or escrow.
Trade only with yourself. Do not open trades with real counterparties, and do not use a real person's offer as a test target.
Stop at proof. Take only the minimum action needed to demonstrate the issue. Do not pivot further into the system once you have proven access.
If you encounter another person's data, stop immediately. Do not view more of it, do not download it, do not retain a copy. Tell us in your report what you saw and delete it.
Do not degrade the service. Throttle your testing. No mass automated scanning, no brute forcing of live authentication, no bulk enumeration.
Do not submit fraudulent identity documents. Never upload another person's identity document, and never upload a forged document belonging to a real individual, to test our verification process.
Do not alter or destroy data. No deleting records, no defacing content, no persisting payloads that other users would see.
Do not exfiltrate. Proving you can read a record is enough; copying the database is not research.

Moving customer funds, retaining customer data, or degrading availability places you outside this policy and outside its safe harbour, regardless of your intent.

6. How to report

Send us one vulnerability per report. Reports in English are easiest for us to action quickly.

Please include:

A description of the issue and the impact you believe it has
The affected URL, endpoint or screen
Step-by-step instructions to reproduce it, and a proof of concept
The username or account you tested with
The source IP addresses you tested from, and the dates and times

Email support@payswapr.com

The report form is the quickest route and reaches the same team. Use email if your report includes attachments, or if you want to encrypt it.

Please do not include another person's personal data in your report. If demonstrating the issue requires it, tell us that and we will arrange a secure channel.

That last point matters more than it looks. We log and alert on suspicious activity, and knowing which traffic was yours lets us separate your research from a real attack — and stops us blocking you mid-test.

7. What happens next

Once we receive your report, we commit to the following:

Acknowledgement within 3 business days.
Initial triage and a severity assessment within 10 business days.
Progress updates at least every 14 days until the issue is resolved or closed.
Notification when the issue is fixed, with an opportunity for you to verify it.

Severity	Example	Target
Critical	Loss of customer funds, full account takeover	7 days
High	Access to another user's data or documents	30 days
Medium	Limited-impact logic or authorisation flaw	90 days
Low	Minor issue with a narrow exploit path	Best effort

If a report is a duplicate, out of scope, or we assess it as not a vulnerability, we will tell you and explain why.

8. Recognition

We offer public credit for valid reports. With your permission we will name you in our acknowledgements, and we are happy to confirm your contribution in writing if that is useful to you — for a CV, a conference submission or an employer.

Tell us in your report whether you would like to be credited, and under what name. If you would rather stay anonymous, that is fine too.

Recognition for a report is assessed case by case, taking into account the severity of the issue, the quality of the write-up and whether the finding was already known to us.

9. Public disclosure

Please give us a chance to fix the issue before telling anyone else. We ask that you do not disclose publicly until the issue is resolved, or 90 days after your report, whichever comes first.

If you intend to publish, tell us and we will coordinate timing with you. If a fix is taking longer than expected we will explain why rather than ask you to wait indefinitely. We will not ask you to sign a non-disclosure agreement as a condition of reporting.

10. Changes to this policy

We may update this policy as the platform changes. The version in force is the one published here, dated at the top of this page. A machine-readable pointer to this policy is published at /.well-known/security.txt in accordance with RFC 9116.

Wallet PIN Required

Contents