Lick Protocol Litepaper

Version 0.3 - Token Launch Update
September 2026

Inscriptions, participation records, and the live $LICK market layer on Robinhood Chain.

This litepaper documents the current public beta, the live $LICK token, the design direction of the inscription system, and the principles that govern LICK ID, XP, LICK Score, referrals, and streaks. Live behavior and planned architecture are labeled separately throughout the document.

1. Executive summary

Lick Protocol starts with a simple cultural reference: the 2016 dog lens that became one of the most recognizable selfie formats of the era. The project uses that reference as a distribution hook, but the product being built is a participation and inscription system on Robinhood Chain.

The public beta already provides a LICK ID, a locally generated EVM wallet, XP, verified task history, qualified referrals, daily streaks, a beta LICK Score, and a shareable LICK ID card. The next technical layer is a Robinhood Chain inscription system that can turn selected verified milestones into permanent onchain receipts.

The system deliberately separates four concepts:

• LICK ID - the account and participation record.
• XP - a non-transferable measure of verified participation used to inform access.
• LICK Score - a beta composite signal summarizing the strength of the account record.
• LICK inscriptions - planned immutable onchain receipts for selected milestones.

$LICK is live on Robinhood Chain as the transferable market layer around the product. Token balance does not purchase or substitute for LICK Score. The official contract address is 0x7B81059EA0123B7D8213490d1f970744ec48CA8f.

The live launch market is $LICK / $SNAP on Pons. The official token contract is 0x7B81059EA0123B7D8213490d1f970744ec48CA8f. Broader token utility, protocol fee integrations, and any additional market structure remain subject to future implementation and disclosure.

2. Why this exists

2.1 From temporary media to durable records

The original dog lens was designed for a disappearing-media era. Its value came from participation: people recognized the format, recreated it, sent it, and repeated it. A decade later, the same cultural object is recognizable enough that Snap reported a renewed 2016 nostalgia cycle in 2026, including a 352% increase in searches for the Dog Lens.

Lick Protocol explores a different question: what if meaningful participation around an internet-native cultural object could leave a durable, verifiable receipt?

That is the role of inscriptions in LICK. The protocol is not designed to put every click, page view, or social action onchain. It is designed to select meaningful milestones, verify them, and make a subset of them permanently referenceable.

2.2 The design problem

Open reward systems are easy to farm. Pure points systems are easy to ignore. Pure token-gated systems let capital substitute for contribution. Pure onchain systems often make users pay before they understand why they should care.

LICK separates the system into layers so each layer has one job:

1. Identity - establish a persistent LICK ID.
2. Participation - record actions and verified activity.
3. Access - use XP and account history to determine what a user may unlock.
4. Reputation signal - summarize record strength with LICK Score.
5. Permanence - inscribe selected milestones on Robinhood Chain.
6. Market - add $LICK as the transferable economic layer without making token balance equal reputation.

3. Current product status

The project uses explicit status labels because planned functionality should not be presented as shipped functionality.

4. System architecture

LICK is designed as a layered system rather than a single smart contract.

4.1 Client layer

The current beta is a static web application. It handles onboarding, LICK ID creation, profile display, task submission, referral routes, streak views, and card generation.

4.2 Identity and session layer

The beta uses an anonymous application session and creates a dedicated EVM wallet locally in the user’s browser. The public address can be attached to the LICK ID. Private key material is not intended to be sent to the project database.

This remains a beta convenience model, not a recommendation to store significant assets in the generated wallet. v0.2 introduced optional account recovery by linking a verified email and an encrypted wallet-backup file protected by a user-chosen passphrase. Account recovery and wallet-key recovery are deliberately separate: the email recovers the application account, while the encrypted backup restores the local signing key on a new device.

4.3 Application data layer

Current offchain state includes:

• profile metadata;
• XP balance;
• task submissions and verification state;
• referral relationships and qualification state;
• current and longest streak;
• daily streak activity;
• beta LICK Score inputs.

Row-level access controls separate each user’s readable account data. XP, task approval, referral qualification, streak writes, card claims, and LICK Score authority are server-controlled. The public client can read its own state but cannot directly grant XP, approve tasks, or write score state.

4.4 Verification layer

Task completion is not awarded solely because a user clicked an external button. Submissions enter verification states and XP is awarded only after the backend accepts the proof.

Referrals use a similar principle. A referred account begins as pending. It becomes qualified only after the system observes activity that satisfies the active qualification policy. Qualification rules can evolve to reduce farming and Sybil behavior.

4.5 Onchain layer

Robinhood Chain is the intended settlement layer for LICK inscriptions. Robinhood describes the network as a permissionless, Ethereum-compatible Layer-2 built on Arbitrum Dedicated Blockchains. It uses chain ID 4663 and ETH as the native gas token.

The onchain module is not live in this litepaper version. Before public minting opens, LICK will publish the final contract addresses, record format, event schema, and verification/indexing method.

5. LICK ID

A LICK ID is the canonical account record inside the LICK application.

It is designed to answer three questions:

1. Which account performed the activity?
2. Which verified actions belong to that account?
3. Which onchain inscriptions should later resolve back to the same history?

A LICK ID currently connects an X handle, a local EVM address, account progress, referrals, streaks, tasks, and LICK Score.

The ID is not an NFT, a transferable username, or a financial asset in the current beta. Transferability would weaken the meaning of account history because a purchased identity would inherit another participant’s record.

6. XP: participation and access

XP is a non-transferable application primitive.

Its purpose is to track verified participation and provide one input into future access decisions. It is not a token and has no redemption value.

Current beta activities can award XP after verification. Exact task weights, future categories, and access thresholds can change as abuse patterns and product usage become clearer.

6.1 What XP is for

• measuring verified participation;
• creating progression without requiring token ownership;
• informing inscription mint eligibility;
• helping separate long-term participants from fresh accounts;
• supporting future access tiers without publishing easily farmed rules too early.

6.2 What XP is not

• a transferable asset;
• a monetary balance;
• an airdrop entitlement;
• inscription access by itself;
• a substitute for verification quality.

7. Referrals and streaks

7.1 Referrals

Every LICK ID can receive a referral code and a dedicated /r/CODE link.

Referral state is split into:

• Invited - an account was created through the referral relationship.
• Pending - the account has not yet satisfied the active qualification policy.
• Qualified - the referred account satisfied the active qualification policy and can count as a stronger record signal.

Only qualified referrals are intended to strengthen LICK Score. This makes referral quality more important than raw signup quantity.

Anti-abuse controls can include verification history, account age, repeat activity, device/network heuristics, rate limits, and other Sybil-resistance signals. Not every anti-abuse rule will be publicly enumerated because a fully disclosed rule set becomes easier to farm.

7.2 Streaks

Streaks borrow the simple behavioral idea of returning on consecutive days. During beta, streaks use UTC calendar days and one signed-in visit can keep the day active.

Streaks are a continuity signal, not a financial reward mechanism. A long streak can contribute to record quality, but it should not overpower verified activity or allow empty daily visits to dominate LICK Score.

8. LICK Score

LICK Score is a server-computed beta composite signal. The browser displays the result returned by an authenticated backend function rather than calculating an authoritative score locally.

Formula v1 uses verified task completion, streak continuity, and qualified referrals. Those input categories are public; exact weights and anti-abuse thresholds are not published. Formula versions are explicit so weights can evolve without silently changing what an older score meant. Future versions may include inscription history and other onchain signals.

The score is intentionally separate from XP:

• XP asks: how much verified participation has this account accumulated?
• LICK Score asks: how strong is the record behind the account?

8.1 Design principles

• Token holdings should not directly buy reputation.
• Raw referral volume should not equal quality.
• Verified actions should carry more weight than unverified clicks.
• Score weights should be versioned and changeable as abuse patterns emerge.
• Historical score snapshots may be included in inscriptions, but the live score should remain updateable.

8.2 Interpretation limits

LICK Score is not a credit score, identity proof, universal trust score, investment rating, or statement about a person’s character. It is an application-specific summary of activity inside Lick Protocol and can be incomplete or manipulated despite anti-abuse controls.

Users should not rely on LICK Score alone for financial, identity, employment, lending, or other high-stakes decisions.

9. LICK inscriptions

Inscriptions are the core onchain product direction.

9.1 What LICK means by an inscription

Bitcoin Ordinals inscribe content onto individual satoshis and give those inscriptions identifiers and provenance. LICK uses the word “inscription” in a different, application-specific EVM context.

A LICK inscription is intended to be an immutable Robinhood Chain record that references a verified LICK milestone and can be independently indexed from onchain data.

LICK inscriptions are not Bitcoin Ordinals, BRC-20 tokens, or claims that Robinhood Chain provides native Ordinals semantics.

9.2 What should be inscribed

The protocol should not inscribe every interaction. Candidate inscription classes include:

• genesis / early LICK ID milestones;
• verified cultural receipts;
• significant account achievements;
• inscription mint history;
• future drop participation;
• other protocol-defined milestones that benefit from permanence.

9.3 Proposed record schema (format v1)

The final schema is not yet deployed. A minimal inscription record may contain fields conceptually similar to:

{
  "p": "lick",
  "v": 1,
  "type": "receipt",
  "kind": "genesis_id",
  "lick_id": "<canonical-id>",
  "subject": "0x...",
  "evidence_hash": "0x...",
  "score_snapshot": "<server-score>",
  "parent": null,
  "timestamp": 1789280000
}

The placeholders above are illustrative and do not reveal live ID counts, score thresholds, or access criteria. Field types and encoding remain subject to the final schema.

evidence_hash is intended to commit to the evidence or protocol state that justified a receipt without placing raw evidence onchain. The exact preimage set, canonicalization method, hash function, and any salting rules are TBA and will be published before inscription minting is enabled.

The production format may use calldata, contract storage, events, content hashes, or a combination of these. The invariant is more important than the encoding: a canonical record should be immutable, attributable, indexable, and independently verifiable from Robinhood Chain.

9.4 Record lifecycle

A milestone can move through four logical states:

1. Candidate - an activity may be eligible for inscription.
2. Verified - supporting evidence or protocol state has been accepted.
3. Eligible - the account satisfies the active access policy.
4. Inscribed - the canonical onchain receipt has been created and indexed.

This separation allows the project to apply anti-spam review before users spend gas or create permanent state.

9.5 Provenance and history

Future inscription records may support parent-child relationships so a LICK ID can have a genesis record and later receipts can reference it. This creates a chronological history without requiring the live LICK Score itself to be immutable.

10. Access model

The inscription system is intended to use earned access rather than an unrestricted public mint from day one.

Access may consider:

• XP;
• LICK Score;
• verified task history;
• account age and continuity;
• qualified referral history;
• existing inscriptions;
• onchain behavior where relevant;
• anti-abuse and integrity checks.

Exact thresholds are intentionally not fixed in this litepaper. The beta is collecting enough information to set useful rules without turning the system into a checklist for bots.

Future access can include personal inscription minting, expanded inscription formats, and the ability for qualifying accounts to launch inscription drops. These capabilities remain planned until the relevant module and eligibility policy are live.

11. $LICK and the market layer

$LICK is live as the transferable market layer around Lick Protocol on Robinhood Chain.

The token is deliberately separate from LICK Score and XP:

• XP is non-transferable participation progress.
• LICK Score is an application-specific record signal.
• $LICK is a transferable token and market asset.

Holding or purchasing $LICK is not intended to directly purchase LICK Score.

11.1 Intended role

The token is live, while broader protocol utility is still being developed. Potential future utility surfaces include inscription-related fees or access mechanics, community incentives, and other functions tied to shipped product behavior. These functions should be treated as design direction until they are implemented.

11.2 $LICK / $SNAP market

The initial live market is $LICK / $SNAP on Pons. The pairing connects the project’s origin in Snap-era culture with Robinhood Chain’s Stock Token ecosystem.

The official $LICK contract is 0x7B81059EA0123B7D8213490d1f970744ec48CA8f. Users should verify this address rather than relying on token name or ticker alone. Future venues, liquidity routes, or additional pairs may differ from the initial Pons market and will be announced separately if introduced.

11.3 Tokenomics disclosure policy

The live launch establishes the official contract and initial market, but this litepaper does not invent allocation or utility details that have not been separately disclosed.

Public token disclosures should identify, as applicable:

• total supply;
• initial circulating supply;
• liquidity allocation;
• team / contributor allocation, if any;
• treasury allocation, if any;
• vesting and lockups;
• fee flows;
• mint / burn authority status;
• verified contract address;
• initial launch venue and live pair;
• pool address and liquidity details, where applicable.

The verified $LICK contract is 0x7B81059EA0123B7D8213490d1f970744ec48CA8f and the initial market is $LICK / $SNAP on Pons. Any conflicting contract address, allocation claim, or unofficial market should be treated as unverified unless confirmed through Lick Protocol’s official channels.

12. Why Robinhood Chain

Robinhood Chain is a permissionless, Ethereum-compatible Layer-2 built on Arbitrum Dedicated Blockchains for onchain financial infrastructure and tokenized real-world assets. The network uses chain ID 4663 and ETH for gas.

For LICK, the network offers three relevant properties:

1. EVM compatibility - standard Ethereum tooling can be used for contracts, indexing, wallets, and signatures.
2. Stock Token context - Robinhood Chain supports Stock Tokens as standard ERC-20 assets, which makes the live $LICK / $SNAP market technically relevant to the ecosystem.
3. Composable onchain state - inscription records can be indexed alongside token and application activity.

Lick Protocol is an independent project. Building on or referencing Robinhood Chain does not imply sponsorship, endorsement, certification, or partnership by Robinhood.

13. Security, integrity, and anti-abuse

A reputation-like system becomes useless if the easiest strategy is farming it.

The beta therefore follows several principles:

• XP should be awarded by backend-controlled verification, not client-side clicks.
• Raw referrals should not equal qualified referrals.
• A public X proof can be used only once across task types and accounts; the database unique constraint is the final backstop.
• Users cannot directly write their own XP or authoritative LICK Score state.
• Sensitive service-role credentials must never be shipped to the browser.
• Local wallet private keys should not be transmitted to the project database.
• Inscription eligibility should be computed from server and onchain state, not user-supplied flags.
• New anonymous account creation in the production deployment requires Cloudflare Turnstile CAPTCHA, while task submissions are also rate-limited server-side.
• Automated X verification fails closed when authorship metadata is missing; ambiguous proofs move to review instead of auto-approval.
• Rate limits and anti-Sybil controls should become stricter as economic value increases.

No anti-abuse system is perfect. False positives, false negatives, RPC failures, indexer delays, smart-contract bugs, and wallet failures are all possible.

14. Privacy and custody model

The beta intentionally minimizes onboarding friction, but the local-wallet model still has custody tradeoffs.

• The browser creates a dedicated EVM wallet for the LICK ID.
• The project does not need the plaintext private key.
• A user can optionally link a verified recovery email so the same application account can be reopened on another device.
• The local signing key can be exported only as a passphrase-encrypted recovery JSON file and restored after the same LICK ID is recovered.
• The recovery file and passphrase should be stored separately. Recovering the application account and recovering the wallet signing key are separate operations: email recovery can restore access to the server-side LICK account, while the encrypted backup is required to restore the generated wallet key on a new device.
• Losing the wallet signing key does not erase server-side LICK ID, XP, Score, referral, or streak state, but it can make the linked generated wallet unable to sign. Without a linked recovery email, loss of the browser’s authentication state can also make the application account unrecoverable.
• Users should not treat the beta-generated wallet as a high-value custody wallet.
• Public X posts, public wallet addresses, public inscriptions, and referral relationships can create linkable public data. Because inscriptions are permanent, an inscription tied to a public address can remain linkable to an account’s public activity even if other surfaces later change.

Future recovery options may add passkeys or externally controlled wallets after security review.

15. Roadmap

The roadmap is organized by workstream rather than promised dates.

Public beta - live

• LICK ID onboarding
• local EVM wallet creation
• XP and verified task submissions
• qualified referral tracking
• daily streaks
• beta LICK Score
• LICK ID share card

Onchain record workstream

• finalize inscription v1 schema
• publish contracts and event format
• deploy mint / registry module
• add inscription history to LICK ID
• build explorer and verification views
• open controlled mint access
• expand inscription formats and provenance

Market workstream

• maintain verified $LICK contract and market references
• publish additional token disclosures as applicable
• monitor initial market infrastructure
• connect token utility to shipped product behavior where appropriate

Access workstream

• version LICK Score inputs
• strengthen Sybil resistance
• define mint eligibility policy
• define higher-tier inscription launch access
• publish policy changes and version history

Workstreams may ship in a different order based on readiness, security, infrastructure, and market conditions.

16. Governance and change management

LICK is currently an early-stage product, not a decentralized governance system.

Protocol parameters, score weights, task categories, verification rules, and access policies can change during beta. Material changes should be versioned and documented rather than silently rewritten.

If governance mechanisms are introduced later, their scope should be explicit. Token ownership alone should not automatically control user reputation records or rewrite historical inscriptions.

17. Risks

Participation involves technical and market risk.

Product risk

The beta can contain bugs, data inconsistencies, broken sessions, lost local wallet state, or incorrect score/referral states.

Smart-contract risk

Future inscription and token contracts can contain vulnerabilities even after review. Onchain transactions may be irreversible.

Market risk

$LICK is live and can be volatile, illiquid, or lose all value. LICK ID, XP, LICK Score, referrals, streaks, and inscriptions are product records or signals; they do not create a claim on token value or financial return.

Stock Token risk

Stock Tokens can have jurisdictional, transfer, market-hours, issuer, compliance, liquidity, and counterparty constraints. Access to the live $LICK / $SNAP market can vary by user, venue availability, and applicable restrictions.

Scoring risk

LICK Score has been server-authoritative since v0.2, but its inputs can still be incomplete, gamed, delayed, or incorrectly verified. It should not be treated as a universal measure of trustworthiness.

Third-party risk

Lick Protocol depends on browsers, RPC providers, Supabase, hosting infrastructure, Robinhood Chain, wallets, social platforms, indexers, and potentially launch/trading venues. Failures or policy changes in third-party systems can affect the product.

18. Disclosures

Lick Protocol is an independent project inspired by internet culture. It is not affiliated with, endorsed by, sponsored by, or officially connected with Snap Inc., Snapchat, Robinhood Markets, Inc., Robinhood Chain, or any launch/trading venue unless an explicit written partnership is announced by both parties.

References to the dog lens are historical and cultural. References to Robinhood Chain identify the network used by the project. References to $SNAP describe the live launch pair and do not imply endorsement by Snap Inc. or Robinhood.

$LICK is live on Robinhood Chain. The official contract address is 0x7B81059EA0123B7D8213490d1f970744ec48CA8f, and the initial market is $LICK / $SNAP on Pons. Planned inscription features, access rules, future token utility, additional market structure, and token value are not commitments until separately implemented or announced. This litepaper is informational and does not constitute financial, investment, legal, tax, or securities advice.

19. Glossary

• LICK ID - the canonical application account record that connects profile data, participation history, referrals, streaks, and score state.
• XP - non-transferable application progress earned from verified participation; one input into future access decisions.
• LICK Score - a server-computed, application-specific beta signal summarizing the strength of the account record.
• Qualified referral - a referred account that has satisfied the active backend qualification policy; distinct from a raw signup or pending referral.
• Streak - consecutive UTC calendar days on which the signed-in account records qualifying daily activity in the beta.
• LICK inscription - a planned immutable Robinhood Chain receipt for a selected verified LICK milestone; not a Bitcoin Ordinal or BRC-20 object.

20. References

1. Snap Newsroom, 2016 Energy, 2026 Mindset, 16 January 2026. Source
2. Teen Vogue, Why Snapchat’s Puppy Filter Makes Everyone Look Good, 16 June 2016. Source
3. Robinhood Chain Documentation, About Robinhood Chain. Source
4. Robinhood Chain Documentation, Connecting to Robinhood Chain. Source
5. Robinhood Chain Documentation, Stock Tokens. Source
6. Robinhood Chain Documentation, Brand Guidelines. Source
7. Ordinal Theory Handbook, Inscriptions. Source
8. Farcaster Protocol, Overview. Source
9. Ethos, Credibility Score documentation. Source
10. Binance Research, Introducing Binance Research / project report structure. Source
11. Binance Research, Tokenomics - Deep Dive. Source

21. Version history

v0.3 - September 2026

• Records the public launch of $LICK on Robinhood Chain.
• Publishes the official contract address: 0x7B81059EA0123B7D8213490d1f970744ec48CA8f.
• Records the initial $LICK / $SNAP market on Pons.
• Keeps inscription minting, access thresholds, and broader token utility clearly separated as planned or evolving product layers.

v0.2 - September 2026

• Moves authoritative LICK Score calculation to the backend and versions the score formula.
• Re-audits core RLS and sensitive write permissions in a single security migration.
• Retires the legacy follow task and reverses traceable legacy fixed referral XP.
• Rejects cross-task proof reuse and changes X auto-verification to fail closed on missing authorship metadata.
• Persists LICK card claims server-side.
• Adds optional recovery email and passphrase-encrypted local-wallet backup/restore flow.
• Adds Cloudflare Turnstile CAPTCHA protection for anonymous account creation in the production deployment.

v0.1 - September 2026

• First public litepaper.
• Documents live beta primitives and the proposed inscription architecture.
• Separates XP, LICK Score, inscriptions, and $LICK into distinct layers.
• Leaves tokenomics, launch venue, executable quote asset, and inscription contract details explicitly unfinalized.

Official website: https://lickprotocol.fun
Official X: https://x.com/Lick_Protocol