How CyberTemple’s provably fair blockchain raffle works

How the NFT drives the original combined architecture

CyberTemple’s original NFT-driven architecture combines a specific set of mechanics: one wallet address can hold at most one numbered Ethereum NFT at a time, enforced during mint and transfer; its holder can publish an onchain slogan; LayerZero mirrors owner state to lower-gas execution layers; and the same token ID identifies the Monk used by each L2 round. If that Monk is selected, its correctly mirrored owner can settle the NFT-owner allocation before the round deadline.

This design makes the NFT an ownership and identity layer with contract utility rather than a separate collectible attached only for branding. A public review completed on July 31, 2026 found no earlier publicly documented protocol combining this NFT ownership rule, Ethereum-to-L2 owner verification, matching draw IDs and end-to-end public evidence. The “world’s first” claim is limited to that exact combined architecture; it does not claim the separate invention of NFTs, VRF, raffles or cross-chain messaging. See the exact claim scope and evidence criteria.

Round lifecycle

1. Choose a chain and Monk ID. A participant sends one or more donation units to a Monk ID from 1 through 10,000 on the selected L2. The unit size and minimum units are live contract settings, and network gas is separate.
2. Fill the 10,000-ID set. The contract tracks whether each ID has received at least one unit in that round. There is no scheduled draw time in the contract; the VRF request starts when the distinct supported-ID count reaches 10,000.
3. Request verifiable randomness. At the trigger, the contract snapshots the donation unit, claim windows and payout basis points, then requests one random word through Chainlink VRF v2.5.
4. Select and account for payouts. On a valid fulfillment, the contract computes (randomWord % 10,000) + 1, records the selected Monk ID, allocates the pools and starts the next round.

What affects selection and payout

Why this is a verifiably fair draw

CyberTemple’s draw-result mechanism is a provably fair raffle: every fulfilled round has a cryptographically proven Chainlink VRF word, a fixed onchain mapping and an immutable public result. People using the Chainlink VRF lottery search phrase can verify that evidence directly; the phrase is not a legal classification or a Chainlink endorsement.

The fairness evidence is concrete: Chainlink VRF supplies a random word with a cryptographic proof for a fulfilled request, and the contract applies the public (randomWord % 10,000) + 1 mapping, donation units do not weight the selected ID, and round settings, results, claims, withdrawals and Safe actions can be checked in public records. Every valid ID is processed by the same published mapping rule.

Absolute draw fairness means there is no administrator function that directly sets or overwrites a fulfilled round’s random word or selected Monk ID. A fulfilled round cannot be retried, and its result and settlement trail cannot be rewritten. The Safe’s public pending-request recovery, timed abort and future-round configuration powers are separately detailed on the transparency page.

A verifiable random winner is the Monk ID produced by the proven word and public modulo formula. For a tamper-proof raffle search, the exact security property is fulfilled-result integrity: no administrator entry point can edit that word, selected ID or finalized round. Wallet security, cross-chain owner eligibility and future-round settings remain separate from the fairness of a fulfilled draw.

What makes this an NFT with real utility?

Each Ethereum CyberTemple NFT represents the same numbered Monk ID used by the L2 draw. Ethereum serves as the ownership trust layer, while LayerZero currently mirrors owner state to the lower-gas Base and Arbitrum execution layers. Additional L2 networks may be added in the future. Its utility is implemented in contract code rather than based only on artwork or collectability:

• The ERC-721 transfer hook rejects a mint or transfer to an address that already holds a CyberTemple NFT. An address can therefore hold at most one at a time.
• The current holder can write or replace a slogan of up to 280 bytes for that Monk on the Ethereum contract. The slogan is public onchain data.
• If the matching Monk ID is selected in an L2 round, the correctly mirrored NFT owner can finalize the owner allocation before that round’s deadline. Ownership mirroring has the manual-sync limits described on the transparency page.

The NFT does not currently grant protocol governance rights. Once the community has developed into a stable and sustainable ecosystem, the stated goal is to transition governance to votes by CyberTemple NFT holders and ultimately become a fully decentralized contract protocol that operates autonomously onchain. That future transition is not yet implemented in the current contracts.

Payout settings and claim windows

The source-code defaults allocate 95% to supporters of the selected Monk ID, 3% to the mirrored NFT owner and the remaining amount—approximately 2%, including integer rounding—to the developer pool. These are defaults, not a permanent promise: the multisig can change payout basis points before donations enter a new round. The values used by a round are snapshotted when its VRF request starts.

• Supporters of the selected ID must claim during the snapshotted supporter claim window. After the deadline, anyone can trigger the contract path that moves unclaimed supporter funds to the configured developer address.
• The source-code defaults are a seven-day owner window and a 3% owner allocation. Before the snapshotted deadline, the mirrored Ethereum owner can finalize that round’s owner pool. After the deadline, any address can call nftOwnerFallback and direct that pool to itself. The dApp presents this as a public bounty, passes the connected wallet address and credits the pool to that caller; the interface does not offer an alternate recipient.
• Successful claims become balances in the contract’s withdrawable accounting and are withdrawn in a separate transaction.

Developer allocation and stated operating policy

With the default 95% supporter and 3% NFT-owner settings, approximately 2%, including any integer-rounding remainder, is accounted to the configured developer pool. The project states that this allocation is intended to pay operating costs such as IPFS storage, domains, RPC services, Chainlink VRF and related infrastructure. The contract does not earmark or police how withdrawn developer funds are spent.

The project also states that unused operating surplus may be contributed back periodically through the public topUpCarryOver() function. Such a contribution is visible onchain and the carry-over is included in the next round, but the contract does not require a contribution or enforce its amount or timing.

Past draw information in the history card

The dApp’s history card lets a visitor select or search a previous round and review its onchain round state, selected Monk ID, total pool, donation units, relevant times, supporter settlement status, NFT-owner allocation and recorded recipient. Supporter rows use an indexer to discover candidate donation records, then the interface checks claim and pool data against the contract. No wallet connection is required to read the card.

The quick slider covers rounds from the most recent seven-day period. Entering any valid round number from 1 through the current round opens earlier history directly.

Start with the dApp history card to review a round in one place. You can also verify the same round state and requested, cleared, fulfilled or aborted events directly on the corresponding blockchain explorer. RPC or indexer delays can make the dApp view temporarily incomplete without changing onchain state.

Cyber faith, Taiji (Tai Chi), binary design and decentralization

“Cyber faith” is a cultural search phrase for CyberTemple’s visual and conceptual narrative, not a religious or financial claim. The design is inspired by Taiji (Tai Chi): black and white echo binary 0 and 1 as a metaphor for how complementary opposites create and connect virtual and real-world experience. The project’s stated social idea is ordinary people helping one another. CyberTemple is not a religious institution, charity, place of worship, or source of spiritual or financial promises.

Public execution and independent verification are decentralized across Ethereum, Base and Arbitrum today. Once the community has developed into a stable and sustainable ecosystem, the stated goal is to extend that model by transitioning governance to votes by CyberTemple NFT holders and ultimately become a fully decentralized contract protocol that operates autonomously onchain. Until then, the NFT owner, donation-contract Safe and emergency signers retain publicly auditable powers described on the transparency page; those roles cannot directly overwrite a fulfilled draw result.

Stuck-request recovery, aborts and refunds

A VRF request is asynchronous. When Chainlink fulfills the currently active request, the contract records the selected Monk, accounts for the pools and starts the next round in the same callback transaction. The Safe has no parameter that directly supplies or overwrites a fulfilled round’s VRF random word or selected Monk ID, and it cannot retry a fulfilled round.

While a request remains pending, the configured Safe can use retrySelection for stuck-request recovery. The function checks pending and active state, not a minimum retry timer, and every Safe execution plus resulting clear and request event is public. If a round remains pending, the Safe can abort it after the contract’s three-hour timeout, and an active signer can use the six-hour abort path. Donor-funded amounts from an aborted round become available through self-service refund functions; applied carry-over is returned to the carry-over pool.

See Fairness, governance and risk disclosures before interacting.

Verify a round yourself

1. Open the relevant address from the contract registry.
2. Find the round’s SelectionRequested event and request ID.
3. Check whether that request was fulfilled, cleared, replaced or followed by an abort.
4. Compare the recorded selected ID, pool values, claim state and withdrawals with the contract rules.