XENIA

xenia.studio

18+ verified / adult fantasy / community

Documentation

How xenia.studio works: the privacy filter, age verification, the passkey wallet, tips and unlocks, the desktop app, and the one on-chain program that moves every payment. No custodian, no escrow.

Browse by area

Overview#

xenia.studio is a fantasy adult social network. Verified adults (18+) post real content that has been transformed by the proprietary XENIA augmentation / fantasy filter before it ever leaves their machine. The filter runs inside the XENIA desktop app on Windows, macOS, and Linux; the website never receives an unfiltered original. The result: you are seen, but not identified.

Money is just as direct. Every tip and every unlock is a wallet to wallet transaction on Solana mainnet through a single on-chain program that pays 93% to the creator and 7% to the platform in the same atomic instruction. The platform never holds funds, never issues balances, and never custodies a key.

SolanaSettled on-chainUSDT + SOLTip in either

Why XENIA exists

XENIA gives ordinary people the upside of the lifestyle with none of the usual cost. The freedom, the play, the community, and the thrill of being wanted, without the exposure, the awkward run-ins, or a real face attached to it all forever.

For couples it is a safer way to explore your sexuality together and with others. You decide exactly what you share, who can see it, and what it costs, and because the fantasy filter runs before anything leaves your machine, your likeness is felt but never identifiable.

It runs on genuine connection, not just content. A tip is a way to share your appreciation and your love with a creator, and a DM unlock opens a private line to them on their own terms: the kind of connection that can go beyond friendship.

That is the whole thesis: you can publish your most passionate moments and wake up the next morning with excitement instead of regret.

How XENIA works

  1. Sign up with a username and email, verify the email with a 6-digit code, pass 18+ age verification, and create a non-custodial Solana wallet in the browser. Your profile lives at username.xenia.studio.
  2. Pair the desktop app with a one-time pairing code from the dashboard. The app runs the conversion pipeline locally and uploads only the filtered output over a signed device API.
  3. Publish from the dashboard. Every upload lands as private. Flip each image to public (visible to everyone) or protected (shown as an irreversible blur until unlocked for a price you set).
  4. Viewers browse the global ranked feed and creator subdomains. Logged-in verified users follow creators, tip any image, unlock protected images, and unlock a creator's private DM handles.
  5. Every payment settles on chain. The browser builds and signs the transaction; the server only verifies what already happened on chain and records the entitlement.

Where to start

Core principles

  1. The filter is the identity boundary. Unfiltered originals never leave your machine. The platform stores, serves, and ranks only the transformed output.
  2. Non-custodial money. Funds live in your own wallet. Tips and unlocks pay creators directly; the commission split happens inside one on-chain instruction, not in a database.
  3. Encrypted storage. Every stored image is encrypted at rest with AES-256-GCM envelope encryption. Protected and private content is unreadable in database dumps or backups.
  4. Verified adults only. Both email verification and 18+ age verification are required before an account can post, follow, tip, or unlock.

Platform at a glance

PropertyValue
ChainSolana mainnet-beta
CurrenciesSOL and USDT (SPL, 6 decimals). Nothing else.
Creator share93% of every tip and unlock
Platform commission7%, enforced on chain with a 700 bps hard cap
WalletNon-custodial, passkey-wrapped, created in the browser
Content storageAES-256-GCM encrypted blobs in PostgreSQL
Profilesusername.xenia.studio subdomains
Age verificationGovernment ID via Yoti (ID scan or the Yoti app), creators only
Desktop appRust, Windows / macOS / Linux, paired per device

Getting Started#

Creating an account takes a few minutes and happens entirely in the browser. There are no passwords anywhere on XENIA: your non-custodial Solana wallet is your identity, and a passkey on your device is the local unlock gate for it.

The signup wizard

  1. Username and email. Pick a unique username (it becomes your username.xenia.studio subdomain) and enter an email address. The email is required for activation and is never shown publicly.
  2. Email code. A 6-digit code is sent to your address. Codes expire after 24 hours, allow 5 attempts, and resends are rate limited.
  3. Identity verification. Verify with a government ID through Yoti (an ID document scan with a live face match, or the Yoti app), which proves both that you are over 18 and that the person is you. See Age Verification for exactly how it works and what is stored.
  4. Wallet creation. The browser generates a Solana keypair, wraps it with a passkey, and shows you a 24-word recovery phrase exactly once. The wallet is created by XENIA; external wallets cannot be imported, and your account is permanently bound to this one address. See Wallet for the full mechanics.
  5. Verified face reference. The live face from your ID verification becomes your reference. It is stored encrypted and never shown publicly: a private identity anchor that ties the account to one real verified adult, that the desktop app uses to confirm your likeness in uploads, and that backs enforcement if the account is ever abused.

Activation

Email verification and 18+ age verification both happen inside the wizard, before the account record is created, so a normal signup produces an account that is already activated at birth. Activation simply means both the email and the age check have passed; an activated account can post, publish, follow, tip, unlock, set DM handles, and pair a device. If an account ever lacks one of the two (for example an email later marked unverified), the dashboard shows an activation checklist and those actions stay blocked until it is complete. Browsing the public site requires no account at all, only the 18+ self-attestation gate shown on first visit.

Logging in

Login is a wallet signature, not a password. The server issues a single-use challenge, your passkey unlocks the wallet key for a moment, and the key signs a canonical string:

Text
xenia-login-v1:{walletPubkeyBase58}:{nonceBase64url}

The server verifies the Ed25519 signature, burns the challenge, and sets a session cookie (30 days, httpOnly, shared across your subdomain). Secrets are zeroed from memory after every signature.

Optional two-factor authentication

Any account can add a second factor under Dashboard > Profile > Security. Two methods exist and you can enroll either or both:

  • Authenticator app (TOTP). Scan a QR code, confirm one 6-digit code, and you are enrolled. Ten single-use recovery codes are generated at enrollment and shown once.
  • Passkey. A server-side WebAuthn credential, independent of the passkey that wraps your wallet. You can enroll several, name them, and revoke them individually.

With 2FA enabled, login becomes two steps: the wallet signature first, then the TOTP code, a passkey assertion, or a recovery code. Enrolling or removing a factor always requires a fresh wallet signature.

Your subdomain

Every account gets username.xenia.studio. It serves your public profile: avatar, bio, follow button, the DM unlock card, and your image grid with tip and unlock actions. A set of system and safety names (for example www, app, api, admin, docs, dashboard, login, xenia, support, and abuse) is reserved and cannot be registered.

Next steps

  • Download and pair the desktop app: XENIA Studio.
  • Learn the wallet, send / receive, and (optionally) funding it to spend: Wallet. Earning needs no funding.
  • Start publishing and earning: Creator Guide.

Age Verification#

XENIA is an adults-only platform. Creating an account is a hard requirement before you can post, publish, follow, tip, or unlock, and it requires full government ID verification through Yoti, the same vendor set major adult platforms rely on. ID verification establishes two things at once: that you are a real adult over 18, and that the person is really you. Browsing public content needs no account and no verification.

The two ID routes

MethodBacking serviceFlow
ID document scanYoti Identity Verification (IDV)The browser loads Yoti's hosted iframe; you photograph a government ID and take a live selfie that Yoti matches to it; the result arrives as APPROVED or REJECTED
Yoti appYoti Digital IDAlready verified with Yoti? Scan a QR code and share your ID and over-18 status from the app; the share receipt is verified server-side

What is stored, and what is not

  • Stored: the verification receipt (the provider session id and a redacted result), the method used, a verified at timestamp, the verified face reference (encrypted, see below), and a one-way identity hash derived from the document (so each verified person gets one account and a banned account cannot re-register). The verification is also bound to the wallet that started it.
  • Never stored on XENIA servers: raw ID document images, the document number, and the documents themselves. They stay with Yoti under Yoti's retention policy; XENIA keeps only the one-way hash, not the underlying number or name.
  • Never shown publicly: your legal name, address, ID, or face. They are used for verification and records only, never for your profile, ranking, or advertising.

The verified face reference

The face reference is sourced from your ID verification itself: the live face Yoti matched to your government ID. Your paired desktop app downloads it over the signed device API and stores it immutably, then uses it to confirm that the source photos you transform actually contain you before the filter runs, and to mark each render accordingly. The reference is stored as an encrypted blob, is never served publicly, and is never used for ranking, advertising, or anything else. You cannot swap it: the app re-materializes it from a tamper-resistant store on every render.

Verification states

Each attempt is tracked from start to decision. If a method is temporarily unavailable (for example, the provider is not reachable), the UI says so and the other routes remain available. A failed attempt never locks the account; you can retry or switch methods at any time. Once passed, verification does not expire.

Privacy & the Filter#

XENIA's promise is simple: be seen, not identified. Every piece of content on the platform is real, and none of it shows the creator's actual appearance. The proprietary augmentation / fantasy filter transforms each image before it leaves the creator's machine, and the platform is built so that nothing identifying ever reaches it.

The filter boundary

The conversion pipeline runs inside the XENIA desktop app, locally, on your own hardware. The website has no upload path for unfiltered originals: the only way content enters the platform is through the signed device API, and what the app uploads is the filtered output, tied to one verified account. The platform never sees your real face in published content.

Visibility states

Every upload lands as private. From the dashboard you decide, per image, what the world sees:

StateWho sees what
privateOnly you, in your dashboard. Nothing is served to anyone else.
publicEveryone. Appears on your profile and in the Browse feed.
protectedEveryone sees a heavy blur plus your unlock price. The full image is served only to you and to viewers who have paid to unlock it.

Visibility, price, and caption can be changed at any time, and deleting an image hard-deletes its stored blobs.

What viewers actually receive

The server derives fixed variants from each upload and serves them according to the access decision:

VariantDerivationServed to
originalAs uploaded (post-filter output)Owner; everyone if public; unlockers if protected
displayLongest edge 1600pxSame policy as original (the lightbox view)
thumb512px thumbnailEveryone if public; owner only if private
blur24px downsample, gaussian blur, upscaled to 800pxEveryone, for protected images (the grid and lightbox teaser)

Why the blur is irreversible

The protected preview is not a blurred copy of the full image. It is generated by first resizing the image down to 24 pixels wide, applying a heavy gaussian blur, and then upscaling the result. The downsample destroys identifying detail before the preview ever exists; there is no sharpening, AI upscaling, or deblurring technique that can recover what was discarded. Serving the blur leaks nothing recoverable.

Encrypted at rest

Every stored variant, including private images and face references, is encrypted with AES-256-GCM envelope encryption before it touches the database. Decryption happens only inside the image-serving route after an access-control decision. The full scheme is documented in Security & Encryption.

Wallet#

Your XENIA wallet is a real, non-custodial Solana wallet created in the browser at signup. There are no browser extensions to install and no third-party wallet apps to connect: the keypair lives on your device, wrapped by a passkey, and the server only ever learns the public key. A total database compromise yields zero spendable funds.

How the wallet is created

  1. At signup the browser draws a random 32-byte seed and derives the Solana keypair from it.
  2. The seed is encrypted with AES-GCM under a wrapping key derived from the WebAuthn PRF extension, which binds the wrapping key to your device's hardware authenticator. Browsers without PRF fall back to an HKDF derivation from the passkey credential id.
  3. The encrypted blob is stored in the browser's IndexedDB. Every signature requires a passkey unlock; key material is zeroed from memory after each use.
  4. A 24-word recovery phrase (BIP39) is shown exactly once. It is the portable form of the same wallet: entering it on a new device re-creates the encrypted blob there.

The server never sees the seed, the phrase, or the private key, at signup or at any later point. The only thing XENIA stores is your public wallet address, which is public information and gives XENIA no ability to spend; it is what links your earnings to your account and powers your wallet view.

Supported assets

AssetDetails
SOLNative Solana, used for payments and transaction fees
USDTSPL token, 6 decimals, mint Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB

Any other token sent to the address is ignored everywhere in the product. All prices on XENIA display in both currencies: $X USDT (≈ Y SOL), using a server-side price quote cached for 60 seconds.

Buy SOL or USDT

You can fund your wallet with a card or bank from inside XENIA, with no separate exchange account. Open Dashboard › Wallet › Buy, pick SOL or USDT, and choose a provider (MoonPay or Transak). The provider opens prefilled with your wallet address and the asset you picked, so the crypto lands straight in your XENIA wallet the moment the purchase clears. Payment methods include card and Apple or Google Pay, plus bank transfer where the provider supports it. The on-ramp provider runs its own identity check and is the party you buy from; XENIA never touches the funds.

Deposit by QR code or address

Already hold crypto somewhere else? Send it in. Open Dashboard › Wallet › Deposit and your address is shown two ways:

  1. Scan the QR code. In your other wallet or exchange, choose send and scan the QR on screen to fill in your XENIA address automatically. No typing, no paste error.
  2. Copy the address. Tap Copy address and paste it as the destination in the sending app.

Send SOL or USDT on the Solana network only. There is no minimum and no platform processing step; the funds are yours the moment the transaction lands, usually within seconds. Tokens other than SOL and USDT, or transfers on a different network, are not supported and could be lost.

Send

The wallet sends SOL and USDT to any Solana address. Each send is built in the browser, confirmed with a passkey unlock, signed locally, and submitted straight to the chain. Withdrawal is just a send to wherever you want the funds.

No fee, ever, on your own money. XENIA takes nothing on a deposit, a send, or a withdrawal. The 7% platform share applies only to tips, image unlocks, and DM reveals (see Tips & Unlocks); moving your own funds in or out costs only the tiny Solana network fee, so you keep 100%. A full withdrawal drains the balance to zero, including reclaiming the small rent on a USDT token account, leaving no dust behind.

History and CSV export

The Activity view reads the complete on-chain history of your address and classifies every transaction into a labelled row: deposits and sends (received / sent), and the XENIA money events it can attribute, payments you made (a tip you sent, a post or DM you unlocked) and earnings you received (a tip or unlock from a buyer). Each row shows the token and amount moved, the USD value and counterparty where XENIA knows them, and a link to the transaction on the Solana explorer. The classification is built by merging the raw chain transactions with your platform money events from /api/me/activity. The list paginates and exports to CSV for bookkeeping. Your earnings are also collected on their own under Dashboard > Earnings with full payer context.

Restoring on a new device

On a new device, choose restore at login and enter the 24-word phrase. The wallet is re-derived, wrapped under a fresh passkey on that device, and stored in its IndexedDB. The phrase itself is never transmitted.

Tips & Unlocks#

Two payment actions exist on XENIA: tips and unlocks. Both are plain Solana transactions, built in your browser, signed by your passkey wallet, and routed through the single on-chain program (xenia-pay) that pays 93% to the creator and 7% to the platform atomically. There is no balance to top up and no payout to wait for; the creator's wallet is paid in the same instruction you sign.

The 7% is the only fee XENIA ever takes, and it applies only to these earning actions: tips, image unlocks, and DM reveals, in both SOL and USDT. It is enforced on chain and capped at 7% in the program itself. Moving your own money, depositing to your wallet or sending and withdrawing out of it, is never split: those transfers pay only the tiny Solana network fee, so you keep 100% of what is yours. See the Wallet for the send and withdraw flow.

Tips

  • Free amount, in SOL or USDT, on any public or protected image, or to a creator directly.
  • Tips are the primary ranking signal on the Browse feed: every dollar tipped moves the image up. See Ranking.
  • Tips accumulate on the image and on the creator's earnings view with the tipper's context.

Unlocks

  • Image unlocks buy permanent access to a protected image at the price the creator set (in USDT). Until unlocked, you see only the irreversible blur preview.
  • DM unlocks buy permanent access to a creator's private contact handles. See DM Reveals.
  • Entitlements never expire and survive price changes; once unlocked, always unlocked.

How a payment settles

  1. The browser builds a transaction invoking the xenia-pay program with the creator's wallet, the amount, and a 32-byte ref_id that binds the payment to this exact intent.
  2. Your passkey unlocks the wallet key for one signature and the transaction is sent to the chain. The program transfers 93% to the creator and 7% to the platform wallet in the same instruction.
  3. The client then calls POST /api/pay/confirm with the transaction signature.
  4. The server fetches the transaction itself at finalized commitment (so no fork or reorg can ever drop a payment an entitlement was granted for), confirms it actually invoked xenia-pay, and decodes only the PaymentEvent the program emitted while it was the executing program, not any look-alike log line. It validates payer, creator, mint, amount, and ref_id, cross-checks on chain that the creator's balance really rose by the net amount, and enforces that each transaction signature is recorded at most once. The tip or unlock is recorded and the entitlement is live immediately.

The ref_id is the SHA-256 of a canonical intent string, so a confirmed transaction can match exactly one cart intent and can never be replayed into a different entitlement:

Text
xenia:tip:image:{id}:{userId}:{nonce}
xenia:unlock:image:{id}:{userId}

Paying in SOL vs USDT

  • USDT: you pay exactly the listed price (price × 10^6 base units). What you see is what is transferred.
  • SOL: the client converts the USDT price to lamports at the quoted rate. The server accepts the payment if the on-chain amount converts to at least 98% of the USDT price at confirmation time. The tolerance absorbs normal price drift between quote and confirmation, so honest payers are never rejected over basis-point moves, while stale-quote gaming does not work.

Prices everywhere display in both currencies, $X USDT (≈ Y SOL), and you choose the currency at payment time.

DM Reveals#

XENIA has no built-in chat. Instead, creators sell DM reveals: one on-chain payment unlocks the creator's private contact handles so the conversation happens wherever the creator actually wants it, on their terms, off the platform.

A DM unlock is how a viewer turns appreciation into a real conversation. Paired with tips, it lets you share your appreciation and your love with a creator, and it opens a private line that can become a connection well beyond friendship, always at the creator's discretion.

Supported services

ServiceWhat is revealed
TelegramThe creator's Telegram handle
DiscordThe creator's Discord username
KeybaseThe creator's Keybase handle
SMSA phone number for texting
EmailA contact email address

For creators

  • Configure any subset of the five services and one unlock price (in USDT) under Dashboard > Messages.
  • Handles are encrypted at rest with the same AES-256-GCM envelope used for images. They are decrypted only for you and for buyers who have paid.
  • You can change handles or the price at any time. Existing buyers keep access; the entitlement is to your DM reveal, not to a snapshot.

For buyers

  • Every creator profile with DM reveals configured shows an unlock card with the price.
  • One payment reveals all the services the creator has configured, permanently. There is no per-service pricing and no renewal.
  • After unlocking, the handles render on the creator's profile for your account, and your unlocked reveals are listed with the rest of your entitlements.

The payment path

A DM reveal is a normal xenia-pay payment: 93% to the creator, 7% to the platform, in one atomic instruction. The transaction's ref_id is the SHA-256 of the canonical intent string:

Text
xenia:unlock:dm:{creatorId}:{userId}

The server confirms the transaction on chain, records the unlock, and from then on serves the decrypted handles to your session.

Ranking#

The Browse feed is one global, ranked stream of every creator's public and protected images. Ranking is deliberately simple and fully mechanical: money and attention, nothing else. There is no paid placement, no boosting product, and no editorial curation.

The rank score

Every image carries a score computed from three counters:

Text
rank = tip_total_usd * 100 + hearts * 10 + views

One tipped dollar outweighs ten hearts, and one heart outweighs ten views, so the default ordering surfaces what people are actually willing to pay for, with hearts and then raw attention as the tiebreakers. The score is computed in-query at read time; there is no batch job and no hidden decay factor.

Sort tabs

TabOrdering
TopThe combined rank score (tips × 100 + hearts × 10 + views)
Most tippedLifetime tip total, in USD terms
Most heartedLifetime heart count
Most viewedDeduplicated view count
NewPublication time, newest first

How views are counted

  • A public image counts a view when its full or display variant is fetched.
  • A protected image counts a view when its blur preview is fetched, so locked content competes on attention too.
  • Views are deduplicated per image, per viewer, per day. Refreshing a page all afternoon counts once.
  • Private images are never served to anyone but the owner and accumulate nothing.

What this means for creators

  • Tips are the lever. A single generous tip from one fan moves an image further than thousands of passive views, and tip totals are written by confirmed on-chain transactions, not by anything editable.
  • Protected images rank alongside public ones. A compelling blur preview earns views, and every unlock and tip it attracts feeds the same score.
  • The feed has no memory of who you are, only of what each image has earned. New creators compete on exactly the same terms as established ones.

XENIA Studio#

XENIA Studio is the free desktop app that turns your own adult photos into clean, sexy anime. It is a true anime redraw of your hair, face, and body that keeps your likeness, the exact pose, and the moment as shot - then, if you want, brings it to life as a short looping clip. It runs on your machine: no login to create, nothing uploaded until you review it and choose to, and originals that never leave your computer.

It is one native binary per OS (Rust + Tauri) for Windows, macOS, and Linux, painted in the same Midnight Aurora look as the rest of XENIA. Here is the library where every session starts:

XENIA Studio: the library grid with photos selected and the convert flow running

Getting the app

Grab the installer for your OS from GitHub Releases - .AppImage / .deb (Linux), .msi / .exe (Windows), .dmg (macOS). On first launch a setup wizard does the heavy lifting:

  1. Detects your hardware - NVIDIA (CUDA), AMD, Intel, Apple Silicon, or plain CPU - and installs the matching PyTorch build.
  2. Downloads the models with a live progress bar (a few GB, one time).
  3. Points you at the one license-gated anime checkpoint on Civitai (WAI-NSFW-Illustrious, v17) with exact, copy-paste instructions.

After that the app checks the releases feed on launch and installs a new version in one click once you confirm. Once setup finishes, generating images needs no internet, no login, and no account - everything runs locally.

How you use it: the five tabs

A sidebar splits the window into two groups: Create (Run, Review, Animate) and Setup (Configure, XENIA). A session flows through them roughly in that order. Drag photos anywhere onto the window to begin - input/ even supports nested folders, so you can drop a whole night at once.

TabWhat it is for
ConfigureEvery choice as a friendly picker: themes, enhancements, effects, per-character looks. Leave it all blank and the AI stays realistic. Saves are comment-preserving, so your config.tomlstays readable.
RunLive per-image progress: the eight stage chips ① to ⑧, an accurate step %, a shimmer on the card that is rendering, and partial previews streamed straight from the diffusion latents as the picture forms.
ReviewKeep, Retry (fresh seed), or Discard each result. Press and hold any result to compare it against the original photo.
AnimateYour library of finished loops. Press Animate on any kept render (from Review) to turn it into a seamless ~5-second loop: the AI reads the image and writes the motion itself - zero config. Needs a GPU (see below).
XENIAPair with your xenia.studio account and upload your kept images and loops. Uploads land private; you publish from the web dashboard.

How it works: the redraw pipeline

XENIA Studio does not slap a filter on your photo. It runs a fresh anime redraw - replacing the photo’s pixels with new anime art - while a stack of guidance models holds your likeness, pose, and anatomy exactly in place. Every photo runs the full stack, and each enhancement stage is guarded: if one trips, it is skipped and the render still finishes. The safety checks are the deliberate exception: they can stop a render and are never skipped.

Your photo
Autocrop

Trims away letterbox bars and phone-UI edges so only your photo is left.

The AI director reads the scene

An uncensored vision model studies the real photo and writes down exactly what is happening, and where each hand sits. This is the smart part that stops mangled anatomy.

Casting - your settings applied

Your choices from the Configure tab (config.toml) are layered in. Leave them blank and the AI stays true to the photo.

Base redraw into anime

WAI-Illustrious SDXL repaints the picture as fresh anime art, held tight to your original by triple ControlNet (edges, depth, and pose).

Hand pass

Each hand is re-rendered large and clean so you never get melted fingers.

Face pass

The face is re-rendered crisp, keeping the same identity.

Hi-res + colormatch

A diffusion upscale pass sharpens everything, then the palette is pulled back toward your real photo.

Final upscale

ESRGAN ×4 super-resolution finishes it at roughly 2048px.

Finished anime render
Every photo runs the full stack. If any one stage trips, it is skipped and the render still finishes.

The pieces that make it look right rather than melted:

  • An AI director sees the real scene. A local, uncensored vision model studies the photo and writes precisely what is happening and where each hand sits - so the model renders the real situation instead of inventing mangled anatomy.
  • High-strength redraw, not paint-over. A timid filter just smears the photo. A strong redraw replaces it with real anime; triple ControlNet (edges for likeness, depth for volume, pose for limbs) then locks it back onto the original.
  • Dedicated hand and face passes. The two regions that always break get re-rendered large and clean.
  • Colormatch + ESRGAN give a faithful palette and a crisp HD finish.

Four styles ship in: anime (default, glossy cel + gradient), cel (flat, bold lineart), cgi (3D render look), and slight (subtle, maximum likeness). Sixteen themes can re-dress every subject - angel, demon, elf, fairy, dragon, succubus, bare, cyberpunk, elegant, shinobi, witch, renaissance, shinigami, vampire, beach, pornstar - or any look you type in your own words. By default nothing about a body is changed: only the anime transformation happens. You opt in to everything else.

Size stays real. Breast, genital, and hip or butt size always render at their true proportions, faithful to the source photo; you can shape fitness and build, but size tracks what is actually there. The AI director reads the real proportions from your photo, and an optional faithful pass (on by default) pulls real genital shape and proportions into the render. That authenticity is the point: it keeps the scene honest, and it is your own likeness being enjoyed.

Adding a partner (MMF / FFM): best effort

You can ask for a partner in the scene: MMF adds a man, FFM adds a woman. This is best effort, not a guarantee. It is only attempted when the photo is one woman and one man together; on a solo shot, an already-group scene, or two people of the same sex it is simply skipped. When it does apply, the AI director places the extra person only where the existing pose and composition leave room, and never forces a body where there is none. Because the redraw is a single pass rather than a separate inpaint, the added person sometimes still does not come through.

The provenance reflects only what actually landed: the MMF or FFM badge is set only when a person was really added, and an FFM render is re-checked against the finished image and the badge dropped if the second woman did not appear. So the badge is a record of the result, not the request.

The safety gate (always on)

Consensual adult content of any kind passes through untouched. The gate exists so the tool cannot be pointed at the things it must never make.

The provenance watermark

Every render carries a small set of provenance tags: a compact, honest record of how it was made (your verified face, whether the body was left natural or enhanced, any theme, a third person in the scene, and so on). The desktop app determines those tags and uploads them alongside the clean render. XENIA turns the tags into a credential stack in the corner whenever the content is shown, so it is the single place the badge is drawn and it reads identically everywhere. The badges read left to right and only the ones that apply are shown.

BadgeWhen it appearsWhat it means
XENIAAlwaysThe render was produced by XENIA Studio.
VerifiedWhen your verified face is present in the sourceThe face match confirmed your own verified likeness is in the photo. It attests to identity only, never to age or to anyone else in the frame.
Natural / EnhancedAlways one of the twoThe body credential. Natural means the body was rendered as the AI saw it, at its real size and build. Enhanced means a fitness change (a fitter or more toned build) was applied. Breast, genital, and hip or butt size can never be changed, so size is always authentic and only fitness flips this to Enhanced. One is always shown, so every image discloses its body state.
MMF / FFMWhen a partner was actually added to the sceneDiscloses a best-effort partner that was rendered in (MMF added a man, FFM a woman). Shown only when one really appeared; FFM is re-verified against the finished image.
ThemeWhen a costume or fantasy theme is appliedNames the active theme (for example Demon, Angel, Elegant), so a costume re-dress is never mistaken for the real scene.
CumWhen that effect was addedDiscloses an added effect that was not in the source.

Because Natural and Enhanced are scoped to the body alone, they sit cleanly alongside the other badges instead of contradicting them. A few examples: XENIA · Natural is a plain conversion; XENIA · Enhanced had a fitness change; XENIA · Natural · DEMON is a real body in a demon costume; and XENIA · Verified · Enhanced · MMF · DEMON is your verified face, a fitness change, a third person, and a demon theme. XENIA renders the stack from the stored tags: composited into the corner of a still image and drawn as a live overlay while an animation plays. Because the platform applies it on every view from the provenance it stored, the disclosure is consistent and is never left to the creator to add.

CPU vs GPU: what runs where

This is the single most important thing to understand about speed. Images can be generated on a normal CPU - you do not need a fancy graphics card to make art. Animation needs a GPU. Here is the whole story in one table:

TaskOn a supported GPUOn CPU only
Image redrawSeconds to a couple of minutes each Works, but slow - several minutes per image. Just let it run.
Animation (loops)A few minutes per ~5s clip Not practical - a clip would take days, so it is disabled on CPU.

On launch the app probes your hardware and picks the best device automatically, preferring a supported GPU and using the CPU when there is no supported card. It also sets the right precision and thread count for each backend:

HardwareUsed asNotes
NVIDIA (Win/Linux)CUDA, fp16The fast path; runs both images and animation locally.
Apple Silicon (Mac)MPS, fp32Accelerates image redraws.
AMD / IntelROCm or DirectML, fp16AMD uses ROCm on Linux and DirectML on Windows; Intel uses its XPU build. Older AMD cards (e.g. Polaris) fall back to CPU.
Anything elseCPU, fp32Uses all cores but two. Images only; slow but fully functional.

Animations & the cloud GPU: RunPod, step by step

Animation uses Wan 2.2, a video model that needs a 24 GB-class GPU. If you do not have one locally, XENIA Studio can run animation (and, if you like, image renders) on your own private cloud GPU through RunPod. “Private” is the whole point: it is your RunPod account, your endpoint, and your content never touches a shared service. It scales to zero when idle, so you only pay for the seconds it actually renders.

XENIA Studio
on your laptop
Your private RunPod endpoint
a 24GB GPU, billed to you
Scales to zero when idleSame models as localNothing shared

The app has a Cloud GPU panel with these exact steps and buttons that open each page for you. It takes a few minutes, once:

  1. Make a RunPod account and add a card. Sign up and enter billing under console / signup.
  2. Create a Serverless endpoint. In Serverless › New Endpoint, paste this exact Container Image and pick a 24 GB+ GPU (RTX 4090 / A5000 work well):
    Text
    ghcr.io/mbrassey/xenia-anim-worker:latest
  3. Copy your Endpoint ID, then make an API key. The endpoint page shows its ID (looks like a1b2c3d4e5f6); create a key under Settings › API Keys.
  4. Paste both into XENIA Studio - the Endpoint ID and the API key - and press Connect. The app checks the endpoint’s health and stores the credentials in your OS keychain. Done.

Recommended endpoint settings, so it is cheap and fast:

SettingValueWhy
GPU24 GB+ (RTX 4090 / A5000)Wan 2.2 fits; bigger is faster.
Idle timeout~5 secondsScales to zero - you pay only for active seconds.
Max workers1Private, single-user.
Network volumeNone neededThe worker image already contains every model, so there is nothing to cache. A little container disk (20 GB+) is plenty.

From your machine to the gallery

Here is the journey of a finished render - and it is identical for a still image and an animated loop:

Keep a render or loop in Studio
Press Upload to XENIA.
It lands in your account - PRIVATE
Everything arrives here first; only you can see it. Open Dashboard ▸ Content.
You choose, per item
Keep private

Nobody else ever sees it.

Make public

Free for everyone to view.

Protect with a price

Shows blurred; unlocks forever the moment a viewer pays.

Anything public or protected appears in two places
Your subdomain
your own page
The Browse gallery
everyone’s work, together

Both still images and loops upload the same way and behave the same way once they are on your page: a loop is just a content item that plays. When you protect an item with a price, viewers see only an irreversibly blurred teaser until they pay; the unlock is permanent and settles wallet-to-wallet on Solana (see Tips & Unlocks). Public items show full-quality on your page and flow into the shared Browse feed, where the whole community’s work is ranked together and sortable by views, tips, and hearts.


The command-line version (headless and batch)

The desktop app is a friendly front end over a command-line engine, and that engine ships in the box. If you would rather work in a terminal, or script the conversion over thousands of photos, you can run the exact same pipeline with no window at all. It runs from any directory, fully local, on CPU or GPU, and the always-on safety gate and the provenance tags are produced for every render just as in the app.

With no arguments it converts everything in input/ and writes the results to output/. Otherwise pass any files or folders to convert, plus options:

Shell
# the whole input/ folder -> output/
./anime.sh

# a single image
./anime.sh photo.jpg

# a folder, CGI look, custom output directory
./anime.sh /path/to/pics --style cgi --out /path/to/results

# compare a few strengths side by side, then pick
./anime.sh input/ --ladder

# one-shot demon theme, reproducible seed
./anime.sh night/ --theme demon --seed 42

Folders are processed recursively, and a re-run skips images that are already done unless you pass --force, so a big batch can be stopped and resumed freely. The options:

ArgumentWhat it does
path (one or more)Image files and/or folders to convert. Folders are walked recursively.
--out DIROutput directory (default output/).
--style anime | cel | cgi | slightThe base look (default anime).
--strength 0.4 to 0.95Redraw amount: higher is more anime, lower keeps more of the photo (default: the style preset).
--nudge -0.06 .. +0.06Shift the resolved strength a touch softer or more anime.
--theme NAMEA one-shot theme for this run: a preset name, your own words, or an empty string to force realistic (default: config.toml).
--tags "..."Manual tags; omit to auto-tag via the AI director.
--seed NFix the random seed for reproducible output.
--faceidTighter likeness via IP-Adapter FaceID.
--ladderRender several strengths side by side to compare, then pick.
--variantWrite a new file (stem~2.png, stem~3.png) instead of overwriting; retries keep every prior render.
--forceRe-render even if the output already exists.
--no-tagger, --no-facedetail, --no-handdetail, --no-hires, --no-colormatch, --no-upscale, --no-configSkip individual pipeline stages for speed or control.

Pairing a device (the technical bit)

The app never holds your wallet key and never sees a password. Instead it generates its own Ed25519 device keypair and binds it to your account through a short, one-time pairing ceremony:

  1. In Dashboard › Devices, choose Generate pairing code. The server issues a one-time code like 7XK2-M9PQ-4RTV, valid for 10 minutes and stored only as a hash.
  2. Enter the code in XENIA Studio’s XENIA tab.
  3. The app registers with its public key, a device name, and your platform. The code is burned atomically; it can never pair a second device. The response hands back your display name and profile avatar, so the app personalizes itself the moment pairing completes.
JSONPOST /api/app/pair
{
  "code": "7XK2-M9PQ-4RTV",
  "devicePubkey": "<base58 Ed25519 public key>",
  "deviceName": "Studio desktop",
  "platform": "linux"          // windows | macos | linux
}

// response (201)
{
  "deviceId": "…",
  "userId": "…",
  "username": "…",
  "displayName": "…",
  // the profile avatar inline, so the app shows it right after pairing
  // (null when none is set); base64 thumbnail bytes plus its mime type
  "avatar": { "mime": "image/webp", "dataBase64": "…" }
}

Request signing

Every request after pairing is individually signed with the device key and carries four headers. There are no bearer tokens and no cookies - nothing reusable to steal off the wire.

HeaderContent
x-xenia-deviceThe device id issued at pairing
x-xenia-tsUnix timestamp of the request
x-xenia-nonceRandom per-request nonce (16 to 64 hex chars)
x-xenia-sigbase58 Ed25519 signature over the base string below
Text
xenia-app-v2:{METHOD}:{target}:{deviceId}:{ts}:{nonce}:{sha256(body) hex}:{sha256(provenance) hex}

The server rejects, with no exceptions:

  • unknown or revoked devices,
  • clock drift greater than 300 seconds,
  • any replayed (device, nonce) pair within the drift window,
  • bad signatures, and
  • bodies whose hash does not match the signed hash.

What the app can do

EndpointPurpose
POST /api/app/pairExchange the one-time code for a device identity; the response also returns the display name and the profile avatar inline so the app can show them immediately
GET /api/app/meAccount snapshot (username, display name, content counts, and whether a face reference and avatar are set)
POST /api/app/uploadUpload a filtered image (raw bytes, sha256, optional caption)
POST /api/app/upload-animationUpload a loop: the MP4 plus its poster still, as one signed multipart body
GET /api/app/contentYour uploads with their visibility states and media kind
DELETE /api/app/content/{id}Delete an upload
GET /api/app/face-referenceThe account’s signup face reference (raw image bytes), for optional at-the-app’s-discretion identity use
GET /api/app/avatarThe account’s profile avatar (raw image bytes), for the app to show for personalization; 404 when none is set. This is the chosen profile picture, which can differ from the face reference.
GET /api/app/healthUnauthenticated liveness check

Every upload lands in your dashboard as private; nothing the app does can publish content. Image uploads are deduplicated by sha256 (re-uploading identical bytes returns the existing id), capped at 25 MB, and must be JPEG, PNG, or WebP. Animation uploads send the MP4 (capped at 64 MB) alongside the poster still it was rendered from, so the server builds the grid and blur-teaser previews without ever transcoding video. Every format is sniffed by magic bytes rather than trusted by extension.

Device management

Dashboard › Devices lists every paired device with its name, platform, and last activity, and revokes any of them with one click. Revocation is immediate: the next signed request from that device is rejected.

Creator Guide#

Everything a creator needs is the account you already made plus the desktop app. No application process, no payout forms, no minimums. This guide walks the path from a fresh account to money arriving in your wallet.

1. Activate and pair

Finish both verifications (Getting Started), then download the desktop app and pair it with a one-time code from Dashboard > Devices (XENIA Studio). Pairing requires an activated account.

2. Upload

Run your content through the app. It applies the filter locally and uploads the result, signed by your paired device key. Every upload appears in Dashboard > Content as private: visible to nobody but you until you decide otherwise.

3. Publish

  • Public images appear on your profile and in the Browse feed. They earn views and tips.
  • Protected images appear everywhere as an irreversible blur with your unlock price. They earn views, tips, and unlock revenue. A protected image requires a price above zero, in USDT.
  • Captions, prices, and visibility are editable at any time, and you can delete any image permanently.

4. Set up DM reveals

Under Dashboard > Messages, add any of Telegram, Discord, Keybase, SMS, or email, and set one reveal price. Handles are stored encrypted and revealed only to paying fans. Details in DM Reveals.

5. Share your page

Your profile lives at username.xenia.studio. It carries your avatar, bio, follow button, DM unlock card, and your grid. Link it anywhere; viewers need no account to look, only to pay or follow.

How the money works

  • 93% of every payment (tips, image unlocks, DM reveals) arrives in your wallet in the same on-chain instruction the fan signs. There is no payout schedule because there is no payout: the money never stops anywhere else.
  • Dashboard > Earnings lists every tip and unlock with its payer context. Dashboard > Wallet shows the complete on-chain history with CSV export.
  • Fans pay in SOL or USDT; your prices are set in USDT and displayed in both.
  • You never fund anything to start earning. A fresh wallet with a zero balance collects tips and unlocks from day one; depositing or buying crypto is only ever for spending.

Dashboard map

TabWhat it does
FollowingYour home feed: the creators and posts you follow
OverviewStats at a glance, activation checklist
ContentManage uploads: visibility, price, caption, delete
WalletBalances, deposit QR, send, full history, CSV
EarningsTips and unlocks with payer context
MessagesDM services and the reveal price
DevicesPair the app, revoke devices
ProfileDisplay name, bio, avatar, security, your subdomain

The Smart Contract#

All value transfer on XENIA flows through exactly one on-chain program: xenia-pay, an Anchor program on Solana mainnet. It does one thing: split a payment between a creator and the platform commission wallet, atomically, with checked math. It holds no funds, has no escrow, no balances, and no withdrawal path, because money only ever passes through it inside a single instruction.

State: the Config PDA

The program's entire state is one account, a PDA derived from the seed [b"config"]:

Rustxenia-pay Config
pub struct Config {
    pub authority: Pubkey,                 // governance key
    pub pending_authority: Option<Pubkey>, // two-step transfer target
    pub platform_wallet: Pubkey,           // commission destination
    pub fee_bps: u16,                      // 700 at initialize
    pub bump: u8,
}
  • authority can rotate the platform wallet and lower the fee. Authority itself moves only via a two-step propose / accept handshake, so a typo cannot brick governance.
  • fee_bps starts at 700 (7%) and is bounded by a compile-time MAX_FEE_BPS of 700. The fee can be lowered and raised back, but never above 700. The cap is not a parameter; it is in the bytecode.

Instructions

InstructionArgumentsBehavior
initializeplatform_walletCreates Config; authority = payer; fee_bps = 700
set_platform_walletnew_walletAuthority only
set_fee_bpsnew_fee_bpsAuthority only; requires new value ≤ 700
propose_authority / accept_authorityTwo-step governance rotation
pay_solamount, ref_idSplits native SOL: a System transfer of net from payer to creator, then (when the fee is non-zero) a second System transfer of fee from payer to platform
pay_splamount, ref_idSame split via transfer_checked CPIs from the payer's token account to the creator and platform ATAs

Payment math

Rust
fee = amount * fee_bps / 10_000   // u128 intermediate, checked, floor
net = amount - fee                 // creator receives net
  • The floor rounding means dust always favors the creator.
  • Amounts below 15 base units would floor the fee to 0; a hard MIN_PAYMENT of 1,000 base units (lamports or token units) keeps every split meaningful.
  • For both pay_sol and pay_spl the platform account passed in must equal config.platform_wallet; an identical platform.key() == config.platform_wallet constraint guards each path, so substituting any other account fails the instruction. On the SPL path the platform token account is then derived canonically from that constrained wallet.
  • For pay_spl both destination ATAs are derived canonically and created on the fly if missing (init_if_needed, payer funds the rent). The program works for any SPL mint; the platform itself only indexes USDT.

PaymentEvent

Every successful payment emits one event, decoded by the server:

RustPaymentEvent
pub struct PaymentEvent {
    pub payer: Pubkey,
    pub creator: Pubkey,
    pub mint: Pubkey,      // Pubkey::default() for SOL
    pub amount: u64,
    pub fee: u64,
    pub net: u64,
    pub ref_id: [u8; 32],
    pub kind: u8,
    pub timestamp: i64,
}

ref_id: binding a transaction to one intent

ref_id is the SHA-256 hash of a canonical platform reference string. It lets the server match a confirmed transaction to exactly one intent without a memo instruction, and makes replaying a transaction into a different entitlement impossible. The four intent formats:

Text
xenia:tip:image:{id}:{userId}:{nonce}
xenia:unlock:image:{id}:{userId}
xenia:unlock:dm:{creatorId}:{userId}
xenia:tip:user:{creatorId}:{userId}:{nonce}

Unlock intents carry no nonce, so the same buyer unlocking the same item always hashes to the same ref_id: one entitlement, idempotent. Tips carry a client nonce so repeated tipping produces distinct references.

Server-side confirmation

  1. The client submits the signed transaction, then calls POST /api/pay/confirm with the signature.
  2. The server fetches the parsed transaction itself (retrying up to ~30s for confirmation) and requires an instruction invoking the xenia-pay program id.
  3. It decodes PaymentEvent from the logs and validates: payer matches the session wallet (for unlocks), creator matches the expected wallet, mint is SOL or USDT, amount covers the price (with the SOL drift tolerance), ref_id equals the expected intent hash, and the signature has never been recorded before (unique index).
  4. Only then is the tip or unlock recorded, inside a database transaction. The server trusts nothing it did not re-read from the chain.

Safety properties

  • Overflow-checked release profile; no unsafe anywhere.
  • CPI surface limited to the System, Token, and Associated Token programs. Nothing else can be reached through xenia-pay.
  • The test suite (bankrun, no local test cluster required) covers initialize and re-init guarding, exact split math across boundary values, both SOL and SPL paths, ATA auto-creation, rejection of platform-account substitution, fee cap enforcement, authority gating with the two-step transfer, and event decoding.

Security & Encryption#

The threat model starts from one premise: customer content is the crown jewel. Everything below exists so that a database dump, a stolen backup, or raw filesystem access yields nothing readable, and so that a full server compromise yields zero spendable funds.

Envelope encryption for every blob

Every stored image variant, face reference, and DM handle is encrypted with AES-256-GCM envelope encryption before it reaches PostgreSQL:

  1. Each blob gets its own random 32-byte data encryption key (DEK) and 12-byte IV; the ciphertext is stored with the GCM tag appended.
  2. The DEK is wrapped (again AES-256-GCM) by the master key, which lives only in the environment, never in the database.
  3. The GCM additional authenticated data binds the blob id and kind, so a ciphertext cannot be detached and re-attached to a different row.
  4. Key rotation re-wraps DEKs under a new master key; the data itself never needs re-encryption.
What one blob row holds
FieldWhat it stores
ciphertextAES-256-GCM(image bytes, DEK, IV) + authentication tag
ivPer-blob initialization vector, 12 bytes
dek_wrappedAES-256-GCM(DEK, master key); the master key lives only in env
sha256Integrity digest of the plaintext

Decryption happens in exactly one place: inside the image-serving route, after the access-control decision. There are no direct object URLs and no static file paths to guess.

The blur is destruction, not decoration

Protected previews are generated from a 24-pixel downsample that is then blurred and upscaled. The identifying detail is discarded before the preview exists, which is why serving the blur publicly is safe: there is nothing left to recover, by any technique.

Nothing secret is stored in plaintext

SecretAt rest
Session tokensHMAC-SHA256 hash only
Pairing codesHash only, 10-minute TTL, single use
Email verification codesHash only, attempt-limited
Login challenge noncesHash only, 5-minute TTL, single use
2FA recovery codesHash only, burned on use
TOTP secretsEnvelope-encrypted like blobs
Wallet keysNever on the server in any form; only public keys are stored

Transport authentication

  • Logins are single-use Ed25519 signature challenges with a 5-minute TTL. No passwords exist to phish or to leak.
  • Desktop devices sign every request over the method, path, device id, timestamp, nonce, and body hash. Replays are caught by a nonce cache; clocks may drift at most 300 seconds. See XENIA Studio.
  • Sessions are httpOnly, SameSite cookies (Secure outside localhost) backed by hashed server-side records with sliding expiry. State-changing routes require a CSRF double-submit header plus Origin checking in middleware.
  • Rate limits apply per IP and per device on auth, upload, and payment-confirm routes, answering 429 with a retry-after.

Upload hardening

  • File types are sniffed by magic bytes (JPEG, PNG, WebP only); extensions are never trusted.
  • Pixel-bomb guards cap decoded dimensions; files cap at 25 MB.
  • A sha256 of the body is signed by the device and re-verified server-side; identical bytes deduplicate to the existing image.

Browser security headers

  • A strict Content-Security-Policy: default-src 'self', with connect-src opened only to the Solana RPC endpoint (HTTPS plus its WebSocket for transaction confirmation) and frame-src opened only to the Yoti age-verification widget. There are no third-party scripts, trackers, or analytics embeds anywhere.
  • frame-ancestors 'none' plus X-Frame-Options: DENY on every route, so no XENIA page can be embedded in a hostile frame. base-uri 'none' and object-src 'none' close the remaining injection sinks.
  • Referrer-Policy: strict-origin-when-cross-origin, X-Content-Type-Options: nosniff, and a Permissions-Policy that grants only the camera (to the site itself, for face capture) while denying microphone and geolocation, all across the board.

Payments

The server records a payment only after re-reading the confirmed transaction from the chain, decoding the program event, and matching the ref_id intent hash. Transaction signatures are unique keys, so the same transaction can never be credited twice, and one buyer's transaction can never be replayed into another account's entitlement. Details in The Smart Contract.

Content safety: zero tolerance

Independent of the augmentation pipeline, every upload passes a dedicated AI-driven screening for child sexual abuse material, animal abuse, and abusive or non-consensual content. This check is not a moderation queue and there is no discretionary review for clear detections: a hit results in an immediate permanent ban, deletion of the account's entire content library, and a report to the relevant authorities, including NCMEC and law enforcement, with the evidence preserved for that report. Identity signals collected at age verification make "new account, same person" a losing strategy.

FAQ#

Can anyone see my real face or body?

No. The augmentation / fantasy filter runs inside the desktop app on your own machine, and the platform has no upload path for unfiltered originals. What viewers see is the transformed output. Protected images add a second layer: the public preview is generated from a 24-pixel downsample, so even the blur contains nothing recoverable.

What content is forbidden?

Anything involving minors, animals, or abuse and non-consent. Every upload is screened by a dedicated AI check before it can publish, and the policy is zero tolerance: detection means an immediate permanent ban, deletion of everything the account ever uploaded, and a report to the authorities, including NCMEC and law enforcement. Everything between consenting, verified adults is welcome; this line is not.

Does XENIA hold my money?

Never. Your wallet is non-custodial and lives in your browser; the server stores only the public key. Tips and unlocks pay 93% to the creator and 7% to the platform inside one atomic on-chain instruction. There is no balance, no escrow, and no payout queue.

XENIA cannot withdraw, freeze, or move your funds in any way. Only your passkey can authorize a transaction, and the keys never leave your device. Even if an account is frozen or banned by moderation, that touches only published content; the wallet and its funds stay entirely in your custody and control at all times.

Which currencies are supported?

SOL and USDT (the SPL token, 6 decimals), on Solana mainnet. Any other token is ignored everywhere. Prices are set in USDT and displayed in both currencies; payers choose at payment time.

What does XENIA cost?

XENIA is completely free to use. Your account, your username.xenia.studio subdomain, posting, browsing, following, and every tool to earn cost nothing. The only fee is the 7% commission on tips, image unlocks, and DM reveals (in both SOL and USDT), taken through the XENIA wallet and enforced on chain with a hard 700 bps cap the program itself cannot exceed. Depositing, sending, or withdrawing your own funds is never split: those transfers pay only the Solana network fee, so you keep 100% of your own money and 93% of every tip and unlock. You also never have to fund your wallet to start earning: a zero-balance wallet collects tips and unlocks from day one, and buying or depositing crypto is only ever for spending.

I lost my device. Is my wallet gone?

No, if you have the 24-word recovery phrase from signup. Enter it on a new device and the wallet is restored under a fresh passkey. If you have lost every passkey device and the phrase, the wallet is unrecoverable; nobody else ever had the key, so nobody can restore it.

How is identity and age verified?

Creators verify with a government ID through Yoti, either an ID document scan with a live face match in Yoti's hosted flow, or an ID share from the Yoti app. This proves both that you are over 18 and that the person is you. Browsing needs no account or verification. See Age Verification for what is and is not stored.

What personal data does XENIA keep?

A username, an email (never shown publicly), a wallet public key, your verification receipts (provider session id and redacted result), and your content, encrypted. Raw ID documents are never stored on XENIA servers; they stay with the verification provider. The face reference photo is encrypted and only ever served to your own paired devices.

Can I delete my content or my account?

Yes. Deleting an image hard-deletes its encrypted blobs immediately. Account deletion cascades through everything you own. What cannot be deleted is on-chain history: transactions on Solana are public and permanent, but they contain only wallet addresses and amounts, never content or identity.

Why is an image blurry?

It is protected: the creator priced it. The price shows on the tile; unlocking pays the creator directly and the full image is served to your account permanently.

Do unlocks expire?

No. Image unlocks and DM reveals are permanent entitlements, recorded against confirmed on-chain transactions. Later price changes do not affect what you already unlocked.

Can I use Phantom or another wallet extension?

No. XENIA uses its own in-browser passkey wallet exclusively, because the wallet is also the account identity and the signing flow is built around per-use passkey unlocks. You can always move funds between the XENIA wallet and any external wallet with a normal send.

Is there a built-in chat?

No. Creators sell DM reveals: one payment reveals their handles on Telegram, Discord, Keybase, SMS, or email, and the conversation happens there.

Where is the desktop app API documented?

The complete wire contract, including the signature base string, a worked test vector, every endpoint, and a Rust client example, lives in INTEGRATION.md in the repository. The overview is in XENIA Studio.

Does XENIA support two-factor authentication?

Yes, optionally: an authenticator app (TOTP) and server-side passkeys, either or both. Ten single-use recovery codes are issued at TOTP enrollment. Managing factors always requires a fresh wallet signature.