Protect the ministry, the witness, and the people it serves.

1. Security contact

Send vulnerability reports to:

Use the subject line JCS Security Report. Email is the primary reporting channel. The public X account may be used to say that an urgent report was sent, but do not publish technical details, exploit code, private information, or an unpatched weakness on social media.

2. Systems in scope

3. Systems and issues outside JCS control

The following are generally outside scope unless the report demonstrates that JCS code or configuration directly causes the vulnerability:

• Xaman, XRPL Labs, Xumm/Xaman APIs, or the Xaman mobile application.
• The XRP Ledger protocol, validators, public nodes, WebSocket servers, or unrelated wallets.
• Sologenic, XPMarket, Bithomp, CoinGecko, YouTube, Internet Archive, Wikimedia, LibriVox, Facebook, X, Instagram, hosting providers, or other independent services.
• Browser, operating-system, device, extension, antivirus, ISP, DNS, email-provider, or network vulnerabilities not caused by JCS.
• Public blockchain data that is functioning as designed, including visible wallet addresses, transactions, memos, balances, trustlines, offers, and NFT identifiers.
• Token price movement, thin liquidity, slippage, lack of buyers, unsuccessful exchange listings, or ordinary market risk.
• Spam, theological disagreement, criticism, content disputes, or user testimony that does not involve a security vulnerability.
• Reports based only on automated scanner output without a reproducible security impact.

4. What to include in a report

A useful report should contain enough information to reproduce and understand the issue while avoiding unnecessary personal or sensitive data.

Use a test wallet and the smallest possible proof. Redact wallet secrets, access tokens, session identifiers, personal testimony, names, locations, and any information that could expose a believer to persecution or retaliation.

5. Good-faith security research

6. Prohibited testing and conduct

The following activities are expressly outside this policy and are not authorized:

• Denial-of-service, distributed denial-of-service, stress testing, resource exhaustion, or excessive automated requests.
• Social engineering, phishing, impersonation, fraudulent support contact, or requesting wallet credentials.
• Malware, ransomware, cryptojacking, persistence, command-and-control, destructive payloads, or modification of another person’s device.
• Physical intrusion, threats, stalking, doxxing, bribery, coercion, or targeting ministry participants.
• Testing against a real person without informed authorization.
• Data destruction, corruption, mass download, bulk scraping, or unnecessary data retention.
• Market manipulation, wash trading, front-running, exploit-based trading, draining an AMM, or intentionally creating harmful XRPL transactions.
• Publishing an uncorrected vulnerability, exploit code, secret, personal information, or dangerous detail before coordinated disclosure.
• Violating law, contractual duties, platform terms, sanctions restrictions, or another party’s rights.

7. Limited safe harbor for compliant research

When a researcher acts in good faith, stays within this policy, avoids harm, reports promptly, and gives JCS a reasonable opportunity to correct the issue, JCS will not initiate legal action against that researcher solely for the policy-compliant security research.

This limited statement applies only to JCS-controlled systems and only to conduct JCS has legal authority to authorize. It does not bind governments, prosecutors, law-enforcement agencies, Xaman, XRPL Labs, validators, hosting providers, social platforms, service providers, wallet owners, or other third parties. It does not excuse unlawful conduct, privacy violations, financial harm, extortion, reckless testing, or activity outside the stated scope.

If uncertainty exists about whether a proposed test is allowed, ask for written permission before performing it.

8. Expected response process

These are good-faith targets, not guarantees. Response time may depend on report quality, volunteer availability, access to affected systems, third-party coordination, legal requirements, and the seriousness of the issue.

JCS may ask for clarification, additional evidence, safer reproduction steps, or confirmation that sensitive data was deleted. A report may be closed when it is not reproducible, outside scope, already known, a duplicate, informational only, or not a security vulnerability.

9. Severity priorities

Severity is determined by actual exploitability, user interaction, scope, confidentiality, integrity, availability, wallet or financial impact, public-ledger permanence, and risk to people whose Christian identity could be exposed.

10. Coordinated public disclosure

Do not publish an uncorrected vulnerability or identifying details before coordination. JCS asks reporters to allow at least ninety days from confirmation for correction before public disclosure, unless the parties agree to a different timeline or immediate disclosure is legally required to prevent imminent harm.

A disclosure should protect users by omitting wallet secrets, access tokens, personal testimony, names, locations, unpublished code, live exploit paths, and information that could identify or endanger believers. JCS may request additional time when a correction depends on a third party, major redesign, application review, hosting provider, or wallet integration.

JCS may publish a security notice, correction summary, release number, affected version, mitigation, or acknowledgment when appropriate. Reporter acknowledgment requires the reporter’s permission.

11. No bug-bounty or payment promise

JCS does not currently operate a paid bug-bounty program and does not promise money, JCS tokens, XRP, NFTs, donations, employment, public recognition, or any other reward for a report. Do not incur costs or perform risky testing in expectation of payment.

JCS may voluntarily thank a researcher or provide acknowledgment, but any recognition is discretionary and does not create a contract, employment relationship, partnership, ownership interest, or entitlement to future compensation.

12. Reporter privacy and submitted information

JCS will use report information to investigate, reproduce, correct, document, coordinate, and defend against the reported issue. Information may be shared with developers, hosting providers, Xaman or another affected third party, legal advisers, security professionals, or authorities when reasonably necessary.

JCS cannot promise absolute confidentiality, attorney-client privilege, clergy-penitent privilege, or anonymous communication through ordinary email. Reporters should use an alias and avoid unnecessary identifying information when personal safety is a concern.

See the Privacy Policy for additional information. Never include a wallet seed, recovery phrase, private key, victim data, government identification, or information revealing a persecuted person’s identity unless lawfully necessary and specifically requested through a secure process.

13. Machine-readable security.txt file

The machine-readable file provides the primary contact, canonical location, policy URL, preferred language, expiration date, and bug-bounty status. It should be renewed before its expiration date so researchers do not rely on stale information.

14. Legal and ministry limitations

This policy is intended to encourage responsible reporting and improve security. It is not legal advice, a warranty that the site is secure, a promise that every report will be corrected, or a waiver of rights concerning conduct outside the policy.

JCS describes itself as a Christ-centered faith ministry and technology project. This security policy does not independently create or prove legal status as a church, nonprofit corporation, public charity, tax-exempt entity, or organization recognized under Section 501(c)(3).

Nothing here authorizes access to third-party systems, circumvention of law, violation of another person’s rights, or interference with public blockchain infrastructure. Mandatory law applies regardless of this policy.

15. Contact the JCS security team