Upcoming ICPLAY SNS Decentralization Sale

[cryptoschindler]

DFINITY rejected the ICPLAY proposal due to several concerns, including but not limited to:

• Lack of demonstrated Product-Market Fit (PMF): Although the concept may have potential, the existing product is minimal (only one playable game), and clear traction metrics have not been provided to validate PMF.
• Voting power distribution and vesting schedules are not transparently articulated.
• Inconsistencies between proposal summary and actual SNS payload

[Laurie]

Firstly,

The following page in our whitepaper presents the results from our recent open beta test:

https://icplay.gitbook.io/docs/open-beta-round-icp-giveaway

This BETA test was available via a shared link on X. Given a chance to try the game, users experienced the full loop, from II login to prize distribution in ICP. While we didn’t promote it widely, the test was open and real, and all the stats reported were collected directly from actual user sessions. The data is based directly on real user activity, and we believe it offers early evidence of PMF.

We started with one game by design. This single game let us test real spending, real prizes, and real user behavior in a clean way to prove the model.

Secondly,

To better align with community expectations, we’ve made the following adjustments:

minimal_disolve_delay: 1 month

MaximumVotingPowerBonuses
DissolveDelay:
duration: 24 months

(Vesting schedules have been updated accordingly)

event: 4
interval: 2 month

Subsequently, our team’s voting power share has been lowered to 37.3%, and any inconsistencies in the proposal summary have now been corrected.

And lastly,

The inconsistencies in the proposal summary have now been corrected as:

  * Min participation - 5 ICP
  * Min participants - 5
  * Min to be raised - 20,000 ICP
  * Max to be raised - 150,000 ICP

We’ll continue posting more content on X and hosting Spaces to encourage more interaction.

https://x.com/ICPLAY_APP

Stay tuned!

[Lorimer]

@Laurie

Subsequently, our team’s voting power share has been lowered to 37.3%

Could you confirm what dissolve delay this percentage assumes? Thanks.

[Laurie]

@Lorimer

Could you confirm what dissolve delay this percentage assumes? Thanks.

The 37.3% VP is based on a 1-month dissolve delay.

[Lorimer]

Thanks. Could you confirm what that percentage would jump to if you reconfigured the dissolve delay to the maximum (2 years) immediately after the vesting scehdule (assuming community participant neurons remain unchanged in this respect)?

Could you also comment on why the dev team is opting for such short dissolve delays (and vesting schedule)?

[Laurie]

Thanks for the follow-up. Happy to provide clarity.

If dissolve delay is reconfigured to the full 24 months after vesting, team VP would increase based on the +100% bonus defined in the config. (Although the Tokenomics Analyzer doesn’t calculate the VP at a 24-month setting under current parameters.)

Unlike governance-only tokens, $PLAY has a dual role (not just for voting): it’s also the core redemption asset for game rewards. That means the treasury must remain liquid for player payouts and buybacks, and the system needs flexibility in managing inflows and conversions.

The short dissolve delay helps us stay agile in the early stages, especially when player activity, redemption demand, and treasury needs are all in flux. It’s a product-first design choice.

We’re still open to tuning parameters based on community feedback — but from a game economy perspective, this approach lets us deliver faster and respond to real user behavior.

[Lorimer]

@Laurie

If dissolve delay is reconfigured to the full 24 months after vesting, team VP would increase based on the +100% bonus defined in the config

By my back of the envelope calculation you’d end up with 54% VP.

@Laurie

from a game economy perspective, this approach lets us deliver faster and respond to real user behavior

The name of the game is decentralisation, or you shouldn’t be launching an SNS.

[Laurie]

Hey Lorimer,

I may not be able to explain every internal decision in full detail here, but I now genuinely understand where your concerns are coming from. We’ve taken them seriously and made adjustments accordingly. I believe the current setup reflects a much more balanced approach that aligns closely with the intent behind your suggestions while still allowing us to move forward.

Minimum Dissolve Delay: 1 month→6 months,

DissolveDelay bonus: 100% →10%,

Age bonus: 20% →5%

    minimum_dissolve_delay: 6 months
    MaximumVotingPowerBonuses:
        DissolveDelay:
            duration: 24 months
            bonus: 10%
        Age:
            duration: 12 months
            bonus: 5%

Vesting Schedule, events: 4→6, interval: 2→3 month

VestingSchedule:
        events: 6
        interval: 3 month

The VP now allocates:

Even if the team maxed out dissolve delays, the developer VP would remain capped around 44%, under current tokenomics.

The changes have been updated to SNS_init.yaml

Appreciate your help again in guiding toward meaningful improvements.

[Lorimer]

Thanks @Laurie, this sounds much healthier. I’ll take a closer look at the yaml again when I get a chance, but sounds like you’ve addressed that issue nicely.

---

I’ve revisited the answers to my other questions, and I’d like to have a clearer understanding of what (if any) components do not reside on-chain (and where they instead reside, and what they’re responsible for).

Would you also be able to provide some screenshots and more details about the existing game given this is what you’re attempting to decentralise? (other things are suggestions for the future - but the future is unknown, particulalry when it’s controlled by a DAO).

[Laurie]

ICPLAY is a play-to-win casual gaming platform where players compete in simple, addictive games for real token rewards.

What’s basically being decentralized here,

• A working prize-based gaming system

• A DAO-led development model

• A revenue-backed token system

---

A working prize-based gaming system

The current game, Play Your Cards Right (PYCR), is often seen as a standalone game. We are proving the core mechanics (real money entry, fair competition, on-chain rewards) that actually demonstrates the product loop being built around.

The prize-based gaming system handles the full loop: user login, gameplay, score submission, leaderboard ranking, and automated prize distribution via smart contracts, which gives us a foundation to build the larger platform on.

From here, the system can scale to support multiple games, community governance, creator submissions, and broader reward formats. It’s the base unit of the full ICPLAY experience.

@Lorimer

I’d like to have a clearer understanding of what (if any) components do not reside on-chain

The primary business logic including user identity, session tracking, leaderboard scores, entry validation, payments, prize pool management, and token distribution, is handled by the set of modular canisters. Unity WebGL game client is hosted inside a frontend canister. However, we’re aware that bundling Unity within a canister contributes to longer loading times, and this is something we’re actively working to improve through ongoing optimization.

During the beta round, we did deploy another off-chain server to assist in recording most user behavior data for analytical purposes. This was to improve performance during testing and enable faster collection and filtering of stats.

---

A DAO-led development model

Since the dev team has experienced difficult projects in the past, some of which suffered from closed-door decision-making, some lacking community support and overly reliant on a single entity. We’re trying to avoid the traditional model of building everything in isolation and only handing over control after key choices are already made.

The aim is to form a DAO that actively guides product development, funding, and platform expansion. With new structures over the current SNS framework:

1. Milestone-Based Treasury Proposals

   • Devs and creators get funded based on delivery, not promises.

   • DAO approves each stage (build, test, release).

2. Game Selection by Governance

   • Anyone can propose new games, whether to be developed by the core team, external creators, or the community itself.

   • DAO votes based on fun, fairness, fit with platform.

3. Creator Grant Pool

   • DAO allocates funds to support external games (can be generated from Caffeine.ai) or features.

   • Transparent usage reports required.

4. Treasury Sub-Pools

   • Split into developer support, platform ops, growth fund, and liquidity/buyback reserve.

   • DAO controls allocation weights.

5. Governance Constraints

   • Soft limits: cooldown periods, spending caps, limited proposal frequency.

Of our opinions, the benefits of this model over traditional development:

1. Early accountability

   • DAO approves funding only when output is proven.

2. Transparent roadmap

   • Everything runs through public proposals.

3. Community-driven direction

   • Games, features, and incentives come from actual community.

4. Resilience

   • No centralised kill-switch. Platform grows even if team changes.

5. Aligned incentives

   • Everyone who contributes (devs, voters, players) shares in value creation.

The innovation in this development model lies in how it merges real-time product growth with decentralized decision-making. It’s governance as part of the build.

---

A revenue-backed token system

As described in the whitepaper, (https://icplay.gitbook.io/docs/revenue-model)

ICPLAY uses a revenue-backed token system where the value of the $PLAY token is directly tied to player activity (not speculation or inflation).

Players pay entry fees to join games. A portion of that inflow is used to purchase $PLAY from the open market, which is then distributed as prizes to winners. This creates a natural demand: the more people play, the more tokens are bought and circulated.

Unlike other play-to-earn models that rely on emissions or unsustainable yields, ICPLAY’s token economy is grounded in real, verifiable spending. The DAO can further adjust inflow-to-reward ratios, trigger buybacks, or allocate treasury funds. The DAO governs how value is sustained and how the platform grows over time.

---

To give a clearer sense of where ICPLAY is headed, we’re also sharing a few designed interface previews for mobile apps:

[Lorimer]

Thanks @Laurie

@Laurie

Unity WebGL game client is hosted inside a frontend canister

Does this mean tech savy users could cheat to win more money by modifying what’s running in the browser?

Out of interest, what are the game rules for ‘Play Your Cards Right’?

[Laurie]

Thank you,

@Lorimer

Does this mean tech savy users could cheat to win more money by modifying what’s running in the browser?

The current setup follows a classic server-authoritative architecture, widely used in real-time online games.

There are typically two implementation models:

1. Backend as the sole authority, with the client acting as a presentation layer (in single-player or casual experiences).

2. Shared logic between client and backend, with client-side prediction while the backend remains the final authority (in multiplayer games).

In both cases, backend is responsible for determining the actual game outcomes. The client simply sends intent (“what I want to do”), and the backend decides the result (“what actually happens”). It’s standard in modern online gaming, as it effectively balances performance and security.

@Lorimer

Out of interest, what are the game rules for ‘Play Your Cards Right’?

Play Your Cards Right or Card Shark (to players from the USA) is a game where you simply have to guess whether the next card will be lower or higher than the last.

As in the well known TV gameshows there are no points for two of a kind although the game continues. The Joker cards are double points & a guaranteed win whether you choose lower or higher. If you draw a middle value card like a 7 for example you can SWAP the card a maximum of 9 times. The 5 highest scores during each gaming period (weekly) win prizes.

[JimmySteve]

I understand and respect this sentiment, however I strongly feel that all forms of democratic voting need to remain anonymous.

[bitel911]

Initial Review of ICPlay SNS Launch Proposal

As an applicant for the Voting Neuron Grants focusing on SNS & Neurons’ Fund topics, I am providing this initial review of the ICPlay SNS decentralization sale proposal

ICPlay is positioned as a skill-based gaming arcade on the Internet Computer, emphasizing real token rewards derived from entry fees rather than inflation, with accessibility through mobile and Telegram interfaces without requiring a wallet.

The proposal outlines SNS governance for revenue distribution, including 40% allocated to prizes and 15% to marketing, with the $PLAY token serving utility functions. The initial game, “PLAY YOUR CARDS RIGHT,” is operational and integrated with NFTs. While the concept demonstrates potential for ecosystem growth through casual gaming, several aspects warrant scrutiny, including governance centralization risks, tokenomics structure, and product maturity. The team has shown responsiveness in the thread by requesting rejection of the current proposal (137563) to address voting power concerns, which is a positive step. Below, I outline key insights, followed by specific concerns and questions for the developers.

Proposal and Thread Summary

The forum post describes ICPlay as a play-to-earn platform backed by fiat and stablecoin reserves, with milestones subject to DAO votes and legal compliance for skill-based games (no gambling license required). The thread (over 30 replies) includes community feedback on technical issues such as loading delays (attributed to 38MB data volume, with alternative links suggested), canister roles (clarified as indexer, user management, platform, and frontend), high developer voting power at genesis (44%, raising attack risks), and inconsistencies in the YAML summary (minimum participation and participants). The team has addressed these by explaining voting power for initial guidance without unilateral control, confirming verifiable features, and acknowledging YAML oversights (file is accurate). Additional suggestions include hosting an X space for transparency, and no Neurons’ Fund participation is requested (YAML confirms false). Supporting resources: Whitepaper (GitBook), GitHub (GitHub - dfinitydeck/icplay-dev), and X (@ICPLAY_APP).

YAML Analysis and Alignment with Guidelines

From the YAML file (icplay-sns/sns_init.yaml at main · dfinitydeck/icplay-sns · GitHub):

• Token Supply: 300 million $PLAY, with 70% allocated to treasury (potentially high for early DAO control), 18% to swap, and 12% to developers (vested over 6-30 months across multiple neurons/principals).
• Raise Parameters: Minimum 20,000 ICP and maximum 150,000 ICP, with per-participant minimum 5 ICP and maximum 100,000 ICP; minimum participants set at 5 (relatively low, which could limit decentralization).
• Vesting Schedule: 6 events every 3 months, providing some anti-dump measures.
• Rewards: Fixed at 1% (initial and final over 3 years, indicating low inflation).
• Dissolve Delay: Minimum 6 months, with bonuses of +10% voting power for 24-month delay and +5% for 12-month age.
• Neurons’ Fund: False, appropriately avoiding issues with the ongoing pause (Proposal 135970).

Alignment with DFINITY guidelines (e.g., thoughts on SNS swaps: DFINITY thoughts on SNS/decentralization swap proposals; voting on launches: DFINITY's voting on upcoming SNS launch proposals):

• Project and Use Case: The skill-based gaming model aligns with ecosystem development goals, offering on-chain entertainment without barriers. However, maturity appears early-stage, with reported loading issues and limited demonstrated traction.
• Tokenomics: The 70% treasury allocation and 44% developer voting power at genesis raise centralization concerns, as guidelines emphasize majority participant control post-genesis. The minimum participants of 5 is low, potentially enabling sybil risks.
• Decentralization and Security: Canisters are specified (four main plus cycles wallet), but questions in the thread about controllers (not all under NNS Root) highlight potential failure points. No audits are mentioned, contrary to best practices for security.
• Syndication and Funding: The post has been active since July, providing adequate time, but could benefit from broader multi-channel promotion. Funding uses are linked to milestones, though expenditure details remain somewhat vague.

Insights on Revenue-Backed Model and Risks

ICPlay’s revenue-backed token model ties $PLAY’s value directly to player activity and entry fees, avoiding inflationary mechanics that plague other DAOs.

This means the token’s price stability hinges on sustained engagement: Fees from games fund prizes (40% of revenue), marketing (15%), and buybacks/liquidity, creating a utility loop where more players = more demand for $PLAY (for redemptions/staking).

If activity drops, revenue tanks, potentially crashing price – opening doors to takeovers like we’ve seen in low-traction DAOs (e.g., cheap stake buys for 51% VP control).

From the thread (post 26), the team explains short min dissolve delay (6 months) keeps treasury liquid for payouts/buybacks, but config offers strong bonuses: +10% VP for 24-month delay, +5% for 12-month age – encouraging long-term holds to counter attacks. Post 28/30 highlight community worries on early dev VP (44% at genesis, risking control if price falls),

but team requests rejection of proposal 137563 to tweak for better decentralization (e.g., higher delays). Unlike pure gov tokens, $PLAY’s dual role (voting + rewards) adds incentive to hold during dips, as low price could attract players for cheap entries, boosting activity organically.
Protections vs. Other DAOs:

• Anti-Takeover: Min 6-month dissolve + bonuses make quick attacks costly (time-locked stake). Treasury buybacks stabilize price during low activity. DAO votes on revenue use (e.g., no dumps) per whitepaper.
• Low Players Risk: If no activity, price falls – yaml’s 70% treasury could be vulnerable (devs/principals hold 12% vested over 30 months, but low min participants=5 risks sybil). Team in thread says focus on product-first (skill games for retention), but no auto-burn/maturity like ICP to prop value.
• Comparisons: Other DAOs (e.g., those with inflation) crash from dumps; ICPlay avoids that, but if players ghost, it’s like a failed economy – cheap $PLAY enables whale buy-ins for VP (51% attack via accumulated stake). Mitigated by vesting (devs can’t dump fast) and DAO oversight.
  Overall, solid safeguards via bonuses/liquidity, but low activity = real takeover threat if price craters. Team’s responsive (fixing VP) is positive – watch resubmit.

Concerns and Questions for Developers
While the proposal shows promise in addressing casual gaming on ICP, several areas require clarification to ensure alignment with DFINITY guidelines and mitigate risks:

• The 70% treasury allocation and initial 44% developer voting power raise concerns about early centralization. How will the revised proposal adjust dissolve delays or vesting to ensure participants hold majority voting power at genesis?
• The minimum participants set at 5 appears low, potentially increasing sybil attack risks. What measures are planned to enhance decentralization in this regard?
• Security audits are not mentioned in the proposal or thread. Can you provide details on any conducted audits or plans for them prior to resubmission?
• Product maturity: Thread feedback highlights loading issues and limited traction. What current metrics (e.g., active users, revenue generated) demonstrate product-market fit?
• Revenue Model Risks: In the event of low player engagement, how will the DAO prevent price crashes leading to potential takeovers, beyond the proposed buybacks and bonuses?
• Tokenomics: With no post-genesis minting, how will incentives be sustained long-term without introducing inflation?

I look forward to the developers’ responses to these points for greater clarity. Community input is also welcome.

[Laurie]

Many thanks, @bitel911. This is an absolutely objective review. I’ll respond to your questions shortly.

[bitel911]

@Lorimer how do i make such a nice looking disclaimer / banner for my posts, teach me Jedi