Main JCS portal
Threats include phishing, issuer substitution, malicious destination or amount changes, stale Xaman requests, dependency compromise and misleading market data.
Security stewardship · coordinated disclosure · people first
Protect the ministry, the ledger, and the people it serves.
JCS combines Christian prayer and testimony, public XRP Ledger evidence, Xaman-authorized transactions, market tools, NFTs, privacy-threshold mapping and experimental encrypted communication. A weakness can therefore create financial loss, permanent public disclosure or personal danger. This policy defines the security boundaries of the current ecosystem, how to report vulnerabilities, and how JCS intends to respond without asking researchers to endanger users.
Ministry principle: “The prudent man foreseeth the evil, and hideth himself.” — Proverbs 22:3, King James Version.
High-risk believer rule: If testing reveals a person's Christian identity, exact location, vulnerable third-party identity, private prayer/testimony, Private Capsule plaintext or recovery key, stop immediately. Do not continue exploring, correlate the wallet with real-world identity, copy more data, or publish the evidence. Report the minimum necessary facts privately.
No extraction or escape routes on public JCS surfaces.
Prayer-focus country or region is not treated as the signer's physical location.
Private Capsule plaintext and keys stay off XRPL by design.
A neutral receipt NFT is optional and can itself create wallet linkage.
No reporter should use real persecuted-believer data as proof of concept.
Physical-safety impact can raise security priority beyond conventional technical severity.
Security policy contents
1. Security contact
Email a security reportjesuschristsaves@gmail.com · subject: JCS Security ReportMachine-readable contact/.well-known/security.txt
Email is the primary reporting channel. An urgent public message may say only that a private report was sent; do not post exploit details, transaction substitution instructions, private information or unpatched attack paths on social media.
Minimal-report rule: use an alias if needed, a test wallet you control, redacted screenshots, and the smallest proof that establishes impact. Never send seeds, recovery phrases, private keys, Xaman passcodes, victim data or unnecessary government identification.
2. Project-wide security invariants
These are design requirements for the current JCS ecosystem. A violation can be a security defect even when the underlying third-party service behaves as designed.
JCS never needs a wallet seed, recovery phrase, private key or Xaman passcode.
Read-only pages must not create Xaman signing payloads.
Transaction-capable pages require an explicit user action and independent wallet review.
Signed or submitted is not settled; validated ledger evidence controls finality.
One user intent should map to one active signing request; stale requests are reset, not silently reused.
Six-digit challenges supplement—not replace—review of destination, amount, issuer, currency, NFT and memo fields.
Public Prayer Map refresh signals carry no prayer text, wallet identity or exact location.
Private Capsule plaintext and recovery keys never belong in public NFT metadata or XRPL memos.
No hidden master decryption key or universal recovery backdoor is maintained by JCS.
3. Current JCS surface and threat model
Sign the Ledger
Prayer NFT minting and public registry publication require deliberate approvals. Threats include duplicate minting, wrong memo/content binding, unintended public disclosure and false success before validation.
Prayer Map
Threats include re-identification, location inference, threshold bypass, malicious aggregation and confusing prayer focus with participant location.
Private Capsule
Threats include endpoint compromise, key mishandling, wallet linkage from an optional public receipt, malicious ciphertext substitution and accidental disclosure of transport plus key together.
Network Observatory / Metrics
Threats include stale or manipulated upstream data, wallet over-enumeration, false zero values when evidence is unavailable, and mixing external market context with validated XRPL facts.
Account Readiness
Threats include treating public lookup as account-control proof, enumerating unrelated assets, misreading reserve/trustline state, and relying on a stale or non-validated ledger.
Threat-model boundary: JCS can harden its own code and integration choices but cannot make Xaman, XRPL validators, public nodes, browsers, operating systems, DNS, email providers or independent market/media services secure by policy.
4. Systems in scope
JCS-controlled web surfaces
Production HTML, CSS, JavaScript, JSON manifests, metadata, static configuration and deployment artifacts served from jesuschristsavestoken.com.
JCS integration logic
Xaman authorization/payload handling, transaction construction, reset logic, memo/challenge binding, XRPL read logic and validated-ledger verification implemented by JCS.
Prayer, testimony and NFT workflows
Draft handling, mint/registry sequencing, public feed parsing, replies, Amens, Prayer Map handoff and JCS-controlled privacy thresholds.
JCS-controlled cryptographic wrappers
Private Capsule browser-local encryption/decryption, SHA-256 evidence fingerprints, key/transport separation and optional neutral receipt construction.
JCS-controlled policy/discovery files
security.txt, privacy/terms/security policies, AI manifest, Web DID, XRPL TOML, sitemap/robots and machine-readable security descriptors.
Repository/deployment configuration
Only where the specific repository, Pages deployment or project configuration is controlled by JCS and the report does not require unauthorized account access.
5. Systems and conditions outside JCS control
- Xaman/XRPL Labs services and mobile applications except where JCS integration logic introduces the defect.
- The XRP Ledger protocol, validators, public nodes and unrelated wallets.
- GitHub, hosting/CDN providers, DNS providers, explorers, Sologenic, XPMarket, Bithomp, market-data providers, media hosts and social platforms except for integration errors caused by JCS.
- Browser, operating-system, extension, antivirus, ISP or device vulnerabilities not caused by JCS code.
- Public XRPL visibility that is functioning as designed, including durable addresses, transactions, trust lines, offers, NFT identifiers and memos.
- Token price movement, thin liquidity, slippage, lack of buyers or ordinary market risk.
- Theological disagreement, criticism, content disputes or spam that do not demonstrate a security vulnerability.
- Automated scanner output without a reproducible, JCS-specific impact.
6. Xaman and XRP Ledger transaction integrity
Before wallet handoff
Resolve the exact JCS issuer/currency, freeze a user intent into one transaction template, reject self-contradictory inputs, and display the fields the user must compare in Xaman.
During signing
Maintain one active request for the intent, expose QR/deep link only for that request, make Reset clear stale UI/state, and use a six-digit challenge where the workflow supports it.
After signing
Require a transaction hash and validated ledger result; compare transaction type, account, destination, issuer, currency, amount, NFT fields and expected memo/challenge bindings as applicable.
Never treat as success
A QR appearing, Xaman opening, the user tapping sign, submission to a server, a non-validated response, an unmatched transaction or a locally generated receipt is not by itself a successful ledger result.
7. What to include in a report
Provide enough information to reproduce the issue without exposing unrelated people.
Subject: JCS Security Report
Reporter name or alias:
Preferred contact method:
Affected JCS URL / file / release:
Date and approximate time observed:
Browser / device / operating system:
JCS workflow or surface involved:
Clear vulnerability description:
Minimal reproduction steps:
Expected result:
Actual result:
Security / privacy / wallet / human-safety impact:
Proof of concept or redacted screenshot:
Whether any real wallet, transaction or person was affected:
Whether sensitive data was encountered (do not attach it):
Suggested mitigation, if known:
Requested disclosure timeline:
Use test data and a wallet you control. If a real person's content appears unexpectedly, stop and describe the category of data rather than copying the content into the report.
8. Good-faith security research
Within the intended research boundary
- Inspect publicly delivered HTML, CSS, JavaScript, JSON, headers and client-side requests.
- Use developer tools on your own browser session.
- Test only wallets, accounts, devices and content you own or are expressly authorized to use.
- Use the minimum action needed to confirm the flaw.
- Stop once impact is established or sensitive information appears.
- Report privately and allow reasonable time for remediation.
Outside the intended boundary
- Exfiltration, persistence, privilege escalation or lateral movement.
- Access to another person's wallet, Private Capsule, draft, testimony, device or account.
- Unauthorized real transactions or changing another user's intended transaction.
- De-anonymization, location inference or correlation of believers with real identities.
- Load testing, denial of service or flooding public XRPL infrastructure.
- Exploit-based trading, extortion, coercion or publicity pressure.
Stop condition: once a vulnerability is confirmed, or once sensitive information becomes visible, additional exploitation is not necessary to produce a useful report.
9. Prohibited testing and conduct
- DoS/DDoS, resource exhaustion or excessive automation.
- Social engineering, phishing, impersonation or credential harvesting.
- Malware, ransomware, cryptojacking, destructive payloads or persistence.
- Physical intrusion, threats, stalking, doxxing, bribery or targeting ministry participants.
- Testing on a real person without informed authorization.
- Mass download, scraping or retention of prayers, testimonies, wallet/activity mappings or encrypted materials.
- Market manipulation, wash trading, front-running or intentionally harmful XRPL transactions.
- Publishing an uncorrected vulnerability, exploit chain, secret or dangerous identity detail before coordination when doing so creates material risk.
10. Narrow assurance for policy-compliant research
When a researcher stays within this published policy, acts in good faith, avoids harm and reports promptly, JCS intends not to initiate legal action solely because of the minimal JCS-controlled web testing described here.
This is deliberately narrow. It is not a guarantee about prosecutors, governments, Xaman, XRPL Labs, hosting providers, wallet owners or any other third party, and it does not excuse unlawful conduct. If proposed testing is invasive, affects infrastructure beyond your own session, requires bypassing authorization, or falls outside the examples above, request written permission first.
License boundary: vulnerability reporting does not create an open-source or source-reuse license. The repository LICENSE continues to govern copying, modification, redistribution, deployment, derivative works, AI/model training and other reuse of proprietary JCS materials. This policy does not enlarge the LICENSE's separately defined Qualified Federal Watchdog exception.
11. Expected vulnerability-disclosure response
Targets are good-faith objectives, not contractual guarantees. JCS may request clarification, safer reproduction, deletion of inadvertently obtained sensitive data or coordination with a third-party provider.
12. Severity priorities: technical impact plus human safety
JCS may use CVSS v4.0 as a technical reference, but a numerical score does not replace contextual triage. Public-ledger permanence, irreversible wallet effects and exposure of a believer to persecution, stalking or physical harm are explicit priority factors.
13. Security incident response
Evidence minimization: incident response should preserve what is necessary for defense, legal obligations and root-cause analysis without turning the incident into a reason to collect unrelated prayer, testimony, location or wallet data.
14. Deployment and software-supply-chain hardening
Secure-by-default release behavior
Transaction pages should fail closed when issuer identity, Xaman state or validated evidence is unavailable. Missing evidence must remain unavailable rather than being rendered as a favorable zero or success.
Release evidence
Security-sensitive HTML releases should carry a release number and, where practical, a matching validation record with SHA-256, structural/browser test results and explicit controlled-versus-live test boundaries.
Dependency discipline
Minimize remote dependencies, constrain CSP/connect/frame origins, avoid unnecessary third-party loads, and keep policy/read-only pages free of wallet SDKs when no wallet is needed.
Hosting-header limitation
Meta CSP is useful defense in depth, but some protections—such as CSP frame-ancestors—require an HTTP response header. When hosting supports response headers, prefer server-delivered CSP and related hardening.
15. Coordinated public disclosure
JCS asks reporters to coordinate before publishing an unremediated weakness that could expose wallets, private content, user identity or a practical attack path. A default target of up to 90 days after confirmation may be used for correction, but timelines should adapt to exploit activity, third-party dependencies, legal obligations and immediate user safety.
Public advisories should omit wallet secrets, Private Capsule keys/plaintext, exact locations, vulnerable-person identities, live exploit tokens and unnecessary reproduction detail. When appropriate, JCS may publish the affected release, remediation, residual risk and credit requested by the reporter.
16. No bug-bounty or payment promise
JCS does not currently operate a paid bug-bounty program and does not promise money, JCS, XRP, NFTs, donations, employment, recognition or any other reward. Voluntary acknowledgment does not create a contract, partnership, ownership interest or entitlement to compensation.
17. Reporter privacy and submitted information
Security reports may be used to investigate, reproduce, remediate, document and defend against the issue and may be shared with only those developers, providers, security professionals, legal advisers or authorities reasonably necessary for that purpose. JCS cannot promise absolute confidentiality or privilege through ordinary email.
Use an alias and minimize identifying information when personal safety is a concern. If you inadvertently obtain a prayer, testimony, wallet-to-identity link, Private Capsule content or other sensitive data, do not include the contents in the report unless specifically necessary and a safer transfer method has been agreed.
See the Privacy, Religious Safety & Legal Process Policy for data-minimization, legal-process and user-notice principles.
18. Security records and legal process
A security report, incident record or preserved artifact is not automatically public. If JCS receives legal process seeking security-report information, the current Privacy Policy's legal-process protocol governs verification of authority, scope minimization, objections, user/reporter notice when legally permitted and disclosure only of information JCS actually possesses and is legally required to produce.
No surveillance expansion: a security incident or legal demand does not by itself authorize JCS to create new exact-location tracking, a universal decryption backdoor, new wallet-to-person correlation data, or records it did not previously possess.
19. Machine-readable security.txt
Canonical location
https://jesuschristsavestoken.com/.well-known/security.txtThe security.txt file is the machine-readable discovery point for security contact and policy information. It should remain available over HTTPS, be renewed before expiration and point back to this policy.
20. Security reference frameworks
RFC 9116 · security.txt
Defines the machine-readable vulnerability-disclosure contact file at the HTTPS /.well-known/security.txt location.
NIST SP 800-61 Rev. 3
Frames incident response as part of cybersecurity risk management across preparation, detection, response and recovery activities.
Open NIST guidanceCISA Secure by Design
Supports taking ownership of user security outcomes, secure defaults, transparency and accountability rather than shifting the full security burden to users.
Open CISA guidanceDOJ vulnerability-disclosure guidance
Provides a mature model for minimal good-faith testing, avoiding disruption and sensitive-data access, stopping after confirmation and coordinating disclosure.
Open DOJ VDPFIRST CVSS v4.0
Provides a common technical vocabulary for vulnerability severity. JCS adds wallet irreversibility, ledger permanence and human-safety context rather than treating the score as the whole decision.
Open CVSS v4.0OWASP CSP guidance
Supports Content Security Policy as defense in depth against client-side attacks and emphasizes stronger server-delivered controls when hosting permits them.
Open OWASP guidance21. Legal, ministry and license limits
- This policy encourages defensive reporting but is not legal advice, a security warranty or a promise that every report will be fixed.
- JCS's religious mission does not by itself create legal status as a church, nonprofit corporation, public charity or tax-exempt organization.
- Nothing here authorizes access to third-party systems, another person's wallet or private data, or conduct prohibited by applicable law.
- Publicly viewable source remains proprietary under the repository LICENSE; public visibility is not an open-source grant.
- Mandatory law, non-waivable rights, lawful compulsory process and third-party rights continue to apply.
22. Contact the JCS security team
Security report emailjesuschristsaves@gmail.comUrgent public notice@JesusCS_token · say only that a private report was sent
Never send: wallet seed, recovery phrase, private key, Xaman/device passcode, Private Capsule recovery key, exact location, vulnerable third-party identity or unnecessary sensitive personal information.
“Moreover it is required in stewards, that a man be found faithful.”
— 1 Corinthians 4:2, King James Version
— 1 Corinthians 4:2, King James Version