INTRODUCING MOLT
One token.
A changing identity.
MOLT is a proposed Solana memecoin that evolves with internet culture instead of launching a new token for each meme.
No official token address or live voting service is published on this site. Connecting a wallet does not mean the token has launched.
The concept is simple: discover emerging trends, let holders choose the next identity, then change the coin’s public expression. Repeat on a hourly cycle while keeping the same underlying token.
01 / CONTINUITY
What changes. What stays.
An identity is a name, visual world and narrative attached to the same token. It is not a replacement asset.
The intended transformation does not require holders to swap or migrate. Changing branding does not itself create new liquidity or reset balances. Market price and liquidity can still change independently.
The metadata mechanism and update authorities have not been selected yet. Third-party wallets and exchanges may cache branding; synchronized updates across every platform are not guaranteed.
02 / TRANSFORMATION
A proposed one-hour rhythm.
- Discover. Collect signals from internet culture and emerging narratives. The sources and ranking method still need to be chosen.
- Review. Prepare a shortlist and proposed branding. Moderation and publishing controls must be defined before launch.
- Vote. Eligible holders choose from the published candidates during an open round.
- Finalize. The service validates the result and publishes the winning identity. A timer reaching zero does not itself prove that finalization succeeded.
- Remember. Preserve the previous identity and the completed round in a public archive.
AI-assisted discovery and branding generation are planned components, not active integrations. Emergency changes are also a proposal; authority, triggers and limits must be documented before they can be enabled.
03 / PARTICIPATION
Your wallet. Your decision.
The frontend uses Privy for sign-in by email or compatible Solana wallet. Privy manages the session and exposes connected wallets to MOLT. Connecting does not submit a token transfer.
The prepared voting flow requests a single-use challenge from the future backend. A wallet signs a readable message binding the vote to the site, network, token, round and candidate. A vote is shown as confirmed only after a valid server receipt.
The prepared integration uses server-verified message signatures. An on-chain voting program has not been built. Durable storage, signature checks and replay protection are implemented. Token-holder eligibility and the public voting policy are not configured.
When the feed is unavailable or stale, voting is disabled. If a submission times out, its outcome is unknown until the service confirms it; the interface does not invent a successful result.
The connection dialog is provided by Privy and styled for MOLT. The account menu lets you select a Solana wallet or sign out. A successful login does not prove token ownership or voting eligibility; token-holder checks must be implemented before public voting opens.
04 / MEMORY
Every identity leaves a trace.
The archive is intended to record published identities in chronological order. It is empty until the service supplies real history. Decorative sculpture shapes on the landing page are not previous token identities.
The backend stores published identities, vote receipts and an audit trail. The main feed includes up to 100 past identities; a separate history endpoint supports pagination.
05 / WHAT EXISTS TODAY
Built, prepared, still to come.
Frontend and documentation
Responsive landing page, interactive sculpture, wallet discovery, explicit empty states and archive interface.
Backend and private administration
Persistent database, signed-vote verification, replay protection, round scheduling, reviewed publication and history. The site is connected to the API. Voting can be rehearsed in an isolated database; public voting remains closed.
Token and operating services
Token creation, verified holder snapshots, public voting rules, trend collection, generated branding and automatic on-chain identity changes.
06 / BEFORE LAUNCH
The decisions still open.
- Who can vote, and when are holder balances measured?
- How much does each vote count? Can a vote be changed?
- What happens in a tie or when too few holders participate?
- Who reviews candidates and controls metadata updates?
- What happens if publication or a scheduled transformation fails?
- Can an emergency transformation bypass a normal round?
These are product and governance decisions. This documentation does not silently choose them on behalf of the community.
07 / INTEGRATION
A small, explicit API surface.
The frontend is static HTML, CSS and JavaScript with locally bundled rendering and wallet dependencies. Configuration is public; secrets belong only in a server environment.
GET /api/v1/stateCurrent identity, token, round, candidates, vote totals and history.
POST /api/v1/vote-challengesA short-lived challenge tied to one wallet and one intended vote.
POST /api/v1/votesA signed vote. The backend validates it and returns a durable receipt.
The server must enforce eligibility, deadlines, signature validation, replay protection and atomic writes. Client-side checks are interface safeguards, never a substitute for those controls.
Technical reference: Solana message signing documentation