Vision, Technology, Economics, and On-Chain Mechanics

The text below is rendered as a preserved reading document. We are keeping the actual wording instead of summarizing it away.

4TEEN Whitepaper
Version 1.2
Date: 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
Abstract
Introduction
Token Overview
Supply Model
Price Logic
Token Locking
TRX Flow on Purchase
Liquidity Architecture
Liquidity Execution
DEX Executors
Vault Architecture
Governance
Frontend Disclaimer
Security Considerations
What 4TEEN Is Not
Verification

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.