Explain LOVE20 core protocol mechanics and map them to the core contracts and whitepaper. Use when asked about fair launch, parent and child token rules, SL and ST staking, SL 解锁期 or unlock period, 申请解锁, 取回质押资产, governance rounds, action submission, voting, joining, random verification, reward minting, or how LOVE20 rules are implemented on-chain.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Explain LOVE20 core protocol mechanics and map them to the core contracts and whitepaper. Use when asked about fair launch, parent and child token rules, SL and ST staking, SL 解锁期 or unlock period, 申请解锁, 取回质押资产, governance rounds, action submission, voting, joining, random verification, reward minting, or how LOVE20 rules are implemented on-chain.
LOVE20 Core Protocol
Use this skill to explain LOVE20 as a state machine backed by focused core contracts.
If local checkout names differ, map local aliases to these canonical names before following any path.
Workflow
Read references/protocol-overview.md.
Read references/governance-lifecycle.md when the question spans multiple phases or rounds.
Read references/core-contract-map.md to map concepts to files and interfaces.
Read references/core-data-structures.md when structs, return shapes, or storage-facing payloads matter.
Read references/generated-interface-index.md when you need a refreshed function inventory.
Open only the interfaces and implementations needed for the answer.
Mandatory Triage
Before explaining a mechanism, answer these questions explicitly in your head:
Is this base LOVE20 behavior, or does extension or group logic change it?
If the user says only action or 行动, treat it as potentially base, extension-backed, or group-backed until narrowed.
Does "round" mean the whitepaper business round, or currentRound() on a specific contract?
Is the user asking for design intent, implemented behavior, or both?
Which contract actually owns the rule being described?
Does the answer need current-state eligibility, or only abstract mechanics?
Is the user using whitepaper terms such as 解锁期, 申请解锁, or 取回质押资产 that must be translated into LOVE20Stake parameters or exit steps?
If the topic is concrete interaction rather than mechanism, switch to love20-contract-playbooks.
Working Rules
Start from the whitepaper semantics in docs/whitepaper/LOVE20协议设计.md, then verify against core/src/interfaces.
Treat unqualified action or 行动 as extension-aware by default. Narrow to base-only action semantics only when the user explicitly scopes to core/base behavior or the cited contract surface proves it.
Translate whitepaper staking terms into on-chain stake vocabulary when relevant:
解锁期 -> promisedWaitingPhases
申请解锁 -> unstake
取回质押资产 -> withdraw
When extension-backed or chain-group-backed behavior matters, prioritize the deployed-contract repos extension, extension-lp, extension-group, and group over adapters.
Separate launch-time behavior from governance-time behavior.
Map every user-visible action to a contract: Launch, Stake, Submit, Vote, Join, Random, Verify, Mint, Token, TokenFactory.
Mention contract dependencies when they matter. Verify depends on Join, Vote, and Random; Mint depends on Vote, Verify, and Stake.
Prefer interface files for public surface area and implementation files for edge cases or state transitions.
Guardrails
Treat Phase.currentRound() as a contract-local timing primitive. Always name the contract whose round you mean.
Treat deployment originBlocks offsets as part of the timing backbone. Submit and vote, join and random, and verify do not share the same origin block.
Do not explain SL staking or unlock eligibility with whitepaper language alone. Name the on-chain waiting-period parameter, the delayed exit stages, and the receipt-token balance caveat when they matter.
Treat LOVE20TokenFactory and LOVE20Launch as the token tree entry point.
Treat LOVE20Token, LOVE20SLToken, and LOVE20STToken as asset primitives, not governance flow contracts.
Call out when a constant is documented in the whitepaper but not exposed by the interface you are citing.
Response Contract
When answering, prefer this order:
Scope sentence: base-only or extension-aware.
Round sentence: business round or contract-local round on which contract.
Rule owner: name the contract or interface that enforces the behavior.
Dependency sentence: note any dependent contracts such as Vote, Join, Random, Verify, or Mint.
Exception sentence: mention extension or group exceptions when they materially change the base rule.
