The AI app builder for web3. Agents at your disposal.

What we're building

Shipping a web3 app still takes four products and a specialist team: wallet onboarding, contract infrastructure, an app builder, and campaign tools. Each has its own account, bill, and integration work, and someone still has to audit, test, deploy, and run the result. Mooons joins them on one stack and lets agents do the work.

Scope

The big picture

One stack, five layers. Services are what people pay for. Infrastructure is what the services, and any outside developer, are built on. The SDKs are the only way anything above reaches the infrastructure below.

Positioning

Our read of what each category typically does by default, from secondary sources. Independent coverage of Orchids is thin. Check each claim against hands-on tests before publishing.

Web3 tools it joins up

Our read of each product's focus, to be checked against their current offerings.

Why it holds

Features

Each of the four category leaders is strong at one layer. These are the features worth taking from each, tagged with the phase they belong in. Phases 1 and 2 are the minimum for the combination to feel complete.

What people can build

"Any web3 app" needs a known catalog the agents can build well. Waves order app types by how much new infrastructure and regulation they bring.

Game engine

The apps

One account and one wallet identity across all of them. Each surface has a single job, so none is a shrunken copy of another.

Sample apps

These are not separate products. Each is a reference app built by the coding agents, which users can remix. Every project gets a subdomain such as bueno.mooons.site.

UI designs

The two screens that define the product, with example data. The working prototype is in mooons-app.html.

Builder

app.mooons.xyz/bueno

bueno · generative NFT · BaseTestProductionApprove

Release pipeline

✓

Build31 credits

✓

Contract testBase Sepolia · 12 credits

✓

App testsign in, mint, claim · 7

✓

Verifyaudit report · 4 credits

●

Test version livebueno-test.mooons.site

○

ApproveNeeds you

○

ProductionAvailable after approval

ContractsWalletFiles

§

BuenoMoons0x7c1e…a94f

§

Allowlist0x21b0…5d3c

§

RoyaltySplit0x9e44…0b17

PhoneDesktop

Test version · Base Sepolia5,000 moons.
No two alike.1,240 of 5,000 minted

Mint · allowlistSign in with email or passkey. Gas is covered.

Checks✓ Source verified✓ Roles belong to owner✓ Spend limits set✓ No secrets in app

MManager

An NFT mint site for 5,000 moons on Base, allowlist first.

Started from the generative NFT sample. I set up email and passkey sign-in, sponsored gas for the allowlist mint, and a delayed reveal.

Your test version is ready. Try a mint with the test wallet, then approve it. Mainnet deployment is quoted at about $4 of gas.

Approve the test versionProduction stays off until you switch it on.

ApproveAsk for changes

Ask for a change

128 of 200 credits412 of 1,000 active usersBuilder plan

Insights

app.mooons.xyz/moonquest/insights

moonquest

ProjectsBuilderContractsInsights 3Domains and usage

Insights7d30d90d

Active users412Up 18% on the month before

Quests completed1,9064.6 per active user

Loot boxes opened73338% of completions

Gas sponsored$11.40$0.03 per active user

Recommendations from your agents3 open

Insights

Turn on email sign-in on the landing page56% of visitors leave at wallet connect. About 3 credits.

Apply

Insights

Add a weekly streak questOnly 97 of 412 users came back the next week. About 6 credits.

Apply

Gamify

Sell a season passNeeds your approval before anything is sold.

Review

Where visitors drop offLast 30 days

Visited2,150

Connected946

Completed a quest412

Opened a box281

Returned97

AI agents

Eleven web3 agents, each with one job. Eight work for the tenant: they build the app, release it, and keep it running. Three work for the Mooons team and keep the platform safe. The tracking service feeds them but is not an agent. See the agent design for the full permissions table.

From build to production

Every project has two environments. Test is automatic. Production needs two things from the owner, and those are the only human steps.

1. Build Agent

   Builder agents write app code, wallet setup, and the MCP server.

2. Contract test Agent

   Contract agents deploy to testnet and run unit, fuzz, fork, and gas tests.

3. App test Agent

   Testing agents sign in, mint, claim, and pay as a user would.

4. Verify Gate

   Verification agents check the audit report, verified source, permissions, and limits.

5. Test version You

   Live on testnet at name-test.mooons.site. The owner tries it.

6. Approve and toggle You

   The owner approves the release and switches production on.

7. Production Agent

   Deployer agents ship contracts to mainnet and the app to its domain, bot, and webhooks.

8. Verify again Gate

   Verification agents confirm production matches the approved test version.

9. Track and improve Agent

   Tracking feeds insights and gamification, and approved changes re-enter at build.

A failed stage goes back to the builder with the failure as its next instruction, at most three times. After that the owner decides. Switching the toggle off unpublishes the app and pauses contracts that support pausing. Contracts already on mainnet cannot be removed.

Rules every agent follows

Infrastructure

Multi-tenant from the start. Every block is scoped to a tenant and a project, and reachable by API, so builders and agents use the same thing the Mooons services do.

How tenancy works

tenant        a paying account: one person or a team
└─ members    owner · admin · developer · viewer · agents with scoped keys
└─ project    one app: its contracts, wallets, domain, bot, MCP server
   ├─ end users   the app's own users, isolated from every other project
   ├─ api keys    publishable for the browser, secret for servers and agents
   └─ events      one stream feeding webhooks, SSE, email, bot, and push

Domains and cells

mooons.xyz is the platform. mooons.site is where tenant apps live, so nothing a tenant deploys can read a cookie or impersonate a platform page.

Colors name cells, not tenants. A cell is a self-contained copy of the API with its own databases. Tenants never choose a color. They call api.mooons.xyz, and the router reads the cell from the API key, such as mk_live_indigo_8f2c…. A bad release or runaway tenant affects one color, and new releases land on a canary cell first.

The API

One address, versioned in the path. This is the proposed shape of the first endpoints, for review, and not yet a specification.

Example

// react sdk · sketch, not final
import { MooonsProvider, ConnectButton } from "@mooons/react"

<MooonsProvider projectKey="mk_test_indigo_…">
  <ConnectButton methods={["email", "passkey", "wallet"]} sponsorGas />
</MooonsProvider>

The stack

Cloudflare is the base for compute, data, and delivery. Everything it does not offer is named as an outside provider or open-source tool. The full list is in the tech stack.

Compute and delivery

Data and state

AI models

Agents are assigned a tier, not a model, so a gateway can swap models without touching any agent. This is a starting map. Benchmark it on real tasks before fixing it.

Agent runtime

Clients, security, and operations

Chains

Each chain family needs its own contract templates and its own route to account abstraction. The user experience is the same on all of them: no seed phrase, no gas prompt. Mooons owns one SDK per chain, and each one is tested against that chain's established library. Rollout order is a proposal.

Wallets and contracts

One wallet service for people and AI agents. Contracts come from an audited library, so generated apps stay consistent and checkable.

The contract path

If a published template turns out to be vulnerable, a superadmin pulls it, sees every project that deployed it, notifies owners, and approves a migration plan.

Standards to support

Listed from existing notes. Standards change status often, so confirm each against its current specification before committing.

SDKs

Mooons owns its chain layer, following the structure of OKX's wallet SDK: shared cryptography, one common interface, and one package per chain. Agents and developers learn one interface, and a new chain is a new package rather than a rewrite. Agents never write wallet or chain code from scratch. They compose these packages, which keeps generated apps consistent and auditable.

@mooons/crypto          audited primitives: curves, hashes, encodings
└─ chain-base           one interface every chain implements, test vectors
   ├─ chain-evm         phase 1
   ├─ chain-solana      phase 3
   ├─ chain-ton         phase 3
   ├─ chain-sui         phase 4
   ├─ chain-aptos       phase 4
   └─ chain-near        phase 4

wallet-sdk              wallet types, signers, agent permissions. Uses any chain package
└─ js-sdk               apis, auth, util helpers, vanilla js
   ├─ react-sdk         providers, hooks, tanstack query clients
   │  ├─ gram-sdk       telegram mini apps
   │  └─ base-sdk       coinbase mini apps
   ├─ game-sdk          rooms, inventory, quests, markets (recommended addition)
   └─ mcp-sdk           platform tools for coding agents

Proposed dependency order. Confirm whether gram and base should also work without react.

The shared interface

// sketch, not final
import { EvmChain } from "@mooons/chain-evm"

const chain = new EvmChain({ network: "base" })

const address = await chain.getAddress(signer)
const tx = await chain.buildTransaction({ to, value, data })
const signed = await chain.signTransaction(tx, signer)

// Every chain package has these same methods
// Sending goes through the relay and rpc.mooons.xyz

What each layer does

What we keep from OKX, and what we change

Why own them

Testing rule. The established library for each chain stays in the test suite. Every package must produce byte-identical addresses and signed transactions to that library across its test vectors. A difference blocks the release.

Scope. Own SDKs cover the client side. Contract tooling such as Foundry and Anchor, and bundlers, RPC providers, and oracles stay as they are in the Stack tab.

The accelerator

The third ring. A cohort program that takes teams from first build to real users on Mooons, measured on what users actually do. Everything in this tab is a proposal: none of it appears in the earlier plans, and the numbers are starting points.

How a cohort runs

Twelve weeks and about ten teams, reviewed against the same numbers each week.

What each side does

1. Apply with a test version Team

   The Free plan covers it, so the application doubles as proof that the team can use the platform.

2. Selection Admin

   People review every application. Agents can summarize one, but do not score or rank teams.

3. Allowances switched on Agent

   Scale-level allowances and a capped gas grant are applied to the team's tenant.

4. Human contract review Admin

   A person reviews contracts on top of the AI audit before the first mainnet release.

5. Weekly report Agent

   Insights and manager agents report active users, retention, transactions, and revenue, with suggested changes.

6. Team decides Team

   The two human release steps stay with the team. The program never approves or deploys for them.

7. Demo day and handover Team

   Teams show live numbers. Allowances end, and each team moves to a normal plan with its app untouched.

What teams get

Selection criteria

Measures and cost

Progress comes from the tracking service from Cohort 1 onward, and the program is judged on the same data.

Cost of one cohort

Built from the plan's full-use cost of a Scale tenant. Those figures are assumptions until measured in beta. Most teams will not use every allowance.

Not included: staff time and any outside auditors. Human contract review is likely to be the largest cost, so get a quote before setting the cohort size.

Accelerator track

Pricing

$19 stays as the headline price. A single flat plan cannot hold, because agent tokens, user traffic, and gas all grow without limit. Every figure here is a starting proposal.

The three meters

Does each plan hold up at full use?

Cloudflare at published rates checked 12 October 2026. Model, RPC, key, and card costs are assumptions to measure in beta. Agent spend is the largest line.

Roadmap

Each phase ships something usable and sets up the next. A phase ends when its exit condition is true, not on a date.

Go to market

Start where builders and apps already exist.

Risks

What could go wrong, and what limits the damage.

Open decisions

Each needs an owner and an answer before the work it blocks.

Legal

Issues to take to counsel, not legal advice. These decide what Mooons can offer and where.

Glossary

Terms used across this plan.

Tenant

A paying account: one person or a team.

Project

One app with its contracts, wallets, domain, bot, and MCP server.

Owner

The person who approves releases and switches production on.

Cell

An isolated copy of the API and its data, named by a color.

Test version

A working release on testnet at the project's test address.

Release record

The one shared record each agent reads from and writes to.

Agent credit

A fixed amount of model spend, used to meter agent work.

Active user

An end user who signs in or signs a transaction in the month.

AI pre-audited

Reviewed by an automated audit pipeline. Not a formal audit.

MCP

Model Context Protocol, which lets agents use an app's tools.

Signer

Anything that can sign for a wallet: a device key, a passkey, the key service, or an agent wallet.

Cohort

A group of teams going through the accelerator together.

Source documents

The earlier plans hold detail this page leaves out.

Brand assets

Three linked rings: the "ooo" in mooons, and the three pillars. The mark is monochrome for small sizes. The gradient belongs to the logo alone, so it is the only colour on a Mooons page.

Isometric mark

The pixel mark built from cubes, on the 30° isometric plane used by the harbor and the voxel moon. Monotone only, for large placements such as covers and section art.

Pixel mark

The same three rings on a pixel grid, in the style of the agent mascots. Monochrome only. Keep it at whole multiples of 47 by 17 so the pixels stay even.

Where each logo goes

Colour

Typography

Usage