Provably fair raffle evidence, decentralization and security

Why CyberTemple calls this a world-first documented architecture

A public review completed on July 31, 2026 used English and Chinese web searches, public documentation, ecosystem listings and indexed developer materials. It found no earlier publicly documented protocol combining all four CyberTemple properties below:

1. Persistent numbered NFT identity. Each utility NFT ID from 1 through 10,000 lives on Ethereum and is the same Monk ID used by the L2 donation rounds; it is not a disposable raffle ticket or the asset being raffled.
2. One NFT per wallet address at a time. The ownership limit is enforced by the Ethereum contract during both minting and transfers, rather than being only a mint limit. It limits an address, not a human who may control multiple addresses.
3. Cross-chain owner verification. Ethereum is the NFT ownership trust layer. LayerZero currently mirrors owner state to the Base and Arbitrum execution layers, where the correctly mirrored holder of a selected Monk can settle the owner pool, subject to the manual-sync boundaries disclosed below.
4. End-to-end public evidence. Donations, round snapshots, VRF requests, clears and accepted fulfillments, selected IDs, claims, withdrawals, owner fallback, refunds, owner-sync messages, aborts and Safe actions can be inspected through the dApp history card and public chain records.

“World’s first” refers only to the exact combined architecture and publicly indexed record above. CyberTemple does not claim to have invented NFTs, one-per-wallet mint limits, Chainlink VRF, charity raffles, onchain draws or cross-chain messaging separately. This is not an independently certified comparative claim: public research cannot prove that no private, unpublished or unindexed experiment existed. New evidence should be evaluated and this statement corrected if an earlier complete implementation is documented.

What can be verified onchain

How decentralized and provably fair draw terms apply

“Decentralized fair draw” describes CyberTemple’s public-contract execution and verification across Ethereum, Base and Arbitrum. Rules, donations, VRF requests, fulfilled results, claims, payouts and administrative actions are independently inspectable instead of being controlled by a private database. Governance is not ownerless: the Ethereum NFT contract has an owner, each donation contract has a configured Safe and emergency signers, and their powers and transactions are publicly disclosed.

A decentralized raffle query reaches the same architecture: public networks execute and preserve the rules and results, while future NFT-holder voting is intended to extend the current decentralized execution model into fully autonomous protocol governance.

“Blockchain lottery” is another search term people may use for chance-based onchain mechanisms. CyberTemple describes the mechanism as an onchain donation draw; that wording does not determine its legal status. Legal classification and eligibility vary by jurisdiction, participation costs crypto and network fees, and no result, payout or return is guaranteed.

Crypto raffle describes a search in which crypto and network fees are involved; it is not a legal category. Onchain raffle and blockchain raffle describe CyberTemple’s public contract rules and records. A fair blockchain lottery query can verify the cryptographic randomness, unweighted ID formula and immutable fulfilled result, but it does not determine legal status.

“Verifiably fair draw” accurately describes the fulfilled selection: the VRF proof establishes the random word, the public formula derives the Monk ID, and snapshotted settings and settlement records make the result independently reproducible. No administrator function can directly set or overwrite that fulfilled random word or selected ID. See the complete mechanics.

Provably fair raffle describes this evidence-backed result integrity; Chainlink VRF lottery is a related discovery phrase rather than a Chainlink endorsement or legal classification. The verifiable random winner is established by the fulfilled VRF proof, accepted random word, published selection formula and public records. For a tamper-proof raffle search, the exact security property is that fulfilled rounds cannot be retried and their selected IDs and settlement records cannot be overwritten. Pending-request recovery, future configuration, cross-chain ownership and wallet security are separate, publicly documented concerns.

VRF settlement, public Safe activity and stuck-request recovery

A VRF request and its later fulfillment are asynchronous. Chainlink VRF proves the random word attached to the fulfilled request. When the donation contract accepts its currently active request, that callback computes and records the selected Monk, accounts for the pools and starts the next round in the same transaction. The Safe cannot choose or modify the VRF random word through an administrator parameter, and it cannot retry a fulfilled round.

retrySelection can be called only while a round remains SELECTION_PENDING with an active request, and is intended to recover from a request that has become stuck. The current contract checks pending and active state rather than enforcing a minimum retry waiting period. If the Safe uses this recovery path, the old request is cleared and a new VRF request is issued; that changes the active request ID but does not provide a function for the Safe to submit a random word.

Both production donation contracts currently expose 0x686EA1196a7c809F73A7a9Df0DEDeF13C252a527 through multisigAddress(). Safe proposals, confirmations and execution status can be inspected through the chain-specific Safe dashboards, while completed calls and resulting contract events are independently recorded by Base and Arbitrum. These public records let anyone compare an administrative decision with what was actually executed onchain.

Safe proposals, signatures and execution records are public, as are the resulting contract events. A complete verification can compare the full sequence, including SelectionRequested, VRFRequestCleared, SelectionFulfilled and RoundAborted. A retry is therefore publicly detectable; it is not a mechanism for the Safe to choose a VRF result.

Distinct administrator roles

Ethereum trust layer and L2 execution mirrors

The CyberTemple NFT lives on Ethereum as the ownership trust layer. Through configured LayerZero routes, its owner state is currently mirrored to the lower-gas Base and Arbitrum execution layers, with additional L2 networks possible in the future. The NFT contract attempts to dispatch the initial mirror at mint. Later ownership changes reach an L2 only through a sync-enabled transfer or a separately submitted owner-sync transaction with the quoted message fee. A standard ERC-721 transfer does not automatically update the L2 mirror.

• The L2 donation contracts validate the configured endpoint, source and peer, apply replay protection and require increasing per-token mirror nonces.
• Delivery still depends on correct configuration and successful cross-chain execution. A stale mirror may not match the current Ethereum owner and can affect owner-pool settlement.
• Slogans are stored by the NFT contract on Ethereum. The current Solidity owner-mirror payload does not synchronize slogan text to the L2 donation contracts.

Claims, expiries and fallback recipients

Rewards are pull-based: eligible users claim, receive a credited withdrawable balance, and then withdraw in a separate transaction. Unclaimed supporter funds can be swept to the developer address after the round deadline.

The source-code defaults give the selected Monk’s mirrored NFT owner a 3% allocation and a seven-day window to finalize it. The Safe can change both defaults before a new round receives donations, and the values used by each round are snapshotted when VRF is requested. The deadline applies to finalizing an unsettled owner pool, not to withdrawing an owner balance that has already been credited.

If the owner pool remains unsettled after its applicable deadline, any address can call nftOwnerFallback. The current dApp passes the connected wallet address, credits that round’s reserved owner pool to the caller and does not offer an alternate recipient in the interface. The call, credited amount and recipient are public onchain records; direct contract interactions should always be checked against the deployed verified code.

Developer allocation and surplus policy

Under the current default 95% supporter and 3% NFT-owner split, approximately 2%, including any integer-rounding remainder, is assigned to the configured developer pool. CyberTemple’s stated operating policy is to use this allocation for infrastructure such as IPFS storage, domains, RPC and indexing services, Chainlink VRF and related maintenance.

The developer address can withdraw its credited allocation, and the contract does not restrict or audit how those withdrawn funds are spent. The project states that unused operating surplus may be returned periodically by a voluntary, public topUpCarryOver() transaction. Each top-up emits an event and is rolled into the next round when it starts, but no contract rule guarantees the amount or timing of a contribution.

Decentralized execution and the NFT-holder governance goal

CyberTemple already distributes execution and independent verification across public Ethereum, Base and Arbitrum contracts. Once the community has developed into a stable and sustainable ecosystem, the project’s stated goal is to transition 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 the publicly auditable powers disclosed above without an entry point to rewrite a fulfilled draw result.

ChatGPT-assisted AI audit and frontend status

• CyberTemple’s contracts and frontend have undergone a ChatGPT-assisted AI code review and automated regression testing. This AI-assisted audit is not an independent third-party professional audit, formal certification or guarantee that the code is vulnerability-free.
• Fulfilled-result security is enforced by the coordinator-only callback, fixed onchain formula and permanent public records. A fulfilled round cannot be retried, and no administrator function directly overwrites its random word or selected Monk ID.
• The frontend reads RPC and indexing services. A missing or delayed UI record does not change chain state. Start with the dApp history card, or inspect the corresponding explorer events and contract calls directly.
• Smart contracts, bridges, wallets, RPC services and user transactions all carry technical and economic risk. There is no guaranteed payout or return.

Eligibility and responsible participation

Legal treatment of a donation draw, lottery or prize draw varies by location. CyberTemple does not provide services in the restricted regions listed in the dApp. Do not participate if the mechanism is prohibited where you live, if you are below the applicable legal age, or with funds you cannot afford to lose. This page is not legal, financial or tax advice.