Skip to main content
This is the canonical semantic icon map for Livepeer docs. Use it to make consistent icon choices across cards, tabs, accordions, and navigation surfaces. When in doubt, check the page-type defaults table first.
The rendered page is backed by /snippets/data/reference-maps/icon-map.jsx so the same mapping feeds validators, authoring helpers, and audit scripts — it does not live only in this MDX file.To check compliance: node operations/scripts/audits/content/reference/audit-icon-usage.js --md --verbose

​
Scope

  • Scan scope:
  • Exclusions:
  • Updated:
  • Coverage: 78 icons mapped out of 365 unique icons in the corpus. All icons with 10+ occurrences are mapped.

​
Page-Type Canonical Defaults

When a component icon (Card, Accordion, Tab) is linking to a page and no specific semantic icon fits the destination, use the default for the page type being linked to.

​
Section Jump

​
Review Queue

These are the icons that look most overloaded or ambiguous in the current docs set.

​
Inline Review Notes

​
wand-magic-sparkles

  • Decision: keep wand-magic-sparkles for AI entry surfaces only. Good fits are Build an AI product in v2/gateways/navigator.mdx and ComfyStream in v2/gateways/guides/node-pipelines/guide.mdx.
  • Products and named solutions should not inherit wand-magic-sparkles by default: pages such as What is Daydream? in v2/solutions/daydream/overview.mdx and Transcode in v2/solutions/livepeer-studio/docs/reference/overview.mdx should use a product icon or brand icon instead.
  • Quickstarts should use bolt, not wand-magic-sparkles or rocket: this should become the default quickstart cue across portal and setup-entry surfaces.
  • Badges need their own icon map: the current Developer Level Up badge on Run a Gateway in v2/gateways/portal.mdx and Run an Orchestrator in v2/orchestrators/portal.mdx should move to a badge-specific set. Candidate icons: gamepad, trophy, or medal. Follow-up: fold badge semantics into this icon map rather than creating a separate disconnected reference.
  • Managed or hosted platforms should use a consistent platform icon: Managed Platform in v2/gateways/guides/deployment-details/setup-options.mdx should converge on cloud as the default unless the platform has its own product icon.
  • Tutorials, guides, and references should use page-type icons instead: for example, Building Real-Time AI Video Effects with ComfyStream in v2/developers/guides/developer-guides.mdx should resolve through tutorial or guide defaults rather than the AI-entry icon.

​
book

  • Decision: keep book for generic non-technical guides and concept pages. Good fits are Contribution Guide in v2/developers/get-started/contributor-quickstart.mdx and concept-oriented reading surfaces where the destination is primarily explanatory.
  • References, tutorials, and resources should not default to book: Orchestrator References in v2/orchestrators/portal.mdx and Orchestrator Offerings Reference in v2/gateways/guides/advanced-operations/production-hardening.mdx should align to the resources/reference icon family instead. Tutorials should have their own default icon, likely circle-play.
  • External docs should use a product icon first, then an external-doc fallback: Daydream docs in v2/solutions/daydream/overview.mdx, ComfyStream documentation in v2/developers/get-started/comfystream-quickstart.mdx, and Frameworks docs in v2/solutions/frameworks/overview.mdx should use a product icon where available, otherwise a generic external-link cue such as up-right-from-square.
  • Technical guides should use a technical-guide icon, not book: items like Python SDK Quickstart (Official Docs) in v2/developers/guides/developer-guides.mdx should likely move to laptop-file or the agreed technical-guide default.
  • GitHub destinations should always use github: Documentation and Livepeer Docs in v2/developers/guides/contribution-guide.mdx are GitHub links and should be branded as such, not rendered as generic books.

​
server

  • Gateway or node deployment paths: used when the reader is choosing a self-hosted path. Examples: Set Up a Gateway in v2/developers/concepts/running-a-gateway.mdx and Solo orchestrator (go-livepeer) in v2/orchestrators/guides/setup-paths/find-your-path.mdx.
  • Direct infrastructure configuration: used when the page is about explicit node-to-node or self-managed infrastructure setup.
  • Infra software and node-adjacent services: also used for software or infrastructure resources rather than operator roles. Examples: Livepeer Catalyst (MistServer) in v2/developers/resources/compendium/resources.mdx.
  • Provider personas and opportunities: used for role-routing and grant surfaces as well. Examples: Workload Provider in v2/developers/navigator.mdx and Earn from Idle GPU in v2/home/get-started.mdx.

​
bolt vs rocket

  • bolt is the canonical quickstart icon. Use it for fast-path cards, get-started shortcuts, and setup-entry choices labelled as quickstart or fast. Replaces the previous ambiguity between bolt and rocket.
  • rocket is the portal/launch icon. Keep it for top-level portal pages (v2/developers/portal.mdx, v2/orchestrators/portal.mdx) where the metaphor is launch rather than speed.
  • Do not mix them. A card linking to a quickstart page uses bolt. A card that is the portal entry point uses rocket.

​
tools

  • Tooling or quickstart hubs: used when the destination is positioned as a tooling collection or jump-off page.
  • Distinguish from gear (single settings/config), gears (multi-part advanced config), and wrench (troubleshooting).

​
coins

  • Staking, rewards, and earnings: used when the topic is protocol economics or operator returns.
  • Gateway funding and payment steps: also used when the action is specifically about ETH funding or payment setup.
  • Distinguish from hand-holding-dollar (grants, subsidies, external financial support) and wallet (balance/payout state).
  • On-chain mode labels: used when the icon stands in for the on-chain operational mode itself.
  • Discovery, routing, and connection flows: used when the page is specifically about connecting to the network or discovering orchestrators.
  • RPC and endpoint references: used for endpoint or connection resource links.
  • Prefer arrow-up-right for generic external destinations — link should signal connection or routing, not “this opens in a new tab”.

​
Data Location

The mapping lives in /snippets/data/reference-maps/icon-map.jsx. That is deliberate:
  • the page can render a reusable data source
  • future validators can consume the same map without copying MDX tables
  • more reference maps can sit beside it under snippets/data/reference-maps/

​
Audit Tooling

Run the icon usage audit to check how well the current docs comply with this map: 
node operations/scripts/audits/content/reference/audit-icon-usage.js --md --verbose
Output: workspace/reports/_local/icon-usage-report.json (and .md with --md). The audit reports:
  • Total unique icon values in use
  • Which icons are mapped vs unmapped in this canonical map
  • Frequency and page coverage for each icon
After updating the map, regenerate the report to verify coverage improved. If a map is only narrative and will never be reused, inline MDX is fine. For reusable authoring/reference maps consumed by docs pages, snippets/data/reference-maps/ is the better home. tools/config/ should stay reserved for governed runtime or script-facing config.
Last modified on April 7, 2026