🟡 BSC Mainnet · chainId 56 · Contract-Aligned
GIGGLE RELOADED
($GGRD)
($GGRD)
Whitepaper v4.0 — Mainnet Specification
⛓ Deployed on BNB Smart Chain · chainId 56 · Snapshot: deployments/bscMainnet.latest.json
📄 Download Full Whitepaper PDF
GGRD_Whitepaper_Contract_Aligned_v4_0.pdf · Full technical specification
⬇ Download PDF
SCOPE AND METHODOLOGY
This whitepaper is a full rewrite based on deployed contract logic and repository specifications. Every numeric parameter is either contract-enforced or explicitly marked as an operational assumption from repository docs.
Source Hierarchy
| Level | Source | Authority |
|---|---|---|
| Level 1 | contracts/*.sol | Immutable and runtime-enforced rules |
| Level 2 | deployments/bscMainnet.latest.json | Live mainnet addresses and constructor timestamps |
| Level 3 | docs/SPEC_TOKENOMICS_v1.md | Declared launch assumptions and architecture docs |
Canonical Rule
When contract code and descriptive text differ, contract code is treated as canonical.
PROJECT VISION AND DESIGN CONSTRAINTS
GGRD is designed as a fixed-supply BSC token with deterministic on-chain sale mechanics, governance delay controls, staking emissions caps, and charity vesting logic. The design target is auditable execution with reduced discretionary control surface.
Explicit Constraints
| Constraint | Status |
|---|---|
| Fixed supply token model | Enforced |
| 0% transfer tax | Enforced |
| No post-deployment mint API | Enforced |
| No blacklist, no freeze, no confiscation logic | Enforced |
| Governance via Safe multisig + timelock layers | Enforced |
| Presale escrow with success/fail settlement paths | Enforced |
TOKEN CONTRACT AND MONETARY POLICY
GGRDToken.sol implements a standard ERC20 with a single mint in the constructor. No owner functions expose post-deployment supply changes.
| Field | Value | Contract Anchor |
|---|---|---|
| Name | Giggle Reloaded | GGRDToken.sol constructor |
| Symbol | GGRD | GGRDToken.sol constructor |
| Decimals | 18 | OpenZeppelin ERC20 default |
| Total Supply | 10,000,000 GGRD — minted once | _mint(recipient, 10_000_000 ether) |
| Transfer Tax | None (0%) | GGRDToken.sol — no tax mechanism |
| Post-deploy Mint | Not available | GGRDToken.sol — no mint function |
| Blacklist / Freeze | Not available | GGRDToken.sol — no restriction functions |
Mint destination in the mainnet deployment artifact is the deployer address at deployment time. Downstream allocations are performed by transfers to module contracts.
ALLOCATION AND ECONOMIC MODEL
The total supply model combines hard caps from contracts and launch allocations from the repository specification.
Presale
30%
Staking Rewards
30%
Charity
20%
Operations + Liquidity
20%
| Component | Amount | Share | Enforcement |
|---|---|---|---|
| Presale token cap | 3,000,000 GGRD | 30% | On-chain — PresaleEscrow8020.tokenCap |
| Staking reward cap | 3,000,000 GGRD | 30% | On-chain — GGRDStakingMultiV1.REWARD_POOL_CAP |
| Charity allocation | 2,000,000 GGRD | 20% | Operational — docs/SPEC_TOKENOMICS_v1.md |
| Operations + Liquidity | 2,000,000 GGRD | 20% | Operational — docs/SPEC_TOKENOMICS_v1.md |
Note
CharityVesting403030 enforces distribution shape (40/30/30) and vesting schedule, but not a fixed token amount. The amount is determined by funding transfers.
PRESALE ESCROW MECHANICS
Presale is implemented in PresaleEscrow8020.sol as USDC escrow with deterministic stage logic, wallet caps, success split, refund fallback, and post-success claim vesting.
Core Parameters (Contract-Enforced)
| Parameter | Value | Anchor |
|---|---|---|
| Payment asset | USDC on BSC | payToken immutable |
| Duration | 21 days | PRESALE_DURATION |
| Softcap | 20,000 USDC | softcap = 20_000 * PAY_UNIT |
| Hardcap | 31,250 USDC | hardcap = 31_250 * PAY_UNIT |
| Min buy | 50 USDC | minBuy = 50 * PAY_UNIT |
| Global wallet cap | 3,000 USDC | globalMaxPerWallet |
| Token cap | 3,000,000 GGRD | tokenCap = 3_000_000 * SALE_UNIT |
| Claim vesting | 60 days linear | CLAIM_LINEAR_DURATION |
Stage Matrix
01
Elapsed < 5 days
$0.0085
1,000,000 GGRD available
Wallet cap: 500 USDC
Max raise: $8,500
02
5–10 days
$0.0100
800,000 GGRD available
Wallet cap: 750 USDC
Max raise: $8,000
03
10–16 days
$0.0115
700,000 GGRD available
Wallet cap: 1,000 USDC
Max raise: $8,050
04
17–21 days (elapsed 16–21)
$0.0134
500,000 GGRD available
Wallet cap: 1,500 USDC
Max raise: $6,700
Mainnet Schedule
2026-03-10 01:15:19 UTC
Presale Start — startTs = 1773105319
2026-03-15 01:15:19 UTC
Stage 1 End — start + 5 days
2026-03-20 01:15:19 UTC
Stage 2 End — start + 10 days
2026-03-26 01:15:19 UTC
Stage 3 End — start + 16 days
2026-03-31 01:15:19 UTC
Presale End — start + 21 days
Settlement and Claim Logic
| Condition | Outcome |
|---|---|
| totalRaised ≥ softcap | SUCCESS — 80% USDC → Liquidity wallet · 20% → Marketing wallet |
| totalRaised < softcap | FAILURE — Each buyer calls refund() for 100% USDC back |
| Success claim vesting | 50% immediate + 50% linear over 60 days |
| Finalize timing gate | Owner can finalize only after end time or at hardcap |
Price Formula
tokenOut = payIn × PRICE_SCALE × SALE_UNIT / (stagePriceScaled × PAY_UNIT)
GOVERNANCE AND CONTROL PLANE
Governance model combines Safe multisig operations with timelock-enforced delays for selected high-impact actions.
🏦 Operational Safe
2 of 3 signers
External Safe setup referenced in deployment docs
External Safe setup referenced in deployment docs
⏱ Short Timelock
48 hours (172,800 seconds)
GGRDTimelock constructor args
GGRDTimelock constructor args
⏱ Long Timelock
72 hours (259,200 seconds)
GGRDTimelock constructor args
GGRDTimelock constructor args
🔒 Staking Owner
Long timelock address
GGRDStakingMultiV1 constructor owner arg
GGRDStakingMultiV1 constructor owner arg
🛡 Staking Guardian
Safe address
GGRDStakingMultiV1 constructor guardian arg
GGRDStakingMultiV1 constructor guardian arg
📦 Airdrop Owner
Short timelock address
MerkleAirdrop constructor owner arg
MerkleAirdrop constructor owner arg
STAKING ENGINE
GGRDStakingMultiV1 is a multi-position staking contract with reward and principal caps, lock-based reward eligibility, and early withdraw penalties.
| Parameter | Value | Effect |
|---|---|---|
| APR | 10% (APR_BPS=1000) | Linear annualized reward accrual |
| Minimum lock | 30 days | No rewards before lock maturity |
| Program duration | 730 days | Reward accrual stops at endTime |
| Reward pool cap | 3,000,000 GGRD | Hard upper bound on funded rewards |
| Max total staked | 5,000,000 GGRD | Hard principal capacity cap |
| Early withdraw penalty | 10% | Penalty before 30-day lock, no reward payout |
| Emergency controls | Guardian or owner can pause | Owner unpauses — operational incident response |
CHARITY VESTING PROGRAM
Charity release is executed by CharityVesting403030 with deterministic share splitting and linear vesting after cliff.
| Parameter | Value | Contract Behavior |
|---|---|---|
| Beneficiary split | 40% / 30% / 30% | A_BPS=4000, B_BPS=3000, C_BPS=3000 |
| Cliff behavior | No vesting before cliff | if (timestamp < cliff) return 0 |
| Post-cliff behavior | Linear until duration end | (total × (timestamp - start)) / duration |
| Mainnet start | 2026-03-10 00:15:17 UTC | constructor arg 1773101717 |
| Cliff end | 2027-03-10 00:15:17 UTC | cliffSeconds = 31,536,000 |
| Full vesting end | 2029-03-09 00:15:17 UTC | durationSeconds = 94,608,000 |
Current Deployment
Current deployment maps charity A/B/C recipients to one operational charity safe address. Beneficiary addresses will be updated via governance as charity partners are confirmed.
AIRDROP DISTRIBUTION FRAMEWORK
MerkleAirdrop supports multiple rounds with independent Merkle roots and claim windows.
- Round creation requires Merkle root, start/end times, and funded amount.
- Claim authorization uses standard Merkle proof verification over
(index, account, amount). - One-claim-per-leaf enforced through bitmap state — no double claims.
- Owner can sweep unclaimed leftovers only after round expiry.
- Airdrop owner is the short timelock (48h) — governance-gated round creation.
LIQUIDITY AND LP LOCK POLICY
Economic intent from repo specification is GGRD/USDC liquidity provisioning after successful presale finalization.
| Parameter | Value |
|---|---|
| USDC to liquidity (on success) | 80% of raised USDC → Liquidity Safe |
| USDC to marketing (on success) | 20% of raised USDC → Marketing Safe |
| Reference launch ratio | ~25,000 USDC paired with ~1,200,000 GGRD |
| LP lock target | 12 months |
| LP lock contract | LPLocker.sol — owner can only extend lock forward |
Important
LP token address does not exist until pair creation. LP locker deployment and lock execution is an explicit post-presale operational step. LP pair and locker addresses will be published with explorer links after finalization.
SECURITY CONTROLS AND RESIDUAL RISKS
✓ Implemented Controls
OpenZeppelin primitives across token, timelock, access control, Merkle verification, and safe transfers
Reentrancy protections in presale, staking, and airdrop state-changing flows
Hard caps for presale token sale, staking rewards, and staking principal
Pause control in staking with guardian-owner split for incident response speed
Timelock delays (48h / 72h) on all governance actions
2-of-3 Safe multisig — no single point of control
⚠ Residual Risks
Misconfigured wallet addresses in deployment/env can route funds incorrectly
High-impact governance transactions still require strict signer discipline
Operational execution (LP provisioning, locking, funding schedules) remains process-sensitive
External oracle or price feed dependency is not present — stage pricing is time-based only
MAINNET ADDRESSES AND PARAMETERS
All addresses sourced from deployments/bscMainnet.latest.json. Always verify before signing any transaction.
Core Contracts
| Component | Address | Role | |
|---|---|---|---|
| GGRD Token | 0xA0d5663d57b7D7EF975D2F02BcAEaf5c94c671f9 | ERC20 fixed supply token | BscScan ↗ |
| PresaleEscrow8020 | 0xd8983534dd3c369d85127f6C9B85d98768139387 | USDC escrow presale | BscScan ↗ |
| USDC (pay token) | 0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d | Presale payment asset | BscScan ↗ |
| GGRDStakingMultiV1 | 0x05d803135bc09e9E5006CA75C533377D7Ea0A34b | Staking module | BscScan ↗ |
| CharityVesting403030 | 0xE2993F0C8D2020dD9866E2d6dC5AA1D62b7C8fDC | Charity vesting splitter | BscScan ↗ |
| MerkleAirdrop | 0x9F64E78185ee697783E0c9ebA0F66131FFCedBD6 | Airdrop module | BscScan ↗ |
| Timelock (48h) | 0xBC4655E8D5A4A4B16bD30db2fFBC94Ed05AbcE87 | Short governance delay | BscScan ↗ |
| Timelock (72h) | 0xd4b5f94f7cF8Eb79bEd2f3Aa5693d9F97D573E31 | Long governance delay | BscScan ↗ |
| Governance Safe (2/3) | 0x28218d08f6D2084eBd7CeF3f582139E7417b6300 | Operational multisig | BscScan ↗ |
| Liquidity Safe (2/3) | 0x7677AC2712d161e7F75fC4316E8B3dC3FaC01009 | USDC destination — 80% on success | BscScan ↗ |
| Marketing Safe (2/3) | 0xF2922343AdF6F2631A2f1e9b9b11c9d269f3874D | USDC destination — 20% on success | BscScan ↗ |
| Charity Safe A | 0xd58B8D79deC67F8731267B929D24A4923Bac59a3 | Charity vesting recipient | BscScan ↗ |
OPERATIONAL RUNBOOK AND GOVERNANCE ACTIONS
Presale Phase
- Fund presale contract with up to 3,000,000 GGRD.
- Monitor stage progress, wallet caps, and raised total against hardcap/softcap thresholds.
- Trigger
finalize()after end time or at hardcap.
Post-Finalize — Success Path
- Execute LP provisioning workflow using liquidity wallet USDC share and planned GGRD allocation.
- Create LP pair token and deploy/initialize LP locker for 12-month lock target.
- Publish LP pair and locker addresses with explorer links.
Post-Finalize — Failure Path
- Keep refund interface open and monitored until participant refunds are completed.
- Communicate final accounting and remaining balances transparently.
Staking and Charity Lifecycle
- Fund staking reward pool gradually within REWARD_POOL_CAP.
- Initialize staking program start time under governance control.
- Call charity vesting release function per schedule and publish transfer reports.
RISK AND LEGAL NOTICE
⚠ RISK DISCLAIMER
GGRD is a high-risk crypto asset; total capital loss is possible. This document is technical information, not investment, legal, or tax advice. Users and operators should verify contract addresses and transaction payloads independently. Operational execution quality materially affects real-world outcomes despite strong contract controls.
Whitepaper v4.0 is a repository-grounded technical specification as of 2026-03-10. Future governance actions, module upgrades, or operational reconfiguration can change non-immutable behavior.
Generated from ggrd-bsc-contracts repository | GGRD Whitepaper v4.0 | 2026-03-10
GGRD is a high-risk crypto asset; total capital loss is possible. This document is technical information, not investment, legal, or tax advice. Users and operators should verify contract addresses and transaction payloads independently. Operational execution quality materially affects real-world outcomes despite strong contract controls.
Whitepaper v4.0 is a repository-grounded technical specification as of 2026-03-10. Future governance actions, module upgrades, or operational reconfiguration can change non-immutable behavior.
Generated from ggrd-bsc-contracts repository | GGRD Whitepaper v4.0 | 2026-03-10