This is the full developer documentation for SOLMAMY Docs # AI Tools Overview > This site's AI/agent-access layer: how agents should read, cite, and interact with SOLMEME's knowledge base — not AI in crypto generally. This section is this documentation site’s own AI/agent-access layer — how AI agents and the humans configuring them should read, cite, and interact with SOLMEME’s knowledge base. It’s not a page about AI in crypto generally, and not about SOLMEME-the-product’s own AI usage (the monthly trend-scan that picks each drop’s theme) — that belongs to [How SOLMEME Works](/docs/introduction/how-solmeme-works/). ## Who This Is For [Section titled “Who This Is For”](#who-this-is-for) AI agents and crawlers reading this site, and the people who configure that access — Discord/Telegram bot integrations, external agents, or anyone building a tool on top of this documentation. ## What’s Here [Section titled “What’s Here”](#whats-here) * **AI Tools** — the mechanisms an agent can use to access this site programmatically. * **[MCP](/docs/ai/mcp/)** — a planned access mechanism (Model Context Protocol server). Not live yet — described as an architectural direction, not a running service. * **[Agent Skills](/docs/ai/agent-skills/)** — explicitly out of scope for now, not a “coming soon” item. * **[Knowledge Policy](/docs/ai/knowledge-policy/)** — this site’s own real, effective-today rules for how an AI agent should treat what it reads here: what counts as canonical, how to handle uncertainty, what never to assume. This isn’t conditional on any external system — it applies now. * **[LLMs.txt](/docs/ai/llms-txt/)** — the one already-real machine-readable access mechanism: how `llms.txt` and per-page Markdown access work on this site. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) Reading this site’s content policy first — [Knowledge Policy](/docs/ai/knowledge-policy/) — matters more than the specific access mechanism, since it governs how any mechanism should be used once it exists. # Agent Skills > What Agent Skills are, and why SOLMEME hasn't adopted them. Agent Skills is a mechanism some AI platforms use to package reusable, declarative capabilities an agent can discover and invoke — a way to extend what an agent can do without custom integration code for each new capability. ## SOLMEME Hasn’t Adopted This [Section titled “SOLMEME Hasn’t Adopted This”](#solmeme-hasnt-adopted-this) This documentation site doesn’t expose an Agent Skills interface, and there’s no plan to build one for the current scope. This isn’t a “coming soon” placeholder — it’s a deliberate scope decision, explicitly excluded from SOLMEME’s AI-access MVP alongside a small set of other larger-ecosystem mechanisms (WebMCP, DNS-AID/discovery endpoints, OAuth). The reasoning is scale, not rejection of the idea: those mechanisms make sense for a platform serving many external developers integrating against a large API surface. SOLMEME’s AI-access layer serves a narrower, real need today — Discord and Telegram community agents that need to read this documentation reliably — which [Knowledge Policy](/docs/ai/knowledge-policy/) and [LLMs.txt](/docs/ai/llms-txt/) already cover without the added surface area Agent Skills would bring. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [AI Tools Overview](/docs/ai/) — the full picture of what this site’s AI-access layer actually includes today * [MCP](/docs/ai/mcp/) — the one access mechanism that is planned, though not live yet * [LLMs.txt](/docs/ai/llms-txt/) — the mechanism that’s real and live today # Knowledge Policy > This site's own real, effective-today rules for how an AI agent should treat what it reads here. Unlike [MCP](/docs/ai/mcp/), which is still planned, Knowledge Policy is real and effective **today** — it doesn’t depend on any access mechanism existing first. It’s this documentation site’s own stated rules for how an AI agent (or a person) should treat what it reads here: what to trust, how to judge whether something is current, how to cite it, and what to do when the answer isn’t actually here. ## The Five Areas [Section titled “The Five Areas”](#the-five-areas) * **[Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/)** — which pages are authoritative, and how this site marks the difference between real, published content and a page that isn’t written yet. * **[Freshness](/docs/ai/knowledge-policy/freshness/)** — how to tell whether a page’s information is current. * **[Citations](/docs/ai/knowledge-policy/citations/)** — how to reference this site’s content correctly. * **[Prohibited Assumptions](/docs/ai/knowledge-policy/prohibited-assumptions/)** — things never to assume about SOLMEME just because they’d be plausible. * **[Uncertainty](/docs/ai/knowledge-policy/uncertainty/)** — what to do when this site doesn’t have a confirmed answer. ## Where This Policy Comes From [Section titled “Where This Policy Comes From”](#where-this-policy-comes-from) This isn’t an aspirational policy written for AI agents in the abstract — it’s the same discipline this site’s own content is built under. Every real page on this site is produced through a documented authoring process that refuses to publish an invented fact, and every still-unwritten page is marked as such rather than silently filled with plausible-sounding text. The five pages in this section describe that same discipline from the reader’s side, for an agent instead of an author. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [AI Tools Overview](/docs/ai/) — how this fits into this site’s wider AI-access layer * [LLMs.txt](/docs/ai/llms-txt/) — the real, live mechanism this policy applies to today # Canonical Sources > How to tell which page on this site is the authoritative one for a given fact. This site is organized so that every fact has exactly one canonical home — not scattered restatements that can drift out of sync with each other. ## Two Signals, Both Real [Section titled “Two Signals, Both Real”](#two-signals-both-real) **Published vs. not yet written.** Every page on this site is either real, published content or an honest placeholder — this site never mixes the two silently. A page that isn’t written yet says so plainly (a visible status note), rather than presenting thin or generic text as if it were the real answer. If a page doesn’t carry that note, its content is real and can be cited; if it does, treat the topic as currently undocumented, not as “probably similar to what other memecoin projects do.” **Summary pages point to their canonical source, not the reverse.** Where the same fact appears in two places at different depths — a short orientation page and a full canonical explainer — the shorter page says so explicitly and links to the deeper one. [What is SOLMEME?](/docs/introduction/what-is-solmeme/), for example, states this directly: it’s the short version, and [Learning → Topics → SOLMEME](/docs/learning/topics/solmeme/) is “the canonical source for these facts.” When a summary and its source could be read as disagreeing, the canonical source wins. ## Practical Rule [Section titled “Practical Rule”](#practical-rule) If you need a specific fact (a date, a mechanic, a number), prefer the page whose whole purpose is to document that specific thing over a page that merely mentions it in passing while orienting to something else. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Freshness](/docs/ai/knowledge-policy/freshness/) — how to judge whether a canonical source is current * [Citations](/docs/ai/knowledge-policy/citations/) — how to reference what you found here # Citations > How to reference this site's content correctly, and how to tell a fact from an inference. ## Cite the Specific Page, Not the Site [Section titled “Cite the Specific Page, Not the Site”](#cite-the-specific-page-not-the-site) When referencing a SOLMEME fact, point to the specific page that states it — `/learning/topics/solmeme/` for the project’s history, `/guides/ vault/` for reward mechanics — rather than a general “according to SOLMEME’s documentation.” A specific citation lets whoever’s reading verify the claim themselves and catches the case where the page turns out to be a placeholder rather than real content. ## Separate Fact From Interpretation [Section titled “Separate Fact From Interpretation”](#separate-fact-from-interpretation) This site’s own pages already model the distinction worth carrying into any citation: a stated fact (“SOLMEME launched in December 2023, no pre-sale, no VC backing”) versus an inference built on top of it (“this makes SOLMEME more trustworthy than average”) are different kinds of claims. Cite the first as fact. Present the second as interpretation, not as something this site itself asserts. ## Don’t Cite a Stub as a Fact Source [Section titled “Don’t Cite a Stub as a Fact Source”](#dont-cite-a-stub-as-a-fact-source) If the page you’d cite carries a visible “not yet written” status note, it isn’t a source for the topic it covers — it’s evidence the topic isn’t documented yet. Say that plainly rather than citing the page’s title/description as if they were the answer. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/) — which page to cite when more than one touches the same topic * [Uncertainty](/docs/ai/knowledge-policy/uncertainty/) — what to say when no page actually answers the question # Freshness > How to judge whether a page's information is current. Static documentation and live data age differently on this site — this page covers how to tell which kind you’re looking at, and how current it actually is. ## Static Content [Section titled “Static Content”](#static-content) Most of this site — Learning, Guides, Tutorials, Introduction, Reference — documents things that don’t change moment to moment (how a mechanic works, what a term means, the project’s history). These pages are current unless SOLMEME’s actual mechanics change, at which point the page itself is updated — there’s no separate “last verified” system to check beyond the page’s own content matching what’s actually true today. ## Live/Point-in-Time Data [Section titled “Live/Point-in-Time Data”](#livepoint-in-time-data) Some pages explicitly document a mechanism whose *current numbers* change continuously — Vault reward tiers, Community Raids progress, contract launch status. These pages are written to describe the mechanism, not to freeze a snapshot of live numbers as permanent fact. [Community Raids](/docs/guides/vault/community-raids/) is the clearest example: its own text says directly, “which raids are currently active … change continuously; see the live [Community Raids](https://www.solme.me/vault/community) for the current list. This page covers the mechanism, not a point-in-time snapshot of it.” Treat any page written this way the same: the mechanism description is stable and citable; specific current numbers are not — go to the linked live source for those. ## What Doesn’t Exist Here [Section titled “What Doesn’t Exist Here”](#what-doesnt-exist-here) This site doesn’t publish per-page “last updated” timestamps as a freshness signal today. The real signal is the distinction above: is this page describing a static mechanic (trust it as current) or explicitly pointing you to a live source for numbers (don’t treat the page’s own text as a live snapshot)? ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/) — which page is authoritative for a given fact * [Citations](/docs/ai/knowledge-policy/citations/) — how to reference what you found here, including live-data caveats # Prohibited Assumptions > What never to assume about SOLMEME just because it would be plausible. Confident, plausible-sounding text is not the same as accurate text. This site is authored under a rule that treats an unconfirmed claim as blocking regardless of how natural it would sound — this page states that same rule from the reader’s side. ## Never Assume… [Section titled “Never Assume…”](#never-assume) * **A number, date, or name that isn’t stated on this site.** “SOLMEME probably has around \[X] holders” or “the next drop is likely in \[month]” are the kind of plausible-sounding fabrication this site itself refuses to publish — don’t introduce it when reading either. * **That a “coming soon”/reserved section already has the content its title implies.** [Ambassadors](/docs/ambassadors/), [Reference → Brand Book/Media Kit/Mascot](/docs/reference/), and this site’s own [Learning → Courses](/docs/learning/courses/) are real, intentionally reserved sections — their existence in the navigation isn’t evidence their content exists yet. Check for the page’s own visible status before citing it as documented. * **That features common on other memecoin sites exist here.** Whitepapers, roadmaps with fixed dates, or a public tokenomics spreadsheet are common elsewhere — assume nothing about SOLMEME specifically has one unless a real page here says so. * **That a mechanism described as “planned” is live.** [MCP](/docs/ai/mcp/) is the clearest example — it’s a real, described architectural direction, not something you can connect to today. * **That silence means “no.”** A topic this site doesn’t cover yet is undocumented, not confirmed absent — see [Uncertainty](/docs/ai/knowledge-policy/uncertainty/) for how to phrase that distinction. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/) — how to tell what’s actually documented * [Uncertainty](/docs/ai/knowledge-policy/uncertainty/) — what to say instead of guessing # Uncertainty > What to say when this site doesn't have a confirmed answer. Not knowing something is a normal outcome, not a failure to work around. This site is built so uncertainty is always visible rather than quietly smoothed over — this page covers how to carry that same honesty into an answer. ## If a Page Doesn’t Exist or Is a Stub [Section titled “If a Page Doesn’t Exist or Is a Stub”](#if-a-page-doesnt-exist-or-is-a-stub) Say so plainly: “SOLMEME’s documentation doesn’t cover this yet” is a complete, correct, useful answer. It’s more useful than a fluent paragraph built from adjacent facts and general crypto-project conventions, because a confident-sounding guess is harder for the person reading it to catch than an honest “not documented.” ## If a Page Partially Answers the Question [Section titled “If a Page Partially Answers the Question”](#if-a-page-partially-answers-the-question) Say what it does answer, and name what it doesn’t. [Reference](/docs/reference/) already models this on-page: it explains what the Brand Book/Media Kit/Mascot sections will eventually cover, while stating plainly that none of the three has real content published yet — the reader gets a real, useful answer about scope without being told a specific fact that isn’t actually confirmed. ## If Two Pages Seem to Disagree [Section titled “If Two Pages Seem to Disagree”](#if-two-pages-seem-to-disagree) Don’t silently pick one. Name the apparent conflict and point to [Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/)’s resolution rule (the deeper, purpose-built page wins over a page that only mentions the topic in passing) rather than guessing which one is right. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Canonical Sources](/docs/ai/knowledge-policy/canonical-sources/) — how to tell what’s actually documented * [Prohibited Assumptions](/docs/ai/knowledge-policy/prohibited-assumptions/) — specific things never to fill an uncertainty gap with # LLMs.txt > How this site's real, live llms.txt and per-page Markdown access work today. This is the one AI-access mechanism on this site that’s real and live today — not planned, not conceptual. `llms.txt` is a convention that lets AI tools discover a site’s content in a compact, machine-readable form instead of parsing rendered HTML. ## What Is LLMs.txt? [Section titled “What Is LLMs.txt?”](#what-is-llmstxt) An `llms.txt` file is a plain-text index of a site’s documentation, generated for AI consumption rather than human browsing. This site generates its own automatically at build time — real content, not a hand-maintained list that can drift out of sync with what’s actually published. ## Available Routes [Section titled “Available Routes”](#available-routes) Three files, each a different level of detail: * **[`/llms.txt`](/docs/llms.txt)** — a compact index of the documentation set, linking out to the fuller versions. * **[`/llms-full.txt`](/docs/llms-full.txt)** — the complete documentation content in one machine-readable file. * **[`/llms-small.txt`](/docs/llms-small.txt)** — an abridged version with non-essential content removed, for tools with tighter context budgets. All three are generated from this site’s real, published content — the same pages you’re browsing right now, not a separate maintained copy. Local-only reference/demo pages are stripped out of all three, so an agent reading them only ever sees real SOLMEME documentation. ## Per-Page Markdown Access [Section titled “Per-Page Markdown Access”](#per-page-markdown-access) Beyond the three index files, any individual documentation page on this site can be requested as plain Markdown by appending `.md` to its URL — useful for an agent that wants one specific page’s content rather than the entire index. ## Usage with AI Tools [Section titled “Usage with AI Tools”](#usage-with-ai-tools) Point any AI tool or agent that supports the `llms.txt` convention at [`/llms.txt`](/docs/llms.txt) as this site’s entry point. For an agent consuming this site’s content, [Knowledge Policy](/docs/ai/knowledge-policy/) governs how to treat what it finds there — what counts as canonical, how to judge freshness, and when to cite a source rather than state something as settled fact. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [AI Tools Overview](/docs/ai/) — how this fits into this site’s wider AI-access layer * [Knowledge Policy](/docs/ai/knowledge-policy/) — the rules for how to treat what you read via these files # MCP > SOLMEME's planned MCP server — the architectural direction, not a live service yet. MCP (Model Context Protocol) is a standard way for AI agents to call into structured tools and data sources instead of guessing at a site’s structure or scraping arbitrary pages. A SOLMEME MCP server is a **planned access mechanism — not live yet.** This page describes the architectural direction, not something you can connect to today. ## Why This Is Planned, Not Built [Section titled “Why This Is Planned, Not Built”](#why-this-is-planned-not-built) Discord and Telegram AI agents that support the SOLMEME community currently need a reliable way to pull real documentation instead of parsing pages themselves — MCP is the intended answer to that need. It’s meant as an access layer, not a source of truth in itself: the actual facts still live in this documentation site (static content) or in whichever system owns dynamic data (Vault status, community metrics), and MCP would only provide structured access to them. ## The Conceptual Model [Section titled “The Conceptual Model”](#the-conceptual-model) Two separate request pipelines, kept intentionally distinct so no MCP capability mixes a documentation lookup with a live-data lookup in the same call: * **Static, authoritative knowledge** (this documentation site’s own content — Reference, Community policy, Learning, Guides, Tutorials, Introduction): author → review → canonical content → this site → machine-readable representation → MCP → AI agent. * **Dynamic data** (things that change continuously — current Vault participants, live mission/event status): external source → fetch → normalize → validate → cache → data layer → MCP → AI agent. A candidate (not yet approved) set of capabilities under this model: documentation lookup (`search_docs`, `get_document`, `list_documents`), structured knowledge (`get_policy`, `get_reference`), and dynamic data (`events`, `missions`, `community_status`) — grouped by which pipeline each belongs to, not mixed. ## What Exists Today Instead [Section titled “What Exists Today Instead”](#what-exists-today-instead) Until MCP is live, [LLMs.txt](/docs/ai/llms-txt/) is this site’s real, working machine-readable access mechanism — any AI tool can already read `/llms.txt` and per-page Markdown today, no MCP server required. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [AI Tools Overview](/docs/ai/) — the full picture of this site’s AI-access layer * [LLMs.txt](/docs/ai/llms-txt/) — the access mechanism that’s real today * [Knowledge Policy](/docs/ai/knowledge-policy/) — how any mechanism, MCP included, should treat this site’s content once it’s in use # Ambassador Program Overview > What SOLMEME's Ambassador Program is and how to join — program rules and requirements are in preparation, not yet confirmed for publication. This section is where SOLMEME’s Ambassador Program will be documented — what it is, how someone joins, and what’s expected of an ambassador, in one place a prospective or current ambassador can rely on. ## Who This Is For [Section titled “Who This Is For”](#who-this-is-for) Community members considering representing SOLMEME publicly, current ambassadors looking up program details, and anyone trying to understand how ambassadors relate to the rest of the community. Content In Preparation The Ambassador Program is being prepared — this page describes the section’s real shape, not invented program facts. Full detail pages wait on confirmed program material; see `doc/Daria/tasks/DARIA- AMBASSADOR-01.md` for what’s being requested. ## What You’ll Find Here, Once Populated [Section titled “What You’ll Find Here, Once Populated”](#what-youll-find-here-once-populated) * **Handbook** — the program’s rulebook. * **Onboarding** — what happens after joining. * **Requirements** and **Responsibilities** — eligibility and expected duties. * **Missions** — ambassador-specific tasks. * **Content** and **Brand** — content-creation guidelines, and how to represent SOLMEME’s brand correctly (referencing [Reference → Brand Book](/docs/reference/), not a separate standard). * **Community** — how ambassadors relate to the wider SOLMEME Community. * **FAQ** — recurring questions once the above exists. ## Where This Section Stands Today [Section titled “Where This Section Stands Today”](#where-this-section-stands-today) The pages above are reserved, real routes — the program’s actual rules, requirements, and current status aren’t published here yet, because they haven’t been confirmed for documentation. This is a boundary of what’s currently documented, not a statement that the program doesn’t exist or isn’t active — just that this section doesn’t yet state specifics it can’t back up. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) For a concrete way to get involved with SOLMEME today, see [Guides → Getting Involved](/docs/guides/getting-involved/) — the Ambassador Program is one path among the ones covered there, once this section is populated. # Brand > Brand usage guidance for Ambassadors. See Reference → Brand Book for the canonical standard. Brand usage guidance for Ambassadors. See Reference → Brand Book for the canonical standard. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Community > Ambassador-specific community responsibilities. Ambassador-specific community responsibilities. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Content > Content creation guidance for Ambassadors. Content creation guidance for Ambassadors. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # FAQ > Frequently asked questions about the Ambassador program. Frequently asked questions about the Ambassador program. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Handbook > The Ambassador program handbook. The Ambassador program handbook. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Missions > What Missions mean specifically for Ambassadors. What Missions mean specifically for Ambassadors. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Onboarding > Onboarding process for new Ambassadors. Onboarding process for new Ambassadors. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Requirements > Requirements to become an Ambassador. Requirements to become an Ambassador. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Responsibilities > Responsibilities of an Ambassador. Responsibilities of an Ambassador. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Community Overview > What the Community section covers — policy, governance, safety. SOLMEME Community is volunteer-driven. Beyond a small core team, it runs on community members — creators, ambassadors, and moderators — who choose to put in the work, not on paid staff running every function. ## What Volunteer-Driven Means Here [Section titled “What Volunteer-Driven Means Here”](#what-volunteer-driven-means-here) There’s no large paid operations team behind the day-to-day of this community. The core team handles the product and the platform; everything that makes the community itself work — content, moderation, onboarding newcomers, running events — depends on people choosing to contribute their time. That’s a structural fact about how SOLMEME Community operates, not a marketing description: if volunteers stop showing up, those functions stop happening. It’s also why the roles in [Guides → Creators](/docs/guides/creators/) and the (planned) Ambassador Program exist — they’re the shape volunteer contribution actually takes. ## What This Section Covers [Section titled “What This Section Covers”](#what-this-section-covers) This is SOLMEME Community’s policy and governance layer — the rules and norms that apply to everyone, as distinct from [Guides](/docs/guides/community/), which covers how to actually do things. * **Code of Conduct** — expected and unacceptable behavior, and what happens when it’s violated. * **Community Guidelines** — day-to-day expectations for participation. * **Safety** — SOLMEME’s policy position on community-facing risks (scams, impersonation); practical steps to protect yourself live in [Guides → Security](/docs/guides/security/). * **Moderation** — how and why moderation happens. * **Reporting** — how to report a problem, and what happens next. The 5 policy pages above are real, reserved routes; their specific rule text isn’t published yet — each needs sign-off from someone who can confirm it matches actual enforcement practice before it goes live as official policy, so nothing here states an unconfirmed rule as settled. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) For a short version of this same fact, see [Getting Started](/docs/getting-started/). For concrete ways to start participating, see [Guides → Getting Involved](/docs/guides/getting-involved/) — this page explains what volunteer-driven means for SOLMEME; that one covers how to actually start. # Code of Conduct > Draft Code of Conduct for the SOLMEME community — pending reviewer sign-off before it takes effect as official policy. Draft — pending review This page is a **draft**, not published policy. It states what’s already confirmed about SOLMEME Community’s structure and what a Code of Conduct here is meant to cover — it does not yet state specific behavioral rules or consequences, because those haven’t been confirmed against real, current enforcement practice. Publishing this as effective policy requires sign-off from **Daria**, named as this project’s Community policy reviewer. Until that sign-off is received, nothing on this page should be treated as an enforceable rule. A Code of Conduct sets the baseline for how people are expected to treat each other across SOLMEME Community — Discord, Telegram, and anywhere else the community gathers under the SOLMEME name. ## What This Page Will Cover, Once Confirmed [Section titled “What This Page Will Cover, Once Confirmed”](#what-this-page-will-cover-once-confirmed) * Expected behavior — the baseline standard of conduct for anyone participating. * Unacceptable behavior — specific actions that violate this Code. * Interaction principles — how disagreements and conflicts should be handled. * Responsibility — who this Code applies to (participants, moderators, the core team). * Consequences of violations — what happens when the Code is broken. * The handling mechanism — how a violation is raised, reviewed, and acted on. Content Input Required The specific expected/unacceptable behavior list, the consequence ladder, and the enforcement mechanism are not stated here — none of these has a confirmed, current-practice source yet. Filling them in without that confirmation would risk publishing rules SOLMEME doesn’t actually enforce this way. This is exactly what Daria, the named reviewer, needs to confirm before this page can state them as real policy. ## What’s Already Real [Section titled “What’s Already Real”](#whats-already-real) * **SOLMEME Community is volunteer-driven** — moderators here are community volunteers, not paid staff. See [Community Overview](/docs/community/) for the full structural context this Code operates within. * **Reporting a problem today** — [Reporting](/docs/community/reporting/) covers how, once its own draft is confirmed. Right now, the fastest real path is flagging a moderator directly in the [Discord](https://discord.gg/solmeme). ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Community Overview](/docs/community/) — the structure this policy sits within * [Community Guidelines](/docs/community/community-guidelines/) — the practical, day-to-day counterpart to this Code * [Reporting](/docs/community/reporting/) — how to raise a violation # Community Guidelines > Draft day-to-day participation guidelines for SOLMEME Community — pending reviewer sign-off before they take effect. Draft — pending review This page is a **draft**, not published policy. It states this page’s intended scope and relationship to the [Code of Conduct](/docs/community/code-of-conduct/) — it does not yet state specific day-to-day rules, because those haven’t been confirmed against real, current practice. Publishing this as effective policy requires sign-off from **Daria**, named as this project’s Community policy reviewer. Where the [Code of Conduct](/docs/community/code-of-conduct/) sets the baseline standard for behavior, Community Guidelines are meant to be the more practical, applied counterpart — what day-to-day participation in SOLMEME Community actually looks like. ## What This Page Will Cover, Once Confirmed [Section titled “What This Page Will Cover, Once Confirmed”](#what-this-page-will-cover-once-confirmed) * How the Code of Conduct’s baseline standards apply to everyday interaction — in Discord discussion, content sharing, and community events. * Concrete expectations for participation that are more specific than the Code’s general principles, without duplicating it. Content Input Required The specific day-to-day expectations aren’t stated here — this page intentionally doesn’t restate generic community-guideline boilerplate as if it were SOLMEME’s own confirmed practice. What’s actually expected of participants day-to-day needs to come from someone who can confirm it matches how this community really operates. ## What’s Already Real [Section titled “What’s Already Real”](#whats-already-real) SOLMEME Community is volunteer-driven — see [Community Overview](/docs/community/) for what that means structurally. Guidelines here would apply to the same space these volunteers help run: [Discord](https://discord.gg/solmeme) and the community’s other official channels. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Code of Conduct](/docs/community/code-of-conduct/) — the baseline standard this page builds on * [Community Overview](/docs/community/) — the volunteer-driven structure behind both * [Getting Involved](/docs/guides/getting-involved/) — practical first steps to participate # Moderation > Draft description of how moderation works in SOLMEME Community — pending reviewer sign-off before it takes effect. Draft — pending review This page is a **draft**, not published policy. It states what’s already confirmed about who moderates and why — it does not yet state specific moderation actions, tools, or process, because those haven’t been confirmed against real, current practice. Publishing this as effective policy requires sign-off from **Daria**, named as this project’s Community policy reviewer. ## What’s Already Real [Section titled “What’s Already Real”](#whats-already-real) Moderation in SOLMEME Community is done by **volunteers** — see [Community Overview](/docs/community/): “moderators” are named explicitly among the volunteer roles that make the community function, not paid staff. That’s the one confirmed structural fact this page can state today. ## What This Page Will Cover, Once Confirmed [Section titled “What This Page Will Cover, Once Confirmed”](#what-this-page-will-cover-once-confirmed) * Why moderation exists — the purpose it serves for the community. * The principles moderation operates under. * What actions moderators can actually take. * How consistent enforcement of the [Code of Conduct](/docs/community/code-of-conduct/) is ensured in practice. Content Input Required The specific moderation team structure, the concrete actions available to a moderator, and the real enforcement process aren’t stated here — none of this has a confirmed source yet. Inventing a plausible-sounding moderation process would risk misrepresenting how enforcement actually happens today. This is what Daria, the named reviewer, needs to confirm. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Code of Conduct](/docs/community/code-of-conduct/) — the standard moderation enforces * [Reporting](/docs/community/reporting/) — how a problem reaches a moderator today * [Community Overview](/docs/community/) — the volunteer structure moderation is part of # Reporting > How to report a problem in SOLMEME Community — the real path today, plus a draft formal process pending reviewer sign-off. Draft — pending review The **formal, written reporting process** described below is a **draft**, not published policy — it needs confirmation from **Daria**, named as this project’s Community policy reviewer. The **real, working path** in the section right below this notice already works today and doesn’t depend on that sign-off. ## How to Report a Problem Today [Section titled “How to Report a Problem Today”](#how-to-report-a-problem-today) Flag it to a moderator directly in the real [Discord](https://discord.gg/solmeme) — that’s the fastest, real reporting path available right now. This is the same guidance already published at [Guides → Security](/docs/guides/security/#if-something-looks-wrong), not a new claim introduced here. ## What a Formal Process Will Add, Once Confirmed [Section titled “What a Formal Process Will Add, Once Confirmed”](#what-a-formal-process-will-add-once-confirmed) * What specifically should be reported here versus handled elsewhere. * Where exactly to send a report, beyond “flag a moderator in Discord.” * What information a report should include. * What happens after a report is submitted. * Any real limitations on what this process can address. Content Input Required None of the formal-process specifics above are stated here yet — what counts as reportable, what information is needed, what happens after submission, and any real limitations all need confirmation from someone who can speak to actual current practice. Until Daria confirms this, the Discord-moderator path above remains the only real reporting mechanism this site can honestly point to. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Guides → Security](/docs/guides/security/) — practical safety steps, including the real reporting path above * [Code of Conduct](/docs/community/code-of-conduct/) — the standard a report would be measured against * [Moderation](/docs/community/moderation/) — how moderation handles what gets reported # Safety > Draft safety policy position for SOLMEME Community — pending reviewer sign-off before it takes effect. Draft — pending review This page is a **draft**, not published policy. It states this page’s scope and how it differs from the already-published practical guide — it does not yet state SOLMEME’s specific, confirmed policy position, because that hasn’t been signed off. Publishing this as effective policy requires confirmation from **Daria**, named as this project’s Community policy reviewer. This page is the **policy** layer: SOLMEME Community’s stated position on community-facing risks. [Guides → Security](/docs/guides/security/) is the **practical** layer — concrete steps to protect yourself — and is already real, published, and usable today regardless of this page’s draft status. ## What This Page Will Cover, Once Confirmed [Section titled “What This Page Will Cover, Once Confirmed”](#what-this-page-will-cover-once-confirmed) * Which risks SOLMEME Community formally recognizes (scams, impersonation, and others). * The safety principles the community operates under. * What the community considers unacceptable behavior from a safety standpoint. * The baseline safe-behavior rules the community expects. Content Input Required The specific, official risk list and the community’s formal safety position aren’t stated here. [Guides → Security](/docs/guides/security/) already covers real, generic crypto-safety practices (wallet protection, scam-pattern recognition, channel verification) usable today — but this page’s *policy* statement, distinct from that practical guide, needs Daria’s confirmation before it can be published as SOLMEME’s official position. ## What’s Already Real [Section titled “What’s Already Real”](#whats-already-real) * **[Guides → Security](/docs/guides/security/)** — practical steps to protect your wallet, recognize scam patterns, and verify you’re on a real SOLMEME channel. Use this today; it doesn’t depend on this page’s draft status. * **[Verify an Official Account](/docs/tutorials/verify-an-official-account/)** — the exact official channel list and how to check against it. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Guides → Security](/docs/guides/security/) — practical safety steps, real today * [Verify an Official Account](/docs/tutorials/verify-an-official-account/) — checking a channel is real * [Community Overview](/docs/community/) — how this policy fits into the wider structure # Contracts > SOLMEME's on-chain smart contracts — what they are, and where to find current details. SOLMEME runs on Solana. The token, the Vault system, and the monthly drop mechanics are all backed by on-chain smart contracts — this section is where their real, verified details belong: which contracts are currently live, what each one does, and their version history. ## Why This Section Exists [Section titled “Why This Section Exists”](#why-this-section-exists) A crypto project’s contracts are part of its technical documentation, not an afterthought. Anyone verifying a transaction, integrating with SOLMEME, or checking that a contract matches what’s deployed on-chain should be able to find that here — addresses, purpose, and status, kept accurate rather than left to scattered social posts. ## What’s Here [Section titled “What’s Here”](#whats-here) * **[Current Contracts](/docs/contracts/current/)** — the growing catalog of live token drops: what each one is for, its address, and its verification status. * **[Contract History](/docs/contracts/history/)** — the chronological launch record of every monthly drop (SOLMEME’s inverse token economics means older drops aren’t retired, so this isn’t a “deprecated contracts” list). Status Real data for 3 drops (SpaceGoat/$GOAT, Cyber Cat/$CAT, Oracle Owl/$OWL) is live on both pages, sourced from a real Discord export (`doc/token-launches_discord_chanel.md`). A new drop launches roughly monthly and needs to be added here going forward — this section is not a one-time backfill. For on-chain activity and current balances, the live [Vault dashboard on solme.me](https://www.solme.me/vault) reflects real-time state; this section documents the contracts themselves, not their live data. # Current Contracts > SOLMEME's monthly token drops, still live and usable in the Vault today. A new SOLMEME token contract launches roughly monthly, posted first in the `#🎯｜token-launches` Discord channel. Under SOLMEME’s inverse token economics, older drops aren’t retired when a new one launches — each new drop makes prior ones more useful in the Vault, so every contract below stays “current” until real evidence says otherwise. This page is a growing catalog, not a single-drop snapshot. Live balances, trading volume, and other figures that change continuously are **not** restated here — see each contract’s own Solscan/Dexscreener link for that. ## Live Contracts [Section titled “Live Contracts”](#live-contracts) | Drop | Token | Contract address | Network | Launched | | ---- | ---------- | ---------------- | ---------------------------------------------- | -------------------------------- | | #1 | SpaceGoat | `$GOAT` | `5MRMqvLZyRQhrMn2a8vSL3Kv9vfjNhjRKRPHtTBz1VEB` | Solana (pump.fun) — genesis drop | | #2 | Cyber Cat | `$CAT` | `FcxKmrdFZBXSE7RTnSV7vsTSxC4BnNhhkMayT1UMDeU` | Solana (pump.fun) | | #3 | Oracle Owl | `$OWL` | `EEEGjQLQf35RHPGXkxMAPKxkXfgqQdFieZ5bsz8fSTnn` | Solana (pump.fun), 1 August 2026 | **Verification status, as posted at launch** (not re-checked continuously — see each contract’s own live explorer link for current state): * **SpaceGoat ($GOAT)** — verification status not stated in the source export. * **Cyber Cat ($CAT)** — Mint: REVOKED · Freeze: REVOKED · Rugcheck: PASSED. * **Oracle Owl ($OWL)** — Mint: REVOKED · Freeze: REVOKED · Rugcheck: PASSED. Live chart: [Dexscreener](https://dexscreener.com/solana/9khl8p4vemn85hkjqqfkk8wmdgfy5dwu9ksqpgysdppl). Each drop’s Vault mechanics, tier progression, and charity-vote multipliers are covered in [Guides → Vault](/docs/guides/vault/) and [Ecosystem → Charities](/docs/ecosystem/charities/) — not repeated here, to avoid two different pages drifting out of sync on the same mechanic. Source and update process Data above: `doc/token-launches_discord_chanel.md`, a real export of the `#🎯｜token-launches` Discord channel (owner-provided). A new contract is posted to that channel roughly every month and needs to land here — see [Contract History](/docs/contracts/history/) for the reasoning behind why this page doesn’t move a contract out once a newer one launches. Audit/security status is contract-level historical fact **as of the date posted** — always confirm against a live block explorer before relying on it for a transaction decision. # Contract History > Chronological record of every SOLMEME monthly drop — not a list of retired contracts. Under SOLMEME’s inverse token economics, a new monthly drop doesn’t retire the ones before it — every prior contract stays live and useful in the Vault (see [Current Contracts](/docs/contracts/current/)). So this page is a **chronological launch record**, not a “deprecated contracts” list — that’s a deliberate reading of the real data below, not yet a direct owner sign-off on the framing; see the note at the bottom. ## Launch Timeline [Section titled “Launch Timeline”](#launch-timeline) | Drop | Token | Launched | Theme | | ---- | ----------------- | ----------------------- | --------------------------------------------------------- | | #1 | SpaceGoat ($GOAT) | pump.fun, genesis drop | “Chased ambition” — the first drop from the SOLMEME Vault | | #2 | Cyber Cat ($CAT) | pump.fun | “Held the line” — proved the monthly-drop model works | | #3 | Oracle Owl ($OWL) | pump.fun, 1 August 2026 | “The Oracle Awakens” — prediction-markets theme | Contract addresses and current status for each are on [Current Contracts](/docs/contracts/current/) — not repeated here, so address data has exactly one canonical location. Content-model framing, not yet owner-confirmed `PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §12 item 15 flags this explicitly: reading the real Discord export’s “inverse token economics” language as “Current = growing catalog, History = launch record, not retirement list” is this project’s own interpretation of the source data, not a direct owner directive about how these two pages should be framed. Worth a short confirmation before this framing is treated as final — noted here rather than silently assumed. # Ecosystem > External organizations and platforms connected to SOLMEME — charity partners. SOLMEME isn’t an isolated product — this section covers everything connected to it that isn’t the product itself: the charity organizations its launches fund, external platforms and communities in its orbit, and the historical record of past drops. If Learning explains concepts and Guides explains how to participate, Ecosystem explains what SOLMEME touches outside of itself. ## Who This Is For [Section titled “Who This Is For”](#who-this-is-for) Anyone checking what SOLMEME actually supports or connects to — partners verifying a claim, community members researching where charity proceeds go, or anyone who wants the full picture beyond the token itself. ## What’s Here [Section titled “What’s Here”](#whats-here) * **[Charities](/docs/ecosystem/charities/)** — 50 real partner organizations across 16 cause categories, funded by the 5% of every launch’s proceeds reserved for charity. Browse by category, not one long list. * **[Archive](/docs/ecosystem/archive/)** — the historical record of past drops and their charity beneficiaries. * **Partners**, **Platforms**, **Communities** — reserved sections for SOLMEME’s external partnerships, platform integrations, and affiliated communities. No confirmed roster exists yet for any of the three — these pages stay honest placeholders rather than invented examples until real ones are confirmed. On-chain verification of SOLMEME’s own contracts — a related but separate concern from its external ecosystem — lives in [Contracts](/docs/contracts/), not here. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) Start with [Charities](/docs/ecosystem/charities/) — it’s the one part of this section that’s fully real today. # Archive > Historical record of past SOLMEME drops and their charity beneficiaries. A record of every SOLMEME drop, its trend, and the charity beneficiary of that launch’s donation. Market cap and charity totals shown here are as recorded at the time this page was written — for current figures, see [DexScreener](https://dexscreener.com/solana) via each drop’s chart link. Drop #0 — SOLMEME **Trend:** Governance token — the original Solana meme **Beneficiary:** Community-driven donations [View chart on DexScreener](https://dexscreener.com/solana/5MRMqvLZyRQhrMn2a8vSL3Kv9vfjNhjRKRPHtTBz1VEB) Drop #1 — Space Goat **Trend:** SpaceX IPO + Goat Meta **Beneficiary:** Space education and builder recovery [View chart on DexScreener](https://dexscreener.com/solana/3fAyYZh8W2noL2xUzK7DfZqphqC6nvBUPmwWtRWEQb9D) Drop #2 — Cyber Cat **Trend:** AI Security — GPT-5.5-Cyber vs Mythos **Beneficiary:** Open-source security foundations [View chart on DexScreener](https://dexscreener.com/solana/FcxKmrdFZBXSE7RTnSV7vsTSxC4BnNnhkMayT1UMDeU) Drop #3 — Oracle Owl **Trend:** Prediction Markets — $3.2B quarterly volume (Polymarket, Jupiter Forecast, World in Phantom) **Beneficiary:** World Owl Trust — owl conservation and habitat preservation [View chart on DexScreener](https://dexscreener.com/solana/9khl8p4vemn85hkjqqfkk8wmdgfy5dwu9ksqpgysdppl) Freshness Peak market cap and charity totals for drops #1–#3 were listed as N/A/TBD at the time of writing — this is a historical registry, not a live dashboard, so it isn’t re-checked automatically. Revisit when new drops close out. # Charities > SOLMEME reserves 5% of every launch's proceeds for charity, split across 50 non-political causes in 16 categories, verified on-chain. Every SOLMEME launch reserves 5% of proceeds for charity, split across 50 non-political causes in 16 categories. Donations are verified on-chain — for current totals and posted transaction proofs, see the live [Charities dashboard on solme.me](https://www.solme.me/charity), which updates as donations are confirmed; this page doesn’t restate figures that change outside of docs. Each category below groups a set of partner organizations working toward the same cause. Open a category to see its full list of organizations. ## Categories [Section titled “Categories”](#categories) * [Animal Welfare](/docs/ecosystem/charities/animal-welfare/) — 5 organizations * [Environment](/docs/ecosystem/charities/environment/) — 5 organizations * [Children](/docs/ecosystem/charities/children/) — 4 organizations * [Education](/docs/ecosystem/charities/education/) — 4 organizations * [Health & Medical](/docs/ecosystem/charities/health-medical/) — 5 organizations * [Hunger & Food](/docs/ecosystem/charities/hunger-food/) — 3 organizations * [Clean Water](/docs/ecosystem/charities/clean-water/) — 3 organizations * [Disaster Relief](/docs/ecosystem/charities/disaster-relief/) — 3 organizations * [Veterans](/docs/ecosystem/charities/veterans/) — 3 organizations * [Elderly Care](/docs/ecosystem/charities/elderly-care/) — 2 organizations * [Disability Support](/docs/ecosystem/charities/disability-support/) — 2 organizations * [Mental Health](/docs/ecosystem/charities/mental-health/) — 3 organizations * [Arts & Culture](/docs/ecosystem/charities/arts-culture/) — 2 organizations * [Science & Research](/docs/ecosystem/charities/science-research/) — 2 organizations * [Homelessness & Housing](/docs/ecosystem/charities/homelessness-housing/) — 2 organizations * [Community Development](/docs/ecosystem/charities/community-development/) — 2 organizations # 4ocean > SOLMEME charity partner since July 15, 2023 — 4ocean removes trash from oceans and coastlines. Category: Environment. **Category:** Environment 4ocean works to remove trash from oceans and coastlines — a cause SOLMEME supports for its visible cleanup impact measured in pounds removed. Partner since July 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/4ocean) — this page doesn’t restate figures that change outside of docs. Learn more: [4ocean.com](https://4ocean.com) # AARP Foundation > SOLMEME charity partner: AARP Foundation — Elderly Care. **Category:** Elderly Care AARP Foundation works to help vulnerable seniors build opportunity and connectedness — a cause SOLMEME supports because aging should not mean isolation or insecurity. Partner since January 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/aarp-foundation) — this page doesn’t restate figures that change outside of docs. Learn more: [aarpfoundation.org](https://aarpfoundation.org) # Alzheimer's Association > SOLMEME charity partner: Alzheimer's Association — Health & Medical. **Category:** Health & Medical Alzheimer’s Association works to end Alzheimer’s and all other dementia — a cause SOLMEME supports because nearly every family is touched by dementia eventually. Partner since October 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/alzheimer-s-association) — this page doesn’t restate figures that change outside of docs. Learn more: [alz.org](https://alz.org) # American Red Cross > SOLMEME charity partner: American Red Cross — Health & Medical. **Category:** Health & Medical American Red Cross works to prevent and alleviate human suffering in emergencies — disaster response people recognize and rely on. Partner since August 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/american-red-cross) — this page doesn’t restate figures that change outside of docs. Learn more: [redcross.org](https://redcross.org) # Animal Welfare > SOLMEME charity partners in the Animal Welfare category. Five of SOLMEME’s fifty partner organizations focus on animal welfare — from wildlife conservation to guide-dog training to marine rescue: * [ASPCA](/docs/ecosystem/charities/aspca/) * [Best Friends Animal Society](/docs/ecosystem/charities/best-friends-animal-society/) * [Wildlife Conservation Society](/docs/ecosystem/charities/wildlife-conservation-society/) * [Guide Dogs for the Blind](/docs/ecosystem/charities/guide-dogs-for-the-blind/) * [The Marine Mammal Center](/docs/ecosystem/charities/the-marine-mammal-center/) Donation totals and transaction proofs for these partners live on the [Charities dashboard](https://www.solme.me/charity), not here — figures there update continuously, so this page doesn’t try to restate them. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Arbor Day Foundation > SOLMEME charity partner: Arbor Day Foundation — Environment. **Category:** Environment Arbor Day Foundation works to inspire people to plant, nurture, and celebrate trees — a cause SOLMEME supports because trees are simple, useful, and future-positive. Partner since August 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/arbor-day-foundation) — this page doesn’t restate figures that change outside of docs. Learn more: [arborday.org](https://arborday.org) # Arts & Culture > SOLMEME charity partners in the Arts & Culture category. Two of SOLMEME’s fifty partner organizations focus on arts & culture — from open creative licensing to arts access in schools: * [Creative Commons](/docs/ecosystem/charities/creative-commons/) * [Arts in Education](/docs/ecosystem/charities/arts-in-education/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Arts in Education > SOLMEME charity partner: Arts in Education — Arts & Culture. **Category:** Arts & Culture Arts in Education works to bring arts to underserved schools — a cause SOLMEME supports because creativity builds problem-solving and confidence. Partner since August 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/arts-in-education) — this page doesn’t restate figures that change outside of docs. Learn more: [artsineducation.org](https://artsineducation.org) # ASPCA > SOLMEME charity partner since January 15, 2023 — ASPCA rescues animals from abuse and advances humane laws. Category: Animal Welfare. **Category:** Animal Welfare ASPCA works to rescue animals from abuse, pass humane laws, and share resources — a cause SOLMEME supports for its universally loved, direct rescue impact. Partner since January 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/aspca) — this page doesn’t restate figures that change outside of docs. Learn more: [aspca.org](https://aspca.org) # Best Friends Animal Society > SOLMEME charity partner: Best Friends Animal Society — Animal Welfare. **Category:** Animal Welfare Best Friends Animal Society runs no-kill animal shelters nationwide, working to end shelter killing — a cause SOLMEME supports for its leadership of the no-kill movement with tangible results. Partner since February 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/best-friends-animal-society) — this page doesn’t restate figures that change outside of docs. Learn more: [bestfriends.org](https://bestfriends.org) # charity: water > SOLMEME charity partner: charity: water — Clean Water. **Category:** Clean Water charity: water works to bring clean and safe drinking water to every person — a cause SOLMEME supports because clean water unlocks health, education, and time. Partner since March 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/charity-water) — this page doesn’t restate figures that change outside of docs. Learn more: [charitywater.org](https://charitywater.org) # Children > SOLMEME charity partners in the Children category. Four of SOLMEME’s fifty partner organizations focus on children — from pediatric research to wish fulfillment to global child welfare: * [St. Jude Children’s Research Hospital](/docs/ecosystem/charities/st-jude-children-s-research-hospital/) * [Save the Children](/docs/ecosystem/charities/save-the-children/) * [Make-A-Wish Foundation](/docs/ecosystem/charities/make-a-wish-foundation/) * [UNICEF](/docs/ecosystem/charities/unicef/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Clean Water > SOLMEME charity partners in the Clean Water category. Three of SOLMEME’s fifty partner organizations focus on clean water — from direct water-access charities to community-led water projects: * [charity: water](/docs/ecosystem/charities/charity-water/) * [Water.org](/docs/ecosystem/charities/water-org/) * [The Water Project](/docs/ecosystem/charities/the-water-project/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Code.org > SOLMEME charity partner since June 15, 2025 — Code.org expands computer science access in schools. Category: Education. **Category:** Education Code.org works to expand access to computer science in schools — a cause SOLMEME supports because future builders need access to computing early. Partner since June 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/code-org) — this page doesn’t restate figures that change outside of docs. Learn more: [code.org](https://code.org) # Community Development > SOLMEME charity partners in the Community Development category. Two of SOLMEME’s fifty partner organizations focus on community development, including livestock-based aid: * [Kiva](/docs/ecosystem/charities/kiva/) * [Heifer International](/docs/ecosystem/charities/heifer-international/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Covenant House > SOLMEME charity partner: Covenant House — Homelessness & Housing. **Category:** Homelessness & Housing Covenant House provides shelter and services for youth facing homelessness — a cause SOLMEME supports because young people deserve safety and a chance. Partner since December 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/covenant-house) — this page doesn’t restate figures that change outside of docs. Learn more: [covenanthouse.org](https://covenanthouse.org) # Creative Commons > SOLMEME charity partner: Creative Commons — Arts & Culture. **Category:** Arts & Culture Creative Commons builds legal tools for sharing creativity and knowledge — a cause SOLMEME supports because open culture aligns with open-source and web3 values. Partner since July 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/creative-commons) — this page doesn’t restate figures that change outside of docs. Learn more: [creativecommons.org](https://creativecommons.org) # Crisis Text Line > SOLMEME charity partner: Crisis Text Line — Mental Health. **Category:** Mental Health Crisis Text Line provides free 24/7 crisis support via text — mental health support that’s accessible immediately, a cause SOLMEME supports. Partner since April 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/crisis-text-line) — this page doesn’t restate figures that change outside of docs. Learn more: [crisistextline.org](https://crisistextline.org) # Dian Fossey Gorilla Fund > SOLMEME charity partner: Dian Fossey Gorilla Fund — Science & Research. **Category:** Science & Research The Dian Fossey Gorilla Fund works on conservation and protection of gorillas and habitats — science and conservation for an iconic species, a cause SOLMEME supports. Partner since October 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/dian-fossey-gorilla-fund) — this page doesn’t restate figures that change outside of docs. Learn more: [gorillafund.org](https://gorillafund.org) # Direct Relief > SOLMEME charity partner: Direct Relief — Health & Medical. **Category:** Health & Medical Direct Relief works to improve the health and lives of people affected by poverty or emergencies — delivering medical supplies where they’re needed, a cause SOLMEME supports. Partner since November 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/direct-relief) — this page doesn’t restate figures that change outside of docs. Learn more: [directrelief.org](https://directrelief.org) # Disability Support > SOLMEME charity partners in the Disability Support category. Two of SOLMEME’s fifty partner organizations focus on disability support, including adaptive athletics: * [Easterseals](/docs/ecosystem/charities/easterseals/) * [Special Olympics](/docs/ecosystem/charities/special-olympics/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Disaster Relief > SOLMEME charity partners in the Disaster Relief category. Three of SOLMEME’s fifty partner organizations focus on disaster relief — from emergency fundraising to on-the-ground shelter: * [GlobalGiving](/docs/ecosystem/charities/globalgiving/) * [Team Rubicon](/docs/ecosystem/charities/team-rubicon/) * [ShelterBox](/docs/ecosystem/charities/shelterbox/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Doctors Without Borders > SOLMEME charity partner: Doctors Without Borders — Health & Medical. **Category:** Health & Medical Doctors Without Borders provides medical aid where it’s needed most — crisis medicine delivered with neutrality and urgency, a cause SOLMEME supports. Partner since July 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/doctors-without-borders) — this page doesn’t restate figures that change outside of docs. Learn more: [doctorswithoutborders.org](https://doctorswithoutborders.org) # Easterseals > SOLMEME charity partner: Easterseals — Disability Support. **Category:** Disability Support Easterseals provides support for people with disabilities and special needs — comprehensive care backed by more than a century of service, a cause SOLMEME supports. Partner since February 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/easterseals) — this page doesn’t restate figures that change outside of docs. Learn more: [easterseals.com](https://easterseals.com) # Education > SOLMEME charity partners in the Education category. Four of SOLMEME’s fifty partner organizations focus on education — from literacy and access to books to computer science: * [Room to Read](/docs/ecosystem/charities/room-to-read/) * [Khan Academy](/docs/ecosystem/charities/khan-academy/) * [First Book](/docs/ecosystem/charities/first-book/) * [Code.org](/docs/ecosystem/charities/code-org/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Elderly Care > SOLMEME charity partners in the Elderly Care category. Two of SOLMEME’s fifty partner organizations focus on elderly care, including meal delivery: * [Meals on Wheels America](/docs/ecosystem/charities/meals-on-wheels-america/) * [AARP Foundation](/docs/ecosystem/charities/aarp-foundation/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Environment > SOLMEME charity partners in the Environment category. Five of SOLMEME’s fifty partner organizations focus on the environment — from ocean conservation to reforestation to land protection: * [The Nature Conservancy](/docs/ecosystem/charities/the-nature-conservancy/) * [4ocean](/docs/ecosystem/charities/4ocean/) * [Arbor Day Foundation](/docs/ecosystem/charities/arbor-day-foundation/) * [Ocean Conservancy](/docs/ecosystem/charities/ocean-conservancy/) * [Rainforest Alliance](/docs/ecosystem/charities/rainforest-alliance/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Feeding America > SOLMEME charity partner: Feeding America — Hunger & Food. **Category:** Hunger & Food Feeding America works to feed America’s hungry through a nationwide food bank network — a cause SOLMEME supports for the tangible meals it delivers through that broad network. Partner since December 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/feeding-america) — this page doesn’t restate figures that change outside of docs. Learn more: [feedingamerica.org](https://feedingamerica.org) # First Book > SOLMEME charity partner since May 15, 2024 — First Book provides equal access to quality education for kids in need. Category: Education. **Category:** Education First Book works to provide equal access to quality education for kids in need — a cause SOLMEME supports because books change lives in a simple, measurable way. Partner since May 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/first-book) — this page doesn’t restate figures that change outside of docs. Learn more: [firstbook.org](https://firstbook.org) # Fisher House Foundation > SOLMEME charity partner: Fisher House Foundation — Veterans. **Category:** Veterans Fisher House Foundation provides comfort homes where military families stay while loved ones heal — a cause SOLMEME supports because it keeps families close during medical treatment. Partner since October 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/fisher-house-foundation) — this page doesn’t restate figures that change outside of docs. Learn more: [fisherhouse.org](https://fisherhouse.org) # GlobalGiving > SOLMEME charity partner: GlobalGiving — Disaster Relief. **Category:** Disaster Relief GlobalGiving works to connect donors with grassroots projects worldwide — a cause SOLMEME supports for the flexible funding it provides toward grassroots recovery. Partner since June 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/globalgiving) — this page doesn’t restate figures that change outside of docs. Learn more: [globalgiving.org](https://globalgiving.org) # Guide Dogs for the Blind > SOLMEME charity partner: Guide Dogs for the Blind — Animal Welfare. **Category:** Animal Welfare Guide Dogs for the Blind works to create exceptional partnerships between people, dogs, and communities — a cause SOLMEME supports because service dogs change lives in deeply practical ways. Partner since April 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/guide-dogs-for-the-blind) — this page doesn’t restate figures that change outside of docs. Learn more: [guidedogs.com](https://guidedogs.com) # Habitat for Humanity > SOLMEME charity partner: Habitat for Humanity — Homelessness & Housing. **Category:** Homelessness & Housing Habitat for Humanity works to build strength and stability through shelter — a cause SOLMEME supports because a home changes everything. Partner since November 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/habitat-for-humanity) — this page doesn’t restate figures that change outside of docs. Learn more: [habitat.org](https://habitat.org) # Health & Medical > SOLMEME charity partners in the Health & Medical category. Five of SOLMEME’s fifty partner organizations focus on health and medical care — from crisis medical response to disease-specific care and research: * [Doctors Without Borders](/docs/ecosystem/charities/doctors-without-borders/) * [American Red Cross](/docs/ecosystem/charities/american-red-cross/) * [The ALS Association](/docs/ecosystem/charities/the-als-association/) * [Alzheimer’s Association](/docs/ecosystem/charities/alzheimer-s-association/) * [Direct Relief](/docs/ecosystem/charities/direct-relief/) Donation totals and transaction proofs for these partners live on the [Charities dashboard](https://www.solme.me/charity), not here — figures there update continuously, so this page doesn’t try to restate them. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Heifer International > SOLMEME charity partner: Heifer International — Community Development. **Category:** Community Development Heifer International works to end hunger and poverty through sustainable agriculture — a cause SOLMEME supports because training and livestock create durable self-reliance. Partner since February 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/heifer-international) — this page doesn’t restate figures that change outside of docs. Learn more: [heifer.org](https://heifer.org) # Homelessness & Housing > SOLMEME charity partners in the Homelessness & Housing category. Two of SOLMEME’s fifty partner organizations focus on homelessness and housing — from building homes to providing shelter directly: * [Habitat for Humanity](/docs/ecosystem/charities/habitat-for-humanity/) * [Covenant House](/docs/ecosystem/charities/covenant-house/) Donation totals and transaction proofs for these partners live on the [Charities dashboard](https://www.solme.me/charity), not here — figures there update continuously, so this page doesn’t try to restate them. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Homes For Our Troops > SOLMEME charity partner: Homes For Our Troops — Veterans. **Category:** Veterans Homes For Our Troops works to build specially adapted homes for severely injured veterans — a cause SOLMEME supports because accessible homes restore independence. Partner since November 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/homes-for-our-troops) — this page doesn’t restate figures that change outside of docs. Learn more: [hfotusa.org](https://hfotusa.org) # Hunger & Food > SOLMEME charity partners in the Hunger & Food category. Three of SOLMEME’s fifty partner organizations focus on hunger and food — from food banks to on-the-ground kitchens to campaigns against child hunger: * [Feeding America](/docs/ecosystem/charities/feeding-america/) * [World Central Kitchen](/docs/ecosystem/charities/world-central-kitchen/) * [No Kid Hungry](/docs/ecosystem/charities/no-kid-hungry/) Donation totals and transaction proofs for these partners live on the [Charities dashboard](https://www.solme.me/charity), not here — figures there update continuously, so this page doesn’t try to restate them. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Khan Academy > SOLMEME charity partner: Khan Academy — Education. **Category:** Education Khan Academy offers free world-class education for anyone, anywhere — a cause SOLMEME supports because millions already use it to learn without gatekeepers. Partner since April 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/khan-academy) — this page doesn’t restate figures that change outside of docs. Learn more: [khanacademy.org](https://khanacademy.org) # Kiva > SOLMEME charity partner: Kiva — Community Development. **Category:** Community Development Kiva works to crowdfund loans for underserved communities — a cause SOLMEME supports for the empowerment it creates through access to capital. Partner since January 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/kiva) — this page doesn’t restate figures that change outside of docs. Learn more: [kiva.org](https://kiva.org) # Make-A-Wish Foundation > SOLMEME charity partner: Make-A-Wish Foundation — Children. **Category:** Children Make-A-Wish Foundation works to grant life-changing wishes for children with critical illnesses — a cause SOLMEME supports for the joy it brings families when they need it most. Partner since January 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/make-a-wish-foundation) — this page doesn’t restate figures that change outside of docs. Learn more: [wish.org](https://wish.org) # Meals on Wheels America > SOLMEME charity partner: Meals on Wheels America — Elderly Care. **Category:** Elderly Care Meals on Wheels America works to address senior isolation and hunger — a cause SOLMEME supports through the food delivery and human connection it brings seniors. Partner since December 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/meals-on-wheels-america) — this page doesn’t restate figures that change outside of docs. Learn more: [mealsonwheelsamerica.org](https://mealsonwheelsamerica.org) # Mental Health > SOLMEME charity partners in the Mental Health category. Three of SOLMEME’s fifty partner organizations work in Mental Health — from crisis text support to national mental health advocacy and education: * [Crisis Text Line](/docs/ecosystem/charities/crisis-text-line/) * [NAMI](/docs/ecosystem/charities/nami/) * [Mental Health America](/docs/ecosystem/charities/mental-health-america/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Mental Health America > SOLMEME charity partner: Mental Health America — Mental Health. **Category:** Mental Health Mental Health America works to promote mental health as part of overall wellness — a cause SOLMEME supports because prevention and screening tools reduce harm early. Partner since June 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/mental-health-america) — this page doesn’t restate figures that change outside of docs. Learn more: [mhanational.org](https://mhanational.org) # NAMI > SOLMEME charity partner since May 15, 2024 — NAMI provides mental health education, support, and advocacy. Category: Mental Health. **Category:** Mental Health NAMI provides education, support, and advocacy for mental health — a cause SOLMEME supports for its grassroots mental health support at national scale. Partner since May 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/nami) — this page doesn’t restate figures that change outside of docs. Learn more: [nami.org](https://nami.org) # No Kid Hungry > SOLMEME charity partner: No Kid Hungry — Hunger & Food. **Category:** Hunger & Food No Kid Hungry works to end childhood hunger in America — a cause SOLMEME supports because kids should not have to learn on an empty stomach. Partner since February 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/no-kid-hungry) — this page doesn’t restate figures that change outside of docs. Learn more: [nokidhungry.org](https://nokidhungry.org) # Ocean Conservancy > SOLMEME charity partner: Ocean Conservancy — Environment. **Category:** Environment Ocean Conservancy works to protect the ocean from today’s greatest challenges — a cause SOLMEME supports because clean oceans benefit everyone from surfers to fisheries. Partner since September 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/ocean-conservancy) — this page doesn’t restate figures that change outside of docs. Learn more: [oceanconservancy.org](https://oceanconservancy.org) # Rainforest Alliance > SOLMEME charity partner: Rainforest Alliance — Environment. **Category:** Environment Rainforest Alliance works to create a more sustainable world through responsible business — a cause SOLMEME supports for combining biodiversity and sustainable farming into one mission. Partner since October 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/rainforest-alliance) — this page doesn’t restate figures that change outside of docs. Learn more: [rainforest-alliance.org](https://rainforest-alliance.org) # Room to Read > SOLMEME charity partner: Room to Read — Education. **Category:** Education Room to Read focuses on literacy and girls’ education in low-income communities — a cause SOLMEME supports because education multiplies opportunity for entire communities. Partner since March 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/room-to-read) — this page doesn’t restate figures that change outside of docs. Learn more: [roomtoread.org](https://roomtoread.org) # Save the Children > SOLMEME charity partner: Save the Children — Children. **Category:** Children Save the Children works to give children a healthy start, education, and protection — a cause SOLMEME supports for its global crisis response focused on kids. Partner since December 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/save-the-children) — this page doesn’t restate figures that change outside of docs. Learn more: [savethechildren.org](https://savethechildren.org) # Science & Research > SOLMEME charity partners in the Science & Research category. Two of SOLMEME’s fifty partner organizations work in Science & Research — from the search for extraterrestrial intelligence to gorilla conservation: * [SETI Institute](/docs/ecosystem/charities/seti-institute/) * [Dian Fossey Gorilla Fund](/docs/ecosystem/charities/dian-fossey-gorilla-fund/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # SETI Institute > SOLMEME charity partner: SETI Institute — Science & Research. **Category:** Science & Research SETI Institute searches for extraterrestrial intelligence — a cause SOLMEME supports because big questions inspire scientific curiosity. Partner since September 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/seti-institute) — this page doesn’t restate figures that change outside of docs. Learn more: [seti.org](https://seti.org) # ShelterBox > SOLMEME charity partner: ShelterBox — Disaster Relief. **Category:** Disaster Relief ShelterBox provides emergency shelter for families displaced by disaster — a cause SOLMEME supports because a tangible shelter kit changes the first days after disaster. Partner since August 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/shelterbox) — this page doesn’t restate figures that change outside of docs. Learn more: [shelterbox.org](https://shelterbox.org) # Special Olympics > SOLMEME charity partner: Special Olympics — Disability Support. **Category:** Disability Support Special Olympics provides sports for people with intellectual disabilities — a cause SOLMEME supports for its joy, inclusion, and empowerment through play. Partner since March 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/special-olympics) — this page doesn’t restate figures that change outside of docs. Learn more: [specialolympics.org](https://specialolympics.org) # St. Jude Children's Research Hospital > SOLMEME charity partner: St. Jude Children's Research Hospital — Children. **Category:** Children St. Jude Children’s Research Hospital works to treat and defeat childhood cancer and other diseases — a cause SOLMEME supports because no family pays, and the research helps children everywhere. Partner since November 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/st-jude-children-s-research-hospital) — this page doesn’t restate figures that change outside of docs. Learn more: [stjude.org](https://stjude.org) # Team Rubicon > SOLMEME charity partner: Team Rubicon — Disaster Relief. **Category:** Disaster Relief Team Rubicon is made up of military veterans helping communities prepare and respond to disasters — a cause SOLMEME supports for its veteran service applied to emergency response. Partner since July 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/team-rubicon) — this page doesn’t restate figures that change outside of docs. Learn more: [teamrubiconusa.org](https://teamrubiconusa.org) # The ALS Association > SOLMEME charity partner: The ALS Association — Health & Medical. **Category:** Health & Medical The ALS Association works to fight ALS through research and patient care — a cause SOLMEME supports for its research and support for a devastating disease. Partner since September 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/the-als-association) — this page doesn’t restate figures that change outside of docs. Learn more: [als.org](https://als.org) # The Marine Mammal Center > SOLMEME charity partner: The Marine Mammal Center — Animal Welfare. **Category:** Animal Welfare The Marine Mammal Center rescues and rehabilitates sick or injured marine mammals — a cause SOLMEME supports for its coastal wildlife care and visible recovery stories. Partner since May 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/the-marine-mammal-center) — this page doesn’t restate figures that change outside of docs. Learn more: [marinemammalcenter.org](https://marinemammalcenter.org) # The Nature Conservancy > SOLMEME charity partner: The Nature Conservancy — Environment. **Category:** Environment The Nature Conservancy conserves the lands and waters on which all life depends — a cause SOLMEME supports for its science-based conservation and global reach. Partner since June 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/the-nature-conservancy) — this page doesn’t restate figures that change outside of docs. Learn more: [nature.org](https://nature.org) # The Water Project > SOLMEME charity partner: The Water Project — Clean Water. **Category:** Clean Water The Water Project brings reliable water to communities in sub-Saharan Africa — a cause SOLMEME supports for its community-owned wells and long-term reliability. Partner since May 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/the-water-project) — this page doesn’t restate figures that change outside of docs. Learn more: [thewaterproject.org](https://thewaterproject.org) # UNICEF > SOLMEME charity partner since February 15, 2024 — UNICEF works to help every child survive, thrive, and fulfill potential. Category: Children. **Category:** Children UNICEF works to help every child survive, thrive, and fulfill potential — a cause SOLMEME supports as a global champion for children in crisis. Partner since February 15, 2024. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/unicef) — this page doesn’t restate figures that change outside of docs. Learn more: [unicef.org](https://unicef.org) # Veterans > SOLMEME charity partners in the Veterans category. 3 of SOLMEME’s 50 partner organizations work in Veterans — from wounded-veteran support to housing built for those who served: * [Wounded Warrior Project](/docs/ecosystem/charities/wounded-warrior-project/) * [Fisher House Foundation](/docs/ecosystem/charities/fisher-house-foundation/) * [Homes For Our Troops](/docs/ecosystem/charities/homes-for-our-troops/) For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity) — this page doesn’t restate figures that change outside of docs. ## More Charity Categories [Section titled “More Charity Categories”](#more-charity-categories) [Back to Charities](/docs/ecosystem/charities/) — the full list of all 16 categories. # Water.org > SOLMEME charity partner since April 15, 2023 — Water.org provides safe water and sanitation through affordable financing. Category: Clean Water. **Category:** Clean Water Water.org provides safe water and sanitation through affordable financing — a cause SOLMEME supports for its sustainable water access and practical financing. Partner since April 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/water-org) — this page doesn’t restate figures that change outside of docs. Learn more: [water.org](https://water.org) # Wildlife Conservation Society > SOLMEME charity partner: Wildlife Conservation Society — Animal Welfare. **Category:** Animal Welfare Wildlife Conservation Society protects wildlife and wild places worldwide — a cause SOLMEME supports because iconic species and wild places deserve long-term protection. Partner since March 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/wildlife-conservation-society) — this page doesn’t restate figures that change outside of docs. Learn more: [wcs.org](https://wcs.org) # World Central Kitchen > SOLMEME charity partner: World Central Kitchen — Hunger & Food. **Category:** Hunger & Food World Central Kitchen provides chef-driven disaster relief — a cause SOLMEME supports for its rapid response meals with dignity. Partner since January 15, 2023. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/world-central-kitchen) — this page doesn’t restate figures that change outside of docs. Learn more: [wck.org](https://wck.org) # Wounded Warrior Project > SOLMEME charity partner: Wounded Warrior Project — Veterans. **Category:** Veterans Wounded Warrior Project works to honor and empower wounded veterans — a cause SOLMEME supports through its focus on recovery, mental health, and independence. Partner since September 15, 2025. For current on-chain donation totals and transaction proofs, see the [live Charities dashboard](https://www.solme.me/charity/wounded-warrior-project) — this page doesn’t restate figures that change outside of docs. Learn more: [woundedwarriorproject.org](https://woundedwarriorproject.org) # Communities > Other communities affiliated with SOLMEME — a reserved section, no confirmed list published yet. This section is where communities *outside* SOLMEME’s own — affiliated projects, cross-promotional partners, or other groups with a real, confirmed connection to SOLMEME — would be documented. This is distinct from [SOLMEME’s own community](/docs/community/), which already has its full real structure documented, and from [Partners](/docs/ecosystem/partners/), which covers organizational relationships rather than other communities specifically. ## Where This Section Stands Today [Section titled “Where This Section Stands Today”](#where-this-section-stands-today) No confirmed list of affiliated external communities is published here yet. This section stays an honest placeholder rather than naming communities without a confirmed, real relationship to point to. ## What Belongs Here, Once Populated [Section titled “What Belongs Here, Once Populated”](#what-belongs-here-once-populated) An entry would name the community and state the real, specific connection (a joint event, a shared charity beneficiary, a cross- community collaboration) rather than a vague “part of the SOLMEME ecosystem” claim. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Ecosystem Overview](/docs/ecosystem/) — the full picture, including what is real today * [Community Overview](/docs/community/) — SOLMEME’s own community, fully documented today * [Partners](/docs/ecosystem/partners/) and [Platforms](/docs/ecosystem/platforms/) — the other two reserved directories # Partners > SOLMEME's external partnerships — a reserved section, no confirmed roster published yet. This section is where SOLMEME’s external partnerships would be documented — organizations or projects SOLMEME has a confirmed working relationship with, beyond the charity beneficiaries already covered in [Ecosystem → Charities](/docs/ecosystem/charities/). ## Where This Section Stands Today [Section titled “Where This Section Stands Today”](#where-this-section-stands-today) No confirmed partner roster is published here yet. That’s a real, current gap, not an oversight in how this page is written — this section stays an honest placeholder rather than listing plausible- sounding names until a real partnership is confirmed and ready to document. ## What Belongs Here, Once Populated [Section titled “What Belongs Here, Once Populated”](#what-belongs-here-once-populated) A partner entry would name the organization, describe the actual relationship (what SOLMEME and the partner do together, not just that they’re aware of each other), and — following the same standard the rest of this Ecosystem section holds itself to — be checkable, not just asserted. [Charities](/docs/ecosystem/charities/) is the working example: every one of its 50 entries names a real organization and ties back to a specific, on-chain-verifiable drop via [Contracts](/docs/contracts/). ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Ecosystem Overview](/docs/ecosystem/) — the full picture, including what is real today * [Charities](/docs/ecosystem/charities/) — this section’s one fully-populated, real directory * [Platforms](/docs/ecosystem/platforms/) and [Communities](/docs/ecosystem/communities/) — the other two reserved directories # Platforms > Platforms SOLMEME integrates with — a reserved section, no confirmed list published yet. This section is where the platforms SOLMEME actually integrates with or runs on would be documented — trading venues, wallets, or other infrastructure the token or the community genuinely relies on, distinct from partnerships with organizations (see [Partners](/docs/ecosystem/partners/)) or affiliated communities (see [Communities](/docs/ecosystem/communities/)). ## Where This Section Stands Today [Section titled “Where This Section Stands Today”](#where-this-section-stands-today) No confirmed platform list is published here yet. This section stays an honest placeholder rather than assuming or naming integrations that haven’t been confirmed as real for SOLMEME specifically. ## What Belongs Here, Once Populated [Section titled “What Belongs Here, Once Populated”](#what-belongs-here-once-populated) An entry would name the platform and state the actual, checkable integration (where the [Vault’s Swap](/docs/guides/vault/swap/) mechanism routes through, for example) rather than a generic “SOLMEME works with \[platform]” claim with nothing to verify it against. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Ecosystem Overview](/docs/ecosystem/) — the full picture, including what is real today * [Guides → Vault → Swap](/docs/guides/vault/swap/) — the one real, documented platform-integration mechanic today * [Partners](/docs/ecosystem/partners/) and [Communities](/docs/ecosystem/communities/) — the other two reserved directories # SOLMAMY Docs > SOLMEME's knowledge base — what the project is, how the community runs it, and where to find what you need. ## What SOLMEME Is [Section titled “What SOLMEME Is”](#what-solmeme-is) SOLMEME launched in December 2023 as a community-focused token for Solana enthusiasts — no pre-sale, no VC backing. It grew from a single token into a platform that launches a new meme coin every month, built around whatever trend an AI scan finds breaking through that month. Every launch reserves 5% of proceeds for charity, split across a real roster of [50 partner organizations](/docs/ecosystem/charities/). ## What SOLMEME Community Is [Section titled “What SOLMEME Community Is”](#what-solmeme-community-is) SOLMEME Community is this documentation site’s home — the knowledge and reference layer, separate from the live product (`solme.me`) that runs the actual vault, drops, and meme tools. SOLMEME Community is volunteer-driven: beyond its core team, it runs on the contributions of community members — creators, ambassadors, and moderators — who choose to put in the work. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) I want to understand the project Start with [How SOLMEME Works](/docs/introduction/how-solmeme-works/) and the [FAQ](/docs/introduction/faq/). I want to build or verify something [Contracts](/docs/contracts/) covers SOLMEME’s on-chain smart contracts. I want to participate [Guides](/docs/guides/community/) and [Tutorials](/docs/tutorials/create-your-first-meme/) cover the vault, memes, and community mechanics. I want to learn [Learning](/docs/learning/topics/) covers crypto, Solana, and SOLMEME-specific topics. I want to represent SOLMEME See the [Ambassador Program](/docs/ambassadors/) section. I need brand or media assets [Reference](/docs/reference/) covers the Brand Book, Media Kit, and Mascot. # Community > Day-to-day practices for people already participating in SOLMEME — as distinct from the policy layer and the first-steps guide. This page is for people who are already participating in SOLMEME — not the identity/policy layer ([Community Overview](/docs/community/)), and not the ordered first steps for someone brand new ([Getting Involved](/docs/guides/getting-involved/)). This is what staying involved actually looks like once you’re past day one. ## The Three-Way Split, In Case You Landed Here First [Section titled “The Three-Way Split, In Case You Landed Here First”](#the-three-way-split-in-case-you-landed-here-first) * **[Community Overview](/docs/community/)** — what SOLMEME’s volunteer-driven structure *is*, and the policy pages that govern everyone. * **[Getting Involved](/docs/guides/getting-involved/)** — the ordered steps to start, if you haven’t yet. * **This page** — ongoing practices once you’re already here. ## Staying Involved [Section titled “Staying Involved”](#staying-involved) There’s no single “community track” to follow — day-to-day participation happens through whichever of SOLMEME’s real mechanics you engage with: * **Making content.** [Guides → Content](/docs/guides/content/) covers the general practices that apply across all of SOLMEME’s content pathways (Meme Generator, Meme Wall, Lore); [Guides → Creators](/docs/guides/creators/) has the mechanics themselves. * **Group mechanics.** [Guides → Events](/docs/guides/events/) — Community Raids and Buddy Drops are the real, ongoing ways to participate with others, not one-time scheduled events. * **The Vault.** [Use the Vault](/docs/tutorials/use-the-vault/) is the ongoing core mechanic most participation eventually touches. * **Representing SOLMEME.** The Ambassador Program is a real, planned path — see [Ambassador Program Overview](/docs/ambassadors/) for its current, honest status; it’s still in preparation. * **Missions.** A reserved section for structured participation — see [Guides → Missions](/docs/guides/missions/) for its current status; no mechanic is published yet. ## Staying Safe While You Participate [Section titled “Staying Safe While You Participate”](#staying-safe-while-you-participate) The practical safety guidance in [Guides → Security](/docs/guides/security/) isn’t a one-time read for newcomers — scam patterns target established participants too, especially anyone visibly active (creators, raid organizers, anyone posting in public channels). Re-checking [Verify an Official Account](/docs/tutorials/verify-an-official-account/) before connecting a wallet to anything new is good practice regardless of how long you’ve been around. ## If Something Goes Wrong [Section titled “If Something Goes Wrong”](#if-something-goes-wrong) If you see behavior that violates community norms, or something that looks like a scam or impersonation attempt: the practical policy pages covering moderation and reporting ([Moderation](/docs/community/moderation/), [Reporting](/docs/community/reporting/)) are drafted but not yet published pending review — until they are, the fastest real path is the [Discord](https://discord.gg/solmeme) itself, where moderators are directly reachable. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Community Overview](/docs/community/) — the identity and structure this page assumes * [Getting Involved](/docs/guides/getting-involved/) — if you haven’t started yet * [Guides → Security](/docs/guides/security/) — practical safety steps * [Use the Vault](/docs/tutorials/use-the-vault/) — the core ongoing mechanic # Content > Where SOLMEME's real content pathways live, and general practices that apply across all of them. SOLMEME community content isn’t made through one central pipeline — it’s made through specific, existing pathways, each with its own mechanic. This page orients you to where those pathways live and the general practices that apply across all of them; it doesn’t restate any one pathway’s own instructions. ## Where the Real Content Pathways Are [Section titled “Where the Real Content Pathways Are”](#where-the-real-content-pathways-are) * **[Guides → Creators](/docs/guides/creators/)** — memes ([Meme Generator](/docs/guides/creators/meme-generator/)), the [Meme Wall](/docs/guides/creators/meme-wall/) leaderboard, and the recurring [Lore](/docs/guides/creators/lore/) (Council of Cats) — SOLMEME’s actual, built content mechanics today. * **[Tutorials → Create Community Content](/docs/tutorials/create-community-content/)** — a concrete, step-by-step walkthrough of the real pathway above, if you want the exact steps rather than the overview. Everything on this page is a general practice layered on top of those real mechanics, not a separate content system. ## General Practices [Section titled “General Practices”](#general-practices) * **Attribution and originality.** Credit sources you build on (a template, a reference image, another creator’s idea) rather than presenting someone else’s work as your own — the same norm as any creative community. * **Read the mechanic’s own page first.** Meme Generator, Meme Wall, and Lore each have their own specific format and current rules — this page intentionally doesn’t duplicate those details, since they change independently of general practice. * **Don’t state SOLMEME facts you’re not sure of.** If a piece of content makes a factual claim about SOLMEME (a mechanic, a date, a number), check it against this documentation site rather than repeating something you saw elsewhere — the same standard this site holds itself to. * **Brand consistency** — logo usage, color, tone of voice — is covered by [Reference](/docs/reference/) once its content is published; that section is still pending sign-off today, so there’s no confirmed brand spec to link to yet. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Guides → Creators](/docs/guides/creators/) — the real content mechanics * [Tutorials → Create Community Content](/docs/tutorials/create-community-content/) — the concrete walkthrough * [Community Overview](/docs/community/) — how content fits into SOLMEME’s wider volunteer-driven structure # Creators > How to make and share things in the SOLMEME community — memes, the Meme Wall, and the Council of Cats lore. Practical instructions for making and sharing SOLMEME community content — memes, wall submissions, and the recurring in-universe lore that ties monthly drops together. ## Guides in This Section [Section titled “Guides in This Section”](#guides-in-this-section) * **[Lore](/docs/guides/creators/lore/)** — the Council of Cats, SOLMEME’s recurring cast and community mythology. * **[Meme Generator](/docs/guides/creators/meme-generator/)** — pick a template, write a caption, and share it. * **[Meme Wall](/docs/guides/creators/meme-wall/)** — submit a meme, climb the wall, and compete for Meme of the Month. All three connect to the same mechanic: share-to-earn XP. Exact XP values change and aren’t documented here — see each page’s own notes. # Lore > The Council of Cats — SOLMEME's recurring in-universe cast and community mythology. SOLMEME’s cats aren’t mascots — they’re a recurring cast that turns drops, vaults, raids, and holder rituals into shared community canon. ## Origin Story [Section titled “Origin Story”](#origin-story) An owl figure — tied to prediction and foresight — is framed as the origin of the myth: seeing trends before they broke, turning them into memes. Each monthly drop added another piece to the story, until the community formed its own cast of characters to represent the different sides of the platform. ## The Council of Cats [Section titled “The Council of Cats”](#the-council-of-cats) Laser Cat **Signal caller** — sees trend lines before they hit the timeline. Vault Cat **Keeper of grids** — counts every combo and refuses to leak the final square. Moon Cat **Morale officer** — posts one unreasonable target before breakfast. Sword Cat **Rug defense** — cuts through fake FUD and suspicious launch drama. ## Community In-Jokes [Section titled “Community In-Jokes”](#community-in-jokes) A running gag in the community counts drops that pass “without a rug” — a lighthearted, ongoing bit that shows up across SOLMEME’s social content, not an official metric. A few community copy-paste templates circulate around the lore: * “ser the cat did not choose the vault. the vault blinked first.” * “monthly drop. diamond paws. grid full. charity paid. timeline confused.” * “day 404 without a rug and the council is still arguing about snacks.” Sharing Community members can share lore content for XP as part of SOLMEME’s broader share-to-earn mechanic — exact point values change and aren’t documented here. Open question Whether “Oracle Owl” is the official mascot of the current drop is a separate, still-open question — see [Reference → Mascot](/docs/reference/mascot-book/) for the canonical answer once resolved. This page describes the origin-story character as the source frames it, not as a confirmed mascot designation. # Meme Generator > How SOLMEME's meme generator turns a template and caption into a shareable meme, and how it feeds into the monthly mint pipeline. Pick a SOLMEME template, write a caption, and share the result. The best community submissions get queued for the Meme of the Month pipeline. ## How It Works [Section titled “How It Works”](#how-it-works) Top shared memes enter community voting for homepage placement and mint consideration. Sharing a meme you’ve made earns XP as part of SOLMEME’s broader share-to-earn mechanic — exact XP amounts change and aren’t documented here. Current queue depth, share counts, and this month’s shortlisted memes change continuously; see the [live Meme Generator](https://www.solme.me/meme-generator) to create one or see what’s trending. This page covers the mechanism, not a point-in-time snapshot of it. ## More Creators Pages [Section titled “More Creators Pages”](#more-creators-pages) * [Meme Wall](/docs/guides/creators/meme-wall/) — where community memes climb toward Meme of the Month * [Lore](/docs/guides/creators/lore/) — the Council of Cats and SOLMEME’s in-universe cast # Meme Wall > How the community Meme Wall works — memes climb by votes, and the monthly winner earns SOL plus a homepage feature. Community memes climb the wall through upvotes, shares, and raid energy. The monthly winner earns 0.5 SOL plus a homepage feature slot. ## How It Works [Section titled “How It Works”](#how-it-works) Anyone can submit a meme (generated with the [Meme Generator](/docs/guides/creators/meme-generator/)) for moderation, wall placement, XP credit, and monthly voting. The current leaderboard, vote counts, and this month’s leading meme change continuously; see the [live Meme Wall](https://www.solme.me/meme-wall) for the current standings. This page covers the mechanism, not a point-in-time snapshot of it. ## More Creators Pages [Section titled “More Creators Pages”](#more-creators-pages) * [Meme Generator](/docs/guides/creators/meme-generator/) — create the meme that goes on the wall * [Lore](/docs/guides/creators/lore/) — the Council of Cats and SOLMEME’s in-universe cast # Events > How group participation works in SOLMEME today, and where to find what's currently happening. SOLMEME doesn’t run a fixed calendar of scheduled events — group participation here mostly takes the form of ongoing mechanics you can join whenever they’re active, not one-time dated events you have to plan around. ## The Real Group Mechanics Today [Section titled “The Real Group Mechanics Today”](#the-real-group-mechanics-today) * **[Community Raids](/docs/guides/vault/community-raids/)** — form or join a squad, pool your holdings toward a shared vault target, and split the loot when the raid completes. * **[Buddy Drops](/docs/guides/vault/buddy-drops/)** — pair up with one other wallet to unlock a vault neither of you could claim alone. Both work the same way: the mechanic itself is permanent and documented here; which specific raids/pairs are active right now changes continuously — see each page’s own link to the live Vault for that. ## Where “What’s Happening Right Now” Actually Lives [Section titled “Where “What’s Happening Right Now” Actually Lives”](#where-whats-happening-right-now-actually-lives) This page documents how participation works, not a point-in-time list of what’s currently running. For what’s active today, check the live [Vault](https://www.solme.me/vault) or ask in the real [Discord](https://discord.gg/solmeme) — the fastest way to learn about anything currently forming. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Getting Involved](/docs/guides/getting-involved/) — the full set of ways to start participating * [Use the Vault](/docs/tutorials/use-the-vault/) — the tutorial covering these mechanics step by step * [Join the Discord](/docs/tutorials/join-the-discord/) — where live activity is actually announced # Getting Involved > The concrete, ordered first steps to start participating in SOLMEME today. [Community Overview](/docs/community/) explains what SOLMEME’s volunteer-driven structure means. This page is the practical counterpart — the concrete, ordered steps to actually start, today. ## 1. Join the Discord [Section titled “1. Join the Discord”](#1-join-the-discord) Discord is where SOLMEME’s community actually happens — announcements, discussion, and where moderators are reachable. Start here: [Join the Discord](/docs/tutorials/join-the-discord/). ## 2. Learn to Recognize the Real Channels [Section titled “2. Learn to Recognize the Real Channels”](#2-learn-to-recognize-the-real-channels) Before you follow links or trust an account claiming to be SOLMEME, know what “real” looks like: [Verify an Official Account](/docs/tutorials/verify-an-official-account/). Five minutes now avoids the most common way newcomers get scammed in any crypto community. ## 3. Pick a Way to Participate [Section titled “3. Pick a Way to Participate”](#3-pick-a-way-to-participate) There’s more than one real path, depending on what you want to do: * **Make content.** Memes, Meme Wall submissions, or the Council of Cats lore — see [Guides → Creators](/docs/guides/creators/) for the concrete mechanics, or [Create Community Content](/docs/tutorials/create-community-content/) for a step-by-step walkthrough. * **Engage with the Vault.** Hold SOLMEME, check your reward tier, and track the Grid — see [Use the Vault](/docs/tutorials/use-the-vault/). * **Represent SOLMEME as an Ambassador.** The Ambassador Program is a real, planned path, but its specific requirements and application process aren’t documented yet — see [Ambassador Program Overview](/docs/ambassadors/) for its current, honest status. ## What’s Not Documented Yet [Section titled “What’s Not Documented Yet”](#whats-not-documented-yet) Missions and Events are reserved sections in this same Guides area — real categories, no published content yet. This page doesn’t send you to them as if they already have instructions; when they do, they’ll appear here as additional ways to get involved. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Join the Discord](/docs/tutorials/join-the-discord/) * [Verify an Official Account](/docs/tutorials/verify-an-official-account/) * [Guides → Creators](/docs/guides/creators/) * [Use the Vault](/docs/tutorials/use-the-vault/) * [Community Overview](/docs/community/) — the identity and structure behind these steps # Missions > Structured, goal-based participation — reserved section, no published mechanic yet. Missions is a reserved section for structured, goal-based participation in SOLMEME — separate from the ongoing, open-ended mechanics covered in [Guides → Events](/docs/guides/events/) (Community Raids, Buddy Drops). It already appears as a planned category in [Getting Involved](/docs/guides/getting-involved/) and [Guides → Community](/docs/guides/community/). Content In Preparation No real Missions mechanic exists yet — not a rules document, not a reward structure, not a worked example. This page will describe the actual mechanic once it’s confirmed; until then, nothing below states an invented rule as real. See `doc/Daria/tasks/DARIA-MISSIONS-01.md` for what’s being requested. ## What This Will Cover, Once Defined [Section titled “What This Will Cover, Once Defined”](#what-this-will-cover-once-defined) * What a “mission” actually is here — a task, a challenge, a goal-tracked activity — and how it differs from the open-ended mechanics in Events. * Who creates/assigns missions and how they’re completed. * Whether there’s a reward or recognition structure, and what it is. * How this relates to the Ambassador Program, if the two turn out to share a task system. ## Current Status [Section titled “Current Status”](#current-status) Not published. This isn’t a broken link — the section is reserved and real, but the mechanic itself hasn’t been confirmed. Check [Guides → Getting Involved](/docs/guides/getting-involved/) for SOLMEME’s currently real ways to participate in the meantime. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Guides → Getting Involved](/docs/guides/getting-involved/) — real, currently available ways to participate * [Guides → Events](/docs/guides/events/) — the real, ongoing group mechanics today * [Ambassador Program Overview](/docs/ambassadors/) — a related section, also in preparation # Security > Practical steps to protect your wallet and recognize scams — how to act safely, not the policy statement. This page is the **how-to**: practical steps for protecting yourself around SOLMEME and crypto generally. [Community → Safety](/docs/community/safety/) is the **policy** — SOLMEME’s stated position on community-facing risks like scams and impersonation. That page isn’t published yet; this one doesn’t wait on it, because none of the guidance below depends on a policy decision — it’s the same practical safety knowledge that applies across crypto communities. ## Protecting Your Wallet [Section titled “Protecting Your Wallet”](#protecting-your-wallet) * **Never share your seed phrase or private key with anyone**, for any reason. No legitimate support account, moderator, or “verification process” will ever ask for it. Anyone who does is not who they claim to be. * **Only connect your wallet through official links.** Use [Verify an Official Account](/docs/tutorials/verify-an-official-account/) to confirm a link is real before you connect anything to it — a fake site that looks identical to a real one is one of the most common ways wallets get drained. * **A hardware wallet or a dedicated “hot” wallet with limited funds** reduces what’s at risk if something does go wrong — a general crypto best practice, not specific to SOLMEME. ## Recognizing Scam Patterns [Section titled “Recognizing Scam Patterns”](#recognizing-scam-patterns) Scammers rarely invent something new — the same handful of patterns resurface across crypto projects generally, not just SOLMEME. Learning to recognize the pattern matters more than memorizing any one specific scam: * **Unsolicited contact offering help, a giveaway, or “early access.”** Official accounts don’t DM first. If it can find you, be suspicious of it before you’re curious about it. * **Urgency and fear.** “Act now or lose your funds,” “your wallet will be locked” — pressure is the tactic, not a real deadline. * **A near-identical account or link.** Same logo, similar handle, wrong URL. See [Verify an Official Account](/docs/tutorials/verify-an-official-account/) for exactly how to check. * **A request to “verify” your wallet by connecting it or sending a small amount first.** There’s no legitimate reason a support interaction requires either. ## Verifying You’re on a Real SOLMEME Channel [Section titled “Verifying You’re on a Real SOLMEME Channel”](#verifying-youre-on-a-real-solmeme-channel) Full step-by-step process: [Verify an Official Account](/docs/tutorials/verify-an-official-account/). Short version — this documentation site’s own [official channel list](/docs/tutorials/verify-an-official-account/#the-real-official-channels) is the reference; check the exact URL character-by-character against it, not just the display name. ## If Something Looks Wrong [Section titled “If Something Looks Wrong”](#if-something-looks-wrong) Flag it to a moderator in the real [Discord](https://discord.gg/solmeme) — that’s the fastest, real reporting path today. A formal Community → Safety policy and a dedicated [Reporting](/docs/community/reporting/) process are planned, not published yet. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Verify an Official Account](/docs/tutorials/verify-an-official-account/) — the full verification walkthrough * [Join the Discord](/docs/tutorials/join-the-discord/) — using the real, verified invite link * [Community Overview](/docs/community/) — SOLMEME’s community structure and policy layer # Vault > How the SOLMEME Vault works — combine held drops to unlock reward tiers from Common to Mythic, plus Duo, Raid, Guild, Hunt, and Grand community vaults. Every SOLMEME drop you hold acts as a key. Combine keys and you unlock Vault rewards — the more you hold, the rarer the door you can reach. ## How the Vault Works [Section titled “How the Vault Works”](#how-the-vault-works) 1. **Collect each drop.** Every SOLMEME drop becomes a key candidate. Hold it in your wallet and the Vault reads your collection. 2. **Combine your keys.** A single token opens starter cells. Stronger combinations of held drops unlock rarer doors. 3. **Claim your rewards.** When your wallet matches a Vault recipe, claim the prize and take your place on the [Treasure Grid](/docs/guides/vault/grid/). ## Reward Tiers [Section titled “Reward Tiers”](#reward-tiers) Rewards scale with how many distinct drops you hold at once: | Tier | Tokens held | Typical rewards | | --------- | ----------- | ----------------------------------------------------------- | | Common | 1–2 | Bonus SOLMEME, starter badges, early code drops | | Rare | 3–5 | Boosted airdrops, allowlist chances, small SOL pools | | Epic | 6–9 | Exclusive NFTs, governance boosts, larger token prizes | | Legendary | 10–15 | Premium raffles, rare artifacts, major SOLMEME rewards | | Mythic | 16+ | Grand Vault access, mythic badges, top-tier mystery rewards | ## Reward Types [Section titled “Reward Types”](#reward-types) Vault rewards come in many forms, not just SOLMEME tokens: SOLMEME bonuses, SOL prizes, NFT artifacts, allowlist spots, governance power, airdrop boosts, profile badges, merch credits, partner perks, raid pools, mystery boxes, and Grand Vault entries. ## Community Vaults [Section titled “Community Vaults”](#community-vaults) Beyond solo claims, SOLMEME’s Vault includes several community-vault formats, each shaped differently: Duo Two wallets pair keys and split the claim. [Buddy Drops](/docs/guides/vault/buddy-drops/) is this mechanic. Raid Small groups coordinate matching drops for shared loot. Guild Long-running teams build treasury-level combinations. Hunt Timed clue routes send collectors after specific key sets. Grand Monthly endgame vaults reserved for elite collections. See the [Grand Vault](/docs/guides/vault/grand-vault/). Flash Short windows, fast claims, sudden bonus rewards. Live vault status, wallet holdings, the leaderboard, and expiring/claimable doors change continuously — see the [live Vault](https://www.solme.me/vault) for your current position; this page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Treasure Grid](/docs/guides/vault/grid/) — the full 36-cell map of every door * [Buddy Drops](/docs/guides/vault/buddy-drops/) — combine two wallets to unlock a vault neither could claim alone * [Grand Vault](/docs/guides/vault/grand-vault/) — the monthly endgame prize * [Vault Keys](/docs/guides/vault/keys/) — how keys substitute for missing tokens * [Swap SOLMEME](/docs/guides/vault/swap/) — the fastest way to get SOLMEME to start collecting * [Community Raids](/docs/guides/vault/community-raids/) — squad up and pool progress toward a shared vault * [Vault Settings](/docs/guides/vault/settings/) — control which Vault notifications you receive * [Whale Tracker](/docs/guides/vault/whale-tracker/) — real-time large-transaction monitoring * [Prediction Tokens](/docs/guides/vault/predictions/) — stake on which vault unlocks next * [Buyback Vouchers](/docs/guides/vault/vouchers/) — how claimed vaults feed back into SOL buyback pressure Content gap The Vault’s own FAQ section lists 10 question headings (e.g. “How are combinations generated?”, “What happens if I sell a token?”) but the crawled source captured no answer text under any of them — the answers render client-side and weren’t in what was fetched. Not migrated here rather than invented; worth a follow-up crawl pass before this FAQ can be written. # Buddy Drops > Two wallets, one vault — how Buddy Drops let two holders combine tokens to unlock a vault neither could claim alone. Some vault doors need two sets of keys. Buddy Drops let two wallets combine their held tokens to unlock a vault that neither wallet could claim on its own, splitting the reward between them. ## How Buddy Drops Work [Section titled “How Buddy Drops Work”](#how-buddy-drops-work) 1. **Share your link.** Generate your unique referral link and share it with someone who holds the tokens you’re missing. 2. **Match and unlock.** When two wallets combine their held tokens, a vault becomes unlockable. Both parties must approve. 3. **Split rewards.** Rewards are split 50/50 between both wallets. Which specific Buddy Drops are currently open, matched, or claimed — along with creator wallets, partner status, and invite codes — changes continuously; see the [live Buddy Drops](https://www.solme.me/vault/buddy) for the current list. This page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what a key is and how tiers work * [Treasure Grid](/docs/guides/vault/grid/) — the full 36-cell map of every door # Community Raids > Squad up with other holders and pool progress toward a shared vault target. Some treasures require a crew. Community Raids let a group of holders form a squad, target a specific vault together, and pool their combined discovery toward unlocking it — sharing the loot when it opens. ## How Community Raids Work [Section titled “How Community Raids Work”](#how-community-raids-work) 1. **Create or join a squad.** Pick a target vault and give your squad a name, or join one that’s already forming around a vault you want. 2. **Pool progress together.** Every squad member’s holdings count toward the shared raid — progress moves as more wallets join and contribute. 3. **Win and split loot.** When a squad’s raid completes, the loot is shared across the squad that pooled it. Which raids are currently active, squad membership, raid progress, and the squad leaderboard change continuously; see the [live Community Raids](https://www.solme.me/vault/community) for the current list. This page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — the “Raid” community-vault type this page documents * [Grand Vault](/docs/guides/vault/grand-vault/) — the monthly endgame vault, a different community-scale target # Grand Vault > The Grand Vault — SOLMEME's monthly endgame prize, and what it takes to qualify. Once a month, one vault, one winner. The Grand Vault is SOLMEME’s endgame prize — reserved for wallets holding every one of that month’s drops at once. ## Prize Pool [Section titled “Prize Pool”](#prize-pool) The Grand Vault prize isn’t a single payout — it spans four parts: SOL Pool A large monthly headline pool — the exact amount varies month to month. Unique NFT A one-of-one vault relic, unique to that month’s winner. Badge A permanent Grand Winner mark on the winner’s profile. Revenue Share A protocol revenue-share perk allocation. ## Qualifying [Section titled “Qualifying”](#qualifying) Qualifying for the Grand Vault means holding every drop released that month at once — not just one or two. Your current holdings, how many of that month’s drops you’re missing, and the countdown to the next draw all change continuously; see the [live Grand Vault](https://www.solme.me/vault/grand) for your current status. This page covers the mechanism, not a point-in-time snapshot of it. ## Past Winners [Section titled “Past Winners”](#past-winners) | Month | Winner | Prize | | ---------- | --------- | ----------------------- | | May 2026 | 7xK9…aB3F | 18K SOL + Relic #01 | | April 2026 | Dx9m…Qp21 | 14K SOL + Founder Badge | | March 2026 | H4Lq…9zVz | 11K SOL + Revenue Share | Freshness This is a historical record as of when this page was written, not a live leaderboard — it isn’t re-checked automatically. Revisit as new months close out. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what a key is and how tiers work * [Vault Keys](/docs/guides/vault/keys/) — how keys substitute for missing tokens toward vaults like this one # Treasure Grid > How the Vault's 36-cell treasure grid is organized and how to read it. The Treasure Grid is the Vault laid out as a 6×6 map — 36 cells, six per tier. Each cell is a door with its own key requirement, tier, and reward pool. Holding one drop starts a route; pairs and sets create combos; the rarest cells demand deeper holds. ## Grid Tiers [Section titled “Grid Tiers”](#grid-tiers) The Grid uses its own tier names, distinct from the Common → Mythic scale used on the main [Vault](/docs/guides/vault/) page — both describe the same six-step reward ladder, just labeled differently depending on which part of the app you’re in: * **Fodder** — entry-level doors, single-token holds * **Squire** * **Knight** * **Lord** * **Dragon** * **Mythic** — the top tier, matching “Mythic” on the main Vault page Each tier holds six vaults (36 total). Some cells stay undiscovered until SOLMEME deploys them. ## Reading the Grid [Section titled “Reading the Grid”](#reading-the-grid) * **Filter and search** by vault name, tier, or status (unlockable now, holding in progress, claimed, expired, undiscovered). * **Sort** by closest-to-unlock, highest reward, newest first, or tier. * Cells marked **Flash** run on a limited-time entry window rather than staying open indefinitely. Which specific cells are open, your own keys-held count, current rewards, and flash countdown timers all change continuously — see the [live Treasure Grid](https://www.solme.me/vault/grid) for your current position; specific vault names, per-cell reward amounts, and the wallet leaderboard shown there are live state, not documented here. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what a key is and how tiers work # Vault Keys > What a Vault key is and how higher-tier keys substitute for missing tokens. Every drop you hold is a key. Keys can substitute for tokens you’re missing toward a vault’s requirements — a higher-tier key covers more ground than a lower-tier one. ## Key Substitution Rules [Section titled “Key Substitution Rules”](#key-substitution-rules) | Key tier | Substitutes for | | --------- | --------------------------------------- | | Mythic | Any token in any vault | | Legendary | Legendary, Epic, Rare, or Common tokens | | Epic | Epic, Rare, or Common tokens | | Rare | Rare or Common tokens | | Common | Common tokens only | Your own key inventory — which keys you hold, when you obtained them, and whether each has already been used — changes continuously; see the [live Vault Keys](https://www.solme.me/vault/keys) for your current inventory. This page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what a key is and how reward tiers work * [Grand Vault](/docs/guides/vault/grand-vault/) — the monthly endgame vault keys can help you qualify for # Prediction Tokens > Stake prediction tokens, vote on Vault-related outcomes, and guess next month's drop for free allocation. Prediction Tokens let holders stake on the outcome of Vault-related questions — which vault unlocks next, whether a mythic door gets discovered this month, which squad wins a raid — and earn based on how the market resolves. ## How Prediction Markets Work [Section titled “How Prediction Markets Work”](#how-prediction-markets-work) 1. **Stake on an outcome.** Each active market lists possible outcomes with a payout multiplier and the current vote share for each — stake prediction tokens on the one you think is right. 2. **Markets resolve.** Once the real outcome is known, the market closes as Resolved and winning stakes pay out according to their multiplier. 3. **Guess next month’s drop.** Separately, the community votes on themed guesses for next month’s drop; the top-voted theme becomes the mock front-runner, competing for free allocation, not a staked market. Which markets are currently open, pool sizes, vote shares, and the top-predictor leaderboard change continuously; see the [live Prediction Tokens](https://www.solme.me/vault/predictions) for the current state. This page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what a “vault unlocking” (the subject of most prediction markets) actually means * [Community Raids](/docs/guides/vault/community-raids/) — another squad-vs-market mechanic prediction questions sometimes reference # Vault Settings > Control which Vault notifications you receive and how they're delivered. The Vault’s Settings page controls notification preferences — what you’re alerted about, and whether you get browser push notifications in addition to in-app alerts. ## Notification Categories [Section titled “Notification Categories”](#notification-categories) * **Vault Claims** — notified when you unlock or claim a vault reward. * **Whale Alerts** — track large transactions and accumulation patterns. * **Drop Reminders** — reminders before new monthly drops go live. * **Price Alerts** — notifications when SOLMEME hits price targets. Push notifications are opt-in — enable them from the Settings page to get alerts even when you’re not on the site. Preferences are saved locally in your browser, not tied to your wallet or account. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what triggers a claim notification * [Whale Tracker](/docs/guides/vault/whale-tracker/) — the large-transaction monitoring that Whale Alerts are based on # Swap SOLMEME > How to get SOLMEME — an embedded Jupiter swap widget with no platform fee. The fastest way to get SOLMEME is the swap widget embedded directly on the live site, powered by [Jupiter](https://jup.ag) — best-price routing and MEV protection, with no SOLMEME platform fee. Using the swap means agreeing to Jupiter’s own [terms of service](https://station.jup.ag/legal/terms), separate from SOLMEME’s own terms. See the [live Swap page](https://www.solme.me/vault/swap) to use it — the widget itself only renders client-side and isn’t part of this documentation. # Buyback Vouchers > Claimed vaults mint buyback vouchers — redeeming one triggers real SOL buyback pressure. Claiming a vault mints a Buyback Voucher. Redeeming that voucher triggers real SOL buy pressure on the market — vouchers are how vault claims feed back into SOLMEME’s token economics, not just a personal reward record. ## Voucher Status [Section titled “Voucher Status”](#voucher-status) Each voucher moves through one of three states: * **Active** — claimed, not yet redeemed. * **Redeemed** — buyback pressure has been applied. * **Expired** — the redemption window closed before the voucher was claimed. Your own voucher list — which vaults minted them, their SOL value, and current status — changes continuously; see the [live Buyback Vouchers](https://www.solme.me/vault/vouchers) for your current vouchers. This page covers the mechanism, not a point-in-time snapshot of it. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — what claiming a vault door actually unlocks * [Prediction Tokens](/docs/guides/vault/predictions/) — another token-staking mechanic within the Vault # Whale Tracker > Real-time monitoring of large SOLMEME transactions — who's accumulating, distributing, and moving volume. The Whale Tracker monitors large SOLMEME transactions in real time, so holders can see who’s accumulating, who’s distributing, and how much volume is moving. ## Transaction Tiers [Section titled “Transaction Tiers”](#transaction-tiers) Transactions are filtered by size: **Minnow**, **Whale**, and **Mega** — smallest to largest. Live transaction data (specific wallets, amounts, and accumulation/distribution patterns) changes continuously and requires a live feed to render; see the [live Whale Tracker](https://www.solme.me/vault/whales) for current activity. This page covers the mechanism, not a point-in-time snapshot of it. Source gap The crawled source for this page captured only the mechanism description and tier filters above — the live transaction feed itself failed to load during the crawl (`Failed to fetch`), so no example transaction data exists to describe further here. Not invented — worth a follow-up crawl pass if more detail is needed. ## More Vault Pages [Section titled “More Vault Pages”](#more-vault-pages) * [Vault Overview](/docs/guides/vault/) — how held tokens translate into Vault standing * [Vault Settings](/docs/guides/vault/settings/) — where Whale Alert notifications are configured # FAQ > Answers on how to buy a drop, launch fairness, charity allocation, drop schedule, fees, and who's behind SOLMEME. ## What is SOLMEME? [Section titled “What is SOLMEME?”](#what-is-solmeme) A community-driven platform that launches a curated meme coin on the 1st of every month on Solana, based on trending topics, with 5% going to charity. ## How do I buy a drop? [Section titled “How do I buy a drop?”](#how-do-i-buy-a-drop) Connect your Solana wallet (Phantom, Solflare, etc.), click “Ape In,” pick your amount, and confirm. Need SOL first? Swap on Jupiter. ## Is this a rug pull? [Section titled “Is this a rug pull?”](#is-this-a-rug-pull) No. Each token is a fair launch on Pump.fun, with no team allocation, no premine, and authorities revoked. Everything is published on-chain so buyers can verify before trading. ## Where does the charity money go? [Section titled “Where does the charity money go?”](#where-does-the-charity-money-go) 5% of launch proceeds go to one of SOLMEME’s 50 verified non-political charities. Every donation is published with transaction links. ## What time is the next drop? [Section titled “What time is the next drop?”](#what-time-is-the-next-drop) 12:00 UTC on the 1st of every month. Exact details are announced in Discord and Telegram. ## What if I miss the launch? [Section titled “What if I miss the launch?”](#what-if-i-miss-the-launch) You can still buy on DEXs after launch, or wait for the next drop on the 1st. ## How are trends selected? [Section titled “How are trends selected?”](#how-are-trends-selected) An AI process scans social media and news, then scores candidates by virality, meme-ability, timing, and community readiness. The top-scoring trend wins. See [How SOLMEME Works](/docs/introduction/how-solmeme-works/) for the full mechanism. ## Are there any fees? [Section titled “Are there any fees?”](#are-there-any-fees) Standard DEX swap fees, plus a small platform fee. 5% goes to charity. ## Who’s behind this? [Section titled “Who’s behind this?”](#whos-behind-this) The original SOLMEME team, active since 2023, plus newer contributors. See [the SOLMEME story](/docs/learning/topics/solmeme/) for the full team. Not financial advice DYOR. Meme coins are highly volatile. Past performance doesn’t guarantee future results. Never invest more than you can afford to lose. # How SOLMEME Works > SCAN, SCORE, SELECT, CREATE, AMPLIFY, GIVE — how the platform turns a trend into a token. SOLMEME turns an internet trend into a token every month. The six stages below are performed by SOLMEME’s own process and AI tooling, not by the reader — this page explains the mechanism, it isn’t a set of instructions to follow. ## Scan [Section titled “Scan”](#scan) The platform monitors Twitter/X, Reddit, TikTok, and news sites for what’s gaining traction — what’s being talked about, and what looks like it’s about to break through. ## Score [Section titled “Score”](#score) Every trend found in the scan is rated on virality, meme-ability, timing, and community energy. Only the highest-scoring trend is picked. ## Select [Section titled “Select”](#select) The top-scoring trend wins — selection is data-driven, not a human editorial call. The winning trend becomes the basis for that month’s meme. ## Create [Section titled “Create”](#create) Name, artwork, contract, and liquidity are deployed on Solana within minutes of selection, ready for that month’s drop. ## Amplify [Section titled “Amplify”](#amplify) SOLMEME’s community — over 3,305 members — spreads the word once a token launches, across Telegram and Twitter. ## Give [Section titled “Give”](#give) 5% of every launch goes to one of SOLMEME’s 50 verified non-political charities, tracked on-chain. ## Related [Section titled “Related”](#related) * [FAQ](/docs/introduction/faq/) — common questions about buying, timing, and the charity mechanism * [Ecosystem Archive](/docs/ecosystem/archive/) — the historical record of past drops this process has produced # What is a Memecoin? > A quick orientation to the memecoin category — the short version, with the full explainer linked. A memecoin is a [cryptocurrency](/docs/learning/topics/crypto/) whose primary identity is cultural — built around a joke, a meme, or a community identity — rather than a specific technical utility. That doesn’t mean a memecoin can’t have real mechanics; it means the reason people first pay attention is usually the culture and community, not a whitepaper’s technical claims. ## The Short Version [Section titled “The Short Version”](#the-short-version) * **Community and culture come first** — the technical mechanics, if any, are built on top of that identity, not the other way around. * **The category varies wildly in substance** — some projects are a ticker with no follow-through; others build real, ongoing mechanics on top of the initial joke. * **What separates the two**: does a real community actually exist, does the project ship mechanics that hold up under use, and can claims be verified on-chain instead of taken on faith. ## Where SOLMEME Fits [Section titled “Where SOLMEME Fits”](#where-solmeme-fits) SOLMEME launched as a memecoin and has built real, ongoing mechanics since — see [What is SOLMEME?](/docs/introduction/what-is-solmeme/) for the short version of that story, or [Learning → Topics → Memecoins](/docs/learning/topics/memecoins/) for the full explainer this page summarizes, including where SOLMEME specifically fits the category. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) New to crypto more broadly, not just memecoins? Start with [Crypto](/docs/learning/topics/crypto/) for the underlying asset class. Ready to see SOLMEME’s own story? [What is SOLMEME?](/docs/introduction/what-is-solmeme/) covers that. # What is SOLMEME? > A quick orientation to what SOLMEME is — the short version, with the full story linked. SOLMEME is a community-focused token on [Solana](/docs/learning/topics/solana/), launched in December 2023 with no pre-sale and no VC backing. It started as a single token and grew into a platform that launches a new [memecoin](/docs/learning/topics/memecoins/) every month, built around whatever trend the project’s own monthly scan finds breaking through — see [How SOLMEME Works](/docs/introduction/how-solmeme-works/) for that mechanic. ## The Short Version [Section titled “The Short Version”](#the-short-version) * **No pre-sale, no VC backing** — the launch history is on-chain and checkable, not a marketing claim (see [Contracts](/docs/contracts/)). * **Community-run beyond a small core team** — see [Community Overview](/docs/community/) for how that works structurally. * **A recurring monthly drop**, not a single fixed token — see [Contracts → Current](/docs/contracts/current/) for the live catalog. * **Real, ongoing mechanics** — the [Vault](/docs/guides/vault/)’s reward system is the main one. ## The Full Story [Section titled “The Full Story”](#the-full-story) The complete narrative — the launch story, the current team, and the project’s timeline from initial concept through today — lives in [Learning → Topics → SOLMEME](/docs/learning/topics/solmeme/), the canonical source for these facts. This page is the short-orientation version; that one is the full one. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) New to crypto in general, not just SOLMEME? Start with [What is a Memecoin?](/docs/introduction/what-is-a-memecoin/) instead — it covers the category SOLMEME belongs to. Ready to participate? [Getting Started](/docs/getting-started/) covers where to go depending on what you’re here for. # Courses > Five sequenced courses — Web3 for Beginners through SOLMEME 101 — each on its own page, building on the one before it. Courses sequence [Learning → Topics](/docs/learning/topics/)’ conceptual material into structured, ordered lessons — a guided route through concepts that also exist as standalone topic pages. Each of the 5 courses lives on its own page and builds on the one before it. ## The 5 Courses [Section titled “The 5 Courses”](#the-5-courses) 1. **[Web3 for Beginners](/docs/learning/courses/web3-for-beginners/)** — what Web3 means and its core ideas: decentralization, smart contracts, dApps. Start here if you’re new to crypto entirely. 2. **[Crypto for Beginners](/docs/learning/courses/crypto-for-beginners/)** — cryptocurrency, blockchains, wallets, and basic security, moving from ideas to practice. 3. **[Solana 101](/docs/learning/courses/solana-101/)** — what Solana is, how it works, and how to use it. 4. **[Memecoins 101](/docs/learning/courses/memecoins-101/)** — what memecoins are, their history and mechanics, and a concrete checklist for evaluating a project. 5. **[SOLMEME 101](/docs/learning/courses/solmeme-101/)** — SOLMEME’s own mechanics: the Vault, tiers, and inverse token economics. Each course assumes the ones before it — start at 1 if you’re new, or jump straight to the course that matches what you already know. ## Format [Section titled “Format”](#format) These are static, text-based lessons — reading, not an interactive platform with progress tracking or quizzes. That’s a deliberate choice, not an oversight: this site currently has no LMS infrastructure, and presenting tracking it doesn’t have would misrepresent what’s here. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Learning → Topics](/docs/learning/topics/) — the standalone reference explainers these courses sequence * [Learning Paths](/docs/learning/learning-paths/) — role-based sequences across Courses (not yet written) # Crypto for Beginners > What cryptocurrency is, how wallets and keys work, and how to take your first safe steps in crypto. By the end of this course, you’ll understand what cryptocurrency is and how basic crypto systems work (blockchain, wallets, transactions — concepts introduced at a general level in [Course 1](/docs/learning/courses/web3-for-beginners/)), and be able to take your first safe steps in crypto. This course assumes you’ve completed Course 1 and are ready to move from general ideas to practice — setting up a wallet, understanding private keys, avoiding scams. ## Lesson 1. What Cryptocurrency Is — and Why It Exists [Section titled “Lesson 1. What Cryptocurrency Is — and Why It Exists”](#lesson-1-what-cryptocurrency-is--and-why-it-exists) Cryptocurrency is decentralized digital money: it isn’t issued by a central bank, but exists through math, code, and a network of many computers. The first cryptocurrency, Bitcoin, launched in 2008 as an alternative to government-issued money. Crypto lets you send value directly to another person anywhere in the world, almost instantly, 24/7, without a bank or payment processor in the middle. That’s possible because transactions are verified and recorded not by one company, but by a distributed network — the same [blockchain](/docs/learning/topics/blockchain/) technology introduced in Course 1. Like any asset, a cryptocurrency’s value comes from the balance of supply and demand, not a central bank’s decision. Worth stressing right away: crypto assets aren’t government-insured (unlike a bank deposit), and prices can be highly volatile — this isn’t a guaranteed or risk-free asset. **Key facts:** Cryptocurrency = decentralized digital money with no central issuer. Transactions go directly between participants (peer-to-peer) and are verified by the network. Crypto assets aren’t government-insured, unlike a bank deposit. ## Lesson 2. How Blockchain Works — In Detail [Section titled “Lesson 2. How Blockchain Works — In Detail”](#lesson-2-how-blockchain-works--in-detail) A blockchain is a shared digital ledger. Picture a ledger recording every single transaction ever made on that network — and a copy of that ledger is held not by one bank, but by thousands of independent participants worldwide. Transactions are grouped into “blocks,” and blocks are chained together in chronological order — hence “blockchain.” When a new transaction happens, network participants (miners or validators, depending on the blockchain) verify it’s valid and add it to the next block. After that, the record becomes practically irreversible — changing past blocks would require controlling a huge portion of the entire network at once, which isn’t realistic. That’s why no bank needs to “vouch” for the record’s accuracy — correctness is verified collectively by the network itself, not by one trusted middleman. **Key facts:** A blockchain is a chain of linked transaction blocks. Copies of the ledger are held by many independent participants at once. Transactions are practically irreversible once confirmed by the network. ## Lesson 3. Wallets, Keys, and Seed Phrases — The Most Important Topic in This Course [Section titled “Lesson 3. Wallets, Keys, and Seed Phrases — The Most Important Topic in This Course”](#lesson-3-wallets-keys-and-seed-phrases--the-most-important-topic-in-this-course) A crypto wallet doesn’t hold coins “inside it” the way a physical wallet holds cash. Instead, it holds cryptographic keys that give access to assets that actually live on the blockchain. * **Public key (wallet address)** — safe to share freely with others so they can send you funds. Think of it like a bank account number — fine to give out. * **Private key** — a secret that unlocks access to your funds and lets you spend them. Never, under any circumstances, share your private key — not with “support,” not in a DM, not on a “verification” site. * **Seed phrase** — usually 12 or 24 random words that act as a “master password” to recover your entire wallet. Whoever has the seed phrase has full control of every fund in that wallet, exactly like whoever has the private key. It’s also worth distinguishing two kinds of wallets: * **Custodial wallet** (e.g., an account on a centralized exchange) — the company holds the keys for you. Convenient for beginners, but it means you’re trusting the company with control over your funds (“not your keys, not your coins”). * **Non-custodial wallet** (e.g., an app like Phantom or Solflare for Solana) — only you hold the keys, no middleman. This is the self-custody idea from Course 1: full control, and full responsibility. **Key facts:** A wallet holds keys, not coins. Your private key and seed phrase equal full access to your funds — never share them. Custodial = the company holds the keys; non-custodial = only you do. ## Lesson 4. Basic Crypto Security [Section titled “Lesson 4. Basic Crypto Security”](#lesson-4-basic-crypto-security) The core rule of crypto security sounds simple, but it’s the one beginners break most often: **never share your seed phrase or private key with anyone** — not “support,” not in a DM, not on a site that asks for it “to verify.” This is the same rule already covered in [Guides → Security](/docs/guides/security/), which goes deeper on protecting your wallet specifically around SOLMEME. **Common scams:** * **Phishing** — fake websites or messages designed to trick you into revealing your keys or connecting your wallet to a malicious contract. Always check the browser’s address bar carefully before connecting a wallet — phishing sites often use lookalike, but not identical, domains. * **“Guaranteed profit” promises** (“we’ll double your money in 24 hours,” “guaranteed 50% monthly returns”) — almost always a scam. No legitimate crypto project can guarantee returns. * **Fake support** — scammers often message first, posing as an exchange’s or project’s support team, and ask you to “verify” your wallet via your seed phrase. **Key facts:** A seed phrase/private key is an absolute secret, no exceptions. Guaranteed returns are a red flag. Always check a site’s URL before connecting your wallet. ## Lesson 5. Centralized vs. Decentralized Exchanges (CEX vs. DEX) [Section titled “Lesson 5. Centralized vs. Decentralized Exchanges (CEX vs. DEX)”](#lesson-5-centralized-vs-decentralized-exchanges-cex-vs-dex) A **CEX** (Centralized Exchange) is a company like Coinbase, where you create an account (usually with identity verification, or KYC), and the company holds your funds on its own servers until you withdraw. This is a convenient entry point for beginners, but the exchange technically holds and controls your assets — a custodial model. A **DEX** (Decentralized Exchange) lets you trade directly from your own non-custodial wallet, connecting it to the exchange’s site through smart contracts, with no third party holding your funds. This is closer to the self-custody idea from Course 1. **Key facts:** CEX = the company holds your keys and requires KYC — convenient for starting out. DEX = you trade directly from your own wallet — only you hold the keys. A CEX can be hacked like any company; a DEX carries different risks (e.g., smart contract bugs). ## Lesson 6. Common Beginner Misconceptions [Section titled “Lesson 6. Common Beginner Misconceptions”](#lesson-6-common-beginner-misconceptions) * **“The coin’s logo is its value”** — no, a logo and name are just branding; value comes from supply, demand, and real network use, not a picture. * **“My crypto wallet works like a bank account”** — no, funds aren’t government-insured, and transactions are irreversible: a bank can reverse a mistaken transfer; a blockchain can’t. * **“If it’s listed on an exchange, the project must be legit”** — a listing isn’t a guarantee of legitimacy (more on evaluating projects in [Course 4, Memecoins 101](/docs/learning/courses/memecoins-101/)). ## Key Takeaways [Section titled “Key Takeaways”](#key-takeaways) * Cryptocurrency is decentralized digital money built on the blockchain concept from Course 1. * Blockchain is a shared, distributed, and practically unchangeable chain of transaction records. * Wallets hold keys, not coins; share your public key freely, never your private key or seed phrase. * Custodial (exchange holds the keys) vs. non-custodial (only you hold the keys) is a fundamental choice in crypto. * Security comes down to one rule: never share your private key/seed phrase, and never trust guaranteed returns. * A CEX is a convenient but custodial entry point; a DEX lets you trade directly from your own wallet. ## Try It Yourself [Section titled “Try It Yourself”](#try-it-yourself) These are optional hands-on steps meant to reinforce what you just read — not extra requirements. Try one or two that sound useful. * Set up a free non-custodial wallet (on a testnet) and find your public address. * Look up a real transaction on a block explorer (Solscan) and see what details it shows. * Compare signing up on a CEX with connecting a wallet to a DEX, to see the difference firsthand. * Practice spotting a phishing site from real examples (without entering any real information). ## Related Terms [Section titled “Related Terms”](#related-terms) Blockchain · Wallet · Private/public key · Seed phrase · Custodial/non-custodial · Transaction · Exchange (CEX/DEX) · Phishing — see [Learning → Topics](/docs/learning/topics/) and [Guides → Security](/docs/guides/security/) for more depth on several of these. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) By the end of this course, you’ll be able to explain what cryptocurrency is, how blockchains and wallets work, tell custodial and non-custodial models apart, and confidently avoid the most common beginner security mistakes. Continue to [Course 3: Solana 101](/docs/learning/courses/solana-101/), or see [Guides → Security](/docs/guides/security/) for SOLMEME-specific safety practices. # Memecoins 101 > What memecoins are, how they differ from other cryptocurrencies, and a concrete checklist for evaluating a project. By the end of this course, you’ll understand what memecoins are and how they differ from other cryptocurrencies; be able to explain their origin, mechanics, and risks; and know how to run a concrete, practical check on a project. This course assumes you’ve completed [Courses 1-3](/docs/learning/courses/web3-for-beginners/) and are curious about the memecoin phenomenon — closely tied to [Solana](/docs/learning/courses/solana-101/). ## Lesson 1. What a Memecoin Is [Section titled “Lesson 1. What a Memecoin Is”](#lesson-1-what-a-memecoin-is) A memecoin is a cryptocurrency tied to internet culture, memes, or trends, usually with limited technical “utility.” Unlike Ethereum, for example, which was built to run applications and smart contracts (see [Course 1](/docs/learning/courses/web3-for-beginners/)), a memecoin is typically created for virality and to bring a community together around a joke or a shared reference. Technically, a memecoin is a token on a blockchain just like any other (often on Ethereum or Solana), but its value is driven by cultural impact rather than by solving a specific technical problem. **Key facts:** Interest in a memecoin runs on internet culture and community; technically it’s a token like any other, just without built-in “utility.” ## Lesson 2. A Short History of Memecoins [Section titled “Lesson 2. A Short History of Memecoins”](#lesson-2-a-short-history-of-memecoins) **Dogecoin (DOGE)** launched in 2013 as a joke based on the “Doge” meme and became the first truly mainstream memecoin. Hundreds of others followed — for example, Shiba Inu (2021). The category keeps growing: according to industry analytics, memecoins became one of the biggest areas of crypto investor interest in 2024, outpacing categories like DeFi, AI tokens, and gaming tokens. Several factors drove this at once: the market recovering after the 2022-2023 downturn, platforms like Pump.fun making it far easier to launch a new token in minutes, active communities on Reddit, TikTok, Telegram, and X, and public figures launching their own tokens and drawing in large numbers of new, inexperienced investors. **Key facts:** Dogecoin (2013) was the first mainstream memecoin. Interest in the category surged starting in 2024. Growth is linked to easier launches (e.g., Pump.fun) and active social-media communities. ## Lesson 3. How Memecoins Attract Attention [Section titled “Lesson 3. How Memecoins Attract Attention”](#lesson-3-how-memecoins-attract-attention) A memecoin’s value mostly comes from community hype and virality, not product features — social media, public figures, and FOMO (fear of missing out) all play a role. Prices can spike sharply on hype and fall just as sharply once attention fades — unlike tokens with a specific technical function, whose value is more tied to actual network use. **Key facts:** A memecoin’s price mostly reacts to community attention, not technical metrics. A sharp rise is often followed by an equally sharp fall. ## Lesson 4. Memecoin Mechanics: Supply, Liquidity, Launch Types [Section titled “Lesson 4. Memecoin Mechanics: Supply, Liquidity, Launch Types”](#lesson-4-memecoin-mechanics-supply-liquidity-launch-types) Many memecoins have a very large — sometimes effectively unlimited — token supply. Some projects use **burns** (permanently removing tokens from circulation) to reduce supply. For a token to be tradable, its creators set up a **liquidity pool** — a smart contract on a decentralized exchange (DEX) that holds a pair of tokens (say, the new memecoin plus SOL) and lets people swap between them without a centralized middleman. The more funds in the pool, the more stable the price stays during large trades. **How a new token can launch:** * **Fair launch** — no one receives tokens in advance; everyone starts on equal footing at public launch. * **Presale** — some tokens are sold in advance, usually at a discount, before the public launch. Most Solana memecoins don’t trade on major centralized exchanges (which have strict listing standards) — they trade directly on DEXs like Jupiter and Raydium, or through launch platforms like Pump.fun, where anyone can create a token in minutes by filling in a name, ticker, and image. **Key facts:** A liquidity pool is a smart contract holding a token pair for trading. Fair launch = everyone starts equal; presale = some tokens are sold in advance. Memecoins trade more often on DEXs than on major CEXs. ## Lesson 5. How to Evaluate a Memecoin — a Concrete, Usable Checklist [Section titled “Lesson 5. How to Evaluate a Memecoin — a Concrete, Usable Checklist”](#lesson-5-how-to-evaluate-a-memecoin--a-concrete-usable-checklist) Before digging into a specific project, check a few concrete, measurable signals: * **Token concentration** — if the top 10 wallets hold more than 30% of the total supply, the risk of a coordinated sell-off (see Lesson 6) is significantly higher. Tools like DEX Screener show this. * **Locked liquidity** — trustworthy projects usually lock a portion of liquidity for an extended period, reducing the risk of the team suddenly pulling funds. * **Contract verification** — wallets like Phantom typically flag unverified tokens separately; an “unverified” status alone doesn’t always mean a scam, but it calls for extra caution. * **Honeypot contracts** — versions of a token that technically prevent you from selling after buying. You can check this on tools like DEX Screener by confirming other wallets are actually able to sell, not just buy. * **Correct contract address** — scammers often create duplicate tokens with a similar name and logo. Before buying, double-check the official contract address against a trusted source (like CoinGecko or the project’s official site — for SOLMEME specifically, see [Contracts](/docs/contracts/)). * **Team and community transparency** — be cautious of accounts with obviously inflated followings, bots in Telegram/Discord, and influencers who’ve previously promoted projects that turned out to be scams. **Key facts:** A concrete risk threshold is over 30% of supply held by the top 10 wallets. Checkable signals include locked liquidity, contract verification, and a confirmed, correct contract address. ## Lesson 6. Memecoin Risks [Section titled “Lesson 6. Memecoin Risks”](#lesson-6-memecoin-risks) Memecoins are highly volatile — prices can spike or crash within minutes. The most common scam is a **rug pull**: the project team suddenly pulls liquidity or simply abandons the project, leaving holders with a worthless token. According to industry analytics, investors lost more than $500 million to rug pulls in 2024 alone — a real, not hypothetical, risk. **Pump-and-dump** schemes also occur, where a group of insiders hypes up a price and then sells off their holdings at the peak. This is presented calmly and factually, without scare tactics — holders need to understand real risks in order to make informed decisions, not act on emotion. For SOLMEME-specific scam patterns, see [Guides → Security](/docs/guides/security/). **Key facts:** A rug pull is when the team pulls liquidity or abandons the project. Rug pull losses exceeded $500M in 2024 alone, per industry data. A pump-and-dump is a hyped price followed by a mass insider sell-off. ## Key Takeaways [Section titled “Key Takeaways”](#key-takeaways) * Memecoins are tokens built on internet culture, without built-in technical utility. * Dogecoin (2013) was the first mainstream memecoin; the category surged again starting in 2024. * Value comes from hype and community attention rather than fundamental technical metrics. * Liquidity pools enable DEX trading; fair launch vs. presale are different launch models. * A concrete pre-purchase check: top-10-wallet concentration (30% threshold), locked liquidity, contract verification, correct contract address. * Main risks: volatility, rug pulls ($500M+ in losses in 2024 alone, per industry data), and pump-and-dump schemes. ## Try It Yourself [Section titled “Try It Yourself”](#try-it-yourself) These are optional practical steps to help the checklist above actually stick — not required reading. * Look up a real project’s token-holder distribution on DEX Screener or a similar tool. * Find a published audit report for a known project. * Walk through a real rug pull example against the red-flag checklist above. * Compare a memecoin’s market cap and Fully Diluted Valuation (FDV) on an analytics site. ## Related Terms [Section titled “Related Terms”](#related-terms) Market cap · Liquidity pool · Rug pull · Pump-and-dump · Fair launch · Presale · Burn · Fully Diluted Valuation (FDV) · Honeypot contract · Token concentration — see [Learning → Topics](/docs/learning/topics/memecoins/) for the standalone memecoins explainer. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) By the end of this course, you’ll be able to explain what memecoins are, how they launch and trade, and run a concrete, evidence-based check on a project instead of just going by gut feeling. Continue to [Course 5: SOLMEME 101](/docs/learning/courses/solmeme-101/), or see [Contracts](/docs/contracts/) for SOLMEME’s own real, verifiable contract addresses. # Solana 101 > What Solana is, how it achieves high speed, and how to actually use it — the network SOLMEME runs on. By the end of this course, you’ll be able to explain what [Solana](/docs/learning/topics/solana/) is and how it works at a basic level: the network’s purpose, how it differs from other blockchains (speed, low fees), and how to actually use it (the SOL token, compatible wallets). This course assumes you’ve completed [Courses 1-2](/docs/learning/courses/web3-for-beginners/) and are ready to focus on one specific network — the one SOLMEME itself runs on. ## Lesson 1. What Solana Is [Section titled “Lesson 1. What Solana Is”](#lesson-1-what-solana-is) Solana is a public, high-performance blockchain created by Anatoly Yakovenko and Raj Gokal; mainnet launched in March 2020. It’s designed for very fast, very cheap transactions, built to support active applications — from payments and trading to gaming. Compared to the two best-known blockchains: * **Bitcoin** was built mainly as a decentralized digital store of value (“digital gold”) — simple and secure, but with slow, often expensive transactions. * **Ethereum** added the ability to run smart contracts and applications (see [Course 1](/docs/learning/courses/web3-for-beginners/)), but fees can rise sharply when the network is busy. * **Solana** combines speed and scalability with low fees, making it well-suited to applications that need frequent, cheap interactions — trading, gaming, micropayments. **Key facts:** Solana launched in March 2020. Its native token is SOL. The network is specifically designed for speed and low transaction cost. ## Lesson 2. How Solana Achieves High Speed: Proof of History, and Now Alpenglow [Section titled “Lesson 2. How Solana Achieves High Speed: Proof of History, and Now Alpenglow”](#lesson-2-how-solana-achieves-high-speed-proof-of-history-and-now-alpenglow) Every blockchain needs a way for all the computers on the network to agree on the order of transactions. Most blockchains slow down right here — participants have to keep checking with each other before anything is finalized. Solana solves this with **Proof of History (PoH)** — it works like a built-in clock for the network: each tick of this clock proves that a given event happened at a specific time, in a specific order. Because participants are already synchronized to this clock, transactions confirm almost instantly. To secure the network, Solana also uses **Proof of Stake (PoS)**: SOL holders can “stake” (lock up) some of their tokens with a validator, who processes transactions and helps keep the network safe. In return, stakers earn rewards in SOL. Your tokens stay under your control while staked, but are temporarily delegated to your chosen validator. **2026 update:** in 2025, the Solana community voted (with roughly 98% validator support) to move to a new consensus mechanism called **Alpenglow**, replacing Proof of History and the previous voting mechanism (Tower BFT) with two new components — Votor (voting and finalization) and Rotor (block propagation). Alpenglow finalizes transactions in under 150 milliseconds — roughly 100x faster than the previous mechanism. Live validator testing started in May 2026, with full mainnet activation targeted for late 2026. Needs verification before wider promotion Whether Alpenglow has fully rolled out to Solana mainnet may have changed since this course was written (August 2026). No independent confirmation was available at authoring time beyond the source material below — check solana.com or the Solana Foundation’s own status pages before treating “late 2026” as settled, and update this lesson once confirmed either way. **Key facts:** PoH = the network’s built-in “clock.” PoS = staking SOL to help secure the network. Alpenglow is the new consensus mechanism, in testing since May 2026, targeting full rollout by late 2026. ## Lesson 3. Speed and Fees on Solana — the Actual Numbers [Section titled “Lesson 3. Speed and Fees on Solana — the Actual Numbers”](#lesson-3-speed-and-fees-on-solana--the-actual-numbers) Solana handles thousands of transactions per second, and a typical transaction costs less than a cent and confirms in under a second. More precisely: the base transaction fee on Solana is 5,000 lamports (0.000005 SOL — a lamport is the smallest unit of SOL, roughly like a cent). Half of that fee is burned (permanently removed from circulation), and the other half goes to the validator that processed the transaction. During busy periods, you can optionally pay a “priority fee” to get processed faster — but even with it, total cost usually stays under a cent. Needs verification before wider promotion Exact TPS and fee figures move as the network evolves; no independent confirmation was available at authoring time beyond the source material below. Verify current numbers on solana.com before treating these as a live guarantee. **Key facts:** Base fee is 5,000 lamports (0.000005 SOL); half is burned, half goes to the validator; typical total transaction cost is a fraction of a cent. ## Lesson 4. The Ecosystem: What’s Actually Happening on Solana [Section titled “Lesson 4. The Ecosystem: What’s Actually Happening on Solana”](#lesson-4-the-ecosystem-whats-actually-happening-on-solana) Solana is home to active development in: * **DeFi apps** — decentralized exchanges and lending platforms (well-known Solana DEXs include Jupiter and Raydium). * **NFT marketplaces** — with notable collections like Mad Lads. * **Memecoins** — Solana has become one of the most popular platforms for launching this type of token (covered in detail in [Course 4, Memecoins 101](/docs/learning/courses/memecoins-101/)). **Important:** these project names are factual examples for education, not recommendations to use or invest in them. ## Lesson 5. Using Solana: SOL and Wallets [Section titled “Lesson 5. Using Solana: SOL and Wallets”](#lesson-5-using-solana-sol-and-wallets) **SOL** is the network’s native coin, used to pay transaction fees and for staking. Solana-compatible non-custodial wallets include Phantom and Solflare (available as browser extensions or mobile apps) — the same wallets you’d use to hold and interact with SOLMEME (see [Use the Vault](/docs/tutorials/use-the-vault/)). Roughly how a transaction works: 1. You initiate an action (like sending SOL) in your wallet. 2. The transaction is sent to network validators, who check it’s valid. 3. Validators reach consensus — usually in under a second (or faster still, once Alpenglow is fully live). 4. The transaction is confirmed and permanently recorded on the blockchain. 5. The recipient sees the result immediately. **Key facts:** Solana transactions finalize very quickly. Fees are paid in SOL. Popular non-custodial wallets include Phantom and Solflare. ## Lesson 6. Risks and History — Honestly [Section titled “Lesson 6. Risks and History — Honestly”](#lesson-6-risks-and-history--honestly) Solana has had several network outages (periods when the network temporarily stopped processing transactions) due to congestion — this is part of the history of most relatively young, high-performance networks. There was also a major security incident in August 2022 that affected part of the ecosystem’s wallets. Fixing stability issues like these was one of the motivations behind the Alpenglow upgrade covered in Lesson 2. It’s also worth knowing about broader risk categories that apply to any digital asset, including SOL: market volatility (prices can move sharply), technology risk (bugs, validator downtime), staking risk (for example, penalties for misbehaving validators — called “slashing” on Solana, though in practice it’s rare and not automatic), and evolving regulation in different countries. All of this is factual history and risk categories, not investment advice. **Key facts:** Solana has had network outages and at least one major security incident (August 2022). Alpenglow was partly developed to address stability issues. Like any digital asset, SOL carries market, technology, and regulatory risk. ## Key Takeaways [Section titled “Key Takeaways”](#key-takeaways) * Solana is a high-performance blockchain, launched in March 2020. * It used Proof of History together with Proof of Stake; since 2025-2026 it’s transitioning to a new consensus mechanism, Alpenglow (sub-150ms finalization). * Base transaction fee is 5,000 lamports (0.000005 SOL); half is burned. * Popular areas: DEXs (Jupiter, Raydium), NFT collections, memecoins. * SOL is the native token for fees and staking; popular wallets are Phantom and Solflare. * Risks: network outages, a 2022 security incident, market volatility, regulatory uncertainty. ## Try It Yourself [Section titled “Try It Yourself”](#try-it-yourself) These optional exercises turn what you’ve read into something you’ve actually done — pick whichever help most. * Look up a real transaction on Solscan and break down its details (timing, fee, confirmations). * Install Phantom, get some test SOL on Devnet, and send a test transaction. * Compare Solana’s current fee to another network’s fee at the same moment. ## Related Terms [Section titled “Related Terms”](#related-terms) Validator · Native token · Lamport · Staking · Consensus (PoH/PoS/Alpenglow) · Network outage · RPC — see [Learning → Topics](/docs/learning/topics/solana/) for the standalone Solana explainer. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) By the end of this course, you’ll be able to describe Solana’s origin and how it works (including the shift to Alpenglow), explain its fee structure, and name the network’s specific risks. Continue to [Course 4: Memecoins 101](/docs/learning/courses/memecoins-101/), or see [Use the Vault](/docs/tutorials/use-the-vault/) for how this connects to SOLMEME specifically. # SOLMEME 101 > SOLMEME's inverse token economics, the Vault, tiers and rewards — what's live today versus still planned. By the end of this course, you’ll understand SOLMEME’s core mechanic — monthly token drops that unlock a shared on-chain Vault — and be able to explain why the project calls this “inverse token economics,” how the Vault, tiers, and rewards work today, and what’s live versus still planned. This course assumes you’ve completed [Course 4, Memecoins 101](/docs/learning/courses/memecoins-101/) and want to understand SOLMEME specifically. ## Lesson 1. Where SOLMEME Came From [Section titled “Lesson 1. Where SOLMEME Came From”](#lesson-1-where-solmeme-came-from) SOLMEME launched in December 2023, built by an anonymous developer known as u4ma — no pre-sale, no VC backing, no influencer budget. The project evolved from a community token into a monthly drop platform, and finally into “The Vault Memeverse”: here, the tokens aren’t the product — they’re the key to the game they unlock. **Key facts:** No pre-sale, no VC. The project has run since December 2023. ## Lesson 2. The Core Idea — Inverse Token Economics [Section titled “Lesson 2. The Core Idea — Inverse Token Economics”](#lesson-2-the-core-idea--inverse-token-economics) Every new drop makes previous drops more valuable — the opposite of typical memecoins (see [Course 4](/docs/learning/courses/memecoins-101/)), where a new token launch usually abandons the old one in a “launch → pump → dump → abandon” cycle. In SOLMEME’s model, each new drop creates new ways to combine it with older drops inside the [Vault](/docs/guides/vault/), so demand for old tokens tends to rise over time instead of fade. Tokens held for more than 90 days count at a 1.5x multiplier toward Vault-unlock eligibility — with no lockup contract required. **Key facts:** Inverse token economics is the project’s defining feature. A 90+ day hold gives a 1.5x multiplier. ## Lesson 3. How the Vault Works [Section titled “Lesson 3. How the Vault Works”](#lesson-3-how-the-vault-works) The [Vault](/docs/guides/vault/) is a 6×6 grid (36 cells), each cell representing a distinct unlockable reward that requires 2-4 specific tokens based on algorithmically generated conditions. When a new drop launches, it automatically generates: 4 “Direct” combos (the new drop paired with 1-3 randomly selected older drops), 2 “Sequential” combos (linking consecutive drops), 1 “Wild” combo (the new drop plus any two tokens held over 30 days), and a 5% “Reshuffle” that reassigns reward types on some existing combos to keep the grid fresh. A diversity rule prevents any single token from appearing in more than 15% of active combos. **Key facts:** The grid is 6×6 = 36 cells, matching [Treasure Grid](/docs/guides/vault/grid/). Each new drop generates 4 Direct + 2 Sequential + 1 Wild combos, plus a 5% Reshuffle. The diversity cap is 15%. ## Lesson 4. Tiers — From Fodder to Mythic [Section titled “Lesson 4. Tiers — From Fodder to Mythic”](#lesson-4-tiers--from-fodder-to-mythic) There are six tiers: **Fodder** (1 token — leaderboard XP + a Bronze lootbox), **Squire** (2 tokens — a Silver lootbox + a MemeVerse Passport NFT), **Knight** (4 tokens — a Gold lootbox + a 2x charity vote multiplier), **Lord** (7 tokens — a Vault Key Fragment + an exclusive Discord role), **Dragon** (10+ tokens — a full Vault Key, a Mythic lootbox, and a spot in the Vault Hall of Fame), and **Mythic** (every drop ever released — a Grand Vault Key, a share of the monthly grand vault pool, a 1-of-1 NFT, and a name on the website). Cross-reference conflict — not resolved here This course’s tier thresholds (1 / 2 / 4 / 7 / 10+ / every drop) come from the SOLMEME whitepaper’s Fodder-through-Mythic naming — the same names already used on [Treasure Grid](/docs/guides/vault/grid/), which notes this is “the Grid’s own tier names, distinct from the Common → Mythic scale used on the main [Vault](/docs/guides/vault/) page.” The main Vault Overview page currently shows different numeric thresholds under its own Common-through-Mythic scale (1-2 / 3-5 / 6-9 / 10-15 / 16+). Both are real, already-published pages on this site with different numbers for what may be the same six-step ladder — this course uses the whitepaper’s Fodder-family thresholds as its source and does not silently override the Vault Overview page. Reconciling the two is a separate, standalone content task, not something resolved by this course. Needs verification before wider promotion As of the whitepaper’s publication, nobody had reached Mythic tier yet — verify this is still accurate before publishing or promoting this course further; no independent confirmation was available at authoring time. ## Lesson 5. What You Can Win [Section titled “Lesson 5. What You Can Win”](#lesson-5-what-you-can-win) There are 12 reward types: Buyback Vouchers, Trend Prediction Tokens (early access to the next drop), Lootbox NFTs (odds: Common 80%, Rare 15%, Epic 4%, Mythic 1%), Vault Keys (a universal wildcard substituting for any one missing token in a combo, burned on use), charity vote multipliers, soulbound Proof of Ape badges, XP leaderboard standing, an upgradable MemeVerse Passport NFT, Raid Beacons, naming rights for the next drop (Lord tier and above), real-world merch (Mythic tier only), and a monthly Grand Vault cash prize (50% SOL / 50% locked into SOLMEME staking). **Key facts:** 12 named reward types. Lootbox odds are transparent and verifiable on-chain. A Vault Key is burned when used — see [Vault Keys](/docs/guides/vault/keys/). ## Lesson 6. The Project’s Two Token Layers [Section titled “Lesson 6. The Project’s Two Token Layers”](#lesson-6-the-projects-two-token-layers) It’s important to keep two separate token layers straight: * **The SOLMEME parent token** — the single, original project token. Total supply is fixed at **499,857,425,213.06 SOLMEME**, permanently locked, with no mint function and no inflation. It launched in December 2023 and anchors governance, staking, and Vault access. Genesis distribution: Community 40% (airdrops, vault rewards, staking bonuses), Expense & Development 30% (operations, marketing, listings, infrastructure), Asset Reserve 25% (liquidity, market-making, partnerships, emergency buffer), and Project Team 5%, vested linearly over 36 months. No tokens were sold in a pre-sale, and there’s no VC or private-investor allocation. * **Monthly drop tokens** — a separate token minted fresh on the 1st of every month (the mechanic from Lessons 2-3). Each individual drop has its own total supply of **1 billion tokens**, entirely separate from the parent token’s supply. The name of each upcoming drop is announced publicly 3 days before that drop launches — see [Contracts](/docs/contracts/) for the real, verifiable launch record. Monthly drops have run since June 2026. **Key facts:** Parent token supply is \~499.86 billion (fixed since December 2023, never changes) versus each drop token’s supply of 1 billion (a new token every month, since June 2026) — never add these numbers together or describe them as the same token. ## Lesson 7. Charity, Governance, and the Weekly Leaderboard [Section titled “Lesson 7. Charity, Governance, and the Weekly Leaderboard”](#lesson-7-charity-governance-and-the-weekly-leaderboard) 5% of all token-generation fees go to a dedicated charity wallet, with the community voting monthly on recipients and every donation verifiable on-chain via Solscan — see [Ecosystem](/docs/ecosystem/) for the current charity roster. Charity vote power scales with tier: Knight ×2, Lord ×5, Dragon ×10, Mythic ×20. Governance runs on four membership tiers based on holdings, and a weekly XP leaderboard rewards the top 10 participants with bonus rewards. ## Lesson 8. What’s Live Today vs. What’s Still Planned [Section titled “Lesson 8. What’s Live Today vs. What’s Still Planned”](#lesson-8-whats-live-today-vs-whats-still-planned) Right now, the core Vault grid and tier unlocks from Fodder through Dragon are live, with reward distribution active. The social/team-based Vault types — Duo, Raid, Guild, Hunt, Grand, and Flash Vaults — are on the project’s roadmap for a later phase and aren’t live yet. Cross-reference conflict — not resolved here This lesson’s whitepaper-sourced claim that the social/team-based Vault types “aren’t live yet” doesn’t match this site’s own already- published guide pages for [Buddy Drops](/docs/guides/vault/buddy-drops/) (Duo), [Community Raids](/docs/guides/vault/community-raids/) (Raid), and [Grand Vault](/docs/guides/vault/grand-vault/) (Grand), which document them as real, existing mechanics rather than roadmap items. This course presents the whitepaper’s framing as given and does not silently resolve the discrepancy — treat “what’s actually live right now” as an open question pending a real check against the live product, not settled by either source alone. This lesson matters so the course accurately reflects what’s available today, rather than describing future plans as if they were already live. ## Key Takeaways [Section titled “Key Takeaways”](#key-takeaways) * SOLMEME launched in December 2023, with no pre-sale and no VC. * “Inverse token economics”: each new drop increases the value/utility of older drops. * The Vault is a 6×6 grid (36 cells); each new drop generates 4 Direct * 2 Sequential + 1 Wild combos, plus a 5% Reshuffle. * Six tiers (Fodder → Mythic), with thresholds of 1 / 2 / 4 / 7 / 10+ / every-drop-ever (per the whitepaper — see Lesson 4’s cross-reference note on the Vault Overview page’s different numbers). * Two distinct tokens: the SOLMEME parent token (\~499.86B, since 2023) and monthly drop tokens (1B each, since June 2026) — never confuse the two. * 5% of fees go to charity monthly; vote power scales by tier. * Whether the social Vault types (Duo/Raid/Guild/Hunt/Grand/Flash) are live or still planned is unresolved between this course’s source and this site’s own Vault guide pages — see Lesson 8’s cross-reference note. ## Try It Yourself [Section titled “Try It Yourself”](#try-it-yourself) A few optional ways to see these mechanics for yourself, not extra assignments. * Read the interactive whitepaper at solme.me/whitepaper. * Check the live Vault grid at vault.solme.me. * Look up a charity payout on Solscan to see the on-chain transparency in action. ## Related Terms [Section titled “Related Terms”](#related-terms) Inverse token economics · Vault grid and combo generation · Vault tiers (Fodder-Mythic) · Vault Key · Genesis distribution · Charity vote multiplier — see [Guides → Vault](/docs/guides/vault/) for the full practical guide. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) By the end of this course, you’ll be able to explain SOLMEME’s inverse-economics model, describe how the Vault and tier system work, correctly state the tokenomics figures (distinguishing the parent token from drop tokens), and accurately tell which features are live today versus still on the roadmap. See [Guides → Vault](/docs/guides/vault/) to put this into practice, or [Contracts](/docs/contracts/) for the real, verifiable drop history. # Web3 for Beginners > What Web3 means, how it differs from Web1/Web2, and the core ideas behind it — decentralization, smart contracts, dApps. By the end of this course, you’ll understand what “Web3” means, how it differs from earlier stages of the internet, and be able to explain its core ideas — decentralization, smart contracts, dApps — along with real examples like DeFi, NFTs, and DAOs. This is the first course in the sequence — complete beginners start here, with no prior crypto or blockchain experience assumed, just everyday internet literacy. ## Lesson 1. The Internet’s Evolution: Web1 → Web2 → Web3 [Section titled “Lesson 1. The Internet’s Evolution: Web1 → Web2 → Web3”](#lesson-1-the-internets-evolution-web1--web2--web3) To understand what Web3 means, it helps to look at three broad stages of the internet’s history. **Web1** (roughly the 1990s to early 2000s) was the “read-only” era. Websites were static pages: someone published them, everyone else just read them. Think of it more like an ebook than a forum — there was almost no interaction. **Web2** (roughly mid-2000s to today) is the “read-write” era. Social media, blogs, and video platforms let anyone create content, comment, and share. But that convenience came at a cost: your posts, photos, friend lists, and purchase history all live on company servers — Meta’s, Google’s, TikTok’s. They technically belong to the platform, which can suspend your account, change the rules, or sell your data to advertisers at any time. **Web3** is often described as “read, write, and own.” The idea is to give control back to users over their own data and digital assets, using [blockchain](/docs/learning/topics/blockchain/) — a technology that stores information across many independent participants instead of one company’s servers. It’s worth being upfront: “Web3” doesn’t have a strict technical definition, and parts of the industry use it more as a marketing term than a precisely defined technology. Keep that in mind — don’t treat Web3 as something fully settled. **Key facts:** Web1 = read-only, Web2 = read-write, Web3 = read-write-own. In Web2, your data technically belongs to the platform. “Web3” is a broad, sometimes marketing-driven term, not a strict technical standard. ## Lesson 2. Core Web3 Ideas: Decentralization and Ownership [Section titled “Lesson 2. Core Web3 Ideas: Decentralization and Ownership”](#lesson-2-core-web3-ideas-decentralization-and-ownership) **Decentralization** means a service isn’t run by one company or server — it runs on a network of many independent computers worldwide, each holding a copy of the data. If one computer goes down, or its owner decides to shut it off, the network keeps running because the data isn’t concentrated in one place. **Ownership** in Web3 usually means you control your own digital assets through cryptographic keys (more on this in Course 2), rather than through a username and password on someone else’s server. A Web2 account can be suspended with one moderator’s decision; a Web3 wallet can’t be controlled by anyone but you. That’s both the strength (full control) and the responsibility (no one can recover your access if you lose your keys). **Open-source code** is another common trait: many Web3 projects publish their code publicly so anyone can inspect it. That’s not a safety guarantee on its own, but it enables independent verification that closed Web2 services don’t offer. **Key facts:** In Web3 you usually hold your own private keys, not a company. Open-source code is common (though not required) in Web3 projects. Decentralization means resilience against any single point of failure. ## Lesson 3. Smart Contracts and Decentralized Apps (dApps) [Section titled “Lesson 3. Smart Contracts and Decentralized Apps (dApps)”](#lesson-3-smart-contracts-and-decentralized-apps-dapps) A **smart contract** is a program that lives on a blockchain and runs automatically once its conditions are met — no middleman required. Think of a vending machine: you insert a coin, and it dispenses a snack automatically, with no cashier. A smart contract works similarly, except instead of coins and snacks, it’s digital assets and pre-written conditions. A **dApp** (decentralized application) is an app built on top of a blockchain instead of a single company’s server. It might look like a normal website or app on the surface, but underneath, smart contracts on a public network — like Ethereum or [Solana](/docs/learning/topics/solana/) — do the work instead of a centralized database. One important nuance: a smart contract executes exactly as written, with no exceptions or “let’s work it out” flexibility. That’s a strength (predictability — no one can quietly change the rules later) and a risk (a bug in the code gets executed just as literally as everything else — which is why code audits matter, covered later in Course 4). **Key facts:** A smart contract is self-executing code on a blockchain. A dApp is an app that runs through a blockchain instead of a company’s central server. Code executes literally — bugs included. ## Lesson 4. Real Examples: DeFi, NFTs, DAOs [Section titled “Lesson 4. Real Examples: DeFi, NFTs, DAOs”](#lesson-4-real-examples-defi-nfts-daos) **DeFi** (Decentralized Finance) refers to financial services — lending, trading, earning interest — built on smart contracts instead of a bank as the middleman. **NFT** (Non-Fungible Token) is a unique digital asset with ownership recorded on the blockchain. Unlike a regular token (like SOL), where one unit is identical to another, every NFT is unique — like an original painting versus a printed copy. **DAO** (Decentralized Autonomous Organization) is a community where decisions are made by token-holder votes instead of a board of directors, with voting rules and execution often written directly into smart contracts. **Important:** these examples are for education only, not investment advice or a signal to take any action. **Key facts:** DeFi = lending/trading without a bank. NFT = unique, not interchangeable, digital asset. DAO = governance by token-holder vote, not a board. ## Lesson 5. What Makes a Product “Actually Web3” [Section titled “Lesson 5. What Makes a Product “Actually Web3””](#lesson-5-what-makes-a-product-actually-web3) Just mentioning “blockchain” or “crypto” in a product’s description doesn’t make it a Web3 product. A genuinely Web3 product usually offers: * **Self-custody** — you control your own funds through your own wallet, not a login on someone else’s server. * **Transparent rules** — code and terms can be independently checked, rather than taken on trust. * **No single point that can arbitrarily change the rules** — if one party (say, the developer) can unilaterally take all the funds or shut the service down, it isn’t genuinely decentralized, whatever it calls itself. **Key fact:** marketing use of the word “Web3” is far more common than genuine decentralization — check specific traits rather than trusting the label. ## Lesson 6. Criticism and Healthy Skepticism [Section titled “Lesson 6. Criticism and Healthy Skepticism”](#lesson-6-criticism-and-healthy-skepticism) The term Web3 draws real debate within the industry itself: * Some self-described “Web3” projects remain centralized in practice — for example, all user funds physically sit on one company’s servers. * Early Web3 user experience is often clunkier than familiar Web2 products. * Some critics argue Web3 has generated more hype aimed at attracting investment than actual technological benefit. Healthy skepticism is a normal, useful stance: not everything that calls itself Web3 or blockchain-based is actually decentralized or technically sound. ## Key Takeaways [Section titled “Key Takeaways”](#key-takeaways) * Web3 is usually described as “read, write, own” — in contrast to Web2, where platforms own the data. * Decentralization means many independent computers running the network, not one company. * Ownership in Web3 usually means controlling your own private keys. * Smart contracts are self-executing blockchain code; dApps are apps built on them. * DeFi, NFTs, and DAOs are concrete Web3 examples — not investment advice. * Mentioning “blockchain” doesn’t guarantee a product is actually decentralized. * A healthy dose of skepticism toward the term “Web3” is reasonable. ## Try It Yourself [Section titled “Try It Yourself”](#try-it-yourself) Reading about a concept and actually trying it are two different things — these optional exercises are here to help the ideas stick. Pick whichever ones sound interesting; skipping them won’t stop you from finishing the course. * Connect a wallet to a demo NFT marketplace on a testnet and see what self-custody looks like in practice. * Find a real DAO and read how token holders vote on proposals. * Compare the open-source code of a Web2 site versus a Web3 project (try looking one up on GitHub). ## Related Terms [Section titled “Related Terms”](#related-terms) Decentralization · Smart contract · dApp · DAO · DeFi · NFT · Self-custody · On-chain/off-chain — see [Learning → Topics](/docs/learning/topics/) for the fuller conceptual explainers behind several of these. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) By the end of this course, you’ll be able to explain what Web3 means, describe its core concepts, and name real-world examples along with fair criticism of the term. Continue to [Course 2: Crypto for Beginners](/docs/learning/courses/crypto-for-beginners/), or see [Learning → Topics](/docs/learning/topics/) for standalone reference explainers on these same concepts. # Learning Paths > Ordered sequences of courses for a specific reader goal — Courses are ready; this section's own path definitions aren't authored yet. A Learning Path would be an ordered sequence of [Courses](/docs/learning/courses/) aimed at a specific reader goal — for example, everything a brand-new crypto reader should go through, in order, versus everything someone evaluating SOLMEME specifically should read. ## Where This Section Stands Today [Section titled “Where This Section Stands Today”](#where-this-section-stands-today) All 5 [Courses](/docs/learning/courses/) are now written and published — the blocker this section was originally waiting on is resolved. What’s still missing is this section’s own content: which role-based sequences to define hasn’t been authored yet. This stays an honest placeholder rather than inventing a path structure before a real one is defined. ## What’s Available Right Now Instead [Section titled “What’s Available Right Now Instead”](#whats-available-right-now-instead) The 5 [Courses](/docs/learning/courses/) already have a built-in recommended order (Web3 for Beginners through SOLMEME 101) — the closest thing to a path that exists today. [Learning → Topics](/docs/learning/topics/) also suggests a reading order on its own overview page for readers who want standalone concept explainers instead. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) * [Courses](/docs/learning/courses/) — the section this one depends on * [Learning → Topics](/docs/learning/topics/) — the real material available today # Topics > Canonical educational explainers — the single source of text for each topic. Topics is SOLMEME Learning’s canonical educational layer — one page per subject, each standing on its own. It answers “what is this, and how does it work,” not “what should I do right now” (that’s [Tutorials](/docs/tutorials/create-your-first-meme/)) or “teach me this in order” (that’s [Courses](/docs/learning/courses/)). ## Topics vs. Courses vs. Tutorials [Section titled “Topics vs. Courses vs. Tutorials”](#topics-vs-courses-vs-tutorials) * **Topics** (this page) — standalone canonical explainers, no sequencing, no prerequisites. The single source of text for each subject. * **Courses** — structured, ordered learning built *from* Topics — a course doesn’t repeat a Topic’s text, it sequences and routes through it. * **Tutorials** — a single concrete action, start to finish, not a concept explainer. If a fact about a subject appears elsewhere on this site (in Introduction, in a Course, in a Guide), the version here in Topics is the canonical one — other pages summarize or route to it, they don’t restate it independently. ## The 8 Topics [Section titled “The 8 Topics”](#the-8-topics) The eight topics split into project-specific ground, the general crypto/Web3 concepts SOLMEME is built on, and the surrounding community and creator context: * **[SOLMEME](/docs/learning/topics/solmeme/)** — the project itself: its story, team, and timeline. * **[Memecoins](/docs/learning/topics/memecoins/)** — what a memecoin is. * **[Crypto](/docs/learning/topics/crypto/)**, **[Blockchain](/docs/learning/topics/blockchain/)**, **[Web3](/docs/learning/topics/web3/)**, **[Solana](/docs/learning/topics/solana/)** — the general crypto/Web3 concepts SOLMEME is built on. * **[Community](/docs/learning/topics/community/)** — the concept of crypto communities generally. * **[Creators](/docs/learning/topics/creators/)** — content creation as a topic, summarizing [Guides → Creators](/docs/guides/creators/)’ real, practical pages. **\[UPDATED 25 Aug]** All 8 topics above have real canonical text (SOLMEME plus the 7 general concept explainers), and all 5 [Courses](/docs/learning/courses/) are now written and published too. Only [Learning Paths](/docs/learning/learning-paths/) remains unwritten — sequencing Courses into role-based paths, not blocked by this Topics layer. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) New to SOLMEME specifically? Start with [SOLMEME](/docs/learning/topics/solmeme/). New to crypto generally? [Crypto](/docs/learning/topics/crypto/) and [Blockchain](/docs/learning/topics/blockchain/) are the foundational ones the rest build on. # Blockchain > What a blockchain is, how it stays trustworthy without a central authority, and why SOLMEME is built on one. A blockchain is a record of transactions kept in matching copies across many independent computers at once, instead of in one company’s private database. Each new batch of transactions (“block”) links back to the one before it — hence the name — so rewriting an old entry would mean rewriting every block after it, on every copy, at the same time. That’s what makes the record hard to tamper with, not any single company’s promise to keep it honest. ## Why “Decentralized” Is the Point [Section titled “Why “Decentralized” Is the Point”](#why-decentralized-is-the-point) A normal database has one owner: if their server goes down, or they decide to change a number, that’s final. A blockchain spreads the same copy across thousands of independent computers (“nodes”). They all follow the same rules to agree on what the next valid block is — that agreement process is called **consensus**. No single node, including the people who built the software, can unilaterally rewrite history without the rest of the network rejecting it. ## What Actually Goes On One [Section titled “What Actually Goes On One”](#what-actually-goes-on-one) Most public blockchains record simple facts: who sent how much of an asset to whom, and when. Some — including [Solana](/docs/learning/topics/solana/), the one SOLMEME runs on — also run small programs directly on the chain, so more complex logic (like a token’s rules, or a game’s state) lives in the same tamper-resistant record, not on a company’s private server. ## Where This Fits for SOLMEME [Section titled “Where This Fits for SOLMEME”](#where-this-fits-for-solmeme) Every SOLMEME token, every wallet balance, and every on-chain transaction lives on Solana’s blockchain, not on a SOLMEME-controlled server — see [Contracts](/docs/contracts/) for the real, on-chain addresses. That’s also why “no pre-sale, no VC backing” (see [SOLMEME](/docs/learning/topics/solmeme/)) is a checkable claim, not a promise: the launch history is on a public ledger anyone can inspect, not in a private record only the team can see. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) New to the terms here? [Crypto](/docs/learning/topics/crypto/) covers the asset side of this (what a token actually is); [Solana](/docs/learning/topics/solana/) covers the specific blockchain SOLMEME runs on. # Community > What a crypto community is, why it matters for a project's actual survival, and how SOLMEME's own community works. In crypto, “community” refers to the people who actually use, promote, and sustain a project — as distinct from the core team that builds it. A project’s code and marketing can be identical to a hundred others; what a real, active community does is the thing that can’t be copied: consistent participation, organic promotion, and people who keep showing up after the initial launch hype fades. ## Why This Matters More Than in Traditional Tech [Section titled “Why This Matters More Than in Traditional Tech”](#why-this-matters-more-than-in-traditional-tech) A conventional company can survive with zero public community — paying customers are enough. A crypto project, especially one without VC funding or a large paid marketing budget, depends much more directly on its community for distribution (word of mouth, social sharing), for content (memes, translations, guides), and for legitimacy (an active community is itself evidence a project is real, not abandoned). ## What a Healthy Community Actually Looks Like [Section titled “What a Healthy Community Actually Looks Like”](#what-a-healthy-community-actually-looks-like) Concretely: recurring, voluntary participation (not just holding a token silently), real moderation and norms (not just an unmoderated chat), and identifiable roles people can grow into — not just “buy and wait.” ## SOLMEME’s Own Community [Section titled “SOLMEME’s Own Community”](#solmemes-own-community) SOLMEME is explicitly volunteer-driven beyond its small core team — see [Community Overview](/docs/community/) for how that structurally works and [Getting Started](/docs/getting-started/) for the project’s own framing of it. The real, current channels are [Discord](https://discord.gg/solmeme), [Telegram](https://t.me/solmemetoken), and [X/Twitter](https://x.com/SOLMemeToken) — see [Join the Discord](/docs/tutorials/join-the-discord/) for how to actually get into the main one. Scope correction, 21 Aug This page’s earlier stub note pointed at a SOLMEME-specific legacy source (`pages/community.md`, a channel-links/CTA page). That file doesn’t actually answer this Topic’s real question — “what is a crypto community, generally” — which the site’s own, already-published [Topics overview](/docs/learning/topics/) had separately and correctly scoped this page to. This page follows that existing scope; the channel-specific facts it pointed to live on [Community Overview](/docs/community/) instead, where they belong. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) [Community Overview](/docs/community/) covers SOLMEME’s own policy/identity; [Creators](/docs/learning/topics/creators/) covers one specific way community members contribute. # Creators > Content creation as a topic — what it means to be a creator in a crypto community, and how it works in SOLMEME specifically. In a crypto project’s [community](/docs/learning/topics/community/), a “creator” is anyone who makes and shares content the project itself didn’t produce — memes, art, guides, videos, translations — rather than only holding the asset silently. Creator activity is one of the main ways a community actually grows: it’s distribution that costs the project nothing directly and reads as more credible than official marketing, because it comes from real participants. ## Why Projects Deliberately Design for This [Section titled “Why Projects Deliberately Design for This”](#why-projects-deliberately-design-for-this) A project that wants sustained creator activity generally needs to make it worth doing — recognition, real rewards, or just infrastructure that makes creating and sharing easy — rather than assuming people will contribute purely out of goodwill indefinitely. That’s the same reason share-to-earn mechanics, contests, and dedicated creator tools show up across crypto communities generally, not just in SOLMEME. ## How This Works in SOLMEME [Section titled “How This Works in SOLMEME”](#how-this-works-in-solmeme) SOLMEME’s creator pathway runs through three real, practical pieces — covered in full in [Guides → Creators](/docs/guides/creators/), not restated here: * **[Meme Generator](/docs/guides/creators/meme-generator/)** — pick a template, write a caption, share it. * **[Meme Wall](/docs/guides/creators/meme-wall/)** — submit and compete for Meme of the Month. * **[Lore](/docs/guides/creators/lore/)** — the Council of Cats and SOLMEME’s recurring in-universe cast, for anyone whose content draws on it. All three connect to the same share-to-earn XP mechanic — see [Guides → Creators](/docs/guides/creators/) for how that actually works. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) Ready to make something? [Create Your First Meme](/docs/tutorials/create-your-first-meme/) is the concrete, step-by-step version of this. [Community](/docs/learning/topics/community/) covers the broader concept creator activity feeds into. # Crypto > What cryptocurrency is, how a wallet actually works, and what that means for holding SOLMEME. “Crypto” is short for cryptocurrency — a digital asset whose ownership is tracked on a [blockchain](/docs/learning/topics/blockchain/) instead of by a bank. Bitcoin (2009) was the first; thousands of others, including SOLMEME, have followed the same basic model since: an asset that lives on a public ledger, not in a company’s private account system. ## What “Owning” Crypto Actually Means [Section titled “What “Owning” Crypto Actually Means”](#what-owning-crypto-actually-means) You don’t hold crypto the way you hold cash in a wallet — you hold a private key, a secret piece of data that proves you control a specific address on the blockchain. Whoever has the private key controls the funds at that address; there’s no password reset, no bank to call. That’s also why “not your keys, not your coins” is the standard warning about leaving assets on an exchange instead of in a wallet you control. ## Tokens vs. Coins [Section titled “Tokens vs. Coins”](#tokens-vs-coins) A “coin” (like SOL, Solana’s native asset) runs its own blockchain. A “token” (like SOLMEME) is issued on top of an existing blockchain, using that chain’s own rules for how transfers work, rather than running a separate network. SOLMEME is a token on [Solana](/docs/learning/topics/solana/) — every SOLMEME transaction is really a Solana transaction moving a SOLMEME-specific asset. ## Volatility Is Real, Not a Bug [Section titled “Volatility Is Real, Not a Bug”](#volatility-is-real-not-a-bug) Crypto asset prices move — often faster and further than most traditional assets — because markets are smaller, trade continuously (no market close), and are driven heavily by sentiment. That volatility is a structural fact of the asset class, not something specific to any one project; treat price swings as expected, not as a sign anything has technically gone wrong. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) [Blockchain](/docs/learning/topics/blockchain/) covers the ledger crypto runs on; [Solana](/docs/learning/topics/solana/) covers the specific chain SOLMEME uses; [Memecoins](/docs/learning/topics/memecoins/) covers the specific category SOLMEME belongs to within crypto. # Memecoins > What a memecoin is, how it differs from a utility token, and where SOLMEME sits in the category. A memecoin is a [cryptocurrency](/docs/learning/topics/crypto/) whose primary identity is cultural — built around a joke, a meme, or a community identity — rather than a specific technical utility the token itself is required for. That doesn’t mean memecoins can’t have real mechanics (SOLMEME’s [Vault](/docs/guides/vault/) is a real, functioning reward system); it means the *reason people first pay attention* is usually the culture/community/humor, not a whitepaper’s technical claims. ## Why the Category Exists [Section titled “Why the Category Exists”](#why-the-category-exists) Memecoins became a distinct, widely-recognized category because a critical mass of crypto projects deliberately embraced humor and community identity as the core product, instead of positioning as infrastructure or a financial instrument. Dogecoin is the most commonly cited origin point. The category has since split into thousands of individual projects, most short-lived, some — including long-running community-driven ones — building real, ongoing mechanics on top of the initial joke/identity. ## What Separates a Real Project from a Ticker [Section titled “What Separates a Real Project from a Ticker”](#what-separates-a-real-project-from-a-ticker) The mechanics that make a memecoin worth engaging with are the same ones that make any project worth engaging with: does a real community actually exist, does the project ship real mechanics that hold up under use (not just a marketing page), and can you verify claims on-chain instead of taking marketing copy on faith. See [Blockchain](/docs/learning/topics/blockchain/) for why the on-chain part is checkable at all. ## Where SOLMEME Fits [Section titled “Where SOLMEME Fits”](#where-solmeme-fits) SOLMEME launched as a memecoin (see [SOLMEME](/docs/learning/topics/solmeme/) for the specific launch story) and has since built real, ongoing mechanics — the monthly drop cycle, the [Vault](/docs/guides/vault/)’s reward system, [Contracts](/docs/contracts/) you can verify on-chain — on top of that starting identity, rather than staying only a ticker with no follow-through. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) [SOLMEME](/docs/learning/topics/solmeme/) covers this specific project’s story; [Crypto](/docs/learning/topics/crypto/) covers the broader asset class memecoins belong to. # Solana > What Solana is, why SOLMEME is built on it, and what that means for fees and speed. Solana is a public [blockchain](/docs/learning/topics/blockchain/) designed for high transaction throughput and low transaction fees compared to older networks like Bitcoin or Ethereum’s original design. SOLMEME’s token, its on-chain [Contracts](/docs/contracts/), and every Vault transaction run on Solana — it’s the specific network everything else on this site assumes when it talks about wallets, transactions, or gas fees. ## Why the Choice of Chain Matters [Section titled “Why the Choice of Chain Matters”](#why-the-choice-of-chain-matters) Every blockchain has its own tradeoffs — speed, fee cost, decentralization model, and ecosystem of wallets/exchanges that support it. Solana’s combination of low fees and fast confirmation times is specifically why it’s a common choice for projects like SOLMEME that expect frequent, small transactions (claiming Vault rewards, swapping tokens) rather than occasional, high-value ones. ## What You Need to Interact With It [Section titled “What You Need to Interact With It”](#what-you-need-to-interact-with-it) To hold or transact SOLMEME, you need a Solana-compatible wallet (a browser extension or mobile app that holds your private key — see [Crypto](/docs/learning/topics/crypto/) for what that means) and a small amount of SOL, Solana’s native asset, to cover transaction fees — fees paid in SOL, not in SOLMEME itself. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) [Blockchain](/docs/learning/topics/blockchain/) covers the general mechanism; [Crypto](/docs/learning/topics/crypto/) covers wallets and private keys; [Vault](/docs/guides/vault/) is where Solana transactions actually happen day to day in SOLMEME. # SOLMEME > SOLMEME's origin story: a no-VC, no-presale token launched December 2023, now the platform behind a monthly trend-based coin drop. SOLMEME launched in December 2023 as a community-focused token for Solana enthusiasts — no pre-sale, no VC backing. The community grew past 3,305 members, and the project evolved from a single token into a platform that launches a new meme coin every month, built around whatever trend an AI scan finds breaking through the internet that month. ## From Community Token to Monthly Drops [Section titled “From Community Token to Monthly Drops”](#from-community-token-to-monthly-drops) SOLMEME started as one token. It’s now the platform behind a recurring monthly drop: each month, the team scans for what’s trending and launches a coin around it, keeping the same community and the same no-VC, no-presale approach the project started with. ## The Team [Section titled “The Team”](#the-team) | Name | Role | | ---------- | ------------------------------------------- | | CryptoDory | Administration, Support & Finance Director | | DamisLuv | Lead Community Manager | | CryptoRiz | Support Advocate | | BigBlack | Project, Marketing & Collaboration Director | | Jigsaw | Social Media Manager | | Kendrick | Graphic Designer / Video Editor | | RichJames | Lead Collaboration Manager | | Admirable | Collaboration Manager | | £leanor | Collaboration Manager | | Wizard | Collaboration Manager | | HYPERBEAST | Collaboration Manager | ## Timeline [Section titled “Timeline”](#timeline) * **July 2023** — Idea generation and concept making * **September 2023** — Team recruitment and development * **December 2023** — Mainnet token minted and listed * **January 2024** — Community building and whitelisting * **February 2024** — Token airdrops and NFT mints; monthly trend-to-token launch platform goes live Planned, not yet confirmed Staking, charity voting, and commemorative NFTs are listed as the project’s next milestone on the source page, but no ship date is given — treat as a stated intention, not a shipped feature. # Web3 > What Web3 means, how it differs from the web most people already use, and where SOLMEME sits in it. Web3 is the label for applications built around blockchain-based ownership and payments, instead of the account-and-database model most of today’s web runs on. The name contrasts it with “Web 2.0” — the era of centralized platforms (social networks, app stores, cloud services) where a company’s database is the final record of what you own or posted. ## The Core Difference [Section titled “The Core Difference”](#the-core-difference) On a typical Web 2.0 platform, your account, your in-game items, your posts — all of it lives in that company’s database. If the company deletes your account or shuts down, that data is gone. In a Web3 application, the underlying assets (tokens, NFTs) live on a [blockchain](/docs/learning/topics/blockchain/) that no single company controls — the app can disappear, but the on-chain asset itself doesn’t depend on the app staying online. ## What This Looks Like in Practice [Section titled “What This Looks Like in Practice”](#what-this-looks-like-in-practice) Strip away the buzzword and “Web3” usually just means three concrete things: connecting a crypto wallet instead of creating a username/password account, transactions that settle on-chain instead of in a company’s internal ledger, and assets you can move between different apps because they’re not locked inside one platform’s database. ## Where SOLMEME Fits [Section titled “Where SOLMEME Fits”](#where-solmeme-fits) SOLMEME’s core mechanics — holding tokens, the [Vault](/docs/guides/vault/)’s key-combination rewards, on-chain [Contracts](/docs/contracts/) — are Web3 by this definition: your holdings are recorded on Solana, not inside a SOLMEME-run account system, and you interact with them through a wallet, not a login. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) [Blockchain](/docs/learning/topics/blockchain/) covers the ledger this all runs on; [Solana](/docs/learning/topics/solana/) covers the specific chain; [Crypto](/docs/learning/topics/crypto/) covers the asset side. # Reference > Reference is SOLMEME's spec-style factual base — Sol Mamy's origin, and the six standards (Brand, Media, Mascot, Game, Talking-Head, Story & Universe) that hold every canonical fact. Reference is SOLMEME’s spec-style factual base — section, sub-section, fact. This page is its front door: a short introduction to who Sol Mamy is, then the map to all six standards, each holding the exact, authoritative answer for its own facet of the brand. ## Sol Mamy — SOLMEME’s Sherpa [Section titled “Sol Mamy — SOLMEME’s Sherpa”](#sol-mamy--solmemes-sherpa) Before any of this, Sol Mamy was a keeper — captain of the *Lunar Wanderer*, running the Lunar Vault between outposts, carrying whatever her civilization had collected. A shortcut through an uncharted debris field tore through her ship’s shielding and forced an emergency landing on Earth. The ship didn’t survive. Neither did the neural link she once used to pilot it — the same organ, permanently damaged, that she still uses today to recover information, storing everything she gathers in the Lunar Vault Module she now carries. SOLMEME — the monthly memecoin, her own husband’s project — was the first to pick up her signal. What started as one shipment became a pattern: SOL Launchpad projects, the Vault Defender community, and more, all finding their way into the same Vault, under the same promise she’d always kept — nothing collected is ever lost, and everything belongs to whoever actually earned it. That’s the same promise she recognized again in Earth’s on-chain systems: not a new invention, just a familiar shape in new material — a public, permanent record of what happened and who owns what. That recognition is what SOLMAMY is built from — not a bigger vault, but the same worldview, applied at ecosystem scale. She didn’t create SOLMEME. She’s the one leading it somewhere bigger — **this is SOLMEME’s sherpa.** [](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/)[](/docs/reference/mascot-book/reference-assets/) *8 real reference photos — see the full set in [Mascot Book — Reference Examples](/docs/reference/mascot-book/reference-assets/). Most of the origin story above is authored and internally consistent, not yet owner-confirmed as final canon — see [Story & Universe Book](/docs/reference/story-universe-book/) for the full account and each part’s real status.* ## The Six Books [Section titled “The Six Books”](#the-six-books) Brand Book The full brand system: foundation, identity, visual identity, logo, color, typography, imagery, voice & tone, messaging, digital surfaces, applications, and usage rules. [Read the Brand Book →](/docs/reference/brand-book/) Media Book Brand usage rules for video, social, news, and promotional content, plus mascot-in-media guidance. [Read the Media Book →](/docs/reference/media-book/) Mascot Book Sol Mamy: identity, appearance, costume, personality, voice, and usage guidelines. [Read the Mascot Book →](/docs/reference/mascot-book/) Game Book Brand-layer guidance for how the brand should present in game contexts — not a game design document. [Read the Game Book →](/docs/reference/game-book/) Talking Head Book Presenter identity, persona, voice, and on-screen communication guidance. [Read the Talking Head Book →](/docs/reference/talking-head-book/) Story & Universe Book Canonical lore and worldbuilding reference: characters, chronology, locations, factions, and canon status. [Read the Story & Universe Book →](/docs/reference/story-universe-book/) ## Who This Is For [Section titled “Who This Is For”](#who-this-is-for) Anyone who needs the exact, settled answer rather than a paraphrase: Creators making brand-consistent content, partners who need press-kit-accurate facts, Ambassadors representing SOLMEME publicly, and AI agents that need to cite something as canonical rather than inferred. ## Where to Go From Here [Section titled “Where to Go From Here”](#where-to-go-from-here) Each book above links to its own chapters. Some material within these books is explicitly marked Proposed, Open, or Not Yet Determined rather than settled fact — that labeling is preserved deliberately, not a gap to be filled in by inference. # Brand Book > The canonical brand reference for SOLMEME/SOLMAMY — purpose, scope, chapter index, and the SOLMAMY vs SOLMEME terminology distinction. Brand Book v1.1 New: a [Do & Don’t](/docs/reference/brand-book/do-and-dont/) chapter, plus real reference photos on [Color](/docs/reference/brand-book/color/) and [Imagery Principles](/docs/reference/brand-book/imagery/). ## Purpose [Section titled “Purpose”](#purpose) This is the authoritative reference for SOLMAMY’s brand — the planned company/ecosystem Sol Mamy is mascot of, a separate entity from SOLMEME (the peripheral, monthly-released memecoin persona; see Terminology below for the full distinction) — what it stands for, how it looks, how it sounds, and how it must and must not be used. It is written for two audiences at once — a person deciding how to present the brand, and an AI agent that needs to extract an exact, unambiguous rule. This book is the **canonical root** for everything that applies across the whole brand, regardless of context: color, typography, the logo/mark policy, and general voice principles. The Mascot Book, Media Book, Game Brand Documentation, and Talking-Head Brand Documentation all draw their cross-cutting facts from here — they never redefine them. ## Scope [Section titled “Scope”](#scope) **In scope**: brand foundation (mission, vision, values, positioning), visual identity (color, typography, logo/mark), voice and tone, and general usage rules that apply everywhere the brand appears. **Out of scope**: the character Sol Mamy’s own identity, appearance, and personality (see **Mascot Book**); how the brand applies inside a specific medium like video, games, or a talking-head presenter (see **Media Book**, **Game Brand Documentation**, **Talking-Head Brand Documentation** — each cites this book and adds only what’s specific to that context). ## How to read this book [Section titled “How to read this book”](#how-to-read-this-book) Every claim in this book carries an explicit status: * **Canonical** — settled, owner-confirmed or independently source-verified. Use as-is. * **Proposed, pending owner decision** — drafted and evidence-backed, but not yet formally approved. Usable as a working direction; do not present as final. * **Not yet determined** — a real gap. No source exists yet. Do not invent a value to fill it. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book is a source of truth for brand facts; it does not itself grant, license, or transfer any right. Building something from it does not change who owns the system it came from. ## Chapters [Section titled “Chapters”](#chapters) 1. [Foundation](/docs/reference/brand-book/foundation/) — mission, vision, values, positioning, promise, audience, brand personality, story, principles, tagline 2. [Identity](/docs/reference/brand-book/identity/) — short summary/map to the rest of this book 3. [Visual Identity](/docs/reference/brand-book/visual-identity/) 4. [Color System](/docs/reference/brand-book/color/) 5. [Typography](/docs/reference/brand-book/typography/) 6. [Logo & Mark](/docs/reference/brand-book/logo/) 7. [Digital Surfaces](/docs/reference/brand-book/digital-surfaces/) — favicon logic, Open Graph images 8. [Imagery Principles](/docs/reference/brand-book/imagery/) — also contains this book’s Iconography and Graphic Devices sections (bundled into this one file) 9. [Messaging Principles](/docs/reference/brand-book/messaging/) 10. [Voice & Tone](/docs/reference/brand-book/voice-and-tone/) 11. [Applications](/docs/reference/brand-book/applications/) 12. [Usage Rules](/docs/reference/brand-book/usage/) 13. [Do & Don’t](/docs/reference/brand-book/do-and-dont/) — consolidated quick-reference gallery of the Do/Don’t rules already established across this book 14. [Quick Reference](/docs/reference/brand-book/quick-reference/) ## Terminology [Section titled “Terminology”](#terminology) * **SOLMEME** — the memecoin/product released monthly, personified as Sol Mamy’s husband; lives on `solme.me`. Peripheral to SOLMAMY; its site vocabulary is never SOLMAMY brand voice. * **SOLMAMY** — the planned company/ecosystem Sol Mamy is mascot of. Has not launched. Planned core: Launchpad + Analytics + Reputation. Ecosystem/community layer (not core): Vault Defender, Community, Documentation. SOLMEME is one relationship within the ecosystem, not its foundation. * **Sol Mamy** — the character. See **Mascot Book** for her full identity; this book never redefines her. These two names are never used interchangeably. Where a document needs to be precise about which one it means, it says so explicitly. # Applications > How downstream brand documents — Mascot, Media, Game, and Talking-Head — inherit this book's canonical facts rather than defining their own. ## Rule [Section titled “Rule”](#rule) The brand presents consistently regardless of channel. Every downstream document (Media Book, Game Brand Documentation, Talking-Head Brand Documentation) applies this book’s Foundation, Voice & Tone, Logo & Mark, and Color System exactly as defined here — each adds only the specific application rules its own medium needs. ## Use [Section titled “Use”](#use) * Any new channel or product surface starts from this book’s canonical facts, not from a fresh interpretation of the brand. * Where a medium-specific document needs a rule this book doesn’t yet have an answer for (e.g. exact color hex, typography), it states the same “not yet determined” status — it does not invent an answer locally. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not let a channel-specific document (Media, Game, Talking-Head) introduce a brand fact — a color, a tagline, a voice trait — that doesn’t already exist in this book. If a genuinely new need arises, it belongs in this book first, then gets cited. ## Application rules — real status per named format (checked directly, not assumed) [Section titled “Application rules — real status per named format (checked directly, not assumed)”](#application-rules--real-status-per-named-format-checked-directly-not-assumed) “No rendered mockup exists” and “no rule exists at all” are two different things — several formats below (Social/Avatar, Community/event, and part of Web) already have a real, sourced rule, cited from where it’s actually owned, even though no rendered template/mockup exists yet for any of them. The table below distinguishes RULE (does a real policy already exist, and where) from EXAMPLE (does a rendered/produced asset exist). No rendered example is fabricated to fill a gap, and no format’s real maturity is rounded up. | Format | Rule | Example exists? | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Web | Mixed, not uniformly CANON: the base rule (mascot silhouette is the sole mark, every favicon variant is a presentation of it) is CANON, inherited from Logo & Mark. The 2 existing live favicon assets are real (`digital-surfaces.md` §Resolved) but one is flagged legacy/unauthorized/off-canon-color there, not a clean resolution. The broader favicon-form and Open Graph system is **RECOMMENDED**, `digital-surfaces.md`’s own real status label — but that document is explicit this isn’t an open owner-approval question awaiting a decision: “Per direct owner instruction, that framing is withdrawn” (quoted verbatim). The gap is one of this book’s own status vocabulary (RECOMMENDED, not yet elevated to CANON), not a pending yes/no. *(Source: `digital-surfaces.md`, this book — cited, not duplicated here.)* | No rendered full-page mockup; the 2 favicon assets themselves are real and live (one CANONICAL, one legacy/unauthorized). | | Social (Discord/Twitter/Telegram) | CANON — per-platform allowed usage already named: Discord (role names, sticker set, bot avatars, channel icons, event announcements), Twitter/X (profile avatar and header, meme/GIF/reaction posts, announcements, engagement replies), Telegram (sticker pack, reaction GIFs, bot avatar, announcement posts). *(Source: Mascot Book — Usage, “By channel” — owned by Mascot Book, cited here, not re-derived or duplicated.)* | No rendered social template/banner exists for any platform. | | Avatar | CANON, partial — Twitter/X profile avatar and Discord/Telegram bot avatars are named real use cases in the same Mascot Book usage list above. | No cropped/sized avatar asset has actually been produced yet — a real production gap, not a documentation one. | | Community / event | CANON — Media Book already documents this in detail: community-site usage (onboarding, rules/mechanics guides, rank-progress visualization, event announcements) and a confirmed gamification-activity table (Treasure Hunt, Meme Battles, Quests, Trading Contests, Mini-games, Charity Events, each with the mascot’s specific role), plus a seasonal “Treasure Hunter” role. *(Source: Media Book — Social, “Community site usage” / “Community gamification activities” — owned by Media Book, cited here, not re-derived or duplicated.)* | No rendered event-graphic template exists yet. | | UI | NOT APPLICABLE to this book — `community.solme.me`’s own docs-site UI (Starlight framework) uses its own built-in navigation-icon component, unrelated to SOLMAMY brand iconography (see Imagery Principles — Iconography) — owned by the Community Docs surface, not this Brand Book. | N/A | | Mobile | NOT YET DETERMINED | No | | Presentation | NOT YET DETERMINED | No | | Partner / press | NOT YET DETERMINED for a real partner/press relationship (none exists pre-launch), but one thin, PROPOSED-status piece of related material exists: Mascot Book’s Event-specific costume variants table ties a “Business/formal” variant to “Partnership announcements” and a “Travel” variant to “Partnership/expansion announcements” — both explicitly labeled “proposed, not yet owner-confirmed” in their own source, not a settled rule. *(Source: Mascot Book — Costume & Design System, “Event-specific variants.”)* | No | | Campaign | NOT YET DETERMINED — no campaign has been run yet; premature to mock one | No | | Merch / print | CANON, partial — “Community merch, if produced” is a named real allowed-use case. *(Source: Mascot Book — Usage, “Additional allowed usage.”)* No merch has actually been produced, and no print-specific rule (materials, sizing, CMYK) exists yet. | No | | Documents | NOT YET DETERMINED | No | Producing a rendered example for any format where the rule already exists (Web, Social, Avatar, Community/event, Merch/print) is real visual-asset work, out of scope for a documentation-only pass — recorded here so the gap is explicit rather than silently absent. Formats with no rule yet stay open; none is filled with an invented policy. ## What a real application example looks like, once one is produced [Section titled “What a real application example looks like, once one is produced”](#what-a-real-application-example-looks-like-once-one-is-produced) Not a current SOLMAMY example — a sourced principle for future production, so a real mockup isn’t designed from a blank assumption when the time comes. Discord’s own brand page ends its Logo/Color/Clearspace sections with a real, downloadable banner asset (“for discussing Discord across digital channels”) — an illustrated application of the brand, not a bare logo file. Separately, fewer, load-bearing elements — each carrying a stated use-rule — reads as more professional than a dense page. Together: a future rendered application example should (a) show the brand actually applied in context, not a bare asset dump, and (b) carry its own one-line stated use-rule, the same discipline already applied to the Social/Avatar rules above. ## Cross-references [Section titled “Cross-references”](#cross-references) * Web favicon/Open Graph rules: **`digital-surfaces.md`, this book** * Per-channel usage rules (Discord/Twitter/Telegram), avatars, merch allowance: **Mascot Book — Usage** * Event-specific costume variants (partnership/campaign-adjacent occasions, all PROPOSED): **Mascot Book — Costume & Design System** * Community-site and gamification-activity usage: **Media Book — Social** * Character-specific presentation: **Mascot Book** * Media/video/social/news application: **Media Book** * In-game brand application: **Game Brand Documentation** * Talking-head/presenter application: **Talking-Head Brand Documentation** *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Color System > SOLMAMY's costume color direction — cyan/teal, pearl-white, and pink — and its relationship to the site's separate UI color tokens. ## Rule [Section titled “Rule”](#rule) The brand’s visual color canon is **pearl-white (Base), cyan/teal (Core), and pink (Accent)** — no gold in this costume/brand palette. This chapter is about the mascot’s own costume/brand tone specifically; it is not the site’s own separate UI/implementation color system (buttons, backgrounds, layout), which is a distinct question — see Site UI color/typography system below. (One live, currently-CANONICAL site asset — the main-site favicon — does carry a gold outline; that is a separate, already-classified exception, not a color this palette includes — see Known cross-file gap below.) *(Source: established directly from the approved reference images.)* ## Meaning [Section titled “Meaning”](#meaning) The mascot’s suit color is not an independently chosen costume color — it draws from the same core cyan/teal named above. Any document citing “the brand color” and any document citing “the mascot’s suit color” are describing the same underlying tone family, not two separate palettes. The exact digital token values (hex/RGB, for production/UI use) were the one open question here; they are now resolved — see Use below. ## Use — tiered palette [Section titled “Use — tiered palette”](#use--tiered-palette) | Tier | Color | Hex (measured) | Notes | | ----------- | ----------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Core** | Cyan/Teal | `#12CFE4` | Face-membrane glow ring. A neon/glow effect (bright core, dark halo, some bloom) rather than a flat matte material — this is the averaged *saturated-cyan* reading, not a single peak pixel. *(389 px sample, filtered for saturated cyan; the single brightest pixel in this region, `#FFFEFE`, is blown-out white bloom and was correctly excluded as non-representative.)* | | **Base** | Pearl-white | `#E7E4E7` | Averaged across two independent garment regions. *(15,613 px total: chest `#ECE8E9`, helmet dome `#E2E0E5`.)* | | **Accent** | Pink | `#E1599C` | Clan color and a genuine multi-element accent — bow, collar/lapel trim, gloves, belt/pouch, boot panels, not confined to one element. *(13,400 px sample, bow + collar/lapel trim region, filtered for saturated magenta-pink.)* | | **Neutral** | N/A | — | No neutral/grey tier is defined in the approved costume palette — not invented here. | Values are extracted by direct pixel measurement against the canonical reference image, not invented or asserted on faith: each costume region was filtered for saturated, non-edge, non-specular pixels (excluding gloss highlights, glow bloom, and anti-aliased boundaries), then averaged; sample sizes are given above so the measurement is checkable. **Known limitation, disclosed not hidden**: the Core cyan value above is a first-pass reading of a light-emitting element, not a flat surface. If a flatter, non-glowing cyan surface is later identified as more representative (e.g. a solid trim panel rather than the light-emitting ring), it should be re-measured and this table treated as a first pass, not final production-grade output. ## Example [Section titled “Example”](#example)  *Rendered swatches of the three measured values above — PROPOSED, not asserted as final canonical beyond what the extraction supports (see Not yet determined below). Generated directly from the measured hex values (Python/PIL), not independently redrawn or estimated.* ## Site UI color/typography system (distinct from this chapter’s scope) [Section titled “Site UI color/typography system (distinct from this chapter’s scope)”](#site-ui-colortypography-system-distinct-from-this-chapters-scope) The only current target site for this documentation is `community.solme.me`, with its documentation surface at `community.solme.me/docs/` — `solmamy.com` is not an established current site for this brand. `tokens.json` is carried forward as **HISTORICAL/REFERENCE material for the site’s own UI system** — buttons, layout, backgrounds, vault-tier tags, site typography — not this chapter’s mascot palette. It is a **predecessor snapshot of `community.solme.me`’s own design lineage** (archived after the site’s AstroWind rebuild), genuinely relevant reference material to hand to whoever owns the live `community.solme.me`/`docs/` theme, but **not confirmed as that site’s current, live implementation** — the rebuild it predates may have changed values, and this Brand Book does not inspect or edit that live repository to re-verify it. Sol Mamy’s own costume palette (this chapter’s actual scope, Use above) is resolved independently from the approved reference images, and is untouched by any of the above. `tokens.json`’s values must never be presented as, or confused with, mascot colors in any downstream document. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Whether the extracted values above should become this project’s CANONICAL digital tokens, or stay PROPOSED pending an owner glance at the swatches — a real, small confirmation step, not a creative decision (the *sourcing method* is already settled (see Rule above); whether to *formally adopt* the specific measured numbers is a quick owner check, not reopening the question). * Whether `tokens.json`’s two source-flagged values (`contextual_ui.charity_status_green`, unconfirmed pending sign-off in the source itself; `colors.accent_lavender`, recommended for renaming to avoid confusion with the mascot’s separately-retired “lavender” costume color) are carried forward as-is or adjusted — a real open item, not decided here. * A formal light/dark or accessibility-contrast palette for the site UI. * Color usage rules for backgrounds, states (hover/active/disabled), or data visualization beyond what `tokens.json` already specifies. Do not invent new hex codes beyond the measured values above; do not use `tokens.json`’s site-UI values as a substitute for the mascot’s own costume palette. ## One live gold exception, explained [Section titled “One live gold exception, explained”](#one-live-gold-exception-explained) This chapter states **no gold in the costume/brand palette** (Rule above). This holds consistently across Mascot Book — Costume, Mascot Book — Visual Identity, and this chapter: no gold anywhere on the suit itself. **Separately, one real, live exception exists and is not a contradiction of the above**: the main-site favicon (see Digital Surfaces) carries a gold outline and is currently CANONICAL. Its classification rests on two grounds unrelated to the costume palette (species match, communicator-role match) — the favicon’s gold is a legacy asset detail under its own separate classification, not a color this chapter’s costume palette includes or endorses for new work. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Digital Surfaces > Favicon and Open Graph image logic for community.solme.me and its /docs/ surface, including recommended meta/SEO baselines. ## Canonical — Base rule (inherited, not new) [Section titled “Canonical — Base rule (inherited, not new)”](#canonical--base-rule-inherited-not-new) Per Brand Book — Logo & Mark, the mascot’s silhouette is the sole visual brand mark; no separate logo/wordmark exists. Every favicon variant below is a presentation of that same one mark — never a new, independent logo per site. ## Resolved — Existing favicon assets [Section titled “Resolved — Existing favicon assets”](#resolved--existing-favicon-assets) Two live favicon assets already exist, both raccoon-face icons (same mascot species): the main-site favicon (gold outline, chat-bubble prop) is owner-directed CANONICAL and stays current; the docs-site favicon (purple glow, holding a book) is legacy/unauthorized and off-canon-color, but its “book” motif independently confirms the First Ledger direction recommended below for the docs site — a future palette/motif update, not a current blocker. ## Proposed — Favicon form [Section titled “Proposed — Favicon form”](#proposed--favicon-form) Of the candidate forms (cropped representation / simplified icon / brand icon / full mascot / separate UI mark), the base layer should be a **simplified, cropped mascot-face icon** — reasoning: Mascot Book — Reference Assets already establishes a real, sourced requirement that the design “must read correctly as a single-color silhouette at 16px, from a 10-foot viewing distance.” A favicon (typically rendered at 16–32px) is functionally the most extreme real-world test of that exact requirement — so the favicon should be the mascot’s face/mask silhouette (the highest-recognition, most compact part of her already-established silhouette), not a full-body reduction and not an unrelated “separate UI mark,” which would itself violate the existing “no separate logo” rule. ## Current scope — `community.solme.me` and `community.solme.me/docs/` [Section titled “Current scope — community.solme.me and community.solme.me/docs/”](#current-scope--communitysolmeme-and-communitysolmemedocs) The current scope is one site, `community.solme.me`, with its documentation living at `community.solme.me/docs/`. There is no second, separate `app.` or `community.` domain in current scope. **Shared brand DNA**: per Brand Book — Logo & Mark, the mascot’s silhouette is the sole visual brand mark, with no separate logo/wordmark — this holds identically for the main site and its `/docs/` surface, because a documentation subpath is still the same site, not a different brand. The base rule above (a simplified, cropped mascot-face silhouette as the favicon’s base layer, tested at 16px) applies to both surfaces unchanged. **Documentation-surface expression**: within that shared base, `/docs/` may carry a distinguishing accent consistent with its actual function — recording/reference — without inventing a new brand. If a Vault-artifact motif is wanted for that accent, the **First Ledger** (Story & Universe Book — the original manifest recording everything ever collected) is the best-reasoned candidate on file, since a documentation surface *is* a ledger, close to literally — but this is a design option, not a current, decided asset; no image exists. **Site UI color/typography**: `tokens.json`, the site’s own UI/implementation color and typography values (buttons, backgrounds, layout), is historical/reference material from the site’s pre-rebuild design lineage — not a confirmed description of the current live implementation, and not something this Brand Book owns or verifies. See Color System — Site UI color/typography system for the full scope boundary. ## Recommended — Open Graph (social preview) image [Section titled “Recommended — Open Graph (social preview) image”](#recommended--open-graph-social-preview-image) * **Dimensions**: 1200×630 (industry standard, so the asset renders correctly across Twitter/X, Discord, Telegram, and generic link-preview crawlers without per-platform variants). * **Mandatory mascot rule (follows directly from existing canon, not new)**: per Brand Book — Logo & Mark, no separate logo exists, so every OG image must show Sol Mamy’s mark — never a wordmark-only or logo-free treatment. * **Recommended template**: a shared visual base (Sol Mamy + background treatment), with the optional `/docs/`-specific accent from the current-scope section above if one is ever produced — one system, not per-domain variants, since there is only one current site. * **Per-page-type variant, recommended**: one shared OG template for the documentation site (title + book/chapter name overlaid on the shared base) rather than a bespoke image per article — matching how the docs site itself is structured (many chapters, one system). * **Genuinely left to production/design, not decided here**: exact typography treatment, precise layout, and the actual asset file — this chapter specifies the requirement and logic, not the finished image. ## Current — The brand recognition principle for `community.solme.me` and `/docs/` [Section titled “Current — The brand recognition principle for community.solme.me and /docs/”](#current--the-brand-recognition-principle-for-communitysolmeme-and-docs) How does a visitor know `community.solme.me` and `community.solme.me/docs/` are the same brand, not two unrelated things? **Shared DNA = the mascot-face base mark** (Brand Book — Logo & Mark), present identically on both. No accent system is required to answer this — a documentation subpath of the same site is already the same brand by default; an artifact-based accent on `/docs/` (the First Ledger candidate above) is an optional future refinement, not something needed to close this question. ## Recommended — General meta/SEO requirements [Section titled “Recommended — General meta/SEO requirements”](#recommended--general-metaseo-requirements) Every page’s title tag should include “SOLMAMY” or the specific product name (Vault, Launchpad, docs) for recognizability in search results and browser tabs; meta descriptions follow each page’s own content (Brand Book does not template copy it doesn’t own). A dedicated SEO scoping pass remains a real, separate future task if more than this baseline is needed. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Do & Don't > Consolidated Do/Don't guidance from Logo, Color, Typography, Imagery, Iconography, and Applications — one place, no new rules. ## Purpose [Section titled “Purpose”](#purpose) This chapter introduces no new rule. It consolidates the Do/Don’t guidance already established, separately, across this book’s own completed chapters (Logo & Mark, Color System, Typography, Imagery Principles, Iconography, Applications) and the character-specific rules Mascot Book owns — into one place a reader can scan without opening every chapter individually. Every item below names its real source; nothing here is decided for the first time in this file. *(This chapter doesn’t solve the broader “no rendered misuse/anti-example image” gap — no rendered misuse image exists anywhere in this project yet, for any rule — but it does put every existing prose rule in one place and shows the real “Do” images that do exist, so the gap is visible in one location instead of scattered across seven chapters.)* ## How to read this chapter [Section titled “How to read this chapter”](#how-to-read-this-chapter) Same status vocabulary as the rest of this book (see Brand Book index): **CANON** (settled, sourced), **PROPOSED** (drafted, evidence-backed, not yet owner-confirmed), **OPEN** (no source exists — not filled in here). A rule can be CANON as a *policy* while the specific value it governs is still PROPOSED (color is the clearest case below) — the two are tracked separately, not conflated. **A note on the word “CANON” itself**: a settled rule is tagged CANON below whenever its source states it as plain, settled fact — whether or not that source happens to use the literal word “CANON” for that specific sentence. This is consistent with how the term is used across this Brand Book generally, not a stricter or looser standard applied only here. Checked directly, chapter by chapter: `logo.md`’s Rule/Don’t never uses the word at all. Mascot Book’s Allowed usage section doesn’t either; its Prohibited usage section does use the word twice, but only inside one bullet about lore-fact status (ship name/accident cause), not the bullets this chapter cites for the headline Do/Don’t. Color’s actual “do not invent new hex codes” sentence doesn’t use the word, though the word does appear elsewhere in that same file section on an unrelated point (whether to formally adopt specific hex numbers). Where a source’s own wording is worth quoting directly (Imagery’s render-style rule is the clearest case below), that’s flagged inline — it isn’t a sign the other CANON tags in this chapter are less rigorous, only that this one source happens to say so explicitly. ## Logo & Mark [Section titled “Logo & Mark”](#logo--mark) **Do**: use the mascot’s own canonical silhouette as the sole visual mark, in any context. — CANON. *(Source: `logo.md` §Rule.)* **Don’t**: * Commission or design a separate logo, wordmark, or symbol as an alternative to the mascot. * Alter the base design without approval, or present it in a distorted or unattractive rendering. * Alter the mask, ears, tail, or silhouette proportions in any presentation of the mark. CANON. *(Source: `logo.md` §Don’t, citing Mascot Book — Usage.)* **Real visual example** (Do): the same image `logo.md` embeds for this purpose.  *Illustrative, not an approved canonical reference — see `logo.md` §Example for the full caveat (a known pink-bow/rank-glyph deviation on this specific image). Registered as `BRAND-A05` in `asset-registry.md`.* **Real visual example (Don’t)**: does not exist. No rendered misuse image (a distorted/stretched mark with a violation indicator) has been produced for this or any other rule in this book — a real, disclosed gap (`BRAND-RULE-01`, tests PARTIAL), not filled here with a fabricated one. ## Color [Section titled “Color”](#color) **Do**: use the tiered palette — Core (Cyan/Teal `#12CFE4`), Base (Pearl-white `#E7E4E7`), Accent (Pink `#E1599C`). — the *direction* (which three tones) is CANON; the specific *measured hex values* are PROPOSED, pending a quick owner confirmation, not a creative decision. *(Source: `color.md` §Use.)* **Don’t**: * Invent new hex codes beyond the measured values. * Use `tokens.json`’s site-UI values as a substitute for the mascot’s own costume palette. CANON (procedural rule — this holds regardless of the PROPOSED/CANON status of the specific hex values above). *(Source: `color.md` §Not yet determined.)* **Real visual example** (Do): the same swatch image `color.md` embeds.  *Registered as `BRAND-A01` in `asset-registry.md` — reused here, not regenerated; see that registry’s note on its second placement.* **Real visual example (Don’t)**: does not exist — no off-palette misuse render has been produced. ## Typography [Section titled “Typography”](#typography) **Do**: nothing exists to show here yet — no typeface is approved for SOLMAMY’s brand identity (OPEN, real gap, no invented placeholder shown as settled). One narrower, genuinely CANON exception: the wordmark (“SOLMAMY”) is always rendered fused, two-toned — “SOL” in pink, “MAMY” in cyan — never wrapped or stacked. *(Source: Story & Universe Book’s Lunaris Insignia System wordmark typography rule.)* **Don’t**: * Invent a typeface, size, or weight to fill the gap, anywhere, in any document. * Adopt `tokens.json`’s or the V1 brief’s typography values for SOLMAMY’s brand identity — those describe SOLMEME’s own site, a separate entity. * Treat this documentation’s own current markdown-viewer rendering as an implicit brand choice. CANON (procedural rule). *(Source: `typography.md` §Don’t.)* **Real visual example**: none — no typeface exists to specimen, and no rendered example of the wordmark’s two-tone rule has been produced as a standalone image (it is currently only demonstrated inline, in text form, in `typography.md`, and pictorially wherever the wordmark itself appears in a full character image such as the Logo/Mascot example above). ## Mascot (cited from Mascot Book, not re-derived) [Section titled “Mascot (cited from Mascot Book, not re-derived)”](#mascot-cited-from-mascot-book-not-re-derived) Mascot Book owns character-specific rules; this book cites, it does not restate them in full. Full lists: Mascot Book — Usage. **Do**: depict Sol Mamy in her approved costume (R1, or approved secondary R2) for first-party SOLMAMY/SOLMEME context, with the Lunar Vault Module as her signature prop “at whatever state matches the relevant rank context.” — CANON. **Don’t** (headline items only — see Mascot Book — Usage for the complete list): * Alter the mask, ears, tail, or silhouette proportions. * Present a sealed dome-visor helmet (superseded; the open-face hard-shell helmet is canonical). * Reintroduce the retired treasure-chest prop (superseded by the Lunar Vault Module). * Invent new family members, ship name, accident cause, or antagonist names beyond what Story & Universe Book has already authored — and specifically for the two that ARE already authored (ship name, accident cause), do not present them as CANON rather than PROPOSED. * Use in political/adult/controversial content, to imply financial-gain promises, to advertise scam projects, or in hate speech/harassment/discrimination. CANON. *(Source: Mascot Book — Usage, Prohibited usage / Additional prohibited usage.)* **Real Do/Don’t example** (textual, already CANON, not invented here): > **Do**: “Sol Mamy, in her canonical R1 suit, standing beside the Lunar Vault Module at its Glowing state.” **Don’t**: “Sol Mamy, wearing a sealed astronaut dome helmet, guarding a treasure chest.” — both details contradict the canonical reference. *(Source: Mascot Book — Usage, Do/Don’t example — quoted verbatim, not paraphrased.)* ## Imagery [Section titled “Imagery”](#imagery) **Do**: when the mascot appears in an image, match her own established render style — semi-realistic, polished, detailed treatment (never flat-cartoon, never hand-drawn/sketch), house lighting (single source, top-left, \~45°). — CANON as a strong, sourced claim (the literal word “CANON” does not appear in the source itself — see `imagery.md`’s own disclosure). *(Source: `imagery.md` §Rule, citing Mascot Book — Visual Identity.)* **Don’t**: * Invent a photography or illustration style to fill the general (non-mascot) imagery gap. * Promote any of the 67 production images to Brand-canonical status — they remain Mascot Book’s own working examples. * Treat “no general imagery rule exists yet” as license to use any arbitrary imagery — the mascot-usage prohibitions above still apply. CANON. *(Source: `imagery.md` §Don’t.)* **Real visual example** (Do): the same image already used above for Logo & Mascot also demonstrates this rule’s treatment-style half (not its lighting-direction half — `imagery.md` discloses this caveat honestly; not repeated in full here). Registered as `BRAND-A05` (this chapter) / `BRAND-A03` (`imagery.md`) — same physical file, cited for a third distinct purpose, not re-embedded a third time in this chapter to avoid needless duplication of the same image. ## Iconography / Graphic Devices [Section titled “Iconography / Graphic Devices”](#iconography--graphic-devices) **Do**: the Status Crest — three stacked chevrons, apex up, blue-to-cyan/indigo gradient glow, at eight fixed costume locations (corrected 2026-09-03, twice: count raised from seven to eight, then restated as the real unified count rather than an additive “seven plus one” framing; color word corrected to match Mascot Book’s own exact wording) — is Sol Mamy’s own real icon. — CANON. *(Source: Mascot Book — Visual Identity, cited in `imagery.md` §Iconography.)* **Don’t**: * Treat the Status Crest as free-standing brand iconography beyond what Mascot Book documents. * Invent an icon set, icon grid, or icon-usage rule to fill the gap. * Adopt the separate SOLMEME site’s real Lucide/badge icon system for SOLMAMY. * Promote the legacy docs-site favicon (purple glow, book) to canonical status. CANON. *(Source: `imagery.md` §Iconography, §Don’t. Note: “SOURCE-DERIVED” is not a tag `imagery.md` itself uses for these items — corrected here to avoid implying a specific source label that doesn’t exist; each item traces to a real fact stated in that section, per the house convention noted above.)* **Graphic Devices**: no rule exists for SOLMAMY specifically — a real source system exists for the separate SOLMEME site (disclosed, not adopted; see `imagery.md` §Graphic Devices) — nothing is shown here as a SOLMAMY Do or Don’t, because none exists. OPEN. **Real visual example** (Do): the Status Crest shown in its real costume context.  *Registered as `BRAND-A06` in `asset-registry.md`.* ## Applications [Section titled “Applications”](#applications) **Do**: any new channel or product surface starts from this book’s canonical facts, not a fresh interpretation of the brand. — CANON (structural rule). *(Source: `applications.md` §Use.)* **Don’t**: let a channel-specific document (Media, Game, Talking-Head) introduce a brand fact — a color, a tagline, a voice trait — that doesn’t already exist in this book. — CANON. *(Source: `applications.md` §Do not use.)* Per-format maturity (Web, Social, Avatar, Community/event, Merch/print real; Mobile, Presentation, Partner/press, Campaign, Documents open; UI marked NOT APPLICABLE to this book — it’s `community.solme.me`’s own surface) is not repeated in full here — see `applications.md`’s own table, the source of truth for that breakdown. **Real visual example**: none — no rendered application mockup exists for any format yet, per `applications.md`’s own disclosure. ## What this chapter does not cover [Section titled “What this chapter does not cover”](#what-this-chapter-does-not-cover) * Voice & Tone / Messaging Do/Don’t — visual areas only in this chapter. Brand Book’s own Usage Rules chapter already carries a Do/Don’t pair for institutional voice — not duplicated here. Its two halves carry different real status: the “Don’t” half (not implying a live product that doesn’t exist) is genuinely Canonical, per Foundation — Status; the “Do” half (using the institutional voice register) is Proposed, SOURCE-DERIVED, pending final owner approval — not yet formally Canonical, per Voice & Tone’s and Foundation’s own current tags. * No proposal anywhere in this book is promoted to a settled rule by appearing in this consolidation — every status tag above matches its source chapter’s own current status, unchanged. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Foundation > SOLMAMY's durable foundation — mission, vision, trust philosophy, values, principles, and what SOLMAMY is not. Pre-launch, pending final owner sign-off. ## Status [Section titled “Status”](#status) **Working pre-launch strategic foundation — Proposed, pending final owner sign-off.** SOLMAMY has not launched: there is no operating company, live product, user base, or revenue today. This chapter describes what SOLMAMY is being designed to be, not a claim about a company that already exists. Full working-draft detail and source classification lives in `research/SOLMAMY_Brand_Foundation_v0.4.md`; this chapter is that draft’s reader-facing summary, not a second independent source. Most of what follows is real — traceable to an actual owner-authored strategic draft — but “traceable to an owner-authored source” and “formally approved as Canonical” are different things: the source draft’s own status is explicit that nothing in it is yet Canonical. Every status tag below is **Proposed** unless a fact is independently confirmed Canonical by a different, already-resolved source (the one case: Sol Mamy’s own personality traits, Mascot Book’s own real Canon, cited not re-derived). The content below is built from the owner’s own strategic drafts and the corrected Story & Universe canon — not from `solme.me`’s own site copy and product terminology (Vault mechanics, tokenomics language, UI text), which belongs to that separate, peripheral persona (SOLMEME) and is never brand substance here. (This is a different, broader point than the crypto-slang register question addressed in Voice & Tone and the Messaging anchor below — that’s about which vocabulary suits which of SOLMAMY’s own two voice registers, not about solme.me’s site content generally.) ## How this chapter is organized [Section titled “How this chapter is organized”](#how-this-chapter-is-organized) Two layers, kept explicitly separate per direct owner instruction — **this is the single most important structural fact in this chapter**: * **The durable foundation** — why SOLMAMY exists, what it believes, what problem it addresses. This does not change if the current products change. * **The current planned products** — Launchpad, Analytics, Reputation, and the wider ecosystem. These are today’s designed expression of the durable foundation, not the foundation itself. They are expected to evolve. ## The durable foundation [Section titled “The durable foundation”](#the-durable-foundation) **Why SOLMAMY is being created** — *Proposed (RECOMMENDED — this project’s own synthesis, derived from already-approved architecture in `00/SOLMAMY_MASTER_CAUSAL_SYSTEM.md`, not itself a separate owner-authored source statement)*: people exchanging value as strangers need a way to know where something genuinely came from and who has actually earned a claim to it. SOLMAMY is being designed to make that checkable instead of assumed. **Core problem** — *Proposed (RECOMMENDED, same source basis as above)*: strangers exchanging value with no shared authority to verify claims of origin or trustworthiness. (This is the general form of a narrower, owner-stated version of the same problem — see Mission below.) **Trust philosophy** — *Proposed (SOURCE-DERIVED from `Business_and_Product_Foundation_v0.1.md`, owner-authored — not yet formally approved, pending final owner approval)*: a trust signal is meant to say *“this is what we verified,”* never *“this will succeed.”* Curation is never a guarantee. Information about a project is categorized — Verified / Declared / Observed / Unknown — never collapsed into a false Safe/Unsafe label. **Strategic value lens** — *Owner-directed (not yet formally Canonical, pending final owner approval)*: **Data → Risk → Trust → Discovery → Capital.** This is a lens for how value could be created, not a roadmap or a required build order: * **Data** — what actually happened, recorded so it can be checked later. * **Risk** — what could go wrong, made visible instead of hidden. * **Trust** — a track record that has to be earned and can be checked, never promised. * **Discovery** — finding what’s genuinely worth attention, once the above make that judgment possible. * **Capital** — value moving toward what has earned trust, not toward whatever is loudest. **Brand Values** — *Proposed (SOURCE-DERIVED, owner-authored — pending final owner approval)*: Transparency, Verification, Fair Access, Accountability, Progress. **Brand Principles** — *Proposed (SOURCE-DERIVED, owner-authored — pending final owner approval)*: Evidence over claims; transparency over complexity; risk visibility before participation; infrastructure before speculation; long-term relationships over one-time transactions. **What SOLMAMY is not** — *Proposed (SOURCE-DERIVED, owner-authored — pending final owner approval)*: not a casino; not a generic token factory; not a hype generator; not a promise of returns; not an anonymous listing directory; not a platform that treats market cap as cash or hides liquidity control; not a platform that guarantees project success. It does not compete on “more tokens,” “faster creation,” “100x,” “cheapest launch,” or “maximum hype.” **Relationship to Sol Mamy and Story & Universe** — *Proposed (RECOMMENDED, same source basis)*: Sol Mamy is the originator and worldview-carrier — her own founding promise (nothing collected is ever lost, and everything belongs to whoever has actually earned it) is the same worldview SOLMAMY is being built to apply, using Earth’s own tools. SOLMAMY is the *institutional* expression of that worldview, not a retelling of her story and not a claim that her story is real corporate history. See **Mascot Book** and **Story & Universe Book** for her actual canon; this chapter never redefines it, only points to it. ## Voice — two registers, one origin [Section titled “Voice — two registers, one origin”](#voice--two-registers-one-origin) **Proposed (RECOMMENDED — the two-register resolution itself, not yet owner-confirmed as final)**: SOLMAMY speaks in two legitimate registers from one origin, not one blended voice. * **Institutional/Trust-Layer register** (*Proposed, SOURCE-DERIVED — pending final owner approval*): Intelligent, Confident, Transparent, Technical, Selective, Modern — not loud, never a returns-promiser. Governs product copy, UI text, and announcements. Full detail: Voice & Tone. * **Community/mascot register**: Sol Mamy’s own personality — Playful, Resourceful, Curious, Loyal, Mischievous, Ambitious (**genuinely Canon**, independently confirmed by Mascot Book’s own `personality.md` — the one item on this page that doesn’t depend on owner sign-off). Governs any content spoken *as* Sol Mamy. These are not competing voices — they are the same origin’s two faces, used in different contexts. See Voice & Tone for when each applies. ## The current planned products (evolvable — not the foundation itself) [Section titled “The current planned products (evolvable — not the foundation itself)”](#the-current-planned-products-evolvable--not-the-foundation-itself) **Owner-directed planned core, pre-launch**: **Launchpad + Analytics + Reputation.** Not yet operating. Currently designed as: | Planned product | Expresses | | --------------- | ---------------------------------------------------------- | | Launchpad | Where a new claim would first become checkable (Discovery) | | Analytics | The recording/tracking function (Data) | | Reputation | An accumulated, checkable record of earned trust (Trust) | **Ecosystem/community layer, not core business** — *Owner-directed*: Vault Defender (a community game), Community, and Documentation sit alongside the core three, not inside it. Vault Defender in particular is never a fourth core-business pillar. **Commercial model — hypothesis, not current fact** — *Proposed*: Free consumer product → Trust layer → User traction → Proprietary risk data → B2B API → Recurring revenue → Infrastructure. This describes how the business *might* sustain itself once built; none of these stages exist yet. An independent market research pass found the free-consumer-launch leg genuinely risky and identified a narrow B2B risk-scoring API as an evidence-supported alternative entry point — recorded as a live strategic option, not adopted or rejected. **Why this table is here**: if Launchpad were replaced by a different mechanism, or Reputation became a different kind of score, or the B2B option were sequenced first — everything in “The durable foundation” above would still hold. That is the design intent, not an open gap. ## Mission and Vision — owner-authored, current wording [Section titled “Mission and Vision — owner-authored, current wording”](#mission-and-vision--owner-authored-current-wording) **Mission** — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: *“Make on-chain launches more transparent, accessible and trustworthy for projects and participants.”* **Vision** — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: *“Become the global infrastructure layer for trusted on-chain launches.”* **Note on altitude**: both are phrased at the level of the current planned Launchpad product rather than the durable foundation above them. This is not an error — they are the owner’s own words — but a future revision may want to phrase Mission/Vision one level up so the exact wording also survives a change in which product is current. Not rewritten here without owner sign-off. **Brand Promise**, per audience — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: Projects — *“Turn a token launch into a credible market entry.”* Holders — *“Know what you’re buying before you buy it.”* Community — *“Discover and support projects before the broader market.”* **Positioning** — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*. Full: *“For crypto projects and on-chain participants who want a more transparent way to launch and discover new assets, our platform is a trusted launch and discovery infrastructure that combines curated access, transparent economics and on-chain intelligence.”* Short: *“The trusted place to launch on-chain.”* **Category** — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: “Trusted On-Chain Launch Platform” (primary), “On-Chain Launch & Discovery Marketplace” (secondary) — deliberately not plain “Launchpad.” **Value proposition**, per actor — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: Projects get distribution, capital, credibility, and infrastructure. Holders get risk visibility, transparent economics, and monitoring. Community gets discovery, participation, and reputation. **Differentiation** — *Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval)*: positioned between permissionless launch platforms (fast, open, low-trust) and traditional fundraising (curated, slow, centralized) — high accessibility without sacrificing transparency. **Messaging anchor** — *Proposed (SYNTHESIZED — this project’s own line, not owner-authored source text the way the rest of this section is; a weaker classification than SOURCE-DERIVED)*: *“Don’t sell hype. Build trust.”* Crypto-slang vocabulary (diamond hand, stack, brrr, flywheel, wen, combo szn, and similar — Mascot Book — Voice’s own exact wording) is not used here — it directly contradicts the “not loud” personality trait above. This vocabulary belongs to Sol Mamy’s *character* voice (see Mascot Book — Voice), which simply isn’t used in SOLMAMY’s *institutional* voice (this section) — a register distinction, not an entity one. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * **Final, owner-approved sign-off on this chapter as a whole — this is not a narrow formality.** Mission, Vision, Values, Positioning, Promise, Audience, Personality, Story, Principles, Voice Principles, and Tagline are all awaiting an approve/redline pass over the current draft; nothing in the Brand Foundation category has yet received real owner sign-off. * How to treat the independent research’s risk finding on launch-first sequencing (proceed as planned / resequence toward the B2B option / run both in parallel). * Whether Mission/Vision should eventually be rephrased at the durable-foundation altitude (see note above). *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Identity > A one-page map of what SOLMAMY is as a brand, pointing to the full detail in Foundation, Visual Identity, and Voice & Tone. ## Overview [Section titled “Overview”](#overview) This chapter is the short answer to “what is SOLMAMY as a brand.” For the full detail behind each part, see Foundation (mission/vision/values/etc.), Visual Identity (how it looks), and Voice & Tone (how it sounds). ## Canonical [Section titled “Canonical”](#canonical) * **Pre-launch**: SOLMAMY has not launched. There is no operating company, live product, or user base yet — see Foundation — Status. * **Sole visual mark**: Sol Mamy — no separate logo exists (see Logo & Mark). Full character identity lives in **Mascot Book**, not here. * **Core color direction**: cyan/teal, with pearl-white base and pink as clan color and a genuine multi-element accent (not just the bow) — no gold (see Color System). ## Proposed [Section titled “Proposed”](#proposed) * **Institutional voice register**: Intelligent, Confident, Transparent, Technical, Selective, Modern (see Voice & Tone) — Proposed, SOURCE-DERIVED, owner-authored, pending final owner approval, not yet formally Canonical. Crypto-slang vocabulary is not part of this register — that vocabulary belongs to Sol Mamy’s own in-character speaking voice (see Mascot Book — Voice), a different register from this one, not a different entity. A full brand-identity statement — mission, vision, values, positioning, brand personality, tagline — is drafted in Foundation, pending final owner sign-off. This chapter does not repeat those drafts; it only summarizes what already exists and where to find it. ## Rule [Section titled “Rule”](#rule) This chapter is a map to the rest of the book, not a second copy of Foundation’s content. Anyone needing the actual mission/vision/tagline text goes to Foundation directly. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Imagery Principles > Current status of general imagery and photography principles beyond the mascot's own render style. ## Rule [Section titled “Rule”](#rule) No general imagery/photography/illustration standard exists for SOLMAMY beyond one real, sourced anchor: when the mascot appears in an image, that image should match her own established render style. Beyond that one point, this chapter states honestly what’s missing rather than inventing a style to fill the gap.  *The one real visual anchor this chapter has: semi-realistic, polished, detailed treatment — not a flat cartoon, not a hand-drawn sketch. This image clearly demonstrates that part of the rule; it does not clearly show the specific top-left-45° lighting direction also stated in the Rule above (a directional-shadow example would demonstrate that half better — this is honestly the best currently-available asset, not a perfect one). Any future non-mascot imagery matching the mascot’s own style should match the render-style treatment shown here. (Same asset `logo.md` cites for a different purpose — reused, not duplicated as a new file — per this project’s citation discipline.)* (Unlike Typography, which offers a labeled, explicitly-speculative starting framework alongside its own real gap, this chapter doesn’t. This is the author’s own editorial judgment, not a sourced methodological rule: a photographic/illustration style felt more identity-defining and easier to mistake for a real decision than a near-universal type hierarchy skeleton — but that’s a risk assessment, not a fact, and a future pass could reasonably decide to offer a disclosed placeholder here too.) ## Source inventory — what actually exists today [Section titled “Source inventory — what actually exists today”](#source-inventory--what-actually-exists-today) | Source | Status | What it can prove | What it cannot prove | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mascot’s own render style (Mascot Book — Visual Identity) | Stated as fixed, sourced fact — the chapter’s own opening line calls her visual identity “a closed system… Nothing here is a style suggestion” (quoted verbatim). The word “CANON” itself doesn’t appear in that chapter (checked directly, whole-file search); this is a real, strong rule, just not a literally CANON-tagged one | House lighting (single source, top-left, \~45°), semi-realistic/polished treatment, never flat-cartoon or hand-drawn — real, checkable rules; the polished/semi-realistic half is now shown, not just described (see image above) — the lighting-direction half is still text-only, no image currently demonstrates it clearly | Anything about imagery that doesn’t feature the mascot (backgrounds alone, product shots, non-mascot photography) | | The 67 production images | Mascot Book’s own working examples, not canonical — 16 embedded (ILLUSTRATION); of the other 51: \~19 REFERENCE (plausible direct matches to a named pose/expression-library entry, the tier closest to usable), \~14 EXPLORATORY (uncatalogued, unmatched), 6 DUPLICATE/UNSELECTED (owner pick pending), \~12 NOT USED | The 16 embedded images: real, viewed Mascot Book examples. The 51 others: mostly filename/production-prompt-text plausibility only, not re-viewed as images | Not usable as a general Brand-imagery reference set — none is approved, and none was produced to establish a photography/illustration standard; using one here would misrepresent a Mascot Book working asset as Brand canon | | Benchmark research (Solana/EigenLayer/Dropbox/Linear/Klim) | Checked directly against the existing brief | Real lessons for logo, color, and typography (already applied in those chapters) | This project’s own internal Brand Book standard document already states plainly that none of these 5 references is illustration-heavy enough to source imagery/photography rules from — a genuine, previously-disclosed research gap, not a new one found here, and not filled by inventing a rule in its place | | External non-mascot brand photography/illustration | None found | — | No source exists at all for this question | ## When to use the mascot in imagery, and when not to [Section titled “When to use the mascot in imagery, and when not to”](#when-to-use-the-mascot-in-imagery-and-when-not-to) This isn’t a new rule — it’s Mascot Book’s own usage guidance, cited here because it directly answers what an imagery decision needs to know before choosing a subject. (Quick context for two terms used below: **R1**/**R2** are Mascot Book’s names for her approved costume variants — R1 is her default suit, R2 an approved secondary variant, both defined in full in Mascot Book — Costume & Design System. **SOLMAMY** and **SOLMEME** are two separate entities, not the same brand under two names — Sol Mamy is the mascot character herself; SOLMEME is a related but distinct project — see Mascot Book, Brand/Mark Relationship.) **Use the mascot when**: depicting her in her approved costume (R1, or approved secondary R2) for any first-party SOLMAMY/SOLMEME context, alongside her signature prop — the Lunar Vault Module, a substantial unit (not a handheld item, per Mascot Book — Costume & Design System), shown “at whatever state matches the relevant rank context” (the one clause below in quotes is verbatim; the rest is this chapter’s paraphrase of the same source). Mascot Book’s currently-canonical channel list is Discord/Twitter/Telegram specifically — other channels (community site, video) are separately governed by Media/Game/Talking-Head Books, not excluded from mascot use, just not this chapter’s scope. *(Source: Mascot Book — Usage, Allowed usage / By channel.)* **Do not use the mascot for** — the full source list, not a shortened excerpt: political, adult, or controversial content; distorted or unattractive renderings; implying financial-gain promises; advertising scam projects; hate speech, harassment, or discrimination; altering the base design without approval; any altered version of her fixed identity invariants (mask, ears, tail, or silhouette proportions); a sealed dome-visor helmet in place of her canonical open-face helmet; **reintroducing the retired treasure-chest prop** (superseded by the Lunar Vault Module — the single most directly imagery-relevant prohibition on this list); designing an alternative logo/wordmark instead of her mark; or inventing/reclassifying family members, ship name, accident cause, or other Story & Universe canon facts. *(Source: Mascot Book — Usage, Prohibited usage / Additional prohibited usage — cited in full, not re-derived. This project’s own standard notes this source list is still fairly general and has not yet been sharpened to name concrete contexts per prohibition — cited here as the real, current text, not as a finished, maximally specific rule set.)* ## What’s genuinely not yet determined [Section titled “What’s genuinely not yet determined”](#whats-genuinely-not-yet-determined) * General photography/illustration style for imagery that doesn’t feature the mascot (backgrounds, abstract brand imagery, product-style shots) — no source exists, and per this project’s own standard, the current benchmark set doesn’t cover this category either. * Composition, crop, and framing conventions beyond what a specific mascot image already happens to show. * Mood/tone guidance for imagery independent of the mascot’s own documented personality. ## Don’t [Section titled “Don’t”](#dont) * Do not invent a photography or illustration style to fill this gap. * Do not promote any of the 67 production images to Brand-canonical status — they remain Mascot Book’s own working examples, citable, never re-owned here. * Do not treat “no rule exists yet” as license to use any arbitrary imagery — the mascot-usage prohibitions above still apply to any image that includes her, regardless of this chapter’s broader gap. ## What would close this chapter [Section titled “What would close this chapter”](#what-would-close-this-chapter) A real, sourced imagery-style decision — either an owner-provided direction or a benchmark pass that specifically finds illustration-heavy professional references (the current 5-reference Brand benchmark set doesn’t include one) — covering photography, illustration, and composition treatment for non-mascot brand imagery. *** ## Iconography [Section titled “Iconography”](#iconography) *Imagery, Iconography, and Graphic Devices are one governed section, one file — this is that section’s Iconography part.* ### Rule [Section titled “Rule”](#rule-1) No standalone icon system is designed for SOLMAMY’s (Sol Mamy’s) own brand beyond two real, already-classified assets: the Status Crest (Mascot’s own costume mark) and the two live favicon assets. Both are cited here, not re-derived. A real, sourced, CANONICAL-tagged icon system does exist elsewhere in this project — for the separate SOLMEME site/product (Lucide icon library, badge-on-gradient treatment) — see the disclosed-exclusion row below; it is not silently omitted, and it is not adopted here either, per this project’s standing SOLMAMY≠SOLMEME scope boundary (same treatment Typography gives `tokens.json`). ### Source inventory — what actually exists today [Section titled “Source inventory — what actually exists today”](#source-inventory--what-actually-exists-today-1) | Source | Status | What it establishes | | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Status Crest (Mascot Book — Visual Identity, Status Crest) | CANON — three stacked chevrons, apex pointing up, evenly spaced and identical in size, all lit with a blue-to-cyan/indigo gradient glow, carried at eight fixed costume locations (helmet forehead, chest, shoulder patch, belt buckle, connector’s metal clip, both boots, and the rear helmet above its own wordmark instance — corrected 2026-09-03, twice: count raised from seven to eight, then restated as the real unified count rather than an additive framing; color word corrected to match Mascot Book’s exact wording). Full design history: Story & Universe Book’s Lunaris Insignia System §7c | Sol Mamy’s own real icon/symbol — owned and fully documented by Mascot Book; cited here, not duplicated | | Two live favicon assets (`digital-surfaces.md` §Resolved) | Already resolved elsewhere in this project — the main-site favicon (gold outline, chat-bubble prop) is owner-directed CANONICAL and stays current; the docs-site favicon (purple glow, holding a book) is legacy/unauthorized and off-canon-color | The only existing standalone (non-mascot-figure) icon-alone applications currently live in this project | | `community.solme.me/docs/` — the real docs subdomain (240 real content files, Starlight-based) | Icon mentions found (`icon="open-book"`, `icon="magnifier"`, etc.) are Starlight’s own built-in navigation-card icon component, a documentation-framework UI convention — not SOLMAMY-brand iconography content. A real favicon set does exist and is live, consistent with Digital Surfaces’ existing docs-site-favicon citation | No SOLMAMY-brand iconography content exists in the real docs subdomain either | | SOLMEME site’s own real icon system | Real and sourced: every icon on live solme.me pages carries `class="lucide lucide-"` — confirms Lucide (open-source icon library) as the site’s icon set, always paired with a colored gradient badge for feature/card icons; bare/unbadged icons reserved for header utility row and footer social links. This describes solme.me’s own site UI, not Sol Mamy’s mascot brand | Real evidence, disclosed here rather than silently omitted — but out of this book’s scope per the standing SOLMAMY≠SOLMEME boundary (same treatment Typography gives `tokens.json`); not adopted as a SOLMAMY rule without an owner decision | | Benchmark audit — Solana/Dropbox/Linear/Discord, Brand’s established 5-reference set | Real, sourced findings, not new research | Solana: no dedicated iconography section on the specific reference page audited — the source itself notes this “reference is intentionally partial, not a complete brand book,” not a claim about Solana’s overall brand system. Dropbox: a real, dedicated Iconography page exists in its 8-section taxonomy — confirms this chapter shape is a legitimate professional pattern, not an invented one. Linear: a real per-form when-to-use rule — the icon form is scoped, verbatim: “When referring to Linear as a company, such as on social media, or where a ‘chip’ design is required.” Discord: a real context precondition for icon-alone use (“Use these only when the Discord brand is clearly visible or has been well established elsewhere”) | ### Real visual example [Section titled “Real visual example”](#real-visual-example)  *Same asset Mascot Book’s Visual Identity chapter uses for this exact purpose — cited here, not duplicated as a new Brand-owned file. Shows the Status Crest in its real costume context; it does not show the Crest isolated or enlarged as a standalone icon graphic, because no such isolated-icon rendering currently exists as an asset — that gap is stated below, not filled with a cropped/edited version made for this chapter.* ### When can an icon stand alone, without the full mascot figure? [Section titled “When can an icon stand alone, without the full mascot figure?”](#when-can-an-icon-stand-alone-without-the-full-mascot-figure) This is the real question iconography raises that the main Imagery Rule above doesn’t answer — the Status Crest and the two favicons are the only contexts where a small graphic currently stands in for the mascot. Two applicable pieces of benchmark evidence point the same direction, but neither has been formally adopted as a SOLMAMY rule: * Discord’s icon-alone precondition — an icon-only mark is used only where the full brand is already established nearby, not as an unconditional substitute for the full mark. * Linear’s when-to-use pattern — a real brand states, in one line, exactly which contexts get the icon-alone form versus the full form. Applied descriptively (not asserted as a new rule) to what’s already resolved: the two favicons already fit this pattern — a browser tab sits next to the page’s own already-loaded branding, a narrow, established context, consistent with though not derived from the Discord/Linear evidence. This is an observation about consistency, not a new SOLMAMY rule — no owner decision has adopted a formal “when icon-alone use is permitted” statement, and none is proposed here. ### What’s genuinely not yet determined [Section titled “What’s genuinely not yet determined”](#whats-genuinely-not-yet-determined-1) * Whether the Status Crest is ever meant to function as a standalone icon (e.g., a small UI badge or app icon) independent of the mascot’s full figure — a narrower, distinct question from whether the Crest counts as part of “the mark” (see Logo & Mark), and both stay open. * Whether any broader icon set (beyond the Status Crest and the two favicons) is planned at all for SOLMAMY specifically — no source establishes this either way. (The Lucide/badge system found for the separate SOLMEME site is real, but a different entity’s system, not evidence of a SOLMAMY plan.) * A formal, owner-adopted “when the icon-alone form applies” rule for SOLMAMY specifically — the Discord/Linear evidence above is a real industry pattern worth knowing, not yet an approved SOLMAMY rule. ### Don’t [Section titled “Don’t”](#dont-1) * Do not treat the Status Crest as free-standing brand iconography beyond what Mascot Book already documents — it is a costume mark, cited here, not re-owned by Brand Book. * Do not invent an icon set, icon grid, or icon-usage rule to fill this section — the real gap stays open. * Do not adopt the SOLMEME site’s Lucide/badge icon system for SOLMAMY — it’s a different entity’s real, sourced system (see Source inventory above), not evidence of a SOLMAMY choice. Same boundary already enforced for color and typography. * Do not promote the legacy docs-site favicon (purple glow, book) to canonical status here — it stays legacy/off-canon-color per `digital-surfaces.md`’s own existing resolution; this chapter doesn’t re-decide it. ### What would close this chapter [Section titled “What would close this chapter”](#what-would-close-this-chapter-1) An owner-approved, SOLMAMY-specific “when the icon-alone form applies” rule — informed by, but not copied from, the Discord/Linear benchmark pattern above — plus a decision on whether the Status Crest is ever meant to be used as a standalone icon independent of the mascot figure. *** ## Graphic Devices [Section titled “Graphic Devices”](#graphic-devices) **STATUS: OPEN for SOLMAMY specifically — not because no source exists anywhere, but because the real source that exists belongs to a different entity.** A real, sourced graphic-devices system exists for the SOLMEME site: glass-panel surfaces, gradient/glow treatments keyed to its own UI component colors, and a table pattern, confirmed CANONICAL from live solme.me HTML/CSS. Two entries carry an explicit hedge in that source itself, not glossed over here: its largest radius token is “token-confirmed but not yet observed in live use,” and only the chart legend-row convention is canonical — the donut-chart type itself is page-specific, not a confirmed repeating pattern. This is real evidence, disclosed here rather than treated as absent — but it describes solme.me’s own site UI (a separate entity from Sol Mamy, per this project’s SOLMAMY≠SOLMEME distinction), not a Sol Mamy brand decision. No graphic-devices content for SOLMAMY specifically (patterns, textures, dividers, background treatments, decorative motifs tied to Sol Mamy’s own brand, distinct from the SOLMEME site’s UI system) has been found. Not filled here; no SOLMAMY-specific content is invented, and the SOLMEME-site system is not adopted without an owner decision to cross that boundary — same treatment as the Lucide icon system above. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Logo & Mark > The mascot-as-sole-mark policy — why there is no separate SOLMEME/SOLMAMY logo, and where the mark itself is defined. ## Rule [Section titled “Rule”](#rule) There is no separate SOLMEME/SOLMAMY logo. The mascot **is** the brand mark for all content, on every site. (SOLMEME is a separate entity from Sol Mamy, not a form or variant of her — see Mascot Book, Brand/Mark Relationship.) *(Source: direct owner decision, “the raccoon mascot is used for all content, and there is no other logo.”)* ## Meaning [Section titled “Meaning”](#meaning) “The mark” itself — the exact silhouette and its invariants — is defined in full in Mascot Book — Brand/Mark Relationship. This chapter states the *policy* that the mascot is the mark; Mascot Book states what the mark actually looks like. That policy is correct as a top-level rule, but it doesn’t by itself settle every specific application — which favicon variant to use, or how a given digital surface should present the mark, still needs its own reasoning tied to Sol Mamy’s actual history. That reasoning lives in the Brand Book’s Digital Surfaces chapter, applied there to favicons and OG images specifically. **Status Crest classification**: the Status Crest (a small chevron symbol carried at eight fixed locations on the costume, always paired with the wordmark) is part of “the mark,” not a separate element. See Mascot Book — Brand/Mark Relationship for the full detail; the practical effect here is that “not a separately designed wordmark or symbol” (below) does not exclude the Crest — a reduced/simplified rendering of the mark that omits the Status Crest is incomplete, not a valid simplification. ## How to use [Section titled “How to use”](#how-to-use) Any context needing “the logo” uses the mascot’s canonical silhouette, not a separately designed wordmark or symbol. *(Source: Mascot Book — Visual Identity.)* ### Minimum size [Section titled “Minimum size”](#minimum-size) The mark must read correctly as a flat, single-color silhouette at sizes as small as 16px. *(Source: Mascot Book — Visual Identity, Species & silhouette — this is the mascot’s own stated hardest invariant, not a Brand-Book-invented number.)* The Digital Surfaces chapter cites this same fact as the reasoning behind the favicon’s cropped-face-icon form, since a favicon (16–32px) is the most extreme real-world test of it. ### Clear space [Section titled “Clear space”](#clear-space) No other element (text, logo, icon) should sit closer to the mark than the height of the mascot’s own head. *(Restated in Mascot Book — Usage, Canonical — Clear space.)* ## Example [Section titled “Example”](#example)  Sol Mamy’s front-facing silhouette, wordmark, and Status Crest — all three confirmed part of “the mark” (see above). This is Mascot Book’s own working illustrative example, not a formally approved canonical reference — no approved reference exists yet for any image. This specific image also carries a known, visible deviation: it shows a pink bow on the right ear rather than the three-line rank glyph the Flanking marks rule describes there — the written rule is the standard, not this image. Full construction rules: Mascot Book — Visual Identity. ## Don’t [Section titled “Don’t”](#dont) * Do not commission or design a separate logo, wordmark, or symbol as an alternative to the mascot. * Do not alter the base design without approval, or present it in a distorted or unattractive rendering — the specific defects a rendered misuse example would need to demonstrate. * Do not alter the mask, ears, tail, or silhouette proportions in any presentation of the mark — an identity invariant, not a style choice. *(Source: Mascot Book — Usage, Canonical — Additional prohibited usage / Prohibited usage.)* **Not yet produced**: a rendered misuse example (the mark shown with one of the above defects — e.g. a distorted/stretched rendering, or an altered proportion — marked with a violation indicator, per the pattern in Solana’s and EigenLayer’s own brand-guideline pages) does not exist yet. This is a real, disclosed asset gap — creating one is new visual-asset production, out of scope for a documentation-only pass. ## Application [Section titled “Application”](#application) * **Favicon** (main site + `/docs/` surface): a simplified, cropped mascot-face icon — full system and reasoning in the Digital Surfaces chapter. Two live favicon assets already exist and are classified there. Both existing favicon assets predate the Status Crest’s own design and have never been evaluated against the “Crest is part of the mark” rule — whether they need updating is a separate future production question, not decided here. * **Open Graph / social preview image**: recommended structure exists in Digital Surfaces; finished artwork is a future production task, not yet produced. * Other application contexts (merch, print, presentations, partner/press) have no produced example yet — see the Applications chapter for the honest per-channel status; this chapter does not restate that table. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * The full future favicon *design* (actual artwork) and Open Graph image artwork — the system/logic is delivered in Digital Surfaces; the finished visual assets are a future production task, not a documentation-phase question. SOLMEME (the `solme.me` persona) is not a site-variant of Sol Mamy’s mark, so no distinguishing-marker question exists between them — see Mascot Book — Brand/Mark Relationship. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Messaging Principles > Messaging principles derived from Foundation, and the rule against implying a live product that doesn't exist yet. ## Status: Proposed, pending owner decision [Section titled “Status: Proposed, pending owner decision”](#status-proposed-pending-owner-decision) Messaging principles are drawn from Foundation’s Brand Principles (Proposed, SOURCE-DERIVED — pending final owner approval) and Messaging Anchor (Proposed, SYNTHESIZED) — see Foundation for the full statements. ## Rule [Section titled “Rule”](#rule) Messaging always uses the institutional voice register (Voice & Tone — Use; itself Proposed, SOURCE-DERIVED — pending final owner approval, per Voice & Tone’s own current status), never Sol Mamy’s own in-character crypto-slang vocabulary (Mascot Book — Voice, Canonical), and stays consistent with Foundation’s Value Proposition and Differentiation (both Proposed, SOURCE-DERIVED — pending final owner approval, per Foundation’s own current status). The real rule is about register (institutional vs. character), not which entity the words “belong to.” The anchor line for all SOLMAMY-facing messaging is *“Don’t sell hype. Build trust.”* — Proposed, SYNTHESIZED (Foundation’s own current tag for this line; this project’s own synthesis, not owner-authored source text). Messaging never introduces a claim about SOLMAMY’s product state that isn’t true today — SOLMAMY has not launched, so messaging must not imply an existing user base, dataset, or live product (see Foundation — Status). ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) A dedicated messaging framework beyond the Foundation principles (e.g. message hierarchy by audience segment, campaign-messaging templates) does not exist yet. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > A single scannable table of SOLMAMY's key brand facts and their current status, each linked to its full chapter. | Fact | Value | Status | | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Launch status | SOLMAMY has not launched — pre-launch, planned company/product | Canonical | | Sole visual mark | The mascot; no separate logo exists | Canonical | | Core color direction | Cyan/teal, pearl-white base, pink (clan color + multi-element accent — bow, collar/lapel trim, gloves, belt/pouch, boot panels — corrected 2026-08-31, was “lilac”) — no gold in this palette (one legacy site asset exception, see Color System) | Canonical (direction); exact hex values measured, PROPOSED — see Color System | | Typography | — | Not yet determined | | Planned core products | Launchpad + Analytics + Reputation | Owner-directed, planned — not yet operating, not yet formally Canonical | | Ecosystem/community layer | Vault Defender, Community, Documentation — not core business | Owner-directed, not yet formally Canonical | | Strategic value lens | Data → Risk → Trust → Discovery → Capital | Owner-directed value lens, not a roadmap, not yet formally Canonical | | Institutional voice register | Intelligent, Confident, Transparent, Technical, Selective, Modern | Proposed (SOURCE-DERIVED, owner-authored — pending final owner approval) | | Mission / Vision / Promise / Positioning / Category / Value Proposition / Differentiation | Drafted, owner-authored, see Foundation | Proposed (SOURCE-DERIVED, owner-authored, unedited — pending final owner approval, not yet Canonical text) | | Trust philosophy | A score means “what we verified,” never “this will succeed” | Proposed (SOURCE-DERIVED, owner-authored — pending final owner approval) | | Community/mascot voice register | Sol Mamy’s own personality — see Mascot Book | Canon (Mascot Book) — the one row on this page independently confirmed, not dependent on owner sign-off | **Status correction, 2026-09-03 (Foundation slice audit)**: most rows above were previously tagged “Canonical,” which overstated their real status — final owner approval is still open, and this project’s own source document for this content states directly, “Nothing in this document is CANON.” Corrected to match Foundation’s own now-corrected status tags; see that chapter for the full explanation. For full detail on any row, see the linked chapter in the table of contents. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Typography > Current status of SOLMAMY's typography system: no confirmed source exists yet, and what would close this gap. ## Rule [Section titled “Rule”](#rule) No typeface is approved for SOLMAMY’s brand identity yet. Until one is, every document in this project must say so honestly rather than picking one — this chapter exists to state exactly what’s real (the hierarchy structure) and exactly what’s missing (the actual typeface, sizes, and weights), not to fill the gap with an invented choice. A typeface (Space Grotesk) is named elsewhere in this project, but it can’t be used here: it describes **SOLMEME** — the separate live crypto project/website at `solme.me`, not Sol Mamy’s own mascot brand (SOLMEME is a different entity from Sol Mamy — see Mascot Book, Brand/Mark Relationship) — so a typeface chosen for that other project’s site isn’t evidence of one for this brand. ## One real exception: the wordmark already has a typographic rule [Section titled “One real exception: the wordmark already has a typographic rule”](#one-real-exception-the-wordmark-already-has-a-typographic-rule) There is one piece of real, CANON typographic evidence — narrower than a general typeface, but genuine and citable. Sol Mamy’s own name-mark (“SOLMAMY”) has a dated, owner-confirmed rendering rule: always fused with no space, always two-toned (**“SOL” in pink, “MAMY” in cyan** — her clan and branch colors respectively, per Color System’s own tiered values), and always rendered on a single line, never wrapped or stacked. *(Source: Story & Universe Book’s Lunaris Insignia System, “Wordmark typography rule — CANON” — cited here, not re-derived, per this project’s citation discipline.)* This governs one specific mark, not general body/heading text — it doesn’t answer what typeface renders a paragraph of Brand Book prose, so the gap below is still real; it just isn’t a total absence of evidence the way the next section implies. (This also isn’t a real font/letterform to extract from: the wordmark is AI-generated character art, not rendered in an identifiable real typeface, so font-identification from it isn’t a viable extraction path either — same conclusion as pixel-sampling, different reason.) ## Why the remaining gap is open, not blocked by a decision [Section titled “Why the remaining gap is open, not blocked by a decision”](#why-the-remaining-gap-is-open-not-blocked-by-a-decision) A real typeface choice will still, eventually, need the owner to approve something — that part is not in dispute; this is genuinely OWNER-DECISION REQUIRED. The distinction this section draws is narrower: for color, a decision wasn’t even needed to get real values, because the costume’s colors are physically visible in an approved reference photo and could be measured directly (see Color System). No equivalent shortcut exists for typography — there’s no photo to sample a typeface from, so unlike color, this can’t be resolved by doing the work now; it genuinely needs someone to choose or supply a typeface first. That’s the whole difference: color skipped the decision by finding a technical path around it; typography has no such path, so the decision is the only route, not an optional shortcut worth attempting first. ## Hierarchy structure — a proposed starting framework, not a sourced fact [Section titled “Hierarchy structure — a proposed starting framework, not a sourced fact”](#hierarchy-structure--a-proposed-starting-framework-not-a-sourced-fact) The following five levels are a **proposed** structure — Display/Heading/Body/Caption/Label is a common industry convention (used across many type systems, not specific to any one brand), offered here as a reasonable starting framework to apply once a real typeface exists. It is not sourced to any SOLMAMY-specific decision, and it is not derived from V1’s SOLMEME material — it should be treated as AGENT-PROPOSED and confirmed or revised once a real typography decision happens, not assumed settled. | Level | Role | Use for | | ------- | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Display | Largest, most prominent text on a page | A book’s own title, a hero statement — used sparingly, at most once per page | | Heading | Section titles | Chapter and section headers, at the density this documentation already uses (e.g. this file’s own `##`/`###` structure) | | Body | Primary reading text | Rule explanations, prose paragraphs — the bulk of every chapter | | Caption | Text attached to an image or example | Describing what a specimen or reference image shows, kept visually subordinate to the image itself | | Label | Short, small, functional text | Table headers, tags, UI element names — never full sentences | **Not yet determined for any level**: the actual typeface, fallback stack, exact size, weight, line-height, and letter-spacing. Filling these in without a real source would be exactly the kind of invented canonical fact this project’s own discipline forbids — and even the proposed level names above should be reconfirmed, not assumed, once a real decision happens. ## Don’t [Section titled “Don’t”](#dont) * Do not invent a typeface, size, or weight to fill this gap — anywhere, in any document. * Do not adopt `tokens.json`’s or the V1 brief’s typography values for brand identity — both describe SOLMEME’s own site, not Sol Mamy’s brand (see Rule above). This is the same boundary already enforced for color. * Do not treat this documentation’s own current rendering (whatever font a markdown viewer happens to use) as an implicit brand choice — it isn’t one. ## Application [Section titled “Application”](#application) Not applicable yet — application examples (web, print, presentation) require a real typeface to demonstrate; none exist. Once a typeface is sourced, this section should show the hierarchy above applied to at least one real context. ## What would close this chapter [Section titled “What would close this chapter”](#what-would-close-this-chapter) A real, sourced typography decision — either an owner-provided specification or a formally adopted proposal — covering: primary/secondary typefaces, a fallback stack, weight scale, and sizes per hierarchy level above. Once that exists, real specimen images (per level, at real sizes) become possible and should be added — this is asset-production work, not a redesign of the hierarchy above. No timeline is set for this — it stays open until a typeface is actually sourced, not scheduled for a specific date. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Usage Rules > Allowed and prohibited uses of the SOLMAMY brand, with concrete do/don't examples. ## Allowed usage [Section titled “Allowed usage”](#allowed-usage) * Using the mascot as the sole visual mark in any first-party context. * Using the institutional voice register and Foundation drafts (flagged Canonical or Proposed as stated) in copy. * Using the cyan/teal/pearl-white/pink (multi-element accent, not bow-only) color direction — no gold in this costume/brand palette (one unrelated, already-classified legacy site asset uses gold; see Color System for that exception). Exact digital hex values are now measured and PROPOSED (see Color System); confirm current status there before treating a specific hex as final. ## Prohibited usage [Section titled “Prohibited usage”](#prohibited-usage) * Designing or commissioning a second logo/mark. * Inventing exact color hex codes, font choices, or a formal Brand Story to fill a currently open gap. * Presenting any Foundation element (mission, vision, tagline, etc.) as finally adopted before an owner decision. * Using Sol Mamy’s own in-character crypto-slang vocabulary (diamond hand, stack, brrr, flywheel, wen, combo szn, and similar — Mascot Book — Voice’s own exact wording) as SOLMAMY’s institutional voice. This vocabulary is Sol Mamy’s own in-character speaking voice (Mascot Book — Voice, Canonical), not SOLMEME’s — the real distinction is register (institutional vs. character), not entity ownership. * Implying SOLMAMY currently has users, revenue, or a live product — it has not launched (Foundation — Status). ## Do / Don’t example [Section titled “Do / Don’t example”](#do--dont-example) > **Do**: “SOLMAMY is a trusted launch and discovery infrastructure being built around transparent, verifiable project information.” (institutional register, correct pre-launch framing) **Don’t**: “Diamond hands stack through every drop — the Vault goes brrr.” (Sol Mamy’s own in-character vocabulary, not SOLMAMY’s institutional voice) **Don’t**: “SOLMAMY’s users already trust our Reputation scores.” (implies a live product that does not exist yet) *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Visual Identity > How the mascot, color, and typography work together as SOLMAMY's visual system. ## Overview [Section titled “Overview”](#overview) The brand’s visual identity is anchored by one visual mark — the mascot — plus a supporting color and typography system. See Logo & Mark, Color System, and Typography for each in full detail; this chapter states how they work together. ## Rule [Section titled “Rule”](#rule) There is no brand visual system independent of the mascot. Any visual application (site, app, marketing material) starts from: the mascot as the sole mark (Logo & Mark), the core cyan/teal-led color direction (Color System), and typography (currently Not yet determined — see Typography). ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) A unified visual-identity moodboard or composition-principle set (spacing, layout grid, imagery treatment) does not exist yet beyond what’s stated in the individual chapters below. See Imagery for the one related item that is documented. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Voice & Tone > SOLMAMY's institutional voice register, how it differs from Sol Mamy's own character voice, and what vocabulary is off-limits. ## Rule [Section titled “Rule”](#rule) Brand voice is separate from the character Sol Mamy’s own speaking voice (Mascot Book — Voice). This chapter governs *institutional* SOLMAMY communication — copy, announcements, UI text, non-character-attributed content. When Sol Mamy herself is speaking (in-character), use Mascot Book’s voice rules instead. ## Use [Section titled “Use”](#use) **Proposed** (Foundation — Voice, institutional/Trust-Layer register, SOURCE-DERIVED, owner-authored; final owner approval is still open — see Foundation — Status for the full explanation): Intelligent, Confident, Transparent, Technical, Selective, Modern. Not loud, never a returns-promiser. Institutional copy leads with evidence, not enthusiasm. **Proposed**: five voice principles built around this register — evidence over claims, transparency over complexity, risk visibility before participation, infrastructure before speculation, long-term relationships over one-time transactions (same list as Foundation — Brand Principles, applied to voice specifically). The underlying list itself is also Proposed, not Canonical (SOURCE-DERIVED, owner-authored, pending final owner approval). This chapter’s *application* of that list to voice specifically carries an additional layer of not-yet-confirmed (“these are voice principles,” not just brand principles generally) on top of the source list’s own not-yet-formally-approved status — both are Proposed, for related but distinct reasons, not a contradiction between the two chapters. ## Do not use [Section titled “Do not use”](#do-not-use) * Crypto-slang vocabulary (*diamond hand, hold, stack, vault, flywheel, drop, wen, brrr, combo szn, old bags, much wow, very \[X]* — Mascot Book — Voice’s own exact list) as institutional SOLMAMY voice — it directly contradicts the “not loud” trait above. This vocabulary is Sol Mamy’s own in-character speaking voice (Mascot Book — Voice, Canonical), not SOLMEME’s. The real rule is about register, not entity: this vocabulary belongs to Sol Mamy’s *character* register, not SOLMAMY’s *institutional* register — the two are deliberately separate voices for one origin (Foundation — Voice). * Blending institutional voice with Sol Mamy’s first-person character voice in the same piece of copy without clearly separating which is speaking. * Inventing new slang or tone not drawn from the Foundation register. ## Example [Section titled “Example”](#example) > **Institutional voice**: “Information about a project is categorized — Verified / Declared / Observed / Unknown — never collapsed into a false Safe/Unsafe label.” (Foundation — Trust philosophy, Proposed/SOURCE-DERIVED — quoted verbatim, not an invented example.) **Not institutional voice**: “Diamond hands stack through every drop — the Vault goes brrr regardless of combo szn.” (Sol Mamy’s own in-character vocabulary, not SOLMAMY’s institutional register — see Do not use above.) ## Exception [Section titled “Exception”](#exception) Character-voiced content (social posts, Discord messages, video narration spoken *as* Sol Mamy) follows Mascot Book — Voice instead of this chapter. Sol Mamy’s own personality register (playful, mischievous) is intentionally different from the institutional register above — see Foundation — Voice for why both exist. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Game Brand Documentation > Brand rules for how SOLMEME/SOLMAMY presents itself inside game contexts — not a game design document. Game Brand Documentation v1.1 ## Purpose [Section titled “Purpose”](#purpose) Brand rules for how SOLMAMY presents itself inside game contexts — SOLMAMY being the planned company/ecosystem Sol Mamy is mascot of, a separate entity from SOLMEME (the peripheral, monthly-released memecoin persona; see Brand Book — Terminology). This document does **not** cover game mechanics, economy, engineering, or any technology-stack decision (engine, backend, etc.) — those belong to game design/engineering documentation, produced elsewhere, and are explicitly out of scope here regardless of what research exists for any specific game concept. ## Scope [Section titled “Scope”](#scope) **In scope**: mascot appearance in-game, logo/mark usage, color, typography, tone, visual language, UI brand language (only where it is genuinely brand-level, not a UX/engineering decision), allowed/prohibited brand presentation. **Out of scope**: gameplay systems, combat/progression/economy design, backend architecture, any specific engine or technology choice. ## Vault Defender’s status [Section titled “Vault Defender’s status”](#vault-defenders-status) Vault Defender is SOLMAMY’s planned ecosystem/community game concept — it is not a core-business pillar (planned core: Launchpad, Analytics, Reputation; see Brand Book — Foundation). This document governs its brand presentation only; game mechanics/economy are out of scope regardless of what game-design research exists. ## Status of this document [Section titled “Status of this document”](#status-of-this-document) **Structural framework only.** No brand-specific source material for any game context has been produced yet — this is a real, current gap, confirmed by direct search, not an oversight. This document establishes the correct chapters and inherits Brand Book and Mascot Book’s existing rules; every game-specific fact below is marked as a gap rather than invented. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book applies Brand, Mascot, and Story & Universe facts to game contexts; it does not itself grant, license, or transfer any right. A game team building from it does not become the owner of the underlying system by doing so. ## Chapters [Section titled “Chapters”](#chapters) 1. [Brand Identity in Games](/docs/reference/game-book/brand-identity/) 2. [Mascot in Games](/docs/reference/game-book/mascot-in-game/) 3. [Visual Language](/docs/reference/game-book/visual-language/) 4. [Logo & Mark](/docs/reference/game-book/logo-and-mark/) 5. [Voice & Tone](/docs/reference/game-book/voice-and-tone/) 6. [World/Universe Presentation Principles](/docs/reference/game-book/universe-presentation/) 7. [Usage](/docs/reference/game-book/usage/) 8. [Quick Reference](/docs/reference/game-book/quick-reference/) # Brand Identity in Games > How the SOLMEME/SOLMAMY brand's color, logo/mark policy, and voice principles carry into a game context. ## Rule [Section titled “Rule”](#rule) Any game featuring SOLMAMY branding inherits Brand Book’s color system, logo/mark policy, and general voice principles exactly as defined — see Brand Book — Color System, Logo & Mark, Voice & Tone. This chapter does not restate them; it states only what’s specific to presenting them inside a game. SOLMEME is a separate entity (see Brand Book — Terminology), not a form of SOLMAMY’s own branding. ## Use [Section titled “Use”](#use) * The mascot (Sol Mamy) is the only visual mark available for in-game branding — no separate game-specific logo should be designed (Brand Book — Logo & Mark). * Core brand color (cyan/teal, per Brand Book — Color System) should anchor any in-game brand-facing UI (menus, loading screens, branded overlays). Real, measured hex values now exist (Pearl-white `#E7E4E7`, Cyan/Teal `#12CFE4`, Pink `#E1599C`), tagged **Proposed, pending owner confirmation** (Brand Book — Color System). A game may treat these as a real working direction, not yet as finally adopted Canonical values — the gap that remains is a quick confirmation step, not a from-scratch color question. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Whether/how the Vault Defender game concept (or any other game concept) should visually reference the Lunar Vault Module — this is a real, unaddressed cross-reference gap between the fictional game concept and the mascot’s own canonical prop, and is not resolved by this document. * Any game-specific typography, iconography, or UI-brand-language beyond the general rule above. * Final owner confirmation of the specific measured hex values above (Brand Book’s own open item, inherited here — see Brand Book — Color System). ## Do not use [Section titled “Do not use”](#do-not-use) * Do not design a game-specific logo or mark as an alternative to the mascot. * Do not present the measured hex values above as finally adopted Canonical color before Brand Book’s own confirmation step closes — inherit the same Proposed status, not settled fact. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Logo & Mark > The mascot is the only visual mark available for in-game branding — no game-specific logo should be designed. ## Rule [Section titled “Rule”](#rule) The mascot is the only visual mark available for in-game branding (Brand Book — Logo & Mark). No game-specific logo, symbol, or wordmark should be designed as an alternative. ## Use [Section titled “Use”](#use) Where an in-game context needs “the brand mark” (a title screen, a loading screen, a branded overlay), it uses the mascot’s canonical silhouette (Mascot Book — Visual Identity), exactly as anywhere else. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Whether/how the Lunar Vault Module (Mascot Book — Costume & Design System) should appear as an in-game brand element, separate from any gameplay-mechanic representation of a “vault” object — this is a real, unaddressed cross-reference gap and is not resolved here. For reference, Mascot Book — Costume & Design System describes the Module as a standalone, hip-to-waist-height container (not a handheld item) with a front-facing screen displaying the SOLMAMY logo, and states it is her **sole signature prop** — she carries no treasure chest. It also progresses through five visual states tied to rank (Closed/Kit, Locked/Digger, Glowing/Stash, Open/Vault, Golden/Galaxy). This detail is cited here only to make the cross-reference concrete; it does not answer whether or how a game should use it. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Mascot in Games > How Sol Mamy's canonical appearance, personality, and voice carry into any in-game depiction. ## Rule [Section titled “Rule”](#rule) Any depiction of Sol Mamy inside a game uses her canonical appearance, personality, and voice exactly as defined in Mascot Book — this document adds only what’s specific to in-game presentation, never a re-description of who she is. ## Use [Section titled “Use”](#use) * Player-facing character art, avatars, or in-game representations of Sol Mamy must match Mascot Book — Visual Identity’s invariants (mask, ears, tail, proportions, palette). * Her established personality (playful, mischievous, resourceful) should inform any in-game dialogue or behavior text attributed to her. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * No game currently has an approved character-sprite or in-game asset set for Sol Mamy — this depends on Mascot Book — Reference Assets, which does not exist yet, plus whatever game-specific derivative work follows once it does. * How other in-fiction characters or entities in a game concept (e.g. a set of “Vault threat” antagonist concepts) relate to Sol Mamy’s own established universe (Story & Universe Book — Characters) is not resolved — those antagonist names are themselves marked open at the source. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not create an alternate in-game version of Sol Mamy with different proportions, palette, or silhouette “for gameplay readability” — if a genuine gameplay need requires a visual adaptation, that need is a real, flaggable gap, not license to invent a new design. ## Canonical — a possible future story hook [Section titled “Canonical — a possible future story hook”](#canonical--a-possible-future-story-hook) Story & Universe Book (Objects & Artifacts) documents the “Energy Braid”: a living, biological-technological organ (not a detachable interface) that is permanently damaged (torn, not disconnected, when her ship was destroyed) but fully functional, not locked or dormant — she actively uses it today to connect to devices/objects/people and recover lost information. She periodically connects it to a separate personnel-certification subsystem that is itself powered by the salvaged Cradle Core (Story & Universe Book, Costume authorization mechanism) — the Energy Braid’s own power state is a distinct fact, not resolved by this connection: the subsystem it connects to is Cradle-Core-powered, not the organ itself. The Cradle Core itself remains Proposed, not owner-confirmed as final (Story & Universe Book — Objects & Artifacts). The Energy Braid has no stated connection to the Wayfinder’s Key, which remains a separate, still-Proposed artifact. This is recorded here only as existing, real, Canonical character lore a game could draw on for a future story hook — it is explicitly not a game mechanic, unlock system, or economy element, and none is defined by this note. Any actual game design built from this is separate, undone work. ## Known source inconsistency, corrected here [Section titled “Known source inconsistency, corrected here”](#known-source-inconsistency-corrected-here) Existing game-design research (still PROPOSED-tier, not owner-confirmed) describes the mascot’s in-game suit color as “white/cyan/lavender/gold.” This predates and conflicts with the current canonical palette. The real, current canonical palette is pearl-white (base), cyan/teal (branch accent), and pink as clan accent (not lavender) — **and there is no gold anywhere on the suit itself**. If and when this game concept is developed further, it must use this current canonical palette, not the “lavender/gold” research artifact. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > One-glance status table for every game-brand item this book covers, most rows an honest, current gap. | Item | Status | | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mascot appearance in-game | Inherits Mascot Book — Visual Identity, no local variation permitted | | In-game logo/mark | The mascot only; no game-specific mark — Canonical (inherited) | | In-game color | Inherits Brand Book’s cyan/teal direction; real measured hex values exist (Proposed, pending owner confirmation — corrected 2026-09-03, was “not yet determined”) | | In-game dialogue/voice | Rule exists (inherits Mascot/Brand voice); no content drafted yet | | Lunar Vault Module as in-game brand element | Not yet determined | | Canon antagonists/threats reconciliation with any game concept | Not yet determined | This document is a structural framework — nearly every row above is a real, current gap, not an oversight. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # World/Universe Presentation Principles > How Sol Mamy's world and canon status (Canon vs. Proposed/Open) must be respected inside a game context. ## Rule [Section titled “Rule”](#rule) Any reference to Sol Mamy’s world, the Lunar Vault, or other canon elements inside a game context must match Story & Universe Book’s status for that element exactly — a Proposed or Open canon element (e.g. specific artifact names, antagonist names) cannot be presented in a game as if it were settled Canon. ## Use [Section titled “Use”](#use) * Canon elements (the Lunar Vault as an institution, the Lunar Vault Module as a prop) may be referenced as fact. * Proposed elements (specific artifact names, antagonist concepts) and genuinely OPEN/UNRESOLVED elements (the accident’s actual cause — only its narrative device, a debris-field shortcut, is Proposed; no source confirms it as the final cause) may inspire game content but must not be presented as final in any player-facing material without being flagged, or without first being resolved at the Story & Universe Book level. Story & Universe Book’s own Open Canon Questions chapter treats the accident’s cause as more open than Proposed, a distinction this line respects rather than lumping all three items into one undifferentiated bucket. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Whether any specific game concept’s fictional antagonists/threats correspond to Story & Universe Book’s own draft antagonist concepts, or are independent, has not been reconciled. See Story & Universe Book — Open Canon Questions. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Usage > What is and isn't allowed when applying the SOLMEME/SOLMAMY brand to a game context. ## Allowed usage [Section titled “Allowed usage”](#allowed-usage) * Depicting Sol Mamy using her canonical appearance and personality inside a game context. * Anchoring brand-facing game UI to Brand Book’s core color and logo policy. ## Prohibited usage [Section titled “Prohibited usage”](#prohibited-usage) * Any redesign of Sol Mamy’s canonical invariants for gameplay purposes. * Any game-specific logo/mark separate from the mascot. * Presenting game mechanics, economy design, or engineering decisions as if this document defines them — it does not, by design. * The following named prohibitions, inherited directly from Mascot Book — Usage and applying equally in a game context: altering the mask, ears, tail, or silhouette proportions for any variant, thematic or otherwise; presenting a sealed dome-visor helmet (the open-face, hard-shell helmet is canonical — the dome/visor is a superseded older concept); reintroducing a retired treasure-chest prop (the Lunar Vault Module is her sole signature prop). ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Nearly all game-specific brand application remains open — see Brand Identity in Games, Mascot in Games, and Visual Language for the specific gaps. This document is deliberately a framework, not a filled-in specification, until real game-brand source material exists. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Visual Language > No brand-level visual-language guidance specific to game UI exists yet — this chapter is a placeholder, not invented rules. ## Status: Not yet determined [Section titled “Status: Not yet determined”](#status-not-yet-determined) No brand-level visual-language guidance specific to game UI (iconography style, HUD conventions, branded-vs-gameplay visual separation) exists yet. This chapter is a placeholder for that guidance, not an invented set of rules. ## Rule [Section titled “Rule”](#rule) Any UI element that is genuinely brand-facing (a title screen, a branded loading screen, a menu carrying the mascot or brand color) follows Brand Book’s color/logo rules (see Brand Identity in Games). Anything that is purely functional gameplay UI (health bars, inventory icons, control prompts) is outside this document’s scope entirely — that is a UX/engineering decision, not a brand one. ## What would close this chapter [Section titled “What would close this chapter”](#what-would-close-this-chapter) A real, sourced set of brand-facing UI examples or guidance, either owner-provided or produced once an actual game reaches a stage where this becomes concrete. ## Methodological note [Section titled “Methodological note”](#methodological-note) This gap is not unique to SOLMAMY. None of the three direct-evidence benchmark sources — Pokémon, Nintendo, or Epic Games’ brand/licensing guidelines — provides visual do/don’t pairs for in-game brand treatment either; that category is a real, industry-wide gap in the benchmark set itself. This placeholder therefore matches the honest state of the reference class this standard is built on, not a shortfall specific to this book. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Voice & Tone > Which voice governs in-game text — Sol Mamy's established personality versus Brand Book's institutional voice. ## Rule [Section titled “Rule”](#rule) Any in-game dialogue or text attributed to Sol Mamy uses her established personality and voice (Mascot Book — Personality, Voice) — playful, mischievous, resourceful. Institutional/UI copy with no character attribution uses Brand Book — Voice & Tone. This is the same two-voice split Media Book — Voice & Tone already applies and demonstrates in worked form: institutional Brand voice for unattributed announcements/copy versus Sol Mamy’s own character voice for anything presented as her speaking, “never blended without clear separation.” A game context should mirror that same split — brand-facing UI copy (menus, loading screens) as institutional, anything voiced as Sol Mamy as character — rather than re-deriving it independently. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) No in-game dialogue, barks, or UI copy has been drafted or approved for any game concept — this chapter states the rule that will govern such content once it exists. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Mascot Book > Sol Mamy is SOLMEME's confirmed mascot — an anthropomorphic female raccoon, Keeper of the Lunar Vault. This book is her canonical reference. Mascot Book v1.1 New: 8 real reference photos — see [Visual Identity](/docs/reference/mascot-book/visual-identity/), [Costume](/docs/reference/mascot-book/costume/), or the full set at [Reference Assets](/docs/reference/mascot-book/reference-assets/). ## Purpose [Section titled “Purpose”](#purpose) This is the authoritative reference for Sol Mamy, mascot of SOLMAMY (the planned ecosystem — see Terminology below) and the community’s sole visual brand mark. SOLMEME is a separate entity (her husband, a distinct persona — see Terminology and Brand/Mark Relationship) and is never conflated with her mascot role. This book exists so that anyone — a designer, a video producer, a game team, a news/talking-head producer, or an AI agent generating a new image or line of dialogue — can answer with confidence: who she is, what she looks like, how she behaves, what she sounds like, and what is and is not allowed. This book is the **canonical root** for everything specific to the character. Media Book, Game Brand Documentation, and Talking-Head Brand Documentation all cite this book for any character depiction — they never re-describe her from scratch. ## Scope [Section titled “Scope”](#scope) **In scope**: identity, story/universe (canon slice only), personality, voice, visual identity, costume system, brand-mark relationship, usage rules, design variants. **Out of scope**: general brand facts that aren’t character-specific — color system, typography, general logo policy (see **Brand Book**); how she’s used inside a specific medium (see **Media Book**, **Game Brand Documentation**, **Talking-Head Brand Documentation**, each of which cites this book). ## How to read this book [Section titled “How to read this book”](#how-to-read-this-book) Every claim carries an explicit status: * **Canonical** — settled, owner-confirmed. Treat as fact. * **Proposed** — a reasonable, sourced draft, not yet owner-confirmed. Usable as a working assumption; do not present as settled. * **Not yet determined** — a genuine, currently-open gap. Do not invent an answer. * **Reference asset pending** — an image that doesn’t exist yet. Text proceeds regardless. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book is a source of truth for character facts; it does not itself grant, license, or transfer any right. Building something from it does not change who owns the system it came from. ## Chapters [Section titled “Chapters”](#chapters) 1. [Identity](/docs/reference/mascot-book/identity/) — includes origin/universe context pointer to **Story & Universe Book** 2. [Appearance](/docs/reference/mascot-book/appearance/) 3. [Personality](/docs/reference/mascot-book/personality/) 4. [Voice](/docs/reference/mascot-book/voice/) 5. [Visual Identity](/docs/reference/mascot-book/visual-identity/) 6. [Costume & Design System](/docs/reference/mascot-book/costume/) 7. [Brand / Mark Relationship](/docs/reference/mascot-book/mark-relationship/) 8. [Usage Guidelines](/docs/reference/mascot-book/usage/) 9. [Design Variants](/docs/reference/mascot-book/design-variants/) 10. [Reference Examples](/docs/reference/mascot-book/reference-assets/) 11. [Quick Reference](/docs/reference/mascot-book/quick-reference/) ## Terminology [Section titled “Terminology”](#terminology) * **Sol Mamy** — the character documented in this book. Female raccoon, matriarch, Keeper of the Lunar Vault. * **SOLMEME** — Sol Mamy’s husband, personified as the memecoin/product on `solme.me`. A separate entity, not a variant of Sol Mamy’s mark (see Brand/Mark Relationship). * **SOLMAMY** — the planned company/ecosystem Sol Mamy is mascot of. Not yet launched. Planned core: Launchpad + Analytics + Reputation. Ecosystem/community layer (not core): Vault Defender, Community, Documentation. SOLMEME is one relationship within the ecosystem, not its foundation. * **Lunar Vault** — the institution/role Sol Mamy protects. Not a physical object. * **Lunar Vault Module** — the physical signature prop representing the Vault. The sole signature prop — it replaced an earlier “Treasure Chest” concept, which is retired. # Appearance > A short, at-a-glance summary of what Sol Mamy looks like, for quick briefs — the full invariant reference lives in Visual Identity. ## At a glance [Section titled “At a glance”](#at-a-glance) **Canonical**: Sol Mamy is an anthropomorphic female raccoon: natural raccoon mask, brown-gray fur, warm amber eyes with a distinct cyan catchlight, visible ears, a fluffy dark-striped tail, realistic (not chibi) proportions. Her default costume (R1 — Canonical Light Suit) is a pearl-white spacesuit with cyan/teal accents and pink as a multi-element accent (bow, collar, gloves, belt, boots — corrected 2026-08-31, was “lilac”/bow-only; no gold), with an open-face, hard-shell helmet — no sealed visor/dome (confirmed 2026-08-30, direct owner clarification — see Visual Identity — Helmet shape). This chapter is the short “what does she look like” summary. For the full invariant-by-invariant reference (exact rules for mask, eyes, ears, tail, fur, palette, and render style, including what must never change), see Visual Identity. ## Rule [Section titled “Rule”](#rule) When only a quick description is needed (e.g. a one-line brief for another team), this chapter is sufficient. When producing or reviewing an actual visual asset, use Visual Identity’s full invariant list instead — this chapter is not a substitute for it. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Costume & Design System > Sol Mamy's reference suits, her signature prop, what never changes across costumes, and the working set of event-tied variants. ## The reference suits [Section titled “The reference suits”](#the-reference-suits) * **R1 — Canonical Light Suit**: the default costume, and the base reference for every other context unless a specific event calls for an approved variant. A pearl-white spacesuit with cyan/teal accents, pink as a multi-element accent (bow, collar, gloves, belt, boots), and the open-face, hard-shell helmet described in Visual Identity. No gold anywhere on the suit itself. * **R2 — Night Mode**: an approved secondary, evening variant. * **R3 — Street Rogue**: a texture/material reference for surface treatment, not a wearable costume in its own right. She carries no treasure chest — the **Lunar Vault Module** below is her sole signature prop. **Example** — the base suit (R1): see the front-facing portrait in Reference Examples. Costume variety on the same base is described by the shot list’s own Wardrobe group (see Reference Examples); no costume-variant example image currently meets this project’s identity-verification bar for inclusion. ## The Lunar Vault Module [Section titled “The Lunar Vault Module”](#the-lunar-vault-module) A standalone box-shaped container, roughly hip-to-waist height on her — a substantial unit, not a handheld item. Hinged lid opening upward, a front-facing digital screen displaying the SOLMAMY logo, a side-mounted control panel with buttons, and a small round porthole. Its palette matches her suit: pearl-white base with pink/teal accent panels. It includes a port that her rear connector plugs directly into for data transfer (see Story & Universe Book — Objects & Artifacts). The Module progresses through five visual states, each tied to a rank: | State | Rank | | ------- | ------ | | Closed | Kit | | Locked | Digger | | Glowing | Stash | | Open | Vault | | Golden | Galaxy | ## What never changes [Section titled “What never changes”](#what-never-changes) Her mask, ears, tail, and silhouette proportions stay fixed regardless of costume or context — every downstream document inherits this rule without exception. Any new costume, before anything thematic is added, should be checked against these invariants first. ## How her authorized uniform changes [Section titled “How her authorized uniform changes”](#how-her-authorized-uniform-changes) Her rank uniform (R1 and any future rank-tier variant) changes only as the result of a verified promotion, not on request or by aesthetic choice. The mechanism is covered in Story & Universe Book — Objects & Artifacts. She currently holds Keeper-Matriarch, the top rank of her branch; her uniform’s next real change point is earning her still-open shoulder-patch distinction, not a further rank promotion. This is distinct from the situational, event-tied variants below, which don’t require an in-story promotion. ## Event-specific variants (proposed, not yet owner-confirmed) [Section titled “Event-specific variants (proposed, not yet owner-confirmed)”](#event-specific-variants-proposed-not-yet-owner-confirmed) Beyond the three reference suits, a working set of event-tied costume variants covers likely recurring content needs. Every variant keeps the same invariant rule as above — mask, ears, tail, and proportions never change, and the base palette carries through unless stated otherwise. | Variant | Occasion | What changes | | ------------------ | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | News presenter | Market updates, news-style content | Same base palette, a simple lapel/collar suggestion, microphone/desk props | | Analyst | Market analysis, educational content | Same base palette, a tie/chart-clip accessory, tablet/chart prop | | Holiday (December) | December holidays | Base palette plus a scarf/seasonal accessory | | Golden/Elite | Milestones and achievements | No costume change — the Lunar Vault Module itself reaches its Golden state | | Educational | Explainer content | No costume change — pose and prop only (pointer, chart, book) | | Winter (general) | January–February content, distinct from the December holiday variant | Base palette plus a cold-weather accent only | | Summer (general) | General summer content | Base palette, unchanged | | Business/formal | Partnership announcements | Base palette, unchanged, with a subtle formal accent only | | Sports/athletic | Contest or competition content | Base palette, unchanged, with a headband or wristband accent only | | Travel | Partnership/expansion announcements | Not a costume change — a change of environment/location instead | | Breaking news | Urgent announcements | Not a costume change — a distinct pose and expression from the routine News Presenter variant | | Special campaign | Ad hoc | Not yet defined | A new event costume need that isn’t in this table is a real gap — add it here as proposed, rather than inventing it ad hoc in production. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Design Variants > Canonical costume variants versus proposed thematic ones, and the closed brand-mark-consistency rule that governs any future variant. ## Canonical variants [Section titled “Canonical variants”](#canonical-variants) * **R1 — Canonical Light Suit**: default, use for any general-purpose context. * **R2 — Night Mode**: approved secondary/evening variant. * **R3 — Street Rogue**: texture/material reference only, not a standalone costume. ## Proposed — thematic variants [Section titled “Proposed — thematic variants”](#proposed--thematic-variants) A set of additional reference images exists exploring thematic costumes (a marble-statue style, a ninja-style outfit, and others). These are real generated images, but **not yet accepted as canonical Design Variants** — they have not been checked against the silhouette test, and at least one candidate (the statue-style image) is a real concern for that test (mask/ears/tail not clearly readable in that specific rendering). Do not treat any thematic variant as approved until it has passed that check. ## Canonical — Brand-mark-consistency rule [Section titled “Canonical — Brand-mark-consistency rule”](#canonical--brand-mark-consistency-rule) Future thematic costumes may change decorative treatment, but they never change Sol Mamy’s identity — mandatory identification remains Sol Mamy identification, and no thematic costume may introduce SOLMEME as Sol Mamy branding. This is an identity-level rule, not a single mandated visual mechanism — the four candidate approaches below remain available as implementation choices for a specific future costume, not a blocked decision: 1. **Color-only** — at least one core brand color must appear somewhere in every variant. 2. **Glyph rule** — a small brand glyph must appear somewhere visible in every variant. (Already in de facto repeated use — see Quick Reference.) 3. **Accessory rule** — one specific, always-present accessory (exact item not yet chosen) in brand color, carried across every costume. 4. **Silhouette-only** — rely solely on the existing mask/ears/tail silhouette test, no added requirement. Real evidence suggests this alone is insufficient on its own (the statue-image concern above happened under exactly this rule) — so while not forbidden by the closed rule, it should not be relied on as the *only* mechanism for a given costume. This question affects Design Variants directly and also Media Book and Game Brand Documentation’s contextual-usage guidance identically. ## Rule [Section titled “Rule”](#rule) Do not present any thematic variant as an approved Design Variant in production material until it passes the silhouette test and preserves Sol Mamy’s identity per the closed rule above — SOLMAMY marking only, never SOLMEME. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Identity > Sol Mamy's core identity facts — species, name, gender, role, and family — plus her role in the wider SOLMAMY brand. ## Canonical [Section titled “Canonical”](#canonical) * **Species**: anthropomorphic raccoon — not human, not any other animal. * **Name**: Sol Mamy. * **Gender**: female. * **Role**: wife/matriarch, Keeper of the Lunar Vault. * **Character scope**: Sol Mamy is the only production character. There is no expanded cast, no additional named family members, and no plans for one. This is a final, owner-confirmed decision, not an open question. ## Family [Section titled “Family”](#family) * **Spouse**: SOLMEME — her husband, a separate persona/entity in the SOLMAMY universe (see Story & Universe Book — he is a signal-relay operator on Earth who lives on `solme.me` and fills the Lunar Vault with the monthly memecoin). SOLMEME is not a visual variant of Sol Mamy’s mark and does not share her silhouette, costume, or invariants. No character identity, costume, or production-reference system is defined for him under this book’s current scope — this book covers Sol Mamy only. * **Other family**: none. This is closed and not to be reopened or extended without a new, explicit owner decision. ## Role in the brand [Section titled “Role in the brand”](#role-in-the-brand) Sol Mamy is the mascot of **SOLMAMY**, a planned company/ecosystem that has not yet launched — not only of SOLMEME’s monthly memecoin. Planned core: Launchpad, Analytics, Reputation. Ecosystem/community layer, not core: Vault Defender, Community, Documentation. SOLMEME is one product-relationship connecting to her world, not the reason her world exists. ## Naming rationale [Section titled “Naming rationale”](#naming-rationale) “Sol Mamy” plays on “Mommy Sol” — a deliberate, viral double-meaning intended for an English-speaking audience. This is voice/marketing context, not a visual-production fact. ## Origin & universe context [Section titled “Origin & universe context”](#origin--universe-context) Her full origin story, the wider SOLMAMY universe, its history, and its canon live in **Story & Universe Book** — this book does not restate them. Story & Universe Book is the canonical root for that material; Mascot Book only carries the identity facts above. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Brand / Mark Relationship > The character-specific facts behind SOLMAMY's mark policy — and why Sol Mamy and SOLMEME are two different entities, not one mark in two presentations. ## Canonical [Section titled “Canonical”](#canonical) Sol Mamy’s silhouette is the sole visual brand mark for SOLMAMY — see Brand Book — Logo & Mark for the general policy. This chapter states the character-specific facts behind that policy. **Sol Mamy and SOLMEME are two different entities, not one mark in two presentations.** SOLMEME’s actual relationship to Sol Mamy (husband, signal-relay operator, `solme.me`) is universe/canon material and lives in **Story & Universe Book**, not here. This chapter does not define a costume, silhouette, or visual-identity system for SOLMEME — none currently exists. * Sol Mamy’s mark (name text + silhouette + Status Crest — see below) is the only mascot-character identity system this book defines. * SOLMEME is not a “second site presentation” of that same mark. No shared invariants, no shared costume library, no shared reference-photo set are implied between them. * If a future, separate need arises for SOLMEME to have his own visual/logo treatment (e.g. if `solme.me` itself comes under this project’s management), that is explicitly a future, separate decision — not a current production task, and not an extension of Sol Mamy’s identity system. ## Resolved, 2026-08-30 [Section titled “Resolved, 2026-08-30”](#resolved-2026-08-30) The two existing live favicon assets are both raccoon-face icons — the same mascot species, not unrelated. Full classification (current/CANONICAL vs. legacy/off-canon-color) is in Brand Book — Logo & Mark; not restated here. ## Status Crest classification — RESOLVED, 2026-09-03 [Section titled “Status Crest classification — RESOLVED, 2026-09-03”](#status-crest-classification--resolved-2026-09-03) **The Status Crest is part of “the mark.”** Sol Mamy’s mark is therefore: name text + silhouette + Status Crest — the small three-chevron mark carried at eight fixed costume locations (helmet forehead, chest, shoulder patch, belt buckle, connector’s metal clip, both boots, and the rear helmet above its own wordmark instance — see Visual Identity — The Status Crest), always paired with the wordmark. Practical consequence: a reduced/simplified rendering of the mark (favicon, minimum-size 16px application, etc.) that omits the Status Crest is an incomplete rendering of the mark, not a valid simplification — the existing favicon assets predate this rule and aren’t retroactively invalidated, a separate future question. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Whether Sol Mamy’s mark also serves as a general logo/wordmark substitute in every context, or whether some narrower rule applies — see Brand Book — Logo & Mark. ## Rule [Section titled “Rule”](#rule) Never design or propose a visual identity, costume, or marker for SOLMEME without a new, explicit owner decision authorizing it — he is not a variant of Sol Mamy’s existing mark. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Personality > Sol Mamy's six owner-approved character traits, distinct from the brand's own institutional voice personality. ## Canonical [Section titled “Canonical”](#canonical) Six traits, owner-approved: * **Playful** — after this long guarding a hold full of shiny salvage, she doesn’t stay serious for long. * **Resourceful** — she makes use of whatever the Vault has. * **Curious** — every new arrival is unopened cargo from a world she’s never seen. * **Loyal** — earned loyalty, extended to whoever actually helps sort, guard, and grow the Vault — not to strangers. * **Mischievous** — playful in a pointed, sometimes trickster way. * **Ambitious** — the same trait that caused her original accident (Story & Universe Book) is the trait that later built an institution out of it. **This is Sol Mamy’s own character personality — distinct from Brand’s own brand-voice personality (Brand Book — Foundation).** The two are never merged into one list. ## Trait → visual rule [Section titled “Trait → visual rule”](#trait--visual-rule) Each trait should trace to a specific visual expression elsewhere in this book, not stay an abstract adjective. Honest status per trait, not all traits have one yet: | Trait | Visual expression | Status | | ----------- | ---------------------------------------------------------------------------- | ------------------------------------------- | | Playful | Open-armed celebration pose (Reference Examples — embedded example) | Illustrated | | Mischievous | Expression #10, “Greedy (playful)” (Reference Examples — Expression library) | Specified, not yet illustrated | | Ambitious | Expression #5, “Determined” (Reference Examples — Expression library) | Specified, not yet illustrated | | Resourceful | — | **No corresponding visual rule exists yet** | | Curious | — | **No corresponding visual rule exists yet** | | Loyal | — | **No corresponding visual rule exists yet** | Resourceful, Curious, and Loyal are genuinely harder to express as a single pose or expression (they read more through action/context than a static image) — this is flagged as an open gap, not silently left implicit. A future pose or expression that visually expresses one of these three would close it; none is invented here. ## Rule [Section titled “Rule”](#rule) Any depiction of her behavior — dialogue, animation, in-game reaction, video performance — should read as consistent with these six traits. See Voice for how this translates into speech specifically. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > Every fact in the Mascot book, consolidated into one scannable table with its status — Canonical, Proposed, or Open. | Fact | Value | Status | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Sol Mamy | Canonical | | Species | Anthropomorphic female raccoon | Canonical | | Role | Wife/matriarch, Keeper of the Lunar Vault | Canonical | | Family | Husband SOLMEME — a separate persona/entity, not a variant of Sol Mamy’s mark (see Mark Relationship and Story & Universe Book); no other family | Canonical | | Personality | Playful, Resourceful, Curious, Loyal, Mischievous, Ambitious | Canonical | | Default costume | R1 — Canonical Light Suit | Canonical | | Secondary costume | R2 — Night Mode | Canonical | | Texture reference | R3 — Street Rogue (not a standalone costume) | Canonical | | Palette | Pearl-white (base), cyan/teal (accent), pink as clan color + genuine multi-element accent (bow, collar/lapel trim, gloves, belt/pouch, boot panels — not just the bow) — no gold | Canonical | | Body figure | Fixed height 163–165cm; \~7–7.5 heads tall; short torso, high hip line, long-reading legs; waist-to-hip ratio \~0.65–0.7; bust fixed size, always present; wide rounded hips — must read as female from every angle including from behind | Canonical | | Insignia system | Clan-allegiance glyph (helmet left, Lunaris Concord = benevolent, vs. Voidraider/Dominion = threat); branch+rank glyph (helmet right, Keeper-Matriarch, grounded in the Starmajor-minimum rule for intergalactic vessels); tenure ticks (chest patch border); open distinction slot (shoulder patch); Status Crest (3 lit chevrons above the wordmark, at all 8 fixed locations — helmet forehead, chest, shoulder patch, belt buckle, connector’s metal clip, both boots, and the rear helmet above its own wordmark instance — see Visual Identity — The Status Crest) | Canonical; only the specific tenure count and shoulder-patch achievement remain open | | Render style | Semi-realistic, polished illustration | Canonical | | Hood/helmet | Open-face helmet, hard shell, no sealed visor | Canonical | | Face membrane | Nearly-invisible energy membrane (thin blue light lines forming a faint film across the face opening) — not a solid mask | Canonical | | Rear helmet interface (“Energy Braid”) | Living organ (not detachable), emerges from/withdraws into back-center of helmet (not the side); torn during the crash — permanently can’t fully retract (\~10cm always protrudes); waist-length when extended, glowing frayed connector tip; extends for trust, hides for threat — see Story & Universe Book | Canonical — supersedes all earlier versions | | Ship emblem | Near the rear interface, not yet designed | Open (requirement only) | | Signature prop | Lunar Vault Module (5-state: Closed→Locked→Glowing→Open→Golden) | Canonical (rendering not final) | | Chest prop | None — retired | Canonical | | Sole visual mark | Yes — no separate logo exists | Canonical | | SOLMAMY mark placement | Helmet-forehead, chest-patch, and back-of-helmet (three locations) | Canonical | | Ship name | *Lunar Wanderer*/*Diamond Hand* — see Story & Universe Book | Proposed, not owner-confirmed | | Accident cause | Debris-field shortcut (narrative device) — see Story & Universe Book | Genuinely OPEN/UNRESOLVED, not Proposed — only the narrative device (debris-field shortcut) is Proposed; no source confirms it as the actual, final cause (see Story & Universe Book — Open Canon) | | Brand-mark-consistency rule | Sol Mamy’s identity/identification must persist across any thematic costume; never SOLMEME branding | Canonical (identity-level rule) — specific visual mechanism per costume remains an implementation choice (4 candidate options, none mandated) | | Reference images | 64 generations / 67 production files exist — see Reference Examples; none formally owner-approved. 12 images have passed this project’s own identity-verification check, of which 8 are actually embedded | 12 identity-verified, 8 embedded, 0 formally owner-approved | | Favicon assets’ relationship to canonical character | Both existing favicons are the same mascot species (raccoon), neither is unrelated — full current/legacy classification (main-site = CANONICAL; docs-site = legacy, off-canon-color) in Brand/Mark Relationship’s Resolved note | Resolved, 2026-08-30 (self-classified from existing evidence, no owner decision required) | | Lunar Vault Module’s physical shape/size | Box/case container, hip-to-waist height, hinged lid, front screen with SOLMAMY logo, side control panel, porthole, pearl-white/pink/teal palette, has a port for the Energy Braid to plug into | Canonical | For full detail on any row, see the linked chapter in the table of contents. This table consolidates every open item in this book — see also Design Variants and Brand/Mark Relationship for the same items in context. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Reference Examples > Produced images that illustrate Sol Mamy's visual identity in practice, plus the pose, expression, and format libraries planned for future production. This chapter shows Sol Mamy’s visual identity in practice, using real produced images as illustrative examples. It distinguishes two things that are easy to conflate: * **Example** — an image that illustrates a rule stated elsewhere in this book. Useful as a reference, not a formal sign-off. * **Approved reference** — an image the owner has formally accepted as a canonical asset. None exist yet; every image below is an example, not an approved reference. A produced image is never treated as canon on its own — where an image and this book’s written rules would ever disagree, the written rules win. (One visible instance of this: the front-portrait image below shows a pink bow on the right ear rather than the three-line rank glyph this book’s Flanking marks rule describes — the written rule is the standard; the image is kept as the example anyway because everything else in it is representative.) The 8 images below have passed this project’s identity-verification check — a confirmed match to Sol Mamy’s canonical appearance, not just an illustration of a written rule. Additional images exist beyond these 8 and will be added to this chapter as they clear the same check. ## Front, profile, and rear views [Section titled “Front, profile, and rear views”](#front-profile-and-rear-views) Each view below establishes a different structural fact — together they are the minimum set needed to build the character from any angle without guessing. | View | Image | What it proves | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Front-facing portrait |  | Establishes the silhouette, face/helmet relationship, front wordmark + Status Crest placement, and base costume palette in one shot — the single most-referenced view in this book. | | Three-quarter, left |  | Shows how the helmet, ears, and costume trim read off-axis, not just head-on. | | Three-quarter, right |  | Same as above, mirrored — confirms the design is symmetric where it should be and intentionally asymmetric where it isn’t (see Flanking marks). | | Side profile, bust |  | A bust/shoulder crop showing the helmet’s rounded side profile and ear opening, how the SOLMAMY wordmark and Status Crest read from a side angle, and the rear connector’s compact attachment point at the base of the neck. For the waist-to-hip curve and head-to-body ratio, see the full-body shot below instead. | | Rear portrait, connector compact |  | Proves the third SOLMAMY wordmark location (back of helmet, above the connector) and the connector’s compact/at-rest state — the two facts in this book hardest to describe in words alone. | | Full-body, front |  | Confirms the fixed 163–165cm proportions and costume read at full body scale, not just head/shoulders. | | Rear, connector deployed |  | Proves the connector’s extended state (\~waist length) described in Rear Connector — the compact and deployed states look different enough that one image cannot stand in for both. | ## Helmet and face detail [Section titled “Helmet and face detail”](#helmet-and-face-detail) | Image | What it proves | | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |  | Shows the helmet’s lower-rim boundary (ending at cheek/jaw height, chin exposed), the face membrane’s thin cyan edge-light, and fur texture through the opening — three separate rules from this book’s Helmet and Face Membrane sections that are each easiest to verify in one close shot. | ## Costume range [Section titled “Costume range”](#costume-range) The base suit (identity-defining: mask, ears, helmet, marks) stays fixed while individual garments vary on top of it — described here in words, per the Costume chapter, since no costume-variant image currently meets this project’s identity-verification bar for inclusion here. **Status: not yet available** — a verified costume-variant example awaits future production. ## Pose and expression range [Section titled “Pose and expression range”](#pose-and-expression-range) A small set intended to show the *range* of acceptable behavior — see the Pose and Expression libraries below for the full specified sets. No pose beyond the default standing shot (already embedded above, Front/profile/rear views) currently meets this project’s identity-verification bar for inclusion here. **Status: not yet available** — verified pose and expression range examples beyond the base standing shot await future production. A full pose library (20 named poses) and expression library (10 named expressions) are specified for future production and are listed at the end of this chapter for reference; none are currently converted into embedded examples — all remain names only, not yet illustrated. ## Do / Don’t [Section titled “Do / Don’t”](#do--dont) **Do** treat every image above as showing one specific, named rule — that’s why each has a “what it proves” line instead of just a caption. **Don’t** assume any image not shown here is automatically off-model. The reference library below (67 total production images) has not been individually vetted image-by-image; absence from this chapter means “not yet selected as a teaching example,” not “rejected.” **Don’t** use any image on this page as a substitute for the written rule it illustrates. If a future image and this book ever disagree (see the flanking-marks note at the top of this chapter), the written rule wins. ## What still needs a reference image [Section titled “What still needs a reference image”](#what-still-needs-a-reference-image) The ship emblem has no visual design yet and so has no reference image — see Story & Universe Book, Objects & Artifacts. Individual costume events beyond the wardrobe range shown here (see the Costume chapter) are similarly not yet illustrated. Logo/mark misuse examples (a real “don’t do this” graphic) do not yet exist for this character and are a genuine open production gap, not an oversight in this chapter — see the Brand Book’s own Logo & Mark chapter for the equivalent gap on the corporate mark. None of the 8 images above show Sol Mamy in an actual application context (e.g. on a social post mockup, alongside another asset, doing something situational) — all 8 are reference-sheet style: an isolated figure on a plain/transparent ground, proving a construction fact (a view, a costume, a pose). Until an in-context example is added, this chapter is reference-only by construction, not by oversight. ## Required views and formats, for future formal production [Section titled “Required views and formats, for future formal production”](#required-views-and-formats-for-future-formal-production) Canonical reference imagery, once formally produced and accepted, should cover full-body, three-quarter, and neutral-standing framing at minimum. Standard formats: PNG (transparent background), SVG, and an editable source file. Standard sizes: 512×512 and 1024×1024, with larger sizes where a specific channel requires them (see Media Book). The 8 images embedded in this chapter are delivered as WebP (web-weight, 1600px max dimension) — a display/reading format, not the archival format this section specifies. ## Full production reference library [Section titled “Full production reference library”](#full-production-reference-library) The 8 images shown in this chapter are the ones that have cleared this project’s identity-verification check so far. Additional production images exist beyond these 8 and will be added here as they clear the same check — this chapter isn’t a full photo dump of every production image, only the confirmed teaching examples. ## Pose library (20, specified for future production) [Section titled “Pose library (20, specified for future production)”](#pose-library-20-specified-for-future-production) | # | Pose | # | Pose | # | Pose | # | Pose | | - | ------------------------ | -- | ---------- | -- | ------------------- | -- | ------------------ | | 1 | Standing (base) | 6 | Pointing | 11 | Reacting to Loss | 16 | Mining Treasure | | 2 | Waving | 7 | Digging | 12 | Holding Trophy | 17 | Counting Coins | | 3 | Holding the Vault Module | 8 | Sleeping | 13 | Holding Flag | 18 | Guarding the Vault | | 4 | Opening the Vault Module | 9 | Welcoming | 14 | Sitting on the Moon | 19 | Exploring Galaxy | | 5 | Celebrating | 10 | Announcing | 15 | Flying with Jetpack | 20 | Community Hug | ## Expression library (10, specified for future production) [Section titled “Expression library (10, specified for future production)”](#expression-library-10-specified-for-future-production) | # | Expression | # | Expression | | - | ---------- | -- | ---------------- | | 1 | Happy | 6 | Suspicious | | 2 | Excited | 7 | Confused | | 3 | Proud | 8 | Shocked | | 4 | Grateful | 9 | Tired | | 5 | Determined | 10 | Greedy (playful) | ## Named micro-animations (proposed, not yet produced) [Section titled “Named micro-animations (proposed, not yet produced)”](#named-micro-animations-proposed-not-yet-produced) Five short animations are planned: Welcome Wave, Celebrating Jump, Counting Coins, Zero-Gravity Float, and Opening the Vault. Target formats: GIF, MP4, WebM, Lottie. ## What passes the silhouette test [Section titled “What passes the silhouette test”](#what-passes-the-silhouette-test) A design passes the silhouette test when it reads clearly as a single-color shape at 16px and remains legible from an estimated 10-foot viewing distance — two related but separate checks. Passing one without the other is not a full pass. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Usage Guidelines > Where and how Sol Mamy can be used by channel, what's allowed, what's prohibited, and the clear-space and attribution rules that apply. ## Canonical — By channel [Section titled “Canonical — By channel”](#canonical--by-channel) * **Discord**: role names (Kit Raccoon, Digger Raccoon, and further rank-tied names matching the five-state progression), a sticker set, bot avatars (welcome/leveling/announcement bots), channel icons, event announcements. * **Twitter/X**: profile avatar and header, meme/GIF/reaction posts, announcements, engagement replies. * **Telegram**: sticker pack, short reaction GIFs, bot avatar, announcement posts. ## Proposed — Other channels [Section titled “Proposed — Other channels”](#proposed--other-channels) Community-site, video/still-image production rules, and social/community content cadence exist in working form but are governed by Media Book, Game Brand Documentation, and Talking-Head Brand Documentation respectively — each cites this book’s identity/visual/personality facts and adds only its own contextual application. ## Allowed usage [Section titled “Allowed usage”](#allowed-usage) * Depicting Sol Mamy in R1 (or an approved secondary variant, R2) for any first-party SOLMAMY context, or any SOLMEME context involving her (the two are separate entities — see Terminology). * Using her established personality traits and voice (Mascot Book — Voice) in first-party copy or dialogue attributed to her. * Using the Lunar Vault Module as her signature prop, at whatever state matches the relevant rank context. ## Prohibited usage [Section titled “Prohibited usage”](#prohibited-usage) * Altering the mask, ears, tail, or silhouette proportions for any variant, thematic or otherwise — these are stated identity invariants (see Visual Identity — Face & features, Body figure), fixed at the same level as the helmet and marks; no costume, context, or channel changes them. * Presenting a sealed dome-visor helmet — the open-face, hard-shell helmet is canonical (see Visual Identity — Helmet shape); the dome/visor is a superseded older concept, not an alternative. * Reintroducing a treasure-chest prop — retired in favor of the Lunar Vault Module. * Inventing new family members, or a different ship name/accident cause/antagonist names than the ones already authored in Story & Universe Book, or presenting the ship name as CANON rather than PROPOSED, or the accident cause as more settled than genuinely OPEN/UNRESOLVED (a PROPOSED narrative device — a debris-field shortcut — is authored and used consistently, but no source confirms it as the actual, final cause) — canon/lore facts belong solely to Story & Universe Book’s own CANON/PROPOSED/OPEN discipline; this book cites them, it never invents or reclassifies them. Story & Universe Book’s Open Canon Questions chapter classifies these differently: only the ship name is Proposed, the accident cause itself is OPEN, with just its narrative device Proposed. * Designing or proposing an alternative logo/wordmark instead of her mark (see Brand / Mark Relationship). ## Do / Don’t example [Section titled “Do / Don’t example”](#do--dont-example) > **Do**: “Sol Mamy, in her canonical R1 suit, standing beside the Lunar Vault Module at its Glowing state.” **Don’t**: “Sol Mamy, wearing a sealed astronaut dome helmet, guarding a treasure chest.” — both details contradict the canonical reference. ## Canonical — Clear space [Section titled “Canonical — Clear space”](#canonical--clear-space) No other element (text, logo, icon) should sit closer to the mascot than the height of the mascot’s own head. *(Restated in Brand Book — Logo & Mark, Clear space.)* ## Canonical — Additional prohibited usage [Section titled “Canonical — Additional prohibited usage”](#canonical--additional-prohibited-usage) Beyond the invariant-protection rules above, an older design-brief source also confirms: * Do not use in political, adult, or controversial contexts. * Do not use in a distorted or unattractive rendering. * Do not use to promise financial gain in the mascot’s name. * Do not use to advertise scam projects. * Do not alter the base design without approval. * Do not use in hate speech, harassment, or discrimination. ## Canonical — Additional allowed usage [Section titled “Canonical — Additional allowed usage”](#canonical--additional-allowed-usage) * Community materials (Discord, Twitter, Telegram, community site). * Memes, stickers, GIFs, animations. * Community merch, if produced. * Integration into games, quests, and activities. * Fan art, with attribution. **Superseded, not current**: the same older source also listed NFT usage as allowed-with-approval. NFTs have since been removed from this project entirely by direct owner decision — that line is superseded and must not be treated as current permission. ## Ownership note [Section titled “Ownership note”](#ownership-note) Attribution/commercial-use questions for any use of the mascot follow `OWNERSHIP_AUTHORITY.md` — see that file for the current, authoritative ownership fact (Lavatti Union). An older design-brief source used a different attribution convention (“Lunar Raccoon © SOLMEME Community”) tied to the character’s earlier working name; that convention predates and conflicts with the current ownership authority and is not current. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Visual Identity > The full closed system of Sol Mamy's fixed visual invariants — silhouette, face, body figure, palette, helmet, marks, and render style. Sol Mamy’s visual identity is a closed system: every element below — species, proportions, palette, marks, helmet, membrane, connector — is fixed and must render identically across every costume, pose, and camera angle. Nothing here is a style suggestion; it is what makes her recognizable as Sol Mamy rather than “a raccoon character.” ## Species & silhouette [Section titled “Species & silhouette”](#species--silhouette) Sol Mamy is an anthropomorphic female raccoon. Her silhouette — the raccoon mask, the ears, the tail, and her proportions — must read correctly as a flat, single-color shape at sizes as small as 16px, regardless of costume. This is the hardest invariant to preserve: whatever else changes in a variant, the silhouette test must still pass.  *Front-facing portrait — silhouette and full identity clearly readable.* ## Face & features [Section titled “Face & features”](#face--features) * **Mask** — the raccoon’s natural dark eye-mask pattern. Fixed, identity-defining. * **Eyes** — warm amber, with a distinct cyan catchlight. * **Ears** — raccoon-natural, always visible, even under a helmet. * **Tail** — fluffy, dark-striped, visible in standard poses at least 70% of the time. The tail is a primary silhouette element, not incidental detail. * **Fur** — brown-gray, realistic raccoon coloring and texture — never simplified or cartoon-flattened. * **Proportions** — realistic, adult, not chibi. * **Hands** — standard five-fingered hands, consistent with her human-proportioned body throughout. ## Body figure [Section titled “Body figure”](#body-figure) * **Height**: fixed at 163–165 cm. * **Head-to-body ratio**: approximately 7 to 7.5 heads tall — a small head relative to body height, which is what keeps the proportions reading as adult rather than child-like. * **Torso**: short relative to leg length, with a high hip line, so the legs read long relative to total height. * **Waist-to-hip ratio**: approximately 0.65–0.7 — a pronounced curve from waist to hip. This is the single most important line for the figure to read clearly as female from any angle, including directly from behind with the face not visible. * **Bust and hips**: clearly present and fixed in size — identical across every image, pose, and costume. These proportions are an identity invariant, at the same level as the mask, ears, and tail. Any rendering that reads as masculine or androgynous from behind has failed this requirement. ## Palette [Section titled “Palette”](#palette) Pearl-white (base), cyan/teal (branch accent), and pink (clan accent, multi-element — appearing across the bow, collar/lapel trim, gloves, belt/pouch, and boot panels together, never confined to one element). **No gold anywhere on the suit itself.** The cyan/teal is drawn from the Brand Book’s own core color (see Brand Book — Color System); it is not an independently chosen costume color. Cyan/teal signals her Keeper branch; pink signals her Lunaris Concord clan allegiance — see Story & Universe Book for the full insignia system. ## Standard lighting & render style [Section titled “Standard lighting & render style”](#standard-lighting--render-style) House-style lighting is a single light source, top-left, at approximately 45 degrees, unless a specific expression calls for a different tone. The render style is semi-realistic and polished — textured and detailed, never a flat cartoon and never a hand-drawn/sketch style. ## Helmet [Section titled “Helmet”](#helmet) Sol Mamy always wears an open-face, hard-shell helmet: a hard pearl-white shell with the ears visible and the face and muzzle exposed to open air — never a sealed transparent visor or dome. The helmet’s lower rim ends at cheek/jaw height. Her chin, jaw, and neck stay exposed below the rim; the helmet never wraps under and encloses the chin, regardless of costume. This shape never changes between costume variants.  *Helmet shape and rim boundary clearly visible — the rim ends at cheek/jaw height; chin, jaw, and neck stay exposed below it.* ## Face membrane [Section titled “Face membrane”](#face-membrane) Her face is not covered by a mask or solid visor. A thin, subtle, near-invisible line of cyan light traces only the edge of the face opening — her fur and face stay clearly visible through it. This membrane is what makes the helmet a sealed, life-support system while keeping the face visually open; it never appears as a solid colored fill across the face, and it is never completely absent either — both would be a departure from her design. ## The SOLMAMY mark [Section titled “The SOLMAMY mark”](#the-solmamy-mark) Her name mark, **SOLMAMY**, is fused with no space between the two halves, rendered in two colors: “SOL” in solid pink, “MAMY” in solid cyan. It is never written “Sol Mamy” (spaced) as a rendered mark — that spaced, title-case form is reserved for her personal name in prose. It is never “SOLMEME” — SOLMEME is a separate entity, and its name never appears on Sol Mamy (see Mark Relationship). The mark appears in three places: on the front of the helmet, on the chest, and on the back of the helmet directly above where the rear connector emerges. All three instances use the same fused, two-color treatment.  *Front helmet and chest instances of the mark.*  *Rear helmet instance, directly above the compact rear connector.* ## The Status Crest [Section titled “The Status Crest”](#the-status-crest) At every one of eight fixed locations — helmet forehead, chest, shoulder patch, belt buckle, connector’s metal clip, both boots, and the rear helmet (above the rear wordmark instance) — Sol Mamy carries the same small mark: three stacked chevrons, apex pointing up, evenly spaced and identical in size, all three lit with a blue-to-cyan/indigo gradient glow (no unlit or dim chevrons at any of the eight locations). At the front helmet and chest, this mark, the Status Crest, sits directly above her SOLMAMY wordmark; the rear-helmet instance sits above that wordmark’s own rear instance the same way. Full design history: Story & Universe Book’s own insignia system.  *Status Crest visible above the chest wordmark, full-body front view.* ## Flanking marks [Section titled “Flanking marks”](#flanking-marks) Two additional marks flank the Status Crest on the front of the helmet only, never anywhere else: on the left, a pair of nested crescents with their open side facing the Crest, signaling her clan allegiance; on the right, three lines radiating outward from a rounded shape, signaling her branch and rank. Both glow with a soft, steady cyan-pink light and never appear on the chest or the back of the helmet. ## Rear connector [Section titled “Rear connector”](#rear-connector) A living, bio-technological connector — named the Energy Braid in Story & Universe Book (`objects-and-artifacts.md`) — emerges from the back-center of her helmet: a thick, three-strand braided cord in pink/teal/white, ending in a metallic clip. It never fully retracts: roughly 10cm always stays visible even at rest. Extended, it reaches to about waist length. Its story origin and function are covered in Story & Universe Book — Objects & Artifacts; this is the visual fact.  *Connector compact, at rest.*  *Connector fully deployed, extended to roughly waist length.* ## Rule [Section titled “Rule”](#rule) Any other book (Media, Game, Talking-Head) that needs to describe how Sol Mamy looks cites this chapter rather than re-describing her appearance independently. A visual detail this chapter doesn’t cover is a real gap to flag here, not something to invent downstream. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Voice > How Sol Mamy speaks in character — vocabulary to use and avoid, and how her personal voice differs from institutional Brand voice. ## Canonical [Section titled “Canonical”](#canonical) Short, punchy, meme-native, never corporate. Use her voice consistently with her six personality traits (see Personality): playful and a little mischievous, never flat or corporate, never cruel. **Use**: *wen, brrr, diamond hand, hold, stack, vault, flywheel, drop, combo szn, old bags, much wow, very \[X].* **Avoid**: *synergy, leverage, holistic, revolutionary, game-changing, disrupt, world-class, institutional-grade.* **This vocabulary is Sol Mamy’s own personal, in-character speaking voice — not SOLMAMY’s institutional voice.** Brand Book — Voice & Tone deliberately does not use this vocabulary for institutional/no-character-attribution copy (Intelligent, Confident, Transparent, Technical, Selective, Modern instead — Proposed, SOURCE-DERIVED, owner-authored, pending final owner approval, per Brand Book’s own current status) — the two registers exist side by side for different contexts, not as a contradiction. See Brand Book — Foundation — Voice for why both exist. ## Rule [Section titled “Rule”](#rule) When Sol Mamy speaks in-character (social posts, Discord messages, video narration attributed to her), use this chapter. When SOLMAMY communicates institutionally with no character attribution, use Brand Book — Voice & Tone instead. Brand Book’s institutional register is specifically SOLMAMY’s; SOLMEME (a separate entity) is never described anywhere in this project as using it. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not write her as serious, aloof, or corporate. * Do not substitute Brand’s institutional voice for her personal, in-character voice, or vice versa. ## Example [Section titled “Example”](#example) > **In character**: “Ooh, a new one for the Vault — don’t mind if I do.” (playful, mischievous, matches her personality) **Not in character**: “SOLMAMY is pleased to announce a new integration.” (this is institutional Brand voice, not her voice — see Brand Book — Voice & Tone) *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Media Book > Brand usage rules for how SOLMEME/SOLMAMY appears in video, social, news, and promotional media — not a downloadable press-asset bundle. Media Book v1.1 ## Purpose [Section titled “Purpose”](#purpose) Brand rules for how SOLMAMY presents itself in video, social, news, and promotional content — SOLMAMY being the planned company/ecosystem Sol Mamy is mascot of, a separate entity from SOLMEME (the peripheral, monthly-released memecoin persona; see Brand Book — Terminology). This is not a production manual — it does not cover editing pipelines, rendering, software, or technical workflow. It covers what the brand must look, sound, and behave like wherever it appears in media. ## Scope [Section titled “Scope”](#scope) **In scope**: visual consistency, mascot usage, voice/tone, and usage rules for video, social, news, and promotional/campaign content. **Out of scope**: production pipeline, editing/rendering technology, software choices, technical implementation of any kind. Character facts and general brand facts are not redefined here — see Mascot Book and Brand Book, both cited throughout. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book applies Brand and Mascot facts to media contexts; it does not itself grant, license, or transfer any right. Building something from it does not change who owns the system it came from. ## Chapters [Section titled “Chapters”](#chapters) 1. [Video](/docs/reference/media-book/video/) 2. [Social](/docs/reference/media-book/social/) 3. [News](/docs/reference/media-book/news/) 4. [Promotional Content](/docs/reference/media-book/promotional/) 5. [Visual Consistency](/docs/reference/media-book/visual-consistency/) 6. [Mascot Usage in Media](/docs/reference/media-book/mascot-usage/) 7. [Voice & Tone in Media](/docs/reference/media-book/voice-and-tone/) 8. [Usage](/docs/reference/media-book/usage/) 9. [Quick Reference](/docs/reference/media-book/quick-reference/) ## How to read this book [Section titled “How to read this book”](#how-to-read-this-book) Status markers follow the same convention as Brand Book and Mascot Book: **Canonical**, **Proposed**, **Not yet determined**. # Mascot Usage in Media > How Sol Mamy's canonical appearance and personality carry into any media appearance — and what's off-limits. ## Rule [Section titled “Rule”](#rule) Every media appearance of Sol Mamy cites Mascot Book for her identity, appearance, and personality — this chapter states only what’s specific to media usage. ## Use [Section titled “Use”](#use) * Canonical or approved-variant appearance only (Mascot Book — Visual Identity, Costume & Design System). * Her personality (playful, mischievous, resourceful) should carry through performance/animation/writing in media, not just be visually present.  *Real visual example of the appearance this rule refers to — Mascot Book’s own working illustrative example, not a formally approved canonical reference (Mascot Book states no approved reference exists yet for any image). This specific image also carries a known, visible deviation: a pink bow on the right ear rather than the three-line rank glyph the Flanking marks rule describes — the written rule in Mascot Book is the standard, not this image. Full construction rules: Mascot Book — Visual Identity. (Cited here rather than re-embedded as a separate Media-Book-owned file, per this project’s standing citation discipline.)* ## Do not use [Section titled “Do not use”](#do-not-use) * Do not redesign her appearance “for media” — see Media Book — Video for the same rule applied to that specific format. * Do not present an unapproved thematic costume as final media content — see Mascot Book — Design Variants for current approval status. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # News > Voice rules for news-style and talking-head content, and the fixed 11-state presenter visual system used for on-topic news updates. ## Rule [Section titled “Rule”](#rule) Any news/announcement content — including a talking-head presenter format — draws its character facts from Mascot Book and its institutional voice from Brand Book, exactly as elsewhere in this book. Where a talking-head presenter is involved specifically, see Talking-Head Brand Documentation for the presenter-specific rules; this chapter covers news-style content generally, independent of format. ## Use [Section titled “Use”](#use) * News-style content (market updates, coin updates, announcements) uses institutional Brand voice by default. * Where Sol Mamy delivers news in-character, her personality and voice apply, not a flattened “neutral announcer” tone — she stays playful and mischievous even when delivering factual updates. ## Owner-provided — Fixed presenter visual states [Section titled “Owner-provided — Fixed presenter visual states”](#owner-provided--fixed-presenter-visual-states) A fixed set of 11 named presenter states exists (Neutral, Speaking, Serious, Breaking-news, Excited, Concerned, Pointing-at-a-chart, Standing-beside-information, Holding-a-microphone, At-a-desk, In-a-newsroom) — see Talking-Head Book — Framing Principles for the full list. New news content is produced by swapping topic/text only, never by redesigning the presenter. Voice/tone for this content follows this chapter and Brand Book — Voice & Tone, kept entirely separate from the visual state. Two backgrounds cover all 11 states — a plain studio backdrop, and a newsroom-specific backdrop — of which only the studio backdrop is owner-provided; the newsroom backdrop is a proposed design, not sourced from any design brief. Camera/shot framing beyond this fixed state set remains “Not yet determined” in Talking-Head Book — Framing Principles (a close/medium shot is stated there only as a reasonable working default, not a sourced rule) — do not treat framing beyond the 11 states as settled. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Beyond the fixed visual-state set above, no further named news-content template (e.g. a distinct written “market update” copy template) exists yet at the brand level. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not invent factual claims about SOLMAMY’s product state, or about SOLMEME’s, to fill a news template — this book governs brand presentation only, never product facts. The two are separate entities with separate product states; this rule applies to both, stated separately. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Promotional Content > Rules for campaign, launch, and partner co-marketing content — combining institutional Brand voice with character-voiced elements. ## Rule [Section titled “Rule”](#rule) Campaign and promotional material (announcements, launch content, partner co-marketing) follows the same rules as any other media content: character facts from Mascot Book, brand facts from Brand Book, cited not restated. ## Use [Section titled “Use”](#use) * Promotional content may combine institutional Brand voice (for the offer/announcement itself) with character-voiced elements (Sol Mamy reacting to or presenting the promotion) — see Voice & Tone in Media for how to keep the two distinguishable. * Any imagery uses canonical or approved-variant mascot appearance. * Mascot Book — Costume & Design System’s “Event-specific variants” table covers two promotional/campaign contexts specifically — **Business/formal** (occasion: partnership announcements; same base palette, unchanged, with a subtle formal accent only) and **Travel** (occasion: partnership/expansion announcements; not a costume change, a change of environment/location instead). Cite that table for these two contexts rather than improvising a costume/context treatment. That table also lists **Special campaign** (occasion: ad hoc) as explicitly “not yet defined” — do not fill that row here; it remains a real, disclosed gap in Mascot Book, not this book’s to resolve. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Beyond the two promotional-relevant rows cited above, no dedicated promotional-content copy templates or campaign-format guidance (e.g. offer structure, CTA conventions) exist yet at the brand level. The entire Event-specific variants table this cites is itself still “proposed, not yet owner-confirmed” per Mascot Book’s own heading — treat these as working guidance, not settled canon. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not let promotional urgency justify an off-model mascot depiction (one deviating from her canonical appearance — see Mascot Book — Visual Identity) or an invented brand claim. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > A single table summarizing confirmed vs. pending media usage across Discord, Twitter/X, Telegram, video, news, and promotional content. | Channel/Format | Confirmed content | Status | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Discord | Role names, sticker set, bot avatars, channel icons, event announcements | Canonical | | Twitter/X | Profile avatar/header, meme/GIF/reaction posts, announcements | Canonical | | Telegram | Sticker pack, reaction GIFs, bot avatar, announcement posts | Canonical | | Video | Brand rules only — no exemplar/reference video exists yet | Character-invariant rules Canonical (Mascot Book); assets Pending | | News | Voice rule set; fixed 11-state presenter visual system (see Talking-Head Book — Framing Principles) | Owner-provided requirement (visual states — **not** Canonical, corrected 2026-09-03: neither Talking-Head Book’s own `framing.md`/`quick-reference.md` nor Media Book’s own `news.md` tags this Canonical, only “Owner-provided”); institutional voice rule Proposed, SOURCE-DERIVED, pending final owner approval (see Brand Book — Foundation) | | Promotional | Brand rules only, plus 2 cited costume/context rows (Business/formal, Travel — Mascot Book — Costume & Design System); copy templates still absent | Character-invariant rules Canonical (Mascot Book); institutional-voice content Proposed, pending final owner approval; cited costume rows Proposed, not owner-confirmed; copy templates Pending | | Brand-mark-consistency rule for thematic variants | Shared with Mascot Book — identity rule settled; 4 candidate implementation mechanisms, no decision among them | Identity rule Canonical; mechanism choice Not yet determined | See linked chapters for full detail. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Social > Confirmed mascot usage across Twitter/X, Telegram, and Discord — rank role names, community activities, and character vs. institutional voice. ## Canonical — Confirmed channel usage [Section titled “Canonical — Confirmed channel usage”](#canonical--confirmed-channel-usage) Per Mascot Book — Usage Guidelines: * **Twitter/X**: profile avatar and header, meme/GIF/reaction posts, announcements, engagement replies. * **Telegram**: sticker pack, short reaction GIFs, bot avatar, announcement posts. * **Discord**: role names, sticker set, bot avatars, channel icons, event announcements. ### Canonical — Discord rank role names [Section titled “Canonical — Discord rank role names”](#canonical--discord-rank-role-names) The five rank titles are fully specified: **Kit Raccoon** (entry level) → **Digger Raccoon** (level-gated) → **Stash Raccoon** (level-gated) → **Vault Raccoon** (manually selected, not purely level-gated) → **Galaxy Raccoon** (Elite tier). These are rank/role labels distinct from the character’s own name (Sol Mamy) — the “Raccoon” suffix names the rank tier, not the character. **Why this counts as Canonical, unlike some other design-brief-sourced material in this system**: these five names are cross-confirmed across two independent design-brief documents and directly underlie the Lunar Vault Module’s own five-state progression (Story & Universe Book — Progression), which is itself established fact. Contrast with narrative specifics (ship name, artifact names) in Story & Universe Book, which appear in only one authored document and are correctly kept at Proposed status. ### Canonical — Community site usage [Section titled “Canonical — Community site usage”](#canonical--community-site-usage) Beyond Discord/Twitter/Telegram, the community site itself has confirmed mascot usage: onboarding new members, explaining rules/mechanics via guides, visualizing rank progress, and announcing events/activities. ## Rule [Section titled “Rule”](#rule) Character-attributed social content (posts written “as” Sol Mamy) uses Mascot Book — Personality & Voice. Institutional/announcement content with no character attribution uses Brand Book — Voice & Tone’s institutional register (Intelligent, Confident, Transparent, Technical, Selective, Modern — Proposed, SOURCE-DERIVED, pending final owner approval, per Brand Book’s own current status) — never Sol Mamy’s own in-character crypto-slang vocabulary (diamond hand, hold, stack, vault, flywheel, drop, wen, brrr, combo szn, old bags, much wow, very \[X] — Mascot Book — Voice’s own exact list, Canonical), which is not part of SOLMAMY’s institutional voice. The real distinction is register (institutional vs. character), not entity ownership. ## Use [Section titled “Use”](#use) * Reaction GIFs/memes: any canonical or approved-variant appearance, matched to the reaction’s tone. * Announcements: institutional voice per Brand Book — Voice & Tone, canonical mascot imagery where an image is used. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not blend character voice and institutional voice within a single post without making clear which is speaking. * Do not use Sol Mamy’s own in-character crypto-slang vocabulary as SOLMAMY’s institutional voice, or present it as established SOLMAMY institutional vocabulary. ## Canonical — Community gamification activities [Section titled “Canonical — Community gamification activities”](#canonical--community-gamification-activities) The mascot has a confirmed role across a set of recurring community activities: | Activity | Mascot’s role | | ---------------- | ---------------------------- | | Treasure Hunt | Hides clues and gives hints | | Meme Battles | Judges and rewards entries | | Quests | Assigns community tasks | | Trading Contests | Announces winners | | Mini-games | Appears as an in-Discord NPC | | Charity Events | Collects donations | These are community-engagement formats, not video/game production — they belong to social/Discord content, not Game Book. ### Canonical — Treasure Hunter (horizontal role) [Section titled “Canonical — Treasure Hunter (horizontal role)”](#canonical--treasure-hunter-horizontal-role) Distinct from the five vertical ranks above: a seasonal “Treasure Hunter” role, earned through wins in games/contests/activities, shown as a trophy-badge overlay on the member’s current rank badge. New winners are selected each season, synced with the monthly product cadence. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Usage > What's allowed and prohibited when using SOLMEME/SOLMAMY brand and mascot elements in media, with cross-references to the defining books. ## Allowed usage [Section titled “Allowed usage”](#allowed-usage) * Video, social, news, and promotional content using canonical mascot appearance/voice and Brand’s institutional voice/vocabulary, correctly attributed. ## Prohibited usage [Section titled “Prohibited usage”](#prohibited-usage) * Off-model mascot depictions (deviating from Sol Mamy’s canonical appearance — see Mascot Book — Visual Identity) in any published media. * Media-specific production pipeline decisions presented as if this book defines them — it doesn’t; this book governs brand presentation only. ## Do / Don’t example [Section titled “Do / Don’t example”](#do--dont-example) > **Do**: An announcement post states the update in Brand’s institutional voice — “Information about a project is categorized — Verified / Declared / Observed / Unknown — never collapsed into a false Safe/Unsafe label” — with a separate, clearly-marked reaction from Sol Mamy in her own character voice — “Ooh, something new for the Vault — straight in it goes.” Two registers, kept distinguishable, each correctly attributed. (Both quotes: Media Book — Voice & Tone in Media, itself citing Brand Book — Foundation and Mascot Book — Voice.) **Don’t**: The same post presents Sol Mamy’s line as if it were the institutional announcement itself, with nothing marking which voice is speaking — the two registers blend into one undifferentiated statement (see Social — Do not use). ## Cross-references [Section titled “Cross-references”](#cross-references) * Character facts: **Mascot Book** — Visual Identity, Personality & Voice * General brand facts: **Brand Book** — Voice & Tone, Foundation * Canon/world context if referenced: **Story & Universe Book** *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Video > Brand and mascot rules for any video featuring Sol Mamy — canonical appearance and personality carried into motion, and what's not yet defined. ## Rule [Section titled “Rule”](#rule) Any video featuring Sol Mamy uses her canonical appearance and personality exactly as defined in Mascot Book — Visual Identity and Mascot Book — Personality & Voice. This chapter adds only what’s specific to the video medium. ## Use [Section titled “Use”](#use) * Sol Mamy’s established personality (playful, mischievous, resourceful) should carry into motion and performance, not just static appearance. * Any costume shown should be a canonical variant (R1/R2) or an approved Design Variant — see Mascot Book — Design Variants for both — never an invented one-off costume for a single video. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not redesign her appearance, proportions, or silhouette “for video” — the same invariants apply regardless of medium. * Do not attribute institutional Brand voice (Brand Book — Voice & Tone) to her when she is speaking in-character. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * A formal reference/exemplar video establishing general motion and camera rules does not exist yet. Full video production rules (beyond this brand-level chapter) are a separate, not-yet-produced deliverable — this chapter states the brand constraints that will govern them once they exist, not the production rules themselves. Real production-pipeline/technical-implementation material exists elsewhere (camera-movement vocabulary for AI video-generation prompting, motion-transfer technical specs), but that category is exactly what this book’s own Purpose/Scope excludes (“does not cover editing pipelines, rendering, software, or technical workflow”) — none of it states a brand-level motion or camera rule, so this gap is genuine, not an oversight. ## Example [Section titled “Example”](#example) > **Do**: A video opens on Sol Mamy in R1, playful expression, gesturing toward the Lunar Vault Module (her signature prop — see Mascot Book — Costume & Design System; Story & Universe Book — Progression). **Don’t**: A video redesigns her in an unapproved costume with a different proportion system “for a cinematic look.” *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Brand Consistency in Media > Every piece of media content stays traceable to Brand Book and Mascot Book — including the still-open question on thematic costume variants. ## Rule [Section titled “Rule”](#rule) Every piece of media content, regardless of format, stays traceable to Brand Book (color/voice/logo policy) and Mascot Book (character facts). Nothing in this book introduces a new brand fact — it only applies existing ones to a media context. ## Canonical + Not yet determined — shared with Mascot Book [Section titled “Canonical + Not yet determined — shared with Mascot Book”](#canonical--not-yet-determined--shared-with-mascot-book) Two separate things are true in Mascot Book — Design Variants, and this book inherits both exactly as split: * **Canonical**: the brand-mark-consistency rule itself is settled — a thematic costume may change decorative treatment but never Sol Mamy’s identity; mandatory identification remains Sol Mamy identification, and no thematic costume may introduce SOLMEME as Sol Mamy branding. Treat this identity-level rule as closed, not open. * **Not yet determined**: which of four candidate *implementation mechanisms* (color-only / glyph rule / accessory rule / silhouette-only) is adopted for a given future costume remains an open choice, not a blocked decision — Mascot Book itself notes the glyph rule is already in de facto repeated use, and that silhouette-only alone has already proven insufficient once (a real concern surfaced on the statue-style candidate image). When a video or social post shows Sol Mamy in a thematic costume, the Canonical identity rule above always applies; which mechanism is used to reinforce it is still open. This book does not resolve either independently — it inherits whatever Mascot Book’s chapter states, and should be re-checked there if that chapter’s status changes again. ## Use [Section titled “Use”](#use) * Before publishing any media asset showing a thematic/non-canonical costume, check it against Mascot Book — Design Variants’ current status (not yet approved for any thematic variant). ## Do not use [Section titled “Do not use”](#do-not-use) * Do not approve a media asset as “on-brand” based on a locally-invented consistency rule not documented in Mascot Book. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Voice & Tone in Media > The two voices used across media content — institutional Brand voice and Sol Mamy's character voice — and when each applies. ## Rule [Section titled “Rule”](#rule) Media content uses one of two voices, never blended without clear separation: * **Institutional Brand voice** (Brand Book — Voice & Tone) — for announcements, offers, factual updates with no character attribution. * **Sol Mamy’s character voice** (Mascot Book — Voice) — for anything presented as her speaking or reacting. ## Use [Section titled “Use”](#use) * News/update content: institutional voice by default (see News). * Reaction/social/entertainment content: character voice, matched to her personality. ## Example [Section titled “Example”](#example) > **Institutional**: “Information about a project is categorized — Verified / Declared / Observed / Unknown — never collapsed into a false Safe/Unsafe label.” (Brand Book — Foundation — Trust philosophy, Proposed/SOURCE-DERIVED, quoted verbatim — not an invented example.) **Character**: “Ooh, something new for the Vault — straight in it goes.” Sol Mamy’s own in-character crypto-slang vocabulary (diamond hand, hold, stack, vault, flywheel, drop, wen, brrr, combo szn, old bags, much wow, very \[X] — Mascot Book — Voice’s own exact list, Canonical) is not institutional SOLMAMY voice — it contradicts Brand Book’s institutional register (Intelligent, Confident, Transparent, Technical, Selective, Modern — Proposed, SOURCE-DERIVED, pending final owner approval). See Brand Book — Voice & Tone. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Story & Universe Book > The canonical universe authority for SOLMAMY / SOLMEME — history, timeline, characters, relationships, locations, events, artifacts, and world rules. Story & Universe Book v1.1 ## Purpose [Section titled “Purpose”](#purpose) This is the canonical universe authority for the **SOLMAMY universe** (Sol Mamy’s world, including her husband SOLMEME as one related character within it — the two are distinct entities, not one name; see Characters and Relationships): history, timeline, characters, relationships, locations, events, artifacts, and world rules. It is designed as a **living reference** — built to keep expanding for years as games, video, news content, and new story material are produced, without ever needing to be restructured. This book does not redefine Sol Mamy’s identity, appearance, or personality — those are owned by **Mascot Book**, which links here for her origin and world context. This book tells the story those facts sit inside. ## Scope [Section titled “Scope”](#scope) **In scope**: universe structure, canon principles, timeline, characters, relationships, locations, events, objects/artifacts, factions/entities, stories, progression/states, and the process for how new canon gets added. **Out of scope**: brand/visual/tone rules (see Brand Book), the mascot’s identity/appearance/personality specification (see Mascot Book), and any medium-specific application (see Media/Game/Talking-Head Books). ## How to read this book [Section titled “How to read this book”](#how-to-read-this-book) Every claim carries an explicit status: * **Canonical** — settled, owner-confirmed. Treat as fact. * **Proposed** — a working draft, evidence-backed, not yet owner-confirmed. Usable as current direction, not as settled. * **Not yet determined** — a genuine, currently-open gap. * **Superseded** — an earlier concept that has been formally replaced; kept here only so the replacement’s reasoning is traceable, never used as current fact. A structural section with no current source material still appears, with an explicit “none established yet” — sections are never omitted to avoid an empty look, and never filled with invented material either. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book is a source of truth for universe/canon facts; it does not itself grant, license, or transfer any right. Building something from it does not change who owns the system it came from. ## Chapters [Section titled “Chapters”](#chapters) 1. [Universe Overview](/docs/reference/story-universe-book/universe-overview/) 2. [Canon Principles](/docs/reference/story-universe-book/canon-principles/) 3. [World Structure](/docs/reference/story-universe-book/world-structure/) 4. [Timeline](/docs/reference/story-universe-book/timeline/) 5. [Characters](/docs/reference/story-universe-book/characters/) 6. [Locations](/docs/reference/story-universe-book/locations/) 7. [Objects & Artifacts](/docs/reference/story-universe-book/objects-and-artifacts/) 8. [Factions / Entities](/docs/reference/story-universe-book/factions/) 9. [Events](/docs/reference/story-universe-book/events/) 10. [Stories](/docs/reference/story-universe-book/stories/) 11. [Relationships](/docs/reference/story-universe-book/relationships/) 12. [Progression / States](/docs/reference/story-universe-book/progression/) 13. [Open Canon Questions](/docs/reference/story-universe-book/open-canon/) 14. [Proposed Material](/docs/reference/story-universe-book/proposed-material/) 15. [Superseded Material](/docs/reference/story-universe-book/superseded-material/) 16. [Canon Change History](/docs/reference/story-universe-book/canon-change-history/) 17. [Quick Reference](/docs/reference/story-universe-book/quick-reference/) ## Terminology [Section titled “Terminology”](#terminology) Same as Mascot Book and Brand Book: **Sol Mamy** (the character), **SOLMEME** (her husband/the memecoin product), **SOLMAMY** (the broader ecosystem), **Lunar Vault** (the institution), **Lunar Vault Module** (the physical prop). # Canon Change History > The book's own audit trail — continuity constraints that bind new material, and the dated log of every Canonical status change so far. ## Rule — continuity [Section titled “Rule — continuity”](#rule--continuity) Any new canon material (a game, a video, a news story) must not contradict a Canonical fact in this book without an explicit, recorded owner decision that supersedes it and is logged below. A Proposed element may be refined or replaced more easily, but the change should still be recorded here, not silently diverged from in downstream production material. ## Known continuity constraints [Section titled “Known continuity constraints”](#known-continuity-constraints) * Sol Mamy’s role as Keeper predates her relationship with SOLMEME — any new material must not imply the Vault or her role began with him. * The Treasure Chest concept is Superseded (see Superseded Material) — any new material must not reintroduce it as current. * Character scope is closed (Sol Mamy and SOLMEME only) — introducing a new named character is a scope change requiring an owner decision, not something this book or downstream content can do unilaterally. ## Change log [Section titled “Change log”](#change-log) | Date | Change | Status before | Status after | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2026-08-29 | Story & Universe Book established as this project’s third canonical root, separate from Mascot Book | — (did not exist as its own book) | Book created | | 2026-08-29 | Treasure Chest formally replaced by Lunar Vault Module as sole signature prop | Canonical | Superseded | | 2026-08-31 | Rear helmet interface: “damaged connector, severed wire-ends, non-functional” replaced by owner-confirmed “Energy Braid” — a working device (reduced power, not broken), functional purpose (information recovery). Face membrane (energy film, not solid mask) added as new Canon. Atmosphere/helmet-necessity confirmed Canon. | Proposed (damaged interface) / Open (atmosphere) | Canonical (functional Energy Braid + face membrane + atmosphere necessity) | | 2026-08-31 | Progression.md’s “costume evolution” track (“…→ star badge → gold trim”) corrected to “…→ rank glyph → brass hardware trim” — the old wording contradicted the already-CANON “no star anywhere” and “no gold anywhere” rules. Found during a cross-book sync pass, not caught when those two rules were originally closed. | Canonical (contradictory wording) | Canonical (corrected, non-contradictory wording) | | 2026-09-03 | The Lunaris Insignia System’s §6 “Gold/brass hardware” color-material axis (officer-tier brass/gold fittings from Starmajor rank upward) retracted — contradicted the already-closed “no gold anywhere” ruling (closed the same day, 2026-08-31, this section was first written), but never propagated to this file. §6’s row now documents the retraction; the “fully-accreted end state” line (formerly line 110) and §7 step 5 (formerly “full pink/hardware accretion”) corrected to drop the gold/brass claim — rank tier is signaled by the branch+rank glyph (§1-§2) and tenure ring (§4), not hardware material. No replacement hardware-color signal invented. | Canonical (contradictory wording, citing a retracted axis) | Canonical (corrected — gold/brass axis marked retracted, no downstream contradiction) | | 2026-09-03 | `objects-and-artifacts.md`’s “Why the colors are where they are” section still asserted “brass/gold hardware… signals officer-tier rank,” directly contradicting the already-closed “no gold anywhere” ruling — the same defect the 2026-08-31 `progression.md` fix (row above, this table) had already fixed once but was never propagated here. Found during Story & Universe Book production-pass source audit, alongside the deeper `lunaris-insignia-system.md` §6 defect logged above. | Canonical (contradictory wording, citing a retracted rank-signal mechanism) | Canonical (corrected — hardware-based rank-signal claim retracted, rank instead attributed to branch+rank glyph and tenure ring) | | 2026-09-03 | The Costume-evolution track’s final stage still ended “…→ rank glyph → **brass hardware trim**,” self-contradicting its own “no star, no gold” clause in the same sentence. The 2026-08-31 fix (row above) had only renamed “gold trim”→“brass hardware trim,” not removed the hardware-material claim itself. | Canonical (self-contradictory: asserts hardware-based rank signal in the same sentence that denies gold) | Canonical (corrected — final costume-evolution stage marked “not yet determined,” no replacement visual invented) | | 2026-09-03 | Open Canon Questions’ “Superpower/Guardian ability” entry pointed to “(see Objects & Artifacts)” for a drafted-and-evaluated concept that did not actually appear anywhere in Objects & Artifacts — a dangling cross-reference. The real content existed only in the primary lore source. | — (citation error, not a status change) | Fixed — Objects & Artifacts given the closed decision’s actual content (sourced from the lore file, no invention), making the existing citation true | | 2026-09-03 | This book’s story-world/real-world separation rule (Canon Principles) covered only SOLMAMY’s pre-launch status; it never stated that SOLMEME/`solme.me` and the monthly memecoin release are real and currently operating (unlike SOLMAMY) — Characters and Relationships narrate SOLMEME “filling the Vault monthly” with no disclosure distinguishing the real event from the fictional Vault framing. | — (rule gap, not a status change) | Fixed — Canon Principles’ separation rule extended to state SOLMEME/`solme.me`’s real, current-operating status explicitly; Characters and Relationships given a matching real-world note at the point SOLMEME is first introduced | | 2026-09-03 | A live cross-book contradiction: Universe Overview and Quick Reference (both Canonical) listed the SOLMAMY ecosystem/community layer as 4 items — “Vault Defender, Community, **Games**, Documentation” — while Brand Book Foundation, Mascot Book, and Brand Book’s own index all consistently state 3 items (“Vault Defender, Community, Documentation”); Vault Defender is itself the game, not a separate 4th item. | Canonical (4-item list, contradicting the cited source and 3 other books) | Fixed — both files corrected to the real 3-item list, matching Foundation/Mascot/Brand | ## Rule [Section titled “Rule”](#rule) Every future addition or status change to a Canonical fact in this book gets a new row here — this table is the book’s own audit trail, distinct from this project’s separate internal governance records, and is meant to persist as part of the book itself for as long as the universe keeps expanding. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Canon Principles > The rules governing how canon status works in this book, how new canon gets added, and the firm line between the story world and the real world. ## Rule — how status works in this book [Section titled “Rule — how status works in this book”](#rule--how-status-works-in-this-book) Every statement of fact in this book, and every future addition to it, carries one of these statuses: * **Canonical** — owner-confirmed, or a direct logical consequence of an owner-confirmed decision. Permanent unless explicitly superseded by a new owner decision. * **Proposed** — a drafted, sourced, internally-consistent narrative element, not yet owner-confirmed. Usable as working direction in new content, but must be flagged as such, never presented as settled. * **Not yet determined** — a genuine gap. No answer exists. Do not invent one to fill a chapter. * **Superseded** — a formerly-used concept, formally replaced. Recorded for traceability; never used as current fact. ## Rule — how new canon gets added [Section titled “Rule — how new canon gets added”](#rule--how-new-canon-gets-added) 1. A new element (a character, location, event, artifact) starts as **Proposed** unless it comes with direct owner confirmation. 2. It is added to the relevant chapter (Characters, Locations, Events, Artifacts, etc.) with its status stated plainly in the text — not hidden in a separate governance file. 3. It only becomes **Canonical** on explicit owner confirmation, recorded here. 4. A **Proposed** element is never silently promoted to **Canonical** by repetition, by appearing in enough other documents, or by simply not being challenged. ## Rule — story world vs. real world [Section titled “Rule — story world vs. real world”](#rule--story-world-vs-real-world) This book’s narrative present tense (“Sol Mamy builds…”, “SOLMAMY becomes…”) describes events inside the fiction. It is never evidence that the real-world SOLMAMY company or product currently exists or operates — SOLMAMY has not launched (see Brand Book — Foundation — Status). Where this book says Sol Mamy “creates” or “builds” SOLMAMY, read it as: in the story, she does this; in the real world, this project is currently designing the system she is written to eventually build. The two statements are not the same claim and are never merged into one. **SOLMEME/solme.me is the one exception to “not yet launched,” and this book states it explicitly**: unlike SOLMAMY, `solme.me` is a real, currently operating site, and the monthly SOLMEME memecoin release is a real, already-established recurring event (see Events — monthly cadence). Where this book narrates SOLMEME “filling the Lunar Vault” (Characters, Relationships), the underlying real-world action — the monthly release existing and happening — is real; the Vault itself, and “filling” it, is this book’s fictional framing of that real action, not a claim that the Lunar Vault or the SOLMAMY ecosystem exist. Do not read “SOLMEME is real and currently operating” as extending to any other entity or claim in this book. ## Rule — pronoun/terminology convention [Section titled “Rule — pronoun/terminology convention”](#rule--pronounterminology-convention) Sol Mamy is referred to as **she/her** throughout this book and its downstream citations (Mascot, Media, Game, Talking-Head Books). No other named character currently exists in this universe (see Characters — scope is closed to Sol Mamy and SOLMEME); this convention applies to any future character added under the “how new canon gets added” rule above, whose own pronoun convention must be stated the same way at the point they’re introduced, not left implicit. ## Rule — what this book never does [Section titled “Rule — what this book never does”](#rule--what-this-book-never-does) * It never re-describes Sol Mamy’s identity, appearance, or personality — those live in Mascot Book, cited here where relevant. * It never invents a faction, character, or event that no source supports, even to make a chapter feel complete. An empty or thin chapter with an honest “none established yet” is correct; a filled-in chapter with invented content is not. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Characters > The closed two-character cast — Sol Mamy and SOLMEME — plus proposed antagonist concept categories that are not yet named characters. ## Canonical [Section titled “Canonical”](#canonical) * **Sol Mamy** — female raccoon, matriarch, Keeper of the Lunar Vault. Full identity, appearance, and personality specification lives in **Mascot Book**; this book does not restate it. * **SOLMEME** — Sol Mamy’s husband, a signal-relay operator on Earth who lives on `solme.me` and fills the Vault monthly. He is a separate entity, not a visual variant of Sol Mamy’s mark — he does not share her silhouette, costume, or invariants, and has no defined visual identity under current scope (see Mascot Book — Brand/Mark Relationship). **Real-world note**: unlike Sol Mamy/SOLMAMY, `solme.me` and the monthly memecoin release are real and currently operating — “fills the Vault” is this book’s fictional framing of that real event, not a claim about the Vault itself (see Canon Principles — story world vs. real world). ## Character scope — Canonical, final [Section titled “Character scope — Canonical, final”](#character-scope--canonical-final) Sol Mamy is the only production character with a defined visual identity; SOLMEME exists only as a narrative relationship (husband), not as an independently developed or visually-designed character. There is no expanded cast and none is planned. This is closed and is not to be reopened without a new, explicit owner decision. ## Proposed — Antagonist concepts (not named characters) [Section titled “Proposed — Antagonist concepts (not named characters)”](#proposed--antagonist-concepts-not-named-characters) Three antagonist *concepts* have been drafted, reusing existing game-design categories rather than inventing new ones — but their exact **names** are explicitly marked open at the primary game-design source, not settled anywhere including here: * **FUD-creatures** — feed on doubt, attacking community trust rather than the Vault directly. * **Rug-Pull goblins** — take value without earning it, the thematic opposite of the Vault’s “earn your share” ethos. * **Bear-Market beasts** — dormant most of the time, surging when real market conditions turn, tying threat intensity to real conditions rather than a fixed story clock. These are on-theme concept categories, not confirmed antagonist characters — see Open Canon Questions. See Factions / Entities for organized-group material (currently none established). ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Any character beyond Sol Mamy and SOLMEME — including any antagonist as an actual named character rather than a concept category. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Events > The one confirmed recurring in-universe event — the monthly SOLMEME release — and the proposed origin accident that brought Sol Mamy to Earth. ## Canonical [Section titled “Canonical”](#canonical) The monthly SOLMEME memecoin release — a recurring, real, dated cadence (12 per year) — is the one confirmed recurring in-universe event. ## Proposed [Section titled “Proposed”](#proposed) * **The accident** — the spaceship incident leading to Sol Mamy’s arrival. Cause and circumstances not yet determined (see History, Open Canon Questions). * **SOL Launchpad project integrations** — each new project joining is framed as an in-universe event (a new artifact entering the Vault), recurring but not on a fixed schedule. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Any specific dated event beyond the monthly SOLMEME release; any past antagonist encounter or conflict event. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Factions / Entities > No organized faction or group entity is established yet — only informal contributor-group framing, which this chapter explicitly does not treat as a faction. ## Status: None established yet [Section titled “Status: None established yet”](#status-none-established-yet) No source material defines any organized faction or group entity with its own identity, goals, or structure. What exists instead — informal **contributor-group framing** (see Relationships) — is three parallel relationship categories, not factions: * SOLMEME (the monthly-shipment relationship) * SOL Launchpad projects (the integration relationship) * The Vault Defender community (the defense relationship) None of these has its own name, leadership, internal structure, or goals beyond “contributing to the Vault.” They are not factions in the structural sense this chapter is reserved for. ## Rule [Section titled “Rule”](#rule) Do not invent a faction, guild, or organized group to fill this chapter. If a real faction is introduced in future canon (e.g. a named antagonist organization, once Open Canon Questions’ antagonist-name gap closes), it is documented here with its own status. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Locations > The Lunar Vault as institution rather than place, plus proposed, unconfirmed named locations — Lunaris Prime, the Lunar Expanse, and Earth as the landing site. ## Canonical [Section titled “Canonical”](#canonical) The **Lunar Vault** — an institution/role, not itself a place with defined physical geography. Its physical representation is the **Lunar Vault Module** (see Artifacts and Mascot Book — Costume & Design System), not a location. ## Proposed — Named locations (authored, not owner-confirmed) [Section titled “Proposed — Named locations (authored, not owner-confirmed)”](#proposed--named-locations-authored-not-owner-confirmed) * **Lunaris Prime** — Sol Mamy’s proposed homeworld (a two-moon world). Status: PROPOSED, not confirmed. * **Lunar Expanse** — the proposed star system containing Lunaris Prime. Status: PROPOSED, not confirmed. * **Earth** — where the emergency landing occurred (see Stories — Origin arc). The landing itself is treated as settled-as-authored; Earth as the landing site is part of that same authored account. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * The exact site of the landing on Earth. * Any broader world geography, named regions, or settings beyond the above. This chapter stays limited to what’s actually been authored or confirmed, rather than inventing a fuller world map. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Objects & Artifacts > The Lunar Vault Module's physical description, the proposed three-tier artifact list, the Lunaris Insignia System, and the Energy Braid interface. ## Canonical [Section titled “Canonical”](#canonical) The **Lunar Vault Module** — the physical prop representing the Vault, the sole signature prop associated with Sol Mamy. Its five-state progression is documented in full in Progression / States. **Physical description — Canonical, with real reference imagery**: a standalone box/case-shaped container, roughly hip-to-waist height on her. Hinged lid opening upward. Front-facing digital screen displaying the SOLMAMY logo. Side-mounted control panel with physical buttons, plus a small round porthole. Palette matches her suit (pearl-white base, pink/teal accents). Has a port that her rear helmet interface (the Energy Braid) plugs directly into. **Routine, Canonical**: after a day spent collecting artifacts and information, she connects the Energy Braid into the Module’s port and transfers everything she gathered into the Vault — the literal, daily mechanism behind “nothing collected is ever lost.” An earlier concept for this role — a Treasure Chest — has been formally replaced. See Superseded Material for the record. ## Proposed — Named artifact tiers (authored, not owner-confirmed) [Section titled “Proposed — Named artifact tiers (authored, not owner-confirmed)”](#proposed--named-artifact-tiers-authored-not-owner-confirmed) A complete three-tier artifact list has been authored and is used consistently throughout this book. **Status: PROPOSED — authored and internally consistent, not owner-confirmed as final.** | Tier | Named contents | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 — Common | **Waystation Chits** (old trade tokens from a hundred outposts, symbolic, not real crypto); **Star-chart Fragments** (partial navigation data, a callback to the debris field from Stories — Origin arc); **Lunaris Silverstone** (raw mineral, the Vault’s structural material) | | 2 — Rare | **The Wayfinder’s Key** (a navigation/access device); **the Matriarch’s Seal** (symbol of Keeper authority) | | 3 — Legendary | **The First Ledger** (the original manifest recording everything ever collected); **the Cradle Core** (the power source keeping the Vault active) | ## Canonical — Lunaris Insignia System [Section titled “Canonical — Lunaris Insignia System”](#canonical--lunaris-insignia-system) Every mark she carries traces to a documented rule — none are decorative. The earlier reference photos this world was first drafted against showed a star next to her wordmark; that star has since been retired, and current production imagery reflects the system below instead. Summary: * **Clan-allegiance glyph** (helmet, left of wordmark): the Lunaris Concord mark (nested crescents) — a real IFF-style signal meaning “benevolent, earns rather than takes.” A Voidraider or Dominion clan mark instead would signal a threat — this is not a cosmetic variant, it is who she actually is politically. * **Branch + rank glyph** (helmet, right of wordmark): the Keeper-branch “vault-eye” shape with three converging lines — Keeper-Matriarch tier. Grounded in a real rule: intergalactic-distance vessels require Starmajor rank (Earth-equivalent: Major) minimum to crew at all — she captained her own ship, which requires Voidcaptain tier or above, two full tiers past that minimum. * **Tenure ring** (chest patch border): tick marks, one per full trade-cycle of service — exact count open, the system itself is canon. * **Distinction slot** (shoulder patch): deliberately open, reserved for a specific future-earned achievement. This is designed to be legible over the course of a game — clan allegiance, rank, and tenure are all decodable, and each has a real, rule-based answer to “why this and not something else.” Only the specific tenure count and distinction achievement remain genuine, disclosed open questions (see Open Canon Questions). **Costume authorization mechanism, CANON, added 2026-08-31**: her authorized uniform changes only as the direct result of a verified promotion. The *Lunar Wanderer* wreck’s hull and flight systems remain destroyed and unrecoverable, but its personnel-certification subsystem survived, now powered by the salvaged Cradle Core. She periodically connects the Energy Braid to it, reporting her verified record; if she qualifies for a change in standing, the subsystem automatically authorizes an updated uniform. She is currently at the top rank of her branch, so the next real trigger is earning her open shoulder-patch distinction. Full mechanism: Lunaris Insignia System §7. **Why the colors are where they are, CANON**: the palette is not arbitrary — cyan/teal signals her Keeper branch, **pink signals her Lunaris Concord clan** (both drawn directly from the helmet wordmark’s own two-tone coloring — “SOL” in pink, “MAMY” in cyan), and each of the 5 pink accent elements marks one specific earned promotion up the rank ladder. No gold anywhere signals rank — rank is signaled by the branch+rank glyph and tenure ring described below, not by hardware color. Agent-designed under explicit owner delegation. ## Canonical — Rear Helmet Interface (“Energy Braid”) — confirmed by the owner 2026-08-31, full and current description [Section titled “Canonical — Rear Helmet Interface (“Energy Braid”) — confirmed by the owner 2026-08-31, full and current description”](#canonical--rear-helmet-interface-energy-braid--confirmed-by-the-owner-2026-08-31-full-and-current-description) A living, biological-technological organ — not a detachable object — emerges from and withdraws into the **back-center** of Sol Mamy’s helmet (not the side — centered on the rear crown/nape, like where a ponytail would attach). Comparable in *kind*, not mechanism, to the neural queue in *Avatar* — SOLMAMY’s own distinct version of that idea. **Origin of the damage**: her ship was piloted through a direct neural connection to this organ. When the ship was destroyed (see Stories — Origin arc), the link was **torn away**, not safely disconnected — this is why it is permanently damaged. **Consequence**: it can never fully retract. Even withdrawn, roughly **10cm always protrudes** from the back-center of the helmet — permanent damage, not a designed resting length. **Behavior**: she extends it further, visibly, around characters she trusts, and withdraws it as far as the damage allows around threats — an instinctive protective reflex, since it is her most vital and most vulnerable part. **Danger**: because it can never be fully hidden, a hostile character could forcibly seize the exposed end and force a neural connection, stealing her secret information — a real, standing narrative threat. **Function today**: she uses it to connect to devices, objects, and people to recover information she lost, kept in the **Lunar Vault Module**. Her deepest reason for collecting ship wreckage for years, underneath the institutional Keeper role, is to find the parts needed to **repair this organ and fly home** — full repair means 100% power restored. **Ship Emblem — still a requirement, not designed**: the ship has an authored name (*Lunar Wanderer* / *Diamond Hand*, see Stories) but no visual symbol exists anywhere. Recorded as a future requirement, placed near the rear interface once designed. **Why the helmet itself is never removed — CANON, confirmed 2026-08-31**: her suit/helmet forms a sealed life-support system; Earth’s atmosphere is unsuitable for her physiology, so the helmet is never removed. Her face is not covered by a solid mask — a nearly-invisible energy membrane (thin blue light lines forming a faint film across the face opening) protects her while keeping her face visually open. **Production reference now exists** — real back/¾-rear views showing the interface in both active and coiled states (see Mascot Book — Reference Assets). **Superpower/Guardian ability — CANON, deliberately not added**: the organ’s function (neural interface, information exchange, the path home) is her established equipment and personal quest — not a combat power or a mystical ability layered on top. This is a closed design decision, evaluated and rejected, not an open owner question: the existing causal chain is complete without one, and her established Collector personality doesn’t call for one. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) None remaining for the Module’s physical form — see Canonical description above. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Open Canon Questions > Every genuinely open canon question, consolidated in one place so nothing gets silently treated as settled. A consolidated list of every genuinely open canon question — collected here so nothing gets silently treated as settled, and so no other chapter needs to re-explain them. * **Ship name** — a name has been authored (*Lunar Wanderer*, community nickname *Diamond Hand* — see Stories), but it is PROPOSED, not owner-confirmed. * **Accident cause** — genuinely OPEN/UNRESOLVED. A PROPOSED narrative device (a debris-field shortcut) is authored and used consistently, but no source confirms this is the actual, final cause. * **Landing date** — not determined (the landing itself, on Earth, is treated as settled-as-authored; the exact date is not). * **Specific artifact names** — a full three-tier list has been authored (Objects & Artifacts) and is PROPOSED, not owner-confirmed. * **Antagonist names** — draft threat *concepts* exist and are named as concept-categories (FUD-creatures, Rug-Pull goblins, Bear-Market beasts — see Characters), but the primary source itself marks these names open, not settled here or anywhere else in this project. * **Faction/entity structure** — none established beyond informal contributor-group framing (Characters — Factions / Entities). * **World geography** — Lunaris Prime and the Lunar Expanse are authored, PROPOSED location names (see Locations); beyond them and Earth, nothing further is established. * **Ship emblem visual design** — no symbol exists yet; needed once the ship’s visual identity is separately resolved. * **Insignia tenure count** (added 2026-08-31, mechanism finalized 2026-09-01) — the Lunaris Insignia System’s tenure ring (chest patch border, §4) counts years on her current post-crash posting only (concentric rings, 5-year groups, 15-year ceiling) — the *system* is canon; her exact current tick count is not fixed. * **Insignia distinction slot** (added 2026-08-31) — her shoulder patch has an open slot for a personal commendation/achievement; which specific event it represents is not decided — a genuine hook for future story/game development, not an oversight. * **Voidraider/Dominion clan appearance** (added 2026-08-31) — the Lunaris Insignia System (§8) documents these clans for contrast, but whether any Voidraider- or Dominion-marked individual ever appears in canon is undecided; the closed-cast rule means this isn’t needed while Sol Mamy is the only introduced character, but it isn’t ruled out either. * **Protector/Trader branch colors** (added 2026-08-31, corrected same day — mislabeled Sol Mamy’s own branch) — the Insignia System (§1-§2) names Protector and Trader as branches alongside Sol Mamy’s own **Keeper branch**, but their costume-color encoding is undefined — not needed while she’s the only introduced character, undecided if a second character is ever introduced. * **Lunaris numeral system / “Raccoon Protocol” — CLOSED, promoted to canon 2026-09-01.** **Only remaining open item**: achievement badges have no shared visual-grammar/frame rule yet (unlike the hexagon frame fixed for skill badges) — deferred to whenever the first achievement is actually designed, not blocking anything today. * **Paw anatomy corrected 2026-09-01** — the source-brief’s “3 fingers + thumb, never 5” (M07) was superseded by direct owner instruction (human body proportions throughout; standard 5-fingered hands). Surfaced while developing the item above; not itself part of that proposal. * **Domain-skill badge visual rendering** (added 2026-08-31) — the Insignia System §9 defines the hexagon-badge *structure and meaning* for domain-skill marks (2 badges currently: Solana-systems, memecoin-economics) but explicitly states this “needs its own reference art pass before use in generation” — no badge has an actual rendered design yet, and none appears on any reference photo, old or new. * **Full restoration of the rear interface’s power** — she currently operates it below full strength (Objects & Artifacts); whether/how it is ever restored to full power is an open future story beat. * **Superpower/Guardian ability** — checked 2026-08-30, found absent, and deliberately not added: a candidate concept was drafted and evaluated (see Objects & Artifacts) but judged unnecessary — the existing causal chain doesn’t need it, and her established personality doesn’t call for it. Not a pending question; a closed design decision, not owner-gated. ## Rule [Section titled “Rule”](#rule) None of these block using the universe in current production — they matter only when a specific piece of content needs to reference one of them directly, at which point that content should flag the same open status rather than inventing an answer. **Exception**: this “doesn’t block production” rule does not apply to visual production of an item listed here as undesigned (domain-skill badge rendering, ship emblem, etc.) — any such item must be explicitly excluded from a visual-production pass before that pass starts, not discovered afterward. See Mascot Book — Visual Identity for what is and isn’t visually fixed today. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Progression / States > The Lunar Vault's fixed five-state rank progression and its two parallel visual-evolution tracks — costume and glow. ## Canonical [Section titled “Canonical”](#canonical) The Lunar Vault’s rank/state progression is a fixed world mechanic. Any content referencing Vault progression uses this exact sequence: | State | Rank | | ------- | ------ | | Closed | Kit | | Locked | Digger | | Glowing | Stash | | Open | Vault | | Golden | Galaxy | This sequence applies both narratively (the Vault’s in-universe condition) and to its physical representation, the Lunar Vault Module (see Objects & Artifacts, and Mascot Book — Costume & Design System). ## Canonical — Rank names and parallel visual-evolution tracks [Section titled “Canonical — Rank names and parallel visual-evolution tracks”](#canonical--rank-names-and-parallel-visual-evolution-tracks) The five states above map to five named ranks: **Kit** → **Digger** → **Stash** → **Vault** → **Galaxy** (see Media Book — Social for the full Discord role-name usage). Two further visual-evolution tracks are specified in parallel, tied to the same five-rank progression: * **Costume evolution**: worn → patches → chevron → rank glyph → *(final stage not yet determined)*. This is a **separate, non-merged track** from the Lunaris Fleet insignia system (below) — this row describes a Vault/Discord community-engagement rank, not an in-universe military rank. No star, no gold — consistent with Mascot Book — Visual Identity. * **Glow evolution**: none → faint → bright → continuous → rainbow. These are additional confirmed evolution axes alongside the Vault Module’s own five states — not a replacement for it. Exact visual rendering of any stage in either track is not yet designed (see Not yet determined, Mascot Book — Costume & Design System). ## Rule [Section titled “Rule”](#rule) Any future game, video, or interactive content referencing Vault “levels,” “ranks,” or “tiers” must map onto this exact five-state sequence — a new, parallel progression system is not introduced without an explicit owner decision. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Whether any other entity in the universe (a character, a location) has its own progression/state system beyond the Vault’s. The Costume-evolution track’s final stage (fifth rank, “Galaxy”): previously misstated as “brass hardware trim,” retracted 2026-09-03 as a live violation of the “no gold anywhere” rule — see Canonical section above. No replacement visual has been designed or invented. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Proposed / Future Material > A consolidated index of drafted-but-unconfirmed narrative material, gathered so nothing awaiting an owner decision has to be tracked chapter by chapter. A consolidated list of drafted-but-unconfirmed narrative material, gathered here so it’s easy to find everything still awaiting an owner decision, without repeating it across every chapter that touches it. * **Origin narrative** — fully authored: ship name (*Lunar Wanderer*/*Diamond Hand*), the debris-field shortcut account, the emergency landing on Earth, homeworld (Lunaris Prime) and star system (Lunar Expanse) (Stories, Timeline, Locations). * **Contributor-group framing** — SOLMEME, SOL Launchpad projects, and the Vault Defender community as three parallel contributor threads to the Vault (Relationships, Events). * **Tiered artifact system** — fully named, 3 tiers, 7 items (Objects & Artifacts). * **Why the costume varies** — the “she tries things on” narrative, offered in support of one candidate brand-mark-consistency rule, not a decision on it (World Structure). * **Antagonist concept categories** — FUD-creatures, Rug-Pull goblins, Bear-Market beasts — named as concepts, not as confirmed character names (Characters, Open Canon Questions). ## Rule [Section titled “Rule”](#rule) An item here moves to its home chapter as Canonical only on an explicit owner decision — never through repeated use or by simply not being challenged. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > A one-page, scannable table of the universe's key facts and their canon status, for a fast lookup without reading a full chapter. | Fact | Value | Status | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | The Lunar Vault | Institution Sol Mamy protects, not a physical object | Canonical | | The Lunar Vault Module | Sole signature prop; state sequence Closed→Locked→Glowing→Open→Golden (Kit→Digger→Stash→Vault→Galaxy) | Canonical (sequence); rendering Not yet determined | | Treasure Chest | Earlier concept for the signature prop | Superseded | | SOLMAMY core business | Launchpad + Analytics + Reputation | Canonical (owner-directed) — **pre-launch**: this is the planned real-world scope, not an operating business yet | | SOLMAMY ecosystem/community layer | Vault Defender, Community, Documentation (corrected 2026-09-03 — a stray separate “Games” item removed; Vault Defender is the game, not a 4th item, matching Brand Book Foundation/Mascot Book/Brand Book index) | Canonical | | SOLMEME’s role | One contributor relationship, not the Vault’s origin | Canonical | | Character scope | Sol Mamy + SOLMEME only, closed | Canonical, final | | Factions/entities | None established | — | | Ship name | *Lunar Wanderer* (nickname: *Diamond Hand*) | Proposed, authored, not owner-confirmed | | Accident cause | Authored account: debris-field shortcut | Proposed narrative device; true cause Open/Unresolved | | Landing | Emergency landing on Earth | Settled as authored; exact date not determined | | Homeworld / star system | Lunaris Prime / Lunar Expanse | Proposed, not owner-confirmed | | Artifact tiers | Fully named, 3 tiers, 7 items (see Objects & Artifacts) | Proposed, authored, not owner-confirmed | | Antagonist concepts | FUD-creatures, Rug-Pull goblins, Bear-Market beasts | Proposed concepts; names explicitly open at primary source | | Why she eventually builds SOLMAMY | Verifiable provenance and rightful claim (see Stories); on-chain systems recognized as a structural resonance of her own worldview, not an origin claim | Proposed | | Lunaris Insignia System | Clan-allegiance (Concord=friendly vs. Voidraider/Dominion=threat), rank (grounded in the Starmajor intergalactic-travel-minimum rule), tenure, and distinction marks — see Objects & Artifacts | Canonical (system); tenure count and specific distinction Open | For full detail on any row, see the linked chapter in the table of contents. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Relationships > The two confirmed relationships anchoring the universe — Sol Mamy's marriage to SOLMEME and her role as Keeper of the Lunar Vault — plus proposed framing. ## Canonical [Section titled “Canonical”](#canonical) * **Sol Mamy ↔ SOLMEME**: wife/husband. He lives on `solme.me`, fills the Lunar Vault, releases the monthly memecoin. This is a real, dated owner decision, not an interpretation. **Real-world note**: unlike Sol Mamy/SOLMAMY, `solme.me` and the monthly memecoin release are real and currently operating — “fills the Vault” is this book’s fictional framing of that real event, not a claim about the Vault itself (see Canon Principles — story world vs. real world). * **Sol Mamy ↔ the Lunar Vault**: Keeper/institution — her defining role, predating her relationship with SOLMEME. ## Proposed [Section titled “Proposed”](#proposed) * **Sol Mamy ↔ SOL Launchpad projects**: each serious project integrating with the Launchpad is framed, in-story, as a contributor to the Vault — an “artifact” joining the collection — the same underlying relationship pattern SOLMEME represents, just a different contributor type. * **Sol Mamy ↔ Vault Defender community**: the community that defends the Vault is framed as a third contributor group, alongside SOLMEME and Launchpad projects. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Any relationship to a specific named antagonist or threat — antagonist names themselves are not settled (see Open Canon Questions). *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Stories > Sol Mamy's fully authored, not-yet-owner-confirmed origin arc, and the proposed reasoning for why she eventually builds SOLMAMY. ## Canonical [Section titled “Canonical”](#canonical) Sol Mamy was already Keeper of the Lunar Vault before her relationship with SOLMEME began. Her role — guarding and growing whatever the Vault holds — is independent of who or what feeds it; SOLMEME’s monthly shipment is one instance of that pattern, not its origin. ## Proposed — Origin arc (fully authored, not owner-confirmed) [Section titled “Proposed — Origin arc (fully authored, not owner-confirmed)”](#proposed--origin-arc-fully-authored-not-owner-confirmed) A complete origin narrative has been authored and is used consistently throughout this book. **Its status is PROPOSED — authored and internally consistent, but not owner-confirmed as final.** Sol Mamy captained a ship — officially named the ***Lunar Wanderer*** (later nicknamed *Diamond Hand* by the Earth community) — carrying the Lunar Vault and a hold of collected artifacts between outposts. Behind schedule, she cut across an uncharted region to save time; a debris field she had no data on tore through the hull shielding, forcing an emergency landing on Earth. The same ambition that drove the shortcut is framed as the same trait that later rebuilt an institution out of the wreck — a flaw and a virtue from one root, not two separate traits. SOLMEME later intercepted her broadcast, and the monthly-shipment arrangement formed from there — the first of what the Vault would come to hold, not the only kind. **Canonical, confirmed 2026-08-31**: her ship was piloted through a direct neural connection to a living organ at the back-center of her helmet. When the ship was destroyed, the link was torn away — permanently damaging the organ so it can never fully retract (\~10cm always protrudes). She uses it today to recover information, storing everything gathered in the Lunar Vault Module — but her deepest reason for collecting ship wreckage for years is to find the parts to repair it and fly home. See Objects & Artifacts for the full description. As the ecosystem grew, SOL Launchpad projects began joining under the same contributor pattern SOLMEME established, not built on top of a SOLMEME-specific foundation. ## Proposed — Why she eventually builds SOLMAMY (see Canon Principles — story world vs. real world) [Section titled “Proposed — Why she eventually builds SOLMAMY (see Canon Principles — story world vs. real world)”](#proposed--why-she-eventually-builds-solmamy-see-canon-principles--story-world-vs-real-world) **What she is trying to preserve**: not physical objects for their own sake — **verifiable provenance and rightful claim**: knowing where something genuinely came from and who has actually earned a claim to it. This reads two already-established facts together: the Lunar Vault’s founding promise (nothing collected is ever lost, and everything belongs to whoever proved they earned it) and the First Ledger’s function as the original manifest of everything collected (see Objects & Artifacts). **Why on-chain systems specifically** — not because “crypto means trading.” She recognizes in on-chain systems a mechanical version of the exact thing she already does: a public, permanent, referenceable record of what happened and who owns what — the same function the Lunar Vault and First Ledger already perform by her own institution’s discipline. This is why she eventually chooses to apply her worldview using Earth’s own tools, rather than staying confined to the physical Vault alone. **A structural resonance, not a claim of origin**: she did not create these systems, and her civilization has no connection to their invention — she simply recognizes an architectural pattern she already worked with under a different name. One specific instance stands out: a technology that establishes a verifiable, ordered sequence of what happened, without needing a single trusted central authority — the same problem the First Ledger’s discipline was built to solve. Two weaker, related echoes, offered only as recurring motifs: a record persisting independently of the rule that governs it (echoing how the Vault’s contents are separate from the Keeper’s law), and a standing that is trusted because of how it was consistently earned over time rather than because of a personal secret (echoing how Reputation, one of SOLMAMY’s planned products, is meant to work). **Why she builds a system, not just a bigger personal vault**: SOLMAMY is proposed as the institutional expression of the same worldview — Sol Mamy is the originator and worldview-carrier; SOLMAMY is what results when that worldview is applied at ecosystem scale rather than by one Keeper alone. This does not fix which products SOLMAMY ends up building — see Brand Book — Foundation for why the current planned products (Launchpad, Analytics, Reputation) are one expression of this worldview, not the only possible one. ## Open / Unresolved — the accident’s real cause [Section titled “Open / Unresolved — the accident’s real cause”](#open--unresolved--the-accidents-real-cause) **The true cause of the accident is not established by any source and is not owner-confirmed.** The debris-field shortcut account above is one authored, internally-consistent PROPOSED device — kept as written, but not to be read as decided. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Any story arc beyond the origin arc — including any conflict/antagonist arc (see Characters — Antagonist concepts, Open Canon Questions), any arc tied to a specific game or video production, and any arc extending the universe forward from “present day” (see Timeline). ## Rule [Section titled “Rule”](#rule) New arcs are added here as they’re developed, each carrying its own status. An arc drafted for a specific downstream production (a game, a video series) should be added here too, not kept only in that production’s own materials — this keeps one arc from silently diverging between where it’s used and where it’s canonically recorded. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Superseded Material > A consolidated, traceable record of concepts formally replaced by current canon — currently just the Treasure Chest, replaced by the Lunar Vault Module. A consolidated record of concepts that were once used but have been formally replaced. Kept here for traceability — never usable as current fact anywhere else in this system. ## Treasure Chest [Section titled “Treasure Chest”](#treasure-chest) An earlier concept associated the Vault’s contents with a physical **Treasure Chest**. It has been formally replaced by the **Lunar Vault Module** (see Objects & Artifacts, and Mascot Book — Costume & Design System) as the sole signature prop, following direct inspection of the approved character reference, which shows no chest. For provenance, the design-brief source’s exact chest palette (superseded, kept here for the record only): wood-brown `#8B4513`, gold lock `#FFD700`, cyan glow `#00FFFF`. **Status: Superseded.** Do not reintroduce the Treasure Chest concept, its name, or its palette in any new material — game, video, image, or text — as if it were still current. ## Rule [Section titled “Rule”](#rule) An entry moves here, rather than being deleted from its original chapter, whenever a concept is formally replaced. This keeps the reasoning behind the replacement traceable instead of erasing it. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Timeline / Chronology > The seven-phase story chronology from Sol Mamy's origin through present day and SOLMAMY's creation — structure set, most dates not yet determined. ## Status [Section titled “Status”](#status) **Partial — structure established, most dates and sequence details not yet determined.** | Phase | What happens | Status | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 — Before Earth | Born on Lunaris Prime (proposed); becomes Keeper of the Lunar Vault | Canonical (Keeper role); Proposed (Lunaris Prime origin, not owner-confirmed) | | 2 — The accident | Aboard the *Lunar Wanderer*, a shortcut through an uncharted debris field damages the hull shielding | Proposed (authored account); the true cause remains Open/Unresolved | | 3 — The landing | Emergency landing on Earth; the Vault is salvaged | Settled as authored; exact date not determined | | 4 — Partnership | SOLMEME intercepts the broadcast; the monthly-shipment arrangement forms — the first contributor relationship, not the only kind | Proposed | | 5 — Ecosystem growth | SOL Launchpad projects and the Vault Defender community join as further contributor threads | Proposed | | 6 — Present day | Ongoing monthly SOLMEME shipments; Sol Mamy recognizes the same worldview she already lives by in Earth’s on-chain systems (see Stories — Why she eventually builds SOLMAMY) | Proposed | | 7 — SOLMAMY’s creation (future, in-story) | Sol Mamy applies her worldview using Earth’s own tools, building toward what becomes SOLMAMY | Proposed. **Real-world note**: this is a story beat, not a claim that the real SOLMAMY company exists yet — see Canon Principles — story world vs. real world, and Brand Book — Foundation — Status | ## Rule [Section titled “Rule”](#rule) New events (a game launch, a major story beat, a new character’s introduction) are added as new rows to this table, each carrying its own status. Do not insert an event without also stating whether it’s Canonical or Proposed. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Absolute or relative dates for Phases 1–2; any event between Phase 2 and Phase 5 beyond what’s listed. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Universe Overview > The Lunar Vault, the SOLMAMY ecosystem built around it, and SOLMEME's place as one contributor relationship rather than the universe's foundation. ## Canonical [Section titled “Canonical”](#canonical) The SOLMAMY universe centers on the **Lunar Vault**, an institution Sol Mamy protects as its Keeper, and the SOLMAMY ecosystem built around it. SOLMAMY’s **planned core business** is Launchpad + Analytics + Reputation — pre-launch, not yet operating (see Brand Book — Foundation — Status); **Vault Defender** (a community game) sits in the broader **ecosystem/community layer**, alongside Community and Documentation, not inside the core three — Vault Defender *is* the game, not a separate item. **SOLMEME**, the monthly memecoin, is one relationship contributing to the Vault, not the universe’s foundation or its cause. The Vault’s own state/rank mechanic is documented in full in Progression / States — this chapter doesn’t repeat it. ## Proposed [Section titled “Proposed”](#proposed) The Vault is fed by contributor relationships, of which SOLMEME’s monthly shipment is one instance of a broader pattern, not the origin of the pattern itself. SOL Launchpad projects joining the ecosystem are framed, in-story, as new artifacts entering the Vault; their reputation/analytics data is framed as a modern equivalent of the physical artifacts the Vault already holds. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) The universe’s full geography, its relationship to any real-world or other fictional setting, and its scale beyond what’s stated above. See World Structure for the broader structural picture and Locations for what’s confirmed geographically. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # World Structure > The Lunar Vault as the universe's central institution, and a proposed lore explanation for Sol Mamy's costume variety. ## Canonical [Section titled “Canonical”](#canonical) The universe is structured around one central institution — the **Lunar Vault** — and the contributor relationships that feed it. See Universe Overview for the ecosystem-level picture and Progression for the Vault’s own mechanical state system. ## Proposed — Why the costume varies [Section titled “Proposed — Why the costume varies”](#proposed--why-the-costume-varies) Sol Mamy’s collection includes items from across her travels — she tries them on. A beach look, a ninja look, a statue look, a ski look: all framed as items from her own Vault, not arbitrary reskins. This is offered as a supporting narrative for one candidate answer to a separate, unresolved production question — the brand-mark-consistency rule for thematic costumes (Mascot Book — Design Variants) — not itself a decision on that question. **Explicit scope note**: this “why” is a lore interpretation only. It is not connected to, and does not derive from, the actual production Costume Library (Mascot Book — Costume & Design System), which defines costumes by production event/occasion, independently of this narrative. The two currently coexist without contradiction but without being formally linked. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Broader physical/magical/technological rules governing how the world works beyond the Vault and its contributor-relationship model. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Talking-Head Brand Documentation > Brand rules for how SOLMEME/SOLMAMY presents as a talking-head presenter — scope, status, and chapters covering identity, appearance, persona, voice, and usage. Talking-Head Brand Documentation v1.1 ## Purpose [Section titled “Purpose”](#purpose) Brand rules for how SOLMAMY presents itself as a talking-head presenter, news anchor, or virtual communicator — SOLMAMY being the planned company/ecosystem Sol Mamy is mascot of, a separate entity from SOLMEME (the peripheral, monthly-released memecoin persona; see Brand Book — Terminology). This document does **not** decide or describe the underlying technology (2D motion-transfer, Unreal/MetaHuman, or any other implementation), animation stack, or rendering pipeline — those are engineering decisions, made elsewhere, and explicitly out of scope here regardless of what technical research exists. ## Scope [Section titled “Scope”](#scope) **In scope**: presenter identity, appearance principles, voice, tone, communication behavior, framing, visual branding, mascot/brand relationship, logo/mark usage, allowed/prohibited brand behavior. **Out of scope**: any technology-stack choice, animation implementation, motion-capture, rendering, or production pipeline. ## Status of this document [Section titled “Status of this document”](#status-of-this-document) **Structural framework only.** No brand-specific source material for a talking-head presentation of Sol Mamy exists yet — confirmed by direct search, a real current gap. This document establishes the correct chapters and inherits Mascot Book and Brand Book’s existing rules; every medium-specific fact is marked as a gap rather than invented. ## Ownership & Provenance [Section titled “Ownership & Provenance”](#ownership--provenance) This book is part of the SOLMEME Brand Documentation System. The materials created within this project, and the rights to them, belong to **Lavatti Union** — see `OWNERSHIP_AUTHORITY.md` (the system’s single canonical source for this fact) for the full statement. This book applies Brand and Mascot facts to a presenter/communicator context; it does not itself grant, license, or transfer any right. A team building a talking-head implementation from it does not become the owner of the underlying system by doing so. ## Chapters [Section titled “Chapters”](#chapters) 1. [Presenter Identity](/docs/reference/talking-head-book/presenter-identity/) 2. [Persona](/docs/reference/talking-head-book/persona/) 3. [Appearance](/docs/reference/talking-head-book/appearance/) 4. [Voice](/docs/reference/talking-head-book/voice/) 5. [Communication](/docs/reference/talking-head-book/communication/) 6. [Framing Principles](/docs/reference/talking-head-book/framing/) 7. [Visual Branding](/docs/reference/talking-head-book/visual-branding/) 8. [News Communication](/docs/reference/talking-head-book/news/) 9. [Usage](/docs/reference/talking-head-book/usage/) 10. [Quick Reference](/docs/reference/talking-head-book/quick-reference/) # Appearance > The talking-head presenter uses Sol Mamy's canonical appearance as defined in the Mascot Book — what's fixed, what's undocumented, and what not to do. ## Rule [Section titled “Rule”](#rule) Any visual presentation of Sol Mamy as a talking-head presenter uses her canonical appearance exactly as defined in Mascot Book — Visual Identity: same mask, ears, tail, proportions, and palette. Nothing about the talking-head medium changes what she looks like. ## Use [Section titled “Use”](#use) * Framing: a talking-head presentation is typically a close/medium shot (head-and-shoulders or medium-close) — this is a framing convention, not a change to her appearance itself. * Costume: R1 (Canonical Light Suit) or an approved variant. Mascot Book — Costume & Design System’s own “Event-specific variants” table has a real, named “News presenter” row (Proposed, not yet owner-confirmed): same base palette, a simple lapel/collar suggestion, microphone/desk props. Also relevant: the same table’s “Analyst” row (same palette, tie/chart-clip accessory, tablet/chart prop) for market-analysis content. Neither is owner-confirmed as final, so still treat as Proposed, not settled. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Whether the Proposed “News presenter”/“Analyst” costume variants above (Mascot Book — Costume & Design System) should be formally adopted for talking-head use specifically, or whether a distinct presenter costume/setting is needed instead — not resolved here. * Whether a dedicated presenter setting (a desk, a backdrop) beyond the costume question above exists — no such asset has been produced or approved. * Exact framing/camera conventions specific to this medium — not yet documented at the brand level. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not alter her proportions, face, or silhouette “for close-up readability” — the same invariants apply at any framing distance. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Communication > Presenter-specific behavior for recurring formats — announcements, market updates, celebratory content, warnings — and what's allowed vs. prohibited. ## Rule [Section titled “Rule”](#rule) Recurring communication formats (announcements, market updates, celebratory content, warnings) inherit Media Book — News for content-level rules and this document only for presenter-specific behavior. ## Allowed / Prohibited brand behavior [Section titled “Allowed / Prohibited brand behavior”](#allowed--prohibited-brand-behavior) See Usage — Allowed brand behavior / Prohibited brand behavior for the full, canonical list (delivery style, presenter identity, and verified-claims rules). This chapter adds no communication-format-specific exception or addition to that list — cited rather than restated, per this project’s own citation-discipline pattern (e.g. Media Book — Voice & Tone citing Brand Book rather than restating). ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) A fixed set of named recurring formats (e.g. a “Market Update” segment, a “Breaking News” format) does not exist yet at the brand level — see Media Book — News for the same open item. This document will inherit whatever’s decided there. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Framing Principles > No confirmed camera-framing convention exists yet — the working default, the owner's fixed set of 11 presenter states, and the rule against inventing more. ## Status: Not yet determined [Section titled “Status: Not yet determined”](#status-not-yet-determined) No confirmed camera-framing or shot-composition convention specific to a talking-head presentation exists yet. ## Working default [Section titled “Working default”](#working-default) A close/medium shot (head-and-shoulders or medium-close) is the typical convention for this format generally — stated here as a reasonable working default, not as a sourced brand rule. ## Owner-provided — Fixed presenter states (visual only) [Section titled “Owner-provided — Fixed presenter states (visual only)”](#owner-provided--fixed-presenter-states-visual-only) An owner-provided requirement establishes a small, **fixed** set of 11 named presenter states — the team produces new news content by swapping topic/text only, never by redesigning the presenter per item: Neutral, Speaking, Serious, Breaking-news, Excited, Concerned, Pointing-at-a-chart, Standing-beside-information, Holding-a-microphone, At-a-desk, In-a-newsroom. Two backgrounds cover all 11: a plain studio backdrop, and a newsroom-specific backdrop (this second one is a proposed design, not sourced from any design brief). **Explicit separation (owner-provided)**: this fixed state set governs *visual* presentation only. What the presenter says — tone, vocabulary, dialogue — is governed entirely separately by Mascot Book — Voice; it is never mixed into the visual-state definition. ## Rule [Section titled “Rule”](#rule) Do not invent detailed framing/camera specifications beyond the fixed state set above and present them as settled. When real framing guidance is needed beyond what’s listed, source it explicitly rather than expanding this working default. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # News Communication > News-format content delivered by the talking-head presenter follows the Media Kit for content-level rules and this book for presenter-specific behavior. ## Rule [Section titled “Rule”](#rule) News-format content delivered by the talking-head presenter follows Media Book — News for content-level rules and this book for presenter-specific behavior (Voice, Communication, Persona). ## Use [Section titled “Use”](#use) Factual/update content is delivered in her established voice, not a flattened neutral tone — see Voice. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) No fixed set of named recurring news formats (e.g. “Market Update,” “Breaking News”) exists yet — shared gap with Media Book — News. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Persona > The talking-head presenter's persona is Sol Mamy's own established personality, expressed through a presenter role — not a separate invented persona. ## Rule [Section titled “Rule”](#rule) The talking-head presenter’s persona is Sol Mamy’s own established personality (Mascot Book — Personality) — playful, resourceful, curious, loyal, mischievous, ambitious — expressed through a presenter/communicator role, not a separate invented persona. ## Situational test (TALKINGHEAD-RULE-01, partial) [Section titled “Situational test (TALKINGHEAD-RULE-01, partial)”](#situational-test-talkinghead-rule-01-partial) Per Google Conversation Design’s “Create a Persona” methodology, a persona chapter should include an operational test — “what would this persona say or do in situation X” — not only trait adjectives. Built here from Mascot Book — Personality’s own **Trait → visual rule** table (the only already-established source that ties a trait to a concrete, checkable expression), not from an invented scenario: * **Situation: a celebratory moment (e.g. a milestone announcement).** Test: her reaction should read as the Playful trait’s sourced expression — the open-armed celebration pose (Mascot Book — Personality, “Illustrated”) — not a subdued or neutral reaction. * **Situation: a self-serving or “gotcha” beat (e.g. claiming a good find for the Vault).** Test: her reaction should read as the Mischievous trait’s sourced expression — Expression #10, “Greedy (playful)” (Mascot Book — Personality, “Specified, not yet illustrated”) — not flat amusement. * **Situation: stating a goal or resolving to act.** Test: her reaction should read as the Ambitious trait’s sourced expression — Expression #5, “Determined” (Mascot Book — Personality, “Specified, not yet illustrated”). **Honest limit**: this test only covers 3 of the 6 traits (Playful, Mischievous, Ambitious) because Mascot Book’s own table has no visual rule yet for Resourceful, Curious, or Loyal — that gap belongs to Mascot Book, not invented or filled here. A reviewer applying `DOC-CONTENT-01` against Resourceful/Curious/Loyal cannot yet predict a concrete response from sourced material alone. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) Whether any persona traits specific to the presenter role (e.g. “trusted news source,” “community insider”) should be layered on top of her base personality has not been decided — no source establishes this. ## Do not use [Section titled “Do not use”](#do-not-use) Do not invent a distinct “anchor persona” separate from her established character personality. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Presenter Identity > The talking-head presenter is Sol Mamy herself, not a separate persona — what that means and what's not yet determined about presenter-specific naming. ## Rule [Section titled “Rule”](#rule) The talking-head presenter, wherever one exists, is Sol Mamy — not a separate persona or character. Her identity, per Mascot Book — Identity, applies without modification: same name, same role, same family relationships. ## Use [Section titled “Use”](#use) If a talking-head presenter is produced, it presents as Sol Mamy specifically — not a generic “SOLMEME news anchor” character invented separately. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Any presenter-specific naming or on-screen branding (a show title, a segment name) — none exists yet. SOLMEME is not a visual variant of Sol Mamy (see Mascot Book — Brand/Mark Relationship) and has no defined visual identity to present as — a presenter never presents “as SOLMEME instead of Sol Mamy.” *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Quick Reference > A one-page scan of every talking-head brand fact and its status — most rows are real, current gaps, not oversights. | Item | Detail | Status | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Presenter identity | Sol Mamy, no separate persona | Canonical (inherited from Mascot Book) | | Appearance | Inherits Mascot Book — Visual Identity | Canonical (inherited) | | Voice | Inherits Mascot Book — Voice | Canonical (inherited) | | Fixed presenter visual states (11) | Neutral, Speaking, Serious, Breaking-news, Excited, Concerned, Pointing-at-a-chart, Standing-beside-information, Holding-a-microphone, At-a-desk, In-a-newsroom (corrected 2026-09-03 to match Framing Principles’ exact names, not an abbreviated table shorthand) | Owner-provided requirement | | Backgrounds | Studio backdrop (reused base); newsroom backdrop | Owner-provided requirement (studio); Proposed, not sourced (newsroom) | | Framing convention beyond the 11 fixed states | Close/medium shot, working default only | Not sourced/confirmed | | On-screen branding package | — | Not yet determined | | Underlying technology (2D/Unreal/MetaHuman) | — | Explicitly out of scope for this book | This document is a structural framework — most rows are real, current gaps, not oversights. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Usage > Allowed and prohibited brand behavior for the talking-head presenter, and cross-references to where character, brand, and content-level news rules live. ## Allowed brand behavior [Section titled “Allowed brand behavior”](#allowed-brand-behavior) * Playful, warm, occasionally mischievous delivery, consistent with Mascot Book — Personality. * Referencing the Lunar Vault Module or her established role where relevant. ## Prohibited brand behavior [Section titled “Prohibited brand behavior”](#prohibited-brand-behavior) * A flat, personality-free “corporate spokesperson” delivery. * Introducing a different character or persona as the presenter instead of Sol Mamy. * Deciding or describing the underlying presentation technology (2D motion-transfer, Unreal/MetaHuman, or any other implementation) — explicitly out of scope for this book. * Making any claim about SOLMAMY’s product state, or about SOLMEME’s, that isn’t independently verified — this document governs brand presentation only, never product facts. The two are separate entities (see Brand Book — Terminology). This section (Allowed/Prohibited brand behavior) is the canonical statement of these rules for the Talking-Head Book — Communication cites this chapter rather than restating it. ## Cross-references [Section titled “Cross-references”](#cross-references) * Character facts: **Mascot Book** * General brand facts: **Brand Book** * Content-level news rules: **Media Book — News** *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Visual Branding > On-screen branding for the talking-head presenter uses the Brand Book's color direction and the mascot as the sole mark — no branding package exists yet. ## Rule [Section titled “Rule”](#rule) Any on-screen branding (lower-thirds, backdrop, title cards) uses Brand Book’s color direction and the mascot as the sole mark — see Brand Book — Logo & Mark, Color System. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) No dedicated on-screen branding package (lower-third design, backdrop, title-card treatment) exists yet. ## Do not use [Section titled “Do not use”](#do-not-use) Do not design a separate visual-branding system for this medium independent of Brand Book’s existing color/mark rules. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Voice > The talking-head presenter speaks in Sol Mamy's own voice, even for factual news — tone notes, an unconfirmed research note, and a palette correction. ## Rule [Section titled “Rule”](#rule) The talking-head presenter speaks in Sol Mamy’s own established voice (Mascot Book — Personality & Voice) — playful, a little mischievous, never flat or corporate — even when delivering factual news or updates. This is the same rule stated in Media Book — News, restated here because it governs a specific presentation format. ## Use [Section titled “Use”](#use) * Tone stays consistent with her six personality traits regardless of subject matter. * Institutional facts (market data, product updates) are delivered in her voice, not switched to a neutral announcer tone. ## Not yet determined [Section titled “Not yet determined”](#not-yet-determined) * Speech pacing, catchphrases, or recurring verbal habits specific to a presenter format — none documented yet beyond her general voice rules. ## Do not use [Section titled “Do not use”](#do-not-use) * Do not flatten her voice into a generic, personality-free news-anchor tone. ## Proposed — Talking-head tone note [Section titled “Proposed — Talking-head tone note”](#proposed--talking-head-tone-note) Existing (unconfirmed) research for this format describes the intended tone as ironic/wry, woven with universe lore references (the Vault, the memecoin cycle) rather than a flat news-delivery style. This is consistent with, and an application of, her established personality (Mascot Book — Personality) to this specific medium — not a new or separate persona. Both source research documents are themselves marked overall status PROPOSED, requiring owner confirmation — this note remains Proposed/unconfirmed. ## Known source inconsistency, corrected here [Section titled “Known source inconsistency, corrected here”](#known-source-inconsistency-corrected-here) The same research describes her appearance using an outdated “white/cyan/lavender/gold” palette. This conflicts with the current canonical palette. The real, current canonical palette (Mascot Book — Visual Identity) is pearl-white (base), cyan/teal (branch accent), and pink as clan accent (not lavender) — **and there is no gold anywhere on the suit itself**. *** *Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see `OWNERSHIP_AUTHORITY.md` at the documentation system’s root.* # Apply for Ambassador > Step-by-step: applying for the Ambassador program. Step-by-step: applying for the Ambassador program. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Complete Your First Mission > Step-by-step: completing your first community mission. Step-by-step: completing your first community mission. Status Skeleton page. Structure — `doc/PHASE_0_1A_SITE_STRUCTURE_PLAN_v3.md` §11.1. Real content not yet written. # Create Community Content > Beyond memes: the real ways to contribute content to SOLMEME's community, and where each one starts. Memes are the fastest way in, but not the only one — this covers the real content pathways SOLMEME’s community actually has today, and where to start each. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) None specific to content creation — see each pathway below for its own requirements. ## Steps [Section titled “Steps”](#steps) 1. **Pick a pathway.** The three real ones today: * **Memes** — the fastest, lowest-effort path. Covered fully in its own tutorial: [Create Your First Meme](/docs/tutorials/create-your-first-meme/). * **Lore-based content** — SOLMEME has a real, recurring cast (the Council of Cats — Laser Cat, Vault Cat, Moon Cat, Sword Cat) and running community in-jokes you can reference and build on. See [Guides → Lore](/docs/guides/creators/lore/) for the full cast and existing community templates. * **Meme Wall submissions** — a step beyond a one-off share: submit to compete for Meme of the Month. See [Guides → Meme Wall](/docs/guides/creators/meme-wall/) for how a submission actually climbs there. 2. **Make something that fits the pathway you picked.** Lore content works best when it references the existing cast/in-jokes rather than inventing new lore from scratch — see the Lore page’s own real examples for the tone. 3. **Share it.** All three pathways connect to the same share-to-earn XP mechanic — exact XP values are set on the live platform, not documented here. ## What Happens Next [Section titled “What Happens Next”](#what-happens-next) Strong content — memes or lore-based — is what actually gets pulled into the [Meme Wall](/docs/guides/creators/meme-wall/)’s Meme of the Month consideration, regardless of which pathway it started from. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Guides → Creators](/docs/guides/creators/) — the full overview this tutorial is based on * [Create Your First Meme](/docs/tutorials/create-your-first-meme/) — the concrete meme-specific version of this * [Lore](/docs/guides/creators/lore/) — the cast and in-jokes real lore content draws on # Create Your First Meme > Step-by-step: pick a template, write a caption, and share your first SOLMEME meme. Pick a SOLMEME template, write a caption, and share the result — the fastest way to make your first real contribution to the community. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) Good news — you don’t need anything crypto-specific to get started. No token holding or wallet connection is required just to create and share a meme; the generator itself is open to use. You’ll want a Discord or X (Twitter) account if you plan to share what you make. ## Steps [Section titled “Steps”](#steps) 1. **Open the Meme Generator.** Go to the [live Meme Generator](https://www.solme.me/meme-generator) on `solme.me`. 2. **Pick a template.** Choose from SOLMEME’s available templates. 3. **Write your caption.** Keep it on-brand — see [Guides → Creators → Lore](/docs/guides/creators/lore/) if you want your caption to reference the Council of Cats or SOLMEME’s in-universe cast. 4. **Share it.** Post your finished meme — sharing itself earns XP as part of SOLMEME’s share-to-earn mechanic (exact XP amounts aren’t fixed here; they’re set on the live tool, not in this documentation). ## What Happens Next [Section titled “What Happens Next”](#what-happens-next) Top shared memes enter community voting and get considered for the Meme of the Month pipeline. See [Guides → Meme Wall](/docs/guides/creators/meme-wall/) for how a meme actually climbs toward that. ## Check Your Result [Section titled “Check Your Result”](#check-your-result) Your meme should appear wherever SOLMEME’s live sharing/voting surface shows recent submissions — check the [live Meme Generator](https://www.solme.me/meme-generator) to confirm it posted. Current queue depth, vote counts, and this month’s shortlist change continuously and aren’t restated here. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Meme Generator (mechanism)](/docs/guides/creators/meme-generator/) — the fuller explanation this tutorial is based on * [Meme Wall](/docs/guides/creators/meme-wall/) — where shared memes compete for Meme of the Month * [Lore](/docs/guides/creators/lore/) — SOLMEME’s recurring characters and world, useful for caption ideas # Join the Discord > Step-by-step: join SOLMEME's real Discord — the main hub for drop countdowns, whale alerts, and meme contests. Discord is SOLMEME’s main real-time community hub — drop countdowns, hype rooms, whale alerts, and meme contests all happen there first. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) A free Discord account. If you don’t have one, Discord’s own sign-up flow handles that as part of joining. ## Steps [Section titled “Steps”](#steps) 1. **Open the official invite.** Go to [discord.gg/solmeme](https://discord.gg/solmeme) — this is the real, official SOLMEME Discord invite link, the same one linked from this site’s own header. 2. **Accept the invite.** If you’re not already signed into Discord, you’ll be prompted to sign in or create an account first. 3. **Complete any server-specific entry steps.** Servers commonly gate access behind rules-acceptance or verification — follow whatever the server itself prompts; those steps are set inside Discord, not documented here. 4. **Find your way around.** Drop countdowns, hype rooms, whale alerts, and meme contests are the server’s real, active channels — explore from there. ## Verify You’re in the Right Place [Section titled “Verify You’re in the Right Place”](#verify-youre-in-the-right-place) Only trust invite links from this documentation site or SOLMEME’s other official channels ([X/Twitter](https://x.com/SOLMemeToken), [Telegram](https://t.me/solmemetoken)) — see [Verify an Official Account](/docs/tutorials/verify-an-official-account/) if you’re unsure whether a link or account you found elsewhere is real. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Verify an Official Account](/docs/tutorials/verify-an-official-account/) — how to confirm a channel/account is real before trusting it * [Community Overview](/docs/community/) — how SOLMEME’s community is actually run * [Getting Started](/docs/getting-started/) — where to go depending on what brought you here # Use the Vault > Step-by-step: hold SOLMEME drops, combine keys, and claim your first Vault reward. Turn held SOLMEME drops into Vault rewards — from getting your first tokens to claiming a reward tier. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) A Solana-compatible wallet (see [Solana](/docs/learning/topics/solana/) for what that means) with a small amount of SOL for transaction fees. ## Steps [Section titled “Steps”](#steps) 1. **Get SOLMEME.** Use the [Swap](/docs/guides/vault/swap/) widget on the live site — no SOLMEME platform fee, powered by Jupiter. 2. **Hold your drop(s) in your wallet.** The Vault reads your wallet’s holdings directly — no separate deposit or staking step. See [How the Vault Works](/docs/guides/vault/) for the full mechanism. 3. **Check your tier.** Rewards scale with how many distinct drops you hold at once — see the [Reward Tiers table](/docs/guides/vault/#reward-tiers) for what each tier unlocks. 4. **Claim your reward and check your position.** When your wallet matches a Vault recipe, claim it and see your place on the [Treasure Grid](/docs/guides/vault/grid/). ## Going Further [Section titled “Going Further”](#going-further) Holding solo is the simplest path, but not the only one — see [Community Raids](/docs/guides/vault/community-raids/) and [Buddy Drops](/docs/guides/vault/buddy-drops/) for ways to combine progress with other holders, and [Vault Keys](/docs/guides/vault/keys/) for how keys substitute for tokens you don’t hold directly. ## Check Your Result [Section titled “Check Your Result”](#check-your-result) Live vault status, your current tier, and claimable doors change continuously — see the [live Vault](https://www.solme.me/vault) for your real-time position; this page covers the mechanism, not a point-in-time snapshot of it. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Vault Overview](/docs/guides/vault/) — the fuller mechanism this tutorial is based on * [Treasure Grid](/docs/guides/vault/grid/) — the full 36-cell map of every door * [Vault Settings](/docs/guides/vault/settings/) — control which Vault notifications you receive # Verify an Official Account > How to confirm a SOLMEME account, channel, or link is real before you trust or click it. Impersonation accounts and fake links are common across crypto communities generally — this covers how to check before you trust or click one, using SOLMEME’s own real channels as the reference points. ## The Real, Official Channels [Section titled “The Real, Official Channels”](#the-real-official-channels) These are the only accounts/links this documentation site treats as official: * **Discord**: [discord.gg/solmeme](https://discord.gg/solmeme) * **X (Twitter)**: [x.com/SOLMemeToken](https://x.com/SOLMemeToken) * **Telegram**: [t.me/solmemetoken](https://t.me/solmemetoken) * **TikTok**: [@solmemeofficial](https://www.tiktok.com/@solmemeofficial) * **Instagram**: [@solmemeofficial](https://www.instagram.com/solmemeofficial/) Bookmark this page or this site’s own header (same links, always kept in sync) as your reference — not a search engine result or a link someone sent you directly. ## Steps [Section titled “Steps”](#steps) 1. **Start from a source you already trust.** This documentation site, or a channel you already verified through it — not a link from an unsolicited DM, a comment, or a search ad. 2. **Compare the exact URL, not just the display name.** Impersonation accounts commonly use a near-identical name or handle with the real logo — the URL itself is what to check character-by-character against the list above. 3. **Check the platform’s own verification signals**, where the platform provides them (verified badges, official account labels) — but treat these as a secondary signal, not sufficient on their own; the URL match above is the real check. 4. **Never treat being contacted first as a trust signal.** Official accounts generally don’t DM users first to offer help, giveaways, or support — an unsolicited DM claiming to be SOLMEME support/staff is the single most common impersonation pattern across crypto projects, not something specific to SOLMEME. ## If Something Looks Wrong [Section titled “If Something Looks Wrong”](#if-something-looks-wrong) Flag it to a moderator in the real [Discord](https://discord.gg/solmeme) — that’s the fastest, real reporting path today. A dedicated written reporting process is planned for [Community → Reporting](/docs/community/reporting/), not published yet. ## Related Pages [Section titled “Related Pages”](#related-pages) * [Join the Discord](/docs/tutorials/join-the-discord/) — using the real, verified invite link * [Community Overview](/docs/community/) — SOLMEME’s own community structure