Connecting establishes the selected account for this browser session. It does not move XRP or tokens.
Xaman authorization · validated XRPL evidence · Mainnet only
Connect once. Inspect the account. Understand its JCS relationship.
This page uses the official Xaman browser authorization flow to identify the account the user selects, then reads a consistent snapshot from one validated XRP Ledger. Connecting does not create, sign, or submit a Payment, TrustSet, Offer, NFT, Batch, MPT, credential, delegation, sponsorship, or any other ledger transaction.
Release 4.0.0
XRP Ledger Mainnet
SignIn-only connection
No wallet secret collection
Protocol-forward object inventory
Security before connection
Xaman keeps wallet secrets inside the wallet. This page receives the selected public account after authorization and reads public ledger information. It does not ask for recovery words, a family seed, private key, Xaman passcode, device passcode, or remote access.
Addresses, balances, trust lines, offers, NFTs, objects, and transaction history may be visible to anyone.
Other JCS pages may prepare transactions. A user must independently inspect and approve each request in Xaman.
Xaman account-control authorization
The Universal SDK selects the appropriate browser, mobile, or xApp authorization path. The account returned by a successful Xaman session is treated as account-control evidence for the session—not as proof of the person’s legal identity or the truth of off-ledger claims.
1Official Xaman SDK ready
2Account authorized
3Validated ledger snapshot
4JCS relationship checked
No Xaman account-control assertion is active.
Connect Xaman or enter a public account below.
Read-only public account inspection
Anyone can inspect public ledger state without connecting a wallet. Pasting an address does not prove control of that address. The page does not save the pasted address in its own storage.
A format check is performed locally. The XRPL account_info result determines whether the account exists in the selected validated ledger.
Validated account-readiness snapshot
A single validated ledger sequence is selected first. Account, trustline, object, NFT, issuer, and reserve evidence is then requested against that ledger where the method supports it.
Snapshot time: —Source: —
Evidence SHA-256: generated after a validated snapshot is assembled.
JCS trustline and issuer relationship
The connected or inspected account is compared with the exact JCS issuer and currency. Missing trustline evidence is not converted into a zero balance when the query fails.
No account evidence loaded.
Balance from the inspected account’s trustline perspective.
Trustline limit reported for the inspected account.
Derived from the peer-side freeze field when returned.
Trustline setting from the inspected account’s perspective.
Whether peer authorization is explicitly shown on the trustline.
Issuer account_info not loaded.
No issuer-control evidence loaded.
JCS ecosystem readiness lens
This local interpretation layer connects the same validated account evidence to the broader JCS project: token receipt, prayer NFTs, Private Capsule neutral receipts, public prayer/testimony activity and Prayer Map participation. It is not a security score, identity proof, or guarantee that a later transaction will succeed.
Interpretation boundary: a trustline, token balance, NFT, public prayer record, DID, credential or other ledger object proves only the observed ledger state. It does not establish legal identity, spiritual authority, persecution status, off-ledger ownership, safety, authenticity or future behavior.
Create the public prayer/testimony record and optional prayer NFT through explicit Xaman approvals.
Open Sign the Ledger →View threshold-qualified prayer-focus aggregates without inferring a participant's physical location.
Open Prayer Map →Compare project-wide communications, privacy discipline, XRPL health and JCS market structure.
Open Metrics →Return to faith, fellowship and separately disclosed exchange tools.
Open portal →Account authority and controls
These are observable account settings, not a security certification. Active and inactive states are reported without assuming that either state is universally good or bad.
Decoded from the AccountRoot Domain field when present.
Alternative signing key address when configured.
Multi-signing evidence not loaded.
Public encryption-key field presence only; the key is not interpreted here.
No sponsorship evidence loaded.
AMM and Vault pseudo-account fields are identified when present.
Connect or inspect an account to populate this section.
Protocol-forward ledger-object inventory
The inventory groups the raw account_objects response by LedgerEntryType. New object types are shown verbatim instead of being discarded merely because an older page did not know them.
| LedgerEntryType | Observed count | Interpretation | Evidence note |
|---|---|---|---|
| No account_objects evidence loaded. | |||
Why this matters for newer XLS and protocol features
Current XRPL servers may return established objects and newer protocol surfaces such as Credential, Delegate, PermissionedDomain, MPToken, MPTokenIssuance, Sponsorship, Vault, Loan, LoanBroker, Oracle, DID, Bridge, and others. Presence is reported as observed ledger state only; it does not establish legal status, identity, solvency, or safe use.
Xaman and XRP Ledger standards alignment
“Compliant” here means aligned with the identified authorization, metadata, and public ledger interfaces. It is not a regulatory, security-audit, or institutional-certification claim.
Uses new Xumm(publicApiKey), authorize(), the success event, user.account, and logout(). No API secret appears in the frontend.
Selects a validated ledger from server_info, then requests account evidence at that ledger where supported. Unavailable evidence stays unavailable.
Follows returned markers for account_lines, account_objects, and account_nfts within disclosed page caps.
Links to the canonical /.well-known/xrp-ledger.toml route containing JCS issuer, token, icon, description, and application references.
The account-object inventory does not hardcode only the 2025 object set. Unknown or newly returned LedgerEntryType values remain visible in the report.
The page does not create a manual SignIn payload or any ledger transaction. Xaman handles browser authorization; XRPL calls are read-only public methods.
Local evidence export
The current snapshot can be downloaded or copied for support and diagnostics. The export contains public account and ledger evidence, page settings, limitations, and retrieval errors. It contains no seed phrase, private key, Xaman passcode, or API secret.
JCS Account Readiness v4 initialized.
Important limits
Account readiness is a public-data snapshot. It is not proof of legal identity, ownership of off-ledger property, financial suitability, moral character, spiritual standing, or future behavior.
- No transaction guarantee: this connection page is read-only and cannot confirm how another page will behave.
- No identity overclaim: Xaman authorization proves account control for the session, not a government identity.
- No reserve overclaim: spendable XRP is estimated only when ordinary reserve evidence is available; sponsorship can alter responsibility.
- No privacy overclaim: hiding an address in the interface does not remove public XRPL records.
- No availability guarantee: public XRPL servers and Xaman services may be unavailable, delayed, or rate-limited.
- No endorsement: use of Xaman or links to explorers does not imply endorsement, partnership, or shared control.