Crypto Frontend Design Skill

This skill is a CSS-first directive. It produces the visual layer for crypto and web3 frontends: stylesheets, layout systems, animation, theming, responsive behavior, and the semantic HTML structure that carries them. The JavaScript and TypeScript logic layer (wallet connections, contract calls, state management, API integration) lives outside this skill's scope. When the project runs on OPNet, the opnet-development skill governs all logic, and this skill governs all visuals.

Every output must look like it was designed by a funded startup's design team, not generated by AI. The aesthetic is intentional, the code is production-grade, and the responsive behavior is flawless.

Companion Skill: opnet-development

When the frontend is for an OPNet project (any Bitcoin L1 smart contract dApp, OP20 token site, OP721 NFT gallery, DEX interface, staking platform, airdrop claim page, or OPNet ecosystem tool), both skills must be active. The division of responsibility is strict.

This skill (crypto-frontend-design) owns: CSS custom properties, theme system, responsive breakpoints, animations, keyframes, layout grids, typography, color palettes, component visual styling, backgrounds, hover/focus/active/disabled states, the CSS reset, and all HTML structure including semantic elements and ARIA attributes.

opnet-development owns: React component logic, TypeScript interfaces and types, wallet connection via @btc-vision/walletconnect, provider setup via JSONRpcProvider, contract instantiation and simulation, transaction building, state management, caching patterns, and all business logic. The opnet-development skill has mandatory reading requirements (TypeScript Law, setup guidelines, frontend guidelines, provider docs, contract docs, WalletConnect docs, Motoswap reference implementation) that must be followed before writing any logic code.

When generating a complete OPNet frontend page, produce the CSS and HTML structure from this skill first, then hand off to opnet-development patterns for the React/TypeScript layer. The visual layer never imports from @btc-vision/* packages directly; it only provides the styled containers, class names, and CSS variables that the logic layer renders into.

Pre-Flight: Gather Context Before Writing Any CSS

Before generating any stylesheet or markup, ask the user for context. Do not skip this. Present these as direct conversational questions, not a numbered checklist or formatted list.

What to ask:

What type of page or component is this? Possible answers include dashboard, landing page, airdrop claim, staking interface, token launch, portfolio tracker, DEX, bridge UI, NFT gallery, or something else.

Does the user have background images, a logo, or brand assets? If they have images, those drive the atmosphere layer. If not, the skill generates the atmosphere from scratch using gradients, textures, and effects.

What theme or vibe does the user want? Offer concrete options: matrix/terminal green-on-black, cyberpunk neon, clean fintech, dark luxury, brutalist crypto, vapor-gradient, military/ops tactical, glassmorphism, or a custom direction. If the user says something vague like "make it look sick" or "hacker vibes," map that to the closest theme and confirm.

Who is the target audience? Degens, institutional investors, general public, or developers each demand different density, copy style, and visual weight.

Does the user want multiple theme support, such as a dark/light toggle or multiple named themes?

What framework constraints exist? Plain HTML/CSS/JS, React/JSX, Tailwind utility classes, or something else? This skill defaults to plain CSS with semantic HTML unless told otherwise.

Does the project have existing brand colors, fonts, or a style guide? If the user provides brand colors, those override the theme palette defaults.

If the user provides enough context upfront (like "matrix-themed airdrop page for OPNet"), infer reasonable defaults for anything not stated and confirm the direction in one short paragraph before writing code.

Landing Page Architecture

AI-generated landing pages fail because they produce flat, structureless walls of content with no visual rhythm, no spatial hierarchy, and no conversion logic. This section exists to fix that. Every landing page generated by this skill must follow a section-based architecture with intentional visual flow.

Section Structure

A crypto landing page is a sequence of full-width sections, each with a distinct visual treatment and a single communication job. The sections scroll vertically and alternate visual weight to create rhythm.

Hero Section (above the fold): This is the single most important section. It must contain: a headline (short, punchy, no more than 8 words), a subheadline (one sentence explaining the value proposition), a primary CTA button, and optionally a secondary CTA or a visual element (3D render, animated graphic, token icon, or background video). The hero occupies 100vh minimum on desktop, uses the largest type scale, and anchors the entire page's visual identity. The background treatment here sets the mood for everything below.

.hero {
  position: relative;
  min-height: 100vh;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  text-align: center;
  padding: var(--space-2xl) var(--space-lg);
  overflow: hidden;
}

.hero__headline {
  font-family: var(--font-display);
  font-size: var(--font-size-hero);
  font-weight: 800;
  line-height: var(--line-height-tight);
  color: var(--text-primary);
  max-width: 14ch;
  margin-bottom: var(--space-md);
}

.hero__sub {
  font-family: var(--font-body);
  font-size: var(--font-size-lg);
  color: var(--text-secondary);
  max-width: 50ch;
  margin-bottom: var(--space-xl);
}

Social Proof / Stats Bar: Immediately after the hero, show hard numbers: TVL, users, transactions processed, uptime, or partner logos. This section is visually compact (no taller than 120px on desktop), uses a horizontal flex/grid layout, and grounds the hero's claims in data.

.stats-bar {
  display: flex;
  justify-content: center;
  gap: var(--space-2xl);
  padding: var(--space-xl) var(--space-lg);
  border-top: 1px solid var(--border-subtle);
  border-bottom: 1px solid var(--border-subtle);
  background: var(--surface-raised);
}

.stats-bar__item {
  text-align: center;
}

.stats-bar__value {
  font-family: var(--font-display);
  font-size: var(--font-size-2xl);
  font-weight: 700;
  color: var(--text-accent);
  font-variant-numeric: tabular-nums;
  display: block;
}

.stats-bar__label {
  font-size: var(--font-size-sm);
  color: var(--text-muted);
  text-transform: uppercase;
  letter-spacing: 0.08em;
}

Feature Cards Section: Three to four cards explaining core features or value props. Use CSS Grid with auto-fit columns. Each card has an icon or small visual, a heading, and two to three sentences of description. Cards use the raised surface color, subtle border, and the card-lift hover animation.

How It Works / Process Section: Three to five steps with numbered indicators or a horizontal timeline. This section uses a different background treatment (slightly lighter or with a texture overlay) to break the visual monotony.

Tokenomics or Technical Section (if applicable): Charts, allocation breakdowns, or architecture diagrams. Use data visualization patterns from references/components.md. This section often benefits from a grid-dot background texture.

CTA Section: A full-width section with a strong background treatment (gradient, accent color wash, or image overlay), a compelling headline, and a large CTA button. This is the conversion anchor for users who scrolled past everything.

Footer: Links, social icons (SVG, never font icons), legal disclaimers, and optionally a newsletter signup. Compact, muted colors, clear hierarchy.

Visual Rhythm Rules

Adjacent sections must not share the same background color. Alternate between --surface-base, --surface-raised, and sections with texture or gradient overlays. This creates visual "breathing room" and prevents the page from feeling like a single flat slab.

Every section transition should have subtle separation: a 1px border, a gradient fade, or a change in background treatment. Hard cuts between identical-looking sections make the page feel cheap.

Odd sections (1st, 3rd, 5th) lean toward the primary background. Even sections (2nd, 4th, 6th) lean toward the raised or overlay background. This alternation is the single most effective technique for making a landing page feel designed rather than generated.

Section Entry Animations

Each section's content animates in when it enters the viewport. Use Intersection Observer to add an .is-visible class, then trigger CSS animations. Do not animate all sections at page load; stagger them on scroll.

.section-content {
  opacity: 0;
  transform: translateY(30px);
  transition: opacity 0.6s cubic-bezier(0.22, 1, 0.36, 1),
              transform 0.6s cubic-bezier(0.22, 1, 0.36, 1);
}

.section-content.is-visible {
  opacity: 1;
  transform: translateY(0);
}

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('is-visible');
    }
  });
}, { threshold: 0.15 });

document.querySelectorAll('.section-content').forEach(el => observer.observe(el));

Graphic and Visual Element Rules

AI fails at landing page graphics because it either produces nothing (bare text on a background) or produces meaningless decorative blobs. Every visual element must have a reason to exist.

Acceptable visual elements for crypto landing pages: geometric grid/dot patterns as background texture, gradient mesh orbs positioned behind content for depth, animated particle fields (canvas-based, sparse, matching accent color), architectural line drawings suggesting network topology, token/coin iconography (simple SVG, not 3D renders unless the user provides them), code-styled text blocks showing contract snippets or transaction data as visual elements, chart or graph shapes used decoratively in backgrounds, and subtle scan-line or noise overlays for atmosphere.

Unacceptable visual elements: stock photos of people pointing at screens, generic blockchain cube/chain illustrations, cartoon mascots, clip art, emojis, decorative borders that serve no layout purpose, and gradient blobs that float aimlessly without anchoring content.

For orb/glow effects behind content, use absolutely positioned pseudo-elements with radial gradients and blur:

.hero::before {
  content: '';
  position: absolute;
  top: -20%;
  left: -10%;
  width: 60%;
  height: 60%;
  background: radial-gradient(circle, var(--accent-glow) 0%, transparent 70%);
  filter: blur(80px);
  z-index: 0;
  pointer-events: none;
}

.hero::after {
  content: '';
  position: absolute;
  bottom: -15%;
  right: -5%;
  width: 50%;
  height: 50%;
  background: radial-gradient(circle, rgba(0, 136, 255, 0.08) 0%, transparent 70%);
  filter: blur(80px);
  z-index: 0;
  pointer-events: none;
}

.hero > * {
  position: relative;
  z-index: 1;
}

Default Typography

The default body font for all outputs is Poppins. Unless the user specifies a different font or the chosen theme demands a different stack (like monospace for matrix/terminal), Poppins is the base.

@import url('https://fonts.googleapis.com/css2?family=Poppins:wght@300;400;500;600;700;800&display=swap');

:root {
  --font-body: 'Poppins', sans-serif;
  --font-display: 'Poppins', sans-serif;
}

For themes that pair Poppins with a different display font, override --font-display only. Poppins stays as --font-body unless the user provides a brand font or the theme is specifically monospace-heavy (matrix, terminal).

See references/typography.md for alternative display font pairings per theme when a second display font is needed alongside Poppins.

Design Philosophy

Every crypto frontend communicates three things: legitimacy, technical competence, and energy. Users pattern-match against scam sites constantly, so the design must signal "this team ships real product" through polish, consistency, and attention to detail.

Depth over flatness. Use layered shadows, subtle gradients, glassmorphism, or parallax to create spatial hierarchy. Flat designs look cheap in this space.

Motion with purpose. Every animation communicates state change, draws attention to a CTA, or reinforces the theme. No gratuitous bouncing. Loading states, number tickers, progress bars, and hover reveals are where animation earns its keep.

Typography as identity. The font stack is the single biggest differentiator between "looks professional" and "looks like a template." See references/typography.md for curated pairings by theme.

Color discipline. Pick a dominant, an accent, and a neutral. The accent color appears on CTAs, active states, and key data points only. Everything else stays muted. See references/color-systems.md for theme-specific palettes.

No decorative clutter. No emojis, no confetti, no cartoon illustrations. Geometric patterns, data visualizations, grid lines, and subtle particle effects are acceptable ornamentation. Everything else is noise.

Theme Architecture

Every output uses CSS custom properties for theming. Non-negotiable.

:root {
  --surface-base: #0a0a0f;
  --surface-raised: #12121a;
  --surface-overlay: #1a1a25;
  --surface-interactive: #22222f;
  --text-primary: #e8e8ed;
  --text-secondary: #8888a0;
  --text-muted: #555568;
  --text-accent: #00ff88;
  --accent-primary: #00ff88;
  --accent-secondary: #0088ff;
  --accent-glow: rgba(0, 255, 136, 0.15);
  --border-subtle: rgba(255, 255, 255, 0.06);
  --border-interactive: rgba(255, 255, 255, 0.12);
  --color-success: #00ff88;
  --color-warning: #ffaa00;
  --color-error: #ff3355;
  --color-info: #0088ff;
  --space-xs: 4px; --space-sm: 8px; --space-md: 16px;
  --space-lg: 24px; --space-xl: 32px; --space-2xl: 48px; --space-3xl: 64px;
  --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px;
  --radius-xl: 16px; --radius-full: 9999px;
  --shadow-sm: 0 1px 2px rgba(0, 0, 0, 0.3);
  --shadow-md: 0 4px 12px rgba(0, 0, 0, 0.4);
  --shadow-lg: 0 8px 32px rgba(0, 0, 0, 0.5);
  --shadow-glow: 0 0 20px var(--accent-glow);
  --transition-fast: 150ms cubic-bezier(0.4, 0, 0.2, 1);
  --transition-base: 250ms cubic-bezier(0.4, 0, 0.2, 1);
  --transition-slow: 400ms cubic-bezier(0.4, 0, 0.2, 1);
}

For multiple themes, use [data-theme] attribute selectors overriding these properties. See references/theme-presets.md for complete override sets and toggle implementation. See references/color-systems.md for full palettes per theme.

Responsive Architecture

Mobile-first, min-width queries.

/* Mobile base: 0 - 767px */
@media (min-width: 768px) { /* Tablet */ }
@media (min-width: 1024px) { /* Desktop */ }
@media (min-width: 1440px) { /* Wide */ }

Mobile: nav collapses to hamburger or bottom bar, grids go single-column, tables become card layouts or scroll horizontally with fade hint, body text never below 14px, touch targets 44x44px minimum.

Tablet: two-column grids, sidebars collapse to drawers, padding tighter than desktop.

Desktop: full grid dashboards, multi-column, sidebar nav, hover states, tooltips on hover.

Fluid typography via clamp(): font-size: clamp(1rem, 0.9rem + 0.5vw, 1.25rem);

CSS Grid for dashboard layouts. Flexbox for component-level alignment. Never floats.

Animation Standards

See references/animations.md for the full keyframe library.

Page load: Stagger entry with animation-delay. Hero at 0ms, secondary 100-300ms, tertiary 400-600ms. Use opacity and transform: translateY(). Never animate layout properties.

Hover/interaction: All interactive elements need hover states. Cards: translateY(-2px) plus shadow increase. Buttons: background shift, subtle scale. Links: color transition.

Data: Number counters via requestAnimationFrame or CSS @property. Progress bars fill with eased transition. Chart points stagger in.

Ambient: Theme-reinforcing background effects. Matrix: falling characters. Cyberpunk: scanlines, flicker. Fintech: slow gradient drift. GPU-composited only (transform, opacity). Always respect prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Component Patterns

See references/components.md for full markup and CSS for: wallet connect button, token balance display, transaction table, price ticker, staking card, airdrop claim card, countdown timer, progress bar, network status indicator, gas fee display, address with copy button, and chart containers.

Every component uses custom properties (never hardcoded colors), is fully responsive, and has hover, focus, active, and disabled states.

Background and Atmosphere

Never use a plain solid color as sole background unless the user requests brutalist minimalism.

Layered backgrounds:

body {
  background-color: var(--surface-base);
  background-image:
    radial-gradient(ellipse at 20% 50%, rgba(0, 255, 136, 0.03) 0%, transparent 50%),
    radial-gradient(ellipse at 80% 20%, rgba(0, 136, 255, 0.03) 0%, transparent 50%),
    linear-gradient(180deg, var(--surface-base) 0%, var(--surface-raised) 100%);
  background-attachment: fixed;
}

User-provided background images get dark overlays: background: linear-gradient(rgba(0,0,0,0.7), rgba(0,0,0,0.85)), url(...).

Grid/dot texture: see the .grid-texture pattern in references/animations.md.

CSS Reset

Include the reset from assets/crypto-reset.css at the top of every generated stylesheet. It handles box-sizing, font smoothing, scrollbar styling, focus-visible outlines, selection colors, and base body setup using the custom property system.

Code Quality

Semantic HTML: <header>, <nav>, <main>, <section>, <article>, <aside>, <footer>. ARIA labels on interactive elements lacking visible text.

CSS uses custom properties for all theme-variable values. Class names follow BEM or utility patterns, never .box or .container1.

Vanilla JavaScript ES2020+ for DOM interaction unless user specifies a framework. addEventListener over inline handlers. Cached DOM queries.

For React outputs, functional components with hooks, TypeScript interfaces for props when working alongside opnet-development. The CSS produced by this skill is consumed by the React components defined by opnet-development patterns.

Hard Rules

Never use emojis anywhere in the UI. Not in headings, buttons, status messages, placeholders, or anywhere else.

Never use the generic purple-to-blue AI gradient. Never use unstyled default browser form controls. Never use !important except in the prefers-reduced-motion override.

Never clone an existing known template (Uniswap, generic Bootstrap dashboard). Every output has its own visual identity.

Never use Comic Sans, Papyrus, or more than three font families per page. Never use Lorem ipsum; use realistic crypto placeholder content (token names, wallet addresses, transaction hashes, TVL, APY percentages).

Never produce a landing page that is a flat wall of text with no visual rhythm. Follow the section architecture defined above. Every landing page must have alternating section backgrounds, scroll-triggered entry animations, and at least one atmospheric visual element (glow orb, grid texture, gradient mesh, or particle effect).

Never produce CSS that only works on desktop. Every single class must be tested mentally against the three breakpoints before being written. If a layout uses display: grid with fixed column counts, it must have responsive overrides.