LEONIDA CITY

COIN

CONCEPT WHITEPAPER

A community-led digital token concept inspired by the fictional Leonida setting

Version 0.1 | 10 October 2026

INDEPENDENT FAN / COMMUNITY CONCEPT

Not affiliated with, endorsed by, or sponsored by Rockstar Games or Take-Two Interactive.

Important notice

CONCEPT STATUS This document describes a proposed project only. It does not establish that LeonidaCity Coin has launched, that a token contract exists, that a sale is open, or that any exchange listing, partnership, audit or product is confirmed.

LeonidaCity Coin is presented as an independent community-token concept inspired by the fictional Leonida setting associated with Grand Theft Auto VI (GTA VI). The GTA name, game title, setting, characters, logos and related intellectual property belong to their respective rights holders. This project is not an official game product and must not use protected branding in a way that implies authorization.

This whitepaper is informational, not investment, legal, tax or financial advice. A token may lose all of its value. No profit, liquidity, listing, adoption, game integration, giveaway, reward, or future utility is promised. Anyone considering participation should independently verify all details and understand the risks.

Reading this whitepaper

Confirmed facts, proposed features and open decisions are deliberately separated. Where the project has not supplied a verified parameter, such as network, ticker, supply, allocation, price, contract address, team identity or launch date. This document marks it as TBD rather than inventing details.

Document status

Field	Current status
Project name	LeonidaCity Coin (working name; confirm legal and brand availability)
Project type	Proposed community / fan token concept
Ticker	TBD: do not assume $LEONIDA is available
Blockchain and chain ID	TBD
Contract address	Not provided; no deployment is asserted
Token supply and allocation	TBD; requires approved, reconciled tokenomics
Launch / sale date	TBD; no sale is represented as active
Affiliation	Independent concept; no official GTA / Rockstar / Take-Two affiliation claimed

Contents

1. Executive summary

2. Project vision and scope

3. Community problem and proposed value

4. Product concept and user journey

5. Token utility and boundaries

6. Technical architecture

7. Blockchain and smart-contract design

8. Tokenomics framework

9. Distribution, launch and sale safeguards

10. Liquidity and market integrity

11. Community governance and treasury

12. Security, privacy and risk management

13. Legal, intellectual-property and compliance considerations

14. Roadmap and acceptance criteria

15. Transparency and reporting

16. Decisions required before launch

Appendix A. Glossary

Appendix B. Publication checklist

1. Executive summary

LeonidaCity Coin is a proposed community-oriented digital token concept inspired by the fictional Leonida setting associated with GTA VI. The concept is intended to bring fans and independent community contributors together around fan discussion, creative community activities and transparent project coordination.

The token’s actual purpose must be narrow, useful and accurately described. Potential community features could include participation in polls, access to independently organized community events, or rewards for eligible contributions, only if those features are built, funded and legally reviewed. The token should not be described as an official in-game currency, a way to purchase GTA VI content, or a mechanism that grants rights inside a game unless an authorized integration is confirmed in writing.

The first priority is trust: publish the contract address, token parameters, treasury controls, risks, and responsible parties before inviting the public to acquire tokens. Technical claims should be supported by deployed code and independent review, not by branding or promotional language.

CORE PRINCIPLE Community participation may be the project’s purpose; token price appreciation is not a deliverable and must never be presented as guaranteed.

Project objectives

• Build an independent and clearly labeled fan/community identity.
• Define a real, testable use for the token before launch.
• Publish transparent supply, allocation, wallet and treasury information.
• Use standard smart-contract components and independent security review where appropriate.
• Protect users from misleading claims about official affiliation, game integration, returns or exchange listings.

What this paper does not claim

• No official relationship with Rockstar Games or Take-Two Interactive.
• No in-game utility, access to GTA VI, game assets, or developer endorsement.
• No confirmed deployment, audit, presale, exchange listing, or token economics.
• No guaranteed value, return, liquidity, or market performance.

2. Project vision and scope

Vision

The proposed vision is a recognizable, independent digital community for people interested in the fictional Leonida setting and the wider GTA VI fan conversation. A token, if ultimately launched, should support specific community functions rather than exist only as a speculative ticker.

Initial scope

• Community information hub and clearly labeled social channels.
• Transparent proposal and polling process, with safeguards against duplicate or concentrated voting.
• Optional community rewards funded from a disclosed budget, if legal and operationally viable.
• Public documentation for token supply, treasury activity, privileged contract roles and security findings.
• Clear reporting channels for impersonation, scams and misleading claims.

Out of scope unless separately authorized

• Official Rockstar Games or Take-Two branding, endorsement or partnership claims.
• Promises of integration with GTA VI or any publisher-operated game service.
• Sale or distribution of copyrighted game assets, leaked content, or unauthorized merchandise.
• Promises of profits, guaranteed buybacks, guaranteed liquidity or guaranteed exchange listings.

Design principles

Principle	Practical requirement
Clarity	Every public claim is labeled as live, planned, proposed or unconfirmed.
Verifiability	Token contract, supply, wallets and transactions can be independently checked.
Minimal privilege	Admin powers are limited, disclosed and protected by appropriate controls.
No false affiliation	Branding and disclaimers make the independent status unmistakable.
Responsible promotion	No guaranteed returns, artificial urgency, or unsupported price predictions.

3. Community problem and proposed value

Fan communities can be fragmented across social platforms, and users may have difficulty distinguishing genuine community initiatives from impersonators or speculative token promotions. A community token can add coordination tools, but it can also create financial risk, governance capture and scam incentives.

Potential value areas

Area	Possible mechanism	Evidence needed
Participation	Non-binding polls and community proposals	Published rules, eligibility and anti-abuse design
Contribution	Discretionary rewards for approved work	Written criteria, funded reward pool and review process
Events	Access or priority for independent community events	Actual event operations and fair access terms
Transparency	Public treasury and token reports	Verified wallet addresses and consistent reporting
Community identity	Shared digital symbol for independent fans	Clear IP boundaries and no official endorsement claim

Success measures

Success should be measured using meaningful community outcomes, not only token price or social-media impressions. Proposed measures include unique active participants, proposal participation, completed community projects, reward-budget reconciliation, support response times, and the percentage of material project claims backed by public evidence.

Any published metric should state its measurement period, methodology, and limitations. A rise in wallet count does not necessarily mean a rise in genuine users; activity may be automated or concentrated in a small number of wallets.

4. Product concept and user journey

Illustrative user journey

1. A visitor reads the project page and sees the independent fan/community status and risk notice before any wallet connection.
2. The visitor reviews the token contract, network, supply policy, allocation, treasury wallets, and current security review.
3. If a token is launched, the user obtains it through a clearly documented route and independently verifies the contract address.
4. The user may participate in supported community features under published rules; token ownership does not automatically grant official game rights or publisher access.
5. The community publishes regular reports on treasury movements, rewards, governance decisions and known incidents.

Possible features (not yet implemented)

• Community polls that are clearly marked as non-binding unless a formal governance system is deployed.
• Contribution rewards with published eligibility criteria and a fixed, funded budget.
• Event or community access benefits where practical, lawful and actually delivered.
• Public dashboards showing supply, allocation wallets and treasury activity.

User experience safeguards

The project website should show the full contract address, chain, official communication links, and a warning that scammers may create lookalike tokens. Never ask users to reveal seed phrases or private keys. Wallet connections should be optional unless strictly required for a clearly explained feature.

5. Token utility and boundaries

Utility must be real

A token should be launched only after the team can explain why a blockchain token is needed instead of ordinary community points or a conventional membership system. If tokenization does not provide a clear and proportionate benefit, the project should reconsider whether a tradable token is appropriate.

Candidate utility model

Candidate use	Status	Required condition
Community polls	Proposed	Published voting rules; anti-sybil and concentration analysis
Contribution rewards	Proposed	Budget funded in advance; clear criteria and dispute process
Independent event benefits	Proposed	Events and capacity confirmed; terms and exclusions published
Treasury proposals	Possible later phase	Governance contract or auditable process and defined scope
In-game currency or GTA VI integration	Not claimed	Requires explicit authorization and verified technical integration

Utility limitations

• Holding the token does not confer intellectual-property ownership, publisher affiliation, or rights in GTA VI.
• Token ownership does not guarantee voting influence unless the applicable rules and implementation say so.
• Rewards may be paused, exhausted or unavailable under published conditions; no fixed yield is proposed.
• Token utility does not establish that the token will have market value or be accepted by third parties.

6. Technical architecture

The final architecture depends on the selected blockchain and the intended utility. The following is a reference design, not a claim that components have been deployed.

Component	Proposed responsibility	Key trust / failure boundary
Community website	Publish documentation, notices and feature interfaces	Website compromise can misdirect users; publish verified links
Wallet interface	Allow users to inspect and sign transactions	Users can approve malicious or incorrect transactions
Token contract	Apply token balances and transfer rules	Code defects and privileged roles can affect holders
Treasury wallet	Hold disclosed project funds or token allocations	Signers, key loss and collusion risks
Governance / rewards	Execute approved proposals or funded distributions	Voting concentration, bugs and rule manipulation
Analytics / reporting	Summarize public on-chain activity	Labels and dashboards may be incomplete or inaccurate

On-chain versus off-chain

Only data that benefits from public verification should be placed on-chain. Personal data, private messages, identity documents and confidential community information should not be published to an immutable public ledger. Wallet addresses and transaction histories may be public and can sometimes be linked to individuals.

Network selection

Before launch, compare transaction fees, reliability, ecosystem tooling, wallet support, explorer quality, upgrade dependencies, bridge risk and the experience of intended users. A low fee alone is not enough. The selected network and chain ID must be stated consistently across the website, whitepaper and contract deployment.

Reference standard

If an EVM-compatible chain is selected, a standard fungible-token interface such as ERC-20 may be appropriate. The exact standard, compiler version, library versions and any deviations must be disclosed. The standard itself is not a security audit.

7. Blockchain and smart-contract design

Proposed contract modules

• Token contract: balances, transfers, supply behavior and any permitted administrative controls.
• Distribution contract or documented wallet allocations: records token distribution under published rules.
• Vesting contract, if needed: releases specified allocations on a defined schedule.
• Treasury controls: multisignature custody and, where appropriate, a timelock for material actions.
• Rewards or governance contracts: optional modules only after separate specification, testing and review.

Administrative powers

Any minting, pausing, blacklisting, fee-setting, upgrade or recovery power must be described in plain language and be visible in the verified deployment. If no such power exists, the team should prove that through verified code and deployment configuration. If a power exists, identify who controls it and how misuse is constrained.

Deployment requirements

6. Freeze the specification and token parameters before accepting public funds.
7. Use established libraries and reviewed patterns rather than custom cryptography or unnecessary custom token logic.
8. Test edge cases, access control, transfers, vesting, allocation caps and emergency behavior.
9. Publish verified source code, compiler settings, constructor parameters and the contract address.
10. Commission an independent audit or review appropriate to the code’s complexity and disclose unresolved findings.
11. Reproduce the deployment from a documented release package and verify treasury and allocation addresses.

NO AUDIT CLAIM WITHOUT EVIDENCE Do not use phrases such as “audited,” “secure,” or “rug-proof” unless the exact scope, auditor, report date and unresolved findings are publicly available. An audit does not eliminate all risk.

8. Tokenomics framework

Tokenomics must be finalized before launch and must reconcile to a single maximum supply or clearly defined variable-supply policy. The values below are intentionally marked TBD because no approved token parameters were supplied.

Parameter	Current status	Required publication
Token name	LeonidaCity Coin (working name)	Confirm naming and legal / IP review
Ticker	$LC	Check availability and publish exact ticker
Blockchain / chain ID	TBD	Network, chain ID and explorer
Decimals	TBD	Exact deployed value
Maximum supply	TBD	Numeric cap and enforcement mechanism
Mint authority	TBD	Disabled or clearly defined permissions and limits
Initial circulating supply	TBD	Calculation method and source wallets
Transaction taxes / fees	Not specified	State explicitly if zero; otherwise exact rates and controls
Contract address	Not deployed / not supplied	Publish only after verified deployment

Allocation schedule (template only)

Category	Target %	Token quantity	Unlock / control
Presale	TBD	TBD	Funded schedule and eligibility rules
Liquidity	TBD	TBD	Custody, lock terms if any, and verifiable evidence
Treasury / operations	TBD	TBD	Multisig, spending policy and reporting
Contributors / team	TBD	TBD	Named category, vesting and conflict disclosure
Public distribution	TBD	TBD	Price, caps, eligibility and sale terms if applicable
Reserve / ecosystem	TBD	TBD	Purpose, authorization and release rules
TOTAL	100%	Must equal maximum supply	All categories reconciled

This table is a planning template, not a recommended allocation. The final version must use actual numbers, state whether percentages are calculated from maximum supply, and show that categories do not overlap. Any unsold tokens, abandoned allocations or later treasury transfers require a published treatment.

Economic integrity

• Do not promise token price increases, fixed returns, guaranteed buybacks or guaranteed listings.
• Do not imply that a target market price is a reliable forecast.
• Publish the source and destination of any project-controlled token or liquidity wallet.
• Explain whether supply can change and who has the power to change it.
• Disclose any team, contributor or insider allocation and its vesting schedule.

9. Distribution, launch and sale safeguards

No presale or public sale is established by this document. If distribution or a sale is considered, its legal structure, terms, jurisdictional eligibility and consumer disclosures should be reviewed before funds are accepted.

Minimum sale specification

• Sale dates, time zone, accepted assets, price calculation and total cap.
• Wallet limits and any eligibility rules, including how they are enforced.
• Exact token allocation per purchase and any vesting or lockup.
• Treatment of failed transactions, cancellations, refunds and unsold inventory.
• Recipient wallet for proceeds, spending authority and reporting cadence.
• Applicable restrictions, risk warnings, fees and dispute contact.
• Clear notice that participation may result in a total loss.

Fair distribution controls

If the project chooses a sale, it should publish how purchases are recorded and how token allocations reconcile with the sale inventory. Any bonus must be budgeted inside the disclosed supply and must follow the same published release rules. Wallet limits alone cannot reliably establish one person per wallet.

Avoid misleading promotion

• Do not use countdowns, scarcity claims or “last chance” messaging unless accurate and substantiated.
• Do not claim an exchange listing is confirmed without a verifiable announcement from that exchange.
• Do not present influencer posts or paid promotion as independent endorsements.
• Do not describe a purchase as risk-free, guaranteed, or an assured route to profit.

10. Liquidity and market integrity

Liquidity, if any, depends on actual market participants and the arrangements that exist at launch. A project cannot guarantee that a holder will be able to sell at a particular price or at all.

Required disclosures

• Whether liquidity is planned, live, or absent.
• Which pool or venue is used, with verified links and contract addresses.
• Who controls liquidity-provider positions and whether any lock is independently verifiable.
• Whether project insiders can sell or transfer tokens and under what restrictions.
• Any market-making, treasury, buyback or fee arrangement, including conflicts of interest.

Do not describe liquidity as “locked” unless the relevant position, lock contract, duration, beneficiary and unlock conditions can be independently checked. Liquidity locks do not prevent every form of loss, manipulation or contract failure.

Market abuse and monitoring

The project should prohibit wash trading, fabricated volume, undisclosed paid promotion, insider misuse of material non-public information and coordinated deceptive activity. Public communications should avoid unsupported price targets and should correct material errors promptly.

11. Community governance and treasury

Governance approach

Early community polls may be advisory. Binding token-holder governance should not be implied until the voting mechanism, proposal thresholds, quorum, execution path and emergency powers are defined. Token-weighted voting can concentrate influence among large holders and can be affected by borrowed or temporarily acquired voting power.

Governance element	Must be defined
Proposal scope	Which community or treasury decisions can be proposed
Eligibility	Who may submit and vote; snapshot and anti-abuse rules
Quorum / thresholds	Minimum participation and approval requirements
Execution	Who carries out a decision and how execution is verified
Conflicts	Disclosure and handling of team / treasury conflicts
Emergency action	Who can intervene, under what narrow conditions, and how actions are reported

Treasury policy

• Publish treasury wallet addresses and the purpose of each wallet.
• Use a multisignature wallet with disclosed signer threshold where practical.
• Publish a spending policy, approval thresholds and regular transaction reports.
• Separate operational funds from community reward reserves and liquidity positions.
• Document key rotation, signer replacement, lost-key recovery and incident handling.

12. Security, privacy and risk management

Threat model

Risk	Possible control	Residual limitation
Fake token / impersonation	Verified contract links and official channel list	Lookalike accounts and malicious sites can persist
Compromised admin key	Multisig, hardware-backed custody and role separation	Signer collusion or multiple compromised devices remains possible
Contract exploit	Standard libraries, testing and independent audit	Audits cannot prove absence of all defects
Phishing / wallet drain	Transaction education and domain protection	Users may still approve malicious transactions
Treasury misuse	Public wallets, spending rules and reconciliation	Transparency detects some actions but may not prevent them
Concentrated ownership	Publish holder distribution and governance limits	Public addresses may represent multiple parties or custodians
Regulatory / IP challenge	Specialist legal review and independent branding	Rules differ by jurisdiction and can change
Market loss / low liquidity	Risk disclosure and no return promises	Users can lose some or all of their purchase value

Incident response

12. Provide a verified channel for reporting suspected scams or vulnerabilities.
13. Assess severity and preserve relevant evidence without exposing user secrets.
14. Use only documented emergency powers; explain any pause or restriction publicly.
15. Notify affected users promptly when a material incident is confirmed, subject to legal obligations.
16. Publish a post-incident report with impact, timeline, remediation and unresolved issues.

Privacy basics

A public blockchain is not a private database. Wallet addresses, balances and transfers may be visible and can be analyzed. The project should collect the minimum personal information necessary, publish a privacy notice for any website or event registration, and never request wallet seed phrases or private keys.

13. Legal, intellectual-property and compliance considerations

Independent fan project positioning

LeonidaCity Coin should be presented as an independent community concept. GTA, Grand Theft Auto VI, Rockstar Games, Take-Two Interactive and related names, logos, characters and artwork may be protected by trademark, copyright or other rights. Their mention here is descriptive and does not imply sponsorship, approval, licensing or partnership.

• Use original visual identity and artwork; do not copy official logos, game screenshots, character art or promotional assets without permission.
• Do not name a website, token or social account in a way that is likely to confuse users into believing it is official.
• Place the independent-status disclaimer near prominent branding, wallet links and any token acquisition page.
• Seek legal advice on project naming, promotional materials, token distribution and use of references to the game before public launch.
• Remove or revise material if a rights holder raises a substantiated concern; do not claim legal clearance without counsel's review.

Token and consumer-law review

The legal treatment of a token depends on its design, marketing, distribution, rights, purchaser expectations and the jurisdictions involved. This paper does not determine whether the token is a security, financial instrument, crypto-asset or regulated product. Specialist counsel should review the proposed activity, including any sale, rewards, staking, exchange promotion, custody or cross-border distribution.

Required pre-launch review

• Entity and responsible-party details, or a clear explanation of the project's accountability model.
• Terms of use, privacy notice, risk disclosures and support / complaints contact.
• Applicable registration, licensing, marketing, tax and consumer-protection requirements.
• Sanctions and geographic restrictions where legally required.
• Intellectual-property and naming review, including confusion and endorsement risk.

14. Roadmap and acceptance criteria

The roadmap below is a proposed sequence, not a promise of dates or delivery. Each phase should be considered complete only when its evidence is published.

Phase	Workstream	Exit criteria
1. Definition	Confirm purpose, audience, name, legal review and token necessity	Approved specification, documented risks and clear project accountability
2. Community foundation	Launch information hub and official-channel directory	Independent-status notice, moderation rules and scam reporting route
3. Technical design	Select network and finalize token parameters	Reconciled tokenomics, threat model and deployment plan
4. Test deployment	Deploy to test environment and test user flows	Reproducible tests, verified configuration and no unresolved critical defects
5. Independent review	Review contract, website and operational controls	Public report and documented remediation of material findings
6. Controlled launch	Launch only if approved and legally cleared	Verified contract, published terms, wallet disclosures and incident plan
7. Ongoing operations	Report treasury, governance and security activity	Regular reports, change history and accountable support

Release gates

• No public token sale before token parameters and terms are finalized.
• No “audited” claim before the report and scope are published.
• No game integration claim without written authorization and a working verified integration.
• No reward or staking feature before its funding source, rules and contract are tested.
• No claim of decentralization without identifying and documenting privileged roles.

15. Transparency and reporting

The project should maintain one canonical source of truth for token information. The same chain, ticker, contract address, supply, allocation and risk disclosures should appear consistently across the whitepaper, website and community channels.

Disclosure	Suggested cadence / trigger
Contract and token parameters	At launch and after any approved change
Treasury and allocation wallet report	Monthly, or another stated regular interval
Governance proposals and outcomes	For each proposal
Reward program accounting	Each distribution cycle
Security reviews and fixes	On publication and material remediation
Incidents and emergency actions	As soon as responsibly possible after confirmation
Whitepaper changes	Versioned log with date and summary

Reports should distinguish on-chain facts from team-provided labels and estimates. If a wallet is said to belong to the treasury, publish the evidence or explain the attribution method. Corrections should be dated rather than silently overwriting material history.

16. Decisions required before launch

The following decisions remain open based on the information available for this draft. They should be assigned to accountable owners and resolved before the whitepaper is presented as a final launch specification.

Decision	Status
Final project name and naming / IP review	Open
Ticker availability and exact token name	Open
Chosen blockchain and chain ID	Open
Maximum supply, decimals and mint policy	Open
Allocation percentages and token quantities	Open
Team / contributor allocation and vesting	Open
Liquidity plan and custody	Open
Treasury signers, threshold and spending policy	Open
Token contract implementation and audit	Open
Utility features and delivery owners	Open
Sale terms, eligibility and jurisdictional review	Open / no sale asserted
Website, privacy notice, terms and support channel	Open
Launch date and launch readiness evidence	Not set

Appendix A. Glossary

Term	Meaning
Blockchain	A shared ledger maintained by a network of participants.
Smart contract	Code deployed to a blockchain that executes defined rules.
Token supply	The quantity of tokens issued or permitted under the supply policy.
Circulating supply	A defined estimate of tokens available in the market; methodology matters.
Multisignature wallet	A wallet requiring a specified number of authorized signers to approve actions.
Vesting	A schedule that restricts when an allocation can be transferred or claimed.
Liquidity	The ability to trade without causing a large price impact; it is not guaranteed.
Governance	The process for proposing, deciding and executing community or protocol changes.
Audit	A scoped review of code or controls; it cannot guarantee that no vulnerabilities exist.
TBD	To be determined; the parameter is not yet confirmed.

Appendix B. Publication checklist

• ☐ Independent fan/community status is visible near the title and token acquisition links.
• ☐ Project name, ticker and domains have been checked for availability and IP risk.
• ☐ Token parameters are final, internally consistent and reconciled to 100% allocation.
• ☐ Network, chain ID, contract address and explorer links are verified.
• ☐ Contract source and compiler settings are published.
• ☐ Privileged roles, treasury signers and liquidity arrangements are disclosed.
• ☐ Security review scope and unresolved findings are disclosed accurately.
• ☐ Utility features are live or explicitly labeled as proposed.
• ☐ Sale terms, eligibility, risk warnings and refund conditions are reviewed where applicable.
• ☐ Terms of use, privacy notice, support and scam-reporting channels are live.
• ☐ Claims about GTA VI, Rockstar Games or Take-Two do not imply endorsement or integration.
• ☐ Roadmap and metrics avoid unsupported dates, guarantees and performance claims.
• ☐ Document version, date and change log are maintained.

Version history

Version	Date	Changes
0.1	10 October 2026	Initial concept whitepaper; unconfirmed parameters marked TBD

Disclaimer

This document is a conceptual draft for discussion. It is not an offer to sell or a solicitation to buy any asset. It is not investment, legal, tax or financial advice. Digital assets are volatile and may become worthless. No statement in this document should be interpreted as a promise of profit, official game affiliation, a working product, a future listing or guaranteed utility. All proposed features and token parameters remain subject to implementation, verification and applicable review.