dappster.
Dashboard
Back to Dappster
// Security and architecture

Dappster technical overview

Public documentation for wallet providers, security vendors, users, and integration partners. This document describes the production transaction flows and trust boundaries used by dappster.fun.

Download PDFBase membership contract
Version 1.0Published July 31, 2026Canonical domain: dappster.fun
01 / Executive summary

What Dappster does

Dappster is an AI-assisted application builder that generates smart-contract source, frontend source, deployment instructions, and optional automated audit reports. Users can review and preview generated artifacts before deployment. On EVM networks, deployments remain non-custodial: the connected wallet signs and broadcasts the contract-creation transaction. On Solana, a disclosed, user-funded technical wallet performs program deployment after a wallet-signed authorization and transfers upgrade authority to the user.

Key custody statementDappster does not request, collect, or store EVM or user Solana seed phrases and private keys. Users must approve wallet connection, payments, credit burns, and deployment-related signatures in their own wallet interface.
02 / Architecture

System components

Web application

Next.js and TypeScript application hosted on Vercel. Wallet connections use wagmi/viem for EVM, WalletConnect-compatible connectors, and the Solana wallet adapter.

Generation and audit layer

Server-side AI calls produce structured source artifacts. Solidity source is compiled with a restricted import resolver; Solana programs use an isolated build environment.

Data and authorization

Supabase authentication, linked-wallet records, Postgres Row Level Security, owner-scoped project access, and idempotent transaction records.

Publishing

Verified dApp frontends are packaged with their chain and deployed-contract metadata, pinned through Pinata, and served from IPFS gateways.

03 / EVM deployment flow

User-signed contract creation

  1. 1

    The authenticated user selects a supported EVM network and asks Dappster to generate a contract and frontend.

  2. 2

    Dappster compiles the Solidity source with solc, permits only bundled OpenZeppelin imports, and returns the ABI and creation bytecode.

  3. 3

    Before the wallet prompt, Dappster simulates the exact contract-creation payload against the selected chain RPC and estimates gas.

  4. 4

    The connected wallet signs and submits the deployment. Dappster never receives the wallet private key or seed phrase.

  5. 5

    After confirmation, the backend verifies the successful receipt, contract address, contract-creation form, exact 0.001 native-token value, fee recipient, and emitted fee event.

  6. 6

    Only after verification may the generated frontend be wrapped with deployment metadata and published to IPFS.

Required deployment value0.001 native tokenRecipient0x5D69C42A3a481d0CCFd88CFA8a2a08e2BF456134

The fee is atomic with deployment: the generated zero-argument payable constructor requires exactly 0.001 of the selected chain's native token (for example ETH, POL, AVAX, BNB, XDAI, CELO, MNT, BERA, S, FRAX, METIS, or HYPE), forwards it to the disclosed recipient, and emits DappsterDeploymentFeePaid. If the transfer fails, contract creation reverts. Network gas is separate and is displayed by the user's wallet.

04 / Supported EVM networks

Explicit allowlist

NetworkChain IDEnvironment
Ethereum1Mainnet
Base8453Mainnet
Arbitrum One42161Mainnet
OP Mainnet10Mainnet
Polygon PoS137Mainnet
Avalanche C-Chain43114Mainnet
BNB Smart Chain56Mainnet
Gnosis100Mainnet
Celo42220Mainnet
Scroll534352Mainnet
Linea59144Mainnet
ZKsync Era324Mainnet
Mantle5000Mainnet
Blast81457Mainnet
Mode34443Mainnet
Berachain80094Mainnet
Sonic146Mainnet
Fraxtal252Mainnet
Metis1088Mainnet
Robinhood Chain4663Mainnet
HyperEVM999Mainnet
Ethereum Sepolia11155111Testnet
Base Sepolia84532Testnet

Each network is configured with an explicit chain ID, RPC endpoint set, and block explorer. Dappster rejects unsupported EVM chain IDs and verifies that the wallet switched to the selected network before submission.

05 / Solana deployment flow

Authorized, user-funded relayer

  1. 1

    Dappster compiles the generated Anchor program in an isolated build environment and calculates program rent plus deployment costs.

  2. 2

    The user's linked Solana wallet signs a funding transfer to the disclosed technical wallet. The transaction includes a unique deployment-job memo.

  3. 3

    The backend verifies cluster, linked sender, recipient, minimum amount, memo, signature status, and the user's separate deployment-authorization signature.

  4. 4

    A job queue and cluster lock prevent concurrent jobs from using the same deployment wallet state at the same time.

  5. 5

    The technical wallet writes and deploys the compiled program with Solana's Upgradeable Loader, verifies the executable account, then transfers upgrade authority to the user's wallet.

  6. 6

    The frontend is published only after the Program ID is verified on the selected cluster. The technical wallet is not used for EVM deployments.

The technical wallet is an operational deployer, not an end-user wallet. Mainnet SOL needed for rent and deployment comes from the requesting user. Funding transactions are tied to one deployment job and cannot be reused for another job.

06 / Payments and credits

On-chain settlement on Base

  • Credit packages and membership settle in native Circle USDC on Base.
  • The production membership contract is 0xea7e37d45b6f75ae6826c1925d7b0ac314c7ecae.
  • The backend credits an account only after verifying the receipt and exact USDC transfer event.
  • Credits are non-transferable ERC-1155 units. The normal product flow asks the linked user wallet to sign burnOwnCredits.
  • Unique usage IDs and database payment references make purchases and credit consumption idempotent.
07 / Security controls

Validation and access boundaries

Input validation

API payloads are schema-validated and size-limited. Solidity compilation restricts imports to the bundled OpenZeppelin contracts directory.

Wallet linkage

Payment, credit, and deployment actions must use a wallet linked to the authenticated Dappster account.

Receipt verification

Backend verification checks chain, sender where applicable, destination, amount, transaction success, emitted events, and deployment address before synchronizing state.

Database isolation

Row Level Security limits private profiles, projects, audits, transactions, and deployment jobs to their owners. Public Marketplace access is limited to listed records and configured visibility.

Replay resistance

Unique usage IDs, funding memos, job IDs, transaction references, and database uniqueness rules prevent reuse across actions.

Operational logging

Client errors are accepted only from the same origin and logged with bounded fields; wallet secrets are not part of the telemetry payload.

08 / Trust boundaries and limitations

What users must still verify

AI-generated code can contain defects. Compilation, transaction simulation, and automated audit output do not replace an independent professional security audit. Dappster presents generated source before deployment so users can inspect it and should test high-value applications on a test network first. Wallet simulation and security-warning vendors remain an additional independent protection layer.

09 / Independent verification

Public references

Production domain
https://dappster.fun
Base membership contract
BaseScan verification page
Deployment fee recipient
0x5D69...6134
Security contact
dev@dappster.fun