Set up the Playground environment.

[boundless-forest]

We previously discussed the reasons for setting up the playground environment in the Slack channel: this environment is intended to provide a more user-friendly and feature-rich testing environment for external users who want to try it out, taking email notifications as an example. To that end, we have already done some work, including deploying the relevant contracts on the Darwinia chain.

The playground environment is consistent with other online DAO environments, using the same deployment method and having the same status.

The following points should be noted:

1. The playground contract currently deployed on the Darwinia chain is unusable. We need to deploy this contract on the Base chain instead of the Darwinia chain. This is a long-term consideration because the Base chain has a larger audience than the Darwinia chain, and we want users of this environment to use an environment they are familiar with as much as possible.
2. We need to provide a faucet page for the playground’s governance token. This page will appear together with the playground on the official digoai website in the future. This way, when others visit the official degov website, they can jump to the playground to try it out directly.
3. Currently, all demo environments are deployed on the Darwinia chain and will be used as testing environments in the future.

[fewensa]

Investigation report: production onboarding plan for playground-dao

Investigation date: 2026-07-23
Corrected: 2026-07-24

Executive conclusion

The Playground contracts recorded by PR #875 and PR #879 are deployed on Darwinia Network, chain ID 46. These existing contracts are the implementation target for playground-dao.

No additional Governor or Timelock deployment is required for onboarding. The remaining work is to add the DAO to the registry and shared indexer, expose the scoped application routes, implement the GTK faucet experience, and validate the full governance and notification lifecycle.

Adding this DAO does not require a new database, a separate indexer deployment, or a SQL schema migration.

Sources reviewed

• Issue #1010
• PR #875 — Add playground governor deployment script
• PR #879 — deploy playground
• Current DeGov contract sources and deployment script
• Public Darwinia RPC and explorer contract data
• Current DeGov Registry schema
• Current application and shared indexer onboarding behavior
• Current Datalens DAO compatibility and routing behavior

No code, database, cluster resource, or deployment was changed during this investigation.

1. Existing deployment

Contract	Address	Creation block
GTK	0xbC9f58566810F7e853e1eef1b9957ac82F9971df	5,873,342
Timelock	0xB8b60FdD7426E202f68dc0Ad2963bb0c1ae41B49	12,086,264
DGovernor	0xF7c7C6F9E8E15E8FAa071a7be3D42d1D391Ffd7a	12,086,268

All three contracts have bytecode and verified source on Darwinia.

The shared indexer configuration has one aggregate startBlock. Because GTK predates the Governor and its transfer and delegation history is relevant, the safe value is the earliest contract block:

startBlock: 5873342

GTK

• Name: Governance Token
• Symbol: GTK
• Decimals: 18
• Voting clock: timestamp
• CLOCK_MODE: mode=timestamp
• Creation transaction: 0x2df7152dfd0b976c4113ef55f1a326e2e04009b3ef69117704c6918fd9bb45a3
• Mint authority: token owner

A GTK balance is not automatically voting power. Users must delegate, normally to themselves, before they can create proposals or vote. The faucet flow must expose or clearly explain this step.

Timelock

• Minimum delay: 180 seconds
• Creation transaction: 0x524d8ea58af482423ad8635e022e1fec941e7b53e63e6e09208fef2e6db14664
• Governor is proposer, canceller, executor, and Timelock admin
• Deployer is not Timelock admin

This is a closed Governor-controlled execution model with no separate emergency administrator.

DGovernor

• Onchain name: DGorvernor
• Creation transaction: 0x6d60d5db9001fdd77ae4c71c4a5e157b7352de0215928361699c789feab57688
• Voting delay: 60 seconds
• Voting period: 900 seconds
• Proposal threshold: 1 GTK
• Quorum: 1 GTK
• Execution: Timelock-controlled

The token and Governor both use timestamp clocks, so voting delay and voting period values are seconds.

The deployed name DGorvernor contains a spelling error. This affects the onchain name and EIP-712 domain but does not prevent DeGov from indexing the deployment. The production configuration must use the deployed contract as it exists.

2. Deployment provenance note

The deployed contracts have the intended Governor, token, Timelock relationship and final roles. However, the public transaction sequence does not exactly match every step in the deployment script committed by #875.

This does not invalidate the deployment, but implementation records should preserve the verified addresses, creation transactions, creation blocks, runtime bytecode hashes, constructor values, and final role state. Those records are important for future troubleshooting and contract provenance.

3. Production onboarding model

The existing DeGov platform uses a shared indexer and shared schema for multiple DAO contract sets. Onboarding playground-dao requires:

1. Add the Darwinia contract set with DAO code, chain ID, Governor, GTK, Timelock, token standard, and exact start block.
2. Register the scoped GraphQL route /playground-dao/graphql.
3. Expose the production endpoint at https://indexer.degov.ai/playground-dao/graphql.
4. Add the public DAO Registry configuration in draft state.
5. Route https://playground.degov.ai to the shared web application.
6. Reconcile the shared indexer so it creates a scoped checkpoint.
7. Backfill from block 5,873,342 to the latest durable Darwinia block.
8. Validate that all returned data belongs only to playground-dao.

No manual DeGov Square database insertion is expected; the existing registry synchronization process should discover the DAO.

4. Faucet requirements

The faucet must be designed as a bounded product surface rather than exposing the GTK owner key directly.

The implementation must define:

• claim amount;
• per-wallet claim policy;
• cooldown or one-time limit;
• rate limiting;
• finite inventory or narrowly controlled minting;
• emergency disable behavior;
• monitoring and inventory alerts;
• user messaging about GTK;
• GTK self-delegation after a successful claim;
• the requirement for a small amount of RING to pay Darwinia transaction fees.

Because the Governor threshold and quorum are both 1 GTK, faucet limits directly affect proposal spam and Sybil behavior.

5. Recommended rollout

Phase 1 — freeze inputs

Record the confirmed Darwinia addresses, creation blocks, governance settings, faucet policy, domain, DAO code, and Registry lifecycle.

Phase 2 — staging onboarding

• Add and validate the Registry configuration as draft.
• Add the scoped contract set and GraphQL route.
• Backfill from 5,873,342.
• Verify checkpoint progress, queue drainage, logs, and DAO-specific metrics.
• Compare representative token, delegation, proposal, and vote data with Darwinia chain state.
• Verify that the Playground host resolves the correct DAO configuration.

Phase 3 — end-to-end validation

Using a fresh wallet:

1. Open the Playground site.
2. Connect to Darwinia.
3. Obtain a small amount of RING for transaction fees.
4. Claim GTK.
5. Self-delegate.
6. Confirm voting power.
7. Create a harmless proposal.
8. Vote.
9. Queue the successful proposal.
10. Wait for the Timelock delay.
11. Execute it.
12. Verify every state transition in the UI and scoped GraphQL endpoint.
13. Verify the intended email-notification flow.
14. Verify faucet limits and failure states.

Phase 4 — production activation

• Apply the reviewed contract set and routes to production.
• Wait for the production backfill to reach the latest durable block.
• Repeat chain-parity, GraphQL, wallet, faucet, notification, and governance-lifecycle checks.
• Confirm existing DAOs remain healthy.
• Promote the Registry entry from draft to active.
• Add the official DeGov-site link only after acceptance.

6. Start-block warning

The initial startBlock is critical. The contract-set identity does not include startBlock; lowering the value later does not automatically rewind an existing checkpoint.

Production must start at 5,873,342. If an incorrect later block is used, recovering omitted history requires a separately reviewed scoped reset and reindex.

7. Acceptance criteria

The issue should be considered complete only when:

• the Registry resolves playground-dao by code and hostname;
• the production scoped GraphQL route is available;
• the checkpoint reaches and follows the latest durable Darwinia block;
• proposal, vote, delegation, and metrics queries match chain state;
• the site uses chain ID 46 and the verified contract addresses;
• a fresh user completes faucet → delegate → propose → vote → queue → execute;
• email proposal and state-change notifications work;
• faucet limits and monitoring are active;
• no existing DAO is regressed.

If validation fails, demote or disable only the new Registry entry and remove only the new DAO routes and contract-set configuration. Do not reset the shared database or delete unrelated DAO data.

[fewensa]

Implementation reference: DeGov Registry configuration for playground-dao

This is the implementation reference for the existing Playground contracts deployed on Darwinia Network, chain ID 46, and recorded by PR #879.

Verified contract deployment blocks

Contract	Address	startBlock
GTK	0xbC9f58566810F7e853e1eef1b9957ac82F9971df	5,873,342
Timelock	0xB8b60FdD7426E202f68dc0Ad2963bb0c1ae41B49	12,086,264
DGovernor	0xF7c7C6F9E8E15E8FAa071a7be3D42d1D391Ffd7a	12,086,268

The registry schema has one indexer.startBlock. Because GTK is reused and its transfer and delegation history predates the Governor, the aggregate value must be the earliest relevant block: 5,873,342.

Proposed daos/playground-dao.yml

# Contract deployment blocks:
# - GTK:        5,873,342
# - Timelock:  12,086,264
# - DGovernor: 12,086,268
#
# Start indexing from the earliest relevant block so the reused GTK transfer
# and delegation history is reconstructed.

name: DeGov Playground
code: playground-dao
logo: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/common/degov-1024.png
siteUrl: https://playground.degov.ai
offChainDiscussionUrl: https://github.com/ringecosystem/degov/discussions
editLink: https://github.com/ringecosystem/degov-registry/blob/main/daos/playground-dao.yml
description: |
  DeGov Playground is a public environment for trying the complete DeGov
  governance experience with test governance tokens, including delegation,
  proposal creation, voting, Timelock execution, and notifications.

links:
  website: https://degov.ai
  twitter: https://x.com/ringecosystem
  discord: https://discord.gg/RingDAO
  telegram: https://t.me/RingDAO_Hub
  github: https://github.com/ringecosystem/degov

theme:
  logoDark: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/logos/demo-dark.svg
  logoLight: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/logos/demo-light.svg
  banner: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/banners/demo.jpg
  bannerMobile: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/banners/demo-mobile.jpg

wallet:
  walletConnectProjectId: faf5e91ac5ed4d0a94d2648a6fcc9daa

chain:
  id: 46
  name: Darwinia Network
  rpcs:
    - https://rpc.darwinia.network
  explorers:
    - https://explorer.darwinia.network
  contracts:
    multicall3:
      address: "0xca11bde05977b3631167028862be2a173976ca11"
      blockCreated: 69420
  nativeToken:
    symbol: RING
    decimals: 18
    priceId: darwinia-network-native-token
    logo: https://assets.coingecko.com/coins/images/9443/standard/RING.png
  logo: https://pbs.twimg.com/profile_images/1742030786495500288/merX__YL_400x400.jpg

indexer:
  endpoint: https://indexer.degov.ai/playground-dao/graphql
  startBlock: 5873342

contracts:
  governor: "0xF7c7C6F9E8E15E8FAa071a7be3D42d1D391Ffd7a"
  governorToken:
    address: "0xbC9f58566810F7e853e1eef1b9957ac82F9971df"
    standard: ERC20
  timeLock: "0xB8b60FdD7426E202f68dc0Ad2963bb0c1ae41B49"

treasuryAssets: null

apps:
  - name: Governance Token Faucet
    description: Claim Playground GTK and continue to delegation and governance.
    icon: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/common/degov-200.png
    link: https://playground.degov.ai/faucet

Proposed config.yml entry

Add the DAO under the existing Darwinia group and keep it in draft until the site, indexer, faucet, notifications, and governance lifecycle pass validation:

darwinia:
  # Existing Darwinia entries remain unchanged.

  - config: daos/playground-dao.yml
    state: draft
    domains:
      - playground.degov.ai
    tags:
      - demo
      - playground

After production acceptance, change only the lifecycle state:

darwinia:
  - config: daos/playground-dao.yml
    state: active
    domains:
      - playground.degov.ai
    tags:
      - demo
      - playground

Verified values

• Network: Darwinia Network
• Chain ID: 46
• Native transaction fee token: RING
• GTK, Timelock, and DGovernor addresses
• All three creation blocks
• ERC20 governance-token standard
• Governor, token, and Timelock linkage
• Timestamp voting clock
• Voting delay: 60 seconds
• Voting period: 900 seconds
• Proposal threshold: 1 GTK
• Quorum: 1 GTK
• Timelock minimum delay: 180 seconds

Application values to confirm during implementation

• Display name DeGov Playground
• Stable DAO code playground-dao
• Canonical site URL https://playground.degov.ai
• Reused demo logo and banner assets
• Faucet URL and user-facing copy
• Production indexer URL
• Registry transition from draft to active

The faucet application entry should be published only when https://playground.degov.ai/faucet is deployed and usable.

Required implementation checks

1. Validate daos/playground-dao.yml and config.yml against the Registry schema.
2. Resolve the DAO configuration by both code playground-dao and origin https://playground.degov.ai.
3. Verify https://indexer.degov.ai/playground-dao/graphql returns only the intended DAO data.
4. Start at block 5,873,342, reach the latest durable Darwinia block, and expose healthy DAO metrics.
5. Compare representative token, delegation, proposal, and vote data with Darwinia chain state.
6. Confirm the web application does not fall back to another demo DAO.
7. Complete faucet → self-delegate → propose → vote → queue → wait → execute with a fresh wallet.
8. Verify the email-notification scenario described by Set up the Playground environment. #1010.
9. Confirm existing DAO routes and indexing remain healthy.

[fewensa]

Deployment-chain clarification

The deployment chain for playground-dao is Darwinia Network, chain ID 46.

Implementation will reuse the contracts already deployed and recorded by PR #879:

Contract	Address	Creation block
GTK	0xbC9f58566810F7e853e1eef1b9957ac82F9971df	5,873,342
Timelock	0xB8b60FdD7426E202f68dc0Ad2963bb0c1ae41B49	12,086,264
DGovernor	0xF7c7C6F9E8E15E8FAa071a7be3D42d1D391Ffd7a	12,086,268

The shared indexer must use 5,873,342 as the aggregate startBlock so the historical GTK transfer and delegation data is included.

Users will interact with the Playground on Darwinia and require a small amount of RING for transaction fees. No new Governor or Timelock deployment is part of this onboarding work.

The earlier investigation and Registry-reference comments have been corrected to use Darwinia consistently. This clarification is the implementation authority for the deployment-chain decision.

[fewensa]

Updated deployment decision and recommended Base Playground settings

This comment supersedes the earlier conclusion that playground-dao should onboard the existing Darwinia deployment.

The product decision has now been clarified by the original Slack discussion:

• the existing Darwinia demo and test contracts remain unchanged and continue to serve testing purposes;
• the public Playground intended for external users must be newly deployed on Base Mainnet;
• the Base Playground should provide the same governance lifecycle as the DeGov demo: governance token, Governor, and Timelock;
• it will be presented as a normal DAO in DeGov Square;
• the governance parameters must account for the future public token faucet.

The previous Darwinia contract deployment remains valid historical and testing material, but its addresses must not be used for the final public playground-dao configuration.

Recommended deployment parameters

Setting	Recommended value
Network	Base Mainnet
Chain ID	8453
Token name	DeGov Playground Token
Token symbol	GTK
Decimals	18
Voting clock	Timestamp
Initial and maximum supply	1,000,000 GTK
Faucet claim	10 GTK
Claim policy	Once per address
Proposal threshold	10 GTK
Quorum	Fixed 10 GTK
Voting delay	60 seconds
Voting period	900 seconds
Timelock minimum delay	180 seconds
Minimum complete lifecycle	Approximately 19 minutes, plus transaction and indexing time

The intended relationship is:

faucet claim amount = proposal threshold = quorum = 10 GTK

A new user can claim 10 GTK, self-delegate, wait for the delegation checkpoint to become historical, and then independently complete:

claim → delegate → propose → vote → queue → execute

Why quorum should be fixed

A percentage-of-supply quorum is not appropriate for this Playground.

OpenZeppelin GovernorVotesQuorumFraction calculates quorum from historical total token supply. If 1,000,000 GTK is minted and most of it remains undistributed in the Faucet, a 1% quorum would still require 10,000 GTK. That would prevent a new external user from completing the governance trial.

A fixed 10 GTK quorum:

• matches one Faucet allocation;
• remains stable as the Faucet distributes tokens;
• is easy for users to understand;
• preserves the single-user Playground acceptance flow.

With GovernorCountingSimple, For and Abstain votes count toward quorum, while For votes must still be greater than Against votes for a proposal to succeed.

Token design

The Base token should:

• use ERC20Votes and ERC20Permit;
• implement the ERC-6372 timestamp clock;
• mint 1,000,000 GTK once during deployment;
• have no external mint path after deployment;
• have no upgrade path;
• leave no owner or minter authority with the deployer or an individual wallet.

A fixed supply prevents an exposed Faucet or backend key from creating unlimited voting power.

Faucet design

The recommended implementation includes an onchain Faucet contract, even if the Faucet web page is released later.

The Faucet should:

• use a finite prefunded GTK inventory;
• distribute 10 GTK per address;
• allow one successful claim per address;
• expose its remaining inventory;
• emit a claim event;
• support emergency pause;
• allow an approved operations Safe to recover or migrate unclaimed inventory while paused;
• have no Token mint authority;
• avoid any backend service that holds an unrestricted Token-owner key.

At 10 GTK per claim, the fixed supply can support up to 100,000 claims.

If only Token, Governor, and Timelock are deployed in the first transaction set, the Faucet allocation must temporarily remain in an approved Base Safe and later be transferred into the reviewed Faucet contract. It must not remain under a personal deployer account.

Address-only limits are not Sybil resistance. They bound ordinary repeated claims but cannot prevent one person from creating multiple wallets. The finite inventory and the control-plane protections below are therefore essential.

Long-lived Playground safety boundary

The low quorum deliberately allows one Faucet claimant to pass a proposal. Without an additional safety boundary, the same user could use governance to modify Governor settings, change Timelock roles or delay, or permanently take over the public Playground.

Parameter tuning cannot simultaneously guarantee both:

1. one new user can complete the full governance lifecycle; and
2. one user cannot control an unrestricted governance system.

The Base Playground should therefore reject proposals that directly target its control-plane contracts:

• Governor;
• Timelock;
• GTK;
• Faucet.

It should also reject proposal actions with non-zero ETH values.

A separate assetless PlaygroundCounter or equivalent harmless target should be deployed as the canonical execution target for the end-to-end governance flow. The Timelock must not hold assets of value.

These restrictions preserve the standard OpenZeppelin Governor events, proposal states, voting, queueing, Timelock execution, and DeGov indexer compatibility while preventing a public claimant from permanently breaking the service.

Recommended Timelock role state

Role	Final holder
PROPOSER_ROLE	Governor
EXECUTOR_ROLE	Governor
CANCELLER_ROLE	Governor and the approved operations Safe
DEFAULT_ADMIN_ROLE	Timelock itself
Deployer	No final role

The deployer must have no residual Token, Faucet, Governor, or Timelock authority after deployment.

The operations Safe canceller role is an intentional service-continuity control for a public demo environment. It can censor a queued operation and must therefore be documented and monitored.

The approved Base operations Safe address is a required deployment input and must not be replaced with a personal wallet.

Gas and onboarding

Base lowers the onboarding barrier but is not gasless. Base Mainnet uses ETH, and every transaction includes an L2 execution fee and an L1 security fee.

The first release should:

• show the connected wallet ETH balance;
• estimate transaction fees;
• explain that a small amount of Base ETH is required;
• provide Base funding or bridge guidance.

Gas sponsorship can be considered as a separate second phase. If introduced, begin with a strict contract and function allowlist for:

1. Faucet claim;
2. self-delegation;
3. optionally voting.

Do not initially sponsor propose, queue, or execute, because that would create an unbounded spam and subsidy surface.

Rejected parameter models

Fixed 1 GTK quorum

This is the current demo value, but it is too weak for the public Playground and has no clear relationship to the proposed Faucet allocation.

Percentage quorum

This includes the undistributed Faucet inventory in historical total supply and makes the single-user trial impractical.

Multi-user quorum

A quorum of 20 or 30 GTK would require two or three claimed wallets. It is more representative of collaborative governance but conflicts with the primary goal of letting one external user independently try the complete product.

Required implementation and deployment validation

Before production activation, verify:

1. fixed supply and absence of any external mint authority;
2. timestamp clock and historical vote checkpoints;
3. successful Faucet claim and rejection of a second claim;
4. Faucet pause, exhaustion, inventory reporting, and recovery behavior;
5. self-delegation and historical voting power;
6. proposal threshold and fixed quorum both equal 10 GTK;
7. protected control-plane targets and non-zero ETH values are rejected;
8. exact Timelock role membership and minimum delay;
9. deployer has no residual authority;
10. the complete Counter lifecycle:
    claim → delegate → wait for checkpoint → propose → vote → queue → wait → execute;
11. Base fork simulation and gas estimation;
12. optional Base Sepolia deployment rehearsal;
13. explorer source verification and deployment manifest integrity;
14. fresh-wallet Base Mainnet end-to-end validation;
15. DeGov Registry, scoped GraphQL, indexer, UI, Datalens, and email-notification parity;
16. existing Darwinia test environments remain unchanged and healthy.

The Base Registry entry should begin as draft and become active only after all production acceptance checks pass.

Recommendation

Proceed with a dedicated Base Mainnet Playground deployment using the balanced single-user model:

1,000,000 GTK fixed supply
10 GTK per Faucet claim
10 GTK proposal threshold
10 GTK fixed quorum
60-second voting delay
900-second voting period
180-second Timelock
protected governance control plane
assetless Timelock and harmless execution target

This is the recommended design baseline for implementation. It is evidence-backed but not yet implementation-verified; the contract tests, Base rehearsal, deployment readback, indexer integration, and fresh-wallet lifecycle must still pass before the issue can be considered complete.

[fewensa]

Authoritative current-state report and implementation plan

Investigation date: 2026-07-24

This report supersedes the earlier investigation, Darwinia configuration proposal, deployment-chain clarification, and pre-deployment Base design recommendation in this issue. Those comments remain useful history, but they must not be used as the implementation authority.

The implementation baseline is now the lightweight Base Mainnet Playground that has already been deployed and recorded by PR #1032.

Executive conclusion

The contract-deployment phase is complete.

The remaining work is platform onboarding:

1. register playground-dao as a Base DAO;
2. add its contract set to the shared Datalens-backed indexer;
3. expose its scoped GraphQL route;
4. route playground.degov.ai to the shared DeGov application;
5. validate indexing, UI, governance, and notifications;
6. implement the Faucet as a separate follow-up and publish its application link only when it is usable.

No contract redeployment, separate indexer, separate Datalens deployment, new database, or schema migration is required.

1. Completed contract deployment

Network: Base Mainnet
Chain ID: 8453
Deployment account: 0x0f14341A7f464320319025540E8Fe48Ad0fe5aec

Contract	Address	Creation block	Creation transaction
GTK	0xef8ef3A1705f42e7FC1e06809940ec5942F5bB98	49,042,901	0x3be6b6fb7d7740e906fe5154f9872f262c21478b6f1e1e9349f09e065acac0e1
Timelock	0xa7E9dC6aBe0EfcdaBB8ED0471De0c56013066c20	49,042,902	0x511e632ad692577ac04ffa7eae3612d7b6467150ea82bd0ac193dbc0ecf27880
Governor	0x449337BBe404CaE0bA82f3451661AF7481f37aaC	49,042,904	0x1a000131bc0dff192183f1c1fefba9d8b76b9ec158fc1899c32854a48449ba84

All three addresses contain runtime bytecode. Governor correctly references the GTK and Timelock addresses above. BaseScan reports Exact Match source verification for all three contracts.

Verified runtime settings:

Setting	Deployed value
GTK name	Governance Token
GTK symbol	GTK
GTK standard	ERC20Votes
GTK current supply	0
Governance clock	Block number
Voting delay	60 blocks
Voting period	900 blocks
Proposal threshold	10 GTK
Fixed quorum	10 GTK
Timelock minimum delay	180 seconds
Governor name	DGorvernor

At the normal Base block interval, the voting delay and period are approximately two minutes and thirty minutes. A complete successful lifecycle is therefore approximately thirty-five minutes plus transaction confirmation and indexing time.

The current mint-authority model, zero initial supply, single-user quorum, unrestricted proposal targets, block-number timing, and deployed Governor name are accepted characteristics of this test Playground. They are not blockers for onboarding.

The existing Darwinia Playground contracts remain separate test artifacts. They must not be used in the new playground-dao Registry or indexer configuration.

2. Current platform state

The onboarding work has not yet been applied:

• degov-registry has no playground-dao entry;
• https://playground.degov.ai currently returns HTTP 404;
• https://indexer.degov.ai/playground-dao/graphql currently returns HTTP 404;
• no public Faucet page exists;
• no Faucet application link should be published yet.

The platform already supports Base Mainnet and the shared Datalens EVM logs dataset. Existing Base DAOs use the same Registry, indexer, GraphQL, and web model, so Playground onboarding is a new contract set rather than a new architecture.

The aggregate indexer start block must be the earliest of the three deployments:

startBlock: 49042901

Using this value preserves any GTK transfer, delegation, and checkpoint history from the beginning. Changing to an earlier block later would not necessarily rewind an existing checkpoint automatically, so this value must be correct in the first deployment.

3. Authoritative Registry configuration

The first Registry change should add the DAO in draft state.

Proposed daos/playground-dao.yml:

name: DeGov Playground
code: playground-dao
logo: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/common/degov-1024.png
siteUrl: https://playground.degov.ai
offChainDiscussionUrl: https://github.com/ringecosystem/degov/discussions
editLink: https://github.com/ringecosystem/degov-registry/blob/main/daos/playground-dao.yml
description: |
  DeGov Playground is a public test environment for trying the DeGov
  governance lifecycle on Base, including token distribution, delegation,
  proposal creation, voting, Timelock queueing, execution, and notifications.

links:
  website: https://degov.ai
  twitter: https://x.com/ringecosystem
  discord: https://discord.gg/RingDAO
  telegram: https://t.me/RingDAO_Hub
  github: https://github.com/ringecosystem/degov

theme:
  logoDark: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/logos/demo-dark.svg
  logoLight: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/logos/demo-light.svg
  banner: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/banners/demo.jpg
  bannerMobile: https://raw.githubusercontent.com/ringecosystem/degov-registry/refs/heads/main/assets/banners/demo-mobile.jpg

wallet:
  walletConnectProjectId: faf5e91ac5ed4d0a94d2648a6fcc9daa

chain:
  id: 8453
  name: Base Network
  logo: https://pbs.twimg.com/profile_images/1821025913976287232/l0WGRm5B_400x400.jpg
  rpcs:
    - https://base-rpc.publicnode.com
  explorers:
    - https://basescan.org
  nativeToken:
    symbol: ETH
    decimals: 18
    priceId: ethereum
    logo: https://assets.coingecko.com/coins/images/279/standard/ethereum.png

indexer:
  endpoint: https://indexer.degov.ai/playground-dao/graphql
  startBlock: 49042901
  gateway: https://v2.archive.subsquid.io/network/base-mainnet

contracts:
  governor: "0x449337BBe404CaE0bA82f3451661AF7481f37aaC"
  governorToken:
    address: "0xef8ef3A1705f42e7FC1e06809940ec5942F5bB98"
    standard: ERC20
  timeLock: "0xa7E9dC6aBe0EfcdaBB8ED0471De0c56013066c20"

treasuryAssets: null

Do not add an apps entry in the first Registry PR. Add the Faucet link only after the Faucet page exists and passes acceptance testing.

Proposed config.yml entry:

base:
  # Existing Base entries remain unchanged.

  - config: daos/playground-dao.yml
    state: draft
    domains:
      - playground.degov.ai
    tags:
      - demo
      - playground

After all production checks pass, change only state: draft to state: active.

4. Implementation plan

Phase 1 — Registry draft

• Add daos/playground-dao.yml.
• Add the Base config.yml entry in draft state.
• Validate both files against the Registry JSON schemas.
• Confirm DAO resolution by code and hostname.
• Keep the Faucet application absent.

Exit criteria: Registry schema CI passes and the draft configuration returns the exact Base addresses and startBlock: 49042901.

Phase 2 — staging indexer and Datalens onboarding

Add one Base contract set:

daoCode: playground-dao
chainId: 8453
governor: 0x449337BBe404CaE0bA82f3451661AF7481f37aaC
governorToken: 0xef8ef3A1705f42e7FC1e06809940ec5942F5bB98
tokenStandard: ERC20
timelock: 0xa7E9dC6aBe0EfcdaBB8ED0471De0c56013066c20
startBlock: 49042901

• Add the scoped /playground-dao/graphql route.
• Start indexing from block 49,042,901.
• Confirm the checkpoint reaches the current durable Base head.
• Confirm the checkpoint continues advancing.
• Verify every returned row is scoped to playground-dao.
• Compare contract parameters and representative events with Base RPC.

This reuses the shared Datalens-backed indexer. It does not require a database migration or a separate indexer deployment.

Exit criteria: scoped GraphQL queries succeed, checkpoint lag remains healthy, and new durable events become queryable within the normal indexer latency target.

Phase 3 — staging web and governance validation

• Route the staging Playground hostname to the shared web application.
• Resolve the draft Registry configuration.
• Confirm wallet connection requests Base Mainnet, chain ID 8453.
• Confirm transaction links use BaseScan and gas messaging refers to Base ETH.
• Manually mint or distribute GTK using the accepted current minter model.
• Complete:
  receive GTK → self-delegate → wait for a new block → propose → vote → queue → wait 180 seconds → execute.
• Verify proposal, vote, delegation, state transitions, counts, and indexer status in both UI and GraphQL.
• Verify email subscription and proposal/state-change notifications.

Exit criteria: a fresh test wallet completes the full lifecycle and every state transition matches Base chain state.

Phase 4 — production onboarding

• Add the production Playground contract set and scoped GraphQL route.
• Route playground.degov.ai to the shared DeGov application.
• Wait for the production checkpoint to reach the Base durable head.
• Repeat Registry, API, GraphQL, UI, chain-parity, notification, and lifecycle checks.
• Verify existing DAO routes and indexing remain healthy.

Exit criteria: the DAO config API, scoped GraphQL endpoint, and web hostname all return successful responses; indexer data matches chain state; no existing DAO regresses.

Phase 5 — activate the Registry entry

After production acceptance:

• promote playground-dao from draft to active;
• confirm it appears correctly in DeGov Square;
• confirm code and hostname resolution;
• confirm the public site does not fall back to another demo DAO.

Phase 6 — Faucet follow-up

The Faucet remains part of the product objective but is not required to begin indexer and UI onboarding.

The minimum Faucet behavior should be:

• distribute 10 GTK per successful claim;
• prevent ordinary repeated claims by the same address;
• show transaction status and remaining availability;
• guide the user to self-delegate after receiving GTK;
• explain that Base ETH is required for governance transactions;
• provide basic rate limiting, failure handling, and operational monitoring.

During implementation, the team may use the existing accepted minter model rather than redesigning or redeploying GTK. Once the Faucet page is deployed and tested, add its URL to the Registry apps section.

5. Final acceptance criteria

Issue #1010 can be closed when:

• the Base Registry entry is active;
• https://playground.degov.ai resolves the correct DAO;
• https://indexer.degov.ai/playground-dao/graphql is available;
• indexing starts from 49,042,901 and follows the durable Base head;
• token, delegation, proposal, vote, queue, and execution data match Base;
• a fresh wallet completes the full governance lifecycle;
• notification subscription and delivery work;
• the Faucet is usable and linked, or Faucet delivery has been explicitly moved to a separately tracked issue;
• existing DAO services remain healthy.

6. Rollback boundary

If onboarding fails, keep or return the Registry entry to draft, disable only the Playground hostname/route, and remove only the playground-dao contract set if necessary.

Do not reset the shared database, remove unrelated DAO contract sets, or change the existing Darwinia test environments.

Current issue status

Keep #1010 open. Contract deployment is complete, but Registry, indexer, site routing, production validation, and Faucet delivery remain pending.

[fewensa]

Implementation status and follow-up report

Validation date: 2026-07-24

This report supersedes the platform-state and remaining-work sections of the previous reports in this issue. The earlier contract analysis remains valid, but the Registry, site, and indexer onboarding described there as pending have now been implemented.

This is an implementation milestone report, not a completion report. The issue must remain open.

Executive summary

The Base Playground contracts, Registry draft entry, staging and production site routing, scoped GraphQL route, and shared-indexer contract set are now deployed.

The production Playground completed its initial index from the correct deployment block and currently reports a healthy checkpoint with no persisted indexing error. Existing DAO routes remained available during the rollout.

However, the shared Datalens query path still has a serious freshness limitation caused by very slow GMX and Dope queries. In addition, the Faucet, WalletConnect allowlist, fresh-wallet governance lifecycle, and notification acceptance tests remain incomplete. Therefore:

• keep the Registry entry in draft;
• keep this issue open;
• keep Faucet PR #1033 open and unmerged;
• do not describe the Playground as fully accepted yet.

1. Deployed Base contract set

The contract deployment from PR #1032 remains the authoritative Base Playground contract set:

Contract	Address	Creation block
GTK	0xef8ef3A1705f42e7FC1e06809940ec5942F5bB98	49,042,901
Timelock	0xa7E9dC6aBe0EfcdaBB8ED0471De0c56013066c20	49,042,902
Governor	0x449337BBe404CaE0bA82f3451661AF7481f37aaC	49,042,904

The indexer correctly uses the earliest deployment block:

startBlock: 49042901

The Darwinia test contracts remain separate and are not used by playground-dao.

2. Registry implementation

The Registry onboarding was merged through:

• degov-registry#126
• degov-registry#128

The live Registry entry resolves:

• DAO code: playground-dao
• chain ID: 8453 (Base Mainnet)
• production site: https://playground.degov.ai
• indexer endpoint: https://indexer.degov.ai/playground-dao/graphql
• the exact Governor, GTK, Timelock, and start block listed above
• WalletConnect project ID: faf5e91ac5ed4d0a94d2648a6fcc9daa

The original WalletConnect project ID was intentionally retained. No Faucet application entry was added.

The Registry state remains:

state: draft

That is intentional until the remaining acceptance work is complete.

3. Site and GraphQL deployment

Both Playground hosts now resolve the correct DAO application:

Environment	Result
https://playground.next.degov.ai	HTTP 200, title DeGov Playground
https://playground.degov.ai	HTTP 200, title DeGov Playground
https://indexer.degov.ai/playground-dao/graphql	Scoped GraphQL POST succeeds

The application resolves the Base chain, exact contract addresses, and the scoped Playground GraphQL route. It does not fall back to the previous Darwinia demo configuration.

WalletConnect is not yet accepted because the Reown project allowlist still rejects both origins:

Origin https://playground.next.degov.ai not found on Allowlist
Origin https://playground.degov.ai not found on Allowlist

This requires an allowlist update for the existing project ID; it does not require changing the ID in the Registry.

4. Playground indexing validation

Staging

The staging Playground contract set was indexed from block 49,042,901, reached the durable Base target, and returned a healthy scoped status.

Production initial pass

The production indexer selected playground-dao at approximately 09:22:39Z and used:

• configured start block: 49,042,901
• target block: 49,047,550
• initial range: 4,650 blocks
• Datalens query duration: approximately 3.7 seconds
• pass completion: approximately 09:22:47Z

The production status after the pass was:

{
  "daoCode": "playground-dao",
  "processedHeight": 49047550,
  "provisionalHeight": 49047808,
  "targetHeight": 49047550,
  "syncedPercentage": 100.0,
  "isSynced": true,
  "lastError": null
}

The initial production checkpoint was established about 6 minutes 28 seconds after the production indexer rollout started.

Base RPC comparison found only the deployment/configuration events in this range. GTK totalSupply was still zero, and GraphQL correctly returned no proposals, voters, contributors, queue records, or execution records. The empty governance dataset is therefore consistent with current chain state; the decoded deployment events must not be interpreted as proposals.

5. Shared-indexer concurrency rollout

The shared indexer previously allowed only one contract-set pass at a time. A conservative rollout increased only the global contract-set concurrency:

contract-set global:   1 -> 2
contract-set per-chain: 1
Datalens query global:  1
Datalens query per-chain: 1

No Datalens query concurrency limit was increased.

Staging experiment

During the 30-minute staging experiment with contract-set concurrency 2:

• 14 DAOs advanced;
• 57 chunks completed;
• 15 passes completed;
• 103 Datalens permits were acquired;
• observed Datalens process_in_flight remained exactly 1;
• 16 permit-wait timeouts were recoverable;
• no contract-set pass failed;
• no provider-limit, HTTP 429, database, or RPC error was observed;
• the Pod remained Ready with zero restarts.

The result supported a production rollout of 2, but not a further increase to 3+.

Production 30-minute observation

Observation window:

2026-07-24T09:16:25Z .. 2026-07-24T09:46:25Z

Results:

• 22 distinct DAOs produced completed chunks;
• 219 chunks completed;
• 35 contract-set passes completed;
• 242 Datalens query permits were acquired;
• observed process_in_flight remained exactly 1;
• 28 query deadlines occurred, including 6 waits that timed out on the single Datalens permit;
• 0 contract-set failures;
• 0 provider-limit splits;
• 0 HTTP 429 responses;
• 0 ERROR-level indexer log entries;
• the current indexer Pod remained 3/3 Ready with zero restarts.

Runtime resource use remained low (approximately 2 millicores/23 MiB for the indexer container at the final check). The rollout is operationally stable and improved fairness between contract-set passes.

6. Critical DAO status after rollout

DAO	Processed	Target	Status
ENS	25,601,247	25,601,247	100%, no persisted error
Lisk	35,077,911	35,077,911	100%, no persisted error
AWE	49,047,454	49,047,454	100%, no persisted error
Playground	49,047,550	49,047,550	100%, no persisted error
GMX	487,153,895	487,174,767	behind by 20,872 blocks, no persisted error

The isSynced=true value for ENS, Lisk, AWE, and Playground means each DAO reached the durable target captured by its most recent pass. It does not prove continuous real-time freshness.

7. Remaining Datalens/indexer limitation

The contract-set fairness change does not solve the underlying slow-query problem.

Recent GMX queries still process only 25 blocks in approximately 93–166 seconds. At the audit checkpoint, GMX's remaining lag had increased to 20,872 blocks and its logged throughput was below the Arbitrum block-production rate.

The second contract-set slot was also occupied by slow Dope queries, commonly taking approximately 60–105 seconds for 25 blocks. Since all contract sets still share a single Datalens query permit, these slow queries can delay otherwise healthy DAOs.

A final audit compared public chain heads with the latest stored statuses and found that locally “synced” snapshots could still be stale by hundreds of blocks. This is a separate performance/freshness problem and must not be hidden by the 100% status value.

Recommended follow-up:

1. investigate the GMX and Dope Datalens query execution path and cache/provider behavior;
2. measure end-to-end durable-head lag per DAO, rather than relying only on pass-local isSynced;
3. add alerts for checkpoint age and growing head lag;
4. do not increase Datalens concurrency or contract-set concurrency beyond the validated values without a new controlled benchmark.

8. Faucet status

Faucet PR #1033 is deliberately deferred.

Verified state:

• PR is open;
• auto-merge is not enabled;
• it has not been deployed;
• no Faucet application link has been added to the Registry.

The PR must remain open and must not be merged or deployed until this work is resumed explicitly.

9. Acceptance work still required

The following items remain open:

1. add both Playground origins to the existing Reown/WalletConnect project allowlist;
2. resume, review, and explicitly approve Faucet delivery in PR #1033;
3. make GTK available to a fresh wallet through the accepted distribution flow;
4. complete and verify:
   receive GTK -> self-delegate -> propose -> vote -> queue -> wait for Timelock -> execute;
5. verify every resulting token, delegation, proposal, vote, queue, and execution record against Base RPC;
6. verify email subscription and proposal/state-change notification delivery;
7. address or separately track the GMX/Dope Datalens freshness limitation;
8. only after the above checks pass, promote the Registry entry from draft to active and add the Faucet application link if it is deployed.

Current issue status

Keep #1010 open.

The Base contracts, Registry draft, staging/production sites, scoped GraphQL route, and initial Playground indexing are implemented and validated. The issue is not complete because Faucet delivery is deferred, WalletConnect is not allowlisted, no fresh-wallet governance lifecycle has been exercised, notification delivery is unverified, and the shared Datalens path still cannot guarantee continuously fresh DAO data.

[fewensa]

Final implementation report — Base Playground deployment complete

Completion date: 2026-07-24

This report supersedes the completion criteria in the earlier planning comments.

The accepted scope has been updated: Faucet delivery is not planned at this time and is no longer a completion requirement for this issue. PR #1033 remains open, unmerged, without auto-merge, and no Faucet application link has been published.

Under the revised deployment-only acceptance scope, the Base Playground deployment is complete.

1. Base contract deployment

The authoritative contract set from PR #1032 is deployed on Base Mainnet (chain ID 8453):

Contract	Address	Creation block
GTK	0xef8ef3A1705f42e7FC1e06809940ec5942F5bB98	49,042,901
Timelock	0xa7E9dC6aBe0EfcdaBB8ED0471De0c56013066c20	49,042,902
Governor	0x449337BBe404CaE0bA82f3451661AF7481f37aaC	49,042,904

Fresh archive-RPC checks confirmed that runtime bytecode appears at exactly those creation blocks and is absent immediately before each block.

The Governor references the exact GTK and Timelock addresses above. The verified runtime parameters remain:

• voting delay: 60 blocks;
• voting period: 900 blocks;
• proposal threshold: 10 GTK;
• fixed quorum: 10 GTK;
• Timelock minimum delay: 180 seconds;
• current GTK total supply: 0.

The Registry and indexer correctly use the earliest deployment block:

startBlock: 49042901

The older Darwinia test contracts remain separate and are not used by this DAO.

2. Registry onboarding and activation

The Registry onboarding and WalletConnect-ID preservation were merged through:

• degov-registry#126
• degov-registry#128

After production validation, the DAO was promoted and made publicly discoverable through:

• degov-registry#129 — promote playground-dao from draft to active;
• degov-registry#130 — remove the demo tag that DeGov Square intentionally filters, while retaining the playground tag.

Both activation PRs passed the Registry JSON Schema CI and independent review before merge.

The production Registry state is now:

- config: daos/playground-dao.yml
  state: active
  domains:
    - playground.degov.ai
    - playground.next.degov.ai
  tags:
    - playground

The Registry still resolves the original WalletConnect project ID:

faf5e91ac5ed4d0a94d2648a6fcc9daa

No Faucet apps entry was added.

3. Staging and production application deployment

Both application environments resolve the correct DAO:

Environment	Validation
https://playground.next.degov.ai	HTTP 200, title DeGov Playground, Base configuration
https://playground.degov.ai	HTTP 200, title DeGov Playground, Base configuration

Browser network validation confirmed successful requests to:

• the environment-specific DeGov configuration API;
• the scoped /playground-dao/graphql endpoint;
• Base Mainnet RPC.

The production configuration API returns the exact chain, contracts, start block, site URL, and indexer endpoint recorded above.

4. Indexer deployment and initial synchronization

The shared Datalens-backed indexer contains the exact Base Playground contract set and exposes:

https://indexer.degov.ai/playground-dao/graphql

The production initial pass:

• started at block 49,042,901;
• targeted block 49,047,550;
• processed the 4,650-block deployment range;
• completed its Datalens query in approximately 3.7 seconds;
• established the first production checkpoint approximately 6 minutes 28 seconds after the production rollout began.

Fresh scoped GraphQL readback:

{
  "daoCode": "playground-dao",
  "chainId": 8453,
  "processedHeight": 49047550,
  "provisionalHeight": 49047808,
  "targetHeight": 49047550,
  "syncedPercentage": 100.0,
  "isSynced": true,
  "lastError": null
}

GTK supply and governance data are currently empty. This matches Base chain state: GTK totalSupply is zero and no user governance proposal has been created. Deployment/configuration events were not misclassified as proposals.

5. Production runtime verification

The production DeGov indexer deployment on the Helixbox cluster was read back with:

• Deployment generation equal to observed generation;
• 1/1 desired, Ready, and available replica;
• Pod 3/3 Ready;
• zero restarts for indexer, graphql, and onchain-refresh-worker;
• the exact Playground contract set and scoped GraphQL route;
• no persisted Playground indexer error.

The conservative shared-indexer fairness rollout remains:

Datalens global query concurrency:       1
Datalens per-chain query concurrency:    1
contract-set global concurrency:         2
contract-set per-chain concurrency:      1

Its prior 30-minute production observation completed 219 chunks and 35 contract-set passes across 22 DAOs with:

• Datalens process_in_flight always equal to 1;
• zero contract-set failures;
• zero provider-limit splits;
• zero HTTP 429 responses;
• zero ERROR-level indexer log entries;
• zero Pod restarts.

6. DeGov Square activation

After Registry activation, the Square backend synchronized playground-dao as:

{
  "code": "playground-dao",
  "state": "ACTIVE",
  "tags": ["playground"],
  "endpoint": "https://playground.degov.ai",
  "chainId": 8453
}

Production browser verification then confirmed:

• the Square count increased from All DAOs(36) to All DAOs(37);
• a DeGov Playground row is visible;
• it shows Base and No proposals yet;
• its link resolves to https://playground.degov.ai/.

This completes the public DAO discovery requirement.

7. Explicitly deferred or separate follow-ups

These items are documented but are not blockers under the revised deployment-only scope.

Faucet

Faucet work is deferred indefinitely for now. PR #1033 remains open and must not be merged or deployed unless the work is explicitly resumed later.

Reown allowlist

Both Playground origins still need to be added to the existing Reown project allowlist:

https://playground.next.degov.ai
https://playground.degov.ai

The production browser currently receives:

Origin https://playground.degov.ai not found on Allowlist

The Registry intentionally keeps the existing project ID; no code or Registry ID change is required. WalletConnect usability depends on this external allowlist follow-up.

Shared Datalens freshness

The Playground completed its initial pass, but its current checkpoint can remain behind the live Base head because the shared single Datalens query permit is still occupied by slow GMX and Dope queries.

Consequently, isSynced: true means the DAO reached the durable target captured by its last pass; it does not guarantee continuously fresh head tracking.

This is a shared indexer/Datalens performance concern, not a failure of the Playground contract-set deployment. It should remain tracked separately through checkpoint-age/head-lag monitoring and slow-query optimization.

Governance and notifications

A fresh-wallet receive GTK -> delegate -> propose -> vote -> queue -> execute test and notification delivery test were not performed because GTK supply remains zero and Faucet delivery is out of scope. These are no longer closure criteria for this deployment-only issue.

8. Cleanup

All temporary worktrees created specifically for #1010 across DeGov, Registry, and deployment repositories have been removed. Unrelated issue and release worktrees were preserved.

Final conclusion

The Base Playground contracts, Registry entry, staging and production applications, scoped GraphQL route, initial index, production runtime, active Registry state, and DeGov Square discovery are deployed and verified.

With Faucet explicitly removed from scope and the remaining external/performance limitations documented above, #1010 can be closed as completed.