5. Web3 Integration & Architecture
The ARN contracts are authored and audited by a separate firm. This engagement covers the contract read layer, wallet authentication, the platform services, and the switch from sample data to live Base reads. The platform issues no write calls to any contract.
5.1 Contract integrations
Between five and seven contract integrations are in scope; the seven identified to date are listed below. The platform issues no write calls to any contract. Contract state is read, displayed in plain language, and linked to BaseScan. Three integrations are live at launch; four ship against sample data and switch to live reads on contract handoff.
| Ref | Contract | Data read | MVP status |
|---|---|---|---|
| C-01 | ARN Token (ERC-20) | Balances, total supply, transfer history | Live at launch |
| C-02 | Vesting / Lock | Allocation entries, cliff dates, claimable amounts | Live at launch |
| C-03 | Sale / Allocation | Sale records, open and closed windows | Live at launch |
| C-04 | POMP Controller | Reserve figures, epoch states, activations | Sample-first |
| C-05 | Bonds | Bond amounts, access locks, tier thresholds | Sample-first |
| C-06 | Service Credits | Credit balances, reservations | Sample-first |
| C-07 | Pool Registry | Pool list, utilization figures | Sample-first |
- 1Balances of 2–3 treasury addresses nominated by Aerion are tracked in addition to the contract set at C-01 through C-07.
- 2Those treasury balances are displayed on the public transparency page with BaseScan links.
- 3Sample-first entries move to live reads under the conditions set out at §5.2.
5.2 Sample data and live reads
Every contract-connected view reads through a data abstraction rather than a direct chain call. The source behind that abstraction is a per-contract configuration value.
- 1Views are built and reviewed against structured sample data matching the real shape of each contract's state.
- 2Live Base reads replace that source once ABIs, deployment addresses, audit status and a test environment are provided.
- 3Switching a contract from sample to live is a configuration change, not a rebuild.
- 4Accounts, campaigns, purchase intents and admin records are stored in the platform database as off-chain data.
- 5Balances, vesting, reserves and pool state are read from the chain and are never stored as editable platform values.
- 6Views that combine off-chain and on-chain data label the source of each number.
Dependency — Contract handoff
5.3 Architecture and services
One Next.js application with three route zones: public pages, the authenticated investor dashboard, and the admin console. Fourteen services sit behind them.
- Application
- Next.js with TypeScript, responsive from phone to desktop. Public pages, investor dashboard and admin console are separated by route and by permission.
- Identity
- Two authentication paths on one account model: email sign-in for the platform account, wallet signature for on-chain identity. Roles control route access.
- Data
- One database for users, campaigns, allocations, admin records, the AI knowledge base and remaining off-chain state. Chain data is read and cached, never written back.
- API layer
- A typed API surface serving the dashboard, admin console, campaign engine, AI layer and Web3 read path, each with its own access rules.
- Integrations
- Product analytics and CRM sync for investor and waitlist records, implemented during the build.
- Deployment
- Vercel-class hosting with separate staging and production environments and environment-based configuration. Environments share no credentials or data.
| Ref | Service | Responsibility |
|---|---|---|
| S-01 | auth | Email sign-in, sessions, password and recovery flows |
| S-02 | wallet-auth | Wallet linking and signature-based identity checks |
| S-03 | user-profile | Account records, roles, access states, profile data |
| S-04 | allocation | Purchase intents, allocation records, receipts |
| S-05 | campaign | Bonus rules, windows, invite and referral codes |
| S-06 | contract-read | Typed read calls against the Base contract set |
| S-07 | indexer-cache | Cached chain reads so views stay fast under load |
| S-08 | price-reference | DEX/CEX reference price lookups where available |
| S-09 | ai-assistant | Retrieval and answering over approved sources |
| S-10 | content | Pools, sites, POMP status, documents, FAQs |
| S-11 | admin | Review queues, approvals, configuration, audit trail |
| S-12 | export-crm | CRM sync and exportable allocation and lead records |
| S-13 | notifications | Transactional email and in-app status messages |
| S-14 | data-abstraction | The single switch between sample and live sources |
5.4 Network scope
The MVP targets Base only. Chain configuration is kept out of the view layer so additional EVM networks can be added later as configuration work.
- 1All contract reads, wallet connections and explorer links target Base for the duration of this engagement.
- 2Ethereum, Arbitrum and comparable EVM networks can be added after launch without rebuilding the platform. They are not included in this price.
- 3Solana and other non-EVM networks use a different account and signing model. They form a separate engagement, priced separately.
5.5 Security posture
Security work in this engagement is application-level: access control, data separation, secret handling and input validation.
- 1Role-based access control across dashboard and admin routes.
- 2Audit logs recording admin actions that change money, access or state.
- 3Secure environment handling. Secrets and keys stay out of the repository and out of client bundles.
- 4Input validation on every write path, including admin forms and purchase intents.
- 5Risk and utility disclaimers wherever allocations, bonuses or projections appear.
- 6Off-chain and on-chain separation per §5.2, so a platform record cannot be displayed as a chain balance.
- 7Pre-launch QA pass covering permissions, flows and responsive behaviour.
Exclusion — Third-party security work
Exclusion — Smart-contract audits