FEN supply
1,000,000,000 FEN
Fixed genesis supply for Fenrua FEN.
FENpresale
FENswap is the public quote-review entry into FENpresale; P-FEN is the non-transferable presale receipt; P-FEN is burned to claim unlocked FEN. Unlocked FEN can later be burned to mint N under published migration rules or entered into FENpool rewards.
FENpresale uses a participant-side claim model. After finalization and the cliff schedule, each holder claims from the presale contract by burning claimable P-FEN. The contract calculates the unlocked amount; the participant initiates the transaction.
FEN supply
1,000,000,000 FEN
Fixed genesis supply for Fenrua FEN.
FENpresale reserve
200,000,000 FEN
Required reserve before FENpresale can open.
P-FEN capacity
200,000,000 P-FEN
Receipt capacity backed 1:1 by real FEN reserve.
FENpresale period
360 days
Fixed deadline counted from the presale start day; early sellout can finalize sooner.
Transfer tax
0%
FEN has 0% ERC20 transfer tax.
Reserve
Reserve not verified
The reserve must be exact.
Sale
FENpresale locked
Public purchase controls are not live here; FENpresale uses the fixed 360-day deadline.
Claim window
Claim window pending
Participants initiate claims when the contract schedule makes FEN claimable.
Records
Not yet published
Addresses appear only when ready for public review.
Presale contract explorer link appears after deployment and 200M FEN reserve lock. This page does not invent contract links before the public evidence is ready.
Abstract 1. Section Abstract
This section formalizes the presale surface as a receipt dossier rather than a participation page. The system defines a finite P-FEN capacity, a required FEN reserve, a non-transferable receipt state, a burn-to-claim transition, and a scheduled unlock path. The public interface is therefore allowed to explain evidence and timing while the claim path stays holder-initiated: the participant burns claimable P-FEN through the presale contract when the schedule allows FEN to be claimed.
Presale theorem: P-FEN can be public and useful only if it remains non-transferable, reserve-bound, and downstream of schedule-based claim logic.
Research Question 1. RQ-PS-01
By defining P-FEN as a non-transferable accounting receipt, rejecting approval and transfer pathways, and routing value into burn-to-claim mechanics after finalization.
Research Question 2. RQ-PS-02
The public claim depends on exact reserve requirements, stage allocation totals, report hashes, source excerpts, and finalization rules that burn unsold reserve.
Research Question 3. RQ-PS-03
Eligibility begins only after the receipt has been burned and unlocked FEN has been claimed according to the schedule; P-FEN and unclaimed FEN remain excluded.
Research Question 4. RQ-PS-04
The holder initiates the presale contract claim by burning claimable P-FEN; the contract schedule determines how much FEN is unlocked.
| Claim | Statement | Evidence | Boundary |
|---|---|---|---|
| Formal Claim 1. FC-PS-01 | P-FEN is a non-transferable presale receipt, not liquid FEN. | PFENPresale exposes non-transferability overrides and receipt-focused buy, claim, and claimable functions through source excerpts. | The page provides no transfer, approval, receipt market, liquidity, refund, or staking action. |
| Formal Claim 2. FC-PS-02 | The presale capacity is finite and staged. | The stage table totals 200,000,000 P-FEN across fifteen published allocation rows. | Capacity visibility does not mean the public page is open for purchase or that any stage is currently active. |
| Formal Claim 3. FC-PS-03 | Claimed FEN is schedule-constrained. | The claim timeline states presale finalization, a 120-day delay, monthly unlocks, and final release. | Before burn and unlock, P-FEN cannot be treated as claimed inventory or FENpool-eligible inventory. |
| Formal Claim 4. FC-PS-04 | FENpresale uses participant-side burn-to-claim release, not operator-side distribution. | The claim model is holder-initiated: claimable P-FEN is burned into the presale contract and unlocked FEN is transferred according to the schedule. | No public language should imply batches managed by the team, discretionary holder unlocks, or operator-triggered holder distribution. |
Invariant 1. INV-PS-01
FENswap, FENpresale, and FENtrust copy all name P-FEN as the receive and receipt state before burn-to-claim.
Invariant 2. INV-PS-02
The source evidence panel shows approval, transfer, transferFrom, and update-path rejection logic.
Invariant 3. INV-PS-03
Guardrails explicitly exclude P-FEN and locked or unclaimed FEN from FENpool rewards.
Invariant 4. INV-PS-04
The finalization section states that sold P-FEN remains matched to claimable FEN and unsold presale FEN is burned.
Invariant 5. INV-PS-05
The public page describes claim as burning P-FEN into the presale contract to receive unlocked FEN; it excludes operator distribution and holder unlock language.
| Row | Artifact | Observation | Limitation |
|---|---|---|---|
| Evidence Row 1. PS-01 | contracts/presale/PFENPresale.sol | Contains constructor, purchase, claim, claimable, and non-transferability excerpts. | The excerpt proves contract design, not live sale status on this read-only page. |
| Evidence Row 2. PS-02 | reports/fen-presale-audit/FINAL-REPORT.md | Identified by a public final-report hash for the scoped presale audit package. | Report scope must be read as scoped evidence rather than unlimited protocol approval. |
| Evidence Row 3. PS-03 | docs/security/fen-token-public-trust-statement.md | Aligns holder-facing commitments with source hashes, report hashes, and public claim language. | The statement is a trust artifact; claims remain bounded by the contracts and reports it references. |
Limitation 1. L-PS-01
This section documents the mechanism and evidence. It does not render buy, approve, claim, finalize, refund, pool, or privileged controls.
Limitation 2. L-PS-02
FENpool is downstream, variable, and funded by epochs. The presale section does not promise APY, liquidity, listing, or price outcome.
Limitation 3. L-PS-03
Future N minting is a separate migration constraint requiring burned unlocked FEN under published rules, not a direct property of P-FEN.
Limitation 4. L-PS-04
The public claim path is not described as a team-run release process. Participants claim unlocked FEN by burning P-FEN through the presale contract when the schedule makes FEN claimable.
FENswap -> stablecoin value ->
P-FEN receipt -> burn P-FEN -> claim unlocked FEN by cliff schedule ->
later choices require claimed FEN: N migration or FENpool rewards.
FENswap is the public quote-review entry for FEN access and the FENpresale path.
Supported source assets are measured as stablecoin value for the P-FEN quote.
P-FEN is the non-transferable receipt backed by the exact presale reserve.
Each holder claims unlocked FEN through the presale contract by burning claimable P-FEN.
Future N minting requires burned unlocked FEN under published migration rules.
Only unlocked and claimed FEN can enter FENpool rewards.
P-FEN is a non-transferable receipt.
FENpresale is non-refundable.
FENpresale uses a fixed 360 days deadline from the presale start day.
FEN claims begin 120 days after presale end.
Unlocked FEN is claimed by the holder burning claimable P-FEN through the presale contract.
The claim path is participant-side and schedule-bound.
P-FEN cannot be staked in FENpool.
Locked or unclaimed presale FEN cannot be staked in FENpool.
Only unlocked and claimed FEN can enter FENpool rewards.
Unsold presale FEN is burned at finalization.
FEN has 0% ERC20 transfer tax.
FENgas and FENcont are public ecosystem protection and continuity policy signals, not hidden ERC20 transfer taxes.
Staking rewards are variable and depend on funded reward epochs. No fixed APY.
Future N minting must require burned FEN under the published migration contract rules.
Each purchase must fit inside the active stage. The full schedule totals exactly 200,000,000 P-FEN.
| Stage | Allocation | Price |
|---|---|---|
| 1 | 2,500,000 P-FEN | 0.01 stablecoin |
| 2 | 5,000,000 P-FEN | 0.02 stablecoin |
| 3 | 7,500,000 P-FEN | 0.03 stablecoin |
| 4 | 15,000,000 P-FEN | 0.04 stablecoin |
| 5 | 15,000,000 P-FEN | 0.05 stablecoin |
| 6 | 15,000,000 P-FEN | 0.06 stablecoin |
| 7 | 15,000,000 P-FEN | 0.07 stablecoin |
| 8 | 15,000,000 P-FEN | 0.08 stablecoin |
| 9 | 15,000,000 P-FEN | 0.09 stablecoin |
| 10 | 15,000,000 P-FEN | 0.10 stablecoin |
| 11 | 15,000,000 P-FEN | 0.11 stablecoin |
| 12 | 15,000,000 P-FEN | 0.12 stablecoin |
| 13 | 15,000,000 P-FEN | 0.13 stablecoin |
| 14 | 15,000,000 P-FEN | 0.14 stablecoin |
| 15 | 20,000,000 P-FEN | 0.15 stablecoin |
The claim schedule defines what becomes claimable; it does not describe an operator-run holder distribution process. When FEN is unlocked by schedule, the holder initiates the presale contract claim and burns the claimable P-FEN amount.
This page explains the terms and timing. It does not ask the visitor to sign anything.
No buy, approve, claim, finalize, burn, transfer, pool, refund, or privileged controls on this read-only page.
No receipt transfer action.
No receipt approval market.
No receipt liquidity module.
No operator-run holder release action.
When FENpresale finalizes, sold P-FEN remains matched to claimable FEN and unsold presale FEN is burned. FEN launch through this path waits until the FENpresale allocation is resolved as sold or burned.
These hashes are included for public review without exposing private operational material.
FENpresale final report
fd65c0bfbedd89b3397b827a103fb65897607b428a5855e618f97888d08a2561
Launch accountability final report
08360fd364a5c3845c25bd2c0837b7bb351f684afa1ec7d5c8b727b4525f70ae
Genesis allocation final report
59c6a2e3591e61bfc1e8620198a71ffab4078063b94156876b8864ff921774d0
The buyer-facing rules above are anchored to the contract excerpts below: constructor reserve setup, P-FEN purchase, claim, claimable schedule math, and non-transferable overrides.
PFENPresale constructor
contracts/presale/PFENPresale.sol
Locks the sale to FENchain 978, validates FEN/payment/treasury/owner addresses, and builds the exact 200M P-FEN stage allocation.
constructor(
IPresaleFEN fen_,
IERC20Metadata paymentToken_,
address treasury_
) ERC20('Presale FEN Receipt', 'P-FEN') {
if (block.chainid != FENCHAIN_CHAIN_ID) {
revert WrongFenchain(block.chainid, FENCHAIN_CHAIN_ID);
}
if (address(fen_) == address(0) || address(paymentToken_) == address(0)) revert ZeroAddress();
if (treasury_ == address(0)) revert ZeroAddress();
address configuredLaunchController = fen_.launchController();
if (configuredLaunchController != treasury_) {
revert InvalidLaunchController(configuredLaunchController, treasury_);
}
uint8 decimals_ = paymentToken_.decimals();
if (decimals_ < 2 || decimals_ > 30) revert BadStablecoinDecimals(decimals_);
fen = fen_;
paymentToken = IERC20(address(paymentToken_));
treasury = treasury_;
paymentTokenDecimals = decimals_;
uint256 unit = 10 ** uint256(decimals_);
_stages[0] = Stage({allocation: 2_500_000 ether, sold: 0, price: unit / 100});
_stages[1] = Stage({allocation: 5_000_000 ether, sold: 0, price: (unit * 2) / 100});
_stages[2] = Stage({allocation: 7_500_000 ether, sold: 0, price: (unit * 3) / 100});
for (uint256 i = 3; i < 14; i++) {
_stages[i] = Stage({allocation: 15_000_000 ether, sold: 0, price: (unit * (i + 1)) / 100});
}
_stages[14] = Stage({allocation: 20_000_000 ether, sold: 0, price: (unit * 15) / 100});
uint256 totalAllocation = 0;
for (uint256 i = 0; i < STAGE_COUNT; i++) {
totalAllocation += _stages[i].allocation;
}
if (totalAllocation != PRESALE_ALLOCATION) {
revert ReserveInvariantBroken(totalAllocation, PRESALE_ALLOCATION);
}
}buyPFEN
contracts/presale/PFENPresale.sol
Requires an open, unfinalized sale, exact reserve backing, current-stage capacity, stablecoin payment forwarding, and P-FEN minting.
function buyPFEN(
uint256 pfenAmount,
uint256 expectedStage,
uint256 maxStablecoinAmount,
uint256 deadline
) external nonReentrant {
if (!opened) revert PresaleNotOpen();
if (soldOutAt != 0) revert PresaleAlreadyFinalized();
// slither-disable-next-line timestamp
if (block.timestamp >= saleEnd) revert PresaleClosed(saleEnd);
// slither-disable-next-line timestamp
if (block.timestamp > deadline) revert PurchaseExpired(deadline, block.timestamp);
if (pfenAmount == 0) revert ZeroAmount();
_requireActiveReserve();
uint256 stageIndex = currentStage;
if (stageIndex != expectedStage) revert StageChanged(expectedStage, stageIndex);
Stage storage activeStage = _stages[stageIndex];
uint256 remaining = activeStage.allocation - activeStage.sold;
if (pfenAmount > remaining) {
revert StageAllocationExceeded(stageIndex, pfenAmount, remaining);
}
uint256 stablecoinAmount = quotePFEN(stageIndex, pfenAmount);
if (stablecoinAmount > maxStablecoinAmount) {
revert PaymentExceedsMaximum(stablecoinAmount, maxStablecoinAmount);
}
uint256 treasuryBalanceBefore = paymentToken.balanceOf(treasury);
paymentToken.safeTransferFrom(msg.sender, treasury, stablecoinAmount);
uint256 treasuryBalanceAfter = paymentToken.balanceOf(treasury);
uint256 stablecoinReceived =
treasuryBalanceAfter >= treasuryBalanceBefore ? treasuryBalanceAfter - treasuryBalanceBefore : 0;
if (stablecoinReceived < stablecoinAmount) {
revert TreasuryPaymentShortfall(stablecoinAmount, stablecoinReceived);
}
activeStage.sold += pfenAmount;
totalSoldPFEN += pfenAmount;
totalStablecoinRaised += stablecoinReceived;
purchasedPFEN[msg.sender] += pfenAmount;
emit PaymentForwarded(
msg.sender,
address(paymentToken),
stablecoinAmount,
stablecoinReceived,
treasury
);
_mint(msg.sender, pfenAmount);
emit PFENPurchased(msg.sender, stageIndex, pfenAmount, stablecoinReceived, treasury);
_advanceStage();
if (totalSoldPFEN == PRESALE_ALLOCATION) {
_recordSellout(block.timestamp);
}
}claim
contracts/presale/PFENPresale.sol
Burns claimable P-FEN and transfers the same amount of unlocked real FEN to the claimant.
function claim() external nonReentrant returns (uint256 amount) {
amount = claimable(msg.sender);
// slither-disable-next-line incorrect-equality,timestamp
if (amount == 0) revert NoClaimableFEN(msg.sender);
uint256 reserveBeforeClaim = fen.balanceOf(address(this));
uint256 requiredBeforeClaim = outstandingFEN();
if (reserveBeforeClaim < requiredBeforeClaim) {
revert ReserveInvariantBroken(reserveBeforeClaim, requiredBeforeClaim);
}
claimedFEN[msg.sender] += amount;
totalClaimedFEN += amount;
_burn(msg.sender, amount);
fen.safeTransfer(msg.sender, amount);
uint256 reserveAfterClaim = fen.balanceOf(address(this));
uint256 requiredAfterClaim = outstandingFEN();
if (reserveAfterClaim < requiredAfterClaim) {
revert ReserveInvariantBroken(reserveAfterClaim, requiredAfterClaim);
}
emit FENClaimed(msg.sender, amount, amount);
}claimable
contracts/presale/PFENPresale.sol
Computes cliff-schedule unlocks after finalization and subtracts already claimed FEN.
function claimable(address account) public view returns (uint256) {
uint256 resolvedClaimStart = claimStart();
if (resolvedClaimStart == 0 || block.timestamp < resolvedClaimStart) return 0;
uint256 periods = ((block.timestamp - resolvedClaimStart) / RELEASE_INTERVAL) + 1;
uint256 unlockedBasisPoints =
periods >= FINAL_RELEASE_PERIOD ? BPS : periods * RELEASE_BPS;
uint256 unlocked = (purchasedPFEN[account] * unlockedBasisPoints) / BPS;
uint256 alreadyClaimed = claimedFEN[account];
if (unlocked <= alreadyClaimed) return 0;
return unlocked - alreadyClaimed;
}P-FEN non-transferable overrides
contracts/presale/PFENPresale.sol
Rejects approval, direct transfer, transferFrom, and wallet-to-wallet ERC20 movement while still allowing mint and burn.
function approve(address, uint256) public pure override returns (bool) {
revert PFENNonTransferable();
}
function transfer(address, uint256) public pure override returns (bool) {
revert PFENNonTransferable();
}
function transferFrom(address, address, uint256) public pure override returns (bool) {
revert PFENNonTransferable();
}
function _update(address from, address to, uint256 value) internal override {
if (from != address(0) && to != address(0)) revert PFENNonTransferable();
super._update(from, to, value);
}These hashes connect the presale rules to the public statement, report packages, and source manifests.
Public statement SHA256
6121a9dcbf564db8cfcde7cb35b570c9d6ccc127626ceedb69eb08648750c199
Fenrua FEN Token Public Trust Statement v0.4.
Presale final report
fd65c0bfbedd89b3397b827a103fb65897607b428a5855e618f97888d08a2561
PFENPresale audit and launch-readiness package.
Launch accountability final report
08360fd364a5c3845c25bd2c0837b7bb351f684afa1ec7d5c8b727b4525f70ae
Launch accountability bundle referenced by the public trust statement.
Genesis allocation final report
59c6a2e3591e61bfc1e8620198a71ffab4078063b94156876b8864ff921774d0
Genesis allocation and custody evidence report.
Presale source manifest
73516fb7b25e83b58ba8557152a5eb7a50f70cbad1564ed10029fdce7cafa340
Source manifest for the presale audit bundle.
Launch source manifest
f8e1abaf3f0fce91e43975cbcd864787e1a0574b5e575a4001a4682c8e32230f
Source manifest for launch accountability.
Genesis source manifest
43c8880207901ca4b77d4fe637e83a0958781fd52cbff9105b4d0bb74a3e82d6
Source manifest for genesis allocation.
Evidence manifest
c55d265a3a7c003a1632f9f3083c4a47728b855c54497ed11533bae96a5b6d67
Evidence manifest for the launch-accountability bundle.
Buyer acknowledgement
I understand that FENpresale is non-refundable, P-FEN is non-transferable, FEN unlocks by contract schedule, FENpool rewards are variable with no guaranteed APY, FENgas/FENcont ecosystem protection policies and launch anti-sniper protections may affect very large, suspicious, or bot-like transaction patterns, and future N minting requires burned FEN under the published migration contract rules.