Vision, Technology, Economics, and On-Chain Mechanics

Summary

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
• 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)

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.

Contract Links

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