✝ Living vision · Current application · Responsible growth

Build technology that points beyond itself—and tells the truth about itself.

Jesus Christ Saves Token is a Christ-centered, non-custodial XRP Ledger project building Scripture, prayer and testimony tools, public verification, privacy-conscious communication, account readiness, transparent market observability and a longer-term Christian fellowship platform—without treating a token, NFT, wallet, application or social network as a substitute for Jesus Christ, Scripture, prayer, fellowship, church, pastoral care or personal responsibility.

Vision 4.0.0 XRPL Mainnet Non-custodial Public evidence · private dignity Source-visible · proprietary

The message comes first

Technology is a vessel, not the destination.

The written vision is complete without audio or video. The optional message player is not loaded until you choose to load it, reducing automatic third-party requests, saving bandwidth, and allowing discreet reading when sound or media could create risk.

Nothing on this page asks you to hold JCS, connect a wallet, mint an NFT, or make a transaction before reading the mission.

Loading the player contacts YouTube’s privacy-enhanced domain. The video does not autoplay and sound remains under your control.

Vision and core values

This is a living statement of intent and responsibility. It is not a technical white paper, securities offering, promise of profit, church charter, or claim of spiritual authority.

The mission is Christ; the technology is a tool. JCS exists to carry testimony about Jesus, preserve prayer and Scripture references in durable digital form, support voluntary fellowship, and make public project activity easier to verify.

Every system should protect human dignity, disclose its limitations, minimize private-data exposure, preserve user-controlled authorization, and remain useful even to a visitor who never buys, holds, or trades JCS.

Christ centered

Features should direct attention toward Jesus Christ rather than speculation, personalities, or technological novelty.

Human dignity

Prayer, grief, crisis, disability, poverty, persecution, and testimony must never become engagement bait.

Voluntary participation

No prayer, testimony, NFT, transaction, reaction, or public record should occur without a deliberate user action.

Non-custodial design

Users review and authorize through Xaman. The website must never request a seed phrase, private key, or wallet passcode.

Public transparency

The issuer, token identity, AMM, order books, transactions, and public records should be independently inspectable.

Privacy restraint

Public evidence should contain the minimum necessary information. Sensitive communication belongs off the public ledger.

Accessible witness

Core text should remain usable without sound, animation, a wallet, a token balance, or a high-powered device.

Stewardship over hype

Utility, truth, maintenance, safety, and service take priority over unsupported price, adoption, or partnership claims.

JCS operating charter

A compact statement of what the project is trying to build, what it refuses to turn into a token mechanic, and which boundaries should survive future technical changes.

Foundation Static client-side application
Wallet model User-controlled Xaman authorization
Evidence model Validated XRPL + local derivation
Social direction Purpose-driven fellowship, not attention extraction

What JCS is

A faith-centered XRPL issued asset and application ecosystem intended to make Scripture, prayer, testimony, public evidence and Christian service easier to encounter, preserve and verify.

What JCS is not

Not a church, pastoral authority, emergency service, bank, custodian, broker, guaranteed investment, proof of salvation, proof of identity, or substitute for professional care.

What the token may do

Support optional ledger utility, exchange activity, artifacts, receipts, access patterns and experimentation. Core Scripture, prayer participation, safety resources and human dignity should not depend on wealth.

What the token must never decide

Who deserves prayer, who is believed, who has spiritual authority, who receives crisis priority, whose theology counts, or whose human worth is greater.

No pay-to-pray
No pay-to-be-heard
No token-weighted theology
No wealth-based spiritual rank
No crisis-content auction
No secret wallet collection
No exact-location inference from prayer activity
No automatic claim promotion from a metric or AI output
No transaction without deliberate wallet review

What exists now

JCS now operates as a connected set of faith, ledger, privacy and observability tools. The cards below describe the current application rather than the older landing-page-only state.

Live

JCS faith + native XRPL portal

Scripture, sacred media, local fellowship tools, JCS/XRP trading, trustline/order workflows and explicit Xaman review.

faith exchange non-custodial
Open JCS Home
Live

Sign the Ledger v7

Prayer/testimony NFT minting, validated Prayer IDs, one-drop registry publication, replies, Amens and content-free Prayer Map refresh.

NFT social registry Xaman
Open Sign the Ledger
Live

Prayer Map v5

Thresholded prayer-focus cohorts, public XRPL reconstruction, support relationships, WWL/USCIRF context and map-safe aggregation.

threshold privacy XRPL map
Open Prayer Map
Experimental

Private Capsule

Browser-local AES-256-GCM encrypted communication with separate transport/key artifacts and an optional neutral NFT fingerprint receipt.

local-first encrypted optional receipt
Open Private Capsule
Live

JCS Network Observatory v3

Validated ledger health, public prayer-network metrics, privacy metrics, issuer state, JCS/XRP AMM and funded order-book conditions.

read-only communications market structure
Open Observatory
Live

Account Readiness v4

Xaman account-control authorization plus public-address inspection, pinned validated-ledger evidence, JCS relationship, NFTs, communication records and object inventory.

read-only account evidence no signing
Open Account Readiness
Live

Identity and machine discovery

Canonical domain, Web DID, XRPL TOML, AI manifest, sitemap, robots policy, security.txt and public source history.

DID metadata AI discovery
Open AI Manifest
Live

Terms, privacy, security + license

User-facing legal/privacy/security disclosures and a source-visible proprietary repository license with a narrowly defined federal-watchdog exception.

policy security license
Open Terms
Active development

Unified ecosystem hardening

Shared headers, mobile containment, evidence exports, validation TXT records, clearer transaction boundaries and consistent language are being applied file by file.

validation accessibility release integrity
Review repository

JCS Fellowship: the social-platform direction

The long-term objective is a purpose-based Christian community—not a copy of conventional social media built around outrage, follower competition, infinite scrolling, or the sale of attention. The following features are planned product direction, not claims of current deployment.

Planned

Prayer lifecycle

A request can move from prayer requested, to people committing to pray, to updates, continuing need, respectful closure, or an optional answered-prayer testimony.

Planned

Faith Circles

Small communities for family, local church, Bible study, grief, recovery, veterans, marriage, parenting, ministry projects, and invitation-only prayer.

Planned

Prayer Garden

A symbolic mini-game where prayer, encouragement, updates, Scripture, and acts of service grow a private or shared garden without pay-to-win advantages.

Planned

Scripture Path

Verse-order challenges, passage completion, parable matching, reflection prompts, memory progress, and collaborative reading journeys.

Planned

Acts of Mercy

A privacy-conscious way to offer or request practical help while publishing only the minimum information necessary for safe community response.

Planned

Quiet and Sabbath modes

A finite daily experience with Scripture, a limited number of prayer requests, one act of encouragement, reflection, and a clear stopping point.

No pay-to-pray
No pay-to-be-heard
No token-weighted theology
No wealth-based spiritual rank
No outrage-ranking feed
No deceptive infinite-scroll design
No crisis-post auction or paid priority
No private-data publication by default
No wallet secret collection

Designed for meaningful return, not compulsive return. The proposed experience uses belonging, progress, reciprocity, reflection, and completion as design principles. It should reward prayer, learning, encouragement, and service—not anxiety, comparison, outrage, or financial pressure.

Safety, privacy, and people at risk

Christian expression can carry personal risk. A public blockchain is durable and observable, so technical permanence must never be confused with confidentiality.

Silent access

Written Scripture, prayer references, safety guidance, and the mission must remain usable without audio, video, or animation.

Identity restraint

Names, locations, handles, medical details, legal matters, and identifying stories should not be placed on-ledger when disclosure could cause harm.

Public versus private

An NFT or transaction can create public evidence of an event. Private support, pastoral discussion, and sensitive communication require separate protected channels.

Public evidence. Private dignity.

The project now uses two deliberately different information paths. Public XRPL evidence is useful for chronology and verification; sensitive human communication should remain off-ledger unless a user deliberately publishes a minimal neutral fingerprint.

Public evidence plane

Designed for information that can safely be durable and independently reconstructed.

  • Validated XRPL transactions and ledger sequence
  • JCS issuer/currency identity and market structure
  • Prayer/testimony registry records deliberately published by the wallet holder
  • Prayer NFT receipt and ledger-derived Prayer ID
  • Thresholded Prayer Map cohorts and aggregate support relationships
  • Hashes, protocol versions, machine-readable metadata and evidence exports

Private dignity plane

Designed to avoid turning personal need into a permanent public record.

  • Local prayer journal and local drafts where implemented
  • Private Capsule plaintext and recovery keys remain outside public map metrics
  • Encrypted Capsule transport can be separated from its key card
  • Exact GPS, IP, browser/device and relay data are not accepted as prayer-location evidence
  • Operational escape routes, safe-house locations and vulnerable third-party identities should never be published
  • Endpoint compromise can defeat browser encryption; the system does not claim impossible confidentiality
Rule for future features

Do not put information on a public blockchain merely because it can be hashed, tokenized or minted. First decide whether the user benefits from permanent public evidence. If the information could endanger, embarrass, identify or expose a person, the safer default is local or protected processing with the smallest possible public receipt.

Public XRP Ledger transparency

Read-only metrics for the exact JCS issuer and JCS/XRP market. Wallet connection is not required. Every value is a current public-ledger observation or a disclosed calculation.

Metrics are idle until you choose to load them.
Open full Network Observatory

Loading metrics opens a read-only WebSocket connection to a public XRP Ledger server and requests an XRP/USD reference from CoinGecko. No wallet address, prayer, testimony, form entry, or browser identifier is intentionally included in these requests.

Network and evidence status

Validated ledger Not loaded Latest validated sequence reported by the selected server.
Ledger age Not loaded Seconds since the server’s latest validated ledger closed.
Evidence coverage Not loaded Successful source groups divided by the source groups attempted.
Last updated Not loaded Your device time when this report finished.

Issuer settings and distribution sample

Issuer domain Not loaded Decoded from the issuer’s AccountRoot Domain field.
Master key Not loaded Whether the AccountRoot reports the master key as disabled.
Global Freeze Not loaded Current issuer-wide freeze setting.
Clawback Not loaded Whether trust-line clawback authority is enabled.
No Freeze Not loaded Whether individual-freeze authority has been permanently limited.
Require Auth Not loaded Whether trust lines require issuer authorization.
JCS obligations Not loaded Gateway obligations when available; otherwise an observed trust-line sample.
Observed holders Not loaded Positive-balance trust lines in the bounded public sample, not beneficial owners.
Trust lines scanned Not loaded The scan is bounded to reduce public-server load.
Indicative network value Not loaded Not a valuation, appraisal, reserve attestation, or securities market capitalization.

AMM and funded order-book structure

AMM XRP reserve Not loaded Public XRP amount held by the JCS/XRP AMM.
AMM JCS reserve Not loaded Public JCS amount held by the JCS/XRP AMM.
AMM trading fee Not loaded Converted from XRPL fee units of 1/100,000.
AMM spot Not loaded Reserve ratio in XRP per JCS before trade impact.
10 XRP AMM impact Not loaded Constant-product estimate including the configured AMM fee.
Indicative pool value Not loaded Two times the XRP reserve multiplied by the external XRP/USD reference.
Best funded bid Not loaded Highest visible funded bid in XRP per JCS.
Best funded ask Not loaded Lowest visible funded ask in XRP per JCS.
Funded spread Not loaded Bid-ask difference divided by the midpoint.
5% bid depth Not loaded Visible funded XRP demand within 5% of the best bid.
5% ask depth Not loaded Visible funded JCS offered within 5% of the best ask.
Visible makers Not loaded Distinct public accounts in the returned bid and ask samples.
Reference price Not loaded Two-sided funded midpoint preferred; AMM spot used as fallback.
JCS reference USD Not loaded Reference XRP price multiplied by CoinGecko’s XRP/USD value.
XRP/USD Not loaded External market reference; not an XRPL-native value.
XRP 24-hour change Not loaded External CoinGecko reference when available.

Funded JCS sell offers

Maker JCS XRP XRP/JCS
Load metrics to inspect the book.

Funded JCS buy offers

Maker JCS XRP XRP/JCS
Load metrics to inspect the book.
How these metrics are calculated and what they cannot prove
  • All XRPL requests specify or rely on validated-ledger data when the method supports it.
  • Order-book amounts use taker_gets_funded and taker_pays_funded when present, falling back to the full offer only when the offer is not partially funded.
  • Trust-line retrieval is paginated but capped to reduce load. A capped sample is labeled rather than represented as complete.
  • Wallet addresses are not verified real-world identities, and multiple addresses may be controlled by one party.
  • Price, spread, depth, pool value, holder count, and indicative network value can change before another person loads the page.
  • No metric proves faith, truth, legality, solvency, intent, ownership, future price, or future project success.

Living roadmap

The roadmap prioritizes ministry purpose, human safety, privacy, accessibility, technical reliability, and truthful disclosure rather than promotional milestones.

Live

Canonical identity + machine-readable discovery

Domain, Web DID, AI manifest, XRPL TOML, security.txt, sitemap, robots policy and source history are live and independently inspectable.

Live

Prayer/testimony publication + map synchronization

Sign the Ledger v7 and Prayer Map v5 share a content-free refresh contract; validated registry records are independently reread from XRPL and remain subject to privacy thresholds.

Live

Network observability + account readiness

Metrics v3 and Account Readiness v4 separate observed ledger evidence, local derivation, privacy boundaries and optional JCS-only account context.

Experimental

Private Capsule communication primitive

AES-256-GCM local encryption, split transport/key artifacts, local decryption and optional neutral NFT fingerprint receipt are available experimentally; this is not yet a full private-message service.

Active

Release validation + cross-page consistency

Canonical headers, transaction safeguards, mobile behavior, machine-readable protocols and HTML-to-validation-TXT release records are being standardized across JCS.

Planned

Durable Fellowship accounts + Faith Circles

Introduce least-privilege account/session services, passkeys or wallet/DID options, invitations, blocking, reporting, moderation queues, appeals and small-group permissions.

Planned

Private messaging beyond the local Capsule

If durable private messaging is introduced, add sender/recipient authentication, key management, secure recovery, abuse controls, retention choices and cross-device continuity without leaking plaintext into XRPL.

Planned

Prayer Garden, Scripture Path + Acts of Mercy

Build reflective and service-oriented experiences without gambling, pay-to-win, spiritual ranking, manipulative streaks, crisis monetization or outrage engagement.

Planned

Independent review + production operations

Add backups, rate limits, audit logs, incident response, accessibility review, child-safety review, legal review, abuse testing and independent security assessment before higher-risk social infrastructure is treated as mature.

JCS ecosystem directory

Official JCS pages, public identity records, independent market interfaces, and related XRPL development work.

Source authority, legal posture and release integrity

Different documents answer different questions. This page summarizes them; it does not silently replace the Terms, Privacy Policy, Security documentation or repository LICENSE.

Validated XRP Ledger Controls current on-ledger facts such as account state, transactions, trust lines, NFTs, AMMs and order books. The website can summarize but cannot override the ledger.
Terms · Privacy · Security Control user-facing use conditions, privacy disclosures and security/reporting boundaries for JCS-controlled pages.
Repository LICENSE Controls permission to copy, modify, redistribute, deploy, derive from, train AI on or otherwise reuse covered source and project materials, subject to mandatory law and third-party rights.
AI manifest · DID · XRPL TOML · README Provide machine-readable/project identity, technical orientation and public documentation. They should not be interpreted more broadly than the higher-authority source relevant to a claim.

Religious identity boundary

JCS describes a Christ-centered religious mission. That description does not itself establish church, nonprofit, public-charity, tax-exempt or 501(c)(3) status.

Financial boundary

JCS is not represented here as a stablecoin, insured deposit, guaranteed-return product, guaranteed market, or promise of liquidity, price appreciation, listing or institutional adoption.

Ledger-evidence boundary

Hashes, NFTs, wallet authorization and validated transactions can document technical events. They do not automatically establish legal identity, authorship, truth, property ownership, regulatory compliance or pastoral authority.

Third-party boundary

XRPL, Xaman, explorers, exchanges, GitHub, media hosts, market-data providers and related XRBC tools are independently operated. References do not imply partnership, certification or guaranteed availability.

Safety boundary

JCS is not emergency, medical, mental-health, legal, law-enforcement, evacuation or crisis-intervention infrastructure. High-risk users should not rely on a public blockchain as a confidential channel.

Software boundary

The project is experimental and provided subject to its current Terms and LICENSE. Public servers, wallets, browsers, APIs and source code can fail or change. Validate critical actions independently.

Source-visible does not mean open source.

The current repository LICENSE is proprietary and all-rights-reserved. Public visibility does not by itself grant permission to copy, modify, redistribute, deploy, white-label, create derivative works, build datasets from, or train/evaluate AI systems on covered material. The LICENSE contains a narrowly defined Qualified Federal Watchdog exception and preserves third-party/public-domain material, fair use, compulsory process and other non-waivable rights. Read the complete LICENSE before relying on this summary.

Machine-readable charter ready in this page.

Important boundaries

The project’s religious mission does not remove technical, financial, privacy, legal, or human limitations.