Wallet Auth and XEL Product Shell

Wallet Auth and XEL Product Shell

Role

XEL.xyz is the public destination for published Living Characters. It should feel like a consumer-facing character surface, not only a protocol explorer. The public product shell gives a XEL object a shareable profile, public assets, a direct conversation entry point, and a secondary proof/details surface for provenance and protocol state.

Wallet authentication is the onboarding and account layer for people using XEL.xyz. It is separate from a Living Character’s own on-chain ownership, delegate, and treasury wallets.

Product Shell

The default public destination is a character profile page at XEL.xyz. It should be optimized for discovery, sharing, inspection, and conversation.

Core profile elements:

• public character name, avatar, handle or slug, and profile bio
• public profile links, such as website, socials, storefronts, communities, or related archives
• verified XEL Living Character identifier
• creator or publisher attribution when public
• ownership state and high-level authority status
• public media and asset grid
• primary chat call to action
• customize settings link for the owner/admin flow
• funding wallet section near the bottom of the page with runway status
• link to Proof of Genesis and protocol details
• links to public discovery metadata where available

The profile should use an Instagram-like character presentation model: identity at the top, compact metadata, profile links, and a grid of visible public assets below. The goal is for users to understand who the character is, where else they can be found, and what public material anchors it before opening a chat or inspecting proof records.

The profile bio is first-class public profile data, not the private persona/system prompt. It is short public copy for people browsing XEL.xyz. It can be written directly by the owner, generated by a provider, or derived from a persona artifact, but it must not expose classified system prompt text or private source evidence.

Profile URL Hosting

Public profile URLs use the Instagram/TikTok-style route:

https://xel.xyz/@username

The public profile artifact for that route must be hosted as a Walrus Site. XEL infra can keep the human-friendly xel.xyz/@username URL by resolving or proxying the current Walrus Site object, but the profile HTML/manifest/media bundle should be published through Walrus Sites, not only stored on the XEL VPS.

The manifest should record:

• Walrus Site object ID
• Walrus portal URL
• SuiNS name when one is configured
• resource-map or ws-resources.json reference
• deployed network, epochs, expiry, and renewal state
• publisher wallet and content digest

The reference helper runtime/storage/walrus-sites.mjs builds the offline publish plan for this boundary. A profile plan binds:

• canonical route: https://xel.xyz/@username
• Walrus Sites content source: static profile build directory, entry HTML, public profile manifest, and public assets path
• deploy command: site-builder --context=testnet deploy --epochs <n> <site-dir>
• first deploy output: the site object ID and ws-resources.json resource map
• renewal/update command: rerun site-builder deploy against the existing site object or resource map before the storage window expires

The helper is planning-only by default. Live publishing still needs site-builder, current Walrus/Sui testnet configuration, and a publisher wallet funded with SUI gas plus WAL storage balance.

The settings page, signed owner actions, paid interaction, email login, and chat runtime remain dynamic XEL application services. They are linked from the profile but are not part of the immutable/static Walrus Site profile artifact.

Profile links are first-class public fields. They should support common destinations:

• official website
• social profiles
• creator or publisher page
• community links
• merch/storefront links
• archive or source collection links
• external proof, marketplace, or explorer links

Each link should carry a label, URL, optional relationship type, optional platform, and optional verification/provenance status.

Public Assets and Media Grid

The media grid is the primary public artifact surface for a Living Character. It can display images, videos, documents, social-derived references, generated assets, or other public evidence selected for publication.

Grid items should resolve from protocol artifacts or provider-neutral references, not private GEN account state. Each item should be able to carry:

• display media URL or content-addressed reference
• media type
• title or caption when public
• content hash or integrity reference when available
• visibility status
• source or provenance reference when public
• relationship to the character package, persona artifact, or Proof of Genesis

Private source evidence, private prompts, classified persona artifacts, and GEN-only synthesis inputs must not appear in the public grid unless the owner explicitly publishes derived public metadata.

Chat CTA

The primary action on a Living Character profile is to chat with the character. The CTA should take the user to the configured runtime experience for that character.

The chat entry point may require wallet sign-in depending on the product policy, usage limits, payment requirements, or provider configuration. That sign-in authenticates the human user; it does not make the user’s login wallet the character owner, delegate, or treasury wallet.

For the first launch, creating a XEL object is not blocked by payment. The profile can publish first, then ask the owner or supporters to fund the XEL object. By default, chat should be disabled until the XEL object reaches the configured activation threshold. The profile should expose a clear disabled chat state when the runtime is offline, paused, permissioned, underfunded, or not yet configured.

Privacy and Interaction Settings

XEL profile visibility is a product setting layered over the public protocol records. It controls how the XEL.xyz product exposes a Living Character page and chat entry point; it does not replace on-chain ownership, Seal access policy, or encrypted artifact permissions.

Profile visibility modes:

• private: not publicly reachable; visible only to owner/admin-authorized sessions.
• unlisted: reachable by direct URL but excluded from public discovery/search/index pages. This is the product mode people often call “public link.”
• public_discoverable: reachable by direct URL and eligible for XEL discovery, search, feeds, lists, and public metadata files.
• password_protected: profile or chat requires one of the configured scoped passwords before access. Public preview behavior is configurable.

Interaction settings:

• free: users can chat without paying, subject to rate limits and runtime availability.
• paid: users must pay before interaction.
• password_required: users must enter a valid scoped password before interaction.
• paid_or_password: users can access through either payment or a valid scoped password.
• owner_only: only owner-authorized sessions can interact.
• disabled: chat is unavailable even if the profile is visible.

Paid interactions should support:

• base provider/runtime cost
• owner-set price per interaction, per message, or per session
• owner markup percentage above estimated runtime cost
• free allowance or trial messages when configured
• revenue destination, usually the character treasury wallet
• refund/failure behavior when the runtime cannot answer

Password gates should support multiple scoped passwords. Each password can have its own label, expiry, max uses, allowed interaction mode, and memory-access tier. A password gates product interaction and memory surfacing; it must not grant decryption authority over encrypted persona or memory artifacts.

Fund Your Icon

Every published XEL object should expose public deposit wallets so people can fund the XEL object and keep it running. The default profile should show these near the bottom of the page, below the chat/profile experience, under the heading “Fund this XEL.”

Funding is not a creation gate in the first product version. It is a runtime gate: the XEL object can be created, minted, published, and configured while unfunded, but inference/chat remains disabled until funding is received.

Default XEL funding wallets:

• storage renewal wallet: funds Walrus storage renewal and media/prompt/memory retention
• inference/runtime wallet: funds decentralized inference and runtime provider costs
• treasury/endowment wallet: funds the XEL object’s long-term treasury

These are public receive/deposit endpoints. Displaying them does not grant spend authority. Spend authority remains controlled by the owner, treasury policy, delegate policy, and contracts.

Every XEL object should have its own dedicated funding wallet set. These are not shared XEL deposit addresses. Public payment metadata and 402/x402 responses should point to the dedicated wallet for the XEL object being funded.

The public page should also show a funding/runway summary:

• current reconciled balance, estimated in USD or the configured display unit
• minimum funding required to activate chat
• estimated daily burn for storage renewal, hosting/runtime, and baseline inference availability
• countdown language such as “This XEL will expire in 12 days, 4 hours”
• locked-state language such as “Chat is disabled until this XEL is funded”

The countdown is an estimate. In the first implementation, it can be computed from the latest wallet ledger or chain balance snapshot and the configured daily burn estimate. Later, it should reconcile against provider receipts, storage renewal obligations, and treasury policy.

Settings Link

The public profile should include a visible settings/customization link for authorized owners or admins. That settings surface should control:

• profile visibility: private, unlisted, public discoverable, password protected
• interaction mode and pricing
• markup percentage and revenue destination
• password gates and memory-access tier
• profile bio, links, media selection, and public preview behavior
• funding wallet display, activation threshold, runway estimate, and treasury policy references

The settings page is product/application UX. Any protocol-impacting changes still need the appropriate owner/delegate wallet authority.

Proof and Details Page

The profile should keep consumer presentation separate from protocol inspection. Proof and protocol details belong on a secondary page or tab linked from the profile.

The proof/details surface should include:

• Proof of Genesis record
• aNFT object identifier and chain references
• mint or publication transaction references
• public persona artifact metadata, including whether it is direct, encrypted, classified, or provider-produced
• public asset hashes and storage references
• lineage references
• owner, delegate, and treasury wallet bindings that are public by contract or policy
• spend policy, pause state, migration state, and runtime availability
• profile visibility and interaction settings when public by owner policy
• discovery metadata and provider capability references

This page should be useful to wallets, indexers, auditors, and protocol developers without overloading the profile page with implementation detail.

Wallet Sign-In Scope

XEL.xyz supports email login and wallet-based sign-in for user accounts. Email login controls the XEL account and product session. Wallet signatures are still required for minting, ownership, delegate, treasury, payment, migration, and other protocol-authority actions.

Email login immediate scope:

• A user can request a sign-in email with both a magic link and a copyable one-time code.
• Magic link and one-time code challenges expire after a short server-configured TTL.
• Resend is available after a cooldown and replaces the earlier unconsumed challenge.
• Login tokens and one-time codes are stored only as keyed hashes and are single-use.
• Rate limits apply by normalized email and request source before delivery.
• Delivery uses SendGrid or an equivalent mail transport behind the XEL service boundary.
• Error states distinguish invalid email, resend cooldown, expired challenge, already-used challenge, replaced challenge, invalid code/link, delivery failure, and rate limiting.
• Email login may create or resume a UserAccount, but it does not create or imply a CharacterOwnerWallet, CharacterDelegateWallet, or CharacterTreasuryWallet.

Recommended email login service contract:

• requestLogin(email, requestContext): validates and normalizes email, applies rate limits, creates a magic-link token and numeric one-time code, stores keyed hashes, and sends one email.
• resendLogin(requestId, requestContext): enforces cooldown, marks the old challenge as replaced, creates a fresh challenge, and sends a new email.
• verifyMagicLink(requestId, token): verifies the keyed hash, expiry, and single-use state before creating an account session.
• verifyOneTimeCode(requestId, code): verifies the keyed hash, expiry, and single-use state before creating an account session.
• createSendGridTransport(...): sends a message containing the link, copyable code, expiry, and wallet-authority boundary language.

Production storage should be durable and auditable: account row, email credential row, login challenge row, resend/rate-limit counters, and session row. The open reference runtime includes a dependency-free in-memory store for local tests and integration shape only.

Immediate scope:

• Sui wallet signature login is the default path.
• Phantom support is in scope immediately, including Phantom’s Sui support where available.
• A user account can be created from the first successful supported wallet signature.
• A user account can link additional supported login wallets over time.

Deferred scope:

• Solana wallet login is deferred as a future linked-wallet option.
• Base/EVM wallet login is deferred as a future linked-wallet option.
• Cross-chain account recovery, cross-chain ownership transfer, and multi-chain treasury policy are deferred until the linked-wallet model is explicitly specified.

Phantom support in the immediate scope does not make Solana the default home chain for the protocol. Sui remains the default sign-in and Living Character home-chain path unless a later protocol version or owner policy changes that.

Account and Wallet Model

An XEL user account represents a human or organization using XEL.xyz. A wallet is a credential, authority source, or payment endpoint attached to that account or to a Living Character.

Recommended account model:

• UserAccount: XEL product account used for sessions, profile management, publication workflows, chat access, and linked-wallet management.
• LoginWallet: wallet address and chain used to authenticate a UserAccount.
• PrimaryLoginWallet: default wallet shown for account login and account recovery UX.
• LinkedWallet: additional wallet associated with the same UserAccount.
• CharacterOwnerWallet: on-chain wallet that owns or controls the Living Character aNFT.
• CharacterDelegateWallet: wallet authorized to perform limited character operations.
• CharacterTreasuryWallet: wallet or treasury endpoint used for funds, payments, spend policy, or revenue routing.

One user account may link many login wallets. One wallet may authenticate only the account linkage authorized by its signature and product policy. Linking a wallet to a user account does not automatically grant authority over any Living Character.

Separation of Login and Character Authority

XEL must keep the user login wallet separate from character authority wallets.

User login wallet:

• authenticates a person or organization into XEL.xyz
• creates and resumes product sessions
• manages account settings and linked wallets
• may initiate publication workflows if the user is authorized
• may be different from the owner wallet on any Living Character

Character owner wallet:

• owns or controls the Living Character aNFT according to Sui contracts
• authorizes ownership transfer, migration, pause, recovery, and contract-level policy changes
• may be held by the creator, a custodian, a DAO, a multisig, or another policy-controlled entity

Character delegate wallet:

• receives scoped authority from the owner wallet
• may update runtime/provider bindings, assets, memory roots, or other allowed settings depending on contract policy
• must not imply ownership unless the contract explicitly grants ownership rights

Character treasury wallet:

• receives, holds, routes, or spends funds under the character’s configured policy
• may be different from both the login wallet and owner wallet
• should be constrained by spend policy and public protocol state where applicable

The same address may occupy more than one role only when explicitly configured and signed through the required authority path. Product UX should show these as separate roles even when the address is identical.

Publication and Management Implications

Publishing a Living Character from XEL.xyz or from GEN should require the product account to prove it controls, or is otherwise authorized by, the wallet role needed for the requested operation.

Examples:

• A user can sign in with a Sui wallet and publish a new character whose owner wallet is that same address.
• A user can sign in with one supported wallet and configure a different Sui owner wallet if the owner wallet separately signs the required transaction.
• A GEN-managed flow can prepare publication data, but the XEL protocol state must be authorized by the relevant owner, delegate, or treasury wallet role.
• A chat user can sign in with Phantom for product access without gaining any ownership or delegate authority over the character.

Product sessions, account preferences, and linked-wallet records are XEL.xyz application state. Ownership, delegation, treasury policy, lineage, pause, and migration are protocol or contract state.

Non-Goals

• Do not require GEN persona synthesis to use the XEL.xyz product shell.
• Do not expose private prompts, private source evidence, or classified persona artifacts in the public profile.
• Do not treat Phantom support as a requirement to support Solana ownership or Solana-native Living Character contracts in the immediate scope.
• Do not implement Solana or Base/EVM wallet login in the immediate auth requirement.
• Do not collapse user account identity, login wallets, owner wallets, delegate wallets, and treasury wallets into one field.
• Do not make frontend implementation decisions in this document.

Acceptance Criteria

• XEL.xyz has a defined public destination model for each published Living Character.
• The primary profile page supports an Instagram-like character identity and media grid.
• The primary profile page includes a profile bio and public profile links.
• The primary profile page includes a clear chat CTA.
• The primary profile page includes a settings/customization link.
• The profile page shows funding wallets for storage renewal, inference/runtime, and treasury.
• The profile settings support private, unlisted/public-link, public-discoverable, and password-protected visibility.
• Interaction settings support free chat, paid chat, password-gated chat, paid-or-password access, owner-only access, and disabled chat.
• Paid interaction settings support owner markup percentage and revenue destination.
• Protocol proof, ownership, lineage, runtime, and wallet-role details live on a secondary proof/details surface.
• Sui wallet signature login is the default auth path.
• Phantom support is included in the immediate wallet-auth scope.
• Solana and Base/EVM login are documented as future linked-wallet work.
• The account model supports multiple linked login wallets per XEL user account.
• Login wallets are explicitly separate from Living Character owner, delegate, and treasury wallets.