4TEEN Whitepaper Version 1.2 • February 9, 2026

Vision, Technology, Economics, and On-Chain Mechanics

4TEEN is a modular TRON token protocol built around mint-on-purchase issuance, a fixed 14-day lock, controller-based ownership, and scheduled liquidity execution. This document describes the system as it exists on-chain today.

Token

4TEEN

TRC-20 token on TRON with 6 decimals.

Primary Entry

Mint

New tokens are created only through direct contract purchases.

Lock Rule

14D

Every direct purchase is locked for a fixed 14-day period.

Liquidity Rule

6.43%

Daily controller release, at most once per UTC day.

Table of Contents

Read the protocol in one pass

Abstract

A modular on-chain token system with explicit rules.

4TEEN is a TRON-based token protocol designed around transparent, mechanical behavior. Its core rules are enforced by smart contracts, not by off-chain discretion.

The system combines a TRC-20 token contract, a dedicated liquidity controller, DEX-specific executor contracts, purpose-separated vaults, and controller-side ambassador reward logic.

Supply follows a hybrid model: an initial owner allocation minted at deployment, plus mint-on-purchase issuance triggered only by direct user buys. If users do not buy through the token contract, no new tokens are created.

Every direct purchase creates a separate on-chain lock for 14 days. These locks are additive, deterministic, and cannot be bypassed or manually released by any administrative role.

Scope of this document
This whitepaper describes the current deployed state of the 4TEEN system. It is a technical and structural specification, not a promise of market outcome.

The 4TEEN token itself does not generate profit. Market price depends on liquidity and demand. The algorithmic purchase price affects only direct contract purchases, not secondary market trading.

1. Introduction

The protocol is built to be inspectable, not interpreted.

4TEEN is an on-chain token mechanism with deliberately limited and explicit functionality. Its purpose is to provide a transparent framework for token issuance, transfer restrictions, and liquidity formation enforced entirely by smart contracts.

Unlike custodial or off-chain financial products, 4TEEN does not depend on discretionary management for its core behavior. Token minting, purchase pricing, locking, fund routing, and liquidity scheduling are all defined at the contract level and can be independently verified on-chain.

This document focuses only on what is deployed and enforceable by code. Features, assumptions, or guarantees not explicitly implemented in the contracts are intentionally excluded.

The protocol does not solve price discovery or guarantee market stability. Market price, trading volume, and secondary market demand remain external to the system.

2. Token Overview

Fourteen Token (4TEEN)

Name	Fourteen Token
Symbol	4TEEN
Blockchain	TRON
Standard	TRC-20
Decimals	6
Issuing Time	November 23, 2025 (UTC)

4TEEN is a transferable on-chain token implemented under the TRC-20 standard. It does not represent equity, debt, governance power, dividends, or claims on off-chain assets.

The token contract stays intentionally narrow in scope. It handles issuance, balances, transfer restrictions, available-balance validation, and deterministic TRX forwarding. It does not directly execute DEX operations or read market prices.

What the token does

Issues tokens on deployment and on direct purchase.

Tracks balances and transfer allowances.

Creates and enforces per-purchase locks.

Routes incoming TRX according to hardcoded split rules.

What the token does not do

It does not interact with DEXes directly.

It does not depend on price oracles.

It does not manage liquidity positions.

It does not guarantee market price behavior.

3. Supply Model

Hybrid supply with on-demand expansion

3.1 Initial Supply

At deployment, 10,102,022 4TEEN were minted to the owner side of the system. This initial supply is visible on-chain and was created only once.

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

3.2 Mint-on-Purchase Issuance

New 4TEEN are minted only when a user calls buyTokens() and sends TRX to the token contract. Mint amount is determined by the contract purchase price at the time of execution.

If no direct purchases occur, no new tokens are created.

3.3 No Emissions, No Burn

No periodic emissions

No staking rewards

No yield-based minting

No burn mechanism

3.4 Circulating Supply Clarification

Explorer-visible total supply does not automatically mean all tokens are immediately liquid or transferable. Vault balances and locked balances may still appear on-chain while remaining mechanically restricted by contract logic.

Supply integrity is contract-enforced. The system does not allow arbitrary owner minting, forced balance edits, or silent redistribution of user-held tokens.

4. Price Logic

Primary sale price only

Base purchase price at deployment:
1 TRX = 1 4TEEN

4.1 Algorithmic Growth

The purchase price is subject to deterministic on-chain growth:

Annualized growth rate: 14.75%

Compounding interval: 90 days

Updates are applied lazily when queried or when a purchase occurs

4.2 Scope

This mechanism affects only the amount of 4TEEN minted through the contract purchase flow. It does not set, stabilize, or predict secondary market price.

Market price on DEXes remains independent and depends on trading activity and liquidity conditions.

The algorithmic purchase price is a deterministic contract calculation. It is not a guarantee of market appreciation, yield, or profit.

5. Token Locking Mechanism

Per-purchase locks enforced on-chain

5.1 Lock Creation

Every direct purchase through buyTokens() creates a separate lock entry for the buyer address. Locks are additive and independent. They are not merged or rewritten.

5.2 Lock Duration

Each lock lasts for a fixed 14 days from the block timestamp of the purchase.

5.3 Transfer Enforcement

The contract validates transferable balance at the time of every transfer or delegated transfer.

available balance = total balance − locked balance

If a transfer exceeds the unlocked amount, the transaction reverts.

No administrative override

No early owner unlock

No emergency unlock function

No privileged role with lock-control power

Locking clarification

The lock applies only to tokens minted through direct purchase. Tokens received through later transfers are not retroactively locked by this rule.

6. TRX Flow on Purchase

Every buy routes funds atomically by rule

90% TRX

Liquidity System

Forwarded to FourteenLiquidityController for scheduled release.

7% TRX

Controller Layer

Forwarded to FourteenController for control, attribution, and reward accounting.

3% TRX

Airdrop Layer

Forwarded to AirdropVault for staged ecosystem distribution.

This split is hardcoded and enforced within the purchase transaction itself. If any required transfer fails, the transaction reverts and no tokens are minted.

No TRX remains idle in the token contract as a result of a successful purchase.

7. Liquidity Architecture

A two-layer liquidity model

Layer One — FourteenToken

Receives TRX from direct purchases

Routes 90% to the liquidity system

Does not store liquidity funds long-term

Does not interact with DEXes directly

Layer Two — FourteenLiquidityController

Accumulates TRX forwarded by the token contract

Releases liquidity at most once per UTC day

Calculates release amount from current balance

Dispatches funds to DEX executors

Liquidity formation is not automatic. It is permissionless but still requires an explicit on-chain call that satisfies controller-side conditions.

8. Liquidity Execution Logic

Daily release with hard conditions

Execution conditions

Execution has not already occurred for the current UTC day

Controller balance meets minimum threshold

A valid on-chain execution call is made

Release formula

Daily release amount:
6.43% of the controller’s current TRX balance

The absolute release amount changes as controller balance changes.

Single-execution protection

Execution is restricted to once per UTC day, and the controller records the execution day before external calls are made.

Dispatch split

Released TRX is split equally between the two executor contracts: 50% to JustMoney and 50% to Sun.io V3.

9. DEX Executors

Exchange-specific execution, isolated from core logic

LiquidityExecutorSunV3

Reads current pool price from Sun.io V3

Calculates token amount dynamically

Adds liquidity in a concentrated-liquidity format

Operates with a 0.3% fee tier and a narrow tick range

LiquidityExecutorJustMoney

Reads reserve balances from the pool

Calculates proportional token amount

Adds liquidity through the AMM router

Applies slippage protection

Executors do not decide timing or release amounts. They only apply already released liquidity according to DEX-specific logic.

10. Vault Architecture

Purpose-separated reserve custody

FourteenVault

Stores tokens reserved for liquidity provisioning and keeps them separate from team and airdrop reserves.

TeamLockVault

Stores team allocation under separate custody and lock-oriented logic rather than mixing it with operational balances.

AirdropVault

Stores community and growth reserves for staged ecosystem distribution campaigns.

Vaults do not mint tokens, modify balances, or override pricing and lock rules. Their role is custody and separation of allocation functions.

11. Governance & Permissions

Administrative powers are explicit and limited

What ownership can do

Update annual purchase price growth rate

Update liquidity-related addresses

Update designated airdrop address

Perform explicitly allowed operational maintenance

What ownership cannot do

Mint tokens arbitrarily

Force-unlock user locks

Edit user balances retroactively

Manipulate secondary market prices

Holding 4TEEN does not confer governance rights. Governance in this system means contract-defined admin permissions only.

12. Frontend Disclaimer

The frontend is an interface, not the source of truth

Frontend may display

balances
locked and available amounts
countdown timers
estimated conversion rates
transaction history and live state summaries

Frontend cannot

unlock tokens
change contract rules
guarantee liquidity execution
guarantee price behavior
alter balances or supply

If frontend output and on-chain state ever differ, on-chain state is authoritative.

13. Security Considerations

Security by separation, constraints, and deterministic execution

Critical operations are deterministic and either execute fully or revert.

External-call paths that handle value use protection against reentrancy patterns.

Token, controller, executors, and vaults are intentionally separated.

Permissionless execution still remains bounded by timing and balance rules.

There are no hidden admin backdoors for arbitrary minting or balance editing.

DEX interaction risk is isolated away from the core token logic.

Smart contracts and DEX integrations still carry risk. No absolute security guarantee is implied.

14. What 4TEEN Is Not

Clarifications against misreading

Not an investment product

4TEEN does not promise returns, guaranteed appreciation, profit sharing, or exposure to off-chain revenue.

Not yield-bearing

There are no staking rewards, no interest, and no passive income mechanics tied to simply holding the token.

Not price-controlled

The protocol does not stabilize secondary market price. DEX price remains external to contract purchase logic.

Not risk-free

Users still face smart contract risk, market volatility, liquidity limitations, and external protocol dependency risk.

15. On-Chain Components & Verification

Main contracts and verification surface

These are the public components users can inspect directly through TRON explorers and the open repositories behind the product.

Core FourteenToken Core FourteenController Core FourteenLiquidityController Vault FourteenVault Vault TeamLockVault Vault AirdropVault Execution LiquidityBootstrapper Execution LiquidityExecutorSunV3 Execution LiquidityExecutorJustMoney

Public repositories

4teen-smart-contracts

4teen-wallet-kit

4teen-ambassador-system

liquidity-bootstrapper-cron

4teen-telegram-airdrop-bot

Final note

4TEEN should be read as a structured on-chain system. If a behavior is not defined by deployed code, it is not defined by the protocol.

Back to top Open Direct Buy