Layer3 CUBEs record completed Activations after access and action checks pass
What should you check before your first Layer3 CUBE mint? Confirm the participating wallet, audience access, action checks and credential network. Layer3 CUBEs record Activation completion when an eligible participant mints the campaign’s onchain credential. Each Activation defines its own tasks and incentives; viewing its page does not establish eligibility. Some checks inspect existing holdings or past transactions, while others require a new action or an earlier Activation. Keep the initial review to reading requirements and checking existing records. Stop before signing any transaction until the network, expected cost and reward conditions are clear.
A wallet and an Activation offering a CUBE form the starting point
Audience settings control access, action checks establish eligibility and minting records completion on the selected chain. Review these components together before deciding whether to proceed.
- For an address-specific check, match the participating wallet to the required activity. Another wallet’s record does not establish that address’s eligibility.
- Confirm the Activation includes a CUBE credential in its rewards. A promise of XP alone does not establish a CUBE mint.
- Read the audience restriction and check the participating address against it. Opening the task leaves an allowlist restriction unchanged.
- Inspect each required action and its verification result. An unmet dependency remains unresolved even if later actions already match.
- Identify the credential’s chain before considering the claim. An unexpected transaction network is a reason to stop before signing.
Does opening an Activation mean my wallet is eligible?
Opening an Activation does not establish eligibility; its audience rules and required actions determine whether your wallet qualifies. Public Activations appear in discovery and private ones use direct links; an allowlist restricts participation to specified wallet addresses. These access settings do not replace the campaign’s action checks. A task can be visible while your wallet still lacks a required holding or qualifying interaction.
For an allowlisted Activation, the participating address must appear on its list. Control of another wallet does not extend that eligibility.
Timing and capacity also affect readiness. Activation details include duration and scheduling, and token-reward campaigns can cap the number of participants. Read the stated window and any cap before committing funds to a prerequisite action. Dates and thresholds belong to their named campaign, so an earlier promotion does not establish current access. A configured participant cap limits how many users can complete the Activation and claim its token reward.
Action checks match the wallet to specific evidence
A qualifying record must match the action the Activation asks Layer3 to verify. Holdings checks inspect the specified asset or balance. Contract-interaction checks inspect transactions involving the required contract; asset ownership answers a different question. The Interact with EVM Contract action can restrict qualifying interactions by method and date range. Previous transactions can therefore help only when they meet the configured criteria. A recent transaction with the wrong method can still miss the check.
Other requirements concern account connections or submitted responses, so transaction history cannot resolve every unfinished step. Quizzes test knowledge and polls collect feedback. An Activation can also require completion of another specified Activation. That dependency must pass before the current task meets all its requirements. A first session may therefore begin with the prerequisite task. Identify that dependency before spending on an action farther along the sequence. A required CUBE count can also inspect mints on specified chains, which matters when choosing an accessible first task.
What changes after an allowlist check fails?
The address used for the next check must match the campaign’s allowlist to clear that access restriction.
In a hypothetical first-mint attempt, the Activation uses an allowlist, the connected wallet is absent and another wallet you control is listed. Both wallets have activity matching the same required contract interaction.
The unlisted address fails the audience check even though its action evidence matches. Sending another transaction from that wallet does not add it to the uploaded address list. The listed wallet passes this particular access check.
Before signing, inspect the wallet address and the campaign’s restriction. The retry uses the listed wallet’s address and its own action evidence. It clears the audience mismatch in this example, while scheduling and other claim conditions still apply. Reading the requirements and checking existing activity commit no onchain funds; authorizing a new transaction would end that read-only review.
Review prerequisite and claim costs before signing
Eligibility review can stay read-only: inspect requirements and existing wallet records before authorizing an onchain action. Transfers and contract interactions can commit funds before the credential mint. A later pause before the claim cannot undo those earlier actions. Stop before the first required transaction whenever access, network or action requirements remain unresolved. Any onchain prerequisite deserves its own review, even when the final CUBE claim comes later.
In token-reward Activations, users pay gas for claiming; a successful claim mints the CUBE and delivers the configured tokens in a single transaction. The reward token uses the credential’s chain. Campaign funding supplies the reward inventory; it does not establish that the participant has claim gas. Check any CUBE minting fee alongside the wallet’s displayed cost estimate before signing. A price quoted for another mint, chain or earlier campaign does not determine this claim’s cost.
The credential’s onchain Activation details and action evidence can associate a wallet with a particular campaign. Creators can use CUBE holder lists to target follow-up Activations or build allowlists.
A successful mint supplies the completion record
Passing checks or reviewing a transaction does not establish a completed CUBE mint.
On Ethereum Virtual Machine (EVM) networks, CUBEs use the ERC-721 standard for non-fungible tokens (NFTs); Solana CUBEs use compressed NFTs. Their data includes the associated Activation and community plus proof of its actions, such as transaction hashes. A CUBE records when its Activation was completed. An action’s transaction hash alone does not establish a successful credential mint. Check the successful mint transaction and the resulting credential on the intended chain. Where the claim includes token rewards, inspect the received reward separately from the credential record. That record identifies the completed Activation if a later task requires it as a prerequisite.
Layer3 CUBEs: common questions
Does an NFT purchase qualify for an EVM mint check before claiming a CUBE?
The Mint NFT action checks for an ERC-721 or ERC-1155 mint from the null address, which a secondary-market purchase does not provide. An ERC-1155 requirement can also specify a token ID for the required edition. Ownership alone answers a holdings check, so read whether the Activation asks for minting or possession before spending on an NFT.
Why can a Telegram membership check remain unmet before minting?
A Telegram membership check requires joining the specified group and connecting your Telegram account to Layer3. The campaign must also have the Layer3 bot in that group for verification. That setup belongs to the group’s administrator. Membership alone does not fulfill a separate account-connection requirement, and connecting an account does not establish membership in the required group.
When does a countdown delay access to the CUBE claim?
A Time Gate action imposes the waiting period configured for that Activation. Its countdown concerns a workflow requirement and does not measure blockchain transaction confirmation. The duration belongs to that action’s configuration, so a waiting period attached to another campaign does not determine when this task can continue.
Can a required wallet application affect my first CUBE eligibility?
A Specific Wallet Apps action can require use of the wallet application specified by the Activation. That check concerns application usage, which differs from owning assets or interacting with a contract. Match the listed requirement to the wallet you intend to use before authorizing a task transaction. Chain compatibility alone does not establish that this application-specific condition passes.
What score matters when an Activation uses Gitcoin Passport?
A campaign using the Gitcoin Passport Score action chooses the score threshold the participant must meet. This score check differs from a CUBE count or token balance. Passing it does not satisfy separate onchain or account-connection requirements; it does not establish completion of the entire Activation.
Can an offchain task qualify me for a CUBE?
An Activation can use a Custom API Integration to verify a task completed in an external system. That integration supplies custom verification for the specific action; the resulting CUBE still records Activation completion onchain. The campaign’s configured check determines whether the external task qualifies. Other required actions remain part of the same Activation’s completion conditions.
Do I need a Builder Space to mint my first CUBE?
No. Participants mint through existing Activations; Builder Spaces organize creator campaigns. Creating a Space, enabling two-factor authentication and unlocking submission access concern publishing Activations for review. The participant-facing requirements on the selected Activation determine mint eligibility. L3 staking to unlock Builder submission addresses the campaign creator’s role.
· last updated