LUKO

SPECIFICATION

LUKO (ERC-20), Base mainnet · Document version 1.0 · Status: Final

1 · Introduction

↑ top

LUKO is a fungible token conforming to the ERC-20 standard, deployed on Base, an Ethereum layer-2 network.

The token was created by a single deployment transaction. That transaction minted the entire supply, assigned it to the deployer address, and terminated the issuance process permanently. No further contract-level action is possible.

LUKO has no administrator, no upgrade mechanism, no treasury logic, no governance module, and no dependency on any off-chain service. The deployed bytecode is the complete and final implementation. There is no second component, no backend, and no protocol layer built on top of it.

This document describes what the contract is and what it does. It does not describe intentions, plans, or expectations, because none exist at the contract level. Readers evaluating LUKO — block explorer reviewers, wallet maintainers, listing desks, auditors — should treat the verified source code as authoritative and this document as a description of it.

LUKO is complete. Nothing is pending.

LUKO — pakeičiamas (fungible) tokenas, atitinkantis ERC-20 standartą ir įdiegtas Base tinkle, Ethereum antrojo lygio (L2) tinkle.

Tokenas sukurtas viena diegimo transakcija. Ta transakcija iškalė visą emisiją, priskyrė ją diegėjo adresui ir visam laikui užbaigė emisijos procesą. Jokie tolesni veiksmai sutarties lygmeniu nebeįmanomi.

LUKO neturi administratoriaus, atnaujinimo mechanizmo, iždo logikos, valdymo modulio ir jokios priklausomybės nuo išorinių paslaugų. Įdiegtas baitinis kodas yra visa ir galutinė realizacija. Nėra jokio antro komponento, jokios serverio dalies ir jokio ant viršaus pastatyto protokolo sluoksnio.

Šis dokumentas aprašo, kas ši sutartis yra ir ką ji daro. Jame neaprašomi ketinimai, planai ar lūkesčiai, nes sutarties lygmeniu jų nėra. Skaitytojai, vertinantys LUKO — blokų naršyklių prižiūrėtojai, piniginių kūrėjai, biržų sąrašų sudarytojai, auditoriai — turėtų laikyti patvirtintą pirminį kodą autoritetingu, o šį dokumentą — jo aprašymu.

LUKO yra baigtas. Niekas nėra laukiama.

2 · Design principles

↑ top

The design follows four rules.

Minimality. The contract implements the ERC-20 interface and one public constant, and nothing else. No hooks, no fees, no transfer restrictions, no allowlists, no blocklists, no pause switch, no rebasing, no reflection, no callbacks into external contracts. Every line of behaviour not required by the standard was excluded deliberately.

Immutability as the product. Most token contracts treat immutability as a property to be mentioned. Here it is the entire deliverable. What LUKO offers is the guarantee that its state transition rules cannot be altered by anyone, including its author. That guarantee is only meaningful if there is nothing else — no admin key that could be added, no proxy that could be repointed, no governance that could vote. Removing capability is what creates the guarantee.

Absence of privilege. No address holds a role that other addresses do not. The deployer has no residual rights. After deployment the deployer is an ordinary holder, distinguishable only by balance, not by permission.

Finality over iteration. The contract will not be improved, extended, migrated, or replaced by its author. A version 2 would contradict the premise of version 1. The absence of a roadmap is a design decision, not an omission.

Standard implementation code was used rather than custom code. Novelty in an ERC-20 implementation is a liability, not a feature.

Dizainas remiasi keturiomis taisyklėmis.

Minimalumas. Sutartis įgyvendina ERC-20 sąsają ir vieną viešą konstantą — ir nieko daugiau. Jokių kabliukų (hooks), jokių mokesčių, jokių pervedimo apribojimų, jokių leidžiamų ar draudžiamų adresų sąrašų, jokio pauzės jungiklio, jokio emisijos perskaičiavimo (rebasing), jokio atspindžio (reflection), jokių atgalinių iškvietimų į išorines sutartis. Kiekviena elgsena, kurios standartas nereikalauja, buvo sąmoningai pašalinta.

Nekintamumas kaip produktas. Daugelis tokenų sutarčių laiko nekintamumą tiesiog paminėtina savybe. Čia tai — visas rezultatas. LUKO siūlo garantiją, kad jos būsenos perėjimo taisyklių negali pakeisti niekas, įskaitant ir jos autorių. Ši garantija prasminga tik tada, kai nėra nieko daugiau: nei administratoriaus rakto, kurį būtų galima pridėti, nei tarpinės sutarties (proxy), kurią būtų galima nukreipti kitur, nei valdymo organo, kuris galėtų balsuoti. Būtent galimybių panaikinimas ir sukuria šią garantiją.

Privilegijų nebuvimas. Joks adresas neturi vaidmens, kurio neturėtų kiti adresai. Diegėjas neturi jokių likutinių teisių. Po diegimo diegėjas yra eilinis turėtojas, išsiskiriantis tik balansu, o ne teisėmis.

Baigtumas vietoj iteracijų. Autorius sutarties netobulins, neplės, nemigruos ir nekeis. Antra versija prieštarautų pirmosios prielaidai. Veiksmų gairių nebuvimas yra sąmoningas sprendimas, o ne praleidimas.

Naudotas standartinis realizacijos kodas, o ne savas. Naujovės ERC-20 realizacijoje yra rizika, o ne privalumas.

3 · Technical specification

↑ top
NameLUKO
SymbolLUKO
StandardERC-20
NetworkBase (Ethereum L2)
Chain ID8453
Contract0x4a9DA2831A691E7C4aca594CaFd58c35e0131fD1
Decimals18
Total supply1,000,000
Total supply (base units)1,000,000,000,000,000,000,000,000
Supply modelFixed, minted once at deployment
ImplementationOpenZeppelin ERC20
LanguageSolidity, pragma ^0.8.20
LicenseMIT
Source verificationVerified on BaseScan (exact match)
MutabilityImmutable; not upgradeable
ProxyNone
Owner / adminNone
Mint functionNone reachable post-deployment
Burn functionNot exposed
Transfer feeNone
Pause / freezeNone
External callsNone

Implemented interface: name(), symbol(), decimals(), totalSupply(), balanceOf(address), transfer(address,uint256), allowance(address,address), approve(address,uint256), transferFrom(address,address,uint256), plus the Transfer and Approval events.

The contract is not Ownable. It contains no onlyOwner modifier, no role registry, no AccessControl inheritance, and no selfdestruct. It holds no ETH-handling logic and has no receive or payable function.

Total supply is set once, in the constructor, and is thereafter a constant of the deployed state. totalSupply() will return the same value for the lifetime of the network.

The only member beyond the standard interface is INITIAL_SUPPLY, a public uint256 constant equal to the genesis supply in base units. It is compile-time constant and read-only.

Behaviour matches the OpenZeppelin reference implementation exactly; no function was overridden. Integrators may therefore rely on standard ERC-20 assumptions without special handling. Note the standard approve race condition, inherent to ERC-20 itself and not specific to this deployment.

Įgyvendinta sąsaja: name(), symbol(), decimals(), totalSupply(), balanceOf(address), transfer(address,uint256), allowance(address,address), approve(address,uint256), transferFrom(address,address,uint256) bei įvykiai Transfer ir Approval.

Sutartis nėra Ownable. Joje nėra onlyOwner modifikatoriaus, jokio vaidmenų registro, jokio AccessControl paveldėjimo ir jokio selfdestruct. Ji neturi ETH tvarkymo logikos ir neturi receive ar payable funkcijos.

Bendra emisija nustatoma vieną kartą konstruktoriuje ir nuo tol yra įdiegtos būsenos konstanta. totalSupply() visą tinklo gyvavimo laiką grąžins tą pačią reikšmę.

Vienintelis narys, viršijantis standartinę sąsają, yra INITIAL_SUPPLY — vieša uint256 konstanta, lygi pradinei emisijai baziniais vienetais. Ji yra kompiliavimo meto konstanta ir skirta tik skaitymui.

Elgsena tiksliai atitinka OpenZeppelin etaloninę realizaciją; nė viena funkcija nebuvo perrašyta. Todėl integruotojai gali remtis standartinėmis ERC-20 prielaidomis be jokio specialaus apdorojimo. Atkreipkite dėmesį į standartinę approve lenktynių sąlygą (race condition), būdingą pačiam ERC-20 standartui, o ne šiam diegimui.

3.1 · Source

The verified source is reproduced below in full. It is the entire contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract LUKO is ERC20 {
    uint256 public constant INITIAL_SUPPLY = 1_000_000 ether;

    constructor() ERC20("LUKO", "LUKO") {
        _mint(msg.sender, INITIAL_SUPPLY);
    }
}

The ether suffix is a Solidity literal unit denoting 10^18 and carries no monetary meaning; it expresses 1,000,000 tokens at 18 decimals.

Priesaga ether yra Solidity literalo vienetas, žymintis 10^18, ir neturi jokios piniginės prasmės; ji išreiškia 1 000 000 tokenų su 18 skaitmenų po kablelio.

4 · Genesis

↑ top

The entire supply of 1,000,000 LUKO was minted in the contract's constructor during the deployment transaction, included in Base block 49364826.

That mint is the only issuance event that has occurred and the only one that can occur. The minting code path exists solely inside the constructor and is unreachable once the contract is deployed. There is no scheduled emission, no vesting contract, no inflation parameter, no staking rewards, and no mechanism by which totalSupply() can increase.

All minted tokens were credited to the deploying address at genesis. Subsequent distribution, if any, has occurred through ordinary transfers recorded on-chain. Current holder distribution is observable on any Base block explorer and is not restated here, as it changes independently of this document.

Tokens sent to unrecoverable addresses are permanently removed from circulation. The contract exposes no burn function; supply reduction is possible only in that incidental sense.

Visa 1 000 000 LUKO emisija buvo iškalta sutarties konstruktoriuje diegimo transakcijos metu, įtrauktos į Base bloką 49364826.

Šis kaldinimas yra vienintelis įvykęs ir vienintelis įmanomas emisijos įvykis. Kaldinimo kodo kelias egzistuoja tik konstruktoriaus viduje ir tampa nepasiekiamas, vos tik sutartis įdiegiama. Nėra jokios suplanuotos emisijos, jokios dalinio išmokėjimo (vesting) sutarties, jokio infliacijos parametro, jokių steikingo apdovanojimų ir jokio mechanizmo, kuriuo totalSupply() galėtų padidėti.

Visi iškalti tokenai pradžioje buvo įskaityti diegimo adresui. Vėlesnis paskirstymas, jei toks buvo, vyko įprastais pervedimais, užfiksuotais grandinėje. Dabartinis turėtojų pasiskirstymas matomas bet kurioje Base blokų naršyklėje ir čia nekartojamas, nes jis keičiasi nepriklausomai nuo šio dokumento.

Tokenai, išsiųsti į neatkuriamus adresus, visam laikui pašalinami iš apyvartos. Sutartis neatskleidžia jokios deginimo funkcijos; emisiją sumažinti galima tik šiuo šalutiniu būdu.

5 · Administrative model

↑ top

There is no administrative model. This section exists to state that explicitly, because its absence is otherwise indistinguishable from an omission.

The contract has no owner. Ownership functionality was not renounced after deployment — it was never included. This distinction matters: a renounced-ownership contract passed through a window in which privileged action was possible. LUKO had no such window.

Consequently:

  • No address can mint tokens.
  • No address can burn or seize the tokens of another address.
  • No address can pause, freeze, or restrict transfers.
  • No address can modify balances, allowances, metadata, or supply.
  • No address can upgrade, replace, or migrate the contract.
  • No address can extract funds from the contract, which holds none.

There is no proxy, no implementation slot, no beacon, and no delegatecall. The address a user interacts with contains the executing logic directly. The code returned by eth_getCode at that address is the code that will run, permanently.

The author retains no capability over the contract beyond that of any other address. There is no key whose compromise could alter the token's behaviour, because no such key exists.

Administravimo modelio nėra. Šis skyrius egzistuoja tam, kad tai būtų pasakyta tiesiogiai, nes kitaip jo nebuvimą sunku atskirti nuo paprasto praleidimo.

Sutartis neturi savininko. Nuosavybės funkcionalumo nebuvo atsisakyta po diegimo — jis niekada nebuvo įtrauktas. Šis skirtumas svarbus: sutartis, kurios nuosavybės atsisakyta, praėjo pro langą, kuriame privilegijuoti veiksmai buvo įmanomi. LUKO tokio lango neturėjo.

Todėl:

  • Joks adresas negali iškalti tokenų.
  • Joks adresas negali sudeginti ar pasisavinti kito adreso tokenų.
  • Joks adresas negali pristabdyti, užšaldyti ar apriboti pervedimų.
  • Joks adresas negali keisti balansų, leidimų, metaduomenų ar emisijos.
  • Joks adresas negali atnaujinti, pakeisti ar migruoti sutarties.
  • Joks adresas negali išimti lėšų iš sutarties, nes ji jų neturi.

Nėra jokios tarpinės sutarties (proxy), jokio realizacijos lizdo, jokio švyturio (beacon) ir jokio delegatecall. Adresas, su kuriuo sąveikauja naudotojas, tiesiogiai turi vykdomąją logiką. Kodas, kurį tuo adresu grąžina eth_getCode, yra kodas, kuris bus vykdomas visada.

Autorius neturi jokių galimybių sutarties atžvilgiu, viršijančių bet kurio kito adreso galimybes. Nėra rakto, kurio kompromitavimas galėtų pakeisti tokeno elgseną, nes tokio rakto paprasčiausiai nėra.

6 · Non-goals

↑ top

LUKO is explicitly not the following:

  • Not a governance token. It confers no voting rights over anything, on-chain or off-chain. There is no DAO, no proposal system, no snapshot process.
  • Not equity. It represents no ownership of, claim on, or entitlement to any entity, asset, revenue, dividend, or distribution.
  • Not a protocol. There is no lending, exchange, staking, bridging, or settlement layer. A single ERC-20 contract is the whole system.
  • Not an investment vehicle. No return is offered, implied, projected, or managed. There is no fund, no strategy, and no party acting on a holder's behalf.
  • Not a promise of future utility. No feature is planned. No integration is committed. No product will be built to give the token a use.
  • Not a claim to solve a problem. LUKO does not assert a market inefficiency, a technical gap, or a use case.
  • Not a security-audited guarantee of user outcomes. The implementation is standard and the source is verified; neither fact protects a holder from their own transactions, from price, or from third-party contracts they choose to interact with.

The absence of utility is intentional and permanent. It should be read as a specification, not as an early stage.

LUKO aiškiai nėra šie dalykai:

  • Ne valdymo tokenas. Jis nesuteikia jokių balsavimo teisių niekur — nei grandinėje, nei už jos ribų. Nėra jokios DAO, jokios pasiūlymų sistemos, jokio snapshot proceso.
  • Ne nuosavybės dalis. Jis nereiškia jokios nuosavybės, pretenzijos ar teisės į jokį subjektą, turtą, pajamas, dividendus ar paskirstymą.
  • Ne protokolas. Nėra jokio skolinimo, keitimo, steikingo, tiltų ar atsiskaitymo sluoksnio. Viena ERC-20 sutartis yra visa sistema.
  • Ne investicinė priemonė. Jokia grąža nėra siūloma, numanoma, prognozuojama ar valdoma. Nėra jokio fondo, jokios strategijos ir jokios šalies, veikiančios turėtojo vardu.
  • Ne pažadas dėl būsimo panaudojimo. Jokia funkcija neplanuojama. Jokia integracija neįsipareigota. Nebus kuriamas joks produktas, kuris suteiktų tokenui paskirtį.
  • Ne pretenzija išspręsti problemą. LUKO neteigia esant rinkos neefektyvumo, techninės spragos ar panaudojimo atvejo.
  • Ne saugumo audito garantuotas rezultatas naudotojui. Realizacija yra standartinė, o kodas patvirtintas; nė vienas iš šių faktų neapsaugo turėtojo nuo jo paties sandorių, nuo kainos ar nuo trečiųjų šalių sutarčių, su kuriomis jis pasirenka sąveikauti.

Panaudojimo nebuvimas yra sąmoningas ir nuolatinis. Tai skaitytina kaip specifikacija, o ne kaip ankstyva stadija.

7 · Intended audience

↑ top

LUKO is not designed to satisfy every possible expectation of an ERC-20 token.

The intended audience is not defined by what they expect to be added, but by what they accept will never be added. For those who consider the deliberate absence of governance, utility, administrative control and future obligations to be features rather than deficiencies.

LUKO nėra sukurtas taip, kad tenkintų visus įmanomus lūkesčius ERC-20 tokenui.

Numatytą auditoriją apibrėžia ne tai, ko ji tikisi būsiant pridėta, o tai, ką ji priima kaip niekada nebūsiantį pridėta. Ji skirta tiems, kurie sąmoningą valdymo, panaudojimo, administracinės kontrolės ir būsimų įsipareigojimų nebuvimą laiko privalumais, o ne trūkumais.

8 · Frequently asked questions

↑ top

Why 1,000,000?

Because a fixed number was required and a small round one is legible. One million units at 18 decimals is unambiguous, easy to reason about, and requires no explanation of emission curves. No modelling justifies the figure; none was performed. The specific number matters less than the fact that it cannot change.

Why no owner?

An owner is a trust assumption. Any privileged address must be trusted not to use its privileges, and trusted to keep its key secure indefinitely. Omitting the role removes both risks at the cost of removing all administrative flexibility — flexibility this contract does not need.

Why immutable?

Upgradeability means the rules a holder agreed to can be replaced later by someone else. Immutability means the rules verified today are the rules that apply permanently. For a contract with no functionality beyond balance accounting, there is nothing to upgrade toward, so upgradeability would add only risk.

Why is the initial liquidity pool so small?

The liquidity pool exists to establish a public market and enable permissionless transfers between holders. It is not intended to provide deep liquidity, support speculation, or facilitate large-scale trading. LUKO is not structured as an investment product, and the pool should not be interpreted as one.

Why are so many tokens held in reserve?

Tokens held in reserve are simply held. They confer no additional rights, generate no yield, and possess no administrative capability. A token in reserve is technically indistinguishable from a token in any other wallet. Reserve balances exist only as balances, not as protocol-controlled assets.

Why disclose the genesis allocation?

Because the initial distribution is part of the artifact. Publishing it allows every subsequent transfer to be interpreted in the context of the original state.

Why no roadmap?

A roadmap is a set of unenforceable commitments about future work. Publishing one would create expectations the contract cannot guarantee, and the contract is the only thing that can be guaranteed. The deployment is the deliverable, and it is finished.

Why no utility?

Utility implies a system the token operates within, and that system would require maintenance, operators, and continued trust — the properties this design removes. LUKO is defined by what it does not depend on. Attaching a use case would reintroduce the dependencies.

Why Base?

Base is an Ethereum layer-2 with EVM equivalence, low transaction costs, standard tooling, and established explorer and wallet support. It requires no custom client, no non-standard token behaviour, and no bespoke integration work. No property of LUKO depends on Base specifically; it is a deployment target, not a component of the design.

9 · References

↑ top

Primary

Contract address 0x4a9DA2831A691E7C4aca594CaFd58c35e0131fD1
Block explorer (BaseScan) basescan.org/token/0x4a9D…1fD1 →
Source repository (GitHub) github.com/LKSPec/luko →
X x.com/MeetLUKO →
Website meetluko.eu →
Genesis block 49364826

Standards and network

Standard ERC-20 (EIP-20)
Implementation reference OpenZeppelin Contracts — ERC20
Network base.org →

Third-party venues and data sources

The following are operated by unaffiliated parties. They are listed because they reference the contract address, not because they are endorsed, controlled, or maintained by the token's author. Their availability, pricing, and liquidity are outside the scope of this specification.

Aerodrome (DEX) aerodrome.finance →
DexScreener dexscreener.com →
GeckoTerminal geckoterminal.com →

In case of any discrepancy between this document and the verified source code at the contract address, the source code is authoritative.