4TEEN is a modular on-chain token system deployed on the TRON blockchain.

It is designed as a mechanical smart contract architecture that governs token issuance, time-based locking, and gradual liquidity formation through transparent and verifiable on-chain rules.

The system consists of a TRC-20 token contract, a dedicated liquidity controller, multiple DEX-specific liquidity executors, and a set of purpose-separated vault contracts. Each component operates independently and interacts only through predefined on-chain interfaces.

Token supply follows a hybrid model: an initial owner supply minted at deployment, combined with mint-on-purchase issuance for users. New tokens are created only when users interact with the token contract by sending TRX. There is no fixed maximum supply, no burn mechanism, and no emissions unrelated to direct user interaction.

Purchased tokens are subject to a mandatory 14-day on-chain lock. Locks are enforced at the contract level, apply per purchase, and cannot be bypassed, modified, or manually unlocked by any administrative entity.

Liquidity formation is governed by a two-layer architecture. Funds allocated to liquidity are accumulated first and then released gradually according to strict time and balance conditions. Liquidity execution is permissionless but not automatic and not guaranteed. All liquidity actions require explicit on-chain execution and are fully auditable.

This document describes the current deployed state of the 4TEEN system as it exists on-chain.

It does not describe future plans, guarantees, or financial expectations.

The 4TEEN token itself does not generate profit.

Market price is determined independently by liquidity and demand.

Algorithmic price growth applies only to the contract purchase price and does not affect secondary market prices.

The 4TEEN system is designed as an on-chain token mechanism with clearly defined and limited functionality. Its primary objective is to provide a transparent and verifiable framework for token issuance, transfer restrictions, and liquidity formation, enforced entirely by smart contracts.

Unlike off-chain financial products or custodial systems, 4TEEN does not rely on discretionary management, external promises, or manual intervention for its core operations. All critical behaviors — including token minting, locking, price adjustment for primary sales, and liquidity execution rules — are defined at the contract level and can be independently verified on the blockchain.

This document serves as a technical and structural description of the 4TEEN system in its currently deployed form. It focuses exclusively on what is implemented and enforceable by code. Features, behaviors, or guarantees not explicitly defined in the smart contracts are intentionally excluded.

4TEEN does not attempt to solve price discovery, market stability, or investment performance. Market dynamics such as price fluctuations, trading volume, and demand are external to the protocol and are determined by participants interacting with decentralized exchanges.

The system is intentionally modular. Token logic, liquidity scheduling, DEX execution, and token allocations are separated into distinct contracts. This separation reduces coupling, limits the impact of potential failures, and allows each component to be inspected and reasoned about independently.

This whitepaper should be read as a descriptive specification, not a roadmap.

It explains how the system behaves, not what it aims to achieve financially.

The core component of the system is the Fourteen Token (4TEEN), a transferable on-chain token implemented under the TRC-20 standard on the TRON blockchain.

Token parameters:

The token contract is deployed and verifiable on-chain. All balances, transfers, and supply figures referenced in this document correspond to the live contract state as indexed by public blockchain explorers.

4TEEN is a smart contract–based digital asset. It does not represent equity, debt, ownership rights, profit-sharing arrangements, or claims on any off-chain assets. Holding 4TEEN does not grant governance authority, dividends, or guaranteed economic outcomes.

The token follows the standard TRC-20 interface for:

ensuring compatibility with wallets, explorers, and decentralized exchanges within the TRON ecosystem.

In addition to standard TRC-20 behavior, the 4TEEN token enforces protocol-level transfer restrictions. These restrictions are applied automatically and validated on-chain during every transfer or transferFrom operation. If transfer conditions are not met, the transaction reverts and cannot be executed.

The token contract is intentionally limited in scope. It does not:

Its responsibilities are strictly confined to:

All other system functionality — including liquidity scheduling, liquidity execution, and allocation management — is implemented in separate contracts and operates independently of the token contract.

This separation ensures that the token logic remains minimal, predictable, and auditable, with no implicit behavior beyond what is explicitly defined in its deployed code.

The 4TEEN token uses a hybrid supply model that combines an initial owner supply with on-demand minting triggered by direct user interaction. This model is fully enforced on-chain and does not rely on off-chain accounting or discretionary issuance.

3.1 Initial Supply

At deployment, an initial supply of 10,102,022 4TEEN was minted to the contract owner.

This supply exists on-chain and is visible via public blockchain explorers.

The initial supply:

There are no hidden allocations or deferred minting events beyond what is explicitly visible on-chain.

3.2 Mint-on-Purchase Issuance

In addition to the initial supply, new 4TEEN tokens are minted only when users interact with the token contract via the buyTokens() function and send TRX.

Key properties:

There is no fixed maximum supply. Total supply expands only in response to direct user interaction with the contract.

3.3 Absence of Emissions and Burn

The 4TEEN system does not implement:

Token supply does not change due to time, block production, or protocol-driven rewards. Supply growth is strictly demand-driven.

3.4 Circulating Supply Clarification

Public blockchain explorers may display total supply and circulating supply as equal values. This reflects the fact that all minted tokens exist on-chain and are not segregated by explorer-specific definitions.

However, on-chain existence does not imply immediate liquidity or transferability.

Tokens held in vault contracts or subject to time-based locks may be:

Transferability and liquidity are governed by smart contract rules, not by off-chain supply classifications.

3.5 Supply Integrity

The token contract does not allow:

All supply changes are traceable, deterministic, and verifiable on-chain.

The 4TEEN system implements an on-chain price mechanism that applies exclusively to primary token purchasesexecuted through the token contract. This price logic does not reference, influence, or depend on secondary market prices.

4.1 Base Purchase Price

At deployment, the token contract was initialized with a base purchase price equivalent to:

1 TRX = 1 4TEEN

This base price is stored on-chain as a mutable state variable and is used solely for calculating the amount of tokens minted during a direct purchase.

4.2 Algorithmic Price Growth

The purchase price is subject to an algorithmic growth mechanism with the following parameters:

Price updates are executed lazily. The contract does not update the price continuously. Instead, accumulated growth is applied only when the price is queried or when a purchase occurs.

If multiple growth intervals have elapsed since the last update, the contract applies all missed intervals in sequence within a single transaction.

4.3 Scope and Limitations

The price mechanism described above:

Secondary market prices are formed independently through trading activity and liquidity conditions on decentralized exchanges.

4.4 No Manual Price Control

The scheduled price growth is enforced by code. No manual intervention is required for routine price updates.

While the contract owner retains the ability to modify the growth rate parameter, such changes:

4.5 Price Logic Disclaimer

The purchase price mechanism is a deterministic calculation, not a financial promise.

Algorithmic price growth does not imply profit, yield, or guaranteed return.

Market price behavior remains entirely external to the protocol.

The 4TEEN system enforces a mandatory, on-chain token locking mechanism applied to all tokens acquired through direct purchases from the token contract. This mechanism is designed to restrict immediate transferability and is fully enforced at the smart contract level.

5.1 Lock Creation

Each time a user purchases 4TEEN tokens via the buyTokens() function, a new lock entry is created on-chain.

Key characteristics:

5.2 Lock Duration

All purchased tokens are locked for a fixed duration of:

14 days from the time of purchase

The lock period is calculated using the block timestamp at the moment of purchase. Unlocking occurs automatically when the lock duration has elapsed. No external action is required to release locked tokens.

5.3 Transfer Enforcement

The token contract enforces transfer restrictions by validating the sender’s available balance at the time of every transfer or delegated transfer.

The transferable balance is calculated as:

If a transfer attempt exceeds the available (unlocked) balance, the transaction reverts and cannot be executed.

This enforcement applies equally to:

5.4 No Administrative Override

The locking mechanism cannot be bypassed, modified, or manually overridden.

Specifically:

All locks are time-based and enforced deterministically by the contract code.

5.5 Purpose and Implications

The locking mechanism is intended to:

The lock does not prevent users from holding tokens, viewing balances, or transferring unlocked portions of their balance once available.

5.6 Locking Disclaimer

Token locks apply only to tokens minted through direct purchases from the contract. Tokens obtained through transfers or other means are not subject to retroactive locking unless explicitly transferred into contracts that impose additional restrictions.

The presence of a lock does not imply vesting, yield, or future value.

Liquidity Model

4TEEN’s liquidity structure is built on three principles:

When a user purchases 4TEEN tokens through the token contract, the TRX sent with the transaction is distributed automatically according to predefined on-chain rules. This distribution is executed within the same transaction and does not rely on off-chain processes.

6.1 Distribution Structure

Upon execution of the buyTokens() function, the received TRX is split as follows:

These percentages are:

The full transaction amount is distributed, and no TRX remains idle in the token contract as a result of a purchase.

6.2 Liquidity Allocation

The portion allocated to liquidity (90%) is forwarded directly to the liquidity system address defined in the token contract. This address does not add liquidity immediately and does not interact with decentralized exchanges directly.

Instead, allocated funds are accumulated and later processed according to the liquidity scheduling rules described in subsequent sections of this document.

6.3 Operational Allocation

The operational share (7%) is forwarded to the contract owner’s address. This allocation is intended to support system operation and maintenance.

This allocation:

6.4 Airdrop Allocation

The remaining portion (3%) is forwarded to a designated airdrop address. Funds received by this address are intended for community distribution mechanisms defined outside the token contract itself.

The token contract does not impose any restrictions on how the airdrop address manages received funds beyond standard on-chain transfer rules.

6.5 Atomic Execution and Safety

All TRX transfers described above occur atomically within the purchase transaction. If any transfer fails, the entire transaction reverts and no tokens are minted.

This ensures:

Liquidity in the 4TEEN system is governed by a deliberately separated, two-layer on-chain architecture. This design isolates token issuance from liquidity execution and ensures that no single contract has direct control over the full liquidity process.

The purpose of this architecture is to provide predictability, transparency, and controlled liquidity formation without relying on automatic or discretionary execution.

7.1 Layer One — Token Contract

The token contract is responsible for receiving TRX from users during primary purchases and forwarding the liquidity-designated portion of funds according to predefined rules.

Key characteristics of Layer One:

The token contract has no awareness of market conditions, pool states, or execution timing. Its role in liquidity is strictly limited to deterministic fund forwarding.

7.2 Layer Two — Liquidity Controller

The second layer consists of a dedicated liquidity controller contract. This contract is responsible for holding accumulated liquidity funds and enforcing when and how much liquidity may be released.

The liquidity controller:

Liquidity execution through the controller is permissionless, meaning any network participant may trigger execution when conditions are met.

7.3 Execution Constraints

Liquidity execution is subject to strict on-chain constraints:

If execution conditions are not met or if no execution call is made, liquidity funds remain safely held within the controller contract.

7.4 Non-Automatic Liquidity Formation

Liquidity formation in the 4TEEN system is not automatic.

There are:

Liquidity formation depends on on-chain calls that satisfy contract-defined conditions. This design avoids forced execution, reduces systemic risk, and ensures that liquidity behavior remains transparent and auditable.

7.5 Architectural Implications

By separating liquidity accumulation from liquidity execution:

This two-layer model ensures that liquidity behavior is governed by code-defined rules rather than assumptions or off-chain coordination.

Liquidity execution in the 4TEEN system is governed by deterministic on-chain rules enforced by the liquidity controller contract. This logic defines when liquidity can be released, how much of the accumulated balance may be used, and how funds are dispatched for execution.

8.1 Execution Conditions

Liquidity execution is permitted only when all of the following conditions are met:

These conditions are validated by the controller contract at the time of execution. If any condition fails, the transaction reverts.

8.2 Daily Release Calculation

When execution is permitted, the controller calculates the amount of TRX to be released as liquidity based on the current balance.

The daily release amount is defined as:

6.43% of the controller’s current TRX balance

This percentage is applied dynamically. As the balance changes, the absolute release amount adjusts accordingly.

8.3 Single-Execution Enforcement

To prevent repeated or abusive execution:

This ensures that partial execution or reentrancy cannot be used to bypass timing restrictions.

8.4 Fund Dispatching

The calculated release amount is split deterministically into two portions:

Each portion is forwarded to a dedicated executor contract responsible for interacting with a specific decentralized exchange.

The controller does not:

Its role is limited to scheduling and dispatching funds.

8.5 Permissionless Triggering

Liquidity execution is permissionless. Any user may trigger execution when conditions are satisfied.

There is:

If no user triggers execution, funds remain in the controller contract until a valid call occurs.

8.6 Execution Safety

All execution logic is enforced within a single transaction. If any external call to an executor fails, the transaction reverts and no funds are released.

This guarantees:

DEX executors are specialized smart contracts responsible for interacting with decentralized exchanges on behalf of the liquidity system. They receive funds from the liquidity controller and execute liquidity provisioning according to DEX-specific logic.

This executor-based design isolates exchange-specific behavior from the core system and prevents DEX implementation details from affecting token issuance or liquidity scheduling.

9.1 Executor Pattern

All executors implement a unified execution interface and are called by the liquidity controller with a predefined amount of TRX.

Key characteristics:

The liquidity controller determines when and how much liquidity is released. Executors determine how that liquidity is applied on a given DEX.

9.2 Sun.io V3 Executor

The Sun.io V3 executor interacts with the Sun.io decentralized exchange using a concentrated liquidity model.

Execution behavior:

Key parameters:

The executor may either mint a new liquidity position or increase an existing one, depending on prior execution state.

9.3 JustMoney Executor

The JustMoney executor provides liquidity using a classic automated market maker (AMM) model.

Execution behavior:

Key parameters:

9.4 Executor Constraints

Executors:

If an executor cannot complete its operation due to missing liquidity, invalid pricing, or insufficient token balances, the execution reverts.

9.5 Replaceability and Isolation

Executors are replaceable at the controller level. This allows:

Replacing an executor does not affect:

The 4TEEN system employs a set of purpose-specific vault contracts to manage token allocations in a transparent and auditable manner. Vaults are used to separate distinct token functions and to reduce operational and governance risk by avoiding concentration of control within a single address.

All vault contracts are deployed on-chain, publicly verifiable, and funded through explicit token transfers. Their balances and activity can be independently inspected via blockchain explorers.

10.1 Design Rationale

The use of multiple vaults is intentional and based on the following principles:

Each vault serves a single, clearly defined purpose. Vaults do not mint tokens and do not alter global supply.

10.2 Airdrop Vault

The Airdrop Vault is designated for community distribution activities.

Characteristics:

The token contract does not enforce any specific airdrop logic. Distribution mechanisms, if any, are handled externally and are not guaranteed by the protocol itself.

10.3 Team Lock Vault

The Team Lock Vault is intended to hold tokens allocated for team-related purposes under controlled conditions.

Characteristics:

The existence of a team vault does not imply vesting schedules, unlock guarantees, or distribution timelines unless enforced by the vault’s own contract logic.

10.4 Fourteen Vault

The Fourteen Vault functions as a general-purpose system vault.

Characteristics:

This vault serves as an additional layer of structural separation between token ownership and protocol mechanics.

The Liquidity Bootstrapper is designed to support initial or auxiliary liquidity-related processes.

Characteristics:

Vaults:

Their role is limited to custody and separation of allocated tokens.

The 4TEEN system implements a limited and explicit governance model based on on-chain ownership controls. Governance in this context refers strictly to administrative permissions defined in the smart contracts and does not imply decentralized voting or token-based governance rights.

11.1 Ownership Model

Core contracts within the system implement a standard ownership pattern. Each contract has a single owner address responsible for performing predefined administrative actions.

Ownership is recorded on-chain and can be transferred only through explicit on-chain transactions.

11.2 Owner Permissions

The contract owner is permitted to perform the following actions:

These permissions are limited to configuration and operational maintenance. They do not grant the ability to alter fundamental system behavior retroactively.

11.3 Explicit Restrictions

The owner cannot:

All such restrictions are enforced at the contract level and cannot be overridden by administrative authority.

11.4 Liquidity Governance Constraints

The owner does not control liquidity execution timing. Liquidity execution:

While the owner may update executor addresses, such updates do not:

11.5 Absence of Token Governance

The 4TEEN token does not grant governance rights. Holding tokens does not confer voting power, proposal rights, or control over system parameters.

All governance is contract-based and role-limited.

11.6 Governance Disclaimer

Governance permissions are mechanical and defined strictly by code.

They do not imply discretionary control over outcomes, guarantees, or financial performance.

Any behavior not explicitly permitted by the smart contracts is not possible within the system.

All frontend interfaces associated with the 4TEEN system are provided for informational and interaction convenience only. Frontend applications do not possess authority over the protocol and cannot modify, override, or bypass smart contract logic.

12.1 Informational Nature

Frontend interfaces may display:

These values are derived from on-chain data and, in some cases, external data sources. They are intended to assist users in understanding their current state but are not authoritative.

12.2 No Contract Authority

The frontend:

All authoritative behavior is defined exclusively by deployed smart contracts.

12.3 External Data Sources

Certain frontend features may rely on:

Such data may be delayed, incomplete, or inaccurate. Discrepancies between frontend displays and on-chain state should always be resolved in favor of on-chain data.

12.4 User Responsibility

Users are responsible for verifying:

Interaction with the system occurs directly through smart contracts, regardless of the interface used.

12.5 Frontend Disclaimer

Frontend displays do not constitute guarantees, commitments, or representations of future behavior.

The smart contracts are the sole source of truth for the 4TEEN system.

Security in the 4TEEN system is achieved through explicit contract design choices, separation of responsibilities, and strict enforcement of on-chain rules. The system does not rely on off-chain controls or trusted intermediaries for its core behavior.

13.1 Deterministic Execution

All critical operations — including token minting, locking, fund distribution, and liquidity scheduling — are executed deterministically by smart contracts.

There are:

Each operation either executes fully or reverts entirely.

13.2 Reentrancy Protection

Functions that perform external calls and fund transfers are protected against reentrancy.

This ensures that:

13.3 Separation of Responsibilities

The system is intentionally modular:

This separation reduces the impact of potential vulnerabilities within any single component.

13.4 Permissionless Execution Constraints

While liquidity execution is permissionless, it is bounded by strict conditions:

Permissionless access does not equate to unrestricted control.

13.5 No Hidden Administrative Paths

The contracts do not include:

All administrative permissions are explicitly defined and visible on-chain.

13.6 External Dependency Risk

The system interacts with decentralized exchanges through executor contracts. These interactions depend on external protocols, which may carry independent risks, including:

Such risks are isolated from the core token logic and do not affect token balances or locking rules.

13.7 Security Disclaimer

While reasonable measures have been taken to reduce risk, smart contracts are subject to potential vulnerabilities and unforeseen behavior.

No security guarantees are implied.

Users interact with the system at their own discretion and responsibility.

To avoid misinterpretation, the following clarifications explicitly define what the 4TEEN system and token do notrepresent. These statements are intentional and binding with respect to how the system should be understood.

14.1 Not an Investment Product

4TEEN is not an investment instrument.

It does not:

Any economic outcome resulting from interaction with the token is driven by independent market activity, not by protocol guarantees.

14.2 Not Yield-Bearing

The 4TEEN token does not generate yield.

There are:

Token balances do not increase over time due to protocol behavior.

14.3 Not Price-Controlled

The protocol does not control or stabilize market prices.

Algorithmic purchase price logic:

Market prices are determined solely by liquidity and demand on decentralized exchanges.

14.4 Not Risk-Free

Interaction with the 4TEEN system involves risk.

Risks may include:

No insurance, guarantees, or protections are provided.

14.5 Not Centrally Managed

The system does not rely on discretionary, off-chain management.

Once deployed:

Operational actions do not equate to control over outcomes.

14.6 No Implied Promises

No statement in this document should be interpreted as:

All system behavior is constrained by deployed smart contracts.

The 4TEEN system is a fully on-chain, modular token architecture defined by deployed smart contracts. Its behavior is determined exclusively by code and executed through transparent, verifiable transactions on the blockchain.

This document describes the system as it exists, not as it may evolve. Any behavior, feature, or guarantee not explicitly defined in the deployed contracts is outside the scope of the protocol.

The 4TEEN token itself does not generate profit.

Market price depends on liquidity and demand.

Algorithmic price growth applies only to primary purchase calculations and does not affect secondary market prices.

No component of the system relies on trust-based assumptions. Token issuance, locking, liquidity scheduling, and fund flows are enforced mechanically and are observable on-chain.

This whitepaper should be read as a technical specification, not as a financial or promotional document. Participation in the system is voluntary and subject to the risks inherent in interacting with smart contracts and decentralized markets.

If a behavior is not explicitly described in this document and not enforced by the smart contracts, it is not defined by the 4TEEN system.

The following table lists the core on-chain components of the 4TEEN system and their corresponding TronScan links. All contracts and addresses shown below are deployed on the TRON blockchain and can be independently verified.

These links provide direct access to smart contract source code, balances, transaction history, and emitted on-chain events. The listed components reflect the current live state of the system.