MarsLibertyCoin (MarsLC) — Whitepaper

1. Why BNB Smart Chain (BSC) first (launch rationale)

We chose BNB Smart Chain (BSC) for the first deployment because it balances liquidity, costs, infrastructure, and audience for a reserves-building token:

• Deep retail liquidity & reach. Large EVM user base and strong retail participation help with early price discovery and organic flow
• Multiple swap frontends. MarsLibertyCoin (MarsLC) has its primary liquidity on the PancakeSwap V2 pool, but users can access it from different interfaces (PancakeSwap V2, BogSwap (Bogged Finance), DODO, etc.). This widens reach without fragmenting liquidity
• Low transaction costs. Frequent small trades and treasury ops (sweeps, support-burns) don’t erode reserves
• Mature tooling. BscScan verification and widely supported wallets/infra simplify auditing and monitoring
• USDT availability. We anchor on USDT for on-chain accounting; BNB Smart Chain’s USDT is liquid and widely integrated

Architecture note: The project is hub-and-spoke multi-chain. The hub is on BNB Smart Chain (BSC); additional networks can be onboarded via Tranche B distributions and an external bridge adapter when liquidity and operations justify it.

2. What it is — the future money of Mars

We are building for decades. While humanity makes its way to Mars, MarsLibertyCoin (MarsLC) steadily accumulates substantial USDT reserves—both in Reserve Vaults (Whitebox) and in DEX liquidity pools. By the time “life on Mars” becomes reality, the community will have a token with deep, transparent USDT backing for everyday payments.

3. How every trade builds reserves — USDT-based backing

• A transparent fee is applied to each buy and sell
• Part of the fee is taken in MarsLC and burned; this increases the USDT share in pools (circulating MarsLC decreases)
• The rest of the fee is accumulated as MarsLC in the FeeCollector. On sells, the MarsLibertyCoin contract swaps that MarsLC to USDT (sent to the FeeCollector), and the FeeCollector automatically splits the USDT between the Reserve Vault (Whitebox) and the marketing wallet — this is how “hard” reserves grow
• Even sells feed the reserves: they support liquidity and increase the system’s USDT share
• All official LP tokens are burned (public, irrevocable liquidity)

4. Executive summary

• EVM multi-chain: hub on BNB Smart Chain (BSC); optional spokes on other EVM chains. Markets may expand beyond on-chain V2 DEX to V3 and CEX over time; non-EVM chains (e.g., Solana) would require a dedicated bridge and a separate token implementation
• DEX (on-chain): V2-only; one canonical MarsLC/USDT pair per chain (the pair is never fee-exempt)
• Stable: USDT is the only on-chain stable for protocol logic
• Fees (BUY/SELL): part of the fee is burned; the remainder is transferred as MarsLC to the FeeCollector, swapped to USDT, and split between the Reserve Vault (Whitebox) and the marketing wallet
• W2W: fee is taken in MarsLC (no burn); transferred to the FeeCollector, swapped to USDT, and split with the same Vault/Marketing ratio
• Support-burn: Vault USDT → buy MarsLC → burn
• Creator lock: 3M for 3 years; 100k claims under strict gates
• Additional emission: controlled low-float window; formula-capped
• Bridge: external adapter; token exposes mint/burn sockets
• Oracle: aggregates metrics; excludes bridge burns from economic burns

5. Standards & networks

• Token: ERC-20, 18 decimals
• DEX: PancakeSwap V2 liquidity pool (MarsLC/USDT pair) is the canonical base (one pair per chain). Trading is accessible via multiple front-ends (PancakeSwap V2, BogSwap (Bogged Finance), DODO, etc.). If markets expand to V3 DEXs and/or CEXs, such activity (when applicable) can be tracked off-chain by the Oracle
• USDT normalization: per-network decimals read on-chain; reporting normalized to 18 decimals
• Immutability: no proxy; configurable parameters via roles; contract is not upgradeable

6. Roles & permissions

• Authorized (admin): owner and creator (fees, distributions, support-burns, updates, thresholds)
• Fee-exempt by default: creator, marketing wallet, token contract, dead address, each network’s router, each network’s Reserve Vault (Whitebox), the FeeCollector (when set), and (if set) the bridge
• The V2 pair is never fee-exempt

7. Network config, pair & vaults

Per network, MarsLC stores: the router, USDT (and its decimals), the single canonical V2 pair, and that network’s Reserve Vault (Whitebox). The router and USDT can be updated; if either address changes, the canonical pair address is derived automatically. Liquidity is not migrated, and LP tokens are permanently burned. This is included as an emergency safeguard in case a router or USDT address must be replaced on a given network. The Reserve Vault (one Whitebox) per network is set during deployment or network registration; it is immutable thereafter, except for a one-time relink on the local (hub) chain within 24 hours after deployment.

8. Fees — purpose & current rates

Purpose

• Burn to reduce float and strengthen pools
• Grow USDT reserves
• Fund adoption

Current live rates (BNB Smart Chain (BSC))

• Buy: 3.25% (collected in MarsLC, 1.00% burned, 2.25% swapped to USDT)
• Wallet-to-Wallet (W2W): 2.25% (collected in MarsLC, burn does not apply, 2.25% swapped to USDT)
• Sell: 3.75% (collected in MarsLC, 1.50% burned, 2.25% swapped to USDT)

Split of the swapped USDT (applies to Buy, Sell, and W2W)

• ≈55.56% → Reserve Vault (Whitebox) (≈1.25% of the fee)
• ≈44.44% → Marketing wallet (≈1.00% of the fee)

Mechanics

The contract supports 1–13% per direction and exposes setUnifiedFees(...) — the above BNB Smart Chain (BSC) rates reflect the current live on-chain settings (fees are configurable post-deploy by owner/creator only; fully evented).

9. Liquidity policy

All official LP added by the contract has its LP tokens burned (sent to the dead address). Third-party liquidity additions are possible, but they are not “official” and may be removed by their providers. Only contract-added liquidity is “official” because its LP tokens are burned.

10. Market support (support-burn)

supportBurn(networkId, usdtAmount) spends Vault's USDT (Whitebox) to buy MarsLC on the canonical pair to the Whitebox address and immediately burns it from Whitebox’s balance.

Result: the pool ends up with more USDT and fewer MarsLC, improving the pool’s USDT depth. This is a reserve-building mechanism by design, aligned with the protocol’s goal of steadily growing on-chain USDT reserves for MarsLC holders.

• Effect: more USDT depth, less MarsLC circulating
• Ops pattern: Whitebox grants a one-shot USDT allowance → support-burn executes → allowance is revoked
• Emits: TokensBurnedFromSupport and updates local counters

11. Creator lock

3,000,000 MarsLC locked in the MarsLibertyCoin token contract on the hub for 3 years. After the lock, 100,000-token claims are permitted only if the average price is ≥ $10 (within a 24h window after first reaching $10), and ≥ 30 days have passed since the previous claim.

12. Additional emission (strictly controlled)

Baseline at launch

At launch, MarsLC’s baseline distribution is designed to be simple and transparent. A total of 5,000,000 MarsLC is allocated as follows:

• 3,000,000 MarsLC (Creator-locked allocation) are locked for the Creator (see Section 11 above for the strict unlock rules)
• 1,000,000 MarsLC (Tranche A) were used for the initial market setup: official liquidity on the canonical PancakeSwap V2 pool, with all LP tokens burned
• 1,000,000 MarsLC (Tranche B) are reserved for rollout to other networks and/or exchange liquidity. Tranche B is minted by the contract when rollout begins (it is not automatically minted at deployment)

Tranche B prerequisite (no emissions before full rollout)

Because Tranche B is part of the planned baseline distribution, the protocol does not allow any additional emissions until Tranche B has been fully deployed. Tranche B may be deployed in a single batch or in multiple batches, and may be allocated across V2, V3 (where applicable), and/or exchange (CEX) liquidity.

Low-float trigger (after Tranche B is fully deployed)

Once Tranche B is fully deployed, the protocol monitors the global liquidity float across all canonical pools (as reported by the Oracle). If the total amount of MarsLC remaining inside these pools falls to 10% or less of the circulating supply, a Global Low-Float condition is triggered and a strict, time-limited emission window may open.

Additional emission is only possible under a strict set of conditions:

• Cap per emission: up to 1,000,000 MarsLC per emission
• Trigger (10% rule): emissions are only permitted during a window opened by a Global Low-Float trigger
• Reserves & average price = emission sizing: MarsLC to be emitted = total USDT reserves across all Whiteboxes ÷ the Oracle’s average market price; therefore, the result is capped at 1,000,000 MarsLC per emission
• Timing constraints: emissions are allowed only within the 24-hour window after a Global Low-Float trigger, with at least 1 hour between emissions
• Deployment / use of newly minted tokens: newly issued tokens may be deployed in one batch or in multiple batches, and may be allocated across multiple destinations, including canonical pools (V2 / V3, where applicable — with LP burned) and/or exchange liquidity provisioning (CEX)

13. Cross-chain architecture (external bridge)

Sockets for a dedicated bridge adapter:

• mintFromBridge(amount, to) (onlyBridge) → BridgeMint
• burnFromBridge(from, amount) (onlyBridge) → BridgeBurn

The adapter handles messaging and replay protection. The Oracle excludes bridge burns from economic burn statistics.

14. Metrics & Oracle

Local (on-chain):

• USDT (normalized to 18 decimals) counters: usdtInjectedLocal, usdtCollectedLocal
• Other: burnedFromFeesLocal, burnedFromSupportLocal, lpBurnedLocal
• Pool reserves via getPoolBalances() (USDT normalized to 18 decimals)

Snapshot: getGlobalReserveStatus() → local stats, global aggregates, per-network reports, Oracle's latest update.

Oracle (off-chain): vault balances, injected/collected USDT, burns, LP burned, reserves, spot price, bridge mint/burn, globals.

15. Alerts & integrations

Watch (on-chain events):

• Reserves & funding: ReserveVaultFunded(amountUSDT18d), MarketingFunded(amountUSDT18d)
• Liquidity: LiquidityInjected(...), LPBurned(lpAmount)
• Burns: TokensBurnedFromFees, TokensBurnedFromSupport
• Support (ops): SupportExecuted(networkId, usdtAmount18d, marsBought, marsBurned, poolUsdtAfter18d)
• Bridge: BridgeMint(to, amount), BridgeBurn(from, amount)
• Health: UsdtLiquidityLow(networkId, poolUsdt18d), GlobalLowFloat()
• Creator: CreatorUnlockWindowOpened(...), CreatorClaimed(...)
• Config: RouterUpdated, UsdtUpdated, ReserveVaultUpdated(chainId, oldVault, newVault), LowLiqThresholdUpdated, NetworkRegistered, FeeCollectorUpdated, FeesUnifiedUpdated, FeeExemptionUpdated, AlertConfigUpdated, OracleUpdated, MarketingWalletUpdated, CreatorUpdated(oldCreator, newCreator), BridgeUpdated(oldBridge, newBridge)
• Tranche B/Rollout: TrancheBExported(amount, remaining, targetNetworkId, to)
• Reports: NetworkReportUpdated, AdditionalEmissionPerformed
• Default low-liquidity alert threshold: 100 USDT (18d) per network; adjustable via setLowLiqThreshold()

16. Security & invariants

• Privileged admin/config actions require owner/creator
• Bridge sockets are restricted to onlyBridge
• Transfers use in-swap guards + SafeERC20; stateful externals use nonReentrant where value moves
• Pair is never fee-exempt
• Routers/USDT are updatable
• Reserve Vaults (Whitebox) are fixed per network, except for a one-time relink within 24h after deploy (local network only)

17. Limitations & roadmap

• On-chain ops are V2-only (V3/CEX tracked by Oracle)
• Non-EVM chains require native spokes + bridge/oracle integration
• The bridge adapter is external; the token already exposes the sockets

18. Events (USDT values normalized to 18d where noted)

ReserveVaultFunded(amountUSDT18d), MarketingFunded(amountUSDT18d)
LiquidityInjected(networkId, usdtAmount18d, marsAmount)
UsdtLiquidityLow(networkId, poolUsdt18d)
NetworkReportUpdated(networkId, poolUsdt18d, poolMars)
SupportExecuted(networkId, usdtAmount18d, marsBought, marsBurned, poolUsdtAfter18d)

Also: TokensBurnedFromFees, TokensBurnedFromSupport, LPBurned, GlobalLowFloat
CreatorUnlockWindowOpened, CreatorClaimed, AdditionalEmissionPerformed
RouterUpdated, UsdtUpdated, LowLiqThresholdUpdated, NetworkRegistered
FeeCollectorUpdated, FeesUnifiedUpdated, FeeExemptionUpdated, AlertConfigUpdated
OracleUpdated, MarketingWalletUpdated, BridgeMint, BridgeBurn.

19. FeeCollector — role & properties

Role (what it does): FeeCollector is a minimal on-chain splitter used in the fee-funding pipeline.

• No swaps inside FeeCollector: FeeCollector does not execute router swaps. Any swap (when needed) is executed by the MarsLibertyCoin main token contract
• USDT is transient: when a swap outputs USDT with to = FeeCollector, the collector may receive USDT within the transaction and then split it via sweep(). It is not intended to be a treasury where USDT “accumulates” over time
• What gets split: FeeCollector splits its current USDT balance between: Reserve Vault (Whitebox), and Marketing wallet, using the current on-chain split configured in MarsLibertyCoin contract

MarsLC backlog: FeeCollector can hold an accumulated MarsLC backlog. On sells, MarsLibertyCoin may drain that backlog (using the allowance that FeeCollector grants to the token contract), swap it to USDT, and then trigger the split via sweep()

If FeeCollector is ever replaced: the old FeeCollector supports a strict post-switch leftovers distribution that sends any remaining assets only to Whitebox and Marketing per the current split (no swaps, no arbitrary recipients)

Properties (security model).

• Immutable: no proxy
• No external admin / no operator withdrawal: core functions (sweep() and other token-only plumbing) are callable only by the MarsLibertyCoin contract (onlyToken), so no EOA can pull funds from the collector
• Only human-callable “emergency” path: emergencyDistributeBacklog() is callable only by MarsLibertyCoin owner/creator and only after MarsLibertyCoin has been switched to a new collector (it checks MarsLibertyCoin.feeCollector()), and it distributes leftovers strictly to Whitebox + Marketing (no arbitrary addresses)
• ETH is rejected: plain ETH transfers revert
• Distributions emit on-chain events (public audit trail): splits/moves are recorded in logs

When can the collector be changed? MarsLibertyCoin may switch to a new FeeCollector via setFeeCollector(newCollector) only if strictly required to keep the swap → USDT → sweep pipeline functional due to external infrastructure changes (e.g., router/factory migration, canonical USDT replacement, or other DEX plumbing changes). It is not a discretionary governance lever; under normal conditions, the collector is expected to remain permanent.

Note. FeeCollector is not involved in support-burn; support-burn operates directly via Whitebox (one-shot approvals).

20. Whitebox (Reserve Vault) — one per network

What it is. Whitebox is an immutable vault contract tightly bound to the MarsLibertyCoin contract (token: MarsLC) on a given network. There are no discretionary (arbitrary) withdrawals: funds only serve liquidity and the token’s transparent economics. Controllers are resolved dynamically from the MarsLibertyCoin contract (current owner/creator). No permanent approvals exist—only targeted one-shot approvals for specific actions.

The five Whitebox functions

1. Tranche A (initial launch, official liquidity)
   One-shot USDT approval → the MarsLibertyCoin contract adds the initial liquidity to the canonical V2 pair → all LP tokens are burned → approval is immediately cleared.
2. Support-burn
   One-shot USDT approval → the MarsLibertyCoin contract uses the vault's USDT to buy MarsLC on the canonical V2 pair, sending MarsLC to the Whitebox address → the MarsLibertyCoin contract immediately burns the purchased MarsLC from Whitebox’s balance → approval auto-clears.
3. Official liquidity adds / placing additional emission
   For local top-ups and for placing newly issued tokens under strict emission rules: one-shot USDT approval → MarsLibertyCoin contract action → LP burned → approval cleared.
4. Inter-Whitebox transfer (cross-network treasury routing)
   Schedule → wait ≥12h and <24h (timelock/expiry) → execute. Public procedure with mandatory delay.
5. Exchange payment
   Only to an allowlisted address and only after ACK—either on-chain or via EIP-712/1271 signature—also with timelock and expiry.

Mandatory pattern for 1–3: one-shot approval → action → immediate revocation. Revocation is built in to each scenario.

Security invariants

• Immutability: the MarsLibertyCoin contract address is fixed forever; no proxy
• Dynamic authorization: controllers are always the current MarsLibertyCoin owner/creator at call time
• Vault role check: Whitebox self-verifies that it is the registered vault for the current network
• One-shot approvals only: no standing approvals; each approval is cleared right after the operation
• No admin drain: no arbitrary withdrawals or “rescue” buttons; external payouts require timelock + allowlist + mandatory ACK
• ETH is rejected: plain ETH transfers revert

21. Developer TL;DR

• One canonical V2 MarsLC/USDT pair per chain; pair is never fee-exempt
• Routers/USDT updatable (if DEX infra changes); pair re-derived; no liquidity migration; LP irrecoverable
• Fees: BUY/SELL → burn + MarsLC; W2W → MarsLC; MarsLC (BUY/SELL/W2W) → USDT (FeeCollector) → split Whitebox (Vault) / Marketing
• Official LP is burned
• Support-burn uses Whitebox (Vault) USDT to buy & burn MarsLC (one-shot allowance)
• Launch: Tranche A (1M + 1k USDT; LP burned), Tranche B (1M rollout reserve: for spokes + CEX; V2/V3 where applicable)
• Creator lock: 3Y, 100k/batch with price & cooldown gates
• Bridge: external adapter; token exposes mint/burn; bridge burns excluded from economic burns
• Oracle aggregates per-chain/global metrics
• Whitebox (Reserve Vault) is distinct from creator; set at deploy/registration

22. Implementation baseline

• Solidity: ^0.8.30
• OpenZeppelin (MarsLC/FeeCollector): ERC20, Ownable, ReentrancyGuard, SafeERC20, IERC20, IERC20Metadata
• OpenZeppelin (Whitebox): ReentrancyGuard, SafeERC20, EIP712, ECDSA, IERC1271
• Math & DEX: OZ Math; Uniswap/Pancake V2 factory/router/pair

23. Oracle implementer notes

• Economic burns = fee burns + support burns (no manual burn endpoint)
• Exclude bridge burns from getTotalBurned(); expose bridge mint/burn separately
• Normalize USDT to 18d across networks (many USDT are 6 decimals)
• Average price should be USDT-weighted and outlier-resistant
• Per-network metrics: vault USDT, injected/collected USDT, burnedFromFees, burnedFromSupport, LP burned, pool MarsLC/USDT, spot price, burnedFromBridge, mintedFromBridge; plus globals and lastUpdateTimestamp

24. Glossary & counters

• Reserve Vault (per chain): holds USDT reserves; receives fee USDT; funds support-burns and official LP adds
• usdtCollectedLocal (18d): USDT realized from fees on this chain (Vault + Marketing)
• usdtInjectedLocal (18d): USDT the contract supplied to the pool
• burnedFromFeesLocal / burnedFromSupportLocal: burns from fees / support-burns
• lpBurnedLocal: LP tokens burned on this chain
• Low-float window: 24h after a global low-float trigger (≤10% of circulating); ≥1h spacing between emissions; Tranche B fully exported

25. Contract verification status

All core contracts of MarsLibertyCoin (MarsLC) are verified and published on BscScan (BNB Smart Chain (BSC)):

• MarsLibertyCoin (main token) — verified [✓]
• Whitebox (Reserve Vault) — verified [✓]
• FeeCollector — verified [✓]

This ensures full transparency and simplifies external audits, risk-analysis integrations, and community due diligence.

26. Addresses & verification (BNB Smart Chain (BSC))

• Token (MarsLC): 0x67e5D1470bA737291401E3Ce91DB6779D5363279
• Whitebox (Vault): 0x5D745A513ffA36bc7D7b91F198a000C1a30832bF
• FeeCollector: 0xAa8c8b2297dAae284979062D99554b8ea4809cC4