MoonCats landing pages: comparative survey

Research workflow note: [survey.md](./survey.md) is now the collaborative master catalogue for site-by-site visual, funnel, and usability references. This report remains the deeper synthesis and technical/background analysis.

Research date: 2026-08-02
Purpose: Establish useful design, information-architecture, interaction, and funnel patterns for one or more MoonCats landing pages that help newcomers understand the project and reach the right existing ChainStation or ecosystem destination.

Executive conclusion

Most large NFT websites now follow one of two models:

1. Entertainment-brand storefront: cinematic hero, lifestyle language, merch or product calls to action, and a polished corporate navigation system.
2. Collection utility portal: wallet connection, gallery, marketplace links, minting, traits, rewards, and project-specific tools.

Neither model is sufficient for MoonCats by itself.

The most promising direction is an editorial museum shell + living toolbench + community hackerspace:

• editorial enough to explain the art, history, and technical significance without overwhelming a new visitor;
• functional enough to make ChainStation tools, collection exploration, owner features, and builder resources easy to find;
• strange, colorful, and handmade enough to feel native to MoonCats rather than like a startup template;
• static-first and progressively enhanced so the landing experience remains extremely fast;
• designed mobile-first, with important tasks available without navigating a desktop-style mega-menu.

A useful visual formula is:

Clear modern typography and structure around expressive pixel art, historical artifacts, technical diagrams, and playful interactive details.

The landing-page work should borrow the organizational discipline of contemporary brand sites without adopting their sales language, excessive animation, or interchangeable “premium IP” appearance.

Research method and confidence

The survey examined current public pages, page structure, navigation, visible calls to action, content emphasis, and publicly detectable technical signals.

Framework identification is intentionally conservative:

• High confidence: explicit source, unmistakable platform signature, or strongly identifiable default application shell.
• Medium confidence: independent technology detector or clear but not definitive asset/runtime evidence.
• Low confidence: plausible inference only.
• Unknown: no reliable evidence was found; no framework is guessed.

Some highly animated or protected sites expose little useful content to text-based inspection. Those entries focus on observable product positioning and avoid pretending the implementation is known. Third-party framework detections are also snapshots—often from 2025—and should be rechecked before making technical decisions.

1. Current MoonCats baseline

MoonCatRescue ChainStation

Primary job: Explain the project while routing visitors into a large collection of adoption, collection, owner, accessory, ENS, history, documentation, and community tools.

Current strengths

• The site contains real utility rather than a decorative landing page.
• Navigation reflects the depth of the ecosystem: collections, tools, history, documentation, building, and ownership.
• The language retains personality and avoids generic luxury-brand copy.
• The homepage acknowledges both the 2017 origin and the project’s continuing technical life.

Current weaknesses

• The homepage presents several unrelated destinations with similar visual weight.
• A new visitor must understand internal terms before knowing where to begin.
• “About,” “Adopt,” “Play,” “Build,” collection pages, owner tools, current happenings, and merch compete for attention.
• The wrapper does not communicate the quality and depth of the underlying tools quickly enough.
• The experience feels organized around existing functions rather than the visitor’s next decision.
• Social links are available, but not treated as persistent, easy-reach navigation.

Landing-page lesson

Do not try to reproduce ChainStation’s functional depth on the landing page. Present a much clearer hierarchy that explains MoonCats and routes visitors toward the existing destination that best matches their intent. The immediate problem is primarily one of onboarding, information hierarchy, and task routing.

2. Comparative site matrix

Original survey sites

Added high-value references

3. Patterns by site type

A. Entertainment-brand sites

Examples: Doodles, Azuki, Pudgy Penguins, BAYC, Chimpers, Quirkies, Mocaverse, Good Vibes Club.

What they do well

• Persistent top navigation with clear ecosystem buckets.
• Strong art direction and polished responsive layouts.
• Large, obvious calls to action.
• Social, shop, collection, and account destinations remain easy to find.
• Non-pixel fonts give pixel or character art room to feel like artwork rather than UI chrome.
• They establish a recognizable visual rhythm through large art, short headings, and alternating sections.

What MoonCats should avoid copying

• Hero sections that say almost nothing beyond a brand slogan.
• Autoplay video or 3D that delays the first meaningful content.
• Generic language about “community,” “culture,” “storytelling,” and “the future” without concrete evidence.
• Treating every visitor as a buyer or customer.
• Shop-first information architecture.
• Huge agencies’ visual effects without a clear task underneath them.
• Hiding history, contracts, or practical tools in the footer.

B. Art, history, and technical sites

Examples: Art Blocks, PixelMap, Etheria, 0xDEAFBEEF, Milady Maker, XCOPY, Nyan Cat Collection.

What they do well

• The interface reinforces the project’s actual origin and worldview.
• Dates, artifacts, contracts, processes, and creator context are treated as meaningful content.
• They can be visually memorable without mimicking a commercial product launch.
• The strongest sites are comfortable letting technical detail remain visible.
• Chronology is often more effective than a generic “roadmap.”
• The work is given space and authority.

Risks

• Long pages without progressive disclosure.
• Insider language before a newcomer has a basic model of the project.
• Desktop-first typography and navigation.
• Weak accessibility and no useful no-JavaScript state.
• Historical detail without a clear present-day action.

C. Utility and ecosystem interfaces

Examples: MoonCatRescue ChainStation, Frens, StonkBrokers, Hashmasks, Nouns, Loot, PXL POD, Bearish.

What they do well

• The project’s mechanics are visible rather than abstracted into marketing copy.
• Status, ownership, contracts, live data, and actions create credibility.
• Naming tools or modules can make a complex ecosystem easier to remember.
• Repeated action routes reduce the need to return to the homepage.

Risks

• Navigation follows internal system architecture instead of visitor intent.
• Wallet connection is presented as a prerequisite even when it is not needed.
• Every tool receives equal visual weight.
• Landing pages become dashboards before explaining what the dashboard is for.
• Mobile layouts inherit desktop density.

4. Implications for MoonCats landing pages

4.1 Recommended funnel model

The immediate goal is not to redesign ChainStation or unify every MoonCats destination. The landing-page layer should act as a fast, attractive public front door that helps visitors build a basic mental model of MoonCats and then move deliberately into existing pages and tools.

A landing page should answer, in roughly this order:

1. What are MoonCats?
2. Why are they interesting or historically significant?
3. What might I want to do next?
4. Which existing destination should I use for that?

Different audiences may justify more than one landing page or entry funnel rather than forcing every visitor through the same long homepage.

Likely destination categories include:

• collection exploration and acquisition;
• owner and ChainStation tools;
• history and project background;
• technical documentation, contracts, data, and building resources;
• community activity and social channels.

The landing layer should remain lightweight and should not initialize wallet libraries, large collection indexes, 3D scenes, or heavy application code merely to explain the project or present navigation choices.

4.2 Candidate landing-page navigation

This is a hypothesis to test, not a proposed replacement sitemap for ChainStation:

• About — concise MoonCats introduction
• Explore — route into collection browsing or acquisition
• Tools — route into relevant ChainStation functionality
• History — route into historical context and deeper references
• Build — route into contracts, docs, code, APIs, and assets
• Community — current activity and social destinations

Persistent utility area:

• X, Discord, and possibly GitHub;
• one or two visually dominant calls to action selected from actual visitor needs rather than assumed in advance.

The landing page does not need to reproduce wallet/account controls or the full navigation model of the tools it links to. On mobile, the priority is large tap targets, clear labels, visible socials, and easy access to the primary destinations.

4.3 Candidate landing-page sequence

This is a starting structure for testing rather than a committed design.

1. Immediate identity — MoonCats artwork, name, launch year, and one concrete sentence.
2. Primary actions — likely some combination of Explore MoonCats, Find/Adopt a MoonCat, Use ChainStation, and Learn the Story.
3. Why MoonCats matter — a small number of verifiable historical or technical facts.
4. Collection glimpse — lightweight visual proof of the art and variety, without requiring wallet connection.
5. Choose your path — a small number of clearly described routes into existing MoonCats and ChainStation destinations.
6. Living project — selected current activity, tools, community work, or recent naming activity where useful.
7. History / builder entry points — compact invitations to deeper historical and technical material.
8. Community and socials — easy to reach before the footer as well as inside it.

4.4 Visual direction

Recommended

• Pleasant editorial sans or serif fonts for navigation, headings, and long-form reading.
• Pixel type used sparingly for labels, timestamps, technical readouts, or historical interface references.
• Large areas of real MoonCat color rather than one corporate accent color.
• Diagrams, contract fragments, rescue logs, archived screenshots, star charts, grids, and physical/technical textures.
• Deliberate asymmetry or “workbench” details inside an otherwise stable grid.
• Visible seams: labels, annotations, provenance, versions, source links, and timestamps.
• Motion that explains a system or rewards exploration, not motion used as a loading screen.
• Art direction that can vary between landing-page sections while preserving a coherent typographic and navigation system.

Avoid

• A wall-to-wall pixel font.
• Fake CRT effects across the entire site.
• Generic black background + neon gradient + glass cards.
• Luxury-fashion spacing and vague manifesto copy.
• Huge rounded cards used for every type of content.
• Excessive starfield/space clichés unless the treatment is specifically MoonCats-derived.
• A corporate “IP universe” voice.
• An interface that resembles an NFT marketplace before it resembles MoonCats.

4.5 Calls to action

Calls to action should describe real tasks rather than conversion goals.

Better candidates:

• Explore all MoonCats
• Find a MoonCat
• View my MoonCats
• Read the rescue story
• Open ChainStation tools
• Build with MoonCats

Avoid defaulting to:

• “Join the community” as the only main action;
• “Enter the ecosystem”;
• “Discover the future”;
• wallet connection before the visitor selects an owner-specific task;
• marketplace purchase as the sole definition of participation.

5. Mobile requirements

The landing experience should be designed mobile-first rather than treated as a reduced desktop page.

Navigation

• Large, labeled destinations rather than icon-only navigation.
• Social links visible directly in the menu.
• Current page and menu state must remain obvious.
• Wallet/account controls should not displace the primary content task.
• Important calls to action should remain reachable after the hero without a long scroll back upward.

Content

• One clear claim or task per viewport during onboarding.
• Historical facts and tool descriptions should use expandable details rather than tiny text.
• Collection previews must work with touch and should not depend on hover.
• Avoid full-screen canvas effects that trap scrolling.
• Use artwork crops intentionally rather than shrinking desktop compositions.

Performance

Proposed project budgets to validate during implementation:

• meaningful static content visible without client-side JavaScript;
• initial compressed JavaScript target of roughly 150 KB or less for the public landing route;
• no wallet/web3 bundle on the initial route unless interaction requires it;
• responsive AVIF/WebP images with explicit dimensions;
• one or two locally hosted variable font files at most on the initial route;
• no autoplay background video in the critical path;
• reserve complex WebGL or collection tooling for separate routes or lazy-loaded modules;
• test on a mid-range Android profile and constrained network, not only desktop Lighthouse.

These are design constraints, not cleanup tasks for the end of development.

6. Technical observations

The common modern stack

Several of the most polished content-plus-application sites use a React/Next.js/Vercel model, often with a headless CMS:

• Doodles: Next.js/React, Vercel, Hygraph signal.
• Azuki: Next.js/React, Vercel, Contentful signal.
• PROOF/Moonbirds: Next.js, Vercel, Contentful, Apollo, Algolia signal.
• Art Blocks: Next.js/React/TypeScript/GraphQL/Vercel documented or detected.

This does not mean MoonCats should automatically use Next.js. Those sites support large editorial teams, commerce, search, identity, or frequently updated brand content. Their stack solves organizational needs that may not exist here.

Better selection criteria for the landing-page implementation

The implementation choice should follow the much narrower landing-page requirements rather than the architecture of the existing ChainStation applications.

For the stated goals, the implementation should bias toward:

• static generation or otherwise minimal client-side JavaScript;
• straightforward collaborative content editing;
• strong image optimization;
• simple deployment and local development;
• excellent accessible HTML before enhancement;
• ordinary links into existing ChainStation and ecosystem destinations rather than duplicating their application logic.

A framework is optional rather than a goal in itself. Astro, another static-site generator, or a very small conventional frontend are all plausible. React is only useful where a specific interactive element earns the added complexity.

7. Recommended first design principles

1. Explain before requiring. No wallet, terminology, or tool knowledge should be required to understand the first screen.
2. Lead with the artifact. MoonCats themselves, their origin, and their unusual technical life are more compelling than generic brand claims.
3. Organize the funnel around visitor intent. Existing backend/tool categories should inform destinations without dictating how newcomers first encounter them.
4. Make history actionable. Every historical section should connect to a cat, contract, tool, artifact, or deeper source.
5. Keep the weirdness local and intentional. Experimental details are more effective inside a stable, readable system.
6. Do not hide the machinery. Contracts, data, source code, and provenance are part of the aesthetic and trust model.
7. Progressively disclose depth. The MoonCats ecosystem can contain enormous detail without putting it all on the landing page.
8. Route to heavy applications instead of reproducing them. A visitor should not download or initialize ChainStation merely to learn what MoonCats are.
9. Treat mobile calls to action as navigation design. They should be deliberate, reachable, and task-specific.
10. Performance is part of the visual identity. A historical on-chain project should not feel dependent on a fragile multi-megabyte landing animation.

8. Anti-patterns observed across the survey

• Beautiful hero followed by no clear explanation.
• Wallet connection used as visual decoration.
• A top nav that exposes company departments rather than visitor goals.
• Social links hidden in the footer or represented by ambiguous icons.
• Collection, shop, token, game, lore, rewards, and community all given equal priority.
• JavaScript-only blank shells.
• Video, custom cursors, smooth-scroll libraries, and page transitions competing with basic navigation.
• “Lore” used where a timeline or sourced fact would be clearer.
• Mobile menus that merely reproduce a complicated desktop mega-menu.
• Corporate claims unsupported by project-specific evidence.
• Marketplace statistics becoming the main explanation of the artwork.
• Pixel aesthetics applied to controls, prose, and navigation until readability suffers.

9. Suggested next research artifacts

Before high-fidelity design, create the following:

A. Existing-content inventory

For every current MoonCatRescue/ChainStation destination, record:

• page purpose;
• intended audience;
• primary task;
• required wallet state;
• data dependency;
• current traffic or importance, where known;
• whether it is current, historical, experimental, duplicated, or deprecated.

B. Task and audience hypotheses

Start with hypotheses, then validate them rather than treating them as facts:

• first-time visitor trying to understand why MoonCats matter;
• collector trying to find, compare, or acquire a MoonCat;
• owner trying to use tools or understand a specific cat;
• community member looking for current activity and social destinations;
• builder looking for contracts, data, code, assets, or integration guidance;
• researcher looking for history, provenance, and primary sources.

C. Screenshot archive

Capture each useful reference at consistent sizes, at minimum:

• desktop around 1440 px wide;
• mobile around 390 px wide;
• open navigation;
• first viewport;
• one mid-page transition;
• footer;
• any important collection/tool interaction.

Annotate what is useful rather than collecting screenshots as mood-board decoration.

D. Performance baseline

Measure the current MoonCatRescue homepage and a few representative tools for:

• transferred bytes by type;
• initial JavaScript;
• largest images;
• render-blocking assets;
• mobile interaction issues;
• pages that require wallet or chain calls before displaying useful content.

E. Terminology map

List project terms a newcomer may not understand—rescue, adoption, acclimation, ChainStation, accessories, named cats, Genesis, rescue index, CatID, ENS, and others—and decide where each is introduced, explained, or deliberately left for deeper pages.

10. Suggested immediate workflow

1. Inventory the current MoonCatRescue/ChainStation pages and functions.
2. Turn that inventory into visitor tasks and candidate navigation groups.
3. Create two or three deliberately different low-fidelity landing/funnel structures.
4. Test those structures at mobile width before choosing visual styling.
5. Establish typography, spacing, color, image, and performance rules.
6. Build one landing-page prototype with real content—not placeholder marketing copy.
7. Verify that its calls to action route cleanly into the appropriate existing ChainStation and ecosystem destinations.
8. Use what is learned to decide whether additional audience-specific landing pages or funnels are worthwhile.

A useful first prototype should prove hierarchy, onboarding, routing, mobile behavior, and load speed. It does not need to reproduce ChainStation functionality or prove every art effect.

Sources and technical references

Primary review targets are listed in [survey.md](./survey.md). Technical stack evidence used for representative sites:

• BuiltWith technology profile for Doodles: https://builtwith.com/doodles.app
• Datafragment technology profile for Azuki: https://www.datafragment.com/technology-lookup/azuki.com
• Datafragment technology profile for PROOF: https://www.datafragment.com/technology-lookup/proof.xyz
• Datafragment technology profile for Art Blocks: https://www.datafragment.com/technology-lookup/artblocks.io
• Art Blocks public engineering stack references Next.js, React, Node.js, TypeScript, GraphQL, Vercel, and web3 tooling.

Framework signals should be verified again immediately before implementation because sites and deployments change.