MagnaFork
Go to DashboardGo to Dashboard

MagnaFork documentation

Rules you can verify

This is not a brochure and not raw ABI. It is a readable map of MagnaFork rules: what is visible before entry, where the contract places a participant, how USDT moves, and where interface promises stop.

Cycle map

One fork moves from the top position to two child forks

A fork is not just a UI card. It is one on-chain cycle. The contract fills seats top-down; the outer circle funds payout; split carries the structure forward.

elderlvl2: 2 seatslvl4: 4 seatsouter: 8 seatselderlvl2[0]lvl2[1]lvl4[0]lvl4[1]lvl4[2]lvl4[3]01234567
outer net stays in contractpayout + split
left child forkright child fork
01Top position

Root creator or carried participant after split.

022 seats

Second level fills before the third level.

034 seats

Third level prepares the outer circle.

04Outer circle 8/8

Net parts from these entries stay in the contract.

05Payout + split

One transaction: payout, parent close, two child forks.

What the contract does

For every entry it selects a fork, picks the next seat, records a position, and executes USDT transfers.

What the interface does not do

It does not assign the best seat, promise payout timing, or manually close or wake a fork.

Amounts and funds

Tier formula

Amounts matter more than slogans. Every tier uses the same formula: fee moves immediately, and payout comes only from eight net parts in the outer circle.

tierEntry7% feeNet partElder payout
05 USDT0.35 USDT4.65 USDT37.20 USDT
150 USDT3.50 USDT46.50 USDT372.00 USDT
2500 USDT35.00 USDT465.00 USDT3720.00 USDT

Amounts and funds

Where an entry goes

entry amount100%
7%operating wallet
93%contract reserve
outer[8] builds reserve8 x net to elder
elder / lvl2 / lvl4the full entry amount goes to the operating wallet
outer[8]fee goes to the operating wallet; net stays in the contract
8/8the contract pays elder eight net parts and performs split

Entry routes

Invite, Open entry, and guarded entry solve different problems

MagnaFork's main routing question is not where a user wants to land, but which route the contract can confirm at transaction time.

entry request
Invitelive fork in the same tree
Open entryroot-completion, HOT, WARM, or new root
Guardedchecks fork / level / slot before transferFrom

Invite entry

The user arrives through a fork code or link. If the anchor is already closed, the contract looks for a live fork inside the same tree.

  • refreshes the activity window
  • can wake a SLEEP fork
  • never leaves the invite tree

Open entry

A public route without a specific invite link. It first completes incomplete root forks, then routes across HOT and WARM groups.

  • does not refresh the 24 / 72 hour window
  • does not promise a specific fork
  • creates a root fork if none is suitable

Guarded entry

The same entry flow, with a check for the expected fork, level, and seat before USDT is transferred.

  • protects against stale UI
  • reverts before transferFrom
  • shows the user the real route

States

ACTIVE / HOT / WARM / SLEEP / CLOSED

Status is not decoration. It shows whether a fork can accept entries and whether it participates in Open entry.

invite entry
HOT: 0-24 hoursWARM: 24-72 hoursSLEEP: after 72 hours

a new invite can wake the fork

LabelMeaningRouting effect
ACTIVEfork can accept entriesbase on-chain status
HOTinvite was within the last 24 hoursgets the priority share of Open entry
WARMinvite was 24 to 72 hours agogets a smaller share of Open entry
SLEEP72 hours without invite entrydoes not receive Open entry, but can wake by invite
CLOSEDfork completed payout/splitdoes not accept direct entries

Split map

How a full fork becomes two child forks

After 8/8 the parent closes. The contract does not shuffle seats randomly: left and right forks receive deterministic positions.

Parent fork 8/8elder payout

Left fork

  • lvl2[0] -> elder
  • lvl4[0..1] -> lvl2
  • outer[0..3] -> lvl4

Right fork

  • lvl2[1] -> elder
  • lvl4[2..3] -> lvl2
  • outer[4..7] -> lvl4

Examples

Three situations where the rules become clear

These cases make the boundaries visible: where a link stays useful, where activity matters, and where the UI must protect the user from races.

Old link

Invite survives split

A user enters a root fork code that has already reached 8/8 and became CLOSED.

The contract does not send entry into a closed fork. It selects a live child fork inside the same tree.
Activity window

Open entry does not wake SLEEP

A fork is active, but no invite entry has happened for more than 72 hours.

Open entry skips it. A new invite entry can return the fork to ACTIVE.
Seat race

The contract must confirm the seat

The user saw a seat in the UI, but someone else filled it before confirmation.

Guarded entry reverts before USDT transfer if the target changed.

Full specification

All rules in one place

Below is the user-facing full specification. It is longer, but it now reads as a reference: thesis first, then verifiable rules.

Smart-contract rules

Full MagnaFork V1 Specification

This is the user-facing version of the full contract specification: not an ABI dump, but the complete logic of entries, routing, statuses, payouts, splits, and promise boundaries.

The user sees a compact map first, then the full mechanics. This is not a marketing promise and not a developer-only note: it is how the contract executes MagnaFork.

Participation levels5 / 50 / 500 USDT

Three levels use the same logic and do not mix with each other.

Fee7%

The operating fee is taken from every entry.

Net part93%

The net part of upper seats goes to the operating wallet; the net part of the outer circle stays in the contract until payout.

Payout condition8/8

When the outer circle is full, payout and fork split execute in one transaction.

Activity window24 / 72 hours

HOT up to 24 hours, WARM up to 72 hours, SLEEP after 72 hours without invite entry.

Open entryroots first

Incomplete root forks are completed first; HOT and WARM groups are used after that.

Invite linksurvives split

A link to a closed root fork routes into a live fork in the same tree.

Manual controlnone

The owner does not assign forks or payouts manually.

1. What matters before entry

MagnaFork should be understandable before a transaction: the user sees action conditions, not a result promise.

  1. Before confirmation, the user sees the participation level, entry amount, operating fee, and entry route: invite entry or Open entry.
  2. One wallet can hold multiple positions. The contract has no “1 wallet = 1 position” limit.
  3. The final fork and seat are determined by the contract at transaction time; the interface cannot manually assign a better slot.
  4. If the user confirms a specific route and seat, the app should use guarded entry so the transaction does not execute against a changed fork.

2. Levels and amounts

Every level uses the same formula; only the entry size changes.

  1. Level 0: 5 USDT entry, 0.35 USDT fee, 4.65 USDT net part, 37.20 USDT payout.
  2. Level 1: 50 USDT entry, 3.50 USDT fee, 46.50 USDT net part, 372 USDT payout.
  3. Level 2: 500 USDT entry, 35 USDT fee, 465 USDT net part, 3720 USDT payout.
  4. The contract stores amounts in token base units and assumes USDT-style 6 decimals; it does not call token decimals itself.

3. Roles and permissions

The administrative surface is narrow: it cannot manually steer cycles.

  1. The owner can only change the operating wallet and the address that signs root-fork creation.
  2. The operating wallet receives fees and the net part of upper seats.
  3. The authorization address signs root-fork permissions; each signature is bound to level, link, deadline, chain, contract address, and creator.
  4. A participant can create an authorized root fork, enter by invite, enter through Open entry, or use guarded entry.

4. Fork structure

A fork is one participation cycle inside a selected level.

  1. A root fork starts its tree: it has no parent, and its root id equals its own id.
  2. Child forks inherit the root tree id and store the parent fork id.
  3. A fork stores the top position, two second-level seats, four third-level seats, and an eight-seat outer circle.
  4. After split, the parent records left and right child forks and becomes closed.

5. Positions and fill order

Every entry creates a separate position, and the next seat is selected from the top down.

  1. Fill order: top position, two second-level seats, four third-level seats, then outer circle slots 0 through 7.
  2. A position stores owner, fork, seat level, slot index, retained amount, retained-in-contract flag, and active flag.
  3. Top, second-level, and third-level positions open with no retained amount inside the contract.
  4. Outer-circle positions open with the retained net part, because it funds the current payout.

6. How funds move

Fee, upper-seat net part, and outer-circle net part should not be confused.

  1. For the top, second-level, and third-level seats, the full entry amount goes to the operating wallet; events record fee and net part separately.
  2. For the outer circle, the fee goes to the operating wallet and the net part stays in the contract.
  3. The top-position payout equals eight net parts from the outer circle.
  4. The retained amount in a position is not a user withdrawal balance; it is accounting for the amount that funds the current cycle payout.

7. Root fork creation

A root fork can appear through authorization or through Open entry.

  1. Authorized creation requires a non-empty link, unexpired deadline, unused link id, and a signature from the current authorizer.
  2. The signature cannot be reused by another wallet, on another chain, or on another contract instance.
  3. Open entry can create a root fork automatically when no suitable fork exists in the selected level.
  4. The root-fork creator takes the top position, and the full entry amount goes to the operating wallet.

8. Invite entry

An invite preserves activity and keeps the entry tree useful after split.

  1. If the linked fork is open and has a seat, entry goes into that fork.
  2. If the linked fork is closed, the contract looks for a live fork inside the same tree.
  3. HOT/WARM forks are preferred first, then SLEEP forks with open seats.
  4. Invite entry refreshes the activity window and can wake a SLEEP fork back to active state.

9. Open entry

Open entry moves the shared flow, but it does not promise a specific fork.

  1. Open entry first completes incomplete root forks in the selected level before their first split.
  2. After that, the contract chooses between HOT and WARM: three out of four entries prefer HOT, one out of four prefers WARM.
  3. If the preferred group is empty, the contract tries the other group.
  4. If no suitable fork exists, Open entry creates a new root fork for the incoming participant.

10. HOT / WARM / SLEEP

These short activity labels make routing status readable.

  1. HOT: an active fork with an open seat where the last invite entry was no older than 24 hours.
  2. WARM: an active fork with an open seat where the last invite entry is in the 24-72 hour window.
  3. SLEEP: a fork after 72 hours without invite entry; it does not receive Open entry, but can wake by invite.
  4. Incomplete root forks before their first split are prioritized separately and are not treated as regular HOT/WARM candidates.

11. Guarded entry

Guarded entry prevents the user from confirming a stale route.

  1. The app can pass the expected fork, seat level, and slot index.
  2. If the contract selects a different seat at execution time, the transaction reverts before USDT is taken.
  3. For Open entry that creates a new root fork, the expected values are zero.
  4. Regular and guarded entry have the same economics; guarded entry only protects against a changed route.

12. Payout and split

When the outer circle is full, the contract pays out and continues the tree.

  1. A cycle is ready when the top position, two second-level seats, four third-level seats, and the full 8/8 outer circle are filled.
  2. The contract closes parent positions, transfers payout to the top position, and creates two child forks.
  3. The left child fork receives the first second-level participant, the first two third-level seats, and the first four outer-circle seats.
  4. The right child fork receives the second second-level participant, the last two third-level seats, and the last four outer-circle seats.

13. Routing queues

The contract does not scan the whole fork history on every entry.

  1. Open entry uses queues for incomplete root forks, HOT, and WARM.
  2. An old link to a closed fork uses preferred and fallback queues inside that fork's tree.
  3. Queues are cleaned lazily: stale candidates are removed during selection or synchronization.
  4. Each attempt scans up to 32 candidates for Open entry routing and up to 32 candidates for invite routing.

14. What can be verified

Key actions leave blockchain events and readable state.

  1. Events record entry, fee, upper-seat net part, root-fork creation, Open entry assignment, and position opening.
  2. Events also record SLEEP, wake, payout, split, operating-wallet change, and authorizer change.
  3. Read methods allow checking level amounts, forks by level, fork state, outer circle, fork tree, and position state.
  4. The interface and operator should rely on these data points, not invented or service-only numbers.

15. Read methods and version flags

The contract gives the interface enough state to avoid guessing.

  1. The interface can read level amounts, used root links, the Open entry counter, and fork ids by selected level.
  2. It can read base fork state, the outer circle, tree links, position ids by slot, and individual position state.
  3. The contract reports support for key capabilities: Open-entry root bootstrap, invite-tree routing, upper-seat net-part sweep, root-completion priority, guarded entry, and indexed queues.
  4. These version flags help the interface distinguish MagnaFork V1 behavior from older or future contracts.

16. Errors and reverts

If a required condition is not met, the contract reverts instead of partially executing.

  1. Entry is rejected for an invalid level, invalid fork, closed fork, no empty seat, or changed guarded-entry target.
  2. Root-fork creation is rejected for an empty link, expired deadline, reused link, or signature not from the current authorizer.
  3. Administrative actions are rejected for zero addresses and for callers other than the owner.
  4. If a required USDT transfer fails, state is not partially updated.

17. Contract boundaries

The full specification matters because it also states what the contract does not do.

  1. The contract does not promise yield, payout timing, or that a specific entry will necessarily lead to payout.
  2. The contract has no user refund from a position, no pause, no manual payout, and no level changes after deployment.
  3. The contract has no one-wallet-one-position limit and does not distribute funds through the inviter parameter.
  4. The AI operator and interface help users understand the rules and choose the next checkable step, but they cannot change smart-contract execution.