Know what arrives automatically — and what requires action.

HOW TO RECEIVE & CLAIM REWARDS

Owning a RAOLAX Ticket can make a wallet eligible for selected Founder systems.

But “eligible” does not always mean “already sitting in your wallet.” Some rewards can be distributed automatically. Some are recorded to a snapshot and delivered later. Some require you to open the MUTERRA cabinet or claim interface and actively collect them.

The practical rule is simple:

keep the correct Ticket on the wallet that you intend to use, connect that wallet to MUTERRA, and check whether the current programme requires a Claim action.**

Flow:

1 — CREATE / REGISTER YOUR MUTERRA ACCOUNT

2 — CONNECT YOUR WALLET

Connect the wallet that actually holds the eligible RAOLAX Ticket or other required asset.

3 — KEEP ELIGIBLE ASSETS ON THE CORRECT WALLET

If a programme uses a snapshot, ownership is checked at the defined snapshot moment.

4 — CHECK YOUR ALLOCATION

The cabinet, claim page or programme announcement should show what is allocated, delivered or claimable.

5 — CLAIM WHEN REQUIRED

If the reward is claim-based, use the official Claim interface before any stated deadline.

6 — VERIFY RECEIPT

Check the asset/token on the correct chain, wallet or approved interface.

MUTERRA should never require a holder to send a private key or seed phrase in order to receive a Founder reward.

A normal wallet connection allows the site to read the public wallet address and request signatures or transactions that the user explicitly approves.

For MUTA vesting, the current public flow uses the holder’s own compatible BNB Smart Chain wallet and a public claim dashboard.

If a message, bot, moderator or website asks you to send a seed phrase to “unlock” a RAOLAX benefit, treat it as fraudulent.

Two columns:

SAFE: CONNECT WALLET / SIGN VISIBLE REQUEST / CLAIM THROUGH OFFICIAL INTERFACE

NEVER: SEND SEED PHRASE / SEND PRIVATE KEY / “VERIFY” WALLET BY SHARING SECRET WORDS

A snapshot answers: **who was eligible at a particular moment?**

A Claim answers: **has that eligible holder collected an allocation that requires manual action?**

Example:

SNAPSHOT — Wallet A holds an eligible Ticket at the programme’s defined time.

ALLOCATION — the programme calculates or records what Wallet A is entitled to under the current rules.

CLAIM — Wallet A later opens the official interface and claims the available asset, if manual claiming is required.

Moving the Ticket after the snapshot does not automatically rewrite a closed snapshot. But moving it before a future snapshot can change who is eligible for that future event.

Timeline:

Add second Ticket transfer marker after snapshot to show that closed snapshots and future ownership are separate questions.

Not every Founder benefit needs a manual claim.

A programme can deliver an NFT directly to an eligible wallet, record metadata on an existing Ticket, assign access to an account, or otherwise apply a benefit automatically where the technical design allows it.

When a reward is automatic, the programme communication should say so clearly.

You should not have to guess whether the absence of a Claim button means you missed something.

For claim-based programmes, an eligible allocation can remain waiting until the holder completes the required on-chain or account action.

The current MUTA Vesting / Claim system is an example: eligible wallets can view grant schedules, claimed amounts and claimable balances, then claim unlocked MUTA when it becomes available.

This is especially useful for vested rewards because the entire grant does not necessarily unlock on the same day.

MUTA vesting already has a public infrastructure page, vesting contract, claim dashboard and current vesting templates.

This Founder material should therefore not create a second set of vesting percentages or schedules.

For current MUTA vesting rules, use the MUTA page as the source of truth.

The Founder Pass layer only needs to explain why a Ticket holder may encounter vesting: a particular Founder or contributor allocation can be subject to a schedule, and unlocked MUTA may then require a Claim action.

Embed or recreate a simplified view of the actual MUTA claim dashboard UI:

TOTAL GRANT / UNLOCKED / CLAIMED / CLAIMABLE / NEXT UNLOCK / CLAIM BUTTON

Founder NFT Drops can contain different asset types and can use different distribution mechanics.

One Drop may be sent directly to eligible wallets. Another may require a Claim. Another may record eligibility first and mint/distribute later. Another may be tied to an event or task.

The Drop announcement should define:

— eligibility;

— snapshot time, if used;

— Ticket Degree/class requirements;

— whether delivery is automatic or claim-based;

— claim deadline, if any;

— chain / wallet requirements;

— what happens to unclaimed allocations, if applicable.

A Weighted Draw determines which eligible entry wins according to the draw rules.

After the result is recorded, the prize still needs a delivery path: automatic transfer, claim, account entitlement, fulfilment process or another method appropriate to that asset.

The draw rules should state the delivery method before participation closes.

RAOLAX events do not all need to produce a separate tradable object.

An event can update metadata, unlock a story element, create eligibility for a later task, add access, record an incident or connect a Ticket to another part of the world.

In those cases, “receive” can mean the Ticket or account state changes rather than a new NFT arriving in the wallet.

Three cargo routes from one RAOLAX Ticket:

Some claim-based events may use a defined claim window.

If a deadline exists, it should be published with the event. Holders are responsible for checking official programme information and claiming within that window.

MUTERRA should not silently introduce a deadline after the fact for a programme that was communicated as permanently claimable.

If unclaimed assets are recycled, returned to a pool, burned or handled another way, the programme rules should state that before the claim period closes.

A Ticket can change hands.

If eligibility was fixed by an earlier snapshot, the wallet that held the Ticket at that snapshot can remain the eligible recipient for that closed event even if the Ticket has since moved.

For a future holder-based programme, the new holder can become eligible when the next relevant snapshot occurs.

This is why every serious reward page needs a visible `ELIGIBILITY DATE / SNAPSHOT` field rather than relying on the phrase “for Ticket holders.”

Cryo remains a RAOLAX Ticket while asleep, but normal scheduled Founder participation is intentionally delayed until awakening under the current Ticket design.

That means the claim interface may show nothing for a Cryo Ticket during a programme where Cryo is not eligible.

Selected random, metadata or explicitly Cryo-eligible events can still operate where the event rules say so.

A Founder system will evolve over years. A screenshot from Discord, an old post or an early draft may describe a rule that has since changed for a future programme.

Before signing a claim transaction:

— use the current MUTERRA website or official cabinet;

— verify the connected wallet and network;

— verify the programme name;

— check snapshot and claim dates;

— check whether the reward is vested;

— read the active rules;

— verify the contract/address where practical.

Before contacting support, check:

If those checks do not explain the issue, use official MUTERRA support/community channels and provide the public wallet address / Ticket ID / programme name. Never provide private keys or seed phrases.

The target cabinet architecture should make each holder programme legible in one place.

Suggested fields:

PROGRAMME

MUTA Q3 / Founder Drop #04 / Weighted Draw #12 / Ship Event / etc.

STATUS

UPCOMING / ELIGIBLE / ALLOCATED / CLAIMABLE / CLAIMED / EXPIRED / NOT ELIGIBLE

SNAPSHOT

Date/time + wallet used.

ASSET / AMOUNT

What was allocated where applicable.

DELIVERY

AUTO / CLAIM / VESTED CLAIM / ACCOUNT ACCESS / METADATA UPDATE.

ACTION

CLAIM / VIEW / NO ACTION REQUIRED.

SOURCE

Link to the programme rules.

Create a real dashboard mockup with 4–5 different programme states rather than generic cards.

A good reward system does not make holders hunt through Discord to discover that a claim window opened three days ago.

Where technically and operationally possible, MUTERRA should use:

— cabinet status;

— email / account notifications;

— official Discord/community notices;

— clear deadlines;

— direct links to the current claim interface;

— transaction confirmation after a successful claim.

The story can be mysterious.

The ownership mechanics should not be.**

Left: mysterious RAOLAX event message / sealed cargo notice.

Right: completely clear holder UI: ELIGIBLE / CLAIM BY / CLAIM BUTTON.

Caption: THE STORY CAN HIDE CLUES. THE CLAIM FLOW CANNOT.

If a programme requires manual claiming and has a deadline, doing nothing can mean losing that specific allocation according to the published rules.

If a programme is automatic, doing nothing may be exactly what is required.

This is why the action state must always be explicit.

The holder should be able to answer one question immediately:

Do I need to do anything now?**

For most RAOLAX holders, the long-term routine should remain simple:

KEEP — keep the relevant Ticket on the wallet when you want future holder-based eligibility.

CONNECT — keep that wallet connected to your MUTERRA account/cabinet where required.

CHECK — review active allocations, snapshots and claim status periodically or when notified.

CLAIM — collect only when the programme says an action is required.

VERIFY — confirm receipt and keep your wallet secure.

You should not need to trade every day, watch a price chart every morning or manually interact with every MUTERRA event.

The system should make long-term participation easier than short-term speculation.