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 Logic
• DEX Executors
• Liquidity Automation
• Ambassador System
• Vault Architecture
• Governance & Permissions
• Frontend Disclaimer
• Security Considerations
• What 4TEEN Is Not
• Verification

Abstract

A modular on-chain token system with explicit rules and separated operating layers.

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

The system combines a TRC-20 token contract, a dedicated liquidity controller, DEX-specific executor contracts, purpose-separated vaults, GitHub Actions–based liquidity automation, and a full-stack ambassador reward system centered around controller-side settlement.

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 an 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. Algorithmic price growth applies only to direct contract purchases and does not control secondary market trading.

1. Introduction

The protocol is built to be inspectable, not interpreted.

4TEEN is an on-chain token mechanism with deliberately narrow and explicit functionality. Its purpose is not to simulate a financial product. Its purpose is to create a transparent, verifiable framework for token issuance, transfer restriction, liquidity formation, attribution, and staged ecosystem distribution, all enforced by code.

Unlike custodial or off-chain systems, 4TEEN does not rely on vague promises, hidden bookkeeping, or informal operator discretion for its core behavior. Token minting, direct purchase pricing, purchase locks, fund routing, liquidity scheduling, and reward allocation logic are all defined at the smart contract or infrastructure layer and can be independently inspected.

This document describes the system as it exists in its currently deployed form. Features, guarantees, or assumptions not explicitly enforced by the code are outside the scope of the protocol.

4TEEN does not solve price discovery, market stability, or investment performance. Secondary market behavior remains external to the protocol and is determined by participants interacting with TRON market infrastructure.

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 remains intentionally focused. It handles issuance, balances, allowances, transfer restrictions, available-balance validation, and deterministic TRX routing. It does not directly execute DEX interactions or attempt to control market price.

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 in the deployed system.

3.2 Mint-on-Purchase Issuance

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

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 transferable or liquid. Locked balances and vault-reserved balances may still be visible on-chain while remaining mechanically restricted by protocol logic.

Supply integrity is contract-enforced. The system does not allow arbitrary owner minting, retroactive 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 direct 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 liquidity, trading activity, and demand.

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

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, netted, or rewritten by later purchases.

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 every time a transfer or delegated transfer is attempted.

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 later through transfers are not retroactively locked by this rule.

6. TRX Flow on Purchase

Every direct buy routes value atomically by rule

90% TRX

Liquidity System

Forwarded to FourteenLiquidityController for scheduled release and DEX execution flow.

7% TRX

Controller Layer

Forwarded to FourteenController for control, attribution, reward accounting, and ambassador settlement logic.

3% TRX

Airdrop Layer

Forwarded to AirdropVault for staged ecosystem distribution and campaign infrastructure.

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

The token contract does not treat purchase proceeds as one undifferentiated balance. The protocol separates liquidity, control, and community-distribution value at the point of entry.

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 permissionless, but not automatic and not unconditional. All liquidity actions require an explicit on-chain execution that still satisfies controller-side rules.

8. Liquidity Execution Logic

Daily release with hard conditions

Execution conditions

• Execution has not already occurred for the current UTC day
• Controller balance meets the minimum threshold of 100 TRX
• A valid on-chain execution call is made

Release formula

Daily release amount:

6.43% of the controller’s current TRX balance

Because the release is percentage-based, the absolute liquidity amount adjusts as controller balance changes.

Single-execution protection

The controller enforces a once-per-UTC-day execution boundary. This means liquidity cannot be accelerated by repeated calls inside the same day.

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
• Manages execution through Sun-compatible concentrated liquidity flow

LiquidityExecutorJustMoney

• Reads reserve balances from the pool
• Calculates proportional token amount
• Adds liquidity through the AMM router
• Handles JustMoney-specific pool interaction logic

Executors do not decide timing or release size. They implement already-approved liquidity through DEX-specific market infrastructure.

10. Liquidity Automation

Automation keeps the system moving. The contract still decides what is allowed.

The 4TEEN liquidity automation repository is the external execution layer responsible for running the daily liquidity operation. It does not define policy and it does not loosen contract-side constraints. Its role is operational: detect when execution is available, submit the transaction, wait for confirmation, and publish the result.

The actual rules remain on-chain inside the liquidity infrastructure. The automation can trigger execution, but it cannot bypass controller-side timing limits, minimum-balance requirements, or permanent execution recording. That separation keeps the system active without turning the automation layer into a source of arbitrary power.

On-chain execution layer

• Execution can occur only once per UTC day.
• Execution requires the controller to satisfy minimum balance conditions.
• All successful execution results are recorded permanently on-chain.
• If contract conditions are not met, execution does not occur.

Automation layer

• Checks execution availability.
• Calls bootstrapAndExecute() on the Liquidity Bootstrapper contract.
• Waits for transaction confirmation.
• Collects execution data and publishes the result to notification surfaces.

Operational model

The automation runs through GitHub Actions. This provides a continuous execution layer without forcing the protocol to rely on daily manual interaction.

Even so, the system remains permissionless at the execution edge. If the daily operation has not yet occurred and the contract conditions are satisfied, anyone may still trigger it manually. That fallback matters because it keeps continuity decentralized even if the automation layer is temporarily interrupted.

Execution flow

• Connect to TRON through TronGrid.
• Trigger bootstrapAndExecute().
• Wait for transaction confirmation.
• Collect and publish the execution result.

Transparency

Every successful execution remains publicly verifiable through transaction data and public market explorers. The automation improves continuity, but verification still lives on-chain.

{
  "ok": true,
  "result": "SUCCESS",
  "txid": "transaction_hash",
  "tronscan": "https://tronscan.org/#/transaction/..."
}

Positioning: liquidity automation is part of the operating infrastructure, not part of the rule-making layer. It triggers the routine. The contract determines whether the routine is valid.

11. Ambassador System

A full-stack acquisition, attribution, and reward settlement system.

The 4TEEN Ambassador System is not a lightweight referral add-on. In its current form, it is a multi-layer operating system for ambassador identity, first-touch attribution, purchase verification, backend allocation, cabinet visibility, and on-chain reward settlement.

Its most accurate current description is a TRON-based full-stack ambassador platform built around first-touch referral capture, on-chain registration, a cabinet/dashboard layer, and a resource-aware backend worker that can defer settlement safely when blockchain resources are limited.

Frontend and cabinet layer

• Captures ?r=slug on first touch and stores it for the configured TTL window.
• Validates and normalizes slug identity before registration.
• Registers ambassadors on-chain through Tron wallet connection.
• Submits attribution after successful purchase.
• Presents cabinet data such as rewards, pending sync state, processing requests, purchase counts, and withdrawal history.

Worker and settlement layer

• Verifies purchase data and attribution integrity.
• Decides whether to allocate immediately or defer safely.
• Preserves verified purchase data off-chain when Energy or Bandwidth is insufficient.
• Prepares ambassador withdrawals and replays deferred purchases later.
• Runs daily maintenance, queue processing, and recovery workflows.

Business model and attribution logic

The current architecture follows a first-touch attribution model before the buyer’s first successful purchase. Referral source can be captured before the buy, verified purchase data can be preserved off-chain first, and the blockchain acts as the final reward settlement layer.

This makes the system operationally safer than a naive immediate-write model. If resources are available, allocation may happen eagerly. If resources are constrained, verified purchase state can remain preserved and be finalized later without losing attribution continuity.

Why the cabinet matters

The cabinet is not decoration and it is not a marketing-only dashboard. It is the ambassador-facing operational surface that connects identity, reward state, pending processing, withdrawal preparation, and visible settlement history into one continuous workflow.

In practical terms, the system continues after registration. Registration opens the path. Cabinet and worker logic keep that path alive.

On-chain controller settlement

The final settlement layer is implemented through FourteenController. The contract supports ambassador registration, slug ownership, buyer binding, verified purchase allocation, level management, reward accrual, and reward withdrawal.

It also supports both auto-derived levels and manual override logic, which keeps the reward layer flexible without making it unreadable or hidden.

Ambassador reward ladder

• Bronze: 0–9 buyers → 10%
• Silver: 10–99 buyers → 25%
• Gold: 100–999 buyers → 50%
• Platinum: 1000+ buyers → 75%

Claim-first strategy

The ambassador system is built for operational safety, not only for immediate settlement. Verified purchases may be accepted and stored first, then settled on-chain later when resource conditions allow.

Positioning: this system is best understood as four connected layers working together — frontend referral capture and registration, ambassador cabinet, backend allocation worker, and on-chain controller settlement. It is not just a referral helper, not just a dashboard, and not just a worker.

12. Vault Architecture

Purpose-separated reserve custody

FourteenVault

Stores tokens reserved for liquidity provisioning and keeps them separate from team and airdrop reserves. The documented liquidity reserve funding reference is 2,000,000 4TEEN.

TeamLockVault

Stores team allocation under separate custody and lock-oriented logic rather than mixing it with operational balances. The documented team funding reference is 3,000,000 4TEEN.

AirdropVault

Stores community and growth reserves for staged ecosystem distribution campaigns. The documented community allocation reference is 1,500,000 4TEEN.

Vaults do not mint tokens, rewrite balances, or override price and lock rules. Their role is reserve custody, separation of allocation logic, and reduction of unnecessary coupling between protocol layers.

13. 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.

14. 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.

15. 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, vaults, and operating layers are intentionally separated.
• Permissionless execution still remains bounded by timing and balance rules.
• There are no hidden admin backdoors for arbitrary minting or silent balance editing.
• DEX interaction risk is isolated away from the core token logic wherever practical.

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

16. 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.

17. Verification

The system is strongest when it can be checked from multiple angles.

4TEEN is not meant to be trusted through design language alone. Its contract architecture, repositories, operational infrastructure, and public documentation form a verification surface that can be inspected independently.

Core verification routes

• Public TRON explorer pages for token, controller, liquidity, and vault contracts
• Open repositories for smart contracts, wallet kit, ambassador system, liquidity automation, and Telegram airdrop bot
• Whitepaper, tokenomics, and blog as the public reading layer

Verification philosophy

A serious protocol should become stronger the moment a user leaves the landing page to inspect it. 4TEEN is designed around that principle: outward verification, separated system layers, and observable behavior.

Final principle: if a behavior is not explicitly described here and not enforced by deployed code, it is not defined by the 4TEEN protocol.