LAK Whitepaper

A decentralized utility token for the global entertainment, electronic music and club ecosystem

Disclaimer: This document is provided for technical and ecosystem description purposes only. It does not constitute investment advice, an offer of securities, a promise of returns, or legal advice. LAK is an ecosystem utility token; it does not represent equity, dividend rights, or any form of investment return. Participants must assess risks independently and comply with the laws and regulations of their own jurisdiction. Appendix D lists the items that must be finalised by the project team and professional advisors.

Table of Contents

1. Executive Summary
2. Industry Background and Problems
3. The LAK Solution
4. Tokenomics
5. Technical Architecture
6. Multi-Chain Issuance Matrix
7. Ecosystem Use Cases
8. Governance and Permission Model
9. Security and Audit
10. Roadmap
11. Compliance and Risk Disclosure
12. Appendices

1. Executive Summary

LAK is a decentralized utility token built for the global entertainment industry, the electronic music sector, and club venues. Its design draws on the proven practices of three major public blockchains and a leading exchange ecosystem:

LAK does not aim to be another general-purpose blockchain. It aims to provide the entertainment industry with a settlement, incentive and audit layer — so that ticketing, music royalties, club memberships, fan tipping and venue settlement all run on one shared on-chain standard.

Key characteristics at a glance

• Fixed hard cap — The 21,000,000 ceiling is a contract constant; any mint exceeding it reverts
• Market-linked deflation — The burn rate is tied to entertainment and electronic music industry indices: the hotter the industry, the stronger the burn, capped at 5%
• Zero fee by default — Transfer fee defaults to 0, can be enabled by governance, capped at 5%
• Seven-role permission governance — Built on OpenZeppelin AccessControl; every role can be handed over to a multisig wallet
• Three chains in parallel — EVM, Solana SPL and Bitcoin BRC-20, with a lock/mint mechanism keeping total circulating supply constant
• Open source and verifiable — Contracts are deployed with source code verified on a public block explorer; anyone can audit them independently

2. Industry Background and Problems

The global entertainment and electronic music industry is vast, yet value transfer still suffers from well-known frictions:

2.1 Long settlement cycles and many intermediaries

Revenue from a music festival typically flows through organiser → promoter → artist agency → artist → venue. Cross-border settlement can take weeks, and every layer adds fees and foreign-exchange losses.

2.2 Opaque royalty distribution

Streaming and performance royalties for electronic music artists depend on centralised collecting societies. Creators cannot readily verify the origin and calculation of each payment in real time.

2.3 No programmable relationship between clubs and audiences

Club membership programmes are typically siloed per venue, and membership benefits cannot circulate across venues. Fan support (tipping, cheer campaigns) also lacks a cumulative, verifiable record.

2.4 High barriers in cross-border payments

Entertainment is inherently cross-border — touring, international collaborations, overseas fans — yet traditional payment rails are poorly suited to small, high-frequency flows.

2.5 Existing token designs misaligned with entertainment use cases

Many tokens in the market either lack stable settlement capability or leave compliance and risk controls unaddressed, making them hard to integrate with real commercial scenarios that require KYC/AML and regulatory responsiveness.

3. The LAK Solution

LAK addresses these issues through a three-layer structure: standard contracts, multi-chain issuance, and scenario-specific distribution tools.

┌─────────────────────────────────────────────────────┐
│  Application : ticketing / royalties / membership /  │
│                tipping / venue settlement            │
├─────────────────────────────────────────────────────┤
│  Tooling     : batch distribution · Permit offline   │
│                authorisation · wallet integration    │
├─────────────────────────────────────────────────────┤
│  Contracts   : ERC-20 + Permit + Pausable +          │
│                blocklist + market-linked burn        │
├─────────────────────────────────────────────────────┤
│  Issuance    : all EVM chains · Solana SPL · BRC-20  │
└─────────────────────────────────────────────────────┘

How the design maps to industry problems:

4. Tokenomics

4.1 Base parameters

4.2 Allocation

The allocation sums to 100% of the 21,000,000 hard cap. Everything beyond the 30% genesis supply is released from the treasury multisig according to the roadmap, and every release leaves an on-chain record.

4.3 Market-linked burn mechanism

LAK's deflation model is not a fixed rule; it is tied to the health of the entertainment industry:

burnRate = baseBurnBps + weightedIndexDeviation × burnSensitivity      (capped at 5%)
weightedIndexDeviation = entDeviation × (1 − musicWeight) + musicDeviation × musicWeight
indexDeviation = max(0, (industryIndex − target) / target)

• Index source: reported by ORACLE_ROLE; a value of 1e18 represents the baseline 1.0
• Default weighting: electronic music / club index 50%, broader entertainment index 50%
• Hard cap: regardless of index movement, the burn rate can never exceed maxBurnBps (≤5%)
• Trigger conditions: applies only to actual transfers; minting, burning, fee-exempt addresses and zero-fee scenarios do not incur burns

Worked example: with an entertainment index of 1.15 (+15%) and a music index of 1.08 (+8%), a 50% music weighting yields a weighted deviation of 1500×50% + 800×50% = 1150 bps (11.5%). With sensitivity set to 100 (each 1% deviation → 1 basis point), the increment is 1150 × 100 / 10000 = 11.5 bps; added to a 50 bps base burn, the final burn rate is about 61.5 bps (0.615%).

4.4 Fee model

• Zero fee by default, suited to everyday payments and performance settlement
• Can be enabled by FEE_ROLE when needed, capped at 5%; fees accrue to feeRecipient (recommended: the treasury multisig)
• Fee-exemption list: liquidity pools, treasury and club settlement accounts can be exempted to avoid market-making drag and internal transfer leakage
• Calculation order: burn is deducted first, the fee is computed on the post-burn amount, and the net amount is credited last — so the amount a user actually receives is transparent and predictable

4.5 Transfer settlement flow

Transfer request
   │
   ├─ ① Blocklist check (sender / recipient) ── revert if matched
   │
   ├─ ② Market-linked burn: value × currentBurnBps()  → to address(0), total supply falls
   │
   ├─ ③ Fee: (value − burn) × feeBps  → to feeRecipient
   │
   └─ ④ Net credit: value − burn − fee

5. Technical Architecture

5.1 Contract composition

The LAK contract is built on OpenZeppelin Contracts v5.0.2 and composes the following standard modules:

Compiler settings: Solidity 0.8.24, optimiser enabled (runs = 200), EVM version paris.

5.2 Core capabilities

5.3 Security design highlights

On-chain hard limits, not trust

• The hard cap MAX_SUPPLY, fee ceiling MAX_FEE_BPS and burn ceiling MAX_BURN_BPS are all contract constants
• Any operation exceeding a limit reverts at the contract level, rather than relying on governance self-restraint
• setBurnPolicy adds further checks: base burn cannot exceed the ceiling, and the weight cannot exceed 100%

A single settlement entry point

All balance changes converge on the _update hook (the unified entry point in OpenZeppelin v5), guaranteeing that the ordering of blocklist checks, burning and fee charging is identical across every transfer path — there is no bypass channel.

External call safety

The token rescue function is only permitted to operate on ERC-20 tokens other than LAK itself (an explicit token != address(this) check), eliminating any possibility of an administrator draining the native token through the rescue path; it also uses SafeERC20 and nonReentrant.

Complete event logging

Events such as FeeUpdated, AddressBlocked, IndustryIndexUpdated, BurnPolicyUpdated, BurnFromAccount and TokensRescued cover every governance action and can be tracked in real time by block explorers and third-party monitoring.

Test coverage

The project includes 51 unit tests covering issuance, burning, fees, blocklisting, pausing, market-linked burn policy, batch transfer, permission boundaries, defensive branches and governance parameter boundaries, with 100% statement coverage and 96.74% branch coverage. Passing tests are not a security guarantee — a third-party audit is required before mainnet issuance (see Section 9).

6. Multi-Chain Issuance Matrix

LAK follows a "one economic model, three technical routes" strategy:

Cross-chain consistency principle

A lock — mint / burn — unlock mechanism links the three chains:

• When tokens are locked on the native chain (EVM), an equal amount is minted on the target chain
• When tokens are burned on the target chain, an equal amount is unlocked on the native chain
• At any moment, the sum of circulating supply across all three chains never exceeds the 21,000,000 hard cap

The bridge contracts and their verification mechanisms require an independent audit before launch. This is the highest-risk component of the entire design.

7. Ecosystem Use Cases

7.1 Ticketing and NFT tickets

Concert tickets become on-chain assets with identity binding, transferability and secondary-market royalty flow-back. Organisers can distribute benefits or process refunds to thousands of ticket holders in a single batchTransfer call.

7.2 Royalty distribution for electronic music artists

Streaming and performance revenue is distributed automatically according to pre-set on-chain shares. Creators can query the source address and amount of every payment in real time, and the distribution rules are publicly verifiable.

7.3 Club membership programmes

Token holdings map directly to benefits such as table reservations, beverage discounts and priority access to events. Because the membership credential is an on-chain address, benefits can circulate across venues and cities, forming an alliance-style membership network.

7.4 Fan tipping and support

EIP-2612 Permit lets small tips skip the separate approve transaction — one signature completes the authorisation. Combined with a default zero fee, this substantially lowers the cost of high-frequency micro-payments.

7.5 Performance and venue settlement

Revenue splits among organisers, venues, artists and suppliers can be settled in a single batch transfer, with the on-chain record serving as the settlement receipt.

7.6 Settlement and pricing

Commercial settlement within the ecosystem follows a priced in USD, settled in LAK model — prices are anchored to the US dollar while payment is made in LAK, combining familiar fiat pricing with the efficiency of on-chain settlement.

Core mechanism: settlement discount

Ecosystem merchants price in USD; when a user chooses to pay in LAK, the merchant may apply an ecosystem discount. The discount rate is set, published and adjusted by each merchant at its own discretion.

Conversion method (illustrating the calculation logic only; no fixed amounts)

Let D% be the merchant's discount, P the USD list price, and R the market reference price read from the on-chain oracle at settlement time (USD / LAK):

Example (illustrating the calculation only; the reference price shown is hypothetical)

List price P = 100 USD, discount D = 50%, market reference price at settlement R = 0.05 USD/LAK ⇒ consideration = 50 USD ⇒ LAK amount = 50 ÷ 0.05 = 1,000 LAK

The 1,000 LAK above depends entirely on the hypothetical R: if R were 0.01 USD/LAK, the same order would require 5,000 LAK. The figure therefore does not represent any actual settlement ratio and constitutes no price or quantity commitment; the actual amount payable is determined by the oracle reading at settlement time.

Settlement principles and qualifications

1. The discount is a commercial pricing decision by the merchant, not a statement by the project about the price of LAK. Rates are set voluntarily by each merchant, may be changed at any time, and are not required to be consistent across merchants.
2. The ecosystem does not provide any exchange service between LAK and any fiat currency, and the project assumes no redemption, principal-protection, buy-back or fixed-exchange obligation of any kind.
3. The market price of LAK is determined by public supply and demand and may differ from any merchant's settlement discount standard. No one should make an investment decision based on a merchant's settlement discount.
4. Where a market-based conversion is required, it follows the market reference price read from the on-chain oracle, not any fixed value.

8. Governance and Permission Model

8.1 Seven-role permission matrix

8.2 Principles of permission handover

• Hand over at deployment — On mainnet, the MULTISIG parameter grants all roles to the multisig wallet and revokes the deployer's permissions directly
• Least privilege — Each role goes only to the holders that genuinely need it; avoid a single point of control over all capabilities
• Auditable — Every grant and revoke emits an on-chain event
• Revocable — DEFAULT_ADMIN_ROLE can revoke any role at any time

The project has completed a full governance drill on testnet: create a multisig → grant all seven roles → have the multisig batch-revoke the deployer's permissions → confirm the deployer's calls are rejected by the contract → expand the multisig to 3 holders / threshold 2 → verify the multisig execution path (including signature collection and threshold validation).

8.3 Governance evolution

9. Security and Audit

9.1 Measures already in place

9.2 Outstanding

The project has completed a self-audit (see AUDIT-SELF-CHECK.md): Solhint reports no errors, Slither's only finding against project code has been implemented, and the full report is available to auditors as a pre-audit package.

Audit reports will be published on the official website and the GitHub repository for community verification.

10. Roadmap

The roadmap follows one principle: run the ecosystem on everything that does not depend on compliance filings first, and concentrate compliance spending at the points where it is genuinely required — namely CEX listing and licensed physical-business operations.

On CEX listing prerequisites: the due-diligence checklists of mainstream centralised exchanges routinely require the issuing entity to provide a legal opinion and an audit report, together with entity-level KYC/AML checks. This is an industry-wide threshold and cannot be circumvented by reordering the roadmap.

This roadmap therefore concentrates compliance spending in Phase 5: Phases 2 to 4 (mainnet, DEX liquidity, ecosystem settlement and operations) do not depend on the legal opinion and can proceed first; CEX listing must wait until the compliance documents are complete.

The absolute schedule for each phase will be published once the audit and compliance timeline is confirmed (see Appendix D).

11. Compliance and Risk Disclosure

11.1 Compliance framework

The project entity is intended to be established in the Lao People's Democratic Republic (Lao PDR); upon completion of entity registration, issuance and operations will be conducted in accordance with applicable local regulations. Entity registration and tax compliance fall under Phase 5 of the roadmap. Compliance work follows a "build first, trigger compliance at defined gates" principle, aligned with the roadmap in Section 10:

Mechanisms in place and planned

• Implementing KYC / AML procedures and an address blocklist mechanism (the contract already provides setBlocked)
• Conducting due diligence on partner exchanges, venues and market makers
• Providing contract-level pause and setBlocked capabilities to respond to regulatory requirements and judicial assistance requests
• Entity registration and tax-compliance procedures (Phase 5 of the roadmap)
• Commercial settlement uses a discount-based model (see 7.6) and provides no fiat exchange service

Scope note: compliance spending is phased according to the roadmap in Section 10.

• Until the legal opinion is obtained, the project will not conduct any public offering, sale or pre-sale, and will not submit CEX listing applications;
• Mainnet deployment, DEX liquidity and ecosystem settlement are technical and commercial operations, and proceed according to each phase's prerequisites;
• Laos approaches digital assets through a pilot / regulatory sandbox / licensing framework, and token issuance is a regulated activity. The specific issuance structure, entity qualifications and compliance path must be confirmed only after a legal opinion is issued by a professional qualified to practise law in Laos.

11.2 Risk disclosure

Holding and using the token involves a range of risks, disclosed below by category. Group B (contract and governance risks) describes design features the project discloses proactively — these capabilities are deliberately retained to meet compliance and risk-control requirements and should be read carefully.

A. Token and market risks

B. Contract and governance risks

C. Operational and third-party risks

D. Legal and tax risks

Important notices

• LAK is an ecosystem utility token. It does not constitute any security, equity, debt instrument, fund share or promise of return, and represents no form of investment return.
• This whitepaper does not constitute investment, financial, legal or tax advice, nor an offer or solicitation of an offer in any jurisdiction.
• Digital assets carry extremely high risk and may result in the total loss of capital. Consult independent financial, legal and tax advisers and make an independent decision based on your own risk tolerance.
• The roadmap, parameters and mechanisms described may change with market conditions, regulatory policy and technical constraints; material changes will be announced through official channels.

12. Appendices

Appendix A · Deployed contract addresses

Testnet multisig address (permission holder, holds all seven roles): 0x61019DaD671064a840666241685E98cd973870D3

Testnet liquidity pool (Uniswap V2 · LAK/WETH): 0xa948CE83ca05DdED1A1Ad2027c7C5a3eD3b910C2

The addresses above are for technical verification only. Testnet assets have no market value, and the initial pool ratio does not constitute any pricing, reference price, or price commitment.

Appendix B · Key technical parameters

Appendix C · Contract interface reference

// Read-only
name() / symbol() / decimals() / totalSupply() / balanceOf(address)
allowance(owner, spender) / MAX_SUPPLY() / currentBurnBps() / totalBurned()

// Transfers and approvals
transfer(to, amount) / approve(spender, amount) / transferFrom(from, to, amount)
permit(owner, spender, value, deadline, v, r, s)       // EIP-2612 off-chain approval
batchTransfer(address[] recipients, uint256[] amounts)  // batch distribution

// Governance (role-gated)
mint(to, amount)                          // MINTER_ROLE
burnFromAccount(account, amount)          // BURNER_ROLE
pause() / unpause()                       // PAUSER_ROLE
setBlocked(account, blocked)              // COMPLIANCE_ROLE
setFeeBps(bps) / setFeeRecipient(addr)    // FEE_ROLE
setFeeExempt(account, exempt)             // FEE_ROLE
setIndustryIndex(ent, music)              // ORACLE_ROLE
setBurnPolicy(base, sens, max, weight, enabled)   // BURNER_ROLE
rescueToken(token, to, amount)            // DEFAULT_ADMIN_ROLE

Appendix D · Items to be confirmed

The following must be finalised by the project team together with professional advisors before the official version is published:

1. Legal opinion — A written opinion from a law firm qualified to practise in Laos (issuance structure, entity qualifications, tax arrangements)
2. Audit report — Third-party smart-contract audit findings and a public link
3. Team information — Core members, advisors, engineering team size
4. Entity details — Registered name, registration number and registered address in Laos
5. Vesting details — Cliff period (if any) and linear-release schedule for the team allocation
6. Roadmap timing — Absolute schedule (month / quarter) for each phase
7. Exchange plan — Initial DEX choice and whether to pursue CEX listings
8. Liquidity size — Amount of capital for initial liquidity and the LP lock-up period
9. Airdrop rules — Eligibility, qualification criteria, anti-Sybil mechanism and claim method
10. Contact channels — Official announcement channel, community entry points, media contact

Appendix E · Legal notice

This document does not constitute investment advice, an offer of securities, or a solicitation of an offer in any jurisdiction to any person. The technical plans and roadmap described may change with market conditions, regulatory policy and technical constraints; the project reserves the right to make revisions, and material changes will be announced through official channels.

Investing in digital assets carries extremely high risk and may result in the total loss of your capital. Please consult independent financial, legal and tax advisors before participating.

Document version v1.0 Draft · September 2026 · LAKBTC.com