# Eitherway Documentation Build, deploy, and monetize full-stack apps, mobile apps, browser extensions, and Web3 dApps with natural language in Eitherway. ## Eitherway AI app builder for Web2 and Web3 Use Eitherway to go from idea to product fast. Generate apps from prompts, test them instantly, deploy them, monetize them, and launch tokens through the native launchpad, with launch activity feeding value back into the $EITHER ecosystem. Use Eitherway to go from idea to product fast. Generate apps from prompts, test them instantly, deploy them, monetize them, launch tokens, and create liquidity without switching tools.
Cover image
What is Eitherway?Learn how Eitherway helps teams build AI-generated apps and launch products faster./spaces/nG84RDOv0cfqMD4lVr3c/files/mtnGVhyYK19RTQlyTTz8
What is Eitherway Launchpad ?Learn how the Eitherway Launchpad helps teams launch tokens through a product-first ecosystem, with value flowing back into $EITHER through launch activity./spaces/nG84RDOv0cfqMD4lVr3c/pages/OMHZwxevmOmRRgkxBzW4/files/LcYUTpBJDdajgzrbZR7o
What is $EITHER?Explore the $EITHER token and how it supports the Eitherway ecosystem./spaces/mj0ACZb6uAKeywqiC5GR/files/ho3HYP4zLaxaCWMIf1fg
{% columns %} {% column valign="middle" %} #### "**Build and monetize apps from natural language in minutes**" Building software usually takes time, budget, and technical skill. Eitherway changes that with AI app generation for mobile apps, browser extensions, full-stack web apps, and Web3 dApps. Describe your idea. Generate the app.\ Test it instantly. Deploy it. Monetize it. Launch a token if your product needs its own economy. Get started {% endcolumn %} {% column %} {% embed url="" %} {% endcolumn %} {% endcolumns %}

Learn how to build, deploy, and launch with Eitherway

Read product guides, watch tutorials, and explore examples of AI-generated apps built with Eitherway.

Templates Documentation

***

Join the Eitherway builder community

Join founders, makers, and developers building AI apps, Web3 products, and tokenized experiences with Eitherway.

Cover image

:telegram:

TelegramJoin the Eitherway community on Telegram.Join Telegram/files/B1Wo38wGwcUfbQr8OYkP

:square-x-twitter:

X (formerly Twitter)Follow product updates, launches, and builder stories.Follow us on X/files/SNso8wHVi18kY0mx1Cko

:globe-pointer:

WebsiteVisit the Eitherway website to start building your app.Official Website/files/mynYIGdLTEVnDVCLbGvU
# Vision & Mission #### **Vision** Eitherway envisions a world where software creation is not constrained by developer expertise, fragmented tooling, or long development cycles. Our platform enables rapid application building, deployment, and iteration across web, mobile, and blockchain within a single AI-powered environment. We believe the future of software development is not just conversational but executable. AI should not only assist. It should build, run, and deploy. #### **Mission** We are transforming software development through four key objectives: 1. Empowering Creators\ Making production-grade applications accessible to anyone, regardless of coding background. Users can now launch real products without assembling teams or raising capital. 2. Accelerating Teams\ Reducing development timelines from months to hours by unifying planning, building, testing, and deployment into a continuous execution loop. 3. Bridging Platforms\ Allowing a single project to operate across web, mobile, extensions, and blockchain environments from one system. 4. Expanding Into Markets\ Enabling applications to evolve into live systems with integrated token economies and liquidity, all managed within the same environment. AI handles development, deployment, and scaling. Eitherway is not just a development tool. It is infrastructure for building, deploying, and operating applications and their associated systems. # Problem & Opportunity Eitherway solves the gap between AI coding assistants and deployment with a full-stack AI app builder for web, mobile, and Web3 applications. #### **The Problem With AI Coding Assistants and No-Code Tools** Current AI coding assistants like Copilot, ChatGPT, and Claude improve productivity but lack execution capabilities. They cannot run code, manage environments, provision infrastructure, or handle deployment. They suggest. They do not ship. No-code app builders simplify UI creation but limit flexibility, extensibility, and ownership. You can build, but you do not fully control what you create. *** #### **Key Challenges** • Fragmented pipelines across tools, environments, and deployment workflows\ • High barriers for non-developers moving from prototype to production\ • Resource inefficiencies from integrating multiple systems instead of shipping products\ • Web3 app development requiring specialized and scarce expertise *** #### **The Opportunity in AI App Development** Demand for software, AI app development, and no-code development platforms continues to accelerate across multiple markets. | Segment | Projection | | ------------------ | ---------------- | | No-code platforms | $45B+ by 2027 | | AI developer tools | $22B by 2030 | | Mobile/Web apps | 6M+ applications | Entry costs remain high. A basic MVP can cost 20 to 50 thousand dollars to build. Enterprise systems scale into millions. *** #### **Eitherway’s Solution: A Full-Stack AI App Builder** Eitherway is a full-stack AI development platform for Web2 and Web3 applications. It combines app building, deployment, infrastructure, and monetization in a single system. It removes the need for separate tools, environments, and integrations by allowing users to go from idea to live product within one workflow. Teams can build web apps, mobile apps, browser extensions, and blockchain applications from a single prompt-driven workspace. *** #### **Core Capabilities of the Platform** • Build applications from a single prompt, including frontend, backend, APIs, and business logic\ • Deploy production-ready apps directly from the platform\ • Integrated infrastructure layer including hosting, storage, runtime execution, and environment management\ • Native Web2 functionality including authentication, databases, and payments\ • Native Web3 functionality including wallets, smart contracts, and on-chain interactions\ • Direct deployment to Solana with full smart contract support\ • Integrated storage layer ensuring applications persist without reliance on centralized servers\ • Built-in swap functionality and liquidity routing via integrated providers\ • Token creation and launch directly within the platform\ • Automatic liquidity pool creation and locking mechanisms\ • Economic layer embedded at the protocol level *** #### **Built-In Economic System** Every action inside Eitherway contributes to the network: • Application usage generates protocol activity\ • Token launches create locked liquidity\ • Platform usage drives demand for $EITHER\ • Buybacks and burns are triggered through system activity This creates a closed-loop system where usage, liquidity, and token demand are directly connected. *** #### **Outcome for Founders, Developers, and Teams** Eitherway enables users to: • Go from idea to live application without external tools\ • Launch and scale products without managing infrastructure\ • Integrate payments, tokens, and liquidity from day one\ • Retain full ownership of code and assets\ • Replace fragmented AI coding, no-code, and deployment workflows with one platform # Glossary | **WebContainer** | In-browser sandbox that executes Node.js, filesystem, and terminal operations safely without server roundtrips | | ------------------ | -------------------------------------------------------------------------------------------------------------- | | **Artifact** | Output from a build process that gets deployed or uploaded to a store (APK, IPA, extension package, etc.) | | **Pipeline** | Sequence of automated steps from source code through artifact creation to deployment | | **Manifest v3** | Modern Chrome extension format utilizing a service-worker background model | | **ABI** | Application Binary Interface – contract interface enabling frontends to encode and execute blockchain calls | | **Pinning** | Process of persisting IPFS content to ensure ongoing availability across the network | | **SLO** | Service Level Objective – metric used for tracking operational performance | | **Store Track** | Release distribution channel (internal, closed, open, or production) | | **Rollout** | Phased release strategy distributing updates to user segments for safety validation | | **Runtime Secret** | Security credential injected during execution rather than hardcoded in source | | **SPL Token** | Solana Program Library token – Solana’s standard for fungible tokens (equivalent to ERC-20) | | **Metaplex** | NFT standard and tooling for Solana blockchain | | **Devnet** | Solana’s development network for testing (free SOL via airdrop) | | **Scaffold** | Pre-built template that loads instantly (5 seconds) vs AI-generated templates | # Core Concept
#### **Core Concept** Eitherway is a full-stack, AI-native development environment operating entirely within the browser. It transforms plain-language descriptions into live, production-ready applications within a single workspace. It does not stop at code generation. It handles execution, deployment, infrastructure, and monetization. *** #### **Key Differentiators** #### **Executable AI** Rather than providing suggestions, Eitherway executes. It can: • Install and manage dependencies\ • Run terminal commands\ • Configure backend services, databases, and environments\ • Deploy applications directly\ • Detect and fix runtime errors All within a secure, sandboxed environment. *** #### **In-Browser Development Environment** Applications run entirely in-browser with full runtime support: • Full Node.js and terminal capabilities\ • Instant builds and live previews\ • No external setup or local environment required\ • Real execution environment, not simulation *** #### **Integrated Infrastructure** Applications are not just built, they are hosted and persisted: • Built-in hosting and deployment\ • Decentralized storage integration for persistence\ • No reliance on external infrastructure providers\ • Applications remain live, stored, and accessible *** #### **Web2 + Web3 Native** Eitherway supports both traditional and on-chain development natively: • Authentication, databases, and payments (Web2)\ • Wallets, smart contracts, and on-chain logic (Web3)\ • Direct deployment to Solana\ • Integrated swaps and liquidity routing *** #### **Token + Liquidity Layer** Applications can evolve into economies: • Token creation directly within the platform\ • Liquidity pool creation and locking\ • Protocol-level integration with $EITHER\ • Built-in mechanisms for demand, buybacks, and burns *** #### **Cross-Platform Outputs** A single project can generate: • Web applications (Next.js, Remix, Astro, Vue, Svelte)\ • Mobile apps (React Native, Flutter)\ • Browser extensions (Chrome, Firefox)\ • Web3 applications with smart contracts *** #### **Hybrid Flexibility** • Non-technical users can remain fully prompt-driven\ • Developers can inspect, edit, and extend code at any stage\ • Teams can collaborate in real time *** #### **The 5-Stage Workflow** UNDERSTANDING → AI interprets the request\ PLANNING → System defines architecture and structure\ BUILDING → Production-ready code is generated\ TESTING → Verified in a live environment\ DEPLOYING → Application is published and accessible From concept to live application, infrastructure, and monetization in one system. # Target Audience & Use Cases #### **Non-Technical Founders** **Challenge:** Need to launch MVPs without capital for dev teams\ **Solution:** Describe a photo-sharing app; Eitherway scaffolds the frontend, configures backend services, deploys the app, and enables payments or tokenization within the same workflow\ **Impact:** Save $20–50k in outsourcing; compress months into hours #### **Product Managers** **Challenge:** Need internal tools and prototypes on demand\ **Solution:** Request a dashboard pulling retention data from PostgreSQL; receive a responsive app with live data connections, deployed and accessible without additional setup\ **Impact:** Development cycles shrink from weeks to hours #### **Independent Developers** **Challenge:** Want to increase output and revenue\ **Solution:** Scaffold SaaS products with multi-tenancy, payments, and optional token layers; customize, deploy, and monetize directly\ **Impact:** Increase product output without increasing workload #### **Web3 Teams** **Challenge:** Need to ship dApps without specialist bottlenecks\ **Solution:** Build full-stack dApps with wallet integration, smart contracts, and frontend deployment; manage infrastructure, storage, and execution in one environment\ **Impact:** Replace fragmented workflows with a single execution pipeline #### **Enterprises** **Challenge:** Enable internal innovation without losing control\ **Solution:** Role-based access, secure environments, and controlled deployments across internal or private infrastructure\ **Impact:** Maintain governance while accelerating product development # Technical Architecture
### **Overview** Eitherway’s architecture enables AI with real execution control over a full-stack development environment, entirely within the browser. It functions as a live, sandboxed operating system where applications are built, executed, deployed, and maintained within a single environment. *** ### **Frontend Stack** | Layer | Technology / Capability | | ---------------- | ------------------------------------- | | Frameworks | React, Next.js, Vue, Svelte | | Rendering | Client-side and server-side rendering | | Styling | Tailwind CSS, component libraries | | State Management | Context API, Zustand, Redux | | Editor Interface | In-browser IDE with live preview | *** ### **Backend Stack** | Layer | Technology / Capability | | -------------- | -------------------------------------------------- | | Runtime | Node.js (WebContainer environment) | | Database | PostgreSQL (via integrated services like Supabase) | | Authentication | Built-in auth systems | | Storage | File storage and asset handling | | APIs | Auto-generated REST and service endpoints | *** ### **Infrastructure Layer** | Component | Capability | | ---------- | ---------------------------------------------- | | Execution | In-browser WebContainer runtime | | Deployment | Integrated deployment + external providers | | Storage | Persistent and decentralized storage options | | Hosting | Live application hosting | | Web3 | Smart contracts, wallets, on-chain interaction | *** ### **AI Orchestration Layer** The system operates across four stages: **Prompt Parsing**\ Understands user intent, requirements, and structure **Build Planning**\ Generates architecture, dependencies, and file structure **Command Execution**\ Executes commands directly within the runtime environment **Iterative Refinement**\ Continuously updates based on live preview and system feedback *** # Deployment & Scalability Eitherway supports **four primary deployment types**, each with its own CI/CD process. #### **1. Web Deployment**
Projects compile within WebContainer; artifacts upload to Vercel, Netlify, AWS Amplify, or Cloudflare Pages with automatic domain and SSL configuration. #### **2. Mobile Deployment**
* Android: Cloud-based Gradle builds (AAB/APK) -> Google Play * iOS: Xcode Cloud/Fastlane -> App Store Connect #### **3. Browser Extension Deployment**
Automatic Manifest v3 generation, lint checks, compatibility tests, direct upload to Chrome Web Store or Mozilla Add-ons. #### **4. Web3 Deployment**
Solidity compilation via integrated tools, deployment to EVM networks, frontend to IPFS with pinning services. #### 5. Scalability * Stateless backends with horizontal scaling * On-demand cloud builds via serverless runners * CDN distribution for static assets *** #### **Security & Compliance** Security is handled on multiple levels: * **Environment isolation** – WebContainers ensure no malicious code escapes the sandbox. * **Dependency scanning** – Automated vulnerability checks during package installs. * **API key encryption** – All keys and secrets are encrypted both in transit and at rest. * **Store compliance** – Automated checks for Google Play/App Store guidelines before submission. *** #### **Scalability Approach**
* Stateless backends with horizontal scaling * On-demand cloud builds via serverless runners * CDN distribution for static assets # Features #### **AI-Controlled Full Stack** Eitherway operates as a full-stack execution environment: • Installs and manages dependencies automatically\ • Configures APIs, databases, and runtime environments\ • Executes build and deployment commands\ • Supports live preview with hot reload\ • Detects and fixes runtime errors automatically *** #### **Cross-Platform Outputs** | Output Type | Capabilities | | ------------------- | ------------------------------------------------------ | | Web Applications | Full-stack apps with deployment and live hosting | | Mobile Applications | Cross-platform apps with backend and API integration | | Browser Extensions | Production-ready extensions with persistent logic | | Web3 Applications | Smart contracts, wallet integration, token + liquidity | *** #### **Real-Time Collaboration** Live environments can be shared via link. Collaborators can: • Preview applications in real time\ • Submit prompts and suggestions\ • Modify and extend functionality collaboratively *** #### **Brand Kit Integration** Upload brand assets for automatic application across builds: • Logo integration across UI components\ • Color extraction and consistent styling\ • Typography alignment\ • Reusable asset library *** #### **Backend Services** Backend infrastructure is provisioned automatically, with integrated services including Supabase: • Managed PostgreSQL databases\ • Authentication systems out of the box\ • File storage and asset handling\ • Real-time data subscriptions\ • Auto-generated APIs No manual setup or external configuration required. *** #### **Integrated Infrastructure** Applications are deployed and persist by default: • Built-in hosting and deployment\ • Persistent storage layer\ • No reliance on external setup or manual configuration\ • Applications remain live and accessible *** #### **Web2 + Web3 Support** Eitherway supports both traditional and on-chain functionality: • Payments, authentication, and APIs\ • Wallet integration and smart contracts\ • On-chain interactions and token support\ • Integrated swap and liquidity routing *** #### **Image Generation** Built-in image generation supports: • UI assets and placeholders\ • Product mockups\ • Brand visuals # Competitive Landscape #### **Market Position** Eitherway operates at the intersection of four expanding sectors: • AI-powered development environments\ • No-code and full-code platforms\ • Cloud and in-browser execution environments\ • Web3 infrastructure and tokenized economies A new category is emerging where applications are not only built, but deployed, operated, and monetized within a single system. Eitherway unifies these into one platform. *** #### **Competitive Analysis** | Platform | Code Generation | Deployment | Infrastructure | Web3 Support | Token + Liquidity | | --------------- | --------------- | ---------- | -------------- | ------------ | ----------------- | | Cursor | Yes | No | No | No | No | | Replit | Yes | Partial | Partial | No | No | | v0 (Vercel) | Yes | Yes | Yes | No | No | | Lovable / Bolt | Yes | Partial | No | No | No | | Stitch (Google) | Yes | No | No | No | No | | **Eitherway** | Yes | Yes | Yes | Yes | Yes | *** #### **Key Differentiators** **AI Control & Execution**\ AI executes across the full lifecycle, not just code generation. **Execution Infrastructure**\ In-browser runtime combined with integrated infrastructure enables building, deployment, and persistence within one system. **Multi-Platform Output**\ Web, mobile, extensions, and Web3 applications from a single workflow. **Code Ownership**\ Full exportability with no vendor lock-in. **Web3 Integration**\ Wallets, smart contracts, on-chain logic, and Solana deployment built in. **Token + Liquidity Layer**\ Token creation, liquidity provisioning, and protocol-level economic integration are native to the platform. *** #### **Our Position** Eitherway is not a coding assistant or a no-code tool. It is a full-stack execution platform where applications are built, deployed, operated, and monetized in one system. # Roadmap #### **Phase 1: Core Build & Web Deployment (COMPLETED)** • Secure WebContainer runtime running Node.js in-browser\ • AI-controlled execution for packages, file systems, and terminals\ • Integrated code editor with autocomplete and syntax checking\ • Real-time preview with hot reload\ • Deployment support including Vercel and Netlify, with automatic SSL\ • Persistent application hosting and storage within the platform *** #### **Phase 2: Mobile App Deployment (IN PROGRESS)** • Android builds through cloud-based Gradle runners (AAB/APK)\ • iOS builds via Xcode Cloud or Fastlane with App Store Connect\ • Direct build triggering from the Eitherway interface\ • Cross-platform React Native and Flutter support *** #### **Phase 3: Web3 Deployment (COMPLETED)** • Smart contract compilation and deployment\ • Automated ABI integration into frontends\ • Mainnet workflows with wallet prompts and gas estimation\ • IPFS hosting with pinning services (including Pinata)\ • Solana SPL token and NFT support *** #### **Phase 4: Mobile Application & Launchpad (UPCOMING)** • Eitherway mobile app for building and managing applications\ • Application launchpad enabling token creation at the app level\ • Liquidity provisioning and locking mechanisms\ • Token integration with the $EITHER economic layer\ • One-click mobile deployment for iOS and Android *** #### **Phase 5: Plugin & Template Marketplace (UPCOMING)** • Creator tools for templates, UI kits, and plugins\ • Marketplace search, reviews, and purchase workflows\ • Native credit system for transactions\ • Revenue sharing for creators *** #### **Phase 6: Enterprise Features (LONG-TERM)** • Private AI model hosting for enterprise use\ • On-premise or VPC deployment options\ • Role-based access control and audit logging\ • SSO integration\ • Compliance-ready infrastructure # Marketplace Vision The marketplace transforms Eitherway from a platform into a network. **For Developers:** Sell SaaS templates, dApp frameworks, backend modules, and full applications\ **For Designers:** Offer UI kits and design systems optimized for deployment-ready builds\ **For AI Specialists:** Publish prompt systems, workflows, and reusable automation logic Transactions run through a native credit system, with optional tokenization and integration into the $EITHER economic layer. Marketplace activity contributes to platform demand, linking usage, distribution, and monetization within the same system. # Overview Eitherway is not just an app builder. It is a build environment connected to the infrastructure real products need in order to work. Turning a prompt into an interface is only one part of the job. What matters just as much is everything underneath it: chain access, wallets, authentication, payments, data, liquidity, launch rails, and runtime performance. That is why the integration layer matters. The goal is simple. Builders should not have to piece together five or ten separate services before they can ship something usable. Eitherway brings those layers closer to the point of creation, so users can spend more time on the product and less time wiring the stack together. # Why This Matters A lot of builder tools stop at generation. That is not enough. A product still needs to authenticate users, connect wallets, process payments, fetch live data, run onchain actions, manage state, and hold up once people actually start using it. If those layers are missing, the output may look good, but it is not a real product. Eitherway is built around reducing that gap. The integration layer exists to make the hard parts of software and Web3 infrastructure more accessible inside the build flow itself. # Chain and Ecosystem infrastructure Eitherway supports builders working across multiple ecosystems, with Solana as a core base and expanding support across additional networks. #### **Solana** Solana is a primary execution environment for onchain applications, launch activity, and liquidity coordination across the ecosystem. #### **Base** BASE extends the builder path into a growing EVM environment, allowing users to create products with Base-native functionality directly inside the Eitherway workflow. #### **Tron** Tron expands network reach and gives the platform another chain layer for future builder and launch activity. #### **Wormhole** Wormhole supports interoperability and cross-chain use cases, making it easier to build products that move across ecosystems instead of staying locked inside one network. # Wallets, Onboarding, and Access A product is only as usable as its first few minutes. If onboarding is heavy, most users will never get to the value. That is why Eitherway integrates wallet, authentication, and access layers directly into the stack. #### **Solflare** Solflare supports wallet connectivity and access across Solana-native workflows. #### **Privy** Privy adds wallet infrastructure, authentication, and embedded wallet support, making onboarding smoother for users who are not already deep in crypto. #### **MoonPay** Moonpay helps bridge mainstream user flows into onchain participation by simplifying wallet funding and access to crypto rails. These layers matter because a technically functional app can still fail if getting into it is too much work. # Trading, Liquidity, and Launch infrastructure For many builders, deployment is not the end of the workflow. Once a product goes live, it may also need routing, liquidity, trading access, launch support, and market visibility. That is where the market infrastructure layer comes in. #### **dFlow** dFlow supports routing and execution infrastructure for trading-related product flows. #### **Kamino** Kamino expands access to DeFi functionality, including lending, vault, and yield-related use cases. #### **Meteora** Meteora plays a key role in launch mechanics and liquidity formation, particularly around bonding curve-based launch structures. #### **Jupiter** Jupiter supports broader routing and trading access across the Solana ecosystem. #### **Raydium** Raydiumadds liquidity and market infrastructure for product and launch-related trading flows. #### **Streamflow** Streamflow supports launch and distribution mechanics tied to ecosystem rollout. #### **Fomo** and **Moonshot** Both extend visibility, discovery, and trading support around launched assets and token pairs. #### **Aerodrome** Aerodrome expands the builder path into Base-related DeFi and liquidity use cases as Eitherway continues to support broader multi-ecosystem builds. These integrations matter because for some products, launch also means market access. # Data, Analytics, and Oracle Infrastructure A lot of useful products depend on live information. Dashboards, market tools, tracking apps, analytics products, and onchain workflows all need reliable data under the hood. Eitherway integrates the data and oracle layers needed to support that. #### **Birdeye** Birdeye supports token analytics, trading visibility, and market data. #### **QuickNode** Quicknodes provides RPC and network infrastructure across supported chains and environments. #### **Chainlink** Chainlink adds oracle infrastructure for products that need trusted external data, smart contract triggers, and more advanced automation patterns. #### **Pyth Network** Pyth Network supports price feed and market data use cases where accurate, onchain-aware information is required. #### **Codex** Codex improves metadata indexing, pair recognition, and market visibility across terminals and trading interfaces. These systems make it easier for builders to create products that rely on real-time information instead of static output. # Payments, State, and Runtime Infrastructure A usable product needs more than a front end. It also needs a runtime layer that can support sessions, payments, caching, persistence, and real-time behavior once users show up. #### **Stripe** Stripe provides payment infrastructure for monetizable applications, including SaaS, subscriptions, and other business models built through Eitherway. #### **Upstash** Upstash supports fast state handling, caching, queues, rate limiting, and real-time application behavior for products that need more than static generation. This matters because a lot of products do not fail at the point of creation. They fail once real usage starts. # Asset Infrastructure Eitherway also integrates asset-layer infrastructure for builders working with digital assets and ecosystem-native ownership models. #### **Metaplex** Metaplex extends asset creation and asset-layer functionality inside the Solana ecosystem. That makes it easier for builders to create products involving digital assets, ownership logic, and onchain asset behavior without having to source that layer separately. # A Connected Build Environment #### Taken together, these integrations form the infrastructure layer behind Eitherway. They are not there for optics. They are there because builders need real systems underneath the things they create. Wallets, payments, analytics, launch rails, liquidity, onchain execution, runtime support, and ecosystem access all shape whether an app can move from prompt to something usable in the market. Eitherway is built to reduce how much of that the user has to assemble manually. The result is a more connected build environment, where the builder can focus more on the product, the workflow, and the use case, while the required infrastructure sits closer to the point of creation. # Overview Here is a cleaner **Overview** version for GitBook: ### Overview The Eitherway AI Companion is being built to behave less like a code generator and more like a working partner inside the platform. That distinction matters. A code generator takes a prompt, produces output, and hands the result back. The Eitherway AI Companion is being designed to do more than that. It is intended to plan before acting, explain what it is about to do, check whether its work actually succeeded, recover from errors where possible, remember project context over time, and operate within clear safety boundaries. The goal is not just faster output. It is a system users can work with directly across the full lifecycle of what they build. The companion is also being designed to work across the broader Eitherway experience, not only inside the main platform interface. As the product expands, users will be able to interact with it through messaging-first environments already central to the Eitherway workflow, including Telegram, with broader support being explored across additional interfaces. The aim is to let users work with the companion in the context that feels most natural to them, rather than forcing all interaction into a single surface. The internal standard for the companion has been simple from the start: it should behave more like a teammate than a tool. That means it does not just respond to prompts with isolated code. It is expected to reason through a task, break the work into steps, surface its plan in plain language, carry out the work, verify the result, and return with something the user can actually trust. This is a different standard from traditional AI tooling. It is also a more useful one. # How it Works One of the first principles behind the companion is that it should not act blindly. Before making meaningful changes, it produces a plan in language a non-engineer can understand. The user can approve that plan, request changes, or send it back. This creates a clear decision layer before the system changes anything important. That matters because one of the most common failures in AI tooling is not bad output on its own. It is unexpected output delivered without context. Planning out loud reduces that problem. The companion is also built to check whether its work actually succeeded before treating a task as complete. #### That means running the equivalent of basic validation after a change: * did the build succeed * do tests still pass * does the preview load cleanly * did the intended result actually happen If something is off, the system should not pretend otherwise. The standard is simple: when the companion says a task is done, that should mean something. A major part of the work so far has been getting the companion to recover from failure instead of stopping at the first issue. When something breaks during execution, the system attempts to identify the problem, apply a fix, re-run the checks, and only return to the user if it reaches a real decision point. That changes the product significantly. The difference between a system that gives up at the first error and one that can work through problems on its own is the difference between a tool that needs constant supervision and one that can be trusted with meaningful tasks. The companion is also being developed to help with maintenance over time, not only first-pass execution. That includes surfacing issues inside the codebase, identifying when dependencies or environments need attention, and asking for approval before applying meaningful updates. The aim is to help keep projects functional and current, not just help create them once. The companion also includes a dedicated in-app panel so users can see what it is doing in real time. #### That panel is intended to show: * the plan being followed * the actions being taken * what was auto-approved * what is waiting for user input * the full history of previous runs # Memory & Scheduled Runs Most AI products still begin each session from zero. Users explain the project, explain the conventions, explain what was tried last time, and then repeat the same setup in the next session. The Eitherway AI Companion is being built with memory across sessions so that project context, style, and user preferences carry forward over time. Older or outdated context can fade, reducing the risk of the system getting stuck on stale assumptions. Users will also be able to clear memory when they want a clean start, such as when beginning a new project. Scheduled runs are already working internally. The aim is to let users assign work to the companion, step away, and return to a finished plan, a summary of what was done, and a set of changes laid out for review. This is the shift from an assistant that needs to be actively driven to a system that can be delegated to. That capability is not yet fully released to users, but it is a core part of where the product is heading. As this workflow develops further, users will not need to stay inside the product and manually supervise every step. The companion is being built to handle work asynchronously, with updates and progress flowing back through the relevant interface, including Telegram-based workflows that are already central to the Eitherway experience. The intention is to make delegation feel practical, not theoretical. # Safety Model The companion operates with tiered permissions. Low-risk actions, such as formatting, isolated edits, or well-understood changes, can be handled directly. Higher-risk actions, such as anything involving money, production deployment, or destructive changes, pause for approval first. These boundaries are being tuned with a bias toward caution. As a rule, asking too often is a manageable inconvenience. Acting too far without approval is not. This matters because the more useful an AI system becomes, the less acceptable it is for it to behave like a black box or take important actions without the user understanding what is happening. The aim is not to make the system passive. The aim is to make it useful while keeping decision-making where it belongs when risk is involved. The companion should be able to move quickly on safe tasks, slow down when needed, and remain transparent throughout. # Security Foundation A more capable companion only matters if the platform underneath it is trustworthy. That is why the AI Companion work has been moving alongside a broader security and infrastructure hardening pass across the live platform. The companion is not being built in isolation. It is being built on top of a safer default environment. #### Recent platform work already live in production includes: * tamper-resistant audit records for sensitive actions * stronger, unified authentication across the platform * access tokens kept only in browser memory, not written to disk * secrets stored hashed at rest * platform-wide rate limits to reduce abuse * stricter isolation between previews and embedded widgets * closure of older exposed or weak API paths * stronger security awareness inside the code generation model itself The point of this work is simple: autonomy without trust is not a product worth shipping. The model layer behind code generation has also been updated to recognize and warn against a growing list of common security pitfalls. #### That includes issues such as: * cross-site scripting * unsafe signature handling * cross-origin access mistakes * insecure token contract permissions * unsafe automation patterns * other known review blockers The result should be fewer bad suggestions, fewer avoidable review failures, and output that is safer by default. # What’s Next The AI Companion remains a major focus of development. The autonomous loop is already functioning internally. The next stage is making it more reliable across longer runs, improving the usefulness of scheduled execution, and refining the safety tiers so the system asks exactly when it should. The broader objective is not to create a more impressive demo. It is to build a companion that is genuinely useful to work with, and reliable enough to trust inside the product. As the system gets closer to release, the focus will remain on three things: * making the companion more dependable over longer tasks * improving visibility and control for the user * continuing to harden the platform underneath it The goal is clear: make AI more useful in practice, and safer to rely on. # Environment & Credentials Eitherway separates configuration by environment to keep builds deterministic and secrets safe. ### Environments | Environment | Purpose | | ------------------- | ------------------------------------------- | | **Local Workspace** | Development servers and preview deployments | | **Build Runners** | Temporary variables for compilation | | **Runtime** | Production settings managed by host | *** #### Secrets Management Best practices: 1. Store credentials in a dedicated vault or secret manager 2. Rotate keys regularly 3. Apply minimal access permissions 4. Conceal values in logging systems 5. Never hardcode into source control 6. Use distinct keys per environment and service *** #### **Naming Conventions** Recommended format: `API_URL` \ `AUTH_ISSUER` \ `STRIPE_KEY` \ `FIREBASE_PROJECT`\ `WALLETCONNECT_PROJECT` \ `ALCHEMY_API_KEY` \ `PINATA_JWT` Optional environment suffixes: `_DEV`, `_STAGE`, `_PROD`. #### Required Environment Variables | Variable | Purpose | Required | | -------------------------- | ----------------------- | ---------- | | `ANTHROPIC_API_KEY` | Claude AI | Yes | | `OPENAI_API_KEY` | DALL-E image generation | Yes | | `POSTGRES_*` | Database connection | Yes | | `PRIVY_APP_ID` | Authentication | Yes | | `PRIVY_APP_SECRET` | Authentication | Yes | | `ALCHEMY_API_KEY` | EVM blockchain RPC | Yes (Web3) | | `PINATA_JWT` | IPFS storage | Yes (NFTs) | | `WALLETCONNECT_PROJECT_ID` | Wallet connection | Yes (Web3) | | `DEPLOYER_PRIVATE_KEY` | Contract deployment | Yes (Web3) | | `ENCRYPTION_KEY` | Credential encryption | Yes | | `SUPABASE_*` | Backend service | Optional | *** ### Injection 1. Create `.env.example` from prompt requirements. 2. Keep real values in a secret store. 3. Build runners receive scoped secrets; web hosts receive runtime secrets.
#### For Web3 applications • Secure handling of wallet connections and signing\ • Integration with on-chain interactions and smart contract execution\ • No exposure of sensitive keys within the application layer All credentials are managed within a controlled execution environment to ensure security, isolation, and reliability. # Security Model #### Authentication & Authorization **Privy Integration** * Unified Web2 (email) + Web3 (wallet) authentication * OAuth support: Google, Discord, GitHub * Session management with secure tokens **Wallet Authentication** * WalletConnect/AppKit integration * MetaMask, Phantom, Solflare support * Chainless wallet connection *** #### **Data Protection** | Layer | Protection | | --------- | ----------------------------------- | | Transport | TLS 1.3 (HTTPS everywhere) | | Storage | AES-256 encryption for credentials | | Secrets | Encrypted in database, never logged | *** #### Input Validation * JSON Schema validation via AJV for all inputs * SSRF protection with URL allowlists * Path traversal prevention * File type validation (MIME checking) *** #### **Rate Limiting** | Limit | Default | | --------------- | -------------- | | Requests/second | 30 per user | | File upload | 200MB per file | | Request body | 250MB maximum | *** #### Sandbox Security * WebContainer isolation for code execution * No access to host filesystem * Network request filtering * Resource limits enforced # Release & Rollback Playbooks #### Web **Release** — Build, smoke test, deploy to preview, promote to production. **Rollback** — Revert to previous deployment, invalidate CDN cache, verify health checks. #### Mobile **Release** — Build, internal track, closed testing, open or beta, production. **Rollback** — Halt rollout, ship hotfix with incremented version, update release notes. #### Extensions **Release** — Bundle, store validation, staged rollout. **Rollback** — Unpublish affected version, republish previous version, notify users. #### Web3 **Release** — Testnet deploy, verification, gated mainnet deploy, bind ABIs, publish UI. **Rollback** — Disable UI routes that touch affected contracts, deploy patched contracts, migrate state if required.
# Platform Limits & Quotas #### Session Limits | Resource | Free Tier | Pro Tier | Enterprise | | ---------------- | --------- | --------- | ---------- | | Sessions/day | 10 | Unlimited | Unlimited | | Messages/session | 50 | 500 | Unlimited | | File size | 10MB | 100MB | 200MB | | Total storage | 500MB | 5GB | Custom | *** #### Build Limits | Resource | Free Tier | Pro Tier | Enterprise | | ----------------- | --------- | -------- | ---------- | | Builds/day | 5 | 50 | Unlimited | | Build timeout | 5 min | 15 min | 30 min | | Concurrent builds | 1 | 3 | 10 | *** #### API Rate Limits | Endpoint Category | Rate | | -------------------- | ------- | | Chat messages | 30/min | | File operations | 100/min | | Deployments | 10/hour | | Contract compilation | 20/hour | | Image generation | 10/hour | # Store Compliance Submission quality reduces rejections and speeds review. Use these checklists before publishing to mobile or extension stores. ### Mobile Stores #### Content & Privacy * Accurate app descriptions and screenshots for each device class. * Clear privacy policy URL with data collection details. #### Technical * Correct code signing and provisioning profiles. * Version and build numbers incremented consistently. * Runtime permissions minimized and justified. #### Review * Stable test accounts and credentials provided to reviewers. * In-app purchase compliance where applicable. * Crash-free sessions verified before submission. ### Extension Stores #### Manifest * Manifest v3 validates locally. * Only required host permissions requested. * Icons and localized text included. #### Packaging * Single zip bundle with correct structure. * No remote code execution patterns. #### Review * Clear changelog and version history. * Visible support and privacy links. # Web3 Networks & Deploy Checklist ### Suported Networks **EVM (Ethereum Virtual Machine)** | Network | Chain ID | Type | RPC Provider | | ---------------- | -------- | ---------- | ------------ | | Ethereum Sepolia | 11155111 | Testnet | Alchemy | | Base Sepolia | 84532 | L2 Testnet | Alchemy | | Arbitrum Sepolia | 421614 | L2 Testnet | Alchemy | **Solana** | Network | Type | RPC | | ------------ | -------------- | ---------------------- | | Devnet | Development | Public RPC | | Testnet | Pre-production | Public RPC | | Mainnet-Beta | Production | Custom RPC recommended | #### Deployment Checklist **Pre-Deployment** 1. Separate deployer keys from runtime wallets 2. Use allowlisted RPC endpoints 3. Enable rate limit monitoring 4. Test on devnet/testnet first **Contract Deployment** 1. Compile with latest Solidity version 2. Verify contract source code 3. Document constructor parameters 4. Record deployment transaction **Post-Deployment** 1. Maintain ledger: network, address, version, commit 2. Publish addresses for transparency 3. Set up monitoring 4. Document ABI for frontend integration ### Artifacts * Maintain a ledger of `network`, `contract`, `address`, `version`, and `commit`. * Verify contract source where possible and publish addresses.
# Backend Service (Supabase Integration) #### Overview EitherWay integrates Supabase for instant backend provisioning. One click gives your application: * Managed PostgreSQL database * Authentication (email, OAuth, magic links) * Storage buckets for files * Real-time subscriptions * Auto-generated REST and GraphQL APIs * Row-level security *** #### **Enabling Backend Service** 1. Click “Enable Backend” in the chat interface 2. Eitherway provisions a Supabase project 3. Credentials are securely stored and injected 4. Database schema is auto-generated from your requirements *** #### **API Endpoints** | Endpoint | Purpose | | ----------------------------------------- | ------------------------- | | `GET /api/backend-service/status` | Check provisioning status | | `POST /api/backend-service/enable` | Enable for an app | | `POST /api/backend-service/provision` | Provision resources | | `POST /api/backend-service/schema/apply` | Apply database schema | | `GET /api/backend-service/schemas/:appId` | Get current schema | *** #### **Database Tools** The AI agent can: * Create tables and relationships * Set up row-level security policies * Generate TypeScript types * Create API endpoints automatically * Set up real-time subscriptions *** #### Storage Buckets ``` POST /api/backend-service/storage/bucket { "appId": "your-app-id", "name": "user-uploads", "public": false } ``` # Eitherway Launchpad The Eitherway Launchpad is the native token launch layer within the Eitherway ecosystem. It supports both product-first and token-first launches. Teams can use it to launch tokens for applications built on Eitherway, for products developed externally, or for token-led ecosystems that plan to build the product layer over time. Eitherway’s preferred path is product first, then token. The reasoning is simple: launches tend to be stronger when there is already a real product, use case, or user flow behind them. That said, it is a preference, not a restriction. The launchpad is designed to support different paths to market. ### Strategic Rationale Most launchpads are built around issuance. Eitherway is built around execution. The launchpad is not just a standalone token listing surface. It sits inside a broader system that includes application creation, deployment, monetization, routing, indexing, and ecosystem expansion. That matters because it reduces the fragmentation teams usually face when moving from concept to launch. Instead of building in one environment, coordinating liquidity in another, and depending on separate tools for discovery and trading, teams can move through a more unified launch path. In practical terms, the launchpad connects three layers that are often disconnected: * product creation * tokenized coordination * market access That structure gives teams a clearer route from idea to launch and creates stronger alignment between the asset, the product, and the wider ecosystem. The launch model continues to use a bonding curve structure, but the default pairing model for permissionless launches has evolved. Rather than pairing every launch directly against **$EITHER**, permissionless launches now follow the native-chain path, beginning with **SOL pairs** and expanding into other chain-native pairs such as **Base** as the launchpad grows across ecosystems. This change is intended to keep the launchpad open and scalable while reducing the downside that weak permissionless launches can create for the main **$EITHER** pair. At the same time, launch activity continues to support the wider ecosystem through a **0.5% residual fee on volume**, which accrues toward periodic **buyback and burn of $EITHER**. In that model, **$EITHER** remains central to the launchpad economy, not as the default pair for every permissionless launch, but as the core value-capture layer of the ecosystem. Curated and vetted launches can still use **$EITHER** more directly under stronger market and liquidity conditions, while the broader permissionless system is designed to route value back into the main token in a more sustainable way. That is the core logic behind the updated model: keep the bonding curve, shift permissionless launches toward native-chain pairs, and make sure launch activity still strengthens the **$EITHER** economy over time. # Supported Launch Paths The Eitherway Launchpad supports three primary launch paths. #### 1. Product-first launches A team builds or deploys an application first, then introduces a tokenized economic layer around that product. This is the preferred path. The reasoning is simple: launches tend to be stronger when there is already a real product, use case, or user flow behind them. Product-led launches usually create better alignment between utility, user activity, and market participation. #### 2. Token-first launches A team launches the token first, uses it to coordinate early liquidity and community formation, and develops the product layer over time. This path is supported because some teams choose to use the token as the first coordination layer for building an ecosystem, then expand the product around it as traction grows. #### 3. External product launches A team with an existing product built outside Eitherway uses the launchpad as its token issuance and liquidity coordination layer. This allows external teams to access the launch infrastructure and ecosystem mechanics of the Eitherway Launchpad without needing to have built the product directly on Eitherway itself. All three paths are supported. The platform’s preference remains product first, because product-led launches generally create stronger alignment between utility, user activity, and market participation. But the launchpad is designed to remain flexible enough to support different routes to market, depending on the team, the product, and the stage of the ecosystem. # Launch Design Launches on the Eitherway Launchpad continue to use a bonding curve mechanism. That design still serves three functions at the launch layer: * structured initial price discovery * early liquidity formation * a defined path into broader trading access What has changed is the default pairing model for permissionless launches. Rather than pairing every permissionless launch directly against **$EITHER**, the launchpad now follows the native-chain path. On Solana, that means launches default to **SOL pairs**. As the launchpad expands across ecosystems, launches can also use other native-chain pairs, including **Base-native pairs**. This change is intended to make the permissionless system more scalable while reducing the downside that weak launches can create for the main **$EITHER** pair. At the same time, launch activity still feeds back into the wider Eitherway ecosystem. Each permissionless launch carries a **0.5% residual fee on volume**. That residual accrues toward periodic **buyback and burn of $EITHER**, allowing launch activity across the platform to support the main token without requiring every permissionless launch to be paired directly against it. At a high level, the launch sequence now follows this progression: * a project enters launch preparation * the token is configured for launch through the bonding curve * the default pair follows the native-chain route, such as **SOL** on Solana * the bonding curve manages early issuance and price discovery * liquidity depth forms onchain as activity progresses through the curve * routing expands into broader trading access and terminal visibility * a residual fee from launch volume accrues back toward **buyback and burn of $EITHER** The purpose of this architecture is not only to simplify launch mechanics, but to create a cleaner transition from issuance to liquidity, discovery, and market participation while keeping the wider **$EITHER** economy supported over time. # Technical Architecture The launch flow continues to use a bonding curve model, where token issuance, early price discovery, and initial liquidity formation are handled at the launch layer. As trading progresses along the curve, liquidity depth is established onchain before routing expands into broader secondary market access. What has changed is the default pairing path for permissionless launches. Instead of routing every launch through **$EITHER** by default, the launchpad now follows the native-chain route. On Solana, that means launches default to **SOL pairs**. As the launchpad expands across ecosystems, it can also support other native-chain pairs, including **Base-native pairs**. The routing layer is being connected to **Jupiter legacy API** execution paths so launch pairs can become accessible through a wider range of supported interfaces, terminals, and trading bots. As the model expands across ecosystems, routing follows the same principle: native-chain pairing for permissionless launches, with value flowing back into the wider **$EITHER** economy through launch activity. To support discoverability and price integrity, **Codex / Defined custom metadata indexing** is being used to improve pair recognition, metadata consistency, price visibility, and trading support across external terminals and aggregation surfaces. This is intended to reduce the visibility gap that often affects newly launched pairs in early market environments. Each permissionless launch also carries a **0.5% residual fee on volume**. That residual accrues toward periodic **buyback and burn of $EITHER**, allowing launch activity across the platform to strengthen the main token without requiring every permissionless launch to be paired directly against it. That is the technical logic behind the updated model: keep the bonding curve, use native-chain pairs for permissionless launches, expand routing and visibility through supporting infrastructure, and direct part of launch activity back into **$EITHER** through the residual fee model. # The Role of $EITHER **$EITHER** remains central to the launchpad economy, but its role is now more selective and more structural than simply acting as the default pair for every permissionless launch. Its role includes: * curated launch pair formation * liquidity coordination * ecosystem alignment * value capture from launch activity across the platform This gives **$EITHER** a direct relationship to what happens at the launch layer, even as the permissionless system moves toward native-chain pairs such as **SOL** and, over time, other chain-native pairs such as **Base**. As more projects launch through the system, **$EITHER** remains tied to the economic activity forming around new assets entering the ecosystem. That relationship now comes less from being the automatic pair for every launch, and more from the way launch activity feeds back into the token economy. In practical terms, that means **$EITHER** benefits through: * curated and vetted launch structures where appropriate * residual fee flow from permissionless launch volume * periodic buyback and burn supported by launchpad activity * its position as the core economic layer of the wider Eitherway ecosystem This design is intended to make **$EITHER** more than a passive platform token. It sits at the center of the launch economy, not by forcing every permissionless launch to pair directly against it, but by ensuring that launch activity across the platform continues to strengthen the wider **$EITHER** ecosystem over time. # Why This Model Matters The weakness of many launch systems is not speed. It is disconnection. Tokens can be launched quickly, but without a product layer, a clear liquidity path, discovery support, or ecosystem alignment, the launch often stays detached from real usage. That is the problem Eitherway is designed to address. The launchpad is not meant to replace the importance of product, distribution, or execution. It is meant to sit behind those functions and make tokenized coordination easier once a team is ready to go to market. For product-first teams, it creates a direct route from application to launch. For token-first teams, it provides structure, liquidity coordination, and ecosystem linkage. For external teams, it offers a launch path connected to Eitherway’s broader infrastructure. The Eitherway Launchpad extends the platform from application creation into tokenized launch infrastructure. It supports both product-first and token-first strategies, while maintaining a clear preference for launches backed by real products, utility, or product intent. The launch model continues to use bonding curve-based issuance, integrated routing, metadata indexing, and expanding terminal access. What has changed is the default pairing model for permissionless launches. Rather than routing every launch directly through **$EITHER**, permissionless launches now follow native-chain pairs such as **SOL**, with other native-chain paths such as **Base** expanding over time. At the same time, launch activity still supports the wider **$EITHER** economy. A **0.5% residual fee on launch volume** accrues toward periodic **buyback and burn of $EITHER**, allowing the launchpad to route value back into the main token without forcing every permissionless launch to pair directly against it. The objective is simple: reduce the distance between building something real and launching the economic layer around it, while keeping the Eitherway ecosystem aligned as launch activity grows. # Solana Integration #### Overview Eitherway provides full Solana blockchain support: * SPL Token creation and management * Metaplex NFT minting * Collection management * Devnet/testnet deployment *** #### SPL Token Creation ``` POST /api/solana/tokens/create { "userId": "user-123", "name": "My Token", "symbol": "MTK", "decimals": 9, "initialSupply": "1000000", "cluster": "devnet" } ``` Response: ``` { "success": true, "tokenId": "uuid", "mintAddress": "So1ana...", "signature": "5abc...", "explorerUrl": "https://explorer.solana.com/..." } ``` *** #### **NFT Collection Creation** ``` POST /api/solana/nft/collection { "userId": "user-123", "name": "My NFT Collection", "symbol": "MNFT", "description": "Unique digital art", "imageUri": "https://...", "cluster": "devnet" } ``` *** #### **NFT Minting** ``` POST /api/solana/nft/mint { "userId": "user-123", "collectionId": "collection-uuid", "name": "NFT #1", "imageUri": "https://...", "attributes": [ { "trait_type": "Background", "value": "Blue" }, { "trait_type": "Rarity", "value": "Legendary" } ], "royaltyBasisPoints": 500 } ``` *** #### Wallet Support Frontend applications use: * @solana/wallet-adapter-react – React integration * @solana/wallet-adapter-wallets – Wallet adapters * @metaplex-foundation/js – NFT operations **Supported wallets:** Phantom, Solflare, Torus *** #### **Airdrop (Devnet Only)** Get free test SOL: ``` POST /api/solana/airdrop { "address": "YourWallet...", "amount": 1, "cluster": "devnet" } ``` # EVM (Ethereum) Integration #### **Smart Contract Compilation** Eitherway compiles Solidity contracts using solc 0.8.26 **Supported Standards:** * ERC-20 (Fungible Tokens) * ERC-721 (NFTs) * ERC-1155 (Multi-Token) * Custom contracts Compilation API ``` POST /api/contracts/compile { "sourceCode": "pragma solidity ^0.8.0; ...", "contractName": "MyToken" } ``` *** #### Contract Deployment ``` POST /api/contracts/deploy { "bytecode": "0x...", "abi": [...], "constructorArgs": [...], "chainId": 11155111 } ``` Response: ``` { "success": true, "contractAddress": "0x...", "transactionHash": "0x...", "explorerUrl": "https://sepolia.etherscan.io/..." } ``` *** #### **Wallet Integration** Frontend applications use: * Wagmi 2 * React hooks for Ethereum * Viem — TypeScript Ethereum library * WalletConnect/AppKit — Universal wallet connection **Supported wallets:**\ MetaMask, Coinbase Wallet, Rainbow, Trust Wallet, and 300+ more. # Smart Contracts & NFTs #### **Contract Templates** | Template | Standard | Use Case | | -------------- | -------- | ---------------------- | | Basic Token | ERC-20 | Fungible tokens | | NFT Collection | ERC-721 | Unique collectibles | | Multi-Token | ERC-1155 | Gaming assets | | Escrow | Custom | Trustless transactions | | SPL Token | Solana | Solana fungible tokens | | Metaplex NFT | Solana | Solana NFTs | *** #### **IPFS Integration** NFT metadata and assets are stored on IPFS via Pinata: ``` POST /api/ipfs/upload-metadata { "name": "My NFT", "description": "A unique piece", "image": "ipfs://Qm...", "attributes": [...] } ``` **Response:** ``` { "success": true, "cid": "Qm...", "uri": "ipfs://Qm..." } ``` *** #### **NFT Metadata Standard** Both EVM and Solana NFTs follow compatible metadata: ``` { "name": "NFT Name", "symbol": "SYM", "description": "Description", "image": "ipfs://...", "attributes": [ { "trait_type": "Background", "value": "Blue" }, { "trait_type": "Rarity", "value": "Rare" } ], "seller_fee_basis_points": 500 } ``` # Templates & Scaffolds #### Scaffold Templates (Instant - 5 seconds) **Web2 Templates:** | Template | Description | Stack | | ------------------- | ------------------------ | ---------------------------- | | SaaS Landing | Startup landing page | React + Tailwind + shadcn/ui | | E-commerce Shop | Full shopping experience | React + Tailwind + Cart | | Developer Portfolio | Professional portfolio | React + Animations | | Financial Dashboard | Multi-page finance app | React + Recharts | | Analytics Dashboard | Metrics visualization | React + Charts | **Web3 Templates:** | Template | Description | Stack | | ---------------- | ---------------------- | --------------------- | | NFT Marketplace | Trading platform | Wagmi + Viem + AppKit | | Token Deployer | ERC-20 creation | Wagmi + Viem | | Web3 Escrow | Trustless transactions | Wagmi + Viem | | Crypto Dashboard | Price tracking | CoinGecko API | **Solana Templates:** | Template | Description | Description | | --------------------- | -------------------- | --------------- | | Solana Token Deployer | SPL token creation | @solana/web3.js | | Solana NFT Minter | Metaplex NFT minting | Metaplex SDK | *** #### Using Templates `User: "Create a SaaS landing page"` \ `AI: [Loads scaffold in 5 seconds]` `User: "Create a custom booking platform"` \ `AI: [Generates from scratch in 30 seconds]` # System Requirements #### Minimum * Node.js 18+ * PostgreSQL 14+ * 4GB RAM * 2 CPU cores #### Recommended * Node.js 20+ * PostgreSQL 15+ * 8GB RAM * 4 CPU cores * SSD storage *** #### Quick Start **Clone** ``` git clone https://github.com/eitherwayai/eitherway.git cd eitherway ``` **Install** ``` pnpm install ``` **Configure** ``` cp .env.example .env # Edit .env with your API keys ``` **Database** ``` psql $DATABASE_URL -f packages/database/src/migrations/*.sql ``` **Run** ``` pnpm run server # Backend (port 3001) pnpm run ui # Frontend (port 5173) ``` *** #### Support **Documentation**: docs.eitherway.ai\ **Website**: eitherway.ai **Telegram**: Community discussions\ **Twitter/X**: @eitherwayai\ **Enterprise**: *** # The Eitherway Prompting Guide You're not prompting code. You're describing a system. This guide covers everything you need to get production-ready outputs from Eitherway, from your first prompt to a fully deployed, monetizable application. # Core Framework #### Every strong prompt follows this structure: What + User + Features + Data + Output | **Element** | **Question to answer** | | ----------- | ------------------------------------------------------ | | What | What type of application is this? | | User | Who is using it and what do they need? | | Features | What specific functionality does it need? | | Data | What data sources, APIs, or inputs does it connect to? | | Output | What does the finished product look like? | The more specific each element, the more production-ready the output. # Prompt Quality Examples #### Web App **Weak prompt:** "Build a crypto app" **Strong prompt:** "Build a Solana dashboard for active traders that connects to wallet balances, shows token performance across a 7-day window, includes real-time price charts via Pyth Network, displays transaction history, and allows swap execution via integrated DEX routing" #### DeFi Tool **Weak prompt:** "Build a DeFi dashboard" **Strong prompt:** "Build a DeFi portfolio tracker for Solana users that connects to their wallet, shows all active positions across Kamino, tracks yield in real time, displays liquidation risk levels, and sends alerts when health factor drops below a set threshold" #### SaaS Product **Weak prompt:** "Build a subscription app" **Strong prompt:** "Build a SaaS project management tool for freelancers with user authentication, client dashboard, invoice generation, Stripe subscription billing at $29/month, project timeline view, and file upload for deliverables" #### Marketplace **Weak prompt:** "Build a marketplace" **Strong prompt:** "Build a digital products marketplace where creators can upload files, set prices in USDC, buyers can purchase with Solflare wallet integration, files are delivered on payment confirmation, and creators see real-time revenue analytics" #### Mobile App **Weak prompt:** "Build a health app" **Strong prompt:** "Build a React Native mobile app for medication management with daily reminder notifications, medication database search, dosage tracking, appointment calendar, and emergency contact alerts for missed doses" #### Browser Extension **Weak prompt:** "Build a browser extension" **Strong prompt:** "Build a Chrome extension for Solana traders that shows real-time token prices in the toolbar, alerts on significant price movements, displays wallet balance without leaving the browser, and has a one-click swap button" #### NFT / Token App **Weak prompt:** "Build an NFT app" **Strong prompt:** "Build an NFT minting platform on Solana using Metaplex where creators can upload artwork, set royalty percentages, mint collections up to 10,000 items, display a gallery view, and enable secondary market listings" # Model Toggle Guide #### Eitherway lets you switch between models in real time. Use this as a guide:
| **Use Sonnet when:** | **Use Opus when:** | | ---------------------------- | ----------------------------- | | Building UI and layouts | Debugging complex logic | | Fast iteration and testing | Multi-step workflows | | Simple CRUD applications | Smart contract integration | | Landing pages and dashboards | Complex data relationships | | Quick MVP prototyping | System architecture decisions | **Rule of thumb:** Start with Sonnet. Switch to Opus when the system gets complex or something breaks. # Build Mode Guide
#### Web2 Mode Use for applications that don't require blockchain interaction. Best for: * SaaS tools and dashboards * Authentication and user management * Payment processing with Stripe * Content platforms and marketplaces * Internal tools and analytics
#### Web3 Mode Use for applications that interact with the blockchain. Best for: * Wallet integration and management * Token creation and SPL token support * Smart contract deployment * NFT minting and collections * DeFi interfaces and swap execution * On-chain data and transaction history #### Combining Both The real leverage comes from combining Web2 and Web3 in the same application. Example: A DeFi dashboard that uses Supabase for user accounts and preferences (Web2) while connecting to Solana for live portfolio data and swap execution (Web3). Always specify which layers you need in your prompt. # Add These to Every Prompt for Better Outputs #### The more context you give, the more production-ready the result. * Data sources Specify where the data comes from — wallet address, API, database, or user input. * Authentication State whether users need to log in and how — email, wallet, OAuth. * UI direction Describe the layout, tone, and style — "clean and minimal", "dark mode", "dashboard layout with sidebar navigation". * Error handling Ask for it explicitly — "include error states for failed transactions" or "handle empty states when no data is available". * Real-time requirements State if data needs to update live — "refresh wallet balance every 30 seconds" or "show live price feed". * Payment and monetization Specify if the app needs to charge users, accept USDC, or integrate Stripe. # Common Mistakes and How to Fix Them | **Mistake** | **Why it fails** | **Fix** | | ------------------------------ | ----------------------------------- | ----------------------------------------------- | | "Build something like Uniswap" | Too broad, no specific requirements | List the exact features you need | | "Make it look good" | No visual direction | Describe layout, colours, and style | | "Add blockchain" | No specifics | State the chain, wallet, and interaction type | | "Make it fast" | No technical direction | Specify caching, real-time, or API requirements | | One long prompt for everything | Overwhelms the system | Break into stages, build, then iterate | # The Iteration Method #### Don't try to build everything in one prompt. {% stepper %} {% step %} #### Stage 1 Core Build the core functionality only. Get it live. {% endstep %} {% step %} #### Stage 2 Data Connect your data sources. Real wallet, real API, real database. {% endstep %} {% step %} #### Stage 3 UI Refine the interface. Add styling, layouts, and empty states. {% endstep %} {% step %} #### Stage 4 Features Add secondary features one at a time. {% endstep %} {% step %} #### Stage 5 Launch Deploy. Then iterate based on real usage. {% endstep %} {% endstepper %} Each stage is a separate prompt. This produces better outputs than one complex prompt every time. # Prompt Templates #### Copy, edit, and use these as starting points. * **SaaS Dashboard** "Build a \[type] dashboard for \[user type] with \[auth method] login, \[key feature 1], \[key feature 2], \[data source], and \[monetization method]" * **DeFi Tool** "Build a \[DeFi type] tool for Solana users that connects to \[wallet], shows \[data type], integrates with \[protocol], and displays \[output]" * **Marketplace** "Build a marketplace where \[seller type] can \[action], \[buyer type] can \[action], payments processed via \[method], and \[key feature]" * **Mobile App** "Build a React Native mobile app for \[user type] with \[feature 1], \[feature 2], \[notification type], and \[data integration]" * **Token/NFT App** "Build a \[token/NFT] platform on Solana where users can \[action], with \[supply/royalty details], \[wallet integration], and \[secondary feature]" # The Prompt Sheet Summary ## The Prompt Sheet Summary ​ | **If you want** | **Add this to your prompt** | | ------------------ | -------------------------------------------------------------- | | Better UI | Describe layout, style, and navigation | | Real data | Name the API, wallet, or database | | Auth | Specify login method | | Payments | State the currency and flow | | Speed | Use Sonnet | | Complexity | Use Opus | | Web2 + Web3 | Specify both layers explicitly | | Production outputs | Use the full framework: What + User + Features + Data + Output | *** The constraint is no longer code. It's clarity. **eitherway.ai** # What is $EITHER Eitherway is a full-stack AI application development platform enabling any builder to generate, deploy, and tokenise a production-grade application from a single prompt. The platform integrates best-in-class Web2 and Web3 infrastructure, including Claude (Anthropic), Supabase, Stripe, Helius, Solflare, Pyth Network, Filecoin, and Google Cloud amongs others. All integrated into a single developer environment native to the Solana ecosystem. $EITHER is the native utility and governance token of the Eitherway protocol. It serves as the economic backbone of the ecosystem, linking platform activity directly to token value through a multi-surface deflationary engine. All mechanics are funded by real platform revenue. Not speculation, not token tax, not inflationary issuance. > **Core thesis:** every action taken on Eitherway reduces circulating supply, generates fee flow, or both. Platform growth and token scarcity are structurally coupled, not narratively coupled. # Token Overview | Parameter | Detail | | ---------------- | ---------------------------------------------------------------------- | | Token Name | $EITHER | | Token Standard | SPL Token (Solana) | | Total Supply | 100,000,000 (100M). Fixed supply. No inflation. No additional minting. | | Chain | Solana (Mainnet) | | Cross-Chain | To be announced | | Contract Address | HmBdm8vbisABUjkxms6ZUnoaXbfwFM6ymxShWfAENaoi | | Version | v1.1, subject to governance updates post-launch | # Token Distribution & Vesting The $EITHER distribution is structured to balance broad community ownership with long-term protocol sustainability. | Allocation | % of Supply | Tokens | Vesting / Lock Schedule | | ------------------------- | ----------- | --------------- | ------------------------------------------------------ | | Community & Public Market | 90% | 90,000,000 | Fully circulating at launch | | Protocol Incentives Pool | 5% | 5,000,000 | Released on a monthly emission schedule over 6 months. | | Team | 5% | 5,000,000 | 8-month cliff, 16-month vesting | | **Total** | **100%** | **100,000,000** | N/A | All team, investor, and treasury unlock schedules are published on-chain at launch and verifiable in real time. No wallet or entity may alter vesting schedules post-publication without a governance supermajority vote. # Platform Subscriptions $EITHER is a functional utility token. Value is derived from platform usage across six utility surfaces. #### Platform Subscriptions * Users may pay for platform subscriptions in fiat, USDC, or $EITHER * Payments in $EITHER receive a 20% cost reduction versus fiat equivalents * $EITHER subscribers receive early access to new platform features ahead of fiat-paying users * $EITHER subscribers receive enhanced governance weight per staked token * $EITHER subscribers receive priority visibility and placement in the Eitherway marketplace * 10% of all $EITHER received for subscriptions is permanently burned at point of payment # Platform Credits * Credits denominate all compute activity, builds, deployments, prompt executions, and GPU usage * Credits purchased with $EITHER incur a 15% burn at the point of purchase * Credit burns are the most frequent deflation event in the protocol. Every build, prompt, or deployment triggers a burn # Marketplace * All templates, plugins, and components in the Eitherway marketplace are transacted in $EITHER * Creators retain 80% of sale revenue, paid in fiat or USDC, eliminating sell pressure from creator payouts * The platform retains a 20% fee per transaction, of which 10% is permanently burned * Featured and promoted marketplace placements require active $EITHER staking # Staking * $EITHER holders may stake tokens to unlock platform subscription tiers without fiat payment * Staking Power = Tokens Staked x Days Locked * Staked tokens are removed from circulating supply for the full lock duration * Staking rewards are distributed in USDC where operationally viable, eliminating reward-driven sell pressure on $EITHER * Fiat-paying subscribers retain priority access above all staking tiers by default # Launchpad * The Eitherway Launchpad is open to all builders. No product requirement to initiate a token launch * All application tokens launched via the Launchpad are paired with $EITHER in a liquidity pool at the protocol level * Builders select a lock duration at launch. Longer locks earn a greater share of LP trading fees: * 1-year lock: 30% of LP trading fees returned to the builder * 3-year lock: 50% of LP trading fees returned to the builder * 5-year lock: 70% of LP trading fees returned to the builder * The $EITHER side of every LP pair is removed from circulating supply for the lock duration, while the locked LP continues to generate trading fees. Supply reduction and fee generation occur from the same launch event * Priority launchpad access, including featured placement, launch promotion, and governance-weighted launch approval, requires active $EITHER staking * Eitherway is the only platform where a builder can go from idea to deployed app to launched token, or launch the token first and build the product after. Both paths. One platform. # Developer Reputation & Scoring * Eitherway will introduce an on-chain developer reputation system tied to $EITHER activity * Reputation scores are accumulated through verifiable on-chain actions: apps deployed, builds completed, marketplace contributions, staking history, and governance participation * Higher reputation scores unlock access to premium platform features, enhanced launchpad terms, and elevated marketplace visibility * Reputation scores are non-transferable and tied to wallet identity * Builder credibility is established and verifiable on-chain through $EITHER activity # Governance * Governance rights are granted exclusively to staked $EITHER. Passive holders carry no voting power * Decisions cover roadmap priorities, protocol integrations, fee parameters, marketplace rules, and treasury spending * A minimum quorum threshold is required for any vote to be valid, preventing low-turnout governance capture * Protocol upgrades require a 60% supermajority vote to pass * All passed governance decisions are subject to a 48-72 hour execution delay, providing the community a response window before changes take effect * An Emergency Guardian Council holds veto power over decisions that pose an immediate security or financial risk to the protocol. Guardian positions are governed by community vote on a 12-month rotation * Treasury spending via governance is capped at 2% of treasury per vote # Staking Unlock Tiers The staking tier system rewards long-term commitment with platform access equivalents to paid subscriptions. Fiat-paying subscribers retain priority above all staking tiers. Staking is economically equivalent, not superior. | Tier | Platform Access | Credit Bonus | Referral Bonus | GPU Priority | | ---- | ------------------------ | ------------ | -------------- | --------------------------------- | | S1 | Free Tier unlocked | +5% | +5% | Starter GPU (below fiat users) | | S2 | Starter Tier unlocked | +10% | +10% | Pro GPU (below fiat users) | | S3 | Pro Tier unlocked | +15% | +15% | Enterprise GPU (below fiat users) | | S4 | Enterprise Tier unlocked | +20% | +20% | Maximum GPU priority for stakers | # Marketplace Economics | Parameter | Value | Notes | | ---------------------- | ------------------------ | ----------------------------------------------- | | Creator Revenue Share | 80% | Paid in fiat or USDC | | Platform Fee | 20% | Retained by protocol | | Marketplace Burn Rate | 10% of platform fee | Permanent on every transaction | | Featured Placement | Staking required | Active $EITHER stake unlocks promoted placement | | Buyback Allocation | Up to 35% of net revenue | Net of operational costs, monthly. . | | Incentives Pool Top-up | 5-10% of revenue | Monthly replenishment. | # Deflationary Engine The $EITHER deflationary engine operates across five mechanisms. All are funded by real platform revenue. Not by token allocation, treasury discretion, or token tax. #### Revenue Sources for Burns and Buybacks To avoid ambiguity, the following platform revenue streams explicitly fund the deflationary engine: * Subscription fees (fiat, USDC, and $EITHER) * Credit purchases across all payment methods * Marketplace fees (20% platform fee on all transactions) * Launchpad fees on every bonding curve token launch * API usage fees #### Burn & Buyback Table | Mechanism | Trigger Event | Rate / Effect | | ------------------ | ------------------------------------------------------------------ | --------------------------------------------------------- | | Subscription Burn | User pays subscription in $EITHER | 10% burned instantly at point of payment | | Credit Burn | User purchases credits in $EITHER | 15% burned instantly at point of purchase | | Marketplace Burn | Transaction completed in marketplace | 10% of platform fee burned per transaction | | Launchpad Fee Burn | App token launched via bonding curve | 20% of launchpad fee burned | | Buyback & Lock | Monthly, up to 35% of net protocol revenue after operational costs | $EITHER purchased from open market and locked long-term | | LP Lock | App token launch, $EITHER paired in LP | Locked 1-5 years; locked LP earns trading fees throughout | > All burn transactions are executed on-chain and publicly verifiable. Buyback and lock operations are funded from net protocol revenue after operational costs. Infrastructure, team, and platform expenses are deducted first. Buyback amounts and treasury balances are disclosed via a monthly treasury report published to the community. # Governance Framework Governance rights are restricted to staked $EITHER. Decisions are made by committed participants with skin in the game. #### Voting Rights * Governance rights are exclusively granted to staked $EITHER. Unstaked tokens carry no voting power * Voting weight is proportional to Staking Power: Tokens Staked x Days Locked #### Proposal & Voting Mechanics * A minimum quorum threshold must be met for any vote to be valid * Standard proposals pass with a simple majority of participating staked supply * Protocol upgrades, fee parameter changes, and vesting schedule modifications require a 60% supermajority * All passed decisions are subject to a 48-72 hour timelock before execution, providing the community a reaction window #### Emergency Guardian Council * An Emergency Guardian Council is elected by community governance on a 12-month rotation * The Council holds veto authority over any governance action that poses an immediate security, financial, or legal risk to the protocol * Council veto decisions are subject to a retrospective community ratification vote within 7 days * Council members may not hold more than 2% of staked supply individually, preventing concentration of emergency power #### Treasury Spending Controls * Treasury spending proposals are capped at 2% of total treasury value per governance vote * Cumulative treasury spending exceeding 10% of total treasury within any 90-day period requires a supermajority vote to authorise * All treasury transactions are executed transparently on-chain with publicly disclosed wallet addresses # Protocol Participation Rewards $EITHER distributes protocol rewards exclusively to participants who perform qualifying actions within the ecosystem. Yield is derived from the participant's own effort and output. Not from the activity of others. This structure is intentional and material to the protocol's legal positioning. The reward mechanism is designated as Protocol Participation Rewards. Not revenue share. #### Qualifying Actions * Deploying an application on the Eitherway platform * Running compute prompts and build operations * Referring new builders to the protocol * Publishing and selling in the Eitherway marketplace * Staking $EITHER and maintaining an active lock position * Accumulating developer reputation score through sustained on-chain activity #### Incentives Pool Structure * 5% of total token supply (5,000,000 $EITHER) is allocated to the Protocol Incentives Pool at genesis * The pool is replenished monthly from 5-10% of gross platform revenue * A minimum pool floor is maintained equivalent to 6 months of projected reward outflows * If the pool falls below the floor threshold, the replenishment rate increases automatically until the floor is restored * Reward distributions are paid in USDC where operationally viable, preserving $EITHER price integrity # Market Demand Drivers $EITHER has three demand drivers for market participants beyond active builders. #### 1. Launchpad Access Staking Priority launchpad visibility, including featured placement and governance-weighted launch approval, requires active $EITHER staking. As competition for visibility grows, staking demand grows with it. #### 2. Marketplace Featured Placement Featured marketplace positions require active $EITHER staking. Creators who want commercial visibility must stake to compete for placement. #### 3. Developer Reputation Scoring The on-chain developer reputation system ties builder credibility to verifiable $EITHER activity. Reputation cannot be purchased. It will be earned through sustained on-chain contribution. Builders who want to establish credibility must engage with $EITHER over time. > These three mechanics answer the investor question directly: $EITHER is demanded by traders who want launchpad access, creators who want marketplace visibility, and builders who want to establish on-chain reputation. None of these can be achieved without active token engagement. # Value Accrual Flywheel The table below maps platform growth events to their corresponding token mechanic and supply effect. | Platform Growth Event | Mechanism Activated | Supply / Demand Effect | | ----------------------------------- | ------------------------------------------------------- | --------------------------------------------------- | | User pays subscription in $EITHER | Subscription burn (10%) | Circulating supply decreases | | Marketplace transaction completed | Marketplace fee burn (10%) | Circulating supply decreases | | App token launched via Launchpad | LP lock (1-5 yrs) + launchpad fee burn (20%) | Supply locked; fees generated from same event | | Swaps on launched app tokens | Locked LP earns trading fees | Protocol earns while supply is constrained | | Platform revenue grows | Buyback and lock (up to 35% of net revenue after costs) | Open market supply tightened | | Builders stake for launchpad access | Tokens removed from circulation | Supply reduced; demand driven by access requirement | | Creators stake for marketplace | Tokens removed from circulation | Staking demand independent of build activity | | Builder reputation compounds | Sustained $EITHER engagement required | Long-term non-speculative demand | | Creator ecosystem expands | More marketplace transactions, more burns | Burn surface grows with platform scale | > The flywheel activates on usage. Not on price. Not on new buyers. Each mechanism generates supply pressure as a direct, automatic output of platform activity. # Sustainable Value Test The Sustainable Value Test asks one question: > If no new capital entered the $EITHER ecosystem tomorrow, would existing participants continue to benefit from using the protocol? The answer is yes. The reasoning is mechanical: * Builders continue to deploy applications because the product works independently of token price * Credit spend continues because compute is required for every build action, regardless of market conditions * Fees continue to route because platform activity is not contingent on token price * Buybacks continue to trigger because they are funded by revenue, not by token price * Burns continue to execute because they are activated by usage events, not by discretionary decision * LP locks continue to generate fees because swap activity does not depend on circulating supply * Developer reputation continues to compound because it is tied to on-chain activity, not to market conditions All token mechanics in this document are designed to satisfy this test. Value comes from utility and activity. Not from future buyers. # Risk Disclosures & Disclaimer This document is a draft tokenomics framework prepared for informational and planning purposes. It does not constitute a prospectus, investment advice, or a solicitation to purchase any financial instrument. * All percentages, rates, and allocations marked TBA are subject to change prior to public launch * Token mechanics are subject to governance modification following launch * Participation in the $EITHER ecosystem involves material risk including smart contract risk, regulatory risk, liquidity risk, and market risk * Revenue projections and burn rate estimates are forward-looking and subject to platform growth. No guarantee of specific burn volumes or buyback amounts is made * Past performance of comparable protocols is not indicative of future results * All prospective participants should conduct independent legal, financial, and technical due diligence prior to any participation * This document has not been reviewed or approved by any regulatory authority *Eitherway Protocol | eitherway.ai | $EITHER | Version 1.1* # Help Center

Have something to share with us?

Do not hesitate to write to us. We are always eager to hear feedback from our community.

:telegram:

Join Telegramhttps://www.gitbook.com/

:square-x-twitter:

Follow us on Xhttps://www.gitbook.com/

:globe-pointer:

Check out our Website!https://www.gitbook.com/

:heart:

Community Supporthttps://www.gitbook.com/

:briefcase:

Business Proposals https://www.gitbook.com/

:bullhorn:

Marketing Proposalshttps://www.gitbook.com/