[ANN] Last Pixel — On-Chain Survival Game With Smart-Contract Prize Pool

[lastpixellive]

Hi everyone,

Last Pixel is a social experiment about the value of persistence. In online games, usually luck, hype or the algorithm wins. Here it's the opposite: the winner isn't the one who guessed right, but the one who doesn't give up. 1,000,000 people press a pixel on a shared canvas again and again, confirming: "I'm still here." Window after window the field empties out, and the canvas becomes a living map of human attention — you watch how, out of a million, only one remains. This is neither a lottery nor a bet, but a collective story about patience, where every pixel is someone's decision not to give up for one more window. The last survivor takes the entire prize pool — because persistence beats luck.

Launching Last Pixel — a live on-chain survival game on Base where one final active participant wins the entire locked prize pool.

This is not a token sale, ICO, or investment product.

It's a long-form elimination game based on timing, consistency, and survival.

How it works

• There are 1,000,000 total pixels
• Anyone can claim one for $3 (crypto)
• Each pixel is assigned randomly and permanently
• Every active window, participants confirm they are still active with one click
• Missing a window means permanent elimination

The first window lasts 24 hours. Each following window becomes 10 minutes shorter. This continues until only one active participant remains. That final survivor wins the entire live prize pool.

Referral rewards

• Earn $0.30 USDC for every direct paid invite — paid instantly in stablecoin
• No cap on invites: your earnings scale with your network
• Rewards are tracked transparently and verifiable on-chain
• Separate on-chain leaderboard reward pool for top referrers — extra on top of the base commission
• Best part: you keep earning from your referrals even after you're eliminated from the game

Early entry advantage

• Window 0 starts at 24 hours
• Every next round becomes shorter
• Earlier players begin under easier survival conditions
• Later rounds become increasingly more demanding

Trust-minimized design

• Prize pool is locked inside a Base smart contract
• Team cannot withdraw participant funds
• Team wallets are excluded from winning
• Participant snapshots are committed on-chain via Merkle roots
• Public verification data is published for every round
• If snapshots stop for more than 5 days, participants can trigger refunds

Smart contract (Base)
0x1D03EE835CB592A72e4127BA05cCAa0437FDfe72

Project links
Website: https://lastpixel.live
Audit: https://lastpixel.live/audit.html
FAQ: https://lastpixel.live/faq.html
Telegram: https://t.me/lastpixellive

Questions welcome.

[SFR10]

FAQ: https://lastpixel.live/faq.html

I quickly went over your FAQ page and the part that mentions "how the money will be returned if your project stops" caught my attention... From what I understand, funds will be returned to the wallets on our dashboards, but doesn't that mean they're still under your control? Am I missing something?

[lastpixellive]

FAQ: https://lastpixel.live/faq.html

I quickly went over your FAQ page and the part that mentions "how the money will be returned if your project stops" caught my attention... From what I understand, funds will be returned to the wallets on our dashboards, but doesn't that mean they're still under your control? Am I missing something?

Thanks for the question — it's about the most important part, trust. Let me answer from the actual code.

The funds are not held in any team wallet, and we don't "send refunds" manually. The entire prize pool sits inside the smart contract on Base, and the team has no withdraw function — the pool can only go to the winner, or back to participants in refund mode.

Emergency path (dead-man switch):
– If the activity snapshots aren't updated for more than 5 days, anyone can call triggerDissolution() — not just the team.
– Refund mode turns on. The contract uses a "lag-frozen" Merkle root from two commits earlier — so a malicious root published right before vanishing can't be used.
– A 48-hour window applies so everyone can verify the refund data against the public snapshot (also published to an open GitHub repo with an immutable history).
– Then claimRefund sends funds strictly to your own dashboard address — even if someone else submits the transaction, the money can only go to the owner. Nobody, including the team, can redirect it.
– The undistributed referral pool in this scenario doesn't go to "top referrers" — it's returned to participants together with the prize pool.

The team receives nothing and doesn't control the distribution — it's all hardcoded. Verify it yourself in the contract: 0x1D03EE835CB592A72e4127BA05cCAa0437FDfe72 (triggerDissolution, claimRefund).

On referrals, since it came up: referral rewards are not locked until the game ends. Each payment is split at the moment it's made, and the referral share lands in your wallet right after your invitee's paid signup — no need to wait for the marathon to finish.

For full transparency: what's locked and verifiable on-chain is the prize pool (and the emergency refund). Referral accounting is handled by the payment system at the time of payment — that's why it's fast, but it's part of the backend, not the contract's on-chain logic.

[internetional]

First of all, respect for making the contract immutable. That is quite rare these days, even though immutability was originally one of the main features of smart contracts.

Second, I have a question. I see that the contract has an administrator, or owner, and also a committer. Usually, administrators or privileged roles have special rights that regular users do not have - that is the whole point of defining such roles in a smart contract.

Could you please clarify what rights the owner and the committer have in your contract?

You wrote:

The team receives nothing and doesn't control the distribution — it's all hardcoded.

So they cannot influence the following functions: proposeWinner, proposeLeaderboard, cancelWinner, cancelLeaderboard, setExcludedWinner, freezeExcluded, finalizeWinner, and finalizeLeaderboard. Is this correct?

And if they cannot influence the distribution of tokens in any way, then what is the practical purpose of having the owner and committer roles in this contract?

[lastpixellive]

First of all, respect for making the contract immutable. That is quite rare these days, even though immutability was originally one of the main features of smart contracts.

Second, I have a question. I see that the contract has an administrator, or owner, and also a committer. Usually, administrators or privileged roles have special rights that regular users do not have - that is the whole point of defining such roles in a smart contract.

Could you please clarify what rights the owner and the committer have in your contract?

You wrote:

The team receives nothing and doesn't control the distribution — it's all hardcoded.

So they cannot influence the following functions: proposeWinner, proposeLeaderboard, cancelWinner, cancelLeaderboard, setExcludedWinner, freezeExcluded, finalizeWinner, and finalizeLeaderboard. Is this correct?

And if they cannot influence the distribution of tokens in any way, then what is the practical purpose of having the owner and committer roles in this contract?

Good question — and a fair correction to make first: the team is not "unable to influence" those functions. There is influence, but it's bounded — the roles can only propose, cancel, or block; never redirect funds.

committer (hot gas key): publishes the snapshot root (commitDailyRoot), and can proposeWinner / proposeLeaderboard. But a proposed winner must be provably in the latest published snapshot as active (Merkle proof, lastActiveCount == 1, not excluded), and leader payouts are capped to ≤3 addresses and ≤ the accrued pool. It cannot name an outsider or exceed the pool, and it cannot finalize or withdraw anything.

owner (2-of-3 multisig): an emergency brake, not a hand on the wallet. It can cancelWinner / cancelLeaderboard (only cancel a pending proposal in the challenge window), setExcludedWinner (only bar addresses from winning — that's where team addresses go), freezeExcluded, rotate the committer via timelock, and set the audit URL. It cannot name a winner, withdraw the pool, or speed up a payout.

Who actually pays out? finalizeWinner, finalizeLeaderboard, claimRefund, triggerDissolution are permissionless — anyone calls them after the window. The payout needs neither role.

Why the roles exist: all heavy logic (pixel accounting, referrals) is off-chain, so committer must push the root and propose — strictly inside published data. owner is the kill switch to cancel a wrong/challenged proposal.

Worst case — full collusion of both. They still can't take the pool. The most they can do is stop publishing snapshots; after 5 idle days the dead-man switch lets anyone call triggerDissolution, returning the pool (plus leaderboard escrow) to participants via claimRefund. So there are exactly two outcomes: (a) the legitimate winner from the public snapshot, or (b) a refund to everyone. "Funds to the team" is simply not a function that exists in the contract.

[lastpixellive]

The affiliate program is now live.

• Earn $0.30 USDC for every paid referral.
• On-chain referral tracking.
• Additional leaderboard rewards.
• No earning cap.

More details:
https://lastpixel.live