Wallet-native access
A signed challenge can prove eligibility without creating another password or exposing a seed phrase.
Roadmap · development only
DevelopmentThis page describes product ideas under consideration. No token, mint, sale, or launch is presented on this site today.
This is a product roadmap, not financial advice or an investment offer.
Why this network
The question is whether wallet-based access can make Ophelia easier to use and sustain. If it cannot improve the product, it should not ship.
A signed challenge can prove eligibility without creating another password or exposing a seed phrase.
Small, auditable service-credit events may be practical without turning every chat message into an on-chain transaction.
A user could prove access across Telegram and web while each channel keeps the same private account boundary.
Possible utility
A token-gated access model may let holders chat with Ophelia. That is a product-access idea, not a promise of availability, ownership value, or a current way to participate.
Connect a wallet and sign a one-time challenge; Ophelia verifies eligibility and never asks for a seed phrase.
An approved holder enters a private Telegram or web session—not a shared memory pool. Each session needs its own identity, history, limits, and deletion controls.
Token-linked service credits become a measured usage allowance; model-provider credentials stay server-side and are never handed to a user or bot client.
Sustainable operation
Future usage could help cover the model and voice costs behind a responsive assistant.
Creator rewards and paid usage, if a future launch venue provides them, could help cover model, voice, hosting, and operations.
Any utility design must serve a real product experience before it earns a broader role.
Phased roadmap
Dates stay deliberately unset until the previous phase has evidence. “Planned” means design work, not a promise to launch.
Define access, cost accounting, wallet privacy, abuse limits, and a sustainable user experience.
Test wallet challenges, isolated identities, Telegram and web access, quotas, revocation, and deletion.
Review contracts, custody boundaries, disclosures, tax treatment, moderation, treasury controls, and incident response.
Proceed only if the utility is useful, costs are sustainable, controls pass review, and public terms are ready.
Security boundary
Ophelia would request a standard signed challenge only. She would never ask for recovery words or a private key.
The access service would verify public wallet state without taking control of user assets.
Wallet eligibility would not create a shared memory pool. Identity, history, deletion, and rate limits remain isolated per user.
Model, voice, and messaging credentials remain server-side behind quotas and abuse controls.
What remains open
The roadmap will stay explicit about these decisions rather than fill the gaps with a launch narrative.
Balance threshold, holding period, supported wallets, renewal checks, revocation, and whether access uses holding, spending, or another proof.
How service credits map to model cost, rate changes, daily caps, exhaustion, unused balances, refunds, and provider fallback.
How creator rewards and usage proceeds are recorded, separated, disclosed, and applied to operating costs.
Moderation, rate limits, abuse response, wallet privacy, tax treatment, jurisdiction, consumer disclosures, security review, and launch approval.
Straight answers
No. There is no token, public token identifier, presale, or public access sale presented by this site.
No. A legitimate access check needs only a wallet signature. Never provide recovery words or a private key.
No. Conversations and memories must remain private. The proposed chain role is eligibility and bounded accounting, not publishing chat history.
No access rule has been approved. Eligibility, usage limits, supported channels, pricing, and revocation remain development decisions.
No. Rewards depend on a future venue and activity. Any operating allocation would need transparent records and public disclosures.