Can a creator remove an allowlist spot after the wallet claims it?

A creator cannot remove a claimed allowlist spot. Campaign management permits removing unclaimed spots and shows claimed and remaining places. A completed claim retains its claimed-place record, so removing an unused place cannot reverse another wallet’s earlier claim.

Does an Activation’s ENS check require a new name purchase?

The ENS Imported action checks whether an ENS name connects to the user’s Layer3 profile. An existing connection addresses that check; other required actions can impose separate conditions. The check itself does not specify a new name purchase. Assess any spending required by the other actions separately from the final claim’s gas.

What does the staking screen’s combined balance include?

The “Staked + Rewards” figure includes staked L3 and accrued staking rewards. Individual stakes retain their own sizes and durations, with management under “Your Stakes.” The combined display does not mean all its tokens are immediately available in the wallet. Access to principal follows each stake’s lock and applicable withdrawal conditions.

Will minting a CUBE automatically make a future airdrop payable?

A CUBE records Activation completion, while a future airdrop has its own eligibility and claim conditions. Creators can use CUBE data to identify audiences for later campaigns. A recorded completion does not specify the token amount a later campaign will distribute to that wallet, so the credential alone does not establish a payable allocation.

Can a campaign require earlier CUBE mints before its reward claim?

A creator can use the CUBEs Minted action to check a user’s previous mint count, optionally on specified chains. This eligibility check differs from minting the current Activation’s completion credential. Earlier activity can therefore form part of a campaign’s requirements, and paying the current claim’s gas does not substitute for meeting them.

Does a conversational trading request authorize a transaction by itself?

A conversational trading request does not replace wallet authorization. The conversational-agent panel is labeled beta and displays a US$100 transaction maximum. Inspect the proposed transaction before signing it; requests above the displayed maximum fall outside the agent’s stated scope. A route shown in transaction review describes a proposed operation, while successful execution determines its outcome.

Layer3 assigns reward funding to Activation creators and claim gas to users

Layer3 splits the costs of token-reward Activations between campaign creators, the platform and participating users. Creators fund each Activation’s reward escrow with the selected token. The platform covers gas for deploying and initializing that escrow. Users pay gas when they mint the CUBE credential and claim the token reward in the same transaction. Any applicable CUBE minting fee is a separate cost. These responsibilities describe the token-reward workflow, not every activity the app supports. Creating its smart wallet has no gas or creation fee. Required onchain tasks, trading and L3 staking introduce their own spending or capital commitments.

The short version: Increasing an Activation’s participant cap raises its required escrow funding when the per-user token reward stays unchanged.

Creators fund rewards while users pay claim gas

Token-reward Activations divide campaign costs by operation. Funding supplies the incentive inventory, setup prepares the escrow and claiming delivers the configured payout.

Reward tokens in escrow

Funding concerns the token the campaign promises and the amount available for distribution. A creator chooses the per-user reward and participant cap. The required budget follows those choices. An escrow holding enough reward tokens does not, by itself, provide a claimant with funds to pay network gas.

Gas sponsorship for escrow setup

Layer3 covers gas for deploying and initializing token-reward escrows. This sponsorship applies to those setup operations. Reward-token authorization and escrow funding have their own roles: authorization permits distribution of the selected token, while funding supplies the inventory. Identify any transaction charges these operations display separately from the sponsored deployment and initialization.

Claim costs at the wallet

Users pay gas for their token-reward claims. Claims using the published EVM CUBE 4.1 contract can also carry a minting price set in authorized claim data. Account for any applicable minting fee separately from network gas. Combining the mint and payout in one transaction does not remove costs associated with actions required before claiming. Those actions may involve other protocols, and their spending belongs in the participant’s assessment.

Smart wallet creation has a limited no-fee scope

The smart wallet creation flow requires no gas, creation fee or browser extension. That describes establishing the wallet. It does not price subsequent transactions. Claiming an Activation’s token reward has the user-paid gas responsibility explained above. A swap, bridge or staking action also has its own transaction and token requirements.

Open full-size image

Required actions can create costs before the claim

Activations combine verifiable requirements with incentives, and their action types determine what participation involves before the final reward claim. Quizzes test understanding; social checks verify connected accounts or community participation. Onchain checks can verify contract interactions and holdings. A holdings condition concerns an asset balance, while an interaction condition concerns activity. Checking an existing holding does not itself establish a requirement to buy more tokens. An instruction requiring a new transaction introduces a separate operation to assess.

Compare the requested action with the incentive’s unit and conditions. Tokens committed to a protocol are distinct from gas spent executing its transaction. Account connections add a different consideration: they associate participation with a social or identity profile. None of these inputs becomes a received reward merely because the task description displays an incentive amount.

In the token-reward claim flow, a CUBE mint and the escrow payout occur in one transaction. The CUBE is an onchain credential recording Activation completion; the payout transfers the configured reward token. A completed requirement, a wallet signature and a successful claim therefore describe different stages. A signature authorizes the proposed operation. The transaction outcome establishes whether execution completed, while the resulting credential and token movement identify what it produced.

CUBE records can include the Activation, community, completion time and transaction hashes associated with actions. Creators can use these records to monitor campaign completion. Activations can offer CUBE credentials or XP alongside their other rewards. When assessing costs, identify the actual reward type before assigning it a spendable token value.

Participant caps set the funding needed for fixed rewards

Fixed token rewards give a creator a direct funding relationship between campaign capacity and the amount promised to each eligible participant. The participant cap counts the maximum unique participants who can complete the Activation and claim its token reward. This is a campaign setting, not an estimate of how many people will ultimately participate.

Reward units and campaign capacity

For a fixed per-user token reward, required escrow funding equals the participant cap multiplied by that token amount. Keep the calculation in the reward token’s units. A budget expressed in token units does not establish a fixed monetary value. Increasing the cap while leaving the reward unchanged increases the tokens needed to cover the full allocation.

Funding the full allocation also differs from recording completed claims. A reward amount shown in campaign settings describes the configured payout. The escrow balance describes available inventory. Neither number alone identifies how much a particular wallet has already received. Claim records supply the separate information needed to follow distribution.

Deployment, authorization and funding

Deployment creates the escrow, and initialization prepares it for reward distribution. The configuration flow then selects the token and allowlists it for the escrow. It sets the participant cap and per-user amount before funding. The interface exposes the escrow address after initialization and shows its balance after funding. A deployed contract can remain unfunded, so deployment confirmation alone cannot establish that the incentive budget is ready.

The reward token and CUBE use the same chain

An Activation’s token reward must use the same blockchain as its CUBE credential, making chain selection part of the creator’s funding responsibility. The distribution system supports ERC-20 tokens on supported Ethereum Virtual Machine networks, SPL tokens on Solana and native tokens including ETH and SOL. Support for a token standard does not make every blockchain available for a particular Activation. The selected chain determines which token instance and escrow receive the funding.

The funding transfer must send the selected token to the intended escrow on the correct blockchain. Token identity on that chain matters because the escrow authorizes the configured token for distribution. Moving tokens elsewhere does not replenish the intended reward contract. The chain, token identity and destination address belong together when checking the campaign balance.

Audience settings determine who can reach a reward claim

Audience controls define access to an Activation separately from its required actions and reward budget. Public Activations appear in discovery and their Community Space. Private Activations use a direct link and stay outside public discovery. Wallet allowlists restrict participation to specified addresses. Each choice fits a different distribution task: public discovery supports broad access, a private link controls discoverability and an allowlist identifies eligible wallets. None of these choices changes who supplies the token budget.

Creators upload allowlisted addresses through a CSV file and can monitor claimed and unclaimed spots. These records help distinguish an access issue from a funding issue. A wallet excluded by the configured audience does not resolve that exclusion by offering more gas. Changing access settings belongs to campaign management; signing a claim belongs to the participating wallet.

Builder submission access requires a separate L3 commitment

Creating a Builder Space is permissionless, while submitting Activations for review has additional prerequisites. Setup includes enabling two-factor authentication. A new Space provides a community dashboard; submission access also requires an L3 stake.

The stake needed to unlock submission

Unlocking Builder submission access requires an L3 stake locked on Ethereum Mainnet for at least 12 months. This commitment concerns creator access. Reward escrow funding supplies a different asset pool for a particular Activation. The access stake therefore needs its own place in the creator’s capital budget, separate from tokens allocated to participant rewards.

Incentives and review

Activations require a user incentive before approval, such as token rewards, points, an NFT allowlist or a raffle. Review can reject poor user experience, high fees without adequate compensation or promotion of unaudited applications. Meeting the staking prerequisite establishes access to submission, while review assesses the proposed campaign. Locking L3 does not itself establish approval for an Activation.

Trading and staking have their own spending constraints

The Trade interface supports swaps and bridging through manual input and conversational requests. The conversational-agent panel displays a beta notice and a US$100 transaction maximum. Trades above that amount fall outside its stated scope. Inspect the generated transaction before signing it. A swap changes the held asset; a bridge moves assets between chains. Inputs and outputs in the route review belong to that proposed trade. Escrow setup sponsorship does not describe the price of those operations. Compare the transaction’s displayed charges and intended output before authorizing the trade.

L3 staking commits token capital and earns L3 staking rewards. Optional locks increase reward rates with longer lock periods. An unlocked stake permits an unstake request at any time, with a seven-day withdrawal period. That wait matters when comparing staking with keeping tokens available in a wallet. The withdrawal period applies to unlocked stakes; it does not erase a chosen lock.

Stake size, duration and activity can affect rewards or access. A quoted annual percentage yield does not show when the principal becomes available.

Escrow balances and claim records locate different problems

A funding problem concerns the creator’s configured reward inventory, while a claim problem concerns a participant’s access or transaction. The escrow interface shows its balance and confirms reward-token authorization. Campaign management also exposes the participant cap and allowlist claim counts. These observations identify different conditions: an empty reward balance needs funding attention, an excluded wallet needs an access review and a proposed claim needs the correct wallet authorization.

A signature, transaction identifier or submitted transaction does not alone prove token receipt. Paying more claim gas does not add reward tokens to an underfunded escrow. The party sending campaign funds needs to investigate a transfer sent to an unintended chain or address. Any recovery depends on that transfer and the contracts involved; the setup sponsorship does not establish an automatic reversal or refund.

Cost responsibility changes with the action you choose

Compare the operation’s practical outcome and its applicable conditions before deciding what to fund.

If you only need to create the smart wallet, its no-gas creation terms cover that task. Assess later transactions separately.
If you want a token-reward claim, account for claim gas, any applicable CUBE minting fee and required onchain task spending. Campaign eligibility remains a prerequisite.
If you need to distribute fixed token rewards, size the escrow budget from the per-user amount and participant cap. Sponsored setup gas does not supply reward inventory.
If you need Builder submission access, account for the L3 stake locked on Ethereum Mainnet for at least 12 months and two-factor authentication. Submission remains subject to campaign review.
If you want to swap or bridge assets, assess the proposed route’s charges and output. For trades above the conversational beta’s displayed US$100 maximum, confirm that an alternative input route supports the amount. Inspect any generated transaction before signing it.
If you need staked L3 available for spending, include the chosen lock or the unlocked stake’s seven-day withdrawal period in that decision.

Everyday questions about Layer3

Can a creator remove an allowlist spot after the wallet claims it?: A creator cannot remove a claimed allowlist spot. Campaign management permits removing unclaimed spots and shows claimed and remaining places. A completed claim retains its claimed-place record, so removing an unused place cannot reverse another wallet’s earlier claim.
Does an Activation’s ENS check require a new name purchase?: The ENS Imported action checks whether an ENS name connects to the user’s Layer3 profile. An existing connection addresses that check; other required actions can impose separate conditions. The check itself does not specify a new name purchase. Assess any spending required by the other actions separately from the final claim’s gas.
What does the staking screen’s combined balance include?: The “Staked + Rewards” figure includes staked L3 and accrued staking rewards. Individual stakes retain their own sizes and durations, with management under “Your Stakes.” The combined display does not mean all its tokens are immediately available in the wallet. Access to principal follows each stake’s lock and applicable withdrawal conditions.
Will minting a CUBE automatically make a future airdrop payable?: A CUBE records Activation completion, while a future airdrop has its own eligibility and claim conditions. Creators can use CUBE data to identify audiences for later campaigns. A recorded completion does not specify the token amount a later campaign will distribute to that wallet, so the credential alone does not establish a payable allocation.
Can a campaign require earlier CUBE mints before its reward claim?: A creator can use the CUBEs Minted action to check a user’s previous mint count, optionally on specified chains. This eligibility check differs from minting the current Activation’s completion credential. Earlier activity can therefore form part of a campaign’s requirements, and paying the current claim’s gas does not substitute for meeting them.
Does a conversational trading request authorize a transaction by itself?: A conversational trading request does not replace wallet authorization. The conversational-agent panel is labeled beta and displays a US$100 transaction maximum. Inspect the proposed transaction before signing it; requests above the displayed maximum fall outside the agent’s stated scope. A route shown in transaction review describes a proposed operation, while successful execution determines its outcome.

13th October 2026 · last updated